Adding to blocker for FC3 to get some attention.  This is still
happening as of fedora-devel (08/16/2004).  Please advise on any
additional information that I can provide to assist in problem
determination.

Sounds like a race in hidinput. Switching VTs causes /dev/input/mice
to be closed and reopen by X. Since the influence of fops methods
does not extend too far down the input stack, I guess a race in
upper layers of input stack. Definitely not USB (hid). How USB might
trip this is by running on softirqs or otherwise breaking through
some other interrupt.

Can you reproduce this wihout X, by running gpm with /dev/input/mice?
This would clear X of any wrongdoing.

I haven't been able to yet.  I also do not do my full days work using
gpm so I probably haven't stressed it enough.  In X the situation
arrises when I'm holding down the <alt> key to move or resize a
window.  It only appears in that scenario.

Like you said, I can chvt to and from my X console, or just
unplug/replug the usb mouse to get it working again.

I'll try and drive the failure in gpm as well...

zaitcev: you were correct!  I can easily reproduce this problem on a
text console with gpm.  Unlike when in X, chvt (to and from an X
console) does not fix the problem.  When the hang is encountered with
gpm, I must restart gpm to get the usb mouse to work again.  I see no
log entries indicating that a failure occured (GPM was configured to
use /dev/input/mouse in /etc/sysconfig/gpm).  

X has been cleared of wrong doing then...

So the common code path would be the usb hid layer?

Please let me know if there is any thing I can do to aid in trouble
shooting this issue.

I am suffering with the same problem, with the mouse dissapearing, for
me I can just leave the system for a prolonged period of time and it
will stop functioning.

I will shutdown X and see if a similar thing happens when at a console.

Doug

I've been having the same issue for a month.  It occurs about 5 - 10
times every DAY.  I know it only occurs when I let the mouse sit for a
few moments.  To correct the issue, I have to switch to a term and
remove and reload mousedev, usbmouse, and input module.  I switch back
to X, and everything is peachy unless i get up to get a drink of water.

I am also not running redhat, I am on gentoo.  I beleive it's a kernel
issue considering I just rebuilt about a month ago.

Just installed FC 3 on a Dell Optiplex with an USB mouse and a PS2
keyboard... same issue (ctrl + mouse move locks the mouse cursor),
though I did not notice anything wrong when the computer/mouse is left
alone.

Eric

Forgot to mention :
FC3 with kernel 2.6.9-1.681_FC3 

I've been having the same issue with FC2 and FC3 on a Dell PowerEdge
670 Workstation.  It happens with any combination of depressing a key
on the keyboard and using the mouse.  Keyboard is a PS/2 keyboard,
Mouse is a USB optical mouse, both from Dell.

Created attachment 107408 [details]
output of dmesg after a mouse freeze

This is the output of dmesg after a mouse freeze.

Just for the record, I'm able to get the mouse working again by
unplugging it and plugging it back in.

Same bug here... Dell demension 2400 out of the box clean
configuration. At the most inopertune moments the mouse stops
responding, and restarting X or switching to a text console and back
fixes it..

Btw, is there a way to write a script that resets the mouse? Would be
nice to be able to hot key that for on the fly mouse resets.

FYI problem occurs on a clean FC3, also tried with the latest FC4
development kernel (2.6.9-1.1020) which still has the same problem

Without wanting to be just another me too me too reporter, I've seen
this too, with a regular (non wireless) ps2 mouse. So this is not usb
related, it seems to as if X somehow looses sync with /dev/input/mice.

I notice it the most when developing xmame (x.mame.net) especially
when I'm trying out the mouse grab code and or alt tabbing from / to a
fullscreen window (xmame grabs the mouse in fullscreen)

xmame also is normally not cpu friendly, iow it takes whatever amount
of cpu it can get, which could starve the X-server for cpu, which
might be related.

Hans:  thats probably not related.  PS2 is a known problematic
protocol with poor error correction.  You may want to open a new bug.

Another USB Me Too report.  I've got a aging HP XV976 workstation
(circa 1.5 GHz) stuffed with 6 HDs, too many cards, ...  A real
contender for power supply issues (Pete rolls his eyes).

