Bug 213031

Summary: MEDION notebook internal keyboard not recognized / not working correctly
Product: ACPI Reporter: Manuel Krause (manuelkrause)
Component: Config-InterruptsAssignee: acpi_config-interrupts
Status: RESOLVED CODE_FIX    
Severity: normal CC: dmitry.torokhov, greearb, grewtmp+6gaym, hui.wang, jamie, kernel, pgnet.dev, pulverized_deglazing, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.11.+ Tree: Mainline
Regression: No
Attachments: i8042 kernel parameters testing results
i8042 kernel parameters testing results
dmesg log of kbd testing @ #11
Working patch to enable internal keyboards on MEDION M15T based notebooks
Function-key-test MK
2nd variant of working patch to enable internal keyboard on MEDION M15T notebooks
a new testing patch
final version patch
EPIA SN acpidump output
EPIA SN successful boot dmesg
Acer Swift 3 dmesg output 4.19.197
dmesg from 5.13.5+ with patch reverted.
dmesg with modified patch

Description Manuel Krause 2021-05-11 19:37:50 UTC
Hi kernel people,

I really hope that I'm right on here to ask for your help with my new notebook's keyboard:
From dmesg: "DMI: MEDION P15651/M15T, BIOS 209 11/24/2020". OS: openSUSE Tumbleweed, kernel: custom vanilla 5.12.2 with a slightly reduced .config from openSUSE default.

Problem: With Linux booted, the internal keyboard doesn't work correctly. It fully works in Windows 10 and in the GRUB2 menu.
The only keyboard keys working under Linux are three function keys for the display-backlight (-/+/on&off == Fn+F5/F6/F7) and keyboard-backlight (Fn+SPACE).
The internal touchpad works, but this is driven over I2C, as it looks like.
An external keyboard (in my case a PS/2 via USB-adapter) works fine.
Under Win 10 the keyboard looks like to be driven by the standard driver: I8042PRT.SYS [5] 

The manufacturer and the vendor (MEDION, ALDI) are stuck to Windows-only, no constructive support available, not even from their user community support forum. [1] 

There are some very few reports on the web, telling me that I'm not the only one with this issue and we're getting more over time [2...3]. Source list at the bottom. I've tested all of the basic suggested debugging proposals without effort.

Affected Notebooks as of 2021-05-11:
MEDION P15651 (model: M15T)    [1], [2]
MEDION S15450 (model: M15T)    [1], [2]
MEDION S15449 (model: M15T)    [3], [2]
MEDION S154495 (typo?)         [2]
Seems like all have the TigerLake chipset and the same CPU, Intel 11th Gen Intel Core i5-1135G7, in common.


Stumbling over the many kernel options for i8042 I lost any path for further testing for a useful targeted debugging. Although, I've tried some random patterns without effort, so far.

Maybe someone of you can tell me what path would be useful for debugging this odd keyboard + controller and / or whom to contact.

I'd provide any info you need upon your request, I just have lost any sense about what you might find useful, atm.
(Please move this posting to a more appropriate thread if beneficial !)

Best regards and TIA,
Manuel

