Bug 317831 - USB mouse stops working
USB mouse stops working
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-04 01:50 EDT by Eric Hokanson
Modified: 2008-01-15 08:09 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-15 08:09:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg after mouse dies and trying to replug (22.97 KB, text/plain)
2007-10-04 01:50 EDT, Eric Hokanson
no flags Details
/proc/interrupts after dead mouse (1000 bytes, text/plain)
2007-10-04 01:51 EDT, Eric Hokanson
no flags Details
lspci -v (8.98 KB, application/octet-stream)
2007-10-04 01:51 EDT, Eric Hokanson
no flags Details

  None (edit)
Description Eric Hokanson 2007-10-04 01:50:00 EDT
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): #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.
Comment 1 Eric Hokanson 2007-10-04 01:50:00 EDT
Created attachment 215451 [details]
dmesg after mouse dies and trying to replug
Comment 2 Eric Hokanson 2007-10-04 01:51:17 EDT
Created attachment 215461 [details]
/proc/interrupts after dead mouse
Comment 3 Eric Hokanson 2007-10-04 01:51:45 EDT
Created attachment 215471 [details]
lspci -v
Comment 4 Pete Zaitcev 2007-10-04 02:07:01 EDT
Fabulous report, although honestly I have no clue why the mouse rolled over.
BTW, what does happen if you reload ohci_hcd?
Comment 5 Eric Hokanson 2007-10-04 19:26:23 EDT
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.
Comment 6 Eric Hokanson 2007-10-05 00:10:41 EDT
Nevermind, I got it to fail even with the irqpoll option, it just took 10x
longer than without.
Comment 7 Eric Hokanson 2007-10-08 19:33:53 EDT
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.
Comment 8 Pete Zaitcev 2007-10-08 19:55:12 EDT
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).
Comment 9 Christopher Brown 2008-01-14 13:20:35 EST

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?
Comment 10 Eric Hokanson 2008-01-14 20:07:05 EST
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
Comment 11 Christopher Brown 2008-01-15 08:09:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.