Bug 2082
|
Description
Mauro M.
2004-02-12 02:55:06 UTC
Kernel 2.6.3 has the same problem. Tested on Dual Pentium III configuration, the same problem applies 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? :-). 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. 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. Have you tried psmouse.proto=imps? If your KVM (and the other machine) supports the IMPS/2 protocol, then that should work, too. 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. 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). Same problem on kernel linux-2.6.5-rc3 Same problem on kernel 2.6.5. I give up working with kernel 2.6. 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? 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.
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. 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.
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! 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. 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 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 :) It goes berserk on Windows too. Its probably a result of the polling frequency being low. *** Bug 3004 has been marked as a duplicate of this bug. *** 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 By the way, when will this be in the kernel? 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? 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
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? 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. 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. 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 Ouch! What bug number is that new blocker bug? Remind me not to install kernel 2.6.9 ;-) Could you provide the output of SysRq-P when the box locks up? That would tell use where it is spinning. Created attachment 3847 [details]
imps2 busmouse resync patch for kernel 2.6.9-rc4
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 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? 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!
What happens if a disconnect and reconnect all happens in faster than the polling frequency? 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. 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 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 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! 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? Scratch that, I just realized that the issue with the Logitech mouse is the cursor stops moving, not erratic behavior. 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 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. 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
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.
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
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.
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. 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. Created attachment 4557 [details]
PS2 mouse resync for kernel 2.6.10 (and hopefully higher)
Patch re-attached as plain text (patch).
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. 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
*** Bug 4564 has been marked as a duplicate of this bug. *** 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, 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
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, 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!
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 ! 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 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 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 Ugh, "resync" is not valid, make it "reconnect": echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl 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 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 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 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... 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 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 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. 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. Please, could we take this latest fix to the kernel mainstream? 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.
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. *** Bug 1255 has been marked as a duplicate of this bug. *** 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.
*** Bug 4469 has been marked as a duplicate of this bug. *** 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. I have tested this both on Fedora %5 (test2) and EzPlanet One 3.0 beta and it works fine. 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. 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! 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!
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. I'll be away until tuesday. I will send debugging info when I get back. 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. Lukas, please reopen this bug if it happens again. 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.
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.
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.
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! 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
Does this problem persist with current kernels? Otherwise I suggest we close this bug. 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 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. 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 #@!$ If you have a patch that would reliably fix this problem on all boxes out there I will gladly push it upstream. 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. ... 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. 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. 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. 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. 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.
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). 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. 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/ 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. 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... 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. 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. 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 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. 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). 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. 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. 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. 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?
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 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.
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. 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! 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.... 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. (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? 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. 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.
Created attachment 13379 [details]
The kernel log before and after KVM switch
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). Dmitry, would you comment on the patch in #124? I suppose it hasn't been submitted. 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. (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. Thanks, this will be appreciated. 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.
time_before(jiffies, psmouse->last + (HZ >> 6)) doesn't work well. I am using time_before(jiffies, psmouse->last + (HZ >> 4)) now. I am using time_before(jiffies, psmouse->last + (HZ >> 2)) now without any problems. Created attachment 15329 [details]
An updated patch to reset PS/2 mouse
This patch uses time_before(jiffies, psmouse->last + (HZ >> 2)).
Can you please submit the patch on the mailing list? (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. Great, thanks. 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?) correction, bad link, (and yes, I mistyped "ohci"): http://www.linuxquestions.org/questions/linux-hardware-18/belkin-flip-usb-kvm-switch-and-msi-k9a2-mobo-ochihcd-driver-problem-643348/ 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. 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 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. 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 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. (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. 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. 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. 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. |