keyboard loss in DF

[Matthew Dillon]

    Anything related to PS/2 dropping out on a KVM switch is almost
    certainly related to problems resynchronizing the keyboard/mouse stream
    after it has been 'glitched'.  E.G. the same issue occurs if you unplug a
    PS/2 mouse and plug it back in.

    This is code I've only glanced at but if someone wants to take a look
    at it and play around (add printf's to see what the stream looks like
    after a glitch to see if it's possible to resynchronize it in a better
    way then the current code does)... then I'd go for it.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


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