Red Hat Bugzilla – Bug 317831
USB mouse stops working
Last modified: 2008-01-15 08:09:20 EST
Description of problem:
After a random amount of time my USB mouse will stop working. This requires me
to ssh into the machine remotely to reboot it.
Version-Release number of selected component (if applicable):
184.108.40.206-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Very, although the time required is random.
Steps to Reproduce:
1. Use the mouse
This may be related to bug 201445.
This is an nvidia nForce 4 mobo that used to have a single core 3800+ processor
in it and it worked fine. After upgrading to dual core 4800+ is when this
problem started. Strangely enough booting with maxcpus=1 does not fix the
problem. Tried noapic and nolapic but problem still persists. Unplugging the
mouse and plugging it back does nothing.
Created attachment 215451 [details]
dmesg after mouse dies and trying to replug
Created attachment 215461 [details]
/proc/interrupts after dead mouse
Created attachment 215471 [details]
Fabulous report, although honestly I have no clue why the mouse rolled over.
BTW, what does happen if you reload ohci_hcd?
I can't seem to reload ohci_hcd. The command just seems to hang forever.
I'm currently booting with 'irqpoll' and this seems to fix the problem. I hear
this is bad for performance but at least I can use my machine for the moment.
Nevermind, I got it to fail even with the irqpoll option, it just took 10x
longer than without.
I seem to have figured out the problem. I had an option in the BIOS enabled to
dynamically overclock the bus/CPU speed based on system load. Linux seems
unable to handle the dynamic bus changes and for some reason this blows up the
USB system or at least the ohci_hcd module. Setting the bus into a locked
speed, even if overclocked beyond what the the dynamic system will do, allows
for a rock stable system.
Very interesting. This may be a similar mechanism as bug 248783, then
(PLEASE do NOT dup -- different controller). There, switching of the
CPU clock by CPUfreq suspends DMA. Perhaps OHCI HCD does not handle
this correctly and dies, which is a bug (in case of EHCI the HC
fails transactons but HCD recovers).
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
Pete, would you like this leaving open or can it now be closed?
I'll provide a quick update on this bug. I noticed an error in my original
report, it's an nForce 5 chipset not 4.
Even with a locked bus speed I would still have the ohci_hcd module die after a
week or so. Upgrading to the 2.6.23 kernels has appeared to fix this. I have
not seen this bug since, however I did not try the dynamic clock option in the
BIOS again. Plugging a high bandwith device such as a webcam still leaves
various "ohci_hcd 0000:00:0a.0: leak ed ffff810037e7e230 (#81) state 2" messages
Thanks for the update. I'll close CURRENTRELEASE but please don't hesitate to
re-open if it returns. Thank you for taking the time to file the original report.