Kevin Buhr wrote:
> There's an insidious spinlock hang hidden in "drivers/char/pc_keyb.c".
> "handle_mouse_event" is called with the "kbd_controller_lock" held. If it
> sees an "AUX_RECONNECT" scancode on the wire, it tries to---according
> to the comments---"ping the mouse". Unfortunately, it does this using
> "aux_write_ack" which tries to grab the lock again.
>
> I triggered this while playing protocol games with a new wheel mouse.
> Presumably, anyone who plugs a PS/2 mouse into a running SMP machine
> will hang their machine; and a flakey mouse that generates spurious
> AUX_RECONNECT messages (or even a working mouse that happens to generate
> that scancode validly) would lead to mysterious lockups, I think.
>
> Anyway, here's a patch. I've tested this on 2.4.0-test5, but it should
> work fine on test7, too.
Hi all,
I have similar problems with a PS/2 mouse on my machine and 2.4.0-test7.
The mouse works ok under X if gpm is not loaded. When loading gpm -t ps2
(gpm 1.19.3) the mouse doesn't work at all in textmode. After killing
gpm and starting it a second time, the machine freezes. This is 100%
reproduceable. I've tried the patch Kevin Buhr posted but it doesn't
change things.
Machine is: i686 Linux-2.4.0-test7 (vanilla)
It's an uniprocessor machine without SMP support, hence the spinlock
issue above doesn't apply here.
IRQ assignment is as follows:
irq 0: 178330 timer irq 9: 0 acpi
irq 1: 3427 keyboard irq 10: 53381 ide0, ide1
irq 2: 0 cascade [4] irq 11: 23 bttv
irq 5: 29039 eth0 irq 12: 49690 PS/2 Mouse
irq 6: 2 irq 13: 1 fpu
irq 7: 1 parport0 [3] irq 14: 708 ide2
irq 8: 1 rtc irq 15: 93661
EMU10K1
I seem to remember that the mouse worked with earlier 2.4.0-testX
versions, but I can't exactly tell at which point things broke.
Regards,
Udo Steinberg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST