Thinkpad L15 Gen 2, keyboard occasionally lock up, recoverable after suspending & resuming.

[logoerthiner1]

How to file a helpful issue

Qubes OS release

R4.1, latest as of 2022.06.08

Brief summary

Since April, keyboard occasionally locks up. When keyboard lock up, all keyboard key has no effect, and the keys that are being pressed down at the tick of lock up will keep pressing without any method to unpress. Only mouse can move.

Suspending by closing lid and then open the lid to resume solves the lock up.

I suspect that this is an issue related to firmware but X side problem cannot be ruled out - actually I find out something interesting in dom0 ~/.xsession-errors.old (this is not inside journalctl -r, which make debugging much more confusing).

Property "/general/LockCommand" does not exist on channel "xfce4-session".
Property "/general/LockCommand" does not exist on channel "xfce4-session".
Property "/general/LockCommand" does not exist on channel "xfce4-session".
xscreensaver: hh:mm:s1: DPMSForceLevel(dpy, DPMSModeOff) did not change monitor power state.
xscreensaver: hh:mm:s1: not launching hack (throttled.)
xscreensaver: hh:mm:s1: LOCK ClientMessage received while already locked.
Property "/general/LockCommand" does not exist on channel "xfce4-session".
xscreensaver: hh:mm:s2: DPMSForceLevel(dpy, DPMSModeOff) did not change monitor power state.
xscreensaver: hh:mm:s2: not launching hack (throttled.)
xscreensaver: hh:mm:s2: ClientMessage ignored while authentication dialog is active

Actually the log file may be a red-herring since hh:mm:s2 is the time I close the lid rather than the keyboard locks up.

This gets annoying as #7340 gets involved -after the april update the frequency of the issue #7340 gets reduced to around once per 50 times, yet each time the lock up happens, a suspension is necessary. When keyboard locks up, many GUI application does not support saving as it is confused to keyboard actions. When this encounter with #7340, I have no chance to save many things.

Actually I wonder whether any user of latest thinkpads encounter the same issues, and whether devs have testing laptop that can reproduce either this issue or issue #7340.

Currently I do not have much free time to try the latest upstream linux-firmware to see whether it works. I will appreciate it if anyone finds out that the upstream linux-firmware solves the problem or have some solid instruction that tells how to correctly TRY an upstream version linux-firmware in DOM0 without get my laptop exploded.

UPDATE: rarer now but it does not seem that this issue completely vanishes.

Steps to reproduce

Use the thinkpad for a while, preferably with the keyboard on the laptop rather than a USB keyboard.

Expected behavior

No lock up happens

Actual behavior

Keyboard locks up occasionally.

[jamke]

@logoerthiner1 any updates on this with current latest kernel?

[logoerthiner1]

@logoerthiner1 any updates on this with current latest kernel?

This still happens from time to time, with all kernels 6.1.42+ and all other packages latest as of now

[ayakael]

I've also been encountering this issue on my Thinkpad T14 Gen 1 with Ryzen 4750U. It usually occurs when there's some kind of heavy load (starting multiple VMs, compilation, Zoom call, etc). It affects both my keyboard and my Trackpoint. I get the following error:

[  496.205845] psmouse serio1: resync failed, issuing reconnect request
[  499.857441] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
[  499.896941] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
[  500.294327] psmouse serio1: synaptics: Advanced gesture mode init failed: -5
[  500.294336] psmouse serio1: synaptics: Unable to initialize device.
[  500.501833] psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5
[  500.718323] psmouse serio1: Failed to enable mouse on isa0060/serio1
[  509.848031] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
[  509.889176] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
[  509.889188] psmouse serio1: synaptics: Your touchpad (PNP: LEN2064 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to [email protected].
[  509.957208] psmouse serio1: synaptics: Touchpad model: 1, fw: 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board id: 3471, fw id: 2909640
[  509.957226] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[  510.014716] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input20
[  510.572345] psmouse serio3: trackpoint: Elan TrackPoint firmware: 0x11, buttons: 3/3
[  511.078904] input: TPPS/2 Elan TrackPoint as /devices/platform/i8042/serio1/serio3/input/input21
[  514.987595] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
[  516.264839] psmouse serio1: resync failed, issuing reconnect request
[  517.087355] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
[  517.123586] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]

While it only mentions the TouchPad, all inputs lock up for a minute or two. Contrary to @logoerthiner1. I do not need to suspend and resume to regain control. I tested with kernel 6.1.42 and also 6.3, with no difference in behavior.

[github-actions]

This issue is being closed because:

• This issue is believed to affect only Qubes OS 4.1 (and possibly earlier).
• Qubes OS 4.1 has reached end-of-life (EOL).

If anyone believes that this issue should be reopened, please leave a comment saying so.
(For example, if a bug still affects Qubes OS 4.2, then the comment "Affects 4.2" will suffice.)