Keyboard wont work during initramfs execution

[erikr]

Over time I have experienced problem that my keyboard does not work during early boot, the time where I am supposed to make key-map selection on system-rescue-cd, but - more important - at the time I am expected to enter encryption key to unlock my encrypted partitions. If I end up in rescue mode I can't do anything, not even ctrl-alt-delete to reboot.

I have had the problem on my current and previous hardware if I am using debian-sources (4.8 and 4.14). I have this problem with all kernels I have tested with my present hardware (ASUS Prime Z370). 

Naturally it failes with my ordinary logitech k750 keyboard but it also fails with a ordinary plain USB cable connected USB-keyboard.

I have played around with different settings in kernel (gentoo-sources) to build in or not support for USB, logitech modules, the fundamental USB HIDBP, etc and cannot observe any difference during boot (but I managed to disable mouse in KDE).

I can see that the logitech modules are loaded when booting debian-kernel but it still wont work.

This is the latest dmesg where HID is loaded

[    1.239301] hidraw: raw HID events driver (C) Jiri Kosina
[    1.239542] usbcore: registered new interface driver usbhid
[    1.239780] usbhid: USB HID core driver

.
.
.

[   20.619928] logitech-djreceiver 0003:046D:C52B.0003: hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-5.1/input2
[   20.732809] input: Logitech K750 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.2/0003:046D:C52B.0003/0003:046D:4002.0005/input/input9
[   20.732897] logitech-hidpp-device 0003:046D:4002.0005: input,hidraw2: USB HID v1.11 Keyboard [Logitech K750] on usb-0000:00:14.0-5.1:1
[   21.154637] usbcore: registered new interface driver snd-usb-audio
[   25.298802] logitech-hidpp-device 0003:046D:4002.0005: HID++ 2.0 device connected.

I am quite sure that luks is opened long before the 20 seconds and the HID is hidraw.

The very same rows with the very same keyboard on a working setup where I can enter the password:

One difference I found is that in a working boot (where keyboard is working) the same rows as above seems to happen earlier:

Dec 30 09:20:37 nuffsan kernel: [    2.440038] usb 8-2.1: new full-speed USB device number 4 using xhci_hcd
Dec 30 09:20:37 nuffsan kernel: [    2.624861] usb 8-2.1: New USB device found, idVendor=046d, idProduct=c52b
Dec 30 09:20:37 nuffsan kernel: [    2.624866] usb 8-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Dec 30 09:20:37 nuffsan kernel: [    2.624869] usb 8-2.1: Product: USB Receiver
Dec 30 09:20:37 nuffsan kernel: [    2.624872] usb 8-2.1: Manufacturer: Logitech
Dec 30 09:20:37 nuffsan kernel: [    2.628778] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.0/0003:046D:C52B.0001/input/input5
Dec 30 09:20:37 nuffsan kernel: [    2.680543] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input0
Dec 30 09:20:37 nuffsan kernel: [    2.683897] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.1/0003:046D:C52B.0002/input/input6
Dec 30 09:20:37 nuffsan kernel: [    2.735411] hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input1
Dec 30 09:20:37 nuffsan kernel: [    2.738136] hid-generic 0003:046D:C52B.0003: hiddev1,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input2
.
.
.
Dec 30 09:20:38 nuffsan kernel: [   12.393989] cryptsetup (4105) used greatest stack depth: 13648 bytes left
Dec 30 09:20:38 nuffsan kernel: [   20.241508] cryptsetup (4179) used greatest stack depth: 13520 bytes left

Password was entered before 12 and 20 seconds.

I use the very same and slightly modified linuxrc and initrd.scripts. Modification is an own luks open function that is similar but independent from the cryptroot-stuff. Instead I open encrypted partitions specified at kernel line in specified order right before BTRFS scan is performed. Eventually I might send a patch.

I have tried the solution mentioned in https://forums.gentoo.org/viewtopic-t-1063372.html but it didn't work.