Bug 124378
Summary: | USB Mouse Hangs Randomly | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | George <gmcastil> |
Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | barryn, c_o_hall, fischer-michael, gmcastil, haliyo, phale |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-16 06:08:45 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: |
Description
George
2004-05-26 03:32:16 UTC
This happens to me too on a Dell Inspiron 8200. I ran FC1 for months without this problem but now at erratic times the mouse would go off and /var/log/messages would be filled with May 25 20:46:59 localhost kernel: usb 1-1: can't set config #1, error -84 May 25 20:47:00 localhost kernel: usb 1-1: new low speed USB device using address 34 May 25 20:47:00 localhost kernel: usb 1-1: can't set config #1, error -84 May 25 20:47:00 localhost kernel: usb 1-1: new low speed USB device using address 35 May 25 20:47:00 localhost kernel: usb 1-1: can't set config #1, error -84 May 25 20:47:01 localhost kernel: usb 1-1: new low speed USB device using address 36 May 25 20:47:01 localhost kernel: usb 1-1: can't set config #1, error -84 May 25 20:47:02 localhost kernel: usb 1-1: new low speed USB device using address 37 May 25 20:47:02 localhost kernel: usb 1-1: can't set config #1, error -84 May 25 20:47:03 localhost kernel: usb 1-1: new low speed USB device using address 38 and so on. BUT, then it would turn on again by itself and the log would reflect: May 25 20:48:10 localhost kernel: usb 1-1: USB disconnect, address 52 May 25 20:48:12 localhost kernel: usb 1-1: new low speed USB device using address 53 May 25 20:48:13 localhost kernel: input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1 May 25 20:51:23 localhost kernel: spurious 8259A interrupt: IRQ7. Alexander, get your own bug. George a) had the same problem on 2.4 b) does not have difficulty setting configs. It should be obvious his problem has nothing in common. BTW, George - please try a different mouse. As in, significantly different. A Logitech or something. Have used a Logitech mouse with the same results. A friend has the same problem with different hardware and input devices (USB keyboard does the same thing). I've also tried enabling ACPI in the BIOS, but this gives the same results. I meant to copy the /var/log/messages around the time the mouse would hang: May 26 14:17:21 cerebro gconfd (meathook-2519): GConf server is not in use, shutting down. May 26 14:17:21 cerebro gconfd (meathook-2519): Exiting May 26 14:17:23 cerebro gconfd (meathook-2695): starting (version 2.6.0), pid 2695 user 'meathook' May 26 14:17:23 cerebro gconfd (meathook-2695): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at position 0 May 26 14:17:23 cerebro gconfd (meathook-2695): Resolved address "xml:readwrite:/home/meathook/.gconf" to a writable config source at position 1 May 26 14:17:23 cerebro gconfd (meathook-2695): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at position 2 May 26 14:18:37 cerebro kernel: usb 2-2: USB disconnect, address 3 May 26 14:18:39 cerebro kernel: usb 2-2: new low speed USB device using address 4 May 26 14:18:39 cerebro kernel: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-2 Didn't know if it was relevant or not. I can confirm this bug. I have installed FC2 final on a Dell machine. The mouse randomly hangs. But instead of going dark, my optical mouse just goes bright for several seconds, before going to the darker idle mode. Anyhow I have to reconnect the mouse in order to get it work again. There are no related error messages on syslog. This is a Dell optical wheel mouse (not wireless), which reports itself as Logitech when connected. I have tried another Dell mouse of the same kind. It seems to hang more rarely now (maybe once a day instead of five times), but it still hangs. Now, what's really interesting is that my machine also has an Intel i865/875 chipset with an Intel 82801 (ICH5/ICH5R) USB controller. I have found someone on fedoraforum.org who could also confirm this issue, and also has this very same chipset. I'm having the same problem with a Logitech optical wheel mouse, an Intel i875 chipset, and a 82801EB/ER (ICH5/ICH5R) USB controller. I've found a pretty consistent way to reproduce the bug on my machine. Using gnome, if I press the alt key, left click on some window, and move the window around for a few seconds, then the mouse will hang. The problem went away after I disabled legacy USB support in the BIOS. Disabling the legacy USB works for me too... Nice workaround! *** Bug 125443 has been marked as a duplicate of this bug. *** I've had a long-standing related problem: Often when I boot and start X, the mouse doesn't work. The mouse cursor just sits there in the center of the screen. This has happened on several different Dell computers with Logitech wheel mice, and with kernels dating back to 2.4 or before. It used to be sporadic, only happening occasionally, so when it did occur, a reboot generally fixed the problem. But with the latest kernel (2.6.8-1.521) and FC2, the mouse fails almost every time. Sometimes unloading and reloading uhci_hcd fixes the problem, but often this has to be repeated many times before the mouse works. I just tried disabling the legacy USB in the BIOS, and the mouse worked the first time! Thanks for the suggestion!!! Very similar problem. Hardware was from Dell, a Dimension 8300 about 1 year old. Mouse is from Dell, optical wheelmouse. System worked fine under RH9, but after update to FC2 started flaking out immediately. Mouse just randomly hangs. Keyboard still responds. Killing the X server with CTL-ALT-DEL and restarting it with startx makes the mouse work again. I have a Dell Precision 670 Workstation with the same problem (Intel 82801EB/ER USB Chipset) but I don't have a BIOS option to disable Legacy USB support. Any ideas on a work-a-round for this system. I've had the same problem since FC2 ( or before, memory fails me ). And now with FC3 (2.6.9-1.678_FC3) it's still not dead. Logitech MX500 mouse. I also need to jump out of X and back into it to get the mouse going again. same probem with FC3 and RHEL4 Dell Dimension 4600 other non dells dont seem to have this problem around here. Logitech marble mouse USB. Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you. I have the same problem with Fedora Core 3 and Dell Dimension 4550. Logitech optical USB mouse. Changing virtual terminals fixes the problem, until next hang. I can reproduce the bug by playing a game (Americas Army/Enemy Territories). Play a few minutes and the mouse hangs. Removing legacy USB emulation in BIOS, which I learned about here, seem to be a workaround - thanks! The version for this bug should be changed to FC3. This bug still exists in FC3 kernel 2.6.11 USB mouse dies unexpecedly with no apparent reason after random periods of time It does not appear to matter what application is running. the macnines are via C3 epia Changing the bios for legacy usb makes no difference. If the mouse is detached and re inserted the mouse normaly re starts. When the mouse stops the mouse light goes dull (Microsoft Optical) Also tried a Labtec mouse same result. stopping and starting the mouse driver makes no diff Chris, get your own bug if you're serious about tracking the problem with the EPIA. The rest of the Dell sufferers can also try kernel option "usb-handoff" now. It tells the kernel to request the USB from the firmware early in the boot process to get SMM out of the way. Im not sure what you mean by get your own bug ? I did not realise this was exclusivly a DELL list Infact I think the first board mentioned on this list was MSI While the problem is present on several epia machines I support I can also get the same bug on an ASUS board. All using FC3 as I mentioned if you un plug the mouse and plug it back in it comes good but only for a random amount of time. |