FreeBSD 15.1-p3 + HP KB-0316 = “NumLock” aka freeze system tool

USerID

USerID

1. Boot from the USB flash drive (version 15.1).
2. Reach the Beastie menu with the system boot options.
3. Press the Space bar to pause the menu and prevent the automatic boot sequence from starting.
4. Press the NumLock key on the keyboard (a 2007–2010 model HP KB-0316 PS/2) to enable the numeric keypad.
Press it again to disable it. If you do this 20–30 times, everything works fine.

1. Boot from the "booting USB flash drive" (version 15.1).
2. Reach the Beastie menu with the system boot options.
3. Enter the installer—the first screen is the "Welcome to FreeBSD!" greeting.
4. Press the NumLock key on the same keyboard to enable the numeric keypad.
Press it again to disable it. If you do this 10–15 times, everything "freezes." The keyboard becomes unresponsive, and the PC can only be turned off using the hardware power button.

If you perform the same actions on an already installed system, the only difference is that you log in as root and enter the password. If you are lucky and the keyboard doesn't hang immediately, you can trigger the "freeze" by repeatedly toggling NumLock.
Sometimes the keyboard freezes right at the login prompt! That’s how it happens!
This doesn't happen consistently; you might work in X for half an hour with no issues.
This doesn't happen on Windows or Linux. Verified through testing.

I thought my A4 wireless mouse might be the culprit. It wasn't. I disconnected the wireless receiver, but the problem persisted.
I connected a standard USB mouse, but nothing changed.

Conclusion: toggling via NumLock works correctly only in the "beastie" menu.
I can't even imagine which module is interacting incorrectly with the keyboard module during startup.
How can I detect a conflict between the keyboard driver and another driver or loaded module?
 
SirDice said:
No module is active because the entire kernel isn't even loaded at this point (that's what loader(8)/loader.efi(8) does)
Click to expand...
Exactly! When we're just looking at the boot menu, everything is clearly clean and working fine—the keyboard responds as expected. But things go wrong even in safe mode. It’s a problem during installation, too—right at the "Welcome to FreeBSD" screen. I noticed this issue with versions 13 and 14. It didn't bother me much back then, though, because I had a mini USB keyboard handy. So, there you have it: this glitch plagues versions 13, 14, and 15.
Oh! It turns out the party is just getting started for me. To "freeze" the keyboard or the system, you have to press the Scroll Lock key in exactly the same way.
I booted with these parameters:
Code: 
ACPI - on
Safe Mode - on
Single Mode - on
Verbose - on
That didn't help.

I disabled the UEFI Fast Boot option—this turns off Num Lock. I tried toggling Num Lock on and off in the UEFI settings, but that didn't help either.
 
I found the same keyboard HP KB-0316 (PS/2) and test it on supermicro server and it's working. I'm unable to reproduce the issue. You can test it on another computer with PS2 port or use a USB keyboard.

kbd1 at kbdmux0
kbd0 at atkbd0
atkbdc0: <Keyboard controller (i8042)> port 0x60, 0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
Click to expand...

Note:
this is from FreeBSD-15.1-RELEASE-amd64-mini-memstick.img
 
