Bug 211884

Summary: IPKVM cannot reliably enter text under 11.0-RC2
Product: Base System Reporter: karl
Component: kernAssignee: Mark Linimon <linimon>
Status: Closed Feedback Timeout    
Severity: Affects Some People CC: albert, bdrewery, chuckiels2011, emaste, pi, re
Priority: --- Keywords: needs-qa, regression
Version: 11.0-RC1Flags: koobs: mfc-stable11?
koobs: mfc-stable10?
Hardware: amd64   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211967
Attachments:
Description Flags
login prompt when unplugging/plugging in keyboard when mouse is plugged in at boot none

Description karl 2016-08-15 22:45:05 UTC 
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.
Comment 1 karl 2016-08-16 03:37:17 UTC 
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

MFC r303765:
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 <brde@optusnet.com.au>

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

And...

uhid0: <Microsoft Comfort Curve Keyboard 2000, class 0/0, rev 2.00/1.73, addr 3> on usbus4
Comment 2 nc 2016-08-18 16:00:24 UTC 
Created attachment 173827 [details]
login prompt when unplugging/plugging in keyboard when mouse is plugged in at boot
Comment 3 karl 2016-08-18 16:35:41 UTC 
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
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-24 13:26:56 UTC 
Assign Hans according to confirmation of r303765 reversion resolving symptoms by users in comment 3
Comment 5 Albert Cervin 2018-05-08 08:30:29 UTC 
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.
Comment 6 Albert Cervin 2018-05-08 08:39:45 UTC 
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.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2023-07-25 19:36:20 UTC 
To submitters/commenters: has this problem been resolved?
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2024-01-05 22:30:39 UTC 
^Triage: feedback timeout (> 3 months).