Using fc-devel kernels on a regular basis, I started running into the
same problem.  GPM on console, X, same thing.  As often as every five
minutes.  Just for kicks I tried a different mouse.  I switched from
the HP USB wheel mouse that came with the box to a Targus PAUM004 USB
wheel mouse.  I've not seen the error for 12 hours now.

So the issue is reproducable with 2.6.10-1.1137_FC4 i686

I can provide more information if it would help.

Worldwide introduction date 01-July-2001: US
Model number P5172A
Base processor and speed
Intel Pentium (R) 4/1.5 GHz Processor
*PGA423 ZIF Socket
*400 MHz FSB (Front Side Bus)
Processor maximum upgrade 2 GHz
Chipset Intel 850
250W Power Supply with a squeeky fan and too many internal components
connected.

As said, this seems to happen when X is starved for CPU, couldn't not
reading from /dev/input/mice and thus exceeding the kernelside buffer
for events in /dev/input/mice cause X to loose sync

Related, since ps/2 is such a buggy protocol, wouldn't it be better to
design and implement a new protocol to be emmitted from
/dev/input/mice, one with proper framing so that once sync is lost it
can be automagicly regained?

I can reproduce this problem with a wacom graphire 3 tablet too. It
happens much more often with the tablet using the pen then when using
the mouse. If I move the pen while clicking and holding down any
button on the keyboard it happends about 25% of the time on a click. I
have never seen it if I'm not holding down a key on the keyboard. It
happends with any keyboard. It alse happends when I use the dell mouse
too but less often. Oddly enough simply moving the mouse will bring
the tablet back to life. If I don't have a mouse plugged in as well as
the tablet I have to unplug/replug the tablet to get it working.. 

I am using a Dell precision 260 workstation with ps/2 keyboards and
USB mice/graphics tablets.

For me, it seems to occur most often when I'm moving the mouse while
concurrently holding Control or Alt on the keyboard - enough so that I
doubt it's coincidence.  I'm not sure if this is the same problem or a
different one altogether, nor do I know how to find out.

Hi,

another (more or less): me too.

When pressing a key and moving the mouse it freezes. This mostly happens within
eclipse (java development environment) where you can open a declaration by
pressing ctrl and clicking on a name (e.g. class name).

In most cases removing the mouse (USB, wire) and plugging it back into the
computer helps. (On my notebook I've noticed complete freezes).

My configurations:
2 boxes with kernel 2.6.10, I'm running gentoo linux
First box: Dell Precision 650N, E7505 chipset (dual Xeon)
Second box: Dell Inspiron 9100 (Notebook), 82865G/PE/P chipset

In https://bugzilla.redhat.com/beta/show_bug.cgi?id=124378 it was recommended to
switch off "legacy USB support" in the BIOS. This option doesn't exist on my
notebook (the other box is currently not available). There is another option
called "USB emulation" which should add support for USB devices to operating
systems that have no USB support. Is disabled this feature and it seemed to
help. Currently the problem seems to be gone.

I've upgraded my system to FC4, and the problem actually got worse, not better.
The mouse freezes more often and is becomming a real nuance.. Everytime i want
to move a window or resize my browser it seems to hang (it seems to always be a
combination of moving the mouse while having a mouse button pressed..)

jlaska) are you using a KVM switch for the keyboard and/or mouse?

Is the mouse plugged into a USB<->PS2 adaptor at all?  Just curious because
I have a problem similar to this.  If I plug my USB mouse into a USB->PS2
adaptor, and plug that into my KVM switch, then after I use the mouse
for a short while it just totally dies.  VT switch sometimes resets it.

The problem occurs in WIndows XP on same box too tho, and on different
box, so I assume my problem is entirely in the hardware.

