x230: keyboard not working after reboot

[alex-nitrokey]

I experience regularly an issue that is causing the keyboard or the x230 to not function after reboot inside of heads. Killing heads via pressing the power button until power off and starting again fixes the problem.

This problem is happening often after reboot (again, reboots inside heads), but not always. I could not detect a pattern yet.

Anybody had this issue or can deduce a cause?

[paulmenzel]

Maybe related to #698?

[alex-nitrokey]

doesn't sound like it imho

[stmc-droid]

I have the same issue sometimes when rebooting inside heads

[paulmenzel]

Are you able to save the logs somewhere even without keyboard?

Please start the Linux (Heads) kernel with i8042.debug, and contact the Linux kernel developers with the failing logs.

[tlaurion]

Intuition here is a race condition with USB Security dongle being connected and considered a keyboard. Possible? Would need to test and isolate if behavior is there without USB Security dongle being connected at boot.

[alex-nitrokey]

Good idea! I try to test this...

[alex-nitrokey]

Can not confirm. I tried around just a bit, but while doing similar stuff like generating new HOTP secrets and reboot via Ctrl+Alt+Del I once got stuck with not working keyboard and once I didn't (in both cases I led the Nitrokey inserted).

[tlaurion]

@alex-nitrokey best point would be to see if the same behavior happens without the Nitrokey Inserted and why the Nitrokey is considered a USB keyboard in Heads use case. (new behavior)

[alex-nitrokey]

I don't think, it has anything to do with the Nitrokey, this was just a working hypothesis above.

I just tested rebooting without inserting the Nitrokey or any other USB device. The keyboard still freezes.

[alex-nitrokey]

(go to recovery shell without doing anything else and type reboot)

[tlaurion]

Just putting some notes, I will do some Heads pull request merging in the next days after testing them under a branch under CIs.

On current issue:
reboot under heads is a bash script:

user@x230-master:~/heads$ cat initrd/bin/reboot 
#!/bin/sh

# Sync all mounted filesystems
echo s > /proc/sysrq-trigger

# Remount all mounted filesystems in read-only mode
echo u > /proc/sysrq-trigger

# Immediately reboot the system, without unmounting or syncing filesystems
echo b > /proc/sysrq-trigger

Please detail your use case:
1- Call reboot inside of heads.
2- Have main Heads screen but not able to type anything even if no USB drive being present on rebooted system?
Is that correct?

@alex-nitrokey :

Please start the Linux (Heads) kernel with i8042.debug, and contact the Linux kernel developers with the failing logs.
That means putting that under coreboot config. Result?

[alex-nitrokey]

Please detail your use case:
1- Call reboot inside of heads.
2- Have main Heads screen but not able to type anything even if no USB drive being present on rebooted system?
Is that correct?

This is one test case, yes. But it happens in different reboot situations as well, like doing the oem-factory-reset (in which I of course needed to insert USB devices). The above use case is just proving that seemingly it has nothing to do with the USB drive as it is happening even without inserting any.

Will try next week with the kernel debug. Where do I find the logs after applying the kernel parameter to my build and booting it?

[tlaurion]

Confirm the behavior after flashing with USB storage in.

[tlaurion]

confirmed after flashing again with usb storage in after oem factory reset

[tlaurion]

infirmed with HOTP security dongle while calling reboot from command line