[Bug 211884] IPKVM cannot reliably enter text under 11.0-RC2

Bruce Evans brde at optusnet.com.au
Tue Aug 16 05:08:16 UTC 2016


On Mon, 15 Aug 2016 "a bug that doesn't want replies"@freebsd.org wrote:

> 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.

Most keyboard drivers have buggy input polling.  I only touched this in
-current, but I asked hselasky to fix some of the bugs in ukbd and he
fixed one in ukbd in r1 and that is in -stable/11.  Apparently the fix
exposed a bug in another layer.  It seems to be acting sort of backwards.

> 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.

Only some keystrokes getting through is caused by the bug of the keyboard
in "polled" mode.  The input handler then eats some or all of the keystrokes
I thought that it was all of them for ukbd.  Switching to polled mode is
supposed to work recursively.  vt depends on this but it was broken in ukbd.
syscons has a bug that compensated the one in ukbd in the GELI input case.

I don't know the plumbing for IPKVM.  Does it just give a usb keyboard?

> 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 PS/2 keyboard driver (atkbd) is closest to working.

kbdmux has the polling nesting bug that was fixed in ukbd.

> 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.

Almost nothing works with the usb keyboard in -current + 1 more round of
syscons fixes for me now.  The usb keyboard worked better a few days ago
with -current + more complete syscons fixes.  So the bug should be easy
to find.

The fix seems to be working inversely.  Without it, getting in and out
of polled mode is too easy and this breaks grabbing if the console
driver doesn't have a compensating bug.  vt doesn't have a compensating
bug, so the expected behaviour with it and ukbd is the interrupt handler
eating most or all of the input.  I see it eating all of the input.
However, vt also has screen refresh bugs at console input prompts,
and has broken keyboard switching using kbdcontrol -k, and seems to
be broken for console input with atkbd too, so it isn't clear if the
bugs are in ukbd.

syscons does have a compensating bug which I am 2 commits away from fixing.
So the expected behaviour is that it works at console input prompts
except nested ones in ddb, but the interrupt handler eats the input
for cncheckc() calls in places like panic dumps.  Oops, places not
like panic dumps -- for panic dumps the cncheckc() calls are in grabbed
mode which should work after the ukbd fix.  However, today I see no
console input with ukbd for syscons too.  kbdcontrol -k works in syscons,
and shows the problem persisting for ddb input after switching to ukbd
in a multi-keyboard configuration.  This worked better a few days ago.
Unplugging the usb keyboard was the only way to get out of some keyboard
hangs then, but today it hung the system (even serial console input
broke).

Bruce


More information about the freebsd-bugs mailing list