Date: Tue, 16 Aug 2016 15:08:11 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: bugzilla-noreply@freebsd.org Cc: freebsd-bugs@freebsd.org Subject: Re: [Bug 211884] IPKVM cannot reliably enter text under 11.0-RC2 Message-ID: <20160816132802.U911@besplex.bde.org> In-Reply-To: <bug-211884-8@https.bugs.freebsd.org/bugzilla/> References: <bug-211884-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160816132802.U911>