Bug 2082 - psmouse, mouse out of control after switching with KVM switch, requires reboot
Summary: psmouse, mouse out of control after switching with KVM switch, requires reboot
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Dmitry Torokhov
URL:
Keywords:
: 1255 3004 4469 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-12 02:55 UTC by Mauro M.
Modified: 2014-03-03 22:38 UTC (History)
24 users (show)

See Also:
Kernel Version: 2.6.27
Tree: Mainline
Regression: No


Attachments
Issue reconnect after 'psmouse.resetafter' partial packets (2.73 KB, patch)
2004-06-17 05:47 UTC, Dmitry Torokhov
Details | Diff
Strict PS/2 protcol enforcement (5.58 KB, patch)
2004-06-24 05:20 UTC, Dmitry Torokhov
Details | Diff
The photo I took of jibberish (334.07 KB, image/jpeg)
2004-09-07 17:01 UTC, Brian 'netdragon' Bober
Details
Modfied patch for 2.6.8.1 (speeded up by removing logging) (26.77 KB, patch)
2004-09-26 08:20 UTC, Mauro M.
Details | Diff
imps2 busmouse resync patch for kernel 2.6.9-rc4 (6.44 KB, patch)
2004-10-17 03:28 UTC, Mauro M.
Details | Diff
periodically poll devices to detect disconnects (4.18 KB, patch)
2004-10-26 15:19 UTC, Dmitry Torokhov
Details | Diff
Periodically poll devices v.2 (4.27 KB, patch)
2004-11-02 16:57 UTC, Dmitry Torokhov
Details | Diff
Periodically poll devices v.3 (4.21 KB, patch)
2004-11-24 15:34 UTC, Dmitry Torokhov
Details | Diff
i8042 debug messages on Dell I8200 (27.83 KB, text/plain)
2005-01-17 14:59 UTC, Martin von Gagern
Details
PS2 mouse resync for kernel 2.6.10 (and hopefully higher) (2.53 KB, patch)
2005-02-17 11:13 UTC, Mauro M.
Details | Diff
PS2 mouse resync for kernel 2.6.10 (and hopefully higher) (6.93 KB, patch)
2005-02-17 11:25 UTC, Mauro M.
Details | Diff
resync-after-idle.patch (6.79 KB, patch)
2005-05-02 23:59 UTC, Dmitry Torokhov
Details | Diff
resync-after-idle-v2.patch (11.80 KB, patch)
2005-05-06 10:41 UTC, Dmitry Torokhov
Details | Diff
linux-2.6.12-imps2resyncIdle.patch (12.27 KB, patch)
2005-07-31 11:12 UTC, Mauro M.
Details | Diff
resync-after-idle-v3.patch (17.26 KB, patch)
2005-12-21 22:20 UTC, Dmitry Torokhov
Details | Diff
dmesg dump 1, the mouse stopped responding for ~0.3 sec (15.37 KB, text/plain)
2006-02-14 14:21 UTC, Lukas Sandstr
Details
Three mouse-freeze events. (46.08 KB, text/plain)
2006-02-14 14:24 UTC, Lukas Sandstr
Details
Mouse lock-up again (15.36 KB, text/plain)
2006-02-15 13:35 UTC, Lukas Sandstr
Details
Mouse lockup from before the event (62.60 KB, text/plain)
2006-02-15 13:59 UTC, Lukas Sandstr
Details
Force resync at open (1.57 KB, patch)
2007-03-12 15:06 UTC, Dmitry Torokhov
Details | Diff
A patch to reset PS/2 mouse after KVM switch (917 bytes, patch)
2007-10-26 18:23 UTC, H.J. Lu
Details | Diff
The kernel log before and after KVM switch (5.25 KB, application/octet-stream)
2007-11-02 09:09 UTC, H.J. Lu
Details
A patch to reset PS/2 mouse (1.90 KB, patch)
2008-03-13 18:32 UTC, H.J. Lu
Details | Diff
An updated patch to reset PS/2 mouse (1.90 KB, text/x-patch)
2008-03-18 07:51 UTC, H.J. Lu
Details

Description Mauro M. 2004-02-12 02:55:06 UTC
Distribution: SuSe 9
Hardware Environment: Dell Inspiron 8200 Laptop
Software Environment: XFree and gpm
Problem Description: When switching to another machine with a KVM switch and
back, the mouse is out of control, both with XFree and gpm. In kernel 2.4
switching (Ctrl-Alt-F1) to a character console and back to XFree solved the
problem for IMPS/2 mouse protocol. From kernel 2.6.0 onwards the trick don't
cure the problem anymore. Unloading and reloading the psmouse module also do not
fix it. To recover mouse usage it is necessary to reboot.

Steps to reproduce: Have a mouse connected using protocol IMPS/2 and either gpm
or XFree. Keyboard, Mouse and Video are connected to a KVM switch. Switch to
another machine and back. You have lost the mouse control.
It should occurr also by simply unplugging the mouse cable and plugging it back.
Comment 1 Mauro M. 2004-02-26 04:11:56 UTC
Kernel 2.6.3 has the same problem.
Comment 2 Mauro M. 2004-02-28 11:32:37 UTC
Tested on Dual Pentium III configuration, the same problem applies
Comment 3 Mauro M. 2004-03-18 10:14:27 UTC
Tested on kernel 2.6.5-rc1, same problem.
In addition shutting down the X server or the gpm service and restarting them
does not work around the problem. To regain control of the mouse a reboot is
necessary (is this Linux or Windoze? :-).
Comment 4 Vojtech Pavlik 2004-03-18 11:12:38 UTC
From the Input FAQ:

Problem:
~~~~~~~~

When I switch my KVM, my PS/2 mouse goes all crazy.

Solution:
~~~~~~~~~

Use psmouse.proto=bare on the kernel command line, or proto=bare on the
psmouse module command line.
Comment 5 Mauro M. 2004-03-18 16:06:34 UTC
The suggested solution disables the IMPS/2 mouse protocol. Although the problem
does not show anymore by setting the suggested parameter, the mouse wheel is
disabled. Not a real solution. 
Comment 6 Vojtech Pavlik 2004-03-18 22:41:54 UTC
Have you tried psmouse.proto=imps? If your KVM (and the other machine) supports
the IMPS/2 protocol, then that should work, too.
Comment 7 Mauro M. 2004-03-20 04:52:00 UTC
Tried with psmouse.proto=imps (and =exps). The mouse control is lost after
switching with the KVM and back (KVM certified Windoze and Linux compatible).
Restarting X or gpm does not solve the problem, an OS restart is necessary. The
problem also occurs by disconnecting and reconnecting the mouse plug. It does
not occurr with other operating systems (including kernel 2.4).
In addition in kernel 2.4 it was not necessary to set a kernel parameter. Having
to do so in 2.6 reduces Linux useability out of the box.
Comment 8 Mauro M. 2004-03-20 07:37:49 UTC
After having seen the following comment in linux-2.6.5-rc2 changelog:

<vojtech@suse.cz>
	input: Fix "psmouse: Lost sync" problem. It was really losing sync.

I have applied the patch. I am afraid the same problem applies (lost mouse
control, requires system reboot).
Comment 9 Mauro M. 2004-03-31 09:57:28 UTC
Same problem on kernel linux-2.6.5-rc3
Comment 10 Mauro M. 2004-04-14 11:16:24 UTC
Same problem on kernel 2.6.5. I give up working with kernel 2.6.
Comment 11 Wolfgang Thiess 2004-06-17 04:23:44 UTC
Problem still exists on kernel 2.6.7. 
 
My mouse is an optical Logitech M-BJ69 wheelmouse. The cable has a USB 
connector, and the mouse is delivered with a USB to PS/2 Adaptor. I use this 
kind of mouse on many different computers in PS/2 mode (imps/2 protocol). It 
even works well with my KVM switch using MS-Windows or Linux kernels 2.4.x. 
Using kernel 2.6.x I encounter the same problems. 
 
When I connect a Microsoft mouse (it has a label "Microsoft Port Compatible 
Mouse 2.1A, Microsoft Corporation), everything works fine - except that mouse 
isn't optical and has no wheel. This mouse uses the ps/2 protocol. On 2.6.x 
kernels there is no entry in kernel command line needed. It just works as 
expected. 
 
Maybe the problem has something to do with the imps protocol? 
Comment 12 Dmitry Torokhov 2004-06-17 05:47:20 UTC
Created attachment 3193 [details]
Issue reconnect after 'psmouse.resetafter' partial packets 

Could you guys please try the attached patch. It will count every partial
packet towards out-of-sync limit and when that limit is exceeded the kernel
will issue reconnect request and will try re-negotiate the protocol. Right now
the limit is somewhat conservative, if your mouse does not lose sync except
when you switch your KVM you may want to set psmouse.resetafter kernel
parameter to be 2 or 3.
Comment 13 Wolfgang Thiess 2004-06-24 04:11:39 UTC
silent linux-2.6.7 # patch -p1 < ~/psmouse-base.diff 
patching file drivers/input/mouse/psmouse-base.c 
Hunk #2 succeeded at 178 (offset -11 lines). 
Hunk #3 succeeded at 211 (offset -11 lines). 
Hunk #4 succeeded at 226 (offset -11 lines). 
Hunk #5 FAILED at 298. 
1 out of 5 hunks FAILED -- saving rejects to file 
drivers/input/mouse/psmouse-base.c.rej 
silent linux-2.6.7 # 
 
Did I something wrong? I currently use kernel 2.6.7 from kernel.org without 
further patches. 
 
Dimitry, if you can send the psmouse-base.c by mail I'll test it. 
 
Comment 14 Dmitry Torokhov 2004-06-24 05:20:19 UTC
Created attachment 3244 [details]
Strict PS/2 protcol enforcement