Another thought about this one, (even if others aren't using KVM) is it
could possibly be a USB power issue perhaps.

A confirmation:  after removing USB emulation from BIOS settings, my Dell 
precision thing actually doesn't keep freezing when I do basic things like 
key+mouse. 
 
I recommend trying this (apparently called "USB legacy" support on some 
systems). 
 
Does anyone still have the problem OR have the problem on a non-Dell 
motherboard? 
 
 
  

I am no longer seeing this on FC4 Test2 

mharris: thankfully there was no KVM interaction involved in this defect.  The
mouse was however plugged into a mini hub:

  kernel: usb 1-1: new full speed USB device using uhci_hcd and address 5
  kernel: hub 1-1:1.0: USB hub found
  kernel: hub 1-1:1.0: 4 ports detected

I'm unfortunately a "me too" case, though the way that it occurs strongly
supports the "USB Emulation" BIOS setting messing things up.

I have a Dell GX150 with an Apple USB keyboard and a Logitech USB scroll mouse
plugged into the keyboard. I also plugged in a wireless USB mouse to a USB port
on the front of the computer. When booting with "USB Emulation" on, the BIOS
briefly complains that I should plug all mice and keyboards into the back of the
computer and then boots. When using X, the wireless mouse works perfectly while
the mouse plugged into the keyboard stops working if I don't use it.

When "USB Emulation" in the BIOS is off, both mice work perfectly.

I think that this might be a kernel issue as the kernel should somehow disable
what the BIOS is doing with the USB keyboards and mice, if possible. My system
is a dual-boot Windows XP and Fedora Core 4 system, and the mouse attached to
the keyboard works perfectly in Windows XP despite the "USB Emulation" setting
in the BIOS being enabled.

Because my system is dual-boot and I'm using a USB keyboard, I would really like
to have the "USB Emulation" BIOS setting on so that I can use GRUB's menu to
select the operating system ;-), though that setting messes with the mouse that
is attached to the keyboard. I'll probably remove the mouse that connects to the
keyboard and just use the wireless mouse for now.

If I have time, I'll try to see if this issue is known upstream, if a kernel
patch exists, or possibly create a kernel patch, assuming that the kernel can be
of assistance.

Hmm.. Just after submitting that, the mouse attached to the keyboard stopped
working :-(. The wireless mouse still works. I'm going to see if having the
wireless mouse plugged into the keyboard with the "USB Emulation" BIOS setting
enable can reproduce the issue with this mouse. I'm going to try that because I
remember having this issue come up last night with the Logitech mouse when I
tried plugging it into the front of the computer. Perhaps this issue only
applies to certain types of USB mice? (which doesn't make much sense as others
report that turning off their "USB Emulation" BIOS setting makes it work).

This sounds like a BIOS bug or BIOS configuration issue, or else the kernel
can't handle the BIOS setting for legacy.  My recommendation to people
esperiencing this problem, is to disable legacy emulation in the BIOS
completely and just leave it that way.

Me, too.

As I was installing FC4, in an early screen, the mouse would 'die' if I stopped
moving it.  I could change virtual terminals, move the mouse (under gpm) and
it'd be working again.

It's USB, direct to the machine, not a hub, and no KVM switches are in use here
(they're too Microsoftie for me- I got SSH!).  I'm using an el-cheapo PS/2 mouse
in order to deal with this, for now, and it works without fail.

I noticed, though, the "serio0" code changes that re-wrote the keyboard and/or
mouse handling have gone through changes- not sure if they're related in any
way, though.  I play UT, and a longstanding bug is the 'voice' menu.  Pressing
"V" is interpreted as a keypress, and randomly, a release.  Annoying.  One day
after a new kernel it worked perfectly, unlike every before, but after another
one, it stopped again.  Musta "fixed" it.

I'm currently on a VIA "Twister" or K*-133 machine, pretty vanilla....and the
recent standard kernels didn't show this problem until _after_ the 770 release,
if that helps.

It sure looks like a bug in the USB section, from here...

If you need a lookaround on my system, I'm happy to work something out. 

New clue: (in addition to above)

I just plugged in my old, favorite mouse while my fallback, PS/2 mouse was still
connected.  It worked!  Both do.  The logger looked like this:

Jun 25 05:29:14 aquila kernel: usb 1-1.1: new low speed USB device using
uhci_hcd and address 6
Jun 25 05:29:15 aquila kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse]
on usb-0000:00:07.2-1.1
Jun 25 05:29:15 aquila hal.hotplug[29468]: DEVPATH is not set (subsystem input)

I don't know about the DEVPATH thing, but it works like two steering wheels on a
car...they both move the cursor.  There's nothing new/different here; no
tarballs involved, everything came from the base repos including Dag and Livna.

And, it's not stopped on me at all, where it used to stop every few seconds my
hands were off of it.

Let me know if you want 'in' to take a look.

I'm trying to figure out where to startup a bugzilla entry involving usb kvm's &
usb mice freezing when X is up and switched from one system to another and back.

Its not clearly a rawhide problem. It may possibly be an x.org prob. It only
happens (the mouse is lost, but log events say otherwise) when X is up & I kvm
out from X to another linux or Win2k box and back. 

I've tried multiple flavours of kvm, different mice, have no problems with the
usb mice on linux (kernel 2.6.13-rc2(today)), and am using evdev module, and
have tried 'mouse' and 'evdev' drivers in X. (I tried a backport from 6.2.99 to
see if it worked). 

If I first <ctrl><alt><f2> to a console from X and *then* change sessions to win
and back, gpm seems to catch the mouse fine and it works. I can then
<ctrl><alt><f7> back to X and I"m back in business. Does this say that there's
perhaps some a) problem with x.org, or b) some way of defining the usb kvm (kind
of as you do for a mouse)? 

