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): xorg-x11-drv-mouse-1.0.3.1-1.2 How reproducible: 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. Thank you.
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] on usb-0000:00:1d.0-2 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] /var/log/dmesg
Created attachment 139809 [details] lspci -vvv
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 to reply.
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 2.6.23.12-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 now reappeared. 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