DragonFly BSD
DragonFly bugs List (threaded) for 2004-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: keyboard loss in DF

From: Chris Pressey <cpressey@xxxxxxxxxxxxxxx>
Date: Thu, 2 Dec 2004 09:00:46 -0800

On Thu, 2 Dec 2004 15:15:43 +0100
Jeroen Ruigrok/asmodai <asmodai@xxxxxx> wrote:

> Matt,
> for the past few weeks/months I've been plagued on this machine at
> work by a loss of the keyboard.
> It's a PS/2 one:
> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
> kbd0 at atkbd0
> Doesn't matter if I use console or X, the keyboard is just dead. 
> Plugging it in/out of the PS/2 port doesn't reset, at least not within
> DF.  Resetting the box and going through boot again re-enables my
> keyboard.
> I know Emiel has suffered the same, not sure if it is also a PS/2 one
> though, and I was just told by Sascha that Chris (Pressey) also
> experiences this problem, also with atkbd (from what Sascha
> remembered).

Specifically, the troubles I have are with my KVM switch (and I recall
hearing through the grapevine that Daimao has similar troubles as well.)
Similar symptom - keyboard has a, say, 60% chance of dying outright any
time I use the KVM switch.  But if I never touch the switch, it's fine. 
It could easily be atkbd or syscons related.  It could be because the
(not-exactly top-of-the-line) KVM switch is throwing garbage at atkbd,
or it could be some sort of race condition in syscons's scrollback
buffer code (since the KVM uses a "double-click Scroll Lock to switch"
mechanism.)  Strangely it doesn't seem to happen with my installed
DragonFly system; it only happens when I've booted into a release
environment, like on the LiveCD.  I'm trying to figure out why this is
(I've tried various kernel configurations and I don't think that's it;
I'm not sure what else to check; /etc maybe, I haven't done a make
upgrade on my installed system in a while.)

> Chris suspects
> M_WAIT* malloc() changes in atkbd.c.

It's more like I couldn't think of what else could possibly be causing
it :)  It does seem unlikely that the atkbd and/or syscons code is
getting resource-starved and waiting forever for free memory.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]