Ubuntu
linux package

  1. Mantic (23.10)
  2. Bug #2034477
  3. Comment #92

Comment 92 for bug 2034477

Revision history for this message
In , jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote :

Hi p0lloc,

I read in bug 217873 that you already have tried to add your model to the DMI quirks to make drivers/acpi/resource.c use the MADT override info on your AMD Zen based laptops resulting in:

ACPI: IRQ 1 override to edge, high(!)

Showing up in the log, which is what that DMI quirk should do. So it looks like you got the patch right but this unfortunately does not help.

This suggests that your IdeaPad Slim 3 14AMN8 is a whole new category of kbd IRQ bug where neither the DSDT nor the MADT override info is correct (what fun).

This really shows once more that to fix this once and for all we need to find a way to readback the actually IRQ settings setup by the BIOS at boot and use those (ignoring all the tables which tell us the info since those seem to be unreliable).

But for now first lets confirm that this really is an IRQ type / polarity issue.

By default 6.6-rc5 uses "edge low" as trigger type and with the DMI quirk which you tested it uses "edge high" as trigger type and neither works.

We have seen several Intel based laptop models which need to NOT use the MADT override so that they stick with the DSDT setting of "level low" so lets give that a try.

I'll attach a quick hack which ignores all the ACPI tables and just sets IRQ1 directly to "level low". Please build a kernel with this and see if this helps.

If it does not help please try "level high" by changing:

                u8 pol = ACPI_ACTIVE_LOW;

to:

                u8 pol = ACPI_ACTIVE_HIGH;

Note a level IRQ with the wrong polarity (low vs high) will lead to an interrupt storm which might very well lead to a non booting system. So make sure you have an entry for another kernel in your grub menu as fallback.

Also if the IRQ storm is not "bad" enough it may seem as if everything works, while at the same time the CPU is very busy.

So if things seem to work please run:

cat /proc/interrupts

and check that the numbers for IRQ 1 are not going crazy (each keypress should add 2 to the IRQ count one for press + one for release).