Ok, the previous patch was bogus (aside from being diffed against my private
tree). Could you please try this one? The mouse should resync on its own but
you can also try holding left+middle or right+middle buttons and move the mouse
to force resync.
Comment 15 K Drummond 2004-06-25 00:03:09 UTC
I've tested the patch (id=3244) and can confirm that it works on kernel 2.6.7-r6
(Gentoo).  I can now switch back to Linux and the mouse resets and retains
scroll wheel support.  I do have psmouse.proto=imps as a kernel parameter.

dmesg spits out this everytime I switch back to Linux:
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 1
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 1
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 1
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 1
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 1
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 1
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 1
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

However, like I said, mouse and wheel still work after switching back.  Hope
others have the same success!
Comment 16 Wolfgang Thiess 2004-06-26 06:42:18 UTC
Result with Patch id=3244 is (last lines in dmesg) 
 
No kernel boot parameter: 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 - driver resynched. 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost sync at byte 4 
 
Kernel boot parameter psmouse.proto=imps: 
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 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 - 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 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 - 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. 
 
I switched my KVM to the computer I used for this test, booted the computer 
and did not switch the KVM again. 
 
When moving the mouse, the cursor doesn't move most of the time. Sometimes it 
moves a short distance (1 or 2 centimeters), sometimes it jumps to a very 
different location on screen. The mousekeys don't work. 
 
I can't see a difference from the behaviour without patch. 
 
Comment 17 Mauro M. 2004-07-02 10:50:36 UTC
I have tested the patch on kernel 2.6.7 an it works! There is a slight delay
when the mouse is out of control before resync, however this patch makes the 2.6
kernel really usable.

I hope that this will be included soon in the official kernel distribution.

Many, many thanks Dmitry!

Mauro
Comment 18 Panu Matilainen 2004-08-25 07:44:08 UTC
Ok confirmed that this fixes the problem with my Bel*** KVM as well. The mouse
goes a bit berserk for a moment after switching before it gets reseted but that
I can easily live with, much better than it ever was with 2.4 kernels where I
had to switch away and back to X to reset the mouse. Thank you!

The code isn't present in 2.6.8 (that's what I tested this on, FYI) - has this
been sent upstream yet? If not, pretty please do so :)
Comment 19 Brian 'netdragon' Bober 2004-08-29 14:59:55 UTC
It goes berserk on Windows too. Its probably a result of the polling frequency
being low.
Comment 20 Anno v. Heimburg 2004-09-07 08:56:56 UTC
*** Bug 3004 has been marked as a duplicate of this bug. ***
Comment 21 Brian 'netdragon' Bober 2004-09-07 17:01:06 UTC
Created attachment 3645 [details]
The photo I took of jibberish

It worked! Excellent job. Tested the patch on Fedora Core 2 using the method I
put in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111161#c25

I could use psmouse.proto=exps, psmouse.proto=imps or supply none at all. In
the xorg.conf file, I used	   Option      "Protocol" "auto"

Some caveats:

1) One thing I noticed is there is like a 2 second lag before the mousewheel
scroll up becomes available.

2) Another thing I noticed is that if you don't move the mouse more than
tapping it like once a second after switching, it'll never reset itself (you
can really see this in the console). Of course, not really a big deal in the
context of normal use, but something to keep in mind. For instance, you can't
switch back and then use the mousewheel without first moving the mouse. 

3) Another thing is that you sometimes get jibberish on the console screen if
you move the mouse right after switching. I'll attach a picture of the screen I
took with my digi cam.

Wolfgang: I noticed you use a Logitech mouse. That might make a difference. Are
you sure you have the code in the patch built properly? You can verify that by
changing one of the kernel messages to something you'd recognize to know if the
changes were really built in properly.

My output: 

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 22 Brian 'netdragon' Bober 2004-09-07 17:01:43 UTC
By the way, when will this be in the kernel?
Comment 23 Brian 'netdragon' Bober 2004-09-25 15:28:50 UTC
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 24 Mauro M. 2004-09-26 08:20:35 UTC
Created attachment 3722 [details]
Modfied patch for 2.6.8.1 (speeded up by removing logging)

Hi,

I have attached a new version of the previously posted patch. I commented out
some kernel logging that was delaying the re-synchronization process. The
result is that there are less chances that your desktop will get scrambled
while the mouse is re-synchronizing.

I tested this on kernel 2.6.7 and 2.6.8.1 on several different hardware
configurations (including smp), and found no issues so far.

To apply, "cd" in your kernel source root and run "patch -p1 < [patchfilepath]"


I hope this helps.

Mauro
Comment 25 Mauro M. 2004-10-05 02:36:52 UTC
Kernel 2.6.9-rc3 still does not include this patch. What is worse is that the
patch that was working for previous releases, no longer can be applied due to
the modifications to the psmouse driver code.

Please can we include this patch to the kernel distribution? If this cannot be
done, please can we have a patch that can be applied to kernel 2.6.9?
Comment 26 Dmitry Torokhov 2004-10-05 08:06:13 UTC
The patch as it is is just a quick hack and I highly doubt it will be included 
in the kernel. As some people on LKML rightfully complained it hijacks 
left+middle and right+middle buttin combinations which is not correct in 
general case.

I will try to come up with some alternative but it will take some time. I will 
re-diff the patch once 2.6.9 is released so you can use your equipment in 
meantime.
Comment 27 Brian 'netdragon' Bober 2004-10-05 23:56:57 UTC
Dmitry: 

Sort of related... How would I track down what causes the mouse to freeze half
the time with a Logitech wireless mouse and a Bel*** KVM switch (bug 3461)? When
it freezes, it needs to be manually unplugged and plugged back. I have the patch
applied, which deals with the case like 50% of the time the mouse doesn't
freeze. I'd like to track down what is causing this so it can be dealt with at
the same time, but don't know where to start.
Comment 28 Mauro M. 2004-10-16 09:32:34 UTC
kernel 2.6.8 with patch-2.6.9-rc4 introduces a new severe blocking bug that
seems to be related to bug 2082: when switching with a KVM that does not support
IMPS2 protocol, the kernel prints the following message:

Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.

And enters in an infinite loop taking 100% of the CPU

Control is then lost and requires an hardware system reset/shutdown.

This is without applying the previously posted patch that cannot be applied to
2.6.9-rc4.

Mauro
Comment 29 Brian 'netdragon' Bober 2004-10-16 23:15:32 UTC
Ouch! What bug number is that new blocker bug? Remind me not to install kernel
2.6.9 ;-)
Comment 30 Dmitry Torokhov 2004-10-16 23:31:12 UTC
Could you provide the output of SysRq-P when the box locks up? That would tell 
use where it is spinning. 
Comment 31 Mauro M. 2004-10-17 03:28:49 UTC
Created attachment 3847 [details]
imps2 busmouse resync patch for kernel 2.6.9-rc4
Comment 32 Mauro M. 2004-10-17 03:33:00 UTC
I have adapted for 2.6.9-rc4 the patch previously posted and working on 2.6.8.
I have also made the following modifications:
- removed dropped packet kernel logging to speed up the process
- removed hijacking of middle + left/right button

I have tested it on 2.6.9-rc4 and it works fine so far, automatically resetting
when switching with a bogus KVM.

Mauro
Comment 33 Joshua Hurtado 2004-10-19 03:58:32 UTC
I have gentoo with the following kernel: 2.6.8-gentoo-r10 (gentoo-dev-sources).
None of the patches posted here see to patch propely with the kernel version. I
keep getting huck fails. Which version of the patch should I use?
Comment 34 Dmitry Torokhov 2004-10-26 15:19:03 UTC
Created attachment 3893 [details]
periodically poll devices to detect disconnects

Guys,

Could you please try the polling patch? It is against 2.6.9, boot with
psmouse.poll=500 option. It sets up polling timer and if there ws no data from
the mouse in last <poll interval> msecs it send PSMOUSE_ENABLE command. If it
gets ACK back evrythign is fine, but if not it assumes that device got
disconnected. Next time there is data transmission it will force reconnect. I
hope that KVMs suppressing connect notification will not fake ACKs.

Disclaimer: it compiles but I have not run it yet.

Thanks!
Comment 35 Brian 'netdragon' Bober 2004-10-27 03:04:58 UTC
What happens if a disconnect and reconnect all happens in faster than the
polling frequency?
Comment 36 Dmitry Torokhov 2004-10-27 06:48:39 UTC
The same as today - the mouse will be left in bad state. That's why I made the 
poll frequency configurable - 0.5 sec I suggested should be adequate under 
normal curcumstances, no? But the difference is that you can switch to the 
other box again, wait a little longer and then switch back and it should start 
working.
Comment 37 Mauro M. 2004-10-27 12:22:53 UTC
Dmitry,

