In article <ingima.720570541@kakwa.ucs.ualberta.ca> ingima@ee.ualberta.ca (Darin Ingimarson) writes:
quoted text
>
>       Well, I haven't got this beat, but I'm far from giving up.  Many thanks
>to Bob Kirkpatrick for his help on this.  Here is what I've found out so far:
>
>       The logitech mouse driver snuffs it in the mouse_int() routine at the
>wake_up() call.  What I am humbly requesting is someone who knows a bit more
>about the mouse driver and Linux scheduling to answer a couple of questions for
>me before I get back at it (I've written many a device driver and done lots of
>system level bughunting in a UNIX-like RTOS, so I'm not a complete techno-
>turnip... just not much experience with things like select(), *NIX interprocess
>security, etc.).
>
>       It seems to me (from perusing Linus' source) that this wake_up() call
>suggests to the scheduler that it might want to wake up any proceses waiting
>on a mouse interrupt.  Why would wake_up() die if no processes are waiting
>on the interrupt?  Shouldn't wake_up() just see that nothing is waiting and go
>on with things?  

wakeup() works fine even if there aren't any jobs on the queue: this
particular problem is due to there being *bogus* jobs on the queue, as
the wait-queue pointer is never initialized to NULL in 0.98.1. 

The easy fix is just to initialize the wait-queue correctly, or indeed
just get 0.98.3 which does it correctly.  Also, using new versions of
LILO will result in the kernel bss being automatically cleared, and the
problem goes away. 

                Linus