Package: src:linux
Version: 6.12.111-1
Severity: important

Dear Maintainers,

I am a user of Linux for a few years but definitely not an expert so I used a 
LLM to help me fill this report. I believe this is much more detailed than what 
I would have been able to produce. I hope that this is true from your 
perspective as well and that it is helping investigate the bug. Note that the 
keyboard works in BIOS and in GRUB (to select previous version to boot). It is 
not working using most recent kernel update during normal boot sequence (stuck 
at LUKS step, workaround possible with USB but main keyboard does not come back 
after full boot). It is fine using 6.12.107 after manual selection in GRUB.

With kindest and most respectful regards,
V

LLM output : 
After upgrading from linux-image-6.12.107+deb13-amd64 (6.12.107-1) to
linux-image-6.12.111+deb13-amd64 (6.12.111-1), the built-in keyboard of my
laptop no longer responds at the LUKS passphrase prompt in the initramfs,
so the encrypted root cannot be unlocked and the system cannot boot.

An external USB keyboard works at that prompt on 6.12.111, and with it the
system boots normally. The built-in keyboard stays dead in the running
system, although it is enumerated and bound to hid-asus.

Selecting 6.12.107+deb13-amd64 in the GRUB menu on the same machine, with
no other change, boots normally and the keyboard works.

Hardware
--------
Laptop: ASUS ROG Zephyrus G14 GA401IV (board GA401IV)
BIOS: GA401IV.222 (09/28/2023)
CPU: AMD Ryzen 7 4800HS
Keyboard: internal, USB 0b05:1866 "ASUSTek Computer, Inc. N-KEY Device"
on xHCI controller 0000:04:00.3 (AMD Renoir/Cezanne, 1022:1639)
three HID interfaces, all bound to hid-asus on both kernels

What happens
------------
1. GRUB menu: keyboard works (firmware driver).
2. Boot 6.12.111+deb13-amd64.
3. The "Please unlock disk nvme0n1p3_crypt" prompt appears.
4. No key press from the built-in keyboard is registered. Without an
external keyboard the machine has to be powered off.

With 6.12.107+deb13-amd64, step 4 accepts the passphrase as expected.
The keyboard also works in the firmware setup, so it is not a hardware
fault.

Booting 6.12.111 with an external USB keyboard
----------------------------------------------
With an external USB keyboard (1997:2433) plugged in, the passphrase can
be typed at step 4 and 6.12.111 boots to the desktop. The external
keyboard keeps working; the built-in one still does not produce any key
press after boot.

State of the running 6.12.111 system (from sysfs, 3 minutes after boot):

* Both keyboards are on the same xHCI controller and the same root hub:
usb 3-1 1997:2433 external keyboard (works)
usb 3-3 0b05:1866 N-KEY Device (dead)
usb 3-4 0b05:193b ITE Device(8910)
All on /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3.
* The built-in keyboard is enumerated normally. Its three interfaces
(3-3:1.0, 1.1, 1.2, all class 03/01/01) are bound to usbhid, and the
three HID devices 0003:0B05:1866.0004-0006 are bound to hid-asus
(report descriptors of 83, 65 and 167 bytes).
* Three input devices named "Asus Keyboard" exist (input19-21, handlers
"sysrq kbd leds" / "sysrq kbd leds" / "kbd rfkill"), so the driver
probe completed and registered them. They just never deliver events.
* USB runtime PM status of 3-3 is "active", power/control is "on".
* urbnum of 3-3 is 38, against 537 for the external keyboard over the
same uptime, i.e. almost no traffic after the initial setup.
* /sys/class/leds has no asus::kbd_backlight entry (only
asus-wireless::airplane), consistent with the backlight init failure
in the kernel log below. Under 6.12.107 asus::kbd_backlight is
present.
* Apart from that LED, sysfs looks the same under 6.12.107, where the
keyboard works: same three interfaces bound to usbhid and hid-asus,
same descriptor sizes, same three "Asus Keyboard" input devices with
the same handlers.
* Loaded: hid_asus, asus_wmi, asus_nb_wmi, usbhid, hid_generic, hid.

So the device is not missing from the bus and the xHCI controller itself
is functional (the external keyboard goes through it). The failure is
between a successful hid-asus probe and the first input report.

Kernel log on 6.12.111 (dmesg-6.12.111.txt attached)
----------------------------------------------------
hid-generic binds the keyboard first (3.1 s - 4.3 s), then hid-asus is
loaded and takes over. Its initialisation fails on the third interface:

