Messages in this thread | | | Date | Sat, 11 Mar 2000 21:54:54 -0500 | From | Wakko Warner <> | Subject | Re: Keyboard/mouse lockup... again |
| |
> > FYI, this anomaly occurs with the linksys cardbus pcmcia network cards as > > well, it loads the pcmcia tulip driver. removal of the card does not return > > the keyboard/mouse. > > You know, I finally have a clue again. > > The Yenta issue is a complete red herring, and it just so happens that > another change happened to pc_keyb.c at around the same time as the new > cardbus stuff. And I suspect it is a problem only with certain super-IO > chips, and those chips probably tend to be used mostly in laptops, which > is why there seemed to be sucha strong correlation.. > > Very simple test: in drivers/char/pc_keyb.c, at around line 446, there's a > line line > > /* Ignore error bytes */ > if (!(status & (KBD_STAT_GTO | KBD_STAT_PERR))) { > ... > > and people who have the "keyboard and mouse goes away" problem should just > remove that single if-statement completely. > > Does that really simply change make your keyboard come to life again?
You mean the entire block, right? I'm not sure about blu3's problem, but mine is only triggered if: 1) the cdrom is in the machine at boot 2) Yenta is compiled in (or just wait, it'll hit yenta_init and others I assume later and do the same thing) 3) A mouse event occures and /dev/psaux is opened.
My keyboard is returned (with keys pending) when /dev/psaux is closed. As he stated, removing the card doesn't return mouse/kb. In my case, it doesn't matter if there's a card installed or not.
I'll try booting with init=/bin/sh (cdrom installed) and run gpm to see if the same thing happens.
-- Lab tests show that use of micro$oft causes cancer in lab animals
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |