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): 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Very, although the time required is random. Steps to Reproduce: 1. Use the mouse Additional info: 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] lspci -v
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).
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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 though.
Hello Eric, 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.