From the architectural point of view, I would rather prefer the driver to be
able to effectively self detect without polling that the synchronization with
the device is lost. Polling introduces an overhead, wasting CPU cycles. The
previously posted patch actually self detects a lost synchronization, taking
what I think it is the right approach. I would rather invest more time in
perfecting the previous patch by reducing the time it takes to make the
detection (presently around 1") in order to reduce the chances to pass dirty
packets to the application. I have been testing the patch posted for 2.6.9-rc4
(working also on the more recent 2.6.9 kernel) for several days now on boxes
with different speeds (from a P III 500 laptop to a dual Xeon server), and the
only remaining problem is the detection latency, now measurable in 1" or less,
during wich the driver passes dirty packets back to X.

I hope this helps.

Mauro
Comment 38 Dmitry Torokhov 2004-10-27 12:46:41 UTC
Well, that is all good except:

1. Not all boxes/mice allow using "strict" PS/2 protocol so while the original 
patch works for you you can see even in this thread that it fails for others, 
and without it sync. detection is very unreliable.
2. Logitech PS/2 protocol extensions (PS2++ protocol) and some others are 
designed to be almost indistinguishable from the standard PS/2 protocol so the 
original patch will not work for them at all.
3. Without "hijacking" middle+other button there is one datapoint less for 
proper resync makeing resync even less reliable.

Given all of that I think the poll is a decent workaround for a broken hardware
(I consider suppressing connection announcements by KVMs to be broken). Plus 
polling should not normally pass any "dirty" packets after switch.

Now, have anyone tried it?

Dmitry 
Comment 39 Darren Davison 2004-10-27 15:50:00 UTC
FYI: I applied the resync patch to a gentoo-dev-sources 2.6.9 kernel and it 
works for me on a Belkin KVM.  After switching back to the gentoo desktop, the 
upward scrolling action is totally ignored for a second or so, then begins to 
work fine.  Similar output in dmesg as reported by others.  Gentoo ref: 
http://bugs.gentoo.org/show_bug.cgi?id=68904 
 
Thanks and regards! 
Comment 40 Brian 'netdragon' Bober 2004-10-28 04:17:12 UTC
Darren: The resynch dection patch doesn't work properly for Logitech. It worked
when I used an Intellimouse Explorer, but with my Logitech wireless mouse, the
patch doesn't work. So obviously this, as it stands, is not sufficient. What if
we simply had erratic mouse behavior detection?
Comment 41 Brian 'netdragon' Bober 2004-10-28 04:18:16 UTC
Scratch that, I just realized that the issue with the Logitech mouse is the
cursor stops moving, not erratic behavior.
Comment 42 Mauro M. 2004-10-28 04:39:21 UTC
I have tested the resync patch that works with:

- Logitech Cordless Wheel Mouse (mouse M/N: M-RG45, base M/N: C-RA1)
- Microsoft IntelliMouse Pro
Comment 43 Brian 'netdragon' Bober 2004-10-28 12:30:23 UTC
The Logitech wireless MX700 mouse freezing when I switch back and forth issue
might be a different issue altogether. I'll have to wait till I have the chance
to test the mouse without the patch applied to the kernel and see if the erratic
mouse behavior happens without it with Logitech. Unfortunately, when I got the
Logitech mouse, I already had the patch applied. The reason I think that the
issue might be caused by a complete hardware incompabibility is I have seen the
mouse freeze on windows. I have to physically unplug it and plug it back into
the KVM's PS/2 port. Unfortunately, I don't know what this does in the operating
system software.
Comment 44 Dmitry Torokhov 2004-11-02 16:57:33 UTC
Created attachment 3936 [details]
Periodically poll devices v.2

Here is updated version of the polling patch, the first one was setting timer
slightly incorrectly. I have gotten couple of success stories so unless it
breaks someone's box I intend on submitting the patch for inclusion.

Dmitry
Comment 45 Martin von Gagern 2004-11-24 11:26:35 UTC
I have a very simple KVM that is really just a switch, without any electronic.
one of the computers connected to this is an Dell Inspiron 8200 Notebook with an
builtin Synaptics touchpad, as well as a tower, both running Gentoo Linux.
Probably the Notebook or its port replicator might try to be "intelligent" and
suppress some important messages, I do not know.

When switching to the notebook, the mouse behaves erratically as described here.
Switching to my other computer and back to the notebook used to "solve" the
problem most of the time.

After including atachment#3936, however, I could not get the mouse to work again
if I ever changed to my other computer. So this patch actually made the problem
worse for me.

I think I'll try attachment#3847 [details] as soon as I find the time, but to me this
polling strategy seemd more obvious and fool-proof, so I wonder what went wrong
with my system.
Comment 46 Dmitry Torokhov 2004-11-24 15:34:06 UTC
Created attachment 4135 [details]
Periodically poll devices v.3

Here is the new version of the polling patch. The last one had a race between
timer and interrupt handler and sometimes did more harm than good.

As far as Inspiron 8200 goes I am surprised that it does not recover anymore as
the patch should have no effect on Dell notebooks. If a notebook has no active
multiplexing controller external mouse and touchpad are connected to the same
KBC port and therefore there is always device responding to "pings".

When you are saying that you were used to recover mouse by switching to other
box - are you talking about 2.4 era or 2.6? What's on the tower? Btw, 8200 have
ALPS if I remember correctly, not Synaptics. Do you have any additional patches
installed? I guess I'd like to see the full dmesg, preferably with #undef DEBUG
changed to #define DEBUG in driver/input/serio/i8042.c

Dmitry
Comment 47 Dmitry Torokhov 2004-11-24 15:42:06 UTC
Btw, doing: 
 
     echo -n "reconnect" > /sys/bus/serio/devices/serioX/driver 
 
should re-initialize mouse. X in serioX is most likely 0 but depends on the 
box. "driver" is changed to "drvctl" from 2.6.10-rc onward. 
Comment 48 Martin von Gagern 2005-01-17 14:59:22 UTC
Created attachment 4427 [details]
i8042 debug messages on Dell I8200

> As far as Inspiron 8200 goes I am surprised that it does not
> recover anymore as the patch should have no effect on Dell
> notebooks. If a notebook has no active multiplexing controller
> external mouse and touchpad are connected to the same KBC port
> and therefore there is always device responding to "pings".

So much for theory. Could this, on the other hand, be the reason why it is
difficult to recognise the input out of sync as garbage?

I don't know about multiplexing controllers, but I'm using a port replicator,
providing two PS/2 connectors, one for keyboard and one for mouse. The notebook
itself, on the other hand, has only one, to be used either for keyboard or for
mouse or with some adapter for both. That anything to do with multiplexing?

> When you are saying that you were used to recover mouse by
> switching to other box - are you talking about 2.4 era or 2.6?

Both are 2.6.x - I just updated the notebook to 2.6.10, the other is 2.6.9

> What's on the tower?

Gentoo linux

> Btw, 8200 have ALPS if I remember correctly, not Synaptics.

Might well be. I only remember my 8000 had a Synaptics, and as this looks the
same... But the name ALPS does ring a bell, so I guess you're correct.

> Do you have any additional patches installed?

none.

> I guess I'd like to see the full dmesg, preferably with #undef
> DEBUG changed to #define DEBUG in driver/input/serio/i8042.c

dmesg is not much use - the ringbuffer gets overwritten much too fast, plus you
get no timing information. I extracted the relevant time from my syslog. dmesg
looks about the same, except for the disconnected part which I never managed to
catch live. So the three different parts you see are
1. connected, working
2. disconnected, Mouse used on other PC
3. connected, garbage

> Btw, doing: 
>  echo -n "reconnect" > /sys/bus/serio/devices/serioX/driver 
> should re-initialize mouse. X in serioX is most likely 0
> but depends on the box. "driver" is changed to "drvctl"
> from 2.6.10-rc onward. 

I tried that, for 0 as well as for 1, but without visible results. Only thing
that worked was reloading the module.
Comment 49 Mauro M. 2005-02-17 11:13:42 UTC
Created attachment 4556 [details]
PS2 mouse resync for kernel 2.6.10 (and hopefully higher)

This patch applies to kernel 2.6.10 (and above, hopefully). The previous patch
did not work with 2.6.10 because someone had the great idea to change the 
"module_param_array_named" macro in the kernel include <linux/moduleparam.h>
replacing an "int" with an "int pointer".

I have tested this patch thoroughly for several months on different hardware
and had no issues so far. EzPlanet One distribution
(http://www.EzPlanetOne.com) ships with this patch in its standard kernel.

Now we should just hope that Vojtech will include this patch in the psmouse
driver main stream.
Comment 50 Mauro M. 2005-02-17 11:25:25 UTC
Created attachment 4557 [details]
PS2 mouse resync for kernel 2.6.10 (and hopefully higher)

Patch re-attached as plain text (patch).
Comment 51 Hubert Figuiere 2005-03-20 15:26:17 UTC
I have applied attachment 4557 [details] to my kernel tree, and it works for me. At last I
can use my KVM beetween that MacMini and the Linux PC.

Is it possible to have this integrated in the next kernel release ?

I filed https://bugzilla.ubuntu.com/show_bug.cgi?id=7335 and Ubuntu mainainers
are a bit upset about applying it.
Comment 52 Mauro M. 2005-03-23 13:30:13 UTC
I confirm that this bug is present once again in kernel 2.6.11.5. I confirm as
well that attachment 4557 [details] does not work on 2.6.11.5 because the mouse driver has
been, once again modified. I am really getting frustrated with this bug. Several
times I have asked Vojtech Pavlik to include this patch in the main stream, but
it is not happening. I think that we should be setting some business related
priorities. Given that Linux is mostly used in server platforms, often running
off KVM switches, I reckon that this issue should have a much higher priority
than fiddling with the latest mouse tablet hardly used by anyone. Vojtech, once
again, please, could you include this patch in the MAIN KERNEL STREAM?

Mauro
Comment 53 Ga 2005-04-30 08:39:17 UTC
*** Bug 4564 has been marked as a duplicate of this bug. ***
Comment 54 Ga 2005-04-30 08:50:54 UTC
I am experiencing the same kind of issues on 2.6.11.7 (see previous comment
duplicate for details). The various patches here do not apply as well, only
thing that works besides loading/unloading psmouse is the echo reconnect to
drvctl in sysfs. (setting resetafter or proto paremeters don't change anything)
Any hope of this being fixed for anybody ? thanks,
Comment 55 Dmitry Torokhov 2005-05-02 23:59:15 UTC
Created attachment 5015 [details]
resync-after-idle.patch

Ok, here is another attempt to detect if mouse was reset by KVM without telling
anybody. The idea is: if we had a relatively long (0.5 sec currently) pause in
data stream, next time we get a byte, psmouse will poll mouse for a packet. If
packet length matches current protocol - all is good and we can continue, if
not - force reconnect to restore proper protocol.

The patch is a "proof of concept" and need some polishing but I would
appreciate some feedback. It is against 2.6.11.

Thanks!

Dmitry
Comment 56 Ga 2005-05-06 10:22:59 UTC
Hello,

Just tried the resync-after-idle patch, and unfortunately it doesn't fix the
issue  for me... However I have noted a probably expected side effect : when the
mouse is idle for a short while, there is some lag before the next move is
processed (which I assume is a reconnect because of idle ?), not quite usable...

Since this seems to be a not so obvious to analyse, is there some  kind of debug
I can activate to see what's going on when switching with the kvm and help fix it ?

Thanks,
Comment 57 Dmitry Torokhov 2005-05-06 10:41:53 UTC
Created attachment 5024 [details]
resync-after-idle-v2.patch

Lagging should be fixed in the v2 of the patch. Could you please try it?
Remember, if you witch back to Linux in less than 5 secs it will not resy (with
this version of patch).

If it still does not work could you please do the following:
- patch the kernel with v2 of the patch, compile, install and reboot
- "echo 1 > /sys/modules/i8042/parameters/debug"
- switch to your other box
- wait 5 seconds
- switch back to linux box
- Press left mouse button once
- "echo 0 > /sys/modules/i8042/parameters/debug"
- send me dmesg.

Thanks!
Comment 58 Ga 2005-05-06 18:04:35 UTC
Hello,

I applied the new patch and rebooted, and the lagging is gone indeed. However,
switching with the kvm is still not working.

I tried with debugging on, and here is the relevant dmesg output :

May  7 02:53:02 tom kernel: input: PS/2 Logitech Mouse on isa0060/serio1
May  7 02:54:39 tom kernel: drivers/input/serio/i8042.c: 9c <- i8042 (interrupt,
kbd, 1) [1523954]
[I switched here]
May  7 02:54:45 tom kernel: drivers/input/serio/i8042.c: 46 <- i8042 (interrupt,
kbd, 1) [1530293]
May  7 02:54:45 tom kernel: drivers/input/serio/i8042.c: c6 <- i8042 (interrupt,
kbd, 1) [1530353]
May  7 02:54:45 tom kernel: drivers/input/serio/i8042.c: 46 <- i8042 (interrupt,
kbd, 1) [1530485]
May  7 02:54:45 tom kernel: drivers/input/serio/i8042.c: c6 <- i8042 (interrupt,
kbd, 1) [1530563]
[followed by a lot more kdb events as I disabled debugging]

There doesn't seem to be any activity from the mouse (aux right ?), even though
I did press the left mouse button.

Hope that helps !
Comment 59 Dmitry Torokhov 2005-05-06 18:30:51 UTC
Gael, 
 
Now that I have re-read your original report I see that it is a different 
issue, I am re-opening your bug. 
 
Dmitry 
Comment 60 Mauro M. 2005-05-14 09:42:12 UTC
Many thanks to Dmitry for his new patch.

I am testing the latest "resync-after-idle-v2.patch" on kernel 2.6.11.9, it
works much better than the previous that I had ported to 2.6.10 because, so far,
on resync I haven't seen garbage passed to user space that produces
unpredictable results on the screen. However with this version I have found the
following issues:

1) sometimes the mouse resyncs without having switched to a KVM, I have seen it
occurring for example when I switch to a console with Ctrl-Alt-F1;

2) when the mouse is reconnected (resync) the keyboard also is reset.

In practice (1) would not be so much a problem if we did not get also the
keyboard reset. With a keyboard reset not only there is a short lag, but also
the keyboard status is reset and every Lock status with it. Not practical if I
am in Caps-Lock, or F-Lock (I have a silly Microsoft keyboard that requires
F-Lock to get the F Keys working) and I am typing.

I have activated debug as indicated in your previous message:
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [1299982]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux, 12) [1299999]
drivers/input/serio/i8042.c: 0a <- i8042 (interrupt, aux, 12) [1300000]
drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, aux, 12) [1300001]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [1300002]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux, 12) [1300018]
drivers/input/serio/i8042.c: 04 <- i8042 (interrupt, aux, 12) [1300019]
drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, aux, 12) [1300020]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [1300021]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux, 12) [1300080]
drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, aux, 12) [1300081]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [1300082]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [1300083]
drivers/input/serio/i8042.c: 1d <- i8042 (interrupt, kbd, 1) [1300594]
drivers/input/serio/i8042.c: 38 <- i8042 (interrupt, kbd, 1) [1300783]
drivers/input/serio/i8042.c: 38 <- i8042 (interrupt, kbd, 1) [1301313]
drivers/input/serio/i8042.c: b8 <- i8042 (interrupt, kbd, 1) [1301328]
drivers/input/serio/i8042.c: 9d <- i8042 (interrupt, kbd, 1) [1301351]

