What kernel version do you have, which xorg-x11 version are you using,
and could you attach your xorg.conf?  Thanks.

Created attachment 103831 [details]
Xorg configuration file

2.6.8-1.541smp
xorg-x11-6.7.99.903-6

Note that the xorg.conf file attached above has composite and the
nvidia driver turned on.  This has no bearing on the bug as I was
still seeing it with the open source "nv" driver and composite turned off.

*** This bug has been marked as a duplicate of 111161 ***

Mike, are you sure about the duplicate?  John doesn't mention any KVM
switch, and bug #111161 is all about problems with KVM switches...

No KVM switch here.  Mouse is resored when I do a ctrl-alt-F1 to a
console and then an alt-F7 to come back to X.  I am directly connected
to the PS/2 port.

The problem in bug 111161 is the mouse going out of sync with the
driver in the kernel, which is frequently caused due to KVM switches
dropping data when switching between hosts.  The same problem can
occur without using a KVM however for various reasons, which is what
I suspect is happening here.  In other words, 2 different cases,
same net result of the kernel driver going out of sync with the mouse.

X just reads what the kernel hands it now, so this is most likely
a kernel driver issue.  Please test the latest kernel which fixes
the problem for KVM case by detecting out of sync data and resetting
the mouse.  This should fix similar problems caused without KVM
switch as well.  If not, please attach /var/log/messages from time
of boot onward.  Make sure you are using the "nv" driver and not
using the proprietary nvidia driver at all however.  The problem
is probably reproduceable with both as you say, but using the
proprietary driver invalidates all log file data and will probably
end up with kernel developers ignoring the bug report completely.
By using the supported driver, your log file and troubleshooting
data is valid configuration, and wont get overlooked.

I see exactly the same bug too (not using any KVM) with DELL usb mouse
(imps protocol).

I don't see how upgrading to latest kernel could help as the patch
from http://bugzilla.kernel.org/show_bug.cgi?id=2082 isn't there yet.

But how I look at the patch I think it's rather a workaround
(resetting the communication after getting out of sync packets). What
would be better if someone could find the real reason why it gets out
of sync on normal usb mouse without KVM. 

What I've noticed - the cursor freezes mainly when I begin cursor
movement and in the same time there is some processing - such a heavy
javascript and redrawing in mozilla window or so.

Created attachment 104076 [details]
/var/log/messages since boot

It happened again with the latest kernel build 2.6.8-1.581smp.	Attached is the
output of /var/log/messages from time of boot.	Ignore the kernel OOPS as it is
just me debugging a problem with a USB memory stick.

*** Bug 134907 has been marked as a duplicate of this bug. ***

I understand my bug has been labelled as a duplicate of this one.
However, I am not sure it is. 

I can reproduce my bug 100% of the time. It is VERY easily reproduced.

This bug states "sometimes" reproduceable. Title of this bug is
"random". There is nothing random about my issue.

Furthermore, my mouse only hangs when I play the two Open GL games I
mentioned. I have not been able to reproduce the error in other ways.

Also, I am using USB. This bug mentions PS2 mouse.

Related? Maybe. Same? I don't know.

All mice are configured to use the kernel /dev/input/mice device,
including USB, PS/2, etc.

[X Devel team comment]

What I believe is going on here, is that the mouse protocol
stream is going out of sync for various types of mice, and the
kernel driver is not detecting this and reseting the mouse.

I believe this is a kernel issue.

Me too :-) Using kernel 2.6.8-1.624 which was just post FC3t3 I'm
getting bitten hard by this. Also in use is a Belkin KVM. Problem does
not manifest itself in other releases or OS's. This bug does not seem
to be on the blocker list for FC3 but it sure renders the system
almost unusable and should be a blocker. If it helps I've got a system
in my cube in Westford that reproduces this.

In my instance cursor motion is maintained but button events are lost.
Not much good if you can move the pointer but not click on anything.

I'm also seeing the following error message in /var/log/messages:

drivers/usb/input/hid-input.c: event field not found

Just added to FC3Blocker

Indeed, this appears to be a kernel regression.  Reassigning to the
kernel component.

Well, I may have solved my bug. I took one more try at it and made 2
changes...

1) Updated BIOS from A04 to A07 for Dell Dimension 8300
2) Disabled PS2 mouse port

I would imagine the BIOS upgrade may have been the issue.

