Bug 115828 - (USB HID)Mouse pointer stops moving (USB mouse)
(USB HID)Mouse pointer stops moving (USB mouse)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-16 09:52 EST by Paul Black
Modified: 2015-01-04 17:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 01:24:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree86 Config File (3.12 KB, text/plain)
2004-02-17 03:20 EST, Paul Black
no flags Details
/var/log/messages (137.21 KB, text/plain)
2004-02-17 03:22 EST, Paul Black
no flags Details
XFree86 Log File (44.22 KB, text/plain)
2004-02-17 03:23 EST, Paul Black
no flags Details

  None (edit)
Description Paul Black 2004-02-16 09:52:59 EST
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]
Comment 1 Paul Black 2004-02-17 02:49:42 EST
This fault also occurs with a second mouse so it's definitely not the
hardware.
Comment 2 Mike A. Harris 2004-02-17 03:01:13 EST
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.
Comment 3 Mike A. Harris 2004-02-17 03:03:50 EST
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?
Comment 4 Paul Black 2004-02-17 03:20:46 EST
Created attachment 97730 [details]
XFree86 Config File
Comment 5 Paul Black 2004-02-17 03:22:24 EST
Created attachment 97731 [details]
/var/log/messages
Comment 6 Paul Black 2004-02-17 03:23:31 EST
Created attachment 97732 [details]
XFree86 Log File
Comment 7 Paul Black 2004-02-17 03:29:59 EST
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.
Comment 8 Mike A. Harris 2004-02-17 03:42:01 EST
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.
Comment 10 Paul Black 2004-02-17 04:08:01 EST
Stopping GPM and rebooting had no effect.
Comment 11 Paul Black 2004-02-17 09:34:06 EST
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.
Comment 12 Mike A. Harris 2004-02-17 10:14:45 EST
Ok, reassigning to kernel...
Comment 13 Paul Black 2004-02-24 05:05:23 EST
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.
Comment 14 Paul Black 2004-04-01 02:35:07 EST
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.
Comment 15 Warren Togami 2004-04-19 03:50:43 EDT
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.
Comment 16 Paul Black 2004-05-05 03:14:03 EDT
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.
Comment 17 Paul Black 2004-05-10 09:29:31 EDT
It has hung again (on 352smp) - no kernel messages. I've got a Windows
XP machine that I'm currently trying the mouse on.
Comment 18 Paul Black 2004-05-14 16:01:00 EDT
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.
Comment 19 Robert G. Fries 2004-05-21 22:27:28 EDT
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.
Comment 20 Dave Jones 2004-12-08 00:34:29 EST
is this still a problem with the latest updates/release ?
Comment 21 Paul Black 2004-12-08 04:11:55 EST
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.
Comment 22 Paul Black 2005-01-04 04:03:12 EST
Doesn't seem to be around any more.
Comment 23 Dave Jones 2005-04-16 01:24:03 EDT
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.

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