I've searched bugs.freedesktop.org and don't see any entries on this, and for
that matter, don't see kvm-specific entries here on fedora either. 

Anyway, if anyone has any ideas on the x.org part of this, I'd be very
interested (well any ideas period).

--- log info from boot and kvm switch with my system when it fails ----

Jul  6 14:14:27 Kathaldo kernel: hub 3-0:1.0: USB hub found
Jul  6 14:14:27 Kathaldo kernel: hub 3-0:1.0: 3 ports detected
Jul  6 14:14:27 Kathaldo kernel: usb 2-2: new full speed USB device using ohci_h
cd and address 2
Jul  6 14:14:27 Kathaldo kernel: hub 2-2:1.0: USB hub found
Jul  6 14:14:27 Kathaldo kernel: hub 2-2:1.0: 4 ports detected
Jul  6 14:14:27 Kathaldo kernel: usb 2-2.1: new full speed USB device using ohci
_hcd and address 3
Jul  6 14:14:27 Kathaldo kernel: hub 2-2.1:1.0: USB hub found
Jul  6 14:14:27 Kathaldo kernel: hub 2-2.1:1.0: 4 ports detected
Jul  6 14:14:27 Kathaldo kernel: usb 2-2.2: new low speed USB device using ohci_
hcd and address 4
Jul  6 14:14:27 Kathaldo kernel: usb 2-2.1.1: new low speed USB device using ohc
i_hcd and address 5
Jul  6 14:14:27 Kathaldo kernel: usbcore: registered new driver hiddev
Jul  6 14:14:27 Kathaldo kernel: input: USB HID v1.10 Keyboard [PS2/USB KVM PS2/
USB KVM] on usb-0000:00:02.0-2.2
Jul  6 14:14:27 Kathaldo kernel: input: USB HID v1.10 Mouse [PS2/USB KVM PS2/USB
 KVM] on usb-0000:00:02.0-2.2
