Distribution: Debian Unstable (sid) Hardware Environment: Celeron i810 board, MS intellimouse optical USB with PS2 adapter, belkin Omni View Pro (4 ports automatic Data switch) Software Environment: XFree 4.2.1 Problem Description: when switching back to linux using the data switch, the mouse does all wrong (same as if I was moving the mouse in all ways while clicking like a fool but I've only moved by 2 cm !) Steps to reproduce: not sure if it comes from the data switch or anything else. The problem doesn't exist in 2.4 tree. I think that a test with another switch of another brand might be interesting.
The problem is that when you switch the switch the mouse gets reset to standard PS/2 mode. If the psmouse.c driver operates it in ImPS/2 or ExPS/2 mode, it'll have troubles, because PS/2 have 3 bytes per packets and the others have 4 bytes per packet. To make sure both the systems use the mouse in PS/2 mode, use the 'psmouse_noext' kernel command line options.
ok, appending "psmouse_noext" solves the problem. Thanks Vojtech. Sadly, I've lost a feature in the battle: the wheel mouse. Forcing pure PS/2 mode make loosing it... Do you see any way to have the problem solved, and the wheel working again ? (seems not as it come from the data switch, but this is working in 2.4 ! so I ask the question ;-)
Distribution: gentoo Hardware: Gigabyte GA-7VAXP motherboard+athlonXP2000 CPU Normal PS/2 mouse ( Genius, Netscroll+ ) Software: Linux 2.6.0-test1 + XFree 4.3.0 using IMPS/2 protocol in XF86Config I don't use any data switch, the Mouse and keyboard uses normal PS/2 ports directly, but I have a similar (same?) problem. Sometimes (about once in 1-2 hours) when I switch back from normal terminal to X, I get the following messages in the log: agpgart: Found an AGP 2.0 compliant device at 00 00:00:00.0. Jul 21 21:44:29 danhome kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 i nto 4x mode Jul 21 21:44:29 danhome kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 i nto 4x mode Jul 21 21:44:29 danhome kernel: [drm] Loading R200 Microcode Jul 21 22:04:33 danhome kernel: psmouse.c: Lost synchronization, throwing 3 byte s away. The last message is sometimes mentions throwing 1,2, or 3 bytes.
An additional note to my previous comment: The same error occures when I leave my computer idle for some time (example: for 30 seconds), and then want to continue my work by using the mouse. (under X environment)
I get this bug too, on a Sony PCG-C1MV laptop, kernel 2.6.0-2 from Debian. Sometimes the mouse just starts jumping around, and I get these psmouse.c mouse at (here some random characters) lost synchronization thrown 2 bytes away
I got this bug too, the mouse went crazy for a second - it moved very quickly to the edge of the screen and clicked randomly. I wasn't doing anything specific like changing virtual console, I was just using a web browser in X. Syslog said: Feb 13 03:39:25 localhost kernel: psmouse.c: Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. I was using 2.6.2, XFree 4.3.0 on Gentoo with an ordinary 3 button PS/2 mouse. I've been using 2.6.2 for about a week now and it's only happened once. It never happened in 2.4.2x - ie I don't think the mouse is dodgy.
The byte-lost issue was fixed in 2.6.3-rc1. The KVM issue is not fixed yet, and I'll probably have to get me a KVM to test with.
I have the same problem that http://bugzilla.kernel.org/show_bug.cgi?id=779#c5 has, but with a 2.6.6 kernel
I am having the same problem with 2.6.9 on an IBM Thinkpad T20 with the built in trackpoint. It occurs frequently, especially with high CPU load. Trying to move the mouse when the CPU load is high is almost certain to trigger the problem. It seems to happen more frequently on a preemptible kernel.
Created attachment 4377 [details] remove packet reset do not throw bytes away
patch 4377 do not solve bug, but I see that strange things do not happen: mouse just stop and consume cpu as usual, but no spurious input go in. This is just an idea on which to investigate.. why this happen? BTW, is better a mouse that block than a mouse which do strange thing
Hi Daniele, Dmitry posted some patches on LKML ([RFC/RFT] Better handling of bad xfers/interrupt delays in psmouse), which may affect this bug? Can anyone test this to see if it helps with these errors? Thanks, Nish.
No that patch is unlikely to help with protocol reset problem that often happens when switching KVM... It should help in case you have a bad cable or something (like disk activity) delays delivery of mouse interrupt. I still can't come up with a reliable way to detect that mouse has been reset.
Well, we could be running the mouse completely in polling mode. That'd take care of the protocol change problems.
Ok, re-reading all the comments to this bug I see that 2 issues have been mixed here. One is that mice are reset when switching KVM and this issue is not fixed yet. The second issue is that mouse starts misbehaving under load or when KBC reports a timeout or a parity error. For that issue I have a patch that I would like people to test. The version for 2.6.10 can be found here: http://www.geocities.com/dt_or/input/2_6_10/ I am very interested in results. Thanks in advance!
Re: polling mode - Synaptics immediately reverts into PS/2 compat mode if you poll it. I wonder what ALPS does. And not very efficient. Plus some people like to run notebook + KVM on a boxes without an active MUX and I have no idea who will reply to poll in this case.
Can't the target of subsequent commands be selected by some ALPS commands? I remember some comments in that direction in the source code.
That's for switching between the touchpad and trackpoint and on ALPS only. You need to know that you are talking to an ALPS. But on many notebooks (Dell for exaple) there is no active MUX and they deliver data from an external PS/2 port and from the touchpad to the same serio port and there is no way to determine where the data is coming from. Well, actually on my Inspiron 8100 if I plug external mouse it completely shadows the touchpad so it stops even responding to synaptics queries.
(replay to #c15) I found there are at least two open bugs for this issue, which actually speak about 2 issue. I think KVM issue should be discussed in http://bugzilla.kernel.org/show_bug.cgi?id=2082 Dmitry, I'll try your patch soon (actually tomorrow)
Any progress with this bug? Thanks, Nish
I'm with kernel 2.6.12.2, and still I get: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. esgrovas@lapy ~ $ dmesg | grep psmouse.c | wc -l 171 from like... 5 minutes of usage
Where do we stand on this bug with the latest releases? The last comment is from 2.6.12, two full releases ago. Dmitry / Vojtech, do you have any ideas on how to resolve this one? Thanks, Nish
Still get this problem with 2.6.15.1 on IBM Thinkpad R51. Tried the psmouse_noext kernel command line option and various CONFIG_PREEMPT and HZ values. Very reproducible under IO load.
This seems not to happen in 2.6.16-rc1 anymore.
Well, since nobody else (beyond Michael) responded to the bug when I asked if it was still present in current kernels, and since Michael's issues seem to be gone in 2.6.16-rc1, shall I close the bug? It can of course be reopened if the problem resurfaces.
Closing the bug. Can be reopened, of course. Thanks, Nish