Sources of information:
 [1] https://community.medion.com/t5/Notebook-Netbook/Hilfeanfrage-MEDION-P1561-Notebook-Tatstatur-keyboard-Linux/td-p/110891    (german)
 [2] https://forums.linuxmint.com/viewtopic.php?f=49&t=339480
 [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814
 [4] https://forums.linuxmint.com/viewtopic.php?t=341013    (espagnol)
[5] https://forums.linuxmint.com/viewtopic.php?p=1995078&sid=58ce5aca7c82ae431d721deb9e6c47b6#p1995078

Many thanks go to the participants for their provided information !
Comment 1 George Dited 2021-05-14 22:03:04 UTC
Hi everyone,

i confirm everything said by Manuel Krause and i would add that, surprisingly, the the keyboard works well in the FreeBSD 12 Installer but i coulnd't install the system becouse it didn't detect the wifi chip.

So the problem is only related to Linux.

I hope this information will be useful.

George
Comment 2 Hui Wang 2021-05-25 03:08:59 UTC
Please check if there is a /sys/devices/platform/i8042 folder?

If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices there.
Comment 3 Manuel Krause 2021-05-25 19:49:56 UTC
Created attachment 296979 [details]
i8042 kernel parameters testing results

During the past weeks I've done some testing with the i8042 and atkbd kernel parameter options.
I hope the .txt "chart" is readable for you.
Comment 4 Manuel Krause 2021-05-25 20:03:16 UTC
(In reply to Hui Wang from comment #2)
> Please check if there is a /sys/devices/platform/i8042 folder?
> 
> If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices
> there.

The folder /sys/devices/platform/i8042 does exist. And in /sys/bus/serio/devices/ there is one item "serio0" which is a link to "../../../devices/platform/i8042/serio0".
This also corresponds to the enumeration shown in dmesg early:
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

I've used "xev", but as expectable, when kernel doesn't like the keyboard, only the above mentioned keyboard keys do produce a response.

Thank you very much for your highly appreciated support !

Best regards,
Manuel
Comment 5 Hui Wang 2021-05-26 00:45:52 UTC
(In reply to Manuel Krause from comment #4)
> (In reply to Hui Wang from comment #2)
> > Please check if there is a /sys/devices/platform/i8042 folder?
> > 
> > If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices
> > there.
> 
> The folder /sys/devices/platform/i8042 does exist. And in
> /sys/bus/serio/devices/ there is one item "serio0" which is a link to
> "../../../devices/platform/i8042/serio0".
> This also corresponds to the enumeration shown in dmesg early:
> input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input0
> 
I checked all dmesg in the https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814, there is no "input: AT Translated Set 2 keyboard as...", how did you make that happen?

If you could make the "input: AT Translated Set 2 keyboard as..." show in the dmesg, that means the keyboard is found and registered. Then could you try 'sudo showkey' and 'sudo showkey -s' and press some keys, this will print keycode or scancode of the key you pressed.

thx.
Comment 6 Manuel Krause 2021-05-26 22:06:32 UTC
(In reply to Hui Wang from comment #5)
> I checked all dmesg in the
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814, there is no
> "input: AT Translated Set 2 keyboard as...", how did you make that happen?
> 
> If you could make the "input: AT Translated Set 2 keyboard as..." show in
> the dmesg, that means the keyboard is found and registered. Then could you
> try 'sudo showkey' and 'sudo showkey -s' and press some keys, this will
> print keycode or scancode of the key you pressed.
> 
> thx.

That's a point. I haven't noticed it. 
I've now searched several dmesg logs, and "input: AT Translated Set 2 keyboard as..." looks like to have appeared only with my latest keyboard-test parameter change in kernel command line to: i8042.dumbkbd=1 i8042.noaux=1 i8042.kbdreset=1

Unfortunately, your suggested use of "showkey" only gives poor feedback:
Only the keys for display brightness (Fn+F5/F6) show something:

showkey:
keycode 224 press
keycode 224 release
keycode 225 press
keycode 225 release

showkey -s:
0xe0 0x4c 0xe0 0xcc 
0xe0 0x54 0xe0 0xd4

TIA
Comment 7 Manuel Krause 2021-05-28 19:20:21 UTC
Created attachment 297029 [details]
i8042 kernel parameters testing results

Let me add the updated chart of my keyboard related testing.

From my short analysis, the parameter 'i8042.dumbkbd=1' looks like to lead to the enumeration line "input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0" in dmesg, but it doesn't lead to added functionality, as reported above.

Below I'd add a dmesg log from my last test.
Comment 8 Manuel Krause 2021-05-28 19:43:10 UTC
Created attachment 297031 [details]
dmesg log of kbd testing @ #11

Here comes a dmesg of my last test No. #11.

In here, we see little additional output of 'i8042.debug=1' and 'i8042.unmask_kbd_data=1' kernel command line parameters.
Shouldn't there be some interrupt related calls?

I've made some other finding, what hasn't occurred on my last and much older notebook: The lines 570+
[    0.422398] ACPI: IRQ 1 override to edge, high
[    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)

If I got it correctly, the IRQ 1 and the ID PNP0303 correspond to the KBD port.
Would the "override to edge, high" be correct? (It's in /usr/src/linux/drivers/acpi/resource.c @line 409 in kernel 5.12.7.)

Both may be misleading traces, but I want to also add odd thoughts.
Comment 9 Hui Wang 2021-05-31 03:05:17 UTC
If you press non-function keys on the keyboard, does it trigger interrupt? (by checking "/proc/interrupts/ | grep i8042"


And you could add noapic in the bootargs to skip the irq override, that means the log in the comment 8 will not show if you add noapic:
[    0.422398] ACPI: IRQ 1 override to edge, high
[    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)
Comment 10 Manuel Krause 2021-05-31 22:23:27 UTC
(In reply to Hui Wang from comment #9)
> If you press non-function keys on the keyboard, does it trigger interrupt?
> (by checking "/proc/interrupts/ | grep i8042"

'cat /proc/interrupts | grep i8042':
1:   0   0   0   0   0   0   0   0  IR-IO-APIC  1-edge   i8042
Even the function keys don't change this. :-(
(This is still with the last mentioned parameter setup #11.)

> And you could add noapic in the bootargs to skip the irq override, that
> means the log in the comment 8 will not show if you add noapic:
> [    0.422398] ACPI: IRQ 1 override to edge, high
> [    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)

Please give me some time for this "noapi" testing. Maybe I therefor should change some of the parameters or leave them at default. If you have hints regarding those, please let me know!
Comment 11 Manuel Krause 2021-05-31 23:16:20 UTC
Short update:
With changed related parameters to: 
i8042.debug=1 i8042.unmask_kbd_data=1 i8042.direct=1 i8042.dumbkbd=1 i8042.kbdreset=1 atkbd.reset=1 noapic

I get the following in dmesg:
[    1.396863] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    1.396865] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    1.396954] i8042: [1] 20 -> i8042 (command)
[    1.397163] i8042: [1] 65 <- i8042 (return)
[    1.397239] i8042: [1] 20 -> i8042 (command)
[    1.397449] i8042: [1] 65 <- i8042 (return)
[    1.397489] i8042: [1] 60 -> i8042 (command)
[    1.397910] i8042: [2] 34 -> i8042 (parameter)
[    1.398770] i8042: [2] 60 -> i8042 (command)
[    1.398887] i8042: [2] 25 -> i8042 (parameter)
[    1.398907] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.398927] i8042: [3] Interrupt 1, without any data
[    1.399086] mousedev: PS/2 mouse device common for all mice
[    1.399111] input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

After some keys pressed:
'cat /proc/interrupts | grep i8042':
1:   1   0   0   0   0   0   0   0  XT-PIC   i8042

I'm clueless about how to go on. I'm not even sure to be searching in the right place. Is this an i8042 keyboard at all? 
I really don't want to disassemble this new machine.
Comment 12 Hui Wang 2021-06-01 01:47:39 UTC
(In reply to Manuel Krause from comment #10)
> (In reply to Hui Wang from comment #9)
> > If you press non-function keys on the keyboard, does it trigger interrupt?
> > (by checking "/proc/interrupts/ | grep i8042"
> 
> 'cat /proc/interrupts | grep i8042':
> 1:   0   0   0   0   0   0   0   0  IR-IO-APIC  1-edge   i8042
> Even the function keys don't change this. :-(
> (This is still with the last mentioned parameter setup #11.)
> 
The function key event is reported to kernel through acpi event, it triggers acpi irq instead of i8042 irq.
Comment 13 Hui Wang 2021-06-01 02:13:33 UTC
(In reply to Manuel Krause from comment #11)

> 1:   1   0   0   0   0   0   0   0  XT-PIC   i8042
> 
> I'm clueless about how to go on. I'm not even sure to be searching in the
> right place. Is this an i8042 keyboard at all? 
> I really don't want to disassemble this new machine.
Someone said the keyboard works well under windows, you could check if it is i8042 keyboard from windows, and what driver is used for it and what resource is assigned to it. For example, the driver is system32\drivers\i8042prt.sys system32\drivers\kbdclass.sys


And if you could build the kernel yourself, you could change the keyboard irq forcibly to below 4 combos (and remove noapic, remove i8042 related parameters like i8042.dumbkbd=1...):
Level High
Level Low
Edge High
Edge Low

This is an example diff to forcibly set the irq to LEVEL Low:

--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -401,10 +401,16 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
         * using extended IRQ descriptors we take the IRQ configuration
         * from _CRS directly.
         */
+       printk("wwwwwwwhhhhhhhhhhhhh gsi = %d triggering = %d polarity = %d\n",
+              gsi, triggering, polarity);
        if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
                u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
 
+               if (gsi == 1)  {
+                       trig = ACPI_LEVEL_SENSITIVE;
+                       pol = ACPI_ACTIVE_LOW;
+               }
                if (triggering != trig || polarity != pol) {
                        pr_warn("ACPI: IRQ %d override to %s, %s\n", gsi,
                                t ? "level" : "edge", p ? "low" : "high");
Comment 14 Manuel Krause 2021-06-01 18:19:19 UTC
(In reply to Hui Wang from comment #13)

There's nothing better than constructive collaboration with Linux people !

You have led to a first success. :-D  I thank you very much !!!

> Someone said the keyboard works well under windows, you could check if it is
> i8042 keyboard from windows, and what driver is used for it and what
> resource is assigned to it. For example, the driver is
> system32\drivers\i8042prt.sys system32\drivers\kbdclass.sys

Yes, toma1970 @linuxmint said it and he re-checked the related driver for me, as I haven't been brave enough to play back my windows backup. (Source: https://forums.linuxmint.com/viewtopic.php?p=2015222&sid=21339e6e4397312b231f3927bfa6d962#p2015222 )

> And if you could build the kernel yourself, you could change the keyboard
> irq forcibly to below 4 combos (and remove noapic, remove i8042 related
> parameters like i8042.dumbkbd=1...):
> Level High
> Level Low
> Edge High
> Edge Low

I've taken your column above, and my first shot "LEVEL HIGH" enabled the keyboard under Linux in tty1 and under X.

Unfortunately, the keypresses do lag for a noticeable amount of ms (also to repeating too often).

Let me check, whether one of the other combos do it better.

Would you say that having "threadirqs" in kernel command line may be counter-productive?
And, could removing the external kbd (via USB adapter) prevent the lagging?
Comment 15 Manuel Krause 2021-06-01 19:59:28 UTC
Short update:

Using "LEVEL LOW" in your patch proposal works PERFECTLY now.

No lagging, no multiple repeating, no false characters printed.

There's also no interference with an addtitionally connected kbd, like mine. The "threadirqs" parameter also doesn't harm atm.

I'm so thankful, that you helped leading to a usable solution, you can't imagine!

My very best regards to you, Hui Wang,

Manuel
Comment 16 Manuel Krause 2021-06-01 20:14:32 UTC
Created attachment 297109 [details]
Working patch to enable internal keyboards on MEDION M15T based notebooks

tested on kernel 5.12.8
Comment 17 Manuel Krause 2021-06-01 22:12:27 UTC
Can be that some special keys don't work with that setup:

Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10...12 (sound).

The brightness and screen Fn keys do work (Fn + F5..F8).
Comment 18 Manuel Krause 2021-06-02 17:41:28 UTC
By now, I've also tested the other variants, to make the pattern filled. Also the last one does work.

Complete result:
LEVEL HIGH: lagging keypresses, repeated keypresses, Shift working wrongly
LEVEL LOW:  no problems, only special keys failing *)
EDGE HIGH:  no internal kbd available, the original setup under this BIOS + Linux
EDGE LOW:   no problems, only special keys failing *)

*) The Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10..12 (sound) don't work. The sound keys can go mad (keypresses repeated !). The brightness and screen Fn keys do work (Fn + F5..F8).
Between these different settings I can't notice any difference using the kbd.

Besides these little issues I'm very glad to use this notebook as it is intended, now.

I'm really curious on how we get this into the kernel, and in what appropriate fashion.

Best regards, 
Manuel
Comment 19 Hui Wang 2021-06-03 04:19:55 UTC
(In reply to Manuel Krause from comment #18)
> By now, I've also tested the other variants, to make the pattern filled.
> Also the last one does work.
> 
> Complete result:
> LEVEL HIGH: lagging keypresses, repeated keypresses, Shift working wrongly
> LEVEL LOW:  no problems, only special keys failing *)
> EDGE HIGH:  no internal kbd available, the original setup under this BIOS +
> Linux
> EDGE LOW:   no problems, only special keys failing *)
If your machine have s2idle by default instead of deep, after your machine enter suspend, you could wakeup the system by the normal keys on the keyboard like the key "Enter", Do the both LEVEL LOW and EDGE LOW could wakeup the system by Enter key? or only one of them could? 

> 
> *) The Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10..12 (sound)
> don't work. The sound keys can go mad (keypresses repeated !). The
> brightness and screen Fn keys do work (Fn + F5..F8).
For those unusable function keys, if you run 'sudo showkey -s/sudo showkey' and press those keys, is there any keycode?

Then run 'acpilisten' and press those keys, is there any acpi event?

The function keys are usually implemented by acpi event, and the driver for them is usually in the drivers/platform/x86/*.c

> Between these different settings I can't notice any difference using the kbd.
> 
> Besides these little issues I'm very glad to use this notebook as it is
> intended, now.
> 
> I'm really curious on how we get this into the kernel, and in what
> appropriate fashion.
> 
> Best regards, 
> Manuel
Comment 20 Manuel Krause 2021-06-03 23:40:51 UTC
(In reply to Hui Wang from comment #19)
> If your machine have s2idle by default instead of deep, after your machine
> enter suspend, you could wakeup the system by the normal keys on the
> keyboard like the key "Enter", Do the both LEVEL LOW and EDGE LOW could
> wakeup the system by Enter key? or only one of them could? 

From "cat /sys/power/state" I only have "freeze mem disk".
Both, freeze & mem come back normally, once 'anykey' pressed. LEVEL LOW or EDGE LOW don't make a difference.
Comment 21 Manuel Krause 2021-06-03 23:48:56 UTC
Created attachment 297139 [details]
Function-key-test MK

I've collected the keyboard function-key tests.
Comment 22 replydev 2021-06-04 13:39:41 UTC
Hi everyone I wanted to report that I have tested the patch of Manuel Krause on Kernel 5.12.9, compiled with Arch Build System and that the internal keyboard works properly except the malfunctions with the Fn functions.
Comment 23 Manuel Krause 2021-06-04 19:01:40 UTC
Created attachment 297159 [details]
2nd variant of working patch to enable internal keyboard on MEDION M15T notebooks

This is the second variant to drive IRQ 1 for the kbd, that's working properly on my notebook. On my system it works without dis-/advantages. 
I want to add it for completeness and for the case that someone has spare time to cross-test it with the other.
Please note: This is preliminary code to enable and test basic kbd function.
Comment 24 Dmitry Torokhov 2021-06-05 22:45:47 UTC
What are the original level and trigger values for IRQ1, before we remap them to "edge, high"?
Comment 25 Hui Wang 2021-06-06 08:12:02 UTC
(In reply to Dmitry Torokhov from comment #24)
> What are the original level and trigger values for IRQ1, before we remap
> them to "edge, high"?

Through disassembling DSDT, the original level and trigger is LEVEL_LOW.

      Device (PS2K)
        {
            Name (_HID, "MSFT0001")  // _HID: Hardware ID
            Name (_CID, EisaId ("PNP0303") /* IBM Enhanced Keyboard (101/102-key, PS/2 Mouse) */)  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0060,             // Range Minimum
                    0x0060,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IO (Decode16,
                    0x0064,             // Range Minimum
                    0x0064,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IRQ (Level, ActiveLow, Exclusive, )
                    {1}
Comment 26 Hui Wang 2021-06-06 14:19:25 UTC
Created attachment 297187 [details]
a new testing patch

This is a testing patch, I tested it on over 10+ lenovo and 10+ dell machines.
Comment 27 Manuel Krause 2021-06-06 18:43:51 UTC
(In reply to Hui Wang from comment #26)
> Created attachment 297187 [details]
> a new testing patch
> 
> This is a testing patch, I tested it on over 10+ lenovo and 10+ dell
> machines.

Quite comprehensive -- and great work --
that approach also works fine on here (MEDION Akoya P15651/M15T).

(I assume, the failing Fn+ keys are a different issue, not to be followed in this thread from now on.)

Thank you very very much and best regards,

Manuel
Comment 28 replydev 2021-06-09 19:15:50 UTC
(In reply to Hui Wang from comment #26)
> Created attachment 297187 [details]
> a new testing patch
> 
> This is a testing patch, I tested it on over 10+ lenovo and 10+ dell
> machines.

I wanted to ask, what is the practical difference between these three patches? Is there a patch that is better to use? Will these fixes be merged into mainline kernel?

Thanks for your work.
Comment 29 Hui Wang 2021-06-10 11:39:30 UTC
Created attachment 297289 [details]
final version patch

This is the final version of patch and which is merged to linux-acpi repository.


https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=0ec4e55e9f571f08970ed115ec0addc691eda613
Comment 30 Zhang Rui 2021-06-16 07:23:37 UTC
We can mark this as Resolved as the patch is in Rafael's tree.
Will close later once the patch hits upstream.
Comment 31 Manuel Krause 2021-06-17 15:26:50 UTC
The right steps. Thank you very much again!

Do you have some advice for me / us regarding the problematic Fn+ F10, F11, F12 keys, responsible for the sound (mute, -, +) ? These keys don't send a release event (https://bugzilla.kernel.org/attachment.cgi?id=297139).
Is there a practical way to change this behaviour?

Of course, I would wait for this code_fix from here landing in mainline before eventually opening a new bug, but maybe you can suggest another way of "best practice" from your expertise and opinion regarding this topic. 

TIA, 
Manuel
Comment 32 Jamie Heilman 2021-07-16 05:41:43 UTC
Created attachment 297893 [details]
EPIA SN acpidump output

The patch for this bug that went into 5.14-rc1 pretty much broke booting on my EPIA SN mainboard.  acpidump output attached.
Comment 33 Jamie Heilman 2021-07-16 05:46:57 UTC
Created attachment 297895 [details]
EPIA SN successful boot dmesg

Here's the dmesg from 5.10.50 with the patch reverted after a successful boot up.
Comment 34 Hui Wang 2021-07-16 05:59:51 UTC
@Jamie,

In theory, the patch could affect this device to override the irq:

[   21.304854] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[   21.305826] ACPI: IRQ 3 override to edge, high
[   21.310533] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
[   21.311313] ACPI: IRQ 3 override to edge, high
Comment 35 Jamie Heilman 2021-07-16 06:08:23 UTC
Given that 00:00 is the rtc and 00:01 is ttyS0 (the port I use for console), and that my serial console was mostly unusable It'd say it atleast messed up my serial port pretty good.  I couldn't ssh into the host so I'm not sure if the rtc was broken too.
Comment 36 Hui Wang 2021-07-16 06:21:06 UTC
@Jamie,

It is the irq of the UART, the BIOS defines the UART irq to be Edge and ActiveLow, the kernel will override the irq to Edge and ActiveHigh without this patch. After applying this patch, the irq of the UART will keep to be Edge and ActiveLow.

The RTC should have no change with or without this patch.
Comment 37 Hui Wang 2021-07-17 00:32:11 UTC
@Jamie,

Let us wait for a couple of days, to see how many machines and how many devices are affected by this patch.
Comment 38 PGNd 2021-07-25 15:12:55 UTC
hi,

fyi, this commit

   96b15a0b45182f1c3da5a861196da27000da2e3c

breaks boot for BayTrail J1900 (Celeron) , without any 'MEDION' kybd.

cref,

 "boot of J1900 (quad-core Celeron) mobo: kernel <= 5.12.15, OK; kernel >= 5.12.17, 5.13.4, slow boot (>> 660 secs) + hang/FAIL"
  https://lore.kernel.org/regressions/3491db05-3bb4-a2c9-2350-881a77734070@gmail.com/
Comment 39 Hui Wang 2021-07-26 01:03:26 UTC
Hi PGNd,

Could you please upload the dmesg with kernel 5.12.15 (without this patch) and the acpidump. Let us see what device is broken by this patch.

thx.
Comment 40 PGNd 2021-07-26 02:10:13 UTC
hi,

here's from the currently running/WIP system:

  https://pastebin.com/4SWZFZw6

If different log levels / flags / etc are more useful, I can provide; Pls just specify.
Comment 41 Hui Wang 2021-07-26 02:40:34 UTC
	[    0.896187] ACPI: IRQ 4 override to edge, high
	[    0.896202] pnp 00:03: [dma 0 disabled]
	[    0.896313] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active)

What device uses irq 4? (less /proc/interrupts), maybe it is also a uart/16550 device?
Comment 42 Manuel Krause 2021-07-26 02:50:32 UTC
@PGNd:

Quite a long command line...

Can you try the affected system WITHOUT:
 acpi_osi=Linux
 acpi=force
 acpi_enforce_resources=lax

by removing them @ kernel commandline?

and see what get's better/ worse?
Comment 43 PGNd 2021-07-26 02:55:19 UTC
it's my serial port.


dmesg | grep ttyS | grep I/O
	[    1.776602] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

setserial -g /dev/ttyS[0123456789] | grep -v unk
	/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4

stty -F /dev/ttyS0
	speed 38400 baud; line = 0;
	min = 1; time = 0;
	-brkint -icrnl -imaxbel iutf8
	-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

less /proc/interrupts
      1             CPU0       CPU1       CPU2       CPU3
      2    4:          0          0          0       1743   IO-APIC    4-edge      ttyS0
      3    8:          0          0          0          0   IO-APIC    8-fasteoi   rtc0
      4    9:          0          0          0          0   IO-APIC    9-fasteoi   acpi
      5   18:          0          0          4          0   IO-APIC   18-fasteoi   i801_smbus
      6   86:          0          0          0          0   IO-APIC   86-fasteoi   soc_dts
      7   90:     241649          0          0          0   PCI-MSI 311296-edge      ahci[0000:00:13.0]
      8   91:          0        368          0          0   PCI-MSI 327680-edge      xhci_hcd
      9   92:          0          1          0          0   PCI-MSI 1048576-edge      enp2s0
     10   93:          0          0     716190          0   PCI-MSI 1048577-edge      enp2s0-TxRx-0
     11   94:          0          0          0     413704   PCI-MSI 1048578-edge      enp2s0-TxRx-1
     12   95:     409990          0          0          0   PCI-MSI 1048579-edge      enp2s0-TxRx-2
     13   96:          0     774810          0          0   PCI-MSI 1048580-edge      enp2s0-TxRx-3
     14   97:          0          0          1          0   PCI-MSI 1572864-edge      enp3s0
     15   98:          0          0          0     633608   PCI-MSI 1572865-edge      enp3s0-TxRx-0
     16   99:     404869          0          0          0   PCI-MSI 1572866-edge      enp3s0-TxRx-1
     17  100:          0     379214          0          0   PCI-MSI 1572867-edge      enp3s0-TxRx-2
     18  101:          0          0     757198          0   PCI-MSI 1572868-edge      enp3s0-TxRx-3
     19  102:       1183          0          0          0   PCI-MSI 32768-edge      i915
     20  103:          0         17          0          0   PCI-MSI 425984-edge      mei_txe
     21  104:         56          0          0          0   PCI-MSI 442368-edge      snd_hda_intel:card0
     22  NMI:         21         22         24         17   Non-maskable interrupts
     23  LOC:    1248777    1112029     964671     719102   Local timer interrupts
     24  SPU:          0          0          0          0   Spurious interrupts
     25  PMI:         21         22         24         17   Performance monitoring interrupts
     26  IWI:       1668        713       2961       3071   IRQ work interrupts
     27  RTR:          0          0          0          0   APIC ICR read retries
     28  RES:       7295       9933       4263       2207   Rescheduling interrupts
     29  CAL:      36608      59082      62042      45137   Function call interrupts
     30  TLB:        294         77        116        143   TLB shootdowns
     31  TRM:          0          0          0          0   Thermal event interrupts
     32  THR:          0          0          0          0   Threshold APIC interrupts
     33  DFR:          0          0          0          0   Deferred Error APIC interrupts
     34  MCE:          0          0          0          0   Machine check exceptions
     35  MCP:          0          0          0          0   Machine check polls
     36  ERR:          0
     37  MIS:          0
     38  PIN:          0          0          0          0   Posted-interrupt notification event
     39  NPI:          0          0          0          0   Nested posted-interrupt event
     40  PIW:          0          0          0          0   Posted-interrupt wakeup event
Comment 44 PGNd 2021-07-26 03:01:05 UTC
> Can you try the affected system WITHOUT:
>  acpi_osi=Linux
>  acpi=force
>  acpi_enforce_resources=lax

Without "acpi=force reboot=acpi", the system locks up on reboot, fails to restart, and requires a manual reset.

"acpi_enforce_resources=lax" is (well, at least was) needed get sensors working; since ~
https://bugzilla.kernel.org/show_bug.cgi?id=204807
Comment 45 PGNd 2021-07-26 03:02:54 UTC
> Quite a long command line...

ack'd.

&, just to not be un-clear, it's been working -- in this content/form -- for ages.  and, still does ...
up to the aforementioned commit.
Comment 46 Hui Wang 2021-07-26 06:19:36 UTC
The PGNd's issue is same as the one of comment32~37, the root cause is in the comment36.

so far, the affected pnp device hid is PNP0501, maybe we could add an exception according to this hid.

Let us wait for if there is other device affected by this patch.
Comment 47 Manuel Krause 2021-07-26 11:30:36 UTC
Thank you for your added info and explanation, now it's eeasier for me to understand.
Comment 48 PGNd 2021-07-26 14:18:08 UTC
iiuc, it the mobo's allocating i2c to a softserial/uart

although *I* don't see this commit-related issue, so far, on any *other* board I've got around here, I'm not clear on why exactly it'd be specific to a particular HID.

in case helpful here:

hwinfo

	/devices/pci0000:00/0000:00:1f.3
	/devices/pci0000:00/0000:00:1f.3/i2c-8
	/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0050
	/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0050/8-00501
	/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0051
	/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0051/8-00512
	...
	  P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0b/PNP0501:00
	  L: 0
	  E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0b/PNP0501:00
	  E: SUBSYSTEM=acpi
	  E: MODALIAS=acpi:PNP0501:
	  E: USEC_INITIALIZED=27986618
	  E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
	  
	  P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0b/PNP0501:01
	  L: 0
	  E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0b/PNP0501:01
	  E: SUBSYSTEM=acpi
	  E: MODALIAS=
	...
	  P: /devices/pci0000:00/0000:00:1f.3/i2c-8/8-0050/8-00501
	  L: 0
	  E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0050/8-00501
	  E: SUBSYSTEM=nvmem


cat  /sys/devices/pci0000:00/0000:00:1f.3/i2c-8/8-0050/8-00501/type
	EEPROM
Comment 49 PGNd 2021-07-28 00:39:56 UTC
(In reply to Hui Wang from comment #46)
> The PGNd's issue is same as the one of comment32~37, the root cause is in
> the comment36.
> 
> so far, the affected pnp device hid is PNP0501, maybe we could add an
> exception according to this hid.
> 
> Let us wait for if there is other device affected by this patch.

This regressions's now been reported for another user, on another device:

	https://lore.kernel.org/stable/db5517bf-35fb-a18c-47cc-d083b0d32304@candelatech.com/

for 

	commit bf155b2eaab40e7d9862ce89ffe2b8a80f86703b

in linus' tree, as opposed to my bisect report in stable tree.

I don't have details beyond that report, but have asked that they share here.
Comment 50 Adrien 2021-07-28 09:12:46 UTC
On my acer swift 3 (SF314-51), I can't boot on my device since 4.19.198 (no issue with 4.19.197) without adding "acpi=off" in the parameters. Same thing happens on 5.12.19 (didn't happened in 5.12.16), 5.13.4 and .5 and 5.10.52.

No log or error whithout the parameter but just a blank screen. Nothing shows up when adding "debug" or "initcall_debug".
Comment 51 PGNd 2021-07-28 13:13:57 UTC
> On my acer swift 3 (SF314-51)

yet another i2c device (Synaptics trackpad?)

can you bisect?

or at least pastebin a peek into logs booted to latest running kernel:

	dmesg | egrep -i "ACPI|IRQ|override"

?
Comment 52 Adrien 2021-07-28 13:55:19 UTC
Created attachment 298079 [details]
Acer Swift 3 dmesg output 4.19.197

(In reply to PGNd from comment #51)
> > On my acer swift 3 (SF314-51)
> 
> yet another i2c device (Synaptics trackpad?)

ElanTech trackpad it seems ("ETPS/2 Elantech Touchpad").
Note : I've set touchaped setting to "Basic" in the BIOS, because "Advanced" mode doesn't work. 

> 
> can you bisect?
> 

Not now, but will try later this week.

> or at least pastebin a peek into logs booted to latest running kernel:
> 
>       dmesg | egrep -i "ACPI|IRQ|override"
> ?
Attached :).
Comment 53 Hui Wang 2021-07-28 14:10:59 UTC
@Adrien,

According to the dmesg-4.19.197, the patch will not bring the influence on your machine.

Could you try the 5.14-rc kernel, like https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14-rc3/
Comment 54 PGNd 2021-07-28 14:24:48 UTC
to my count above, there are 3 reported instances of this commit causing boot failures on three different devices, not including @Adrien's issue

i've currently got 6 servers affected by this^ -- and expect more as upgrades propagate, before I can get to them to freeze out upgrades, or build DIY kernels that revert this patch.

what more data/evidence is required to get a revert of this commit done, and into stable tree kernels?
Comment 55 Adrien 2021-07-28 14:32:54 UTC
(In reply to Hui Wang from comment #53)
> @Adrien,
> 
> According to the dmesg-4.19.197, the patch will not bring the influence on
> your machine.
> 
> Could you try the 5.14-rc kernel, like
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14-rc3/

Okay, sorry. I came from here 
https://lore.kernel.org/stable/YQD5nXW8y6r1IyvJ@kroah.com/T/#t

5.14.rc3 also gives me the same result... 

I will try to bisect between 4.19.197 and .198 when I've got time.
Comment 56 Hui Wang 2021-07-28 14:35:41 UTC
(In reply to PGNd from comment #54)
> to my count above, there are 3 reported instances of this commit causing
> boot failures on three different devices, not including @Adrien's issue
> 
> i've currently got 6 servers affected by this^ -- and expect more as
> upgrades propagate, before I can get to them to freeze out upgrades, or
> build DIY kernels that revert this patch.
> 
> what more data/evidence is required to get a revert of this commit done, and
> into stable tree kernels?

OK, will send a revert patch.
Comment 57 Hui Wang 2021-07-28 15:02:49 UTC
@PGNd and @Adrien,

The patch is not merged to 4.19.y stable kernel at all.
Comment 58 PGNd 2021-07-28 15:09:10 UTC
Sounds like _maybe_ @Adrien's issue isn't related.

The others clearly are.

A verifying (or not) bisect from @Adrien, might still be useful.

If only to eventually fixing original KYBD issue correctly.
Comment 59 Ben Greear 2021-07-28 15:15:13 UTC
I saw problem with this patch as well, symptom was very slow boot, and probably other performance issues if I took time to wait for it to boot.  I hit this
after upgrading from 5.13.0 to 5.13.5 stable kernel.  The bad commit when into 5.13.1 stable.

commit bf155b2eaab40e7d9862ce89ffe2b8a80f86703b (HEAD -> master, refs/patches/master/acpi-resources-add-checks-for)
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Jun 9 10:14:42 2021 +0800

     ACPI: resources: Add checks for ACPI IRQ override

     [ Upstream commit 0ec4e55e9f571f08970ed115ec0addc691eda613 ]

     The laptop keyboard doesn't work on many MEDION notebooks, but the
     keyboard works well under Windows and Unix.
Comment 60 Hui Wang 2021-07-28 15:20:47 UTC
@Ben Greear,

Could you please upload the dmesg of 5.13.0 (booting without any issues), let us see if it is the uart or not.

And BTW, I just sent the revert patch out a moment ago.
Comment 61 PGNd 2021-07-28 15:47:56 UTC
>  I just sent the revert patch out a moment ago.

thx.

Does the revert against upstream

  0ec4e55e9f571f08970ed115ec0addc691eda613

automatically flow to stable branch(es)?

or do backports, e.g., to stable 5.13.x/5.12.x/etc need separate patch requests?
Comment 62 Ben Greear 2021-07-28 15:49:06 UTC
Created attachment 298087 [details]
dmesg from 5.13.5+ with patch reverted.
Comment 63 Manuel Krause 2021-07-28 18:19:31 UTC
Thank you for your info also provided on here. I've also read the related LKML messages.

I'm not confident with a complete withdrawal of this patch. I personally don't have problems to apply/ revert the patch in question as I CAN build my custom kernel. Many others don't, opposed to the people having attached recently.

Wouldn't it be better to add exceptions, either for the MEDION systems or the other affected systems? It looks dumb, but how would we overcome dumb BIOSs in future, without regard, how old the are?

Maybe, we can do it better than simple reverting? I'm ready to test your proposals, @Hui Wang.

BR, Manuel
Comment 64 Manuel Krause 2021-07-28 19:42:56 UTC
@Hui Wang:
Maybe, you remember:
From your first patch proposals there had been two well working setups on here.

+		if (gsi == 1)  {
+			trig = ACPI_EDGE_SENSITIVE;
+			pol = ACPI_ACTIVE_LOW;
...

and 
+		if (gsi == 1)  {
+			trig = ACPI_LEVEL_SENSITIVE;
+			pol = ACPI_ACTIVE_LOW;
...

And based on your ACPI data analysis, you've taken one of them.

Maybe the other one can make it better for the other systems, meaning some kind of compromise?

Just waant to add my odd thoughts,

Manuel
Comment 65 Manuel Krause 2021-07-28 20:17:01 UTC
@Ben Greear:
I don't see any dmesg log from you of a boot with this patch. Can you please provide it?
Comment 66 Ben Greear 2021-07-28 20:20:22 UTC
you want dmesg of boot with the buggy patch applied?  I'm not sure it will even boot at all, at least in any sane amount of time.
Comment 67 Manuel Krause 2021-07-28 20:43:42 UTC
You will only see a result, if you try...

I'm  definitely not the folk being impolite or pushing you to things you don't like to do. We aren't here for such ugly things.

I really thank you very much for your work done for this issue.

Best regards,
Manuel
Comment 68 Manuel Krause 2021-07-28 20:46:25 UTC
(In reply to Ben Greear from comment #66)
> you want dmesg of boot with the buggy patch applied?  I'm not sure it will
> even boot at all, at least in any sane amount of time.

Can you try?!
Comment 69 Manuel Krause 2021-07-28 20:58:41 UTC
In reply to Ben Greear from comment #66)
> you want dmesg of boot with the buggy patch applied?  I'm not sure it will
> even boot at all, at least in any sane amount of time.

If you can try custom kernels on your machine, would you be able to revert the actual "wrong" patch and add the other one and test it? 

https://bugzilla.kernel.org/attachment.cgi?id=297159

TIA,
Manuel
Comment 70 Ben Greear 2021-07-28 21:48:55 UTC
Created attachment 298095 [details]
dmesg with modified patch

The modified patch boots on my system fine, dmesg is attached.
Comment 71 Hui Wang 2021-07-29 02:08:42 UTC
@Ben Greear and @PGNd,

From the log provided by Ben, the culprit is also the UART (serial port).

[    2.191723] ACPI: IRQ 4 override to edge, high
[    2.192072] pnp 00:02: [dma 0 disabled]
[    2.192275] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
[    2.195670] ACPI: IRQ 3 override to edge, high
[    2.196017] pnp 00:03: [dma 0 disabled]
[    2.196218] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active)
[    2.199441] ACPI: IRQ 6 override to edge, high
[    2.199792] pnp 00:04: [dma 0 disabled]
[    2.199986] pnp 00:04: Plug and Play ACPI device, IDs PNP0501 (active)
[    2.203220] ACPI: IRQ 10 override to edge, high
[    2.203578] pnp 00:05: [dma 0 disabled]
[    2.203773] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)

Maybe we could add an exception with PNP0501 or type == UART...
Comment 72 PGNd 2021-07-29 02:27:53 UTC
I'm certainly no expert here, but the issue seems to me to be related to whether i2c is controlling multiple virtual nodes, vs real bus devices

Rather than attempting to make exceptions for myriad servers that have been working for _ages_, perhaps focussing on understanding the difference between those might be useful.

&/or ID'ing the specific characteristics that make these MEDION notebooks uniquely problematic ... not the other way around.
Comment 73 Manuel Krause 2021-07-29 14:45:48 UTC
@Ben Greear:
Many thanks for trying that other patch and sharing a dmesg log!

@Hui Wang:
Would it be a solution to take the other working signal state? Or would you consider it useless fiddling to work around this MEDION kbd problem? 

I have absolutely no insight what's about the i2c <-> UART relation within this issue.

But @PGNd definitely has a good point that adding exceptions for previously working systems doesn't make sense. Maybe it's a buggy BIOS implemented by MEDION on here, but the fact that the kbd works under Windows, UNIX and under grub2 leaves the question "why?" and hope for a more robust solution...

It would be really nice, if we found a way to not leave the coming kernels without working keyboards for these notebooks.

TIA,
Manuel