# USB mouse crashes

## benjamin.kutschan

My USB mouse crashes randomly once in a while. Then I can plug it into another USB socket and it works again for a while. Replugging it doesn't work, so that if all sockets have crashed I can use the touch pad.  :Confused: 

I'm using a Pentium M, ck-sources, gcc-4.2 hardened, KDE with beryl

The output of dmesg is the following

 *Quote:*   

> [   23.435597] EXT3-fs: mounted filesystem with ordered data mode.
> 
> [   23.637336] Adding 1052216k swap on /dev/sda8.  Priority:-1 extents:1 across:1052216k
> 
> [   26.759775] sky2 eth0: enabling interface
> ...

 

Not that this scares me, but it's kind of annoying having to use the touch pad.

Regards

----------

## didymos

Seems to be a problem with the host controller.  From your post, it sounds like  you've only got one in the machine.  What does "cat /proc/interrupts" show?

----------

## didymos

This is interesting.  I did a search on "spurious 8259a interrupt", and the google toolbar instantly suggested adding the "irq 7".  For something so specific, 17,000+ hits is quite a bit. 

Just for convenience's sake:

http://www.google.com/search?q=spurious+8259a+interrupt+irq7

----------

## benjamin.kutschan

 *Quote:*   

> localhost ~ # cat /proc/interrupts
> 
>            CPU0
> 
>   0:     671504    XT-PIC-XT        timer
> ...

 

And after a mouse crash:

 *Quote:*   

> localhost ~ # cat /proc/interrupts
> 
>            CPU0
> 
>   0:     729323    XT-PIC-XT        timer
> ...

 

The "spurious interupt, IRQ 7" thing sounds rather technical and I'm not an expert in computer hardware. I guess choosing another kernel will do the trick?

----------

## Vlad.Sharp

Hmmm, could you try doing "dmesg | grep -i apic" ? Please also take a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/75626 , it seems to be a similar bug.

Edit: eek - "Fixed in both 2.6.20.11 and 2.6.21." (from the upstream bug). Which kernel version are you running? (And what is the output of cat /usr/src/linux/.config | grep -i acpi ?)

----------

## didymos

If you read into the spurious interrupt thing a bit, turns out it's been around for a long time. The closest thing I've found to a definitive cause is "cheap hardware".  It's apparently something in the design of the 8259a which causes it to report false interrupts on that specific IRQ when there's some hardware-related trouble, either with the actual, physical hardware or with a device-driver.  It doesn't matter what that trouble is, and it's not the 8259a (which begs the question: if the 8259a was messed-up-but-functional, how would you know?).  And in fact, this a feature of the controller that was deliberate.  It lets you know there might be a problem, especially when it keeps getting triggered.

----------

## benjamin.kutschan

Here the requested system information:

 *Quote:*   

> localhost ~ # dmesg | grep -i apic
> 
> [    0.000000] ACPI: APIC 3FEE9E88, 0068 (r1 INTEL  ALVISO    6040000 LOHR       5F)
> 
> localhost ~ # cat /usr/src/linux/.config | grep -i acpi
> ...

 

If it's due to cheap hardware it seems an unfixable bug.

I try noapic nolapic as kernel option in grub.

----------

## benjamin.kutschan

By the way. I have found the solution to the problem. It's rather unrelated to Gentoo. I knocked on my notebook before booting and then kept it still for the whole time. It worked perfectly. If it is moved there seems to be a wary connection inside, so that the mouse first stops working and after a while the whole system. Trying to reboot leaves me with a black screen only. Knocking on it rebooting, and it works again. It hasn't died from this problem for a few months now. Though it is annoying.

Benjamin

----------