Jul  6 14:14:27 Kathaldo kernel: input: USB HID v1.11 Mouse [Logitech USB Receiv


--- when kvm switch is cycled twice back to linux ---

Jul  6 14:18:05 Kathaldo kernel: usb 2-2.1: USB disconnect, address 3
Jul  6 14:18:05 Kathaldo kernel: usb 2-2.1.1: USB disconnect, address 5
Jul  6 14:18:05 Kathaldo hal.hotplug[6362]: DEVPATH is not set (subsystem input)
Jul  6 14:18:13 Kathaldo kernel: usb 2-2.1: new full speed USB device using ohci
_hcd and address 6
Jul  6 14:18:13 Kathaldo kernel: hub 2-2.1:1.0: USB hub found
Jul  6 14:18:13 Kathaldo kernel: hub 2-2.1:1.0: 4 ports detected
Jul  6 14:18:13 Kathaldo kernel: usb 2-2.1.1: new low speed USB device using ohc
i_hcd and address 7
Jul  6 14:18:13 Kathaldo kernel: input: USB HID v1.11 Mouse [Logitech USB Receiv
er] on usb-0000:00:02.0-2.1.1
Jul  6 14:18:13 Kathaldo hal.hotplug[6464]: DEVPATH is not set (subsystem input)
Jul  6 14:18:44 Kathaldo kernel: usb 2-2.1: USB disconnect, address 6
Jul  6 14:18:44 Kathaldo kernel: usb 2-2.1.1: USB disconnect, address 7
Jul  6 14:18:44 Kathaldo hal.hotplug[6578]: DEVPATH is not set (subsystem input)
Jul  6 14:18:52 Kathaldo kernel: usb 2-2.1: new full speed USB device using ohci
_hcd and address 8
Jul  6 14:18:52 Kathaldo kernel: hub 2-2.1:1.0: USB hub found
Jul  6 14:18:52 Kathaldo kernel: hub 2-2.1:1.0: 4 ports detected
Jul  6 14:18:53 Kathaldo kernel: input: USB HID v1.11 Mouse [Logitech USB Receiv
er] on usb-0000:00:02.0-2.1.1
Jul  6 14:18:53 Kathaldo hal.hotplug[6711]: DEVPATH is not set (subsystem input)
Jul  6 14:21:52 Kathaldo kernel: usb 2-2.1.1: USB disconnect, address 9
Jul  6 14:21:53 Kathaldo hal.hotplug[6880]: DEVPATH is not set (subsystem input)
Jul  6 14:22:00 Kathaldo kernel: usb 2-2.1.2: new low speed USB device using ohc
i_hcd and address 10
Jul  6 14:22:00 Kathaldo kernel: input: USB HID v1.11 Mouse [Logitech USB Receiv
er] on usb-0000:00:02.0-2.1.2
Jul  6 14:22:00 Kathaldo hal.hotplug[6912]: DEVPATH is not set (subsystem input)
Jul  6 14:22:00 Kathaldo ntpd[5098]: kernel time sync disabled 0041
Jul  6 14:22:14 Kathaldo hal.hotplug[7001]: DEVPATH is not set (subsystem input)

I have the same issue on a Abit IT7-MAX2 system. USB mouse and USB keyboard are
plugged directly into system (no KVM). Hitting any keyboard key will unblank
screen, but mouse is dead. Doing Ctrl-Alt-F1 then Ctrl-Alt-F7 will bring mouse back.

I don't see any relevant log entries when mouse 'goes away', but upon selecting
VT1 I get: 

Sep 28 12:57:08 fuggles gpm[2647]: *** info [mice.c(1766)]:
Sep 28 12:57:08 fuggles gpm[2647]: imps2: Auto-detected intellimouse PS/2

Didn't have this issue before upgrading from FC3 to FC4. I don't recall which
FC3 kernel I was using. I'm currently at 2.6.12-1.1456_FC4

This bug began affecting me when I upgraded from el3 to el4.  Here's a dmesg 
snippet from my last occurrence:

atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 3-2: USB disconnect, address 2
usb 3-2: new low speed USB device using address 3
input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:1d.1-2

This happens to me on a Toshiba Satellite L25-S1192 laptop when using Firefox.
When I press Ctrl+"left click", in Firefox, to open the link in a new tab, my
mouse _sometimes_ freezes.
So my behavior agrees with other people's when it would freeze with Alt+click,
or Ctrl+Alt+click

Forgot to mention that I am using a freshly installed and fully up to date
Fedora Core 5.

After upgrading to the latest kernel-2.6.16-1.2122_FC5 I can't reproduce this
bug anymore.

I can't reproduce this using 2.6.17-1.2187_FC5.

mjc

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.

With the most recent kernels (2.6.18 based), the problem went away!

A new problem appeared (sata hangs every once in a while now) but i'll save 
that for another bug report :-)

Thanks for the update & attention Dave!

Still a problem on kernel-2.6.18-1.2784.fc6 on the same machine I filed this bug
for.

Is this still an issue?  There's not been any updates in quite some time.

I don't see this problem in f8.

mjc

Haven't seen this in F8, I do not have objections to closing this issue.