From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: I have a Microsoft USB mouse. Every now and again (usually after a few minutes use). It "stop working". The mouse pointer doesn't move on the screen (although the pointer icon is able to change). Unplugging and replugging the mouse causes everything to work again (until the next "lock"). My perception is that the problem is more likely to happen if there is "activity" happening (e.g. redrawing) on the screen. NB: I'm uncertain as to whether this is an X or kernel problem. Version-Release number of selected component (if applicable): XFree86-4.3.0-45.0.1 How reproducible: Always Steps to Reproduce: 1. Plug in mouse 2. Wait for an indeterminate amount of time (usually a couple of minutes). 3. Actual Results: After a while, the pointer stop moving. Expected Results: The pointer should always move when the mouse is moved. Additional info: Output from dmesg during "pause time": Feb 16 14:33:55 zurich kernel: usb 3-1: USB disconnect, address 10 Feb 16 14:33:56 zurich udev[4416]: removing device node '/udev/input/mouse1' Feb 16 14:33:56 zurich kernel: updfstab: numerical sysctl 1 23 is obsolete. Feb 16 14:33:56 zurich modprobe: FATAL: Module ide_probe_mod not found. Feb 16 14:33:56 zurich modprobe: FATAL: Module ide_probe not found. Feb 16 14:33:59 zurich kernel: hub 3-0:1.0: new USB device on port 1, assigned address 11 Feb 16 14:33:59 zurich kernel: drivers/usb/input/hid-ff.c: hid_ff_init could not find initializer Feb 16 14:33:59 zurich kernel: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.2-1 Feb 16 14:33:59 zurich input.agent[4462]: ... no modules for INPUT product 3/45e/47/300 Feb 16 14:33:59 zurich input.agent[4453]: ... no modules for INPUT product Feb 16 14:34:09 zurich udev[4474]: configured rule in '/etc/udev/udev.rules' at line 56 applied, 'mouse1' becomes 'input/%k' Feb 16 14:34:09 zurich udev[4474]: creating device node '/udev/input/mouse1' Selected output from "lspvi -vv": 0000:00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Dell Computer Corporation: Unknown device 0151 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 169 Region 0: Memory at f0000000 (32-bit, prefetchable) Region 1: Memory at feb80000 (32-bit, non-prefetchable) [size=512K] Region 2: I/O ports at ed98 [size=8] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Computer Corporation: Unknown device 0151 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 169 Region 4: I/O ports at ff80 [size=32] 0000:00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Computer Corporation: Unknown device 0151 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 185 Region 4: I/O ports at ff40 [size=32] 0000:00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Computer Corporation: Unknown device 0151 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 169 Region 4: I/O ports at ff20 [size=32] 0000:00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Dell Computer Corporation: Unknown device 0151 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 201 Region 0: Memory at ffa80800 (32-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] #0a [20a0]
This fault also occurs with a second mouse so it's definitely not the hardware.
Don't conclude that prematurely. Anything is possible, including it being a kernel USB driver bug, XFree86 bug, or bad hardware. There are Microsoft IntelExplorer mice which are known to be flawed in the hardware itself, and acknowledged by Microsoft to be broken for example. Testing 10 of these identical mice would produce the problem on all of them, and drawing a conclusion that the hardware is ok from that would be dead wrong. I'm not saying that that is your specific problem however, but rather, until the real problem is determined with 100% certainty, it is very bad to jump to any conclusions too early. Please use the bugzilla file attachment mechanism when attaching large log file content instead of cut and pasting it into the comments, as it makes it easier to follow the text content of a bug report. Please attach your XFree86 config file, X server log file, and the complete /var/log/messages file as individual uncompressed file attachments using the "Create a New Attachment" link just below. Thanks in advance.
Some further questions.. Did this mouse work at all with Fedora Core 1, Red Hat Linux 9, or any previous Red Hat OS release? What mouse protocols have you tried to use in the X config file? Is gpm running? If so, if you disable GPM so that it does not start at boot time, then reboot to reset the hardware completely, does the problem still persist? Are you using a KVM switch?
Created attachment 97730 [details] XFree86 Config File
Created attachment 97731 [details] /var/log/messages
Created attachment 97732 [details] XFree86 Log File
Point taken about defective hardware design; I meant that it wasn't just a problem with a specific mouse (it also happens on another PC). The two mice are slightly different, one is an "Intellimouse Explorer 3.0", the other is an "Optical Wheel Mouse" (both Microsoft). One mouse worked fine on Fedora Core 1, the other was fine on Redhat 9. The only mouse setting I've done is to select "Microsoft Intellimouse Optical (USB)" using the mouse config tool. I'll reboot and try running without GPM in a mo (so far today the mouse hasn't stopped. Yet.). No KVM switch.
This makes me suspect the kernel USB drivers or related code, because the XFree86 mouse driver we ship is stock XFree86 4.3.0 and is identical between Red Hat Linux 9, Fedora Core 1, RHEL 3, and current rawhide. The only difference I can think of that would result in the behaviour you describe, would be kernel driver differences between OS releases.
Stopping GPM and rebooting had no effect.
I think you're right about it being a kernel issue; I've been using the mouse quite happily on a USB 2.0 hub all day, as soon as I went direct the problems showed up again.
Ok, reassigning to kernel...
A bit anecdotal ... I upgraded to 2.6.3-1.91smp to fix a UDP bug and the problem seemed to go away (even with the hub). I've had to revert back to 2.6.1-1.65smp because 2.6.3 disagreed with my network card reliability and the problem returned.
Still present in FC2 test2 (2.6.3-2.1.253.2.1smp). Everything work fine with a hub but without it, the mouse still occasionally stops.
Can you please test these mice on other computers and even other operating systems? Make sure they are reliable on their own. Also please upgrade to full FC development rawhide including minimally: initscripts-7.50-1 kernel-2.6.5-1.326 Please run "dmesg" and see if any kernel messages occur when the mouse "stops" working. Copy those messages into this report. If there are too many messages then please attach it in a file instead.
I only noticed the April 19th comment yesterday ... I haven't had an opportunity to recently test with a different system although when the problem first appeared it was fine when I switched it to a Redhat 9 machine. With the various kernels for FC2 that have come out, the problem has become less frequent. The problem also exists on test3 although I have been using the mouse directly connected to the PC on 2.6.5-1.349smp for 24 hours without a problem. I'm about to put in 2.6.5-1.350smp to test a fix for Intel graphics adaptor, hopefully I will be able to leave it in use for considerably longer than 24 hours.
It has hung again (on 352smp) - no kernel messages. I've got a Windows XP machine that I'm currently trying the mouse on.
Worked for 4 days on a Windows XP machine, hung after about an hour when returned to the FC2 test3 machine. Kernel is currently 2.6.5-1.358smp. No kernel messages.
I have a dual boot Windows XP system that has this problem. I switch back and forth several times a day, and the problem never happens when running XP. I do use a KVM switch for the keyboard (ps/2), but the USB mouse is connected directly to the computer. Before FC2 it was running RH9 and never had this problem. It is obvious when the problem occurs because the mouse "shuts down" by turning off its main LED. On my system, the problem can be cleared up simply by unplugging the mouse and plugging it back in again. There are no kernel messages when the mouse stops working, but there is a USB disconnect message when the mouse is actually unplugged and a USB connect message (with a new address) when it is plugged in again, as expected.
is this still a problem with the latest updates/release ?
I've been using a KVM into the PS/2 port so I wouldn't see this at the moment. Will give it a try on FC3.
Doesn't seem to be around any more.
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.