Bug 111161 - (KVM-Mouse) kernel 2.6.0-test10 and a KVM cause IMPS/2 mouse to go mad
kernel 2.6.0-test10 and a KVM cause IMPS/2 mouse to go mad
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
: 123273 124371 127431 128038 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-28 12:04 EST by Nic Doye
Modified: 2015-01-04 17:04 EST (History)
15 users (show)

See Also:
Fixed In Version: kernel-2.6.0-0.test11.1.99
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 00:55:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nic Doye 2003-11-28 12:04:09 EST
Description of problem:

Using kernel 2.6.0-test10 from the arjan-2.6-kernel-i386 apt archive
on a PC with a PS/2 KVM attached to it. Switching to another input on
the KVM and back makes the  mouse "go mad" under X and GPM until you
unplug it and re-attach it.

The following error is shown in /var/log/messages too.

kernel: psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost
synchronization, throwing 3 bytes away

Version-Release number of selected component (if applicable):
kernel-2.6.0-0.test10.*

How reproducible:

Every time.

Steps to Reproduce:
1. Scr Lk Scr Lk 2 (to evil empire box)
2. Scr Lk Scr Lk 1 (back to Fedora Core desktop)
3. 
  
Actual results:

Mouse moves in random, unexpected ways. Various pop-ups appear, panel
moves, as if buttons were pressed on the mouse which weren't.

Expected results:

Mouse would continue to work as normal.

Additional info:

This reminds me of what happens if you say that a IMPS/2 mouse is PS/2
(or the other way around, I forget).
Comment 1 Nic Doye 2003-12-16 05:37:29 EST
Fixed in latest kernel versions. Thanks - nic
Comment 2 Nic Doye 2003-12-22 11:52:36 EST
The problem came back in 

kernel-2.6.0-0.test11.1.102

and is still there in

kernel-2.6.0-1.104

so it ain't fixed. Perhaps I only dreamed that it was.


Comment 3 Craig Emery 2004-02-22 13:40:51 EST
I've been following bug #115870 and I think that it might be a
duplicate of this bug. Any thoughts? I still see this bug in
kernel-2.6.2-1.87
Comment 4 Nic Doye 2004-02-23 04:56:26 EST
I think that this bug is now fixed - for me at least.

The kernel parameter has changed again between 2.6.1 and 2.6.2 and now
works. I'm running 2.6.2-1.182 at the moment.

For a Red Hat compiled kernel, the correct parameter is:
psmouse.proto=imps

As far as I'm concerned, this bug can be closed.
Comment 5 Craig Emery 2004-02-23 07:05:43 EST
Okay.
After reading bug #115713, I've tried adding
"psmouse.proto=imps2" as a kernel option to kernel 2.6.2-1.85 and
apart from not being able to use the scroll wheel *UP* (on the Fedora
box), I can switch machines with my KVM just fine.
I could not, however, use kernel 2.6.2-1.87. When using the 1-87
kernel I can't even start X11 (even though rhgb does so just fine).
Actually I lie. :-/ I can start X11 at 800x600 in 16bpp. There seems
to be a problem with the MGA dri module under that kernel (I'll go
looking for a bug soon).

