ok, this just confirms my theory.
Mouse, USB and PCMCIA can easily all be on irq12 - it may not be the most
common setup, but it is definitely _one_ common setup (another is having
USB and PCMCIA share irq9).
And yes, USB and PCMCIA are the only drivers that are _likely_ to share
the interrupt, so this also explains why problems like this are new. The
keyboard/mouse driver didn't commonly use to care because it historically
didn't get many "spurious" interrupts.
This might actually be an old lockup problem - there have always been
reports of keyboards dying. It might just have been explained only now..
I don't see anything actually _wrong_ in the keyboard interrupt handler,
though. That worries me. What we do to the mouse hardware is pretty much
the same whether the mouse device is open or not, and the only real
difference in opening the mouse is that it makes us save the events...
Oh. We do some mouse initialization at open too. That might be a problem,
and that _does_ make a difference unlike the actual irq path.
In fact, in "aux_open()", could you people who see a problem try to
disable the toshiba4030cdt workaround? Just #if 0 the send_data() code
that sends a KBD_CMD_ENABLE thing to the keyboard, and see if that makes
any difference? The shared interrupt thing may be a red herring, just a
timing difference.
Linus
-
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/