You are not logged in.
Slightly long, so TL;DR laptop keyboard can lock up during initialisation if typed on during that time.
I currently own a Toshiba Satellite Pro C50 on which I run arch, dual booted with the Windows installation that it came with.
This machine works perfectly, for the most part, with no binary blobs required for any of the hardware AFAIK.
However, an issue that keeps cropping up while I use the device is that the keyboard will sometimes lockup after I bring the device out of suspend, and sometimes when I first boot the device.
It appears to occur when the keyboard is typed on just before the system finishes the resume and I get back to the prompt (I suspended on the console using systemctl suspend to test this),
or even if the keyboard is typed on when the system is asleep (which doesn't actually wake the machine up on its own).
If I have typed on the keyboard after waking the system (that is, lid / power button), the first few keystrokes come through on the console but then the keyboard goes dead. If I type during sleep then wake the laptop,
no keystrokes appear at all. In either case, by the time the shell prompt returns (i.e. the 'systemctl suspend' command returns, which AFAIK means systemd has signalled completion of resume),
the keyboard is unresponsive. I cannot type at the prompt, Alt-Fx to switch prompts does nothing, the Num lock LED does not toggle in response to the key being pressed.
The issue can also happen during initramfs stage of boot, if I type some characters before the "Triggering uevents" message appears - I know the keyboard locks up at this point because I'm using the encrypt hook
for an encrypted root partition. This leaves me unable to enter my encryption passphrase, and the usual CTRL-ALT-DEL combination that causes the initramfs script to reboot the machine doesn't work.
I know that the keyboard isn't working here either, despite that the typed password isn't echoed to the console, as the underscore cursor on the console usually flickers from it's usual pulsing when a key is pressed,
but again this is not happening.
In both cases, the only way I know of allieviating the issue is to either power down, or put the system back to sleep and wake it again, which requires another keyboard to plug in as the in-built one isn't
working at this point. (I've altered /etc/systemd/logind.conf to set HandleLidSwitch=Ignore, as I sometimes shut the lid but keep the system awake for a long-running task.)
I'm not sure at what level the fault resides, because as a test I intentionally locked up the keyboard and then (using another keyboard) hexdump'd the event node for the keyboard
(which I found and saw to be working before I put the laptop to sleep). After resume, no events are generated from the device at all.
After poking around in sysfs for a bit, I found out that the keyboard was connected to serio0 of the system's i8042 port. The synaptics touchpad was also connected to serio0, so I decided to test that too.
If I cause a keyboard lockup, the touchpad's event node similarly ceases generating events, and THEN the touchpad's node (but not the keyboard's) disappears altogether, causing hexdump to print a
"no such device" and terminate. The touchpad's disappearance I confirmed with a ls /dev/input, and the node had indeed disappeared.
I have tested to see if events from the touchpad can cause similar lockups, but thus far has not caused either itself or the keyboard to lockup if used during sleep or during resume.
At this point, I ask if anyone knows of a workaround that could fix this issue. I'm not sure that re-inserting the module would work due to the logical keyboard device still using it,
so perhaps a way of "restarting" the i8042 module for those devices (or as a whole) would work? (I'm not sure of the procedure for this.)
Secondly, are there any tools I can use to try and debug this myself? dmesg logs haven't been particularly revealing to me, however I will post an excerpt of the relevant periods of time when the lockup occurs
if requested, as well as any other information on request (lspci etc.)
Any help's appreciated.
Cheers,
delta
Offline