I just wanted to ask: Is the scroll-wheel issue due to the
psmouse.proto kernel option or a separate issue?
Comment 6 Craig Emery 2004-02-23 07:58:58 EST
Actually this hasn't fully fixed the problem; though it looked like it
had.
Now, after I've booted I can switch about on my KVM, but if I leave my
Fedora box for an extended period of time (so far all I can say is
that it's somewhere between a minute and a few hours) then the problem
reoccurs completely.

Thoughts?

Is there anything I could do to give you more information on this?
This is a complete blocker on my using Fedora right now.
Comment 7 Nic Doye 2004-03-02 06:32:42 EST
As an extra datapoint, the same fix works on the same set-up but with
Mandrake 10.0 RC1 replacing the Fedora Core 1.

Also, I assume it's a typo, but you wrote "imps2" instead of plain
"imps" in comment 5 above.

Cheers - nic
Comment 8 Brian "netdragon" Bober 2004-06-21 03:21:15 EDT
See also bug 124371 (dupe?)
Comment 9 Nic Doye 2004-06-21 04:45:51 EDT
Definitely looks like a dupe to me.

And since adding "psmouse.proto=imps" to the kernel fixes it for me at
least (on FC1, MDK 10, FC2), I don't see why this is still open unless
Craig is still having his timeout problem
Comment 10 Craig Emery 2004-06-21 05:19:42 EDT
I'm afraid that I've still got this problem on FC2 (final)
kernel-2.6.5-1.358 with the kernel param as above.
Comment 11 Dave Jones 2004-06-21 08:09:00 EDT
*** Bug 124371 has been marked as a duplicate of this bug. ***
Comment 12 Brian "netdragon" Bober 2004-06-21 16:07:32 EDT
This is open because when you use psmoue.proto=bare with an
Intellimouse Explorer, you can switch but you get no scroll wheel
functionality plus button 4 or 5.

Last I heard, there is work being done in the kernel to fix the
disconnects issue with Belkin switches.
Comment 13 Nic Doye 2004-06-22 05:00:01 EDT
I haven't checked the kernel mailing list since 2.6.1 for this, but I
too have a Belkin switch... (Omni cube 4-port).
Comment 14 Jean-Baptiste Vignaud 2004-06-24 10:00:38 EDT
Same problem for me on FC2 with kernel 2.6.6-1.435 (from fedora) on
X86_64.

Sometimes, physically unplug-plug the mouse restores the correct behavior.
Comment 15 Bernard Johnson 2004-07-02 12:46:31 EDT
Is there any kind of work-around short of rebooting the affected box?  

I had a somewhat similar problem under 2.4 series kernels, but
switching to a VT and back would reset the mouse.  This no longer
works under 2.6.  I hear that unplugging the mouse from the KVM works
as well, but digging through the cables is even worse than a reboot.

By the way, I've tried all the mouse.proto= settings, and none keep
this from happening.

kernel 2.6.6-1.435
Belkin OmniView SE 4 port
Comment 16 Brian "netdragon" Bober 2004-07-02 22:23:32 EDT
Bernard: Its psmouse.proto=bare
Comment 17 Brian "netdragon" Bober 2004-07-07 16:58:31 EDT
The kernel guys have apparently fixed this. Can their patch be put
into the next Fedora kernel release?

http://bugme.osdl.org/show_bug.cgi?id=2082
Comment 18 darkness 2004-07-12 01:16:49 EDT
I think I'm seeing this bug, except I don't have to switch to another
KVM port first.  I get erratic mouse behavior (move mouse slightly,
jumps all over screen and clicks randomly) from both X and gpm.
Connect/reconnect mouse doesn't seem to work.  psmouse.proto=bare
works, but is unacceptable as it kills the mouse wheel.  2.6.5-1.358
WORKS with psmouse.proto=exps and ExplorerPS/2 as the mouse type in
X11.  2.6.6-1.427, .435, .435.2.1, and .435.2.3 all do NOT work with
psmouse.proto=exps: I just get the same erratic behavior I get without
specifying psmouse.proto.  I did a "quick" build of 2.6.6-1.435.2.3
with the patch at http://bugme.osdl.org/show_bug.cgi?id=2082, but
I just get the same behavior as in that bug's comment 16: constant
messages about resetting the mouse, little or no movement most of the
time, but an occasional cursor jump.  I'm on x86, Belkin OmniView SE
PS/2 (model F1D074), MS IntelliMouse Explorer 2.0A.

Should I report this on the kernel bug?  I'm not sure it's applicable
since I'm not running a stock kernel.
Comment 19 Marko Macek 2004-08-15 13:26:35 EDT
darkness: can you try my patch (linkes) in bug 115713.
Comment 20 Sam'l Bassett 2004-08-17 04:15:45 EDT
I have a Linksys 4-cpu switch, and a Logitech cordless trackball.  The
mopuse works fine in Linux 2.6.5-1.327 #1 Sun Apr 18 04:51:55 EDT 2004
i686 athlon i386 GNU/Linux, but every higher version of 2.6 shows the
erratic mouse behavior described above in #18.
Comment 21 Mike Housky 2004-09-04 11:54:52 EDT
I have seen this symptom occasionally, particularly while installating
FC2.  It also happens sometimes on a fully-up2date-ed FC2 running the
Gnome desktop.  It's rare, but sometimes when I switch the KVM to the
Linux box, I get a mouse pointer jumping wildly--mostly along the
right and top edges of the desktop--with any mouse motion.  The mouse
buttons, however, seem to operate normally.  If I get the mouse
pointer onto a bit of clear desktop, I can right-click to launch a
popup context menu, for example.

This happens very rarely with the KVM switch, but I have found another
way to produce the same symptoms every time.  If I press the soft
power button to force a suspend state, then wake the system up *with
the keyboard*, then I get what appears to be the same state.

(When I woke the system up with the mouse, I got no mouse function at
all after wakeup--just a frozen silhouette of a mouse pointer.)

This is an old P2/P3 MB, so maybe its power management support isn't
quite right.  Does anyone else here get this symptom on suspend?
Comment 22 darkness 2004-09-06 10:31:43 EDT
Marko, I tried the patch linked by you from bug 115713 against Fedora
Core 2 kernel-2.6.8-1.521 sources.  The patch did not work with
psmouse.proto=exps: I still experienced erratic mouse behavior (tested
with gpm -t imps2, actually, so if you think I need to put exps2 in
there I'll reboot and try again).  Stock kernel-2.6.8-1.521 works fine
with psmouse.proto=imps, as did the past few kernel versions, so I
didn't try testing your patch with imps.
Comment 23 Brian "netdragon" Bober 2004-09-06 19:13:39 EDT
Cannot scroll up with mousewheel after switching back on Kernel
2.6.8-1.521, psmouse.proto=imps.
Comment 24 Brian "netdragon" Bober 2004-09-07 10:56:27 EDT
Another thing I noticed is that if I do this:

1) Switch to a different system before you boot the system with the
intellimouse
2) Boot the system with the intellimouse without it switched on
3) Wait till you think its done loading into X Windows
4) Switch back

