by Before everyone jumps in and says 'IRQ Problem', it isn't;
atleast I don't think so. I think it's more a case of
hardware being silly.
On a Compaq Deskpro system, we have the following:
Kernel 2.0.34, P-II-333, 160Mb SDRAM, Intel EX chipset.
Adaptec 2940UW (system disk, and optical drive)
2 x 3Com PCI network cards
1 x ATI Rage IIc AGP video card
0 x ESS sound card (We had one, we didn't use it, we didn't
configure it, then we removed it).
Booting into xdm occasionally causes the system to loop
with xdm reporting 'Can't open /dev/mouse, device or resource busy'.
When this happens, the keyboard tends also to be locked, although
not always, which is wierd.
/dev/mouse is a symlink to /dev/psaux
No process has that inode (/dev/psaux) open (scanning through /proc),
GPM and the usual suspects are not running. Shutting down to single
user mode and doing 'cat /dev/psaux' reports the same problem.
No device in /proc/pci is reported as using IRQ 12.
There is nothing listed in /proc/interrupts for IRQ 12
(the PS/2 mouse should only appear in there once it has been
opened).
Nothing in the BIOS allows us to get IRQ 12 for a PCI card,
only IRQ's 9, 10 and 11 seem to be available.
Hacking through drivers/char/psaux.c, I see that there are three
places where the device reports -EBUSY. These are a result of
failures of request_irq(), poll_aux_status() and another request_irq()
which is not compiled in because CONFIG_82C710_MOUSE isn't defined.
Adding a couple of printk()'s, the poll_aux_status is failing.
Looking back through the syslog, the message 'Keyboard error'
appears every so often. This is a result of keyboard.c getting
a scancode of 0xff back from the keyboard under certain conditions.
I currently suspect the keyboard controller (the PS/2 mouse being,
AFAIK an extension of that).
Any ideas?
Jim