Red Hat Bugzilla – Bug 183454
Logitech USB optical mouse freezes after 10 seconds inactive
Last modified: 2008-03-10 20:57:01 EDT
Description of problem:
I have a Logitech USB optical mouse. After starting X, the mouse will work
correctly for as long as I use it almost constantly. If I leave it alone for 10
seconds, all mouse input will thereafter be ignored -- the pointer can not be
moved, nor will the buttons have any effect.
This problem doesn't affect gpm, so it seem unlikely that it's a kernel bug.
It also doesn't affect other USB mice. I've tested an MS optical USB mouse and
a Dell branded USB non-optical mouse.
Version-Release number of selected component (if applicable):
I saw this problem during the installation of FC5 test3, and have seen it
consistently since, after each set of updates applied.
Steps to Reproduce:
1. Log in to X
2. Leave mouse idle for 10 seconds
3. Try to move mouse
I forgot to add:
I can recover mouse activity after a freeze by switching to a different VT and
then back to X.
This is starting to look like a kernel issue... If I boot the last FC4 kernel, I
don't have this problem.
I'm not seeing the problem yet under kernel 2.6.15-1.2009.4.2_FC5
The problem is back under kernel 2.6.15-1.2041_FC5.
2.6.15-1.2009.4.2_FC5 didn't manifest the problem during several days of use.
Same problem with a fresh FC5 on a Dell inspiron 500m (Intel 855GM graphics)
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
I'm still having the problem on FC6. These messages appear in /var/log/messages
after plugging in the mouse:
Oct 30 21:13:54 herald kernel: usb 1-2: new low speed USB device using uhci_hcd
and address 5
Oct 30 21:13:54 herald kernel: usb 1-2: configuration #1 chosen from 1 choice
Oct 30 21:13:54 herald kernel: input: Logitech USB Mouse as /class/input/input4
Oct 30 21:13:54 herald kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse]
Oct 30 21:15:22 herald kernel: usb 1-2: reset low speed USB device using
uhci_hcd and address 5
Oct 30 21:16:45 herald kernel: usb 1-2: reset low speed USB device using
uhci_hcd and address 5
Oct 30 21:18:48 herald last message repeated 2 times
Oct 30 21:20:10 herald kernel: usb 1-2: reset low speed USB device using
uhci_hcd and address 5
I'll also attach lspci output which will detail the USB chipset, and
/var/log/dmesg, in case that's useful, too.
Created attachment 139808 [details]
Created attachment 139809 [details]
The symptoms of this problem have changed slightly from when it was originally
reported. I've been discussing it on the linux-usb-users list (the discussion
has been moved to the linux-usb-devel list) for the last couple of weeks.
Much debugging has indicated that the problem occurs when the kernel is built
with the preemptible option, and the timer frequency is 1000 HZ. Only when both
of those settings are used together do I see the problem.
Gordon, thanks a lot for working with the upstream. I saw Alan Stern's message
to linux-usb-devel. But the problem is so odd that I did't have anything smart
I also see this bug, but in a slightly different form. I'm using a Genius
optical mouse and running at run level 5, so I'm using the X login screen.
The bug only affects me if I leave the console logged out for a few hours,
usually with the screen switched off. When I turn the screen back on the mouse
is partially active - its LED brightness changes as I move it - but the pointer
doesn't move and the entry box doesn't accept a user name. There's no obvious
disk activity associated with moving the mouse.
My workround is to momentarily unplug the mouse. It starts working immediately
its reconnected, the login screen becomes active and I can log in.
The bug first appeared for with my FC5->FC6 upgrade and persisted across the FC-
6->FC7 upgrade. A few releases ago it was apparently cured, but with the recent
upgrade to kernel 184.108.40.206-52.fc7 it has reapeared. I've never bothered to
report this bug because I have a workround and I only use the console every few
days, so its only a minor irritation. Normally the machine is accessed over my
LAN. I'm adding this note to let you know that it was apparently cured but has
Hardware: IBM NetVista, model 6578-PBG, s/n 557432R
Mouse port: the PS/2 mini-DIN socket on the motherboard
Mouse: Genius model GM-04003A
The mouse this may be a Logitech Optical Mouse clone - I have one of those too
and the Genius mouse looks almost identical. Both types are USB mice. The
Genius mouse is connected to the motherboard's PS/2 port via the USB->mini-DIN
converter supplied with it.
Since I added the Genius Mouse comment I've upgraded the NetVista from its
standard 256 MB RAM to its maximum (512 MB) and this problem has vanished.
So, as far as I'm concerned it has been cleared.
closing this bug as requested in the previous comment