VladiBG said:
I found the same keyboard HP KB-0316 (PS/2) and test it on supermicro server and it's working.
Click to expand...
Thanks. I see. Yes, I bought an HP ProLiant DL320 G5 server and this keyboard. It works perfectly in OpenBSD, so that’s not the issue. There are some interesting write-ups out there, but I doubt this keyboard will work properly under FreeBSD 15.1. The processes involved here are very sporadic.
Code: 
I'm trying to install FreeBSD on an old ThinkPad G40. For some reason, the keyboard will not work properly once the system is booted up. I can enter text just fine at the bootloader prompt (thankfully, since this system suffers from this bug), but once the system is actually booted, I only get random letters instead of what I actually typed, forcing me to use an external USB keyboard. This doesn't happen on OpenBSD or on Linux.
It’s a G40. I’m fairly sure the keyboard is PS/2 internally. Again, works perfectly at the bootloader but once the system loads it’s unusable.
The bootloader is (I'd assume) just talking to the keyboard through the BIOS. Once the kernel boots, the OS talks to the keyboard controller directly. So it makes sense that it might work with the former but not the latter.
Yes, it does have a PS/2 port, and an external PS/2 keyboard has the same issue on FreeBSD, but not on Linux (testing through a Debian install USB then dropping to its text shell, since I don't have Linux installed on here anymore, though I have no reason to believe it wouldn't work on an installed system). USB keyboards work just fine both on Linux and FreeBSD. The keyboard is indeed the standard US layout, and my issue is at the FreeBSD login text prompt.
 
T-Aoki said:
Actually I myself never been bitten, but does your motherboard have boot-time numlock option? If so, does flipping it help?
Click to expand...
Thanks, T-Aoki. Yes, there is. I went through all the options and settings, but that didn't help. Unfortunately, as I mentioned earlier, there is another way to "freeze" the keyboard: by pressing Scroll Lock and Caps Lock. But the real mystery likely isn't in this video—it's in the next one.
T-Aoki said:
Not affecting for loader and boot codes, but does changing sysctl kern.evdev.rcpt_mask (default is 12) to 6 (or 3) help after kernel starts?
Click to expand...
$ cat /etc/sysctl.conf
Bash: 
vfs.zfs.vdev.min_auto_ashift=12
# kern.evdev.rcpt_mask=6
kern.evdev.rcpt_mask=3

That didn't help either. But here is the video and my log. It’s actually quite amusing. A solution was found, though it’s not exactly elegant. It might come in handy for someone. The gist is this: when the PS/2 keyboard freezes, you need to plug in a second keyboard—a USB one (in my case, a wireless one). After that, you can see everything in the video...

cat /var/log/messages
Code: 
Sep 21 09:35:10 hkpc kernel: ugen2.3: <Telink Wireless Receiver> at usbus2 (disconnected)
Sep 21 09:35:10 hkpc kernel: usbhid2: at uhub3, port 2, addr 3 (disconnected)
Sep 21 09:35:10 hkpc kernel: hsctrl1: detached
Sep 21 09:35:10 hkpc kernel: hcons1: detached
Sep 21 09:35:10 hkpc kernel: hms1: detached
Sep 21 09:35:10 hkpc kernel: hidbus2: detached
Sep 21 09:35:10 hkpc kernel: usbhid2: detached
Sep 21 09:35:10 hkpc kernel: usbhid3: at uhub3, port 2, addr 3 (disconnected)
Sep 21 09:35:10 hkpc kernel: hkbd1: detached
Sep 21 09:35:10 hkpc kernel: hidbus3: detached
Sep 21 09:35:10 hkpc kernel: usbhid3: detached
Sep 21 09:35:29 hkpc kernel: ugen2.3: <Telink Wireless Receiver> at usbus2
Sep 21 09:35:29 hkpc kernel: usbhid2 on uhub3
Sep 21 09:35:29 hkpc kernel: usbhid2: <Telink Wireless Receiver, class 0/0, rev 1.10/1.00, addr 3> on usbus2
Sep 21 09:35:29 hkpc kernel: hidbus2: <HID bus> on usbhid2
Sep 21 09:35:29 hkpc kernel: hms1: <Telink Wireless Receiver Mouse> on hidbus2
Sep 21 09:35:29 hkpc kernel: hms1: 5 buttons and [XYW] coordinates ID=1
Sep 21 09:35:29 hkpc kernel: hcons1: <Telink Wireless Receiver Consumer Control> on hidbus2
Sep 21 09:35:29 hkpc kernel: hsctrl1: <Telink Wireless Receiver System Control> on hidbus2
Sep 21 09:35:29 hkpc kernel: usbhid3 on uhub3
Sep 21 09:35:29 hkpc kernel: usbhid3: <Telink Wireless Receiver, class 0/0, rev 1.10/1.00, addr 3> on usbus2
Sep 21 09:35:29 hkpc kernel: hidbus3: <HID bus> on usbhid3
Sep 21 09:35:29 hkpc kernel: hkbd1: <Telink Wireless Receiver Keyboard> on hidbus3
Sep 21 09:35:29 hkpc kernel: kbd3 at hkbd1
Sep 21 09:45:24 hkpc kernel: ugen2.3: <Telink Wireless Receiver> at usbus2 (disconnected)
Sep 21 09:45:24 hkpc kernel: usbhid2: at uhub3, port 2, addr 3 (disconnected)
Sep 21 09:45:24 hkpc kernel: hsctrl1: detached
Sep 21 09:45:24 hkpc kernel: hcons1: detached
Sep 21 09:45:24 hkpc kernel: hms1: detached
Sep 21 09:45:24 hkpc kernel: hidbus2: detached
Sep 21 09:45:24 hkpc kernel: usbhid2: detached
Sep 21 09:45:24 hkpc kernel: usbhid3: at uhub3, port 2, addr 3 (disconnected)
Sep 21 09:45:24 hkpc kernel: hkbd1: detached
Sep 21 09:45:24 hkpc kernel: hidbus3: detached
Sep 21 09:45:24 hkpc kernel: usbhid3: detached
Sep 21 10:01:37 hkpc kernel: ugen2.3: <Telink Wireless Receiver> at usbus2
Sep 21 10:01:37 hkpc kernel: usbhid2 on uhub3
Sep 21 10:01:37 hkpc kernel: usbhid2: <Telink Wireless Receiver, class 0/0, rev 1.10/1.00, addr 3> on usbus2
Sep 21 10:01:38 hkpc kernel: hidbus2: <HID bus> on usbhid2
Sep 21 10:01:38 hkpc kernel: hms1: <Telink Wireless Receiver Mouse> on hidbus2
Sep 21 10:01:38 hkpc kernel: hms1: 5 buttons and [XYW] coordinates ID=1
Sep 21 10:01:38 hkpc kernel: hcons1: <Telink Wireless Receiver Consumer Control> on hidbus2
Sep 21 10:01:38 hkpc kernel: hsctrl1: <Telink Wireless Receiver System Control> on hidbus2
Sep 21 10:01:38 hkpc kernel: usbhid3 on uhub3
Sep 21 10:01:38 hkpc kernel: usbhid3: <Telink Wireless Receiver, class 0/0, rev 1.10/1.00, addr 3> on usbus2
Sep 21 10:01:38 hkpc kernel: hidbus3: <HID bus> on usbhid3
Sep 21 10:01:38 hkpc kernel: hkbd1: <Telink Wireless Receiver Keyboard> on hidbus3
Sep 21 10:01:38 hkpc kernel: kbd3 at hkbd1
 
So possibly what I've experienced on ThinkPad P52 (and only on ThinkPad P52 throughout ThinkPads I had before) is NOT P52-specific, but there are some differences between yours and mine.

In my case, bootcodes (regardless legacy BIOS mode via CSM or UEFI mode) and loader often loses control with internal keyboard (PS/2), but not as often after handed over to kernel.
After handed over to kernel (means, FreeBSD drivers are used instead of BIOS calls nor UEFI runtime/boottime services), loses of control for internal keyboards basically under quite heavy loads like building massive ports like LLVM, Rust, Gcc, Chromium and so on, but not by repeatedly pressing "lock keys" like Caps, Num, ...
Attaching USB keyboards and/or mice sometimes helped, but not always for me.

What I suspected was that drivers for PS/2 ports still require GIANT lock (maybe as of ISA bus) and somehow fail to obtain lock when needed (or fail to release locks), but not sure. Analyzing this further beyonds me.
And possibly why attaching USB HID devices sometime helps could be because it changes states for upper HID layer and cause re-initializes for PS/2 (atkbd, psm), too.
 
Have you tried playing with the "Legacy USB" support in the BIOS/UEFI? The USB keyboard -> PS/2 keyboard emulation might interfere with an actual PS/2 keyboard attached.
 
You must log in or register to reply here.
Back
Top