Please let me know if you require any further information.
Mauro
Comment 61 Dmitry Torokhov 2005-05-15 23:01:13 UTC
Mauro,  
  
The patch will also try to resync if driver does not receive next byte in the  
packet for over 0.5 sec - and it is quite often the case when switching from X  
to console - something disables interrupts for a long time.  
  
As far as your keyboard being reset - the patch should not touch keyboard. Does  
reset also happen if you do 'echo -n  
"resync" /sys/bus/serio/devices/serioX/drvctl' where serioX is the port your  
mouse is bound to?  
  
Dmitry  
  
BTW, I'm up to V11: 
 
http://www.geocities.com/dt_or/input/2_6_11/psmouse-resync-2.6.11-v11.patch.gz 
Comment 62 Dmitry Torokhov 2005-05-15 23:34:18 UTC
Ugh, "resync" is not valid, make it "reconnect": 
 
echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl 
Comment 63 Mauro M. 2005-05-16 02:50:19 UTC
Dmitry,

My previous report was related to a Dell Inspiron 8200 docked and connected to a
Belkin KVM (1). Now I have deployed the new kernel to an Asus PC-DL (Dual Xeon)
based workstation (2) and on the latter the patch works a dream, the keyboard
does not reset and the mouse resync is smooth. Today I am using (1) undocked,
still with the patched 2.6.11.9 kernel, and there is no problem. I have tried

echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl 

on (1) undocked and although it resets the mouse, it does not reset the
keyboard. I shall try this later on (1) docked.

I hope this helps.

Mauro
Comment 64 Tony Whitmore 2005-05-16 10:39:25 UTC
I've been trying v11 of the resync patch and it seems to work pretty well. I've
noticed any interference with keyboard settings either.

Tony
Comment 65 Dmitry Torokhov 2005-05-17 09:11:38 UTC
Mauro,

On my Inspiron 8100 KBC and keyboard/touchpad are being reset by Dell's 
firmware every time I dock/undock or plug a keyboard into external PS/2 port, 
with and without my patch. I suspect all Inspirons/Latitudes work this way. I 
do not know of a way to stop it from happening.

Dmitry  
Comment 66 Ricky Ng-Adam 2005-05-19 08:58:15 UTC
I had problems with the mouse freaking out on 2.6.11.8 and an Omniview E Series
4-Port KVM Switch model F1DB104P connected to a Windows 2000, Windows Advanced
Server and Linux Debian (Sarge).

On upgrading to 2.6.11.10, I also applied the resync-after-idle-v2 patch and
everything seems to work fine now! We have two other KVM switches here, I'll be
testing it with those also if they have the same problems.

Hoping for this to get in the mainstream kernel soon...
Comment 67 Darren Davison 2005-05-20 12:39:20 UTC
Hi Dmitry,

I tried the v11 patch against a 2.6.11-gentoo-r8 kernel but it doesn't work. 
Switching back to the desktop (Belkin OmniCube 4 port KVM) causes the mouse to
spew garbage for as long as I continue to move it.  Complete lack of control
over it's function.  It actually seems to need keyboard input before the resync
occurs..?!

dmesg shows;

psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 3 bytes away.
psmouse.c: resync failed, issuing reconnect request
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 2 bytes away.
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 2 bytes away.
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 3 bytes away.
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 1 bytes away.
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization,
throwing 2 bytes away.
psmouse.c: resync failed, issuing reconnect request


The previous patches (for 2.6.9 and 2.6.10) worked perfectly for me.  The v2
patch against 2.6.11 worked to an extent, but a resync accured every time the
mouse was left untouched for more than 0.5s, whether the KVM was used or not. 
This was annoying as there was a pause before the mouse responded to movement. 
It also causes problems in bzFlag when a resync happens.

Let me know if there's anything further I can do to provide better info?

Cheers
Comment 68 Dmitry Torokhov 2005-05-20 12:49:28 UTC
Darren,

Could you please sent me debug info:
- "echo 1 > /sys/modules/i8042/parameters/debug"
- switch to your other box
- wait 5 seconds
- switch back to linux box
- Press left mouse button once
- move mouse a bit
- wait 5 seconds
- Press left mouse button once
- move mouse a bit
- "echo 0 > /sys/modules/i8042/parameters/debug"
- send me dmesg.

Thanks!

Dmitry
Comment 69 Darren Davison 2005-05-26 01:54:45 UTC
I tried Dmitry's -v11 patch from the website (not attached here at time of
writing) which failed for me.  At Dmitry's suggestion, I changed
PSMOUSE_CMD_SETPOLL to PSMOUSE_CMD_DISABLE in
drivers/input/mouse/psmouse-base.c::psmouse_resync() and recompiled.  Now it
works perfectly.

Using gentoo-sources-2.6.11-r8 / Packard Bell optical USB mouse with USB to PS/2
converter / Belkin OmniCube 4-port KVM.
Comment 70 Mauro M. 2005-06-03 02:02:59 UTC
I have been using last Dmitry's patch (v2) for a while now, and I found only a
problem with a Dell Inspiron 8200 and only when docked (random keyboard resets
with a side effect of resetting the key locks). 

Now we are back again running after kernel's modifications: this patch fails to
apply to 2.6.12-rcX.
Comment 71 Mauro M. 2005-07-26 07:52:50 UTC
Please, could we take this latest fix to the kernel mainstream?
Comment 72 Mauro M. 2005-07-31 11:12:24 UTC
Created attachment 5436 [details]
linux-2.6.12-imps2resyncIdle.patch

