Hi Paul, On 1/26/24 14:32, Hans de Goede wrote: > Hi Paul, > > On 1/26/24 08:03, Paul Menzel wrote: >> Dear Hans, >> >> >> Thank you for your reply, and sorry for the delay on my side. I needed to set up an environment to easily build the Linux kernel. > > No problem thank you for testing this. > >> Am 22.01.24 um 14:43 schrieb Hans de Goede: >> >>> On 1/21/24 15:26, Paul Menzel wrote: >> >> […] >> >>>> Am 20.01.24 um 21:26 schrieb Hans de Goede: >>>> >>>>> On 1/18/24 13:57, Paul Menzel wrote: >>>>>> #regzbot introduced v6.6.11..v6.7 >>>> >>>>>> There seems to be a regression in Linux 6.7 on the Dell XPS 13 9360 (Intel i7-7500U). >>>>>> >>>>>> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022 >>>>>> >>>>>> The PS/2 keyboard goes missing after S3 resume¹. The problem does not happen with Linux 6.6.11. >>>>> >>>>> Thank you for reporting this. >>>>> >>>>> Can you try adding "i8042.dumbkbd=1" to your kernel commandline? >>>>> >>>>> This should at least lead to the device not disappearing from >>>>> >>>>> "sudo libinput list-devices" >>>>> >>>>> The next question is if the keyboard will still actually >>>>> work after suspend/resume with "i8042.dumbkbd=1". If it >>>>> stays in the list, but no longer works then there is >>>>> a problem with the i8042 controller; or interrupt >>>>> delivery to the i8042 controller. >>>>> >>>>> If "i8042.dumbkbd=1" somehow fully fixes things, then I guess >>>>> my atkbd driver fix for other laptop keyboards is somehow >>>>> causing issues for yours. >>>> >>>> Just a quick feedback, that booting with `i8042.dumbkbd=1` seems to fix the issue. >>>> >>>>> If "i8042.dumbkbd=1" fully fixes things, can you try building >>>>> your own 6.7.0 kernel with commit 936e4d49ecbc: >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936e4d49ecbc8c404790504386e1422b599dec39 >>>>> >>>>> reverted? >>>> >>>> I am going to try that as soon as possible. >>> >>> Assuming this was not some one time glitch with 6.7.0, >>> I have prepared a patch hopefully fixing this (1) as well >>> as a follow up fix to address another potential issue which >>> I have noticed. >> >> Unfortunately, it wasn’t just a glitch. >> >>> Can you please give a 6.7.0 (2) kernel with the 2 attached >>> patches added a try ? >>> >>> I know building kernels can be a bit of work / takes time, >>> sorry. If you are short on time I would prefer testing these 2 >>> patches and see if they fix things over trying a plain revert. >> >> Applying both patches on v6.7.1 >> >> $ git log --oneline -3 >> 053fa44c0de1 (HEAD -> v6.7.1) Input: atkbd - Do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID >> 0e0fa0113c7a Input: atkbd - Skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID >> a91fdae50a6d (tag: v6.7.1, stable/linux-6.7.y, origin/linux-6.7.y) Linux 6.7.1 >> >> I am unable to reproduce the problem in eight ACPI S3 suspend/resume cycles. The DMAR errors [3] are also gone: > > Thanks. > > So thinking more about this I think the DMAR errors are actually the real cause of the issue here, specifically if we replace: f0 with 00 (I guess DMAR uses the high bits for its own purposes) in > > `[INTR-REMAP] Request device [f0:1f.0] fault index 0x0` > > then the device ID is 00:1f.0 which is the ISA bridge and [INTR-REMAP] errors are known to disable interrupts. The PS/2 controller (which sits behind the ISA bridge) interrupt getting disabled would explain the suspend/resume keyboard issue better then the atkbd.c changes I have been focusing on. > > So then the question becomes why does the 6.7.1 kernel not show the DMAR errors. I don't see anything between 6.7.0 and 6.7.1 which explains this. But maybe your local build is using a different configuration which explains this. > > Can you try your local 6.7.1 build without my 2 patches? The quickest way to do that would be to run: "git reset --hard HEAD~2" and then re-run the make commandos, this will re-use your previous build so it should be pretty quick. > > If things still work after that then the problem is not with the atkbd code. Never mind I just became aware of a bunch of other reports which don't have the DMAR errors on resume, so I'm submitting the 2 fixes for this upstream now. Regards, Hans
