Updated from 11.0-ALPHA to 11.0-RC2 this afternoon on a test machine and ran into a really odd problem.
The system in question has an encrypted root ZFS pool, which results in a prompt for the GELI password during the boot and before the root filesystem mounts. This has been trouble-free for a long time.
This afternoon, however, it suddenly turned into a huge problem. After the kernel loads and the prompt comes up the keyboard was not recognized over the IPMI interface; only one of every handful of keystrokes went through. This meant if you pounded the enter key a few times you'd eventually get one through, but the keys you typed in the meantime (containing the GELI password!) were of course lost - or some of them were anyway.
A locally-attached PS/2 keyboard (at the physical machine) works, but a USB-attached keyboard *also* had intermittent problems, often NOT registering the CAPS and NUMLOCK keys reliably.
The IPMI keyboard is recognized properly at the BIOS level (before the loader gets control) and works fine there.
This is likely to be extremely serious for anyone who attempts to update a system with encrypted disks over a remote link using a built-in IPKVM; the machine in question has a SuperMicro board in it, but given that I *also* had trouble with a USB plugged keyboard on the same machine (but not a PS/2 keyboard!) it appears that this is something in the kernel level and *not* strictly an IPKVM interaction issue.
Reverting to the previous ALPHA kernel resolved the problem immediately. In addition if I change the mouse mode on the web interface (which forces a detach/reattach for the keyboard, which I can see on the KVM console) it will *sometimes* permit me to type the password.
IMHO this needs to be investigated as if RELEASE goes out with this problem present it is likely to screw a large number of people who are doing the upgrade remotely, possibly forcing a trip to the site with a physical keyboard to get beyond the prompt.
I do not know if this was a problem on RC1 as I didn't run it but it was NOT an issue in the ALPHA series of releases.
Scanning back through recent commits I am wondering if this one is related....
r304124 | hselasky | 2016-08-15 03:58:55 -0500 (Mon, 15 Aug 2016) | 7 lines
Keep a reference count on USB keyboard polling to allow recursive
cngrab() during a panic for example, similar to what the AT-keyboard
driver is doing.
Found by: Bruce Evans <email@example.com>
The reason this looks possibly-related is that the KVM attaches as a USB keyboard.... and a plugged-in USB keyboard also exhibits the problem during the boot-time process, as shown here from the boot log on one of the impacted machines....
Enter passphrase for da8p4:
ugen1.2: <Winbond Electronics Corp> at usbus1
ukbd0: <Winbond Electronics Corp Hermon USB hidmouse Device, class 0/0, rev 1.10/0.01, addr 2> on usbus1
kbd2 at ukbd0
uhid0: <Microsoft Comfort Curve Keyboard 2000, class 0/0, rev 2.00/1.73, addr 3> on usbus4
Created attachment 173827 [details]
login prompt when unplugging/plugging in keyboard when mouse is plugged in at boot
Reverting r303765 clears the problem and I can once-again type during the boot process (after the loader hands execution to the kernel and before the system has fully booted to multiuser.)
I strongly recommend reverting this commit prior to 11.0-RELEASE (or figuring out why it causes this undesirable behavior.)
This bug may also be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211967
Assign Hans according to confirmation of r303765 reversion resolving symptoms by users in comment 3
Was this reverted? I also see the same problem on 11.1 with another Input Club keyboard (as in the linked thread). Will see if rolling mentioned change back fixes it for me.
Could the change (the last diff with else if) here https://svnweb.freebsd.org/base/stable/11/sys/dev/usb/input/ukbd.c?r1=304124&r2=305644 have anything to do with it? This change is on 11-STABLE but not released as part of 11.0 or 11.1.