[keyboard] ukbd stops working after filesystems mount at boot time

[Hiroharu Tamaru]

Hi

At Wed, 25 Nov 2009 15:14:01 +0300, Travelling Particle wrote:
> > Does this let you work around your problem too?
> >
> > http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2008/freebsd-mobile/20080309.freebsd-mobile
> 
> Haven't tried the patch, but I see what you mean. I had tested with
> atkbd and kbdmux both disabled and having geli passphrase visible.
> It appears that in 8.0-PRERELEASE (cvsuped Nov 23 2009, I think) the
> original problem I had reported is gone: if I can get thru the
> passphrase, the late stage continues fine and keyboard works at login
> prompt without any problem. However, the keyboard works unreliably(*)
> just before the late boot stage, at the moment when the geli
> passphrase is expected. 8.0-RC3 behaved the opposite way: no problem
> at the passphrase, but unusable console right after that.
> 
> (*) By working unreliably I mean that key presses are randomly
> skipped. Sometimes you see keys pressed right after the first press,
> sometimes it takes 3-4 times to repeat the press before the symbol
> gets entered.
> 
> I have googled up that skipping key presses at the passphrase prompt
> was reported since a long time ago. I see that it was somewhat fixed
> in 8.0-RC3 with undesired side-effects. This leaves me wonder if the
> keyboard can be fixed without breaking the console. I am willing to
> help: if anyone needs debugging output or anything, just tell me what
> I should do. USB keyboard is the only input device this computer has
> (no PS/2 or serial port), so I' somewhat desperate.
> 
> > Chances are that unreliable key inputs at boot stage is not that
> > usb specific, but I couldn't dig any deeper then...
> 
> I think it's usb-specific. What else would be responsible for dropping
> input from the usb device?

BIOS or something alike, or some non-interrupt driven
method, or some interrupt mechanism itself?

Back then, I wondered if the kernel used BIOS or any of the
above, that probably is different from how the device is
driven after the boot stage is finalized, but I never
reached the actual code to know it myself.  I'd appreciate
if someone can confirm it either way.

Anyway, in my case, I was using atkbd, and not ukbd, and it
was just that I thought if it were really the BIOS, the same
work around may help.

Anyway, reading your description above, more than one thing
is probably involved, so just take what I wrote as my wild
guess at best.  I wish I knew the kernel better not to guess
a lot like this, of course...

So, the ball is back on the side of the experts here ;-p

> Thanks.