After making these two changes, I am no longer able to reproduce the
"bug". I played DOOM3 for 30 min, and UT2004 for over 1 hour without
an issue with the mouse. Previously, I could not play either for 5 min
without the mouse hanging.

If you are running Dell hardware, I would recommend the BIOS update. :)

If I am able to reproduce the bug in the future, I will post again to
this thread.

I have not been able to discern a pattern yet, however Kevin's comment
#17 provoked an observation with respect to my configuration. There
are both PS2 and USB pointing devices. Let me elaborate:

The Belkin KVM supports both PS2 and USB. The keyboard and mouse
attached to the KVM are PS2. The connection running to the system is
USB. The system has both PS2 and USB, although the PS2 connectors are
unpopulated. The KVM also makes some PS2 connections to other systems.

If I remove the KVM USB connection and replace it with a direct PS2
(no KVM, plug the keyboard and mouse directly into the PS2) I do not
see problems.

I should probably test with both USB and PS2 simultaneously connected,
but have not yet. I wonder (speculate) if there could be some USB vs.
PS2 problem occuring. Just a thought ...

Here is one more datapoint. With BOTH a PS2 and a USB pointing device
attached the problem has not manifested itself in limited testing
(Note: it can sometimes be difficult to provoke the problem so this
info may have limited value). This would suggest the problem seems to
occur when the PS2 port is unoccupied, but a USB pointing device is
present.

Please test with USB legacy support in the bios turned off. 

I've been seeing similar symptoms; perhaps once a day on average (USB
mouse, mixture of FC2 and various haphazard rawhide updates, I'm
afraid); adding myself to the CC.  Kristian, if you want to
investigate my system further if/when I get it to recur, I'm in the
cube next to yours...

Dave  - See comment #20,  test and report.

Bug 135224 and Bug 114765 related to this? 

I have an smp box at home I can recreate 135224 on repeatedly and
easily (works with UP kernel).

See comment #20, test and report.

If nobody does this soon I'm going to have to close the bug as
"WONTFIX" because nobody is providing any needed data.

Alan asked what happened if legacy USB support was turned off in the BIOS. On
the machines I'm seeing this on, HP XW series, there is no BIOS option to
disable legacy USB support. The closest thing I found was "ACPI S3 PS2 Mouse
Wake Up" given that my observation has been this is some type of interaction
between USB and PS2 (only a half baked theory). There is a BIOS option to
disable "ACPI S3" entirely which includes the PS2 Mouse Wake Up.

I have two similar HP XW boxes. I disabled ACPI S3 on both. The random mouse
jumping (bad mouse protocol framing???) initially seems to be eliminated.
However, button events are still being lost. I'm not entirely certain the change
in the BIOS setting really did have positive effect simply because it can
sometimes be hard to reproduce reliably. Hmm...

FWIW, I tried cat on /dev/input/mouse* and /dev/input/event* to see if raw mouse
events were being seen. Not really understanding the relationship between these
devices. I have the following device nodes in /dev/input: mouse{0,1} and
event{0,1,2,3}. For the mouse devices only mouse1 generates any visible data
(only mouse movement). For the event devices only event3 produces any visible
data (both movement and button clicks). The user experience with X is that mouse
movement occurs but no button clicks. Could this be a problem where the device
numbers aren't paired correctly (mouse1 to event3?) (should they be pairwise
equivalent?). I do have an error message in /var/log/message to this effect:

drivers/usb/input/hid-input.c: event field not found