I have ported Dmitry's resync-after-idle-v2.patch to kernel 2.6.12. Please find
the attachment as "linux-2.6.12-imps2resyncIdle.patch". I have tested this on
my kernel build and it works fine.
Comment 73 Dmitry Torokhov 2005-08-30 11:16:59 UTC
Mauro,

thank you very much for porting the patch to 2.6.12, unfortunately we can't 
merge it as it is right now because it has problems with ALPS touchpads. As 
soon as we resolve the issue I'll submit it.
Comment 74 Dmitry Torokhov 2005-12-21 22:10:32 UTC
*** Bug 1255 has been marked as a duplicate of this bug. ***
Comment 75 Dmitry Torokhov 2005-12-21 22:20:07 UTC
Created attachment 6878 [details]
resync-after-idle-v3.patch

OK, this is the latest generation of resync after idle patch. It is against
2.6.15-rc6 (should apply to any 2.6.15-rcX, don't worry about some offsets).
Please give it a good testing because unless I hear it does not work the patch
will get merged into 2.6.16 once it opens.
Comment 76 Dmitry Torokhov 2005-12-23 14:51:25 UTC
*** Bug 4469 has been marked as a duplicate of this bug. ***
Comment 77 Dmitry Torokhov 2006-01-30 09:24:57 UTC
The resync patch is in 2.6.16-rc1 and is activated by  default (although it 
might be necessary to switch default to "disabled" for 2.6.16-final). Please 
test and holler if something does not work. 
Comment 78 Mauro M. 2006-02-01 02:38:00 UTC
I have tested this both on Fedora %5 (test2) and EzPlanet One 3.0 beta and it 
works fine.
Comment 79 Lukas Sandstr 2006-02-09 14:17:05 UTC
This patch make my mouse (Intellimouse Explorer V1, USB->PS/2 adapter)
freeze every now and then. If I move the mouse it will unfreeze in
~0.2 sec, but it's very annoying.

I also get "psmouse.c: resync failed, issuing reconnect request" in dmesg.

Reverting f0d5c6f419d3a10443f66d6835855837eae4ac4b from Linus' tree
fixes the problem.
Comment 80 Tom Watson 2006-02-10 12:01:30 UTC
I'm a bit new to this, but I do have the problem.  My KVM switch when switching
from CPU to CPU wants to reset the mouse to "non-wheel" mode.  Back in 2.4, I
could get the mouse in the proper mode by going to a text console (CTRL-ALT-F6,
for example) and then switching back to the graphic console (ALT-F7).  If I
didn't move the mouse, it wouldn't get confused.  It sent the "wheel mode" init
sequence back to the mouse and all was well.  Given that I KNOW when I'm
switching the KVM switch, maybe there is a way of using a special key sequence
(Maybe use one of them thar Windows buttons that were added recently) and that
would send off the sequence to get the mouse reset and back in the mode it
thought it was.  Waiting for things like the tray to move back and forth then
having the pointer fly around and land at the lower left corner THEN resync gets
a bit old.  A simple key sequence (maybe the F key one more than the graphic
console?? [with CTRL-ALT obviously]) is a good key, or CTRL-ALT-F12.  Of course
it might require work in the keyboard module (I guess), but it would be a good
solution!
Comment 81 Dmitry Torokhov 2006-02-10 12:44:46 UTC
Lukas,

I wonder if you could enable debugging (echo 1 
> /sys/modules/i8042/parameters/debug) and wait for the mouse to fail 
resynching. Please note the exact time when it happens send me dmesg.

Thanks!
Comment 82 Dmitry Torokhov 2006-02-10 12:47:16 UTC
Tom,

With the current patch (the one in 2.6.16-rc1) mouse should try to resync right 
away, without clicking around, so please try it. To request a manual resync 
use "echo -n reconnect > /sys/bus/serio/devices/serioX/drvctl" where serioX is 
port your mouse is connected to.
Comment 83 Lukas Sandstr 2006-02-10 17:29:15 UTC
I'll be away until tuesday. I will send debugging info when I get back.
Comment 84 Lukas Sandstr 2006-02-14 12:52:25 UTC
I have been using v2.6.16-rc3-g75c0141 for a couple of hours now
with debug enabled. The problem seens to be gone, at least I haven't 
been able to reproduce it. Before it would happen at least every ten minutes.

I'll let you know if it happens again.
Comment 85 Adrian Bunk 2006-02-14 12:57:45 UTC
Lukas, please reopen this bug if it happens again.
Comment 86 Lukas Sandstr 2006-02-14 14:21:00 UTC
Created attachment 7322 [details]
dmesg dump 1, the mouse stopped responding for ~0.3 sec

It happened again. This is a dmesg dump very shortly after the event.
Comment 87 Lukas Sandstr 2006-02-14 14:24:56 UTC
Created attachment 7323 [details]
Three mouse-freeze events. 

The dmesg-logs are concatenated, the events are separated with ----
and happened shortly (<10 sec) before the dmesg-dump.
Comment 88 Lukas Sandstr 2006-02-15 13:35:15 UTC
Created attachment 7357 [details]
Mouse lock-up again

Today it's happening all the time, with the same kernel as yesterday.
If I don't use the mouse for more than 5 seconds it won't respond for 
~1.5 seconds when I use it.

I stopped moving the mouse 7 seconds before the attached dmesg dump was made.
2 seconds before the dump I started moving the mouse, and it responded after
~1.5 seconds.
Comment 89 Dmitry Torokhov 2006-02-15 13:40:37 UTC
Lukas,

I really need the debug data taken at the time of the incident, not after. If 
you could just leave debugging on and wait till mouse misbehaves and then just 
semd me /var/log/kernel or whatever your syslog uses to store kernel messages 
that woudl be helpful.

Thanks!
Comment 90 Lukas Sandstr 2006-02-15 13:59:43 UTC
Created attachment 7358 [details]
Mouse lockup from before the event

I stopped moving the mouse at 22:57:00
I started moving it again at 22:57:06
It started responding just before 22:57:08
Comment 91 Olaf Kirch 2007-03-12 08:01:41 UTC
Does this problem persist with current kernels? Otherwise I suggest we
close this bug.
Comment 92 Mauro M. 2007-03-12 11:03:48 UTC
I am afraid I do not consider this bug as resolved. There is a work-around in
the current kernel main stream that requires to press both left and right mouse
buttons to reset the mouse sync, however before that happens the pointer manages
to jump randomly around the screen, often making random modifications to the
desktop layout that render it unserviceable. The results are disappering icons
or menus and task bars in the worse cases, requiring a desktop settings restore
(if available).

The mouse driver should be able to detect when it lost sync with the device, and
to restore proper communications BEFORE the actions are passed back to the
applications. If Windoze can do it, and kernel 2.4 could do it, I do not see why
kernel 2.6 cannot.

Mauro
Comment 93 Dmitry Torokhov 2007-03-12 11:37:55 UTC
Mauro,

I am afraid that you are mistaken. The workaround activated by pressing all 3 
buttons is not in the mainline. What is in the mainline is resync patch which 
is turned off by default. If you are on KVM switch you can try doing

echo -n 3 > /sys/bus/serio/devices/serioX/resync_time

to activate it and it will try to resync mouse if there was no data coming out 
of it for >= 3 seconds.
Comment 94 Mauro M. 2007-03-12 13:31:10 UTC
Whatever is in the mainstream kernel, it should be fixed as specified in my
previous message(s) and it should be active WITHOUT requiring an activation,
hence I do not consider this bug closed.

I reckon that we have been waiting too long. This bug was opened nearly THREE
YEARS AGO. Your ears should be whistling for the #@!$
Comment 95 Dmitry Torokhov 2007-03-12 13:41:10 UTC
If you have a patch that would reliably fix this problem on all boxes out there 
I will gladly push it upstream.
Comment 96 Dmitry Torokhov 2007-03-12 13:42:59 UTC
Btw, if 2.4 stule psaux works for you you still can have it - just load 
serio_raw module and bind it to your mouse port and enjoy.
Comment 97 Dmitry Torokhov 2007-03-12 13:52:46 UTC
... and hopefully my last message for today...

In pre 2.6 era your mice still did not resync automatically; you had to 
manually switch consoles to re-initialize the mouse and restore protocol. You 
still can do that with 2.6 - have a hotkey issue the following:

echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl

and it should reinitialize the mouse and it will be even faster than switching 
consoles. What we are trying to do here is to restore protocol automatically, 
without hotkeys/console switching, unfortunately that does not work reliably on 
all hardware out there.
Comment 98 Olaf Kirch 2007-03-12 14:15:22 UTC
The difference between 2.6 and 2.4 may have been how mice were handled
in general. Back then, the X server would open /dev/psaux and read the
raw data - and it was the X server that would do the resync if it considered
the mouse "out if sync". I think this included things like looking at whether
the data read from the mouse made sense.

Actually it's not too hard to detect erratic mouse behavior. You basically
look at the second derivative - ie how the mouse "speed" changes. If I get
a movement in the X direction of +100, and the next millisec the mouse protocol
tells me it's -20 in the X direction, then we know that either the user is
jerking the mouse around like mad, or the mouse is out of sync. IOW, you can
look at how the relative motion changes.

I think this is basically what X did to detect mouse desynch.

However, given that this bug has been hibernating forever, I think it hardly
deserves blocker status. I also if you complain about the bug being open for
years, you ignore that fact that the original problem was fixed long ago,
except for some (admittedly annoying) glitch.

Also, if the existing fix for the resync problem in mainline addresses the
problem, regardless of whether it requires manual configuration or not, I
think it is fair to close this bug report. Of course, you are free to pursue
further enhancements with Dimitry.
Comment 99 Mauro M. 2007-03-12 14:45:17 UTC
I am afraid I reckon that the problem is still open and that this bug could only
be seen as resolved when, after switching console or just unplugging and
re-plugging in a PS2 mouse, I will see the X desktop (or gpm) or any other tool
using the mouse to re-sync automatically without user intervention of any sort.

I do not see the point to open another bug. I reckon that we can do much better
just by persevering in tuning this driver.

About two years ago I posted a series of patches, modifications of a Dmitry's
original, that I thought were an acceptable compromise, though they were still
to be fine tuned; but I got frustrated when the mouse driver kept changing for
every new kernel release, thereby requiring every time a re-work of the patch.

I only hope that this work could be picked up buy the mouse driver maintainer.
Dmitry, please, please, include in the main stream a mouse driver working as
specified above.
Comment 100 Tony Whitmore 2007-03-12 15:06:33 UTC
As an end user rather than developer, I continue to find this bug annoying on a
regular basis. I have a Belkin KVM which worked just fine under 2.4. Since 2.6
was released I have used all sorts of work arounds to continue using my KVM as
2.6 kernels just don't play well with it. That included patched kernels. In the
end I  have resorted to using one mouse for my 2.6 box running X and one for the
non-2.6 boxes connected to the KVM. I don't much care which mechanism is used
under the hood, but I shouldn't have to issue any commands to manually resync
the mouse.

I'd rather not go into the damage to my work, desktop and windows that has been
caused by this bug.
Comment 101 Dmitry Torokhov 2007-03-12 15:06:35 UTC
Created attachment 10733 [details]
Force resync at open

OK, since 2.4 behavior is considered holy grail this patch should restore it. I
firmly believe that enabling automatic reconnect is better solution but I know
it does not work for everyone, that's why it is disabled by default. PLease let
me know if the patch works for you.

With regard to original patches - the reason that they were never included is
that people do have left+middel combinations mapped to perform certain tasks
and the patch would break their setups.

As far as Olafs idea for detecting mouse jerkiness - incidentially when I just
read e-mails or surfing web I like to bounce the mouse between my thimb and
pinkie and click it ;) You never know all the wierd ways users might use their
hardware.
Comment 102 Mauro M. 2007-03-12 15:23:20 UTC
Well, since we are discussing about it, the 2.4 behaviour was better, but NOT
GOOD ENOUGH.

