Bug 317831
| Summary: | USB mouse stops working | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Hokanson <hokanson> | ||||||||
| Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 7 | CC: | cebbert, chris.brown | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | 2.6.23 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2008-01-15 13:09:20 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Eric Hokanson
2007-10-04 05:50:00 UTC
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. |