Follow up. Disabling ACPI did NOT solve the problem of random mouse movements
and click events (bad protocol framing?). After rebooting the box mentioned
above again the problem was back with a vengenance, apparently I had just gotten
lucky before :-(

Created attachment 106823 [details]
/var/log/messages showing Kernel Call Trace

update to Alan Cox comment#20... the system ltroan has that is experiencing the
problem hsa the following options set in the BIOS: 

 - Legacy USB KB/Mouse support - disabled
 - USB Passive Release - enabled.

In poking around on the system I stumbled upon 2 Kernel Call Traces.  If these
are seperate issues please advise and I will file them seperately.  Currently,
using the exact same configuration as ltroan had I am not seeing the problems
with RHEL4-Beta2.  I'm going to touch base with ltroan this afternoon to ensure
I'm correctly reproducing the observed failure scenario.  I will post back this
afternoon ... (please advise on the attached kernel call trace)

Not sure if it will help, but I have two systems here in Westford that
with a little patience can be made to reproduce the problem.

Very useful. The traces look like memory corruption problems (ditto
the few messages before about invalid char 0x6 in login name). Looks
like you hsve an X session exit causing corruption bug precisely like
the thinkpads. Please file, include detailed hw info, mark it high and
assign to the Xorg packahge for the moment (its probably joint X/Kernel)

Should this really be in NEEDINFO?

Does the assigned field reflect who's working on it?

AFAICT we currently believe this is a dup of 138348. I'm going to take
it out of NEEDINFO, as I can't tell who it's blocking on for info.

In comment #33, Alan stated:

> Please file, include detailed hw info, mark it high and
> assign to the Xorg packahge for the moment (its probably
> joint X/Kernel)

Nobody has provided detailed hardware info since then, which
I believe is the reason this is in NEEDINFO.

This seems to be a hardware specific issue of some sort, so
having details is probably a prerequisite to software debugging.

Alan/Kristian, could you specify what information you'd like
to see attached?

I am experiencing a more severe loss of mouse functionality with
Fedora Core 3 that I did with FC2.

When I switch between two machines, I must physically reset the
mouse(pull the mouse's ps2 connector out of the belkin and back in) to
get useage.

Under FC2 and below, I could clt-alt-F1 out to a console and back to
reset the mouse.

What information or testing should I do to assist with this issue?

Ditto, I am seeing this issue. I see a loss of the mouse while 
using the computer, and mouse is DOA after switch of the KVM. 

What information should I provide? 

Well, at the suggestion of the fedora-test list, I replaced my optical
MS mouse(USB with PS2 adapter) with a standard PS2 mouse.  I switched
back and forth on my machines and it doesn't lose track of the mouse
any longer.

What do you think of this?

With respect to comment #41, removing mouse connected with USB --> PS2
adaptor to straight PS2 and interesting observation. My Belkin KVM
supports both PS2 and USB, the attached keyboard and mouse are PS2,
however the system sees the devices as USB at the other end of the
KVM. Thus there is a PS2 to USB conversion in effect (although if I
understand comment #41 correctly we have conversion occuring in
opposite directions). As I observed and reported above direct PS2
connections eliminate the problem. I wonder if the PS2 <--> USB
conversion should be the focus of further investigation. It might be
easy to blam the external conversion as the culprit if it were not for
the fact the problem only manifests itself in FC3 which strongly
suggests a software regression.

Is anyone still seeing this without KVMs, or are all the problems
involving KVMs at this point?  I haven't been able to reproduce this
without a KVM.

I am no longer seeing this issue reported by ltroan

No problems on my machine without KVM anymore.

I spoke to Dave Malcolm and John Palmieri who have also seen the
problem without a KVM, and they both report that the issue seems to
have gone away.  John Dennis is using a KVM and still sees the
problem, but it's typically triggered by either booting og switching
computers on the KVM. This bug is about the mouse spontaneously
freezing, and at this point I think that is fixed and the KVM issue is
a duplicate of bug #111161.

I'll leave the bug open a couple of days, if anybody is still seeing
the spontaneous freeze without KVM, please say so.

Thanks,
Kristian

This bug seems to best describe my problem.  Ever 24-48 hours my mouse stops
responding.  I can usually (but not always) ctlr-alt-f1 or ctrl-alt-bcksp my way
out of the problem.  This occurs when the keyboard/mouse are both attached via
USB *and* it also occurs when both are attached via PS/2.

Like J. Palmeiri, I see these three lines at the end of /var/log/Xorg.0.log
after the problem occurs:
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) NVIDIA(0): Setting mode "1024x768"
(II) Mouse0: ps2EnableDataReporting: succeeded

I also do see the hid-input.c message in /var/log/messages:
Jan 24 12:43:31 200 kernel: drivers/usb/input/hid-input.c: event field not found

[root@200 ~]# rpm -q xorg-x11
xorg-x11-6.8.1-12.FC3.21
[root@200 ~]# uname -a
Linux 200.162.226.129.user.ajato.com.br 2.6.10-1.741_FC3 #1 Thu Jan 13 16:38:22
EST 2005 i686 i686 i386 GNU/Linux

Motherboard is an ASUS P4V8X-X bios revision 1.004.

I have not tried to run the machine with USB legacy support turned off in the
bios, I will try and report back.

Mouse still freezes with USB legacy support turned off in the BIOS. 
What did you guys do to fix this?