Please, can we clarify the principle that:

If the mouse DOES NOT resync WITHOUT user intervention (various clicks
combinations or other settings like echoing something to any sys ctl)

 IT IS NOT FIXED

Anything other than automatic resync like it happens for Windows is UNACCEPTABLE
as solution to this bug.

We will consider it FIXED IF and only IF, when switching with a KVM or by
unplugging and re-plugging in the mouse (those without a KVM just have to do the
latter to test), the mouse protocol will RE-SYNC AUTOMATICALLY without any
effect to the application. A brief delay (1-2 seconds) will be considered
acceptable, but it should not occurr if the mouse has not been unplugged (this
was the defect of one of the earlier 2.6 patches).
Comment 103 Dmitry Torokhov 2007-03-12 21:58:19 UTC
Mauro,

I understand your sentiment however I do not have a solution for you nor this 
problem is highest on my TODO list. Given that there are several workarounds 
for the problem you experiencing (enabling resync, manual reconnect via sysfs) 
I will lower the severity of this bug from blocking to normal.
Comment 104 David Rosenstrauch 2007-03-13 07:16:27 UTC
FYI - I was having this problem too, but using the resync_time workaround has
pretty much made it automagically go away in recent 2.6 kernels.  (I'm currently
using 2.6.20.2.)

All I do is just set the following options when I load the psmouse module, and
the mouse will automatically correct itself when I switch the kvm to the linux box.

proto=imps resync_time=10

Seems like a reasonable workaround to me - you just set it once and forget it. 
And it doesn't seem unreasonable to me to have to set some particular module
option if you're using a particularly unique hardware configuration.  (In this
case, a KVM that does funky things.)

Just my $0.02.  HTH/
Comment 105 Vojtech Pavlik 2007-03-20 06:07:04 UTC
Dmitry, I think that Olaf's approach actually makes sense - the physics will not
allow for values of x/y acceleration larger than a few G, and even the sensors
in the mouse have rather stringent limits of what they can cope with.

Since the timing is known in the kernel, we should be able to detect that the
mouse cursor is trying to jump erratically by observing the acceleration of it -
it will not get into the way of any physically possible usage patterns.
Comment 106 Dmitry Torokhov 2007-03-20 06:18:09 UTC
Yes, you (and Olaf) may be right. I also looked again at your self-
resynchronizing driver that you sent me long time ago. But I just started 
implementing locking in input core (too many reports of evdev oopsing ;)) so 
psmouse is kind of on back burner...
Comment 107 OLFarCnArt 2007-03-29 15:15:00 UTC
Hello, folks:

The last time I posted this to Bugzilla was in Bug #1255
<http://bugzilla.kernel.org/show_bug.cgi?id=1255>
Additional Comment #8 From OLFarCnArt@DSLExtreme.com  2005-07-10 13:01

In that post I related having "upgraded" from Mandrake Linux 9.2 to Mandriva
10.1 and running into this same kernel 2.x glitch at that time.  It effectively
killed my use of Linux at that time.

More recently, I installed PCLinuxOS .92, and was pleased that it seemed to work
with my KVM switch -- an IOgear model that seems to work just fine with many
other users' systems -- and was on my way to a beginning in my understanding of
how to use Linux and make it communicate with my Winders boxes.

Then I "upgraded" to PCLinuxOS .93a.  It seems to have included kernel 2.6x as
part of the "upgrade", because now I can't use Linux again.

Excuse me, folks, but for those who have more important fish to fry, know this:
 IF YOU WANT WINDOWS USERS TO CONVERT TO LINUX, TAKE AWAY ALL THE ROADBLOCKS.

Not shouting, here, just emphasis -- which this seems to need.

Folks in the Linux community seem usually to be so far advanced in their craft,
they have forgotten that most computer users are (a) using Winders, and (b)
trying to get some work done -- meaning not rebuilding their operating systems
every five minutes but writing letters, doing bookkeeping, running an office,
communicating via the internet or otherwise, any number of other things.

The Operating System should be virtually transparent, and having the cursor
flying all around the screen, clicking every icon as it passes over it, and
winding up with a screen full of open windows and processes -- all within a
second -- is not my idea of transparent.

The Winders user, when experiencing some glitch this blatant, is going to simply
make a comment about how stupid this thing is, and drop the CD into the
wastebasket along with the AOL disks.

No matter how much or well the OS is promoted, something as basic as getting a
mouse to work through a KVM switch, if it goes this haywire, will result in its
instant de-certification by a Winders user.  I'M damn well frustrated by having
a supposed "UPgrade" to my system wind up completely breaking it.  I'm back to
100% bloody Windows because this supposed "UPgrade" to the 2.6x kernel BREAKS
LINUX for me, and I'm only seeing comments on this 'zilla #2082 that it's not
important enough to waste time on.

Come on, guys -- please!

I am in accord with Additional Comment #100 From Tony Whitmore  2007-03-12 15:06

and most especially with Additional Comment #99 From Mauro M.  2007-03-12 14:45
and Additional Comment #102 From Mauro M.  2007-03-12 15:23

What they say is Gold, here.  This OS is dead in the water until obvious
glitches like this are fixed and made to stay fixed for subsequent versions.

This bug should not be closed nor demoted in severity until it is FIXED for all
users.

Comment 108 David Rosenstrauch 2007-03-30 06:59:10 UTC
As I mentioned in #104, there is a solution that has been working reliably for
me.  You might want to try it and see if it fixes the problem for you.


I also used to tear my hair out about this bug, but since setting the
appropriate module options has fixed this issue for me, I'm not really so
stressed about it now.

As far as whether this should "just work, out of the box" - i.e., these options
should automatically be set by default - just my $0.02 (I'm not a kernel
developer) but I think that's very much open for debate.

Not all KVM's suffer from this issue.  So if you or I happen to choose to
purchase a cheap KVM that acts funky, is it really the kernel developer's job to
compensate for that?

Yes, it would be great if Linux worked perfectly with all hardware out of the
box.  But this is an extremely hard thing to do - particularly given that most
hardware manufacturers do NOTHING to assist the Linux community in this regard.

However, Linux has still made great strides in working "out of the box" in
recent years - mostly due to greatly improved "hardware autodetect" scripts.  So
personally, I think there's a good argument to be made that this is an issue to
be addressed in the various distros' hardware autodetect scripts, and not
necessarily the kernel module.  But, like I said, just my $0.02.


Anyway, like I said, there is a workaround for this.  You just need to customize
some of option settings for the psmouse module.  (This is not so strange.  You
sometimes need to do customize module option settins with other funky hardware.)
 Try setting those options like I described in #104 and see if it fixes your
problem.
Comment 109 OLFarCnArt 2007-03-30 20:26:37 UTC
Hi David:

Thanks for the possible workaround.  But why do I feel like I'm talking to the
wall?  I thought this was a place to report a bug.

I said it in Comment #107 but don't know how or if it was understood.

Experienced Linux users think in terms of patch this, patch that, use this or
that workaround.  This is fine, and works for the experienced user.  A paradigm
shift is in order.

Winders users haven't gone to the command line since DOS 6.2, with few
exceptions.  It is not a usual, daily operation and is only done on the
exceptional occasion that requires it, for those who can remember it.

If a Winders user suddenly finds his cursor flying around the screen, selecting
things and opening them as it goes, and requiring a hard boot to recover, his
computer is considered "broken".  He is not going to use heroic measures to try
to make a broken computer work when he can simply continue to use Winders, which
he already has, and which, even though it's crap in most other ways, works with
virtually any KVM switch on the market, with a few rare exceptions.

In short, this is something that Winders simply does better than Linux, and
needs the attention of the kernel developers beyond what they seem to believe is
necessary.

Yes David, I can try a patch, and probably will, since I'm pissed enough at M$
to keep trying, but a new patch for every version iteration?  Sure.

Consider, if you please:

   proto=imps resync_time=10

