Comment 103 for bug 2034477

Something I want to point out a few things about p0lloc's logs I noticed.

1) This system is Mendocino based, which I want to say is the first time we've seen one of these IRQ bugs outside of Cezanne, Barcelo and Rembrandt. There isn't anything fundamental about Mendocino incompatibilities, just want to mention it in case it shows any patterns in the future.

2) The GPIO controller failed to set up. It's possible that there is an IRQ storm going on because those interrupts aren't being serviced.

[ 0.276113] amd_gpio AMDI0030:00: error -EINVAL: IRQ index 0 not found
[ 0.278464] amd_gpio: probe of AMDI0030:00 failed with error -22

I do see that IRQ should be IRQ 7 from that acpidump.

        Device (GPIO)
        {
            Name (_HID, "AMDI0030") // _HID: Hardware ID
            Name (_CID, "AMDI0030") // _CID: Compatible ID
            Name (_UID, 0x00) // _UID: Unique ID
            Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }
                    Memory32Fixed (ReadWrite,
                        0xFED81500, // Address Base
                        0x00000400, // Address Length
                        )
                })
                Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
            }

            Method (_STA, 0, NotSerialized) // _STA: Status
            {
                If ((TSOS >= 0x70))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (0x00)
                }
            }
        }

3) I don't see any reasons that it should be on IRQ12.

Regarding Suroto's logs:

1) The system is also Mendocino based.
2) I see the same amd_gpio probe failed error.

IMO we should start out with fixing the problem causing the probe for amd_gpio to fail on both of these systems and hopefully that leads to a solution for the keyboard as well.

Maybe we can start with /proc/ioports and /proc/iomem (both captured as root) to look for any resource overlap or misassignment relative to what the kernel is declaring. Or Hans, do these mentions jog any other ideas for you?