I ALWAYS get erratic mouse behavior.
Comment 25 Brian "netdragon" Bober 2004-09-07 18:17:12 EDT
I tried the fix, and it works. By the way, what I mentioned in the
previous comment, I noticed was just random luck. It doesn't really
matter if I have this particular computer switched on or not when
booting. Its just sometimes you can switch without the desynch happening.

A fix is in the patch from
http://bugzilla.kernel.org/show_bug.cgi?id=2082 works. Thanks to
Dmitry Torokhov for the fix. When will this patch appear in Fedora?

I'm giving the process I followed to use the patch below on how to use
it. If you haven't ever recompiled the kernel, you might not wanna
mess with it. 

It'll take a few seconds, I've found, before you can use the
mousewheel to scroll up, but it still does work after the reconnect
request.

If you know how to compile the Fedora 2 kernel, then you're all set.
Otherwise, what you need to do is (don't run each instruction without
knowing what it does... You can really screw up your system if you
don't know what you are doing). You can replace 2.6.8-1.521 with
whatever in each instruction. I'm wondering why you can't use the
default /lib/modules/2.6.8-1.521 when building 3rd party drivers such
as nvidia after the following instructions (and have to tell it to use
usr/src/linux-2.6.8-1.521 instead). Is there some trick that I'm missing?:

1) download the kernel source (for kernel-2.6.8-1.521, you'd use "yum
install kernel-sourcecode")
2) cd /usr/src/linux-2.6.8-1.521 
3) pushd drivers/input/mouse
4) download patch from http://bugzilla.kernel.org/show_bug.cgi?id=2082
5) mv location/to/the/patch/you/just/downloaded ./diff.txt
6) patch -p4 < diff.txt
7) popd
8) cp /boot/config-2.6.8-1.521 .config (replace
kernel-2.6.8-i686.config with the correct architecture)
9) mv Makefile Makefile.bak
10) cat Makefile.bak | sed s/custom// > Makefile
11) make (just press enter for all the questions)
12) tar -cf /boot/2.6.8-1.521.bak.tar /boot/*-2.6.8-1.521* 
 Make sure the following 4 files are backed up into the archive.
You'll need them later if things don't go well: 
System.map-2.6.8-1.521 config-2.6.8-1.521   initrd-2.6.8-1.521.img 
vmlinuz-2.6.8-1.521
13) tar -cf /lib/modules/modules-2.6.8-1.521.bak.tar
/lib/modules/2.6.8-1.521
 Make sure that the contents of the archive are the same as
/lib/modules/2.6.8-1.521
14) make bzImage
15) cp System.map /boot/System.map-2.6.8-1.521
(yes to overwrite)
16) cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.8-1.521
(yes to overwrite)
17) make modules
18) make modules_install
19) mkinitrd /boot/initrd-2.6.8-1.521.img 2.6.8-1.521
20) Now.... You'll need to rebuild Nvidia and any other 3rd party
modules... For some reason, you need to tell it not to use its default
source directory of /lib/modules/2.6.8-1.521 (If anyone knows why that
is, please tell me). I did this:

./NVIDIA-Linux-x86-1.0-6111-pkg1.run --kernel-source-path
/usr/src/linux-2.6.8-1.521



21) And then reboot.


Now when you switch back and forth, you should occasionally see
something like this in dmesg:

psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched.
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4
psmouse.c: Wheel Mouse on isa0060/serio1 reports too many errors,
issuing reconnect request
Comment 26 Panu Matilainen 2004-09-08 01:18:20 EDT
Just a "me too" - the patch from
http://bugzilla.kernel.org/show_bug.cgi?id=2082 restores mouse sanity
with this cheapo kvm of mine.

I'm afraid the answer "when this will be fixed in FC" is "when the
patch gets into upstream kernel" however.
Comment 27 Mike A. Harris 2004-09-15 01:27:18 EDT
*** Bug 128038 has been marked as a duplicate of this bug. ***
Comment 28 Mike A. Harris 2004-09-15 01:27:42 EDT
*** Bug 127431 has been marked as a duplicate of this bug. ***
Comment 29 Mike A. Harris 2004-09-15 01:29:08 EDT
*** Bug 132471 has been marked as a duplicate of this bug. ***
Comment 30 Mike A. Harris 2004-09-21 05:52:26 EDT
*** Bug 123273 has been marked as a duplicate of this bug. ***
Comment 31 Brian "netdragon" Bober 2004-09-25 18:20:50 EDT
I guess I felt like punishing myself, and after I got the Intellimouse
working with the KVM switch, I replaced the Intellimouse and Intillkey
with the Logitech Cordless Elite keyboard and MX700 wireless mouse,
and now sometimes it freezes (filed bug 3461), other times it goes
crazy and gets picked up by this patch properly. Why does it freeze
sometimes and not others?
Comment 32 Brian "netdragon" Bober 2004-09-25 18:24:08 EDT
Sorry, bug 133616 and kernel bug
http://bugzilla.kernel.org/show_bug.cgi?id=3461
Comment 33 Tom Van Vleck 2004-12-02 21:15:11 EST
I just installed FC3, and this bug is still present.
I am using 
- generic 2 button PS/2 mouse (from a JavaStation)
- Belkin 4 port switch
- Dell Latitude J650

System installed fine.  Installed all updates and rebooted.
Still fine. Then I switched away to another
machine and back.  Crazy mouse.  Managed to get terminal
up and shut to single user mode.

This was working in FC2.

Comment 34 Barrey Jewall 2004-12-03 19:21:26 EST
 I can confirm this occurs during initial install of FC3.

Using:
 - Microsoft Wheel Mouse Optical USB and PS/2 compatible
 - Belkin 4-port PS/2 KVM, Model# F1D066 
 - PIII/450 and Daewoo CB650M-BX mobo.

Note: The workaround mentioned, unplug and re-plugging the mouse from
the KVM, seems to work, but is not quite where we want to be...
Comment 35 Dave Jones 2005-04-16 00:55:07 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.
Comment 36 Chris Hapgood 2006-02-03 10:44:34 EST
I am experiencing the erratic mouse behavior using FC4 (kernel 2.6.14-
1.1653_FC4smp) and a Microsoft Intellimouse and a Belkin OmniView SOHO 4-port 
PS/2 KVM.  I have added no kernel parameters at boot.  My xorg.conf specifies 
the IMPS/2 protocol.

Is there a current bug for this problem?  This bug is closed/next version.  I 
think FC4 would qualify as next next version, but the bug remains.

Is there are workaround that does not sacrifice mouse functionality?  If not, 
what workaround retains the most functionality?

-Chris Hapgood

Note You need to log in before you can comment on or make changes to this bug.