Keyboard and PS/2 mouse lockups
I know this is not new, but I feel that my input is worth noting.
I recently upgraded my hardware from a Tyan board with a PII 333 to an ASUS P4T with a P4 1.5G.
Running either kernel 2.2.19 or 2.4.6, 2.4.7, 2.4.8, 2.4.9, I get a serious conflict between the PS/2 mouse and the keyboard. If the mouse is plugged into the machine and generates any mouse event (by moving it or clicking) the keyboard is completely locked up. I am using a KVM (=kbd-video-mouse) splitter box, and the strange thing is that the box will respond to a 'double scroll lock' keypress to switch from one machine to the next, but if the kbd is locked up by the above trouble it will not respond at all, and the manual switching button must be used. This is very strange, as the 'double scroll lock' action works even if the currently selected machine is switched off!
I get the lockup whether or not gpm is running, and even if the kernel is built with no PS/2 mouse support. If the mouse is removed before the trouble is triggered, all is OK.
All of the above is using the console. I can run X from a remote machine - this is what I have usually done anyway, for a number of local reasons. I can also telnet into the machine. But the console keyboard is totally, utterly dead.
For what it is worth, the problem does not occur if the machine is booted up into DOS rather than linux, so it cannot be purely a hardware problem, but must be s combined hardware/linux kernel problem.
Any ideas?
Michael Ben-Gershon
[email protected]
Quoted 18 lines · Michael Ben-Gershon
I know this is not new, but I feel that my input is worth noting.
I recently upgraded my hardware from a Tyan board with a PII 333 to an ASUS P4T with a P4 1.5G.
Running either kernel 2.2.19 or 2.4.6, 2.4.7, 2.4.8, 2.4.9, I get a serious conflict between the PS/2 mouse and the keyboard. If the mouse is plugged into the machine and generates any mouse event (by moving it or clicking) the keyboard is completely locked up. I am using a KVM (=kbd-video-mouse) splitter box, and the strange thing is that the box will respond to a 'double scroll lock' keypress to switch from one machine to the next, but if the kbd is locked up by the above trouble it will not respond at all, and the manual switching button must be used. This is very strange, as the 'double scroll lock' action works even if the currently selected machine is switched off!
Quoted 3 lines
I get the lockup whether or not gpm is running, and even if the kernel is built with no PS/2 mouse support. If the mouse is removed before the trouble is triggered, all is OK.
That seems to be the problem! If the kernel is compiled without busmouse support, and with PS/2 mouse support, then the mouse is recognised and the keyboard does not get locked up.
This is, therefore, a warning to all:
Even if you are configuring a system with no need for a mouse (as I had been doing until now - a system console for a server, and no local X-server required) YOU MUST CONFIGURE THE KERNEL WITH THE PS/2 MOUSE DRIVER (and NOT as a module) or else you are likely to suffer the consequences!
Michael Ben-Gershon
[email protected]