proto- or prot- pref. 1. First in time; earliest: protolithic. 2. First formed;
primitive; original: protohuman. 3. Proto-. Being a form of a language that is
the ancestor of a language or group of related languages: Proto-Germanic. 4.
Having the least amount of a specified element or radical: protoporphyrin.
[Greek proto-, from protos....

imp (imp) n. 1. A mischievous child. 2. A small demon. 3. Obsolete. A graft.
--imp tr.v. imped, imp
Comment 110 David Rosenstrauch 2007-03-31 07:24:03 UTC
That's your take on the situation.  Here's mine.  (And why do *I* feel like
*I'm* talking to a wall?)

This bug has been fixed.  Not a workaround, a fix.  And no, there's no patching
necessary.  The fix is part of the kernel.  All you have to do is turn the fix
on.  I pointed out to you how to do it.

Yes, this is a place to report a bug - specifically this specific bug.  It's not
a place to wax on about Linux vs. Windows adoption.  It is not a place to
consider how the average Windows user would deal with this bug.  You,
specifically are the one dealing with this bug.

If you are having trouble applying the fix because your KVM is going wiggy, then
I would advise this:  set the KVM to the Linux machine and then reboot.  When
the box comes up, the mouse should work and so you can apply the fix.  Or if
that's not working, then temporarily reboot your computer with the mouse in the
PS/2 port and then turn the fix on.  (Or even better, reboot it in console mode
and then you don't even need to worry about the mouse.)

That's really all that matters here, IMO.  There's a fix to your problem.  If
you choose to use it, great.  If not, that's OK too.  The only other thing that
could possibly be relevant to discuss here, IMO, is whether this fix should be
turned on by default or not.  I don't feel too qualified to comment on that,
since I'm not a kernel developer and don't know all the implications of that
decision.  But as I said I can see a good argument for NOT defaulting it to on.
 It's not out of the norm for an OS to cater to the most common hardware
configurations, and then make you take an extra step or 2 to get some rare,
buggy piece of hardware that you chose to work properly.  I know that I've had
to do things like that on Windows on *numerous* occasions.  (Despite your
assertions, I've had MANY cases where things didn't just work out of the box on
Windows, and I had to go forum surfing, hunting for new driver sofware, change
registry settings, etc.)

So, IMO, this bug is fixed (and so perhaps someone should mark it closed
already!).  If you want to discuss unrelated Linux vs. Windows issues, there's
better forums to do that than this.
Comment 111 Tony Whitmore 2007-03-31 09:19:45 UTC
The fix works for me using a Belkin Omnicube 4-port KVM. I've documented the fix
here: http://tonywhitmore.co.uk/cgi-local/wiki.pl?UsefulNotes/BelkinKVM

The annoyance with this bug comes from it being a regression and a harmful one
at that. It's not just cheap KVMs that are affected though. Mine's not an
enterprise KVM but it's not a cheap one either.

@OLFarCnArt: The developers have a fix in the kernel. It's up to distributors to
turn it on by default or by a dialogue box. It's probably worth filing a bug
against your distribution's kernel to get them to enable the fix (assuming it
works for you).
Comment 112 Mauro M. 2007-03-31 10:08:16 UTC
This bug does not affect only systems handled with a KVM switch. It is just
sufficient to unplug and plug in again a mouse for the bug to manifest. Given
that linux is used more likely on 24x7 servers, this is bound to happen sooner
or later during a server operational life time, when keyboard and mouse devices
are plugged in only to do some maintenance and then unplugged again.

The fix should not be distributed as a kernel option, instead it should be part
of an appropriately functional kernel mouse driver.

Comment 113 Dmitry Torokhov 2007-04-01 07:57:14 UTC
As long as people do not use Dell laptops as 24x7 servers pulling mouse out and 
plugging it back in should work just fine. That happens because without KVM the 
PS/2 greeting 0xaa 0x00 is delivered to kernel and it can detect that a new 
device was plugged in.
Comment 114 Mauro M. 2007-04-01 09:04:20 UTC
I just happen to have a single monitor, keyboard and mouse shared by several
servers, workstations and a Dell laptop in its docking station. I reckon that I
might not be an exeption because I know of several thousands people using a
similar configuration and a Dell laptop (it might be not optimal, but Dell
laptops are very popular with large organizations' Chief Financial Officers).
That is one of the reasons that makes Linux hard to be accepted by large
organizations, where developers and architects need to focus on producing their
business solutions (jumping across physically separated development, test, live
environments with a flick of a switch), rather than rebuilding their messed up
desktops. Perhaps here is where reality is out of Linux developers' depth, they
might be alien to seeing several thousands people at work because they may not
be used to working in a team. Their attitude facing this matter speaks for
itself. Personally I have been a Linux advocate for several years, however when
asked for advice on Linux, recently I have started recommending Solaris 10 and
Free BSD as viable alternatives. The Linux kernel was the last remaining solid
Linux component, however it looks like it is becoming an uncontrollable fudge,
like the rest of the operating system, governed by an oligarchy of incompetent
shortsighted developers.

If only, rather than making all these arrogant excuses, you could just tell us
that you aren't capable of doing it, all of us would be more patient and
understanding.

I reckon that it is really sad for Linux having to get to this sort of flaming
arguments, around what is perceived to be a simple and foundamental matter that
should have been fixed years ago. 

Now we will wait and see how mature you are, by your reaction on this provoking
message composed out of a frustration built over years. You can either humbly
start to work on solving this matter or further demote the importance of this Bug.
Comment 115 David Rosenstrauch 2007-04-02 09:26:25 UTC
Egads - can we please stop turning this bug report into a forum discussion about
Linux's ability to survive in the {Windows,corporate,etc.} world!  There's many
other forums for that sort of thing, and this bug report should be used for
specific technical discussions of this bug.

So, int that light, from recent discussion it seems clear that there's an issue
about the way this bug has been fixed.  A number of people feel that it's
incorrect for this fix to be a kernel option that's initially defaulted to off,
and that the fix should be enabled by default (or not even an option).

As I said, I'm not a kernel developer, and so don't feel qualified to comment on
this.  But perhaps one of the kernel developers monitoring this bug can.

I think an explicit decision needs to be made as to whether the fix will be
automatically enabled or not, and after implementing that decision this bug
should finally be closed.  (It's been open for 3 years now!)

Dmitry - is this something you can do?
Comment 116 Dmitry Torokhov 2007-04-02 10:06:01 UTC
David,

There are devices that hickup on poll commands so the kernel performs full 
reconnect every time, even when protocol was not reset. These hickups annoy 
users that do not use KVM switches; that's why resync time is off by default.

I still do not want to close the bug as I do want to get this issue resolved 
completely and not require user involvement however I am busy with other issues 
that I consider having higher priority at the moment.

Dmitry
Comment 117 OLFarCnArt 2007-04-05 11:18:44 UTC
Dmitry:

Re:
"I still do not want to close the bug as I do want to get this issue resolved 
completely and not require user involvement however I am busy with other issues 
that I consider having higher priority at the moment."

Thank you for deciding to keep this open, and I can understand about things
having superior priority.  It's just that some contributors to this bug report
seemed entirely too desirous of closing or demoting it; ("works for me") is
hardly an answer to someone who has a problem and seemingly no answer that works
for him.

To David: I didn't mean to start a flame war.  I did look for the files
mentioned in the "fixes", and as of the moment my distribution seem to NOT HAVE
those files, making editing a bit difficult.  I am the new guy who doesn't know
everything you know, and when things don't work, must ask for help.  This bug
report was already a last resort for me.

I'm ready to wait for the real fix, which I'm sure now will be eventually
forthcoming.  Thanks, Dmitry, for what you do.

Comment 118 Dmitry Torokhov 2007-04-05 11:49:32 UTC
OLFarCnArt: the psmouse.resync_time option is in mainline kernel since 2.6.16 
which is about year old so your distribution is most likely has it.
Comment 119 Tom Watson 2007-04-05 23:12:36 UTC
It seems to me that if one can detect that the mouse has "lost sync", then the
driver ought to send out the parameters to the mouse to get it in the right mode
and get it all sync'd up.

It should be this way as default as well.

The problem with an "idel for 'n' seconds" type of set parameters to mouse is
that if one has a KVM switch, you could be on another CPU when the command gets
sent out, and it is sent to "air".

If the mouse is detected moving at "warp speed", something is wrong.  A setting
of parameters needs to be done so that the mouse will send out the proper data
(including the wheel data).

Yes, it was the #$%^&*%#'s in redmond who thought of this wonderful mouse
protocol.  No wonder it is so fouled up!
Comment 120 OLFarCnArt 2007-04-10 23:36:11 UTC
Dmitry:

Re: --- Additional Comment #118 From Dmitry Torokhov  2007-04-05 11:49 -------
OLFarCnArt: the psmouse.resync_time option is in mainline kernel since 2.6.16 
which is about year old so your distribution is most likely has it.

Is this the right line?

    proto=imps resync_time=10

Where do I put it?  I haven't a clue.

The distribution is PCLinuxOS v.93a and uses lilo.

Thanks....

Comment 121 Natalie Protasevich 2007-09-03 22:52:15 UTC
OLFarCnArt, the resync_time is actually a module parameter, you specify it on module load, normally somewhere in /etc/modules (depends on distro):
MODULE_PARM_DESC(resync_time, "How long can mouse stay idle before forcing resync (in seconds, 0 = never).")

So the default is 0 which means the above.

Anything new with the bug?
Thanks.
Comment 122 Martin von Gagern 2007-09-04 01:38:26 UTC
(In reply to comment #121)
> Anything new with the bug?

I'm still using my dumb KVM described in comment #45, but moved most of my work to the desktop and haven't seen any issues related to KVM switching in quite a while. However during normal operation the mouse cursor sometimes just moves to one corner. So there seems to be still an issue with resyncing, though not related to switching. Is this related to the bug at hand, or should I open a new one?
Comment 123 Natalie Protasevich 2007-09-08 20:25:08 UTC
Sounds like a different problem to me, however, Dimitry will have to decide if this is so, and if he wants to track your issue here.
Comment 124 H.J. Lu 2007-10-26 18:23:15 UTC
Created attachment 13285 [details]
A patch to reset PS/2 mouse after KVM switch

This is the patch against 2.6.23 kernel. Instead of getting

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

now I got

psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, issuing reconnect request.

and my mouse works fine after KVM switch.
Comment 125 H.J. Lu 2007-11-02 09:09:02 UTC
Created attachment 13379 [details]
The kernel log before and after KVM switch
Comment 126 Brian 'netdragon' Bober 2008-01-19 20:21:05 UTC
Interestingly, I just had this same issue with a simple 3 button Logitech scroll mouse (so may it's Logitech mice in general and not that it was a wireless mouse that was the issue). 
Comment 127 Natalie Protasevich 2008-02-02 02:28:13 UTC
Dmitry, would you comment on the patch in #124? I suppose it hasn't been submitted.
Comment 128 Natalie Protasevich 2008-03-03 18:08:32 UTC
HJ, I suppose it'll make sense to submit the patch in #124 to linux-input@vger.kernel.org and/or lkml, it seems the problem is still there.
Comment 129 H.J. Lu 2008-03-03 20:37:10 UTC
(In reply to comment #128)
> HJ, I suppose it'll make sense to submit the patch in #124 to
> linux-input@vger.kernel.org and/or lkml, it seems the problem is still there.
> 

My patch doesn't solve all problems. I will try to look into it again.
Comment 130 Natalie Protasevich 2008-03-03 20:42:20 UTC
Thanks, this will be appreciated.
Comment 131 H.J. Lu 2008-03-13 18:32:48 UTC
Created attachment 15257 [details]
A patch to reset PS/2 mouse

When a mouse is too fast, it is very likely out of sync. I use
time_before(jiffies, psmouse->last + (HZ >> 6)) in this patch.
It is 1/64 second. I don't know how low it should go.
Comment 132 H.J. Lu 2008-03-13 21:44:47 UTC
time_before(jiffies, psmouse->last + (HZ >> 6)) doesn't work well. I
am using time_before(jiffies, psmouse->last + (HZ >> 4)) now.
Comment 133 H.J. Lu 2008-03-17 21:09:56 UTC
I am using time_before(jiffies, psmouse->last + (HZ >> 2)) now without
any problems.
Comment 134 H.J. Lu 2008-03-18 07:51:31 UTC
Created attachment 15329 [details]
An updated patch to reset PS/2 mouse

This patch uses time_before(jiffies, psmouse->last + (HZ >> 2)).
Comment 135 Natalie Protasevich 2008-05-02 15:55:05 UTC
Can you please submit the patch on the mailing list?
Comment 136 H.J. Lu 2008-05-02 16:48:35 UTC
(In reply to comment #135)
> Can you please submit the patch on the mailing list?
> 

My patch is incorrect. I am testing a new one.
Comment 137 Natalie Protasevich 2008-05-02 17:21:03 UTC
Great, thanks.
Comment 138 Daniel Santos 2008-05-21 12:29:47 UTC
I am having a problem with a Belkin "Flip" KVM with both my mouse and keyboard essentially becoming non-functional and I'm wondering if the problem springs from this same issue, but I'm not a hardware & Linux kernel guru, so I though I should ask here before posting a new bug.  It's not causing me much problems since I just don't use the crappy switch now (I have two keyboards and two mice on my desktop, blew), but I'm more obsessed with getting it fixed in the Kernel than anything else.

Sometimes, the mouse will still be powered up (i.e., laser on).  Often, on the 1st attempt to use the keyboard (i.e., pressing a key after power up), the numlock will light up for some 30mS or so.  On one occasion, it spamed the letters "kbkbkb" until I unpluged it.  Once, the mouse and keyboard worked after boot but stopped working later.

It worked before upgrading my system. Before I had an Asus M2NPV-VM motherboard that used an nForce 430 south bridge and I upgraded to a quad phenom AM2+ system that uses an MSI K92A Platinum mobo with an AMD SB600 south bridge (north bridge is an AMD790 FX if that matters).  I posted some details (logs & such) here: http://www.linuxquestions.org/questions/linux-hardware-18/belkin-flip-usb-kvm-switch-and-msi-k9a2-mobo-ochihcd-driver-problem-643348 and I would be happy to perform further tests, experiments, etc. and provide more info.

I am using the Gentoo 2.6.25-4 kernel (which behaved differently than 2.6.25-3 by the way).  I did a dry run with H.J. Lu's latest patch and it would work with an offset of one (i.e., Hunk x succeeded at yyy (offset -1 lines)), but this seems to only address issues with the mouse and I've yet to have a problem with the mouse pointer moving when it shouldn't.

Advice appreciated (new bug or related issue?)
Comment 140 Daniel Santos 2008-05-22 14:29:39 UTC
Sadly, it appears that I may have been suffering from a simple cabling problem (just like the driver's output suggested may be the problem) or other hardware (perhaps the KVM its self).  I'm guessing that everything was fine in low speed mode (got all of the device info from KVM, mouse , keyboard and keyboard's hub), but as soon as it tried to switch to high speed mode, whatever cabling problem I appear to be having cause communication failures because it is now working flawlessly moving stuff around some.  It may even have been due to completely powering down the KVM (unplugging it from all computers).

kernel: [186465.177306] hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?

Sorry for the false alarm.
Comment 141 Andres Mujica Ubuntu BugSquad 2008-08-11 19:03:02 UTC
Hi all, i'm linking this bug report to LP # 176326 as they are related.

Thanks a lot

https://bugs.launchpad.net/linux/+bug/176326
Comment 142 . 2008-09-09 20:16:25 UTC
Solution! Just avoid the problem! Here's how...

I too have been TRYING to move to Linux via KVM with these same aggravations.  I recently bought a new fancy KVM because it had audio (Cables to Go "TruLink VGA/Ps2 w/audio").  When I got it, I was a bit aggravated to learn this KVM uses a PS2 mouse(true PS2 mouse works best)and keyboard, but connects all PC's to the KVM via USB (using the USB HID protocol).  This config actually works great! I can even unplug and replug the keyboard and mouse, move the keyboard to a PC and back to the KVM with no issues!  My PC's have nothing in their keyboard and mouse PS2 ports!  Now I can actually start reliably switching to my Linux box! One caveat though for you gamers....

One of my PC's, I keep Windows 98SE for some old games.  I did notice that this KVM is not as fast as a direct PS2 port keyboard.  So, just for the WIN98 mode, I ran a PS2 extender cable and set it next to the KVM, so when I'm in the Win98 mode, I can move the keyboard from the KVM to the extended true keyboard port (and back without instability). This gives my Win98 mode keyboard a normal "office" speed, or a "gamer" speed.
Comment 143 . 2008-09-09 20:27:28 UTC
David,
In an effort to get us all up to date on this, has anyone outlined the proper way to turn on the fix in #104 for already built and running machines? I'm running Fedora 8 that has these issues and would like to avoid a new build or breaking something. 

tks
Comment 144 Will Foster 2009-02-16 17:04:51 UTC
I can confirm this happens in Fedora 10 (2.6.27.12-170.2.5.fc10.x86_64) as well.

I have to hit my KVM hotkey for that port several times for psmouse.c to resync successfully.  I am using a Belkin Omnicube 4port KVM.

psmouse.c: resync failed, issuing reconnect request
psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
psmouse.c: resync failed, issuing reconnect request.

I should also note that my KVM is not AC/powered, it simply uses the existing power flow from connected devices to power it, I do not know if this factors in at all however.
Comment 145 David Rosenstrauch 2009-09-09 18:01:42 UTC
(In reply to comment #143)
> David,
> In an effort to get us all up to date on this, has anyone outlined the proper
> way to turn on the fix in #104 for already built and running machines? I'm
> running Fedora 8 that has these issues and would like to avoid a new build or
> breaking something. 
> 
> tks

See comment #121.
Comment 146 Chris Cox 2011-05-28 06:58:22 UTC
If you specify protocol and resetafter=1... like:

psmouse.proto=imps psmouse.resetafter=1

Then I found that if I remember to screen lock before switching on the kvm, when I go back, a simple mouse button 1 will force the resync and I can unlock the screen and all it well.  It's not a solution... just a way to get the resync.
Comment 147 Valerio Vanni 2014-02-10 00:42:25 UTC
Is there any patch to try on 3.13.x?
I suffer from the same problem.

The mouse goes out of sync randomly [1] after an upgrade of Debian Lenny to Debian Squeeze.
The mouse goes through a KVM switch, and if connected directly to the PC it works.
The error is not related to the switch between PCs on KVM switch.
Comment 148 Valerio Vanni 2014-03-03 22:38:05 UTC
I've found this patch and tried importing it into a 3.13 kernel.
https://lkml.org/lkml/2005/11/9/47

It does not resolve but it renders the problem less bothering.

Without it, the mouse is left stuck forever (in dmesg I found "psmouse.c: %s at %s lost synchronization, throwing %d bytes away.\n") and the only possible recovery is to CRTL+ALT+Fx -> login -> rmmod psmouse -> modprobe psmouse.

With it, the mouse remains stuck only for 2-3 seconds, and then is able to move again (without any action!).

It doesn't, by the way, address the root of the issue. I've still not found what happened during the upgrade from Lenny to Squeeze [1], but there's something that triggers the "mouse going mad". I suspect of newer versions of Xorg.
If it goes mad three times a minute, it does with or without the patch.

It's the reaction to the issue that makes a great difference.
In a case it's needed to login in text console, giving commands etc; in the other it's enough to wait 2-3 seconds.

I ask: why the standard reaction of kernel is to leave the mouse stuck?


[1] It's not my particular upgrade: I can install a clean Squeeze, Wheezy, Jessie and the issue happens. I've also tried Fedora Core 20, just to give a try with something other than Debian: the issue remains.

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