Bug 99539
| Summary: | USB devices die when using RPM GUI | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <epyon9283> | ||||||||||
| Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 9 | CC: | riel | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | athlon | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2004-09-30 15:41: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: |
|
||||||||||||
I would like to see the output of dmesg, taken AFTER the occurence (the one in /var/log/dmesg won't work). Please attach it to the bug as attachement, do not drop it into the comments box. Created attachment 93112 [details]
Output of dmesg after the problem occurs
Perfect, thanks! Since we are doing so well, please do one more thing. Unplug the mouse; on the console do "su -", then "rmmod hid", "modprobe hid", plug the thing back, and collect the dmesg as before. I am curious to see how it fails to come back, e.g. if it's he hub code, or hid code. And also, please take /proc/interrupts and /proc/modules snapshot, just to make sure that counters move and cs46xx does not do something wrong. Created attachment 93123 [details]
Output of dmesg after "rmmod hid", "modprobe hid"
This is the output of dmesg after disconnecting the USB mouse, running "rmmod
hid" and "modprobe hid" and then reconnecting the mouse.
Created attachment 93124 [details]
/proc/interrupts
I hope this is what you wanted
Created attachment 93125 [details]
/proc/modules
Does the interrupt counter for IRQ10 move? I suspect interrupts ceased to arrive for some reason. It's shared, so eth0 and sound both should be quiet (cable pulled on Ethernet) while replugging the USB mouse. If they arrive (counter moves), it's the usb-uhci problem. If they don't, it's not narrowed. May be a hardware failure of some sort... The counter does change May I see output of "ps alx"? Making sure a) khubd is still alive, b) no stuck processes are present. I failed to reproduce the problem so far, though my laptop is a little different: only one UHCI controller, and ymfpci sound. Same 2.4.20-19.9. Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 Description of problem: When using the RPM GUI in RH9 all of the USB devices on my system die. This includes my mouse and keyboard. The lights on the devices stay on but they do nothing. If I try unplugging the devices and plugging them back in nothing happens. Version-Release number of selected component (if applicable): kernel-2.4.20-18.9 How reproducible: Always Steps to Reproduce: 1. Open an RPM file with the GUI program, Open the Add/Remove Applications program, or try to install anything through the redhat network program. 2. Watch as the USB devices die. 3. Actual Results: My USB devices stopped working until I restarted my computer. Expected Results: My USB devices should have continued to work. Additional info: This happened on an Athlon XP system using an Abit KX7-333 which uses the KT333/VT8233 chipset.