On Thu, 2 Dec 2004 15:15:43 +0100
Jeroen Ruigrok/asmodai <asmodai@wxs.nl> 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.
-Chris