Bug 2345

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.