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
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...
(In reply to Anton Klimanov from comment #1) Where did you obtain 13.4-RELEASE?
(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.
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
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