USB mouse stops working. Fedora Core 3 / Kernel 2.6.10-1.741_FC3 (and earlier 2.6.9 versions) on an HP Pavilion zt1000 laptop. Logitech TrackMan Wheel Mouse and Logitech Optical Wheel Mouse both show same symptoms. No mouse defined except in xorg.conf. Synaptics driver for laptop touchpad commented out. Touchpad mouse does not experience failures. Does not require any specific application: stops working in Firefox, File Browser, and Desktop. Pertinent sections of xorg.conf: Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" # InputDevice "Synaptics" "AlwaysCore" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Core Pointer" Option "Buttons" "5" Option "Device" "/dev/input/mice" Option "Protocol" "IMPS/2" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" EndSection If I switch to another virtual console and back into X the usb mouse starts working again, but will fail again soon (same with unplug/re-plug usb mouse.) Same hardware dual-boots Fedora Core 1 (2.4.x kernel & Xfree86) and does not experience this problem.
Yes, we reproduce that easily with Fedora Core 2 (tried almost all versions of kernel for this distribution, from 2.6.5-1.358 to 2.6.10-1.14_FC2) on a variety of dual-processor Dell workstations. However we can't reproduce that at home, with single-processor machines. All machines have Nvidia graphics cards and USB mice, but I don't know if that's relevant or specific to Nvidia cards. We can reproduce the problem easily by moving the mouse and clicking the mouse's button repeatedly while pressing the Ctrl key on the keyboard. Switching to another virtual console and back to X does help. Any clues on how to debug this or provide more information?
First need to check if the problem does or does not occur with PS/2 mice on the same machines (I have the same problem). As the touchpad doesnt seem to have the problem (likely PS/2 internally), this would indicate that its either a usb problem or something with interrupts in the interrupt layer of Xorg. Has this been verified on non Linux machines?
Yes, I am having similar problems with my setup. I have an nvidia geforce 440 mx AGP and a Microsoft Optical USB Intellimouse mouse. I am running the latest stable release of X.org (6.8.2) on a x86 Gentoo box. Instead of freezing my mouse flips out and starts randomely clicking the left/right buttons. I have had this problem with all the kernel's I have used, including 2.6.9, 2.6.10, 2.6.11. I did not have this problem with Slackware running a 2.4 kernel about half a year back with an older X.org.
Never heard of this problem on our Windows machines.
Can you try with the evdev driver?
I am seeing something like this happen since an upgrade to Debian 6.9.0 on Kernel 2.6.15. After about 30 seconds of inactivity a Logitech OEM USB mouse and i810 driver (865G graphics) the mouse will freeze and report no events. It is restored by switching to a different console and back. When plugging in a Microsoft Intellimouse the Intellimouse works fine with no problems. With both mice connected they both work initially until the logitech freezes, and the MS mouse continues to work.
> Can you try with the evdev driver? In my case, when using the evdev driver it still stops after the idle delay, but when using the evdev driver, the difference is that it won't reset after a virtual console switch and remains frozen. There may be more than one problem here though, because in my case control-clicking doesn't appear to cause the freezing.
You are not using KVM's are you?
I'm also concerned about obscuring this bug with a different issue, but mine is that launching an SDL game (tested crack-attack, Ri_li and frozen-bubble) causes the USB mouse to stop responding the instant the mouse enters the game window. The synaptic touchpad continues to work fine, as does the desktop. Additionally, X process goes into an uninterruptible I/O sleep and the desktop freezes the instant I attempt to switch to a terminal (ctrl-alt-f1) or exit the desktop. Nothing is reported to stdout, Xorg log, dmesg or syslog. I had thought at first it was a symptom of using /dev/input/mice with touchpad and USB mouse, but this occurs whether the two are split up using separate drivers and input device entries or a single entry.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Addendum. SDL game is not needed for the USB mouse to die. Does it sometimes just when using X normally. Last time was while closing a firefox browser window and switching to a new one. The two mice. Driver "synaptics" Option "CorePointer" Option "Device" "/dev/input/mouse1" Option "Protocol" "auto-dev" Driver "mouse" Option "Protocol" "ImPS/2" Option "Device" "/dev/input/mouse0" Will try different protocol, but pretty sure had behaviour with auto-dev too, which was why I switched. and of course X giving me uninterruptible sleep and hanging on logout is definitely not-good.
Ok. After repeated boring tests. USB mouse simply freezes. Disabling synaptic touchpad making USB mouse corepointer does nothing. Changing driver does nothing. SDL triggers it immediately, but even with just regular use it'll freeze eventually after a few minutes to half an hour. Maybe, if lucky, a few hours. No messages to STDOUT, STDERR, dmesg, syslog... Any advice on how to debug would be appreciated.
Turned to Linux on Laptops for advice of those who had gone before. http://cmccabe.freeshell.org/edgy_l25_s119.html Adding "noapic irqpoll pci=routeirq" As suggested seemed to do the trick. No more freezing mouse, no more SDL issues or X lockups. "noapic" seems to be unnecessary. Haven't tried trimming the other two yet, nor reading as to what these options do.
And final update, at least in my case, the magic invocation was "irqpoll" and only "irqpoll" With that in place, no more X freezes, no more loss of mouse. It seems, then, Xorg was responding unpredictably to unpredictable kernel behaviour. If that is the same for the folks who filed the bug, perhaps this bug was filed under the wrong product.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.