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 */
}
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?
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 (RBUF, ResourceTemplate ()
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000007,
}
Memory32F ixed (ReadWrite,
0xFED81500, // Address Base
0x00000400, // Address Length
)
Return (RBUF) /* \_SB_.GPIO. _CRS.RBUF */
{
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
{
{
})
}
Method (_STA, 0, NotSerialized) // _STA: Status
Return (0x0F)
Else
Return (0x00)
{
If ((TSOS >= 0x70))
{
}
{
}
}
}
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?