Bug 278668

Summary: atkbdc: No keyboard on HP Elitebook 845 G10
Product: Base System Reporter: Anton Klimanov <klimanov625>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Only Me CC: douglas.j.burn, gnikl, klimanov625, michael.osipov, wulf, ziaee
Priority: ---    
Version: 15.0-CURRENT   
Hardware: amd64   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707
Attachments:
Description Flags
FreeBSD 15-CURRENT dmesg none

Description Anton Klimanov 2024-04-30 16:29:29 UTC 
Created attachment 250308 [details]
FreeBSD 15-CURRENT dmesg

Hi All,

I'm trying to get FreeBSD running on my personal laptop, but keyboard does not seem to be working (but is recognized). The same behavior is exhibited on 14-RELEASE (memstick) and 15-CURRENT (memstick snapshot from 2024-04-25).

I am not aware of any quirks related to my specific model, neither in Linux, nor in FreeBSD, nor am I aware of how to try them out and which.

The keyboard in question is attached internally via an i8042-compatible controller (likely emulated in acpi?), so PS/2. Nothing else, that I'm aware of is connected in such manner, and only keyboard is affected.

Relevant dmesg lines are:

atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
ioapic0: Changing polarity for pin 1 to high
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0067
atkbd: keyboard ID 0x41ab (2)
kbdc: RESET_KBD return code:00fa
kbdc: RESET_KBD status:00aa
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 14 vector 50
atkbd0: [GIANT-LOCKED]
psm0: unable to allocate IRQ

But atkbd0 grabs IRQ1(?) (vmstat -i):

interrupt                          total       rate
irq1: atkbd0                           2          0
irq9: acpi0                          523          5
irq10: ig4iic0                        42          0
cpu0:timer                          2366         21
cpu1:timer                           998          9
cpu2:timer                          1606         15
cpu3:timer                          1044          9
cpu4:timer                          2250         20
cpu5:timer                          1525         14
cpu6:timer                          1232         11
cpu7:timer                          1102         10
cpu8:timer                          1026          9
cpu9:timer                          1494         14
cpu10:timer                         1056         10
cpu11:timer                          868          8
cpu12:timer                         1483         13
cpu13:timer                         1265         11
cpu14:timer                          932          8
cpu15:timer                         1595         14
irq59: nvme0:admin                    24          0
irq65: nvme0:io5                      74          1
irq66: nvme0:io6                      75          1
irq78: hdac0                           5          0
irq79: xhci0                       14504        132
irq80: xhci1                          46          0
irq81: hdac1                           9          0
irq83: xhci3                        2880         26
Total                              40026        364

Also, full dmesg (also attached as file): https://hastebin.com/share/avukayobob.yaml
pciconf -lv: https://hastebin.com/share/izehegiyen.java
dmesg on linux: https://hastebin.com/share/aliroqiwil.yaml
and, hw-probe (from linux): https://linux-hardware.org/?probe=8fa3424cce

I am willing to probe more and will try patches, but am out of ideas

And I'm not entirely sure on policy with external file hosts, so, if desirable, will upload here, just don't want to unnecessarily bump my own report
Comment 1 Anton Klimanov 2024-04-30 23:02:30 UTC 
Just tried 13.4-RELEASE and keyboard kind of works there, but each keystroke is buffered and delayed. They arrive at regular intervals of 1 second each. Still far from usable, but weird nonetheless. I don't see any significant changes in atkbdc between 13.4-RELEASE and 14.0-RELEASE that would produce such behavior...
Comment 2 Michael Osipov 2024-05-01 12:57:18 UTC 
(In reply to Anton Klimanov from comment #1)

Where did you obtain 13.4-RELEASE?
Comment 3 Anton Klimanov 2024-05-01 13:25:39 UTC 
(In reply to Michael Osipov from comment #2)
Oh, sorry, my bad, 13.3-RELEASE is what I meant (latest of 13 major release). Must have mixed something up in my head.
Comment 4 Anton Klimanov 2024-05-01 14:29:22 UTC 
Okay, new development. Apparently no interrupts arrive per default, but if caps lock is toggled on, exactly one arrives. Should there be any buffered keys, they will arrive with consecutive caps lock toggles. Seems like poking the keyboard makes it do stuff. I really feel like it's awaiting some sort of acknowledgement from the interrupt handler, which happens in Linux and NetBSD, but not FreeBSD
Comment 5 Anton Klimanov 2024-05-01 20:21:59 UTC 
Did some poking in kernel and yes, no interrupts on IRQ1 are received. Curiously, there are two interrupts somewhere after driver initialization before radio silence. Both contain "0x1000000" (NOKEY?). Concerning my previous observation about stuff happening on caps lock off to on, controller seems to send 2 bytes per key, which also seems normal. There definitely is something fishy about keyboard initialization in atkbd, but I just can't quite figure out what
Comment 6 Douglas Burn 2025-01-12 16:54:03 UTC 
I have the same problem as you Anton.
Comment 7 Anton Klimanov 2025-01-12 22:34:58 UTC 
(In reply to Douglas Burn from comment #6)
I checked a few days ago on the latest system firmware (should it still be called BIOS?) with 14.2-RELEASE and it seems to be no longer there (V82 ver. 01.07.00). Might have been a firmware bug that's now fixed. Please check it. If it's fine, then I'll close this issue
Comment 8 Douglas Burn 2025-01-14 11:24:43 UTC 
I’m trying to update my firmware. When I do I’ll let you know if it works.
Comment 9 Gunther Nikl 2025-01-14 15:59:50 UTC 
(In reply to Anton Klimanov from comment #7)
> I checked a few days ago on the latest system firmware (should it still be
> called BIOS?) with 14.2-RELEASE and it seems to be no longer there
I guess this PR is a duplicate of bug #270707 which was fixed on 2024-07-15 with merges to stable/14 and stable/13. This PR precedes the commit(s) fixing the issue.
Comment 10 Douglas Burn 2025-01-18 07:14:08 UTC 
I still haven’t updated my firmware but I don’t mind if you close this thread because it’ll be a few months before I get back to it.