[ 5.357256] input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.0/0003:0B05:1866.0004/input/input19
[ 5.508717] asus 0003:0B05:1866.0004: input,hidraw3: USB HID v1.10 Keyboard 
[ASUSTeK Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input0
[ 5.677483] input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.1/0003:0B05:1866.0005/input/input20
[ 5.844839] asus 0003:0B05:1866.0005: input,hidraw4: USB HID v1.10 Keyboard 
[ASUSTeK Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input1
[ 5.869372] asus 0003:0B05:1866.0006: Fixing up Asus N-Key report descriptor
[ 5.869860] asus 0003:0B05:1866.0006: using HID for asus::kbd_backlight
[ 5.877104] asus 0003:0B05:1866.0006: Asus failed to request functions: -75
[ 5.877131] asus 0003:0B05:1866.0006: Failed to initialize backlight.
[ 5.877222] input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.2/0003:0B05:1866.0006/input/input21
[ 5.932697] asus 0003:0B05:1866.0006: input,hiddev0,hidraw5: USB HID v1.10 
Device [ASUSTeK Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input2

"Asus failed to request functions: -75" (-EOVERFLOW) followed by "Failed
to initialize backlight." explains the missing asus::kbd_backlight LED.
There is no other error or warning for usb 3-3, xhci_hcd 0000:04:00.3 or
any HID device in the log. This happens at 5.9 s, before the LUKS prompt
is answered (the root filesystem is mounted at 29.7 s, after the
passphrase was typed on the external keyboard), which matches the keyboard
being dead at the prompt.

Same sequence on 6.12.107 (dmesg-6.12.107.txt attached)
-------------------------------------------------------
>From the 6.12.107 boot of the same day (taken from journalctl -k, so
wall-clock timestamps only, in UTC; prefixes and the interleaved
amdgpu/drm lines removed here):

input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.0/0003:0B05:1866.0002/input/input15
asus 0003:0B05:1866.0002: input,hidraw1: USB HID v1.10 Keyboard [ASUSTeK 
Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input0
input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.1/0003:0B05:1866.0003/input/input16
asus 0003:0B05:1866.0003: input,hidraw2: USB HID v1.10 Keyboard [ASUSTeK 
Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input1
asus 0003:0B05:1866.0004: Fixing up Asus N-Key report descriptor
asus 0003:0B05:1866.0004: using HID for asus::kbd_backlight
input: ASUSTeK Computer Inc. N-KEY Device as 
/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb3/3-3/3-3:1.2/0003:0B05:1866.0004/input/input17
asus 0003:0B05:1866.0004: input,hiddev0,hidraw3: USB HID v1.10 Device [ASUSTeK 
Computer Inc. N-KEY Device] on usb-0000:04:00.3-3/input2

The probe is identical up to "using HID for asus::kbd_backlight". On
6.12.107 it then continues without error; on 6.12.111 the next two lines
are "Asus failed to request functions: -75" and "Failed to initialize
backlight.". Neither message appears anywhere in the 6.12.107 log. Later
in the 6.12.107 log there is also

asus 0003:0B05:1866.0004: Unmapped Asus vendor usagepage code 0xec

i.e. the keyboard is delivering reports there; no such line exists in the
6.12.111 log.

The HID device numbers differ between the two excerpts (.0002-.0004
against .0004-.0006) only because the external keyboard was present at
boot on 6.12.111 and took the first numbers.

Other errors appear identically in both logs (amdgpu LOAD_TA, asus_wmi
fan_curve_get_factory_default -19, iwlwifi iwl-debug-yoyo.bin), so they
are unrelated. Besides the hid-asus messages, the only differences in
error/warning lines are: the TSC is marked unstable on both kernels but
for different reasons ("check_tsc_sync_source failed" on 6.12.111,
"clocksource watchdog" on 6.12.107, both end up on hpet), and "ee1004
3-0050: probe with driver ee1004 failed with error -5" appears only on
6.12.107. The external keyboard was not
connected when 6.12.107 booted (it was plugged in later in that session);
the original failure on 6.12.111 happened without it as well.

What I checked
--------------
* The initramfs images of both kernels contain the same keyboard-related
modules (compared with lsinitramfs): hid, hid-generic, hid-asus, usbhid,
asus-wmi, wmi, platform_profile, sparse-keymap, battery, video, rfkill,
xhci-hcd, xhci-pci, xhci-pci-renesas. The only difference in the whole
listing is one extra module in 6.12.111, i2c-hid-acpi-prp0001. So this
does not look like a missing module.
* initramfs-tools 0.148.4 with MODULES=most; cryptsetup-initramfs 2:2.7.5-2.
Neither package changed between the two kernel installs.
* The proprietary nvidia modules (nvidia-kernel-dkms 550.163.01-2) are
installed on this system but are NOT included in the initramfs. The
attached 6.12.111 log was captured after they had loaded (taint P, O,
E, at 31.7 s), but the keyboard is already dead at the LUKS prompt,
long before that, on an untainted kernel.

Possible cause (not verified)
-----------------------------
The changelog of 6.12.111-1 lists, under the 6.12.108 stable update, two
changes to the driver for this exact device:

- HID: asus: simplify RGB init sequence
- HID: asus: fix missing hid_is_usb() check

The first one changes the initialisation sequence for N-KEY keyboards. I
have not bisected, so this is a suspicion based on the changelog, but the
observations above fit it: the keyboard enumerates, hid-asus binds and
creates the input devices, its init request fails with -EOVERFLOW ("Asus
failed to request functions: -75"), and then no reports arrive. That error
is absent from the 6.12.107 log, where the same probe completes and the
keyboard works. The same changelog range also contains several xhci
changes; these look less likely, since another keyboard on the same
controller and root hub works.

About the attached logs
-----------------------
Both logs are complete from the first kernel line, with these edits for
privacy: MAC addresses, filesystem UUIDs and the hostname (also where it
appears in the LVM volume group name) are replaced by placeholders, and
firewall, Wi-Fi association and audit/AppArmor lines are removed. The
6.12.107 timestamps are converted to UTC. Nothing
concerning USB, HID, xhci or the asus drivers was changed.

I can test patches or boot with extra kernel parameters and report back.

System information
------------------
Debian Release: 13.7
Architecture: amd64
Failing kernel: Linux 6.12.111+deb13-amd64 (Debian 6.12.111-1)
Working kernel: Linux 6.12.107+deb13-amd64 (Debian 6.12.107-1)
Kernel command line: root=/dev/mapper/laptop--vg-root ro quiet
Disk layout: NVMe, LUKS on nvme0n1p3 -> LVM (root + swap), /boot unencrypted

Reply via email to