Description of problem: Using kernel 2.6.0-test10 from the arjan-2.6-kernel-i386 apt archive on a PC with a PS/2 KVM attached to it. Switching to another input on the KVM and back makes the mouse "go mad" under X and GPM until you unplug it and re-attach it. The following error is shown in /var/log/messages too. kernel: psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away Version-Release number of selected component (if applicable): kernel-2.6.0-0.test10.* How reproducible: Every time. Steps to Reproduce: 1. Scr Lk Scr Lk 2 (to evil empire box) 2. Scr Lk Scr Lk 1 (back to Fedora Core desktop) 3. Actual results: Mouse moves in random, unexpected ways. Various pop-ups appear, panel moves, as if buttons were pressed on the mouse which weren't. Expected results: Mouse would continue to work as normal. Additional info: This reminds me of what happens if you say that a IMPS/2 mouse is PS/2 (or the other way around, I forget).
Fixed in latest kernel versions. Thanks - nic
The problem came back in kernel-2.6.0-0.test11.1.102 and is still there in kernel-2.6.0-1.104 so it ain't fixed. Perhaps I only dreamed that it was.
I've been following bug #115870 and I think that it might be a duplicate of this bug. Any thoughts? I still see this bug in kernel-2.6.2-1.87
I think that this bug is now fixed - for me at least. The kernel parameter has changed again between 2.6.1 and 2.6.2 and now works. I'm running 2.6.2-1.182 at the moment. For a Red Hat compiled kernel, the correct parameter is: psmouse.proto=imps As far as I'm concerned, this bug can be closed.
Okay. After reading bug #115713, I've tried adding "psmouse.proto=imps2" as a kernel option to kernel 2.6.2-1.85 and apart from not being able to use the scroll wheel *UP* (on the Fedora box), I can switch machines with my KVM just fine. I could not, however, use kernel 2.6.2-1.87. When using the 1-87 kernel I can't even start X11 (even though rhgb does so just fine). Actually I lie. :-/ I can start X11 at 800x600 in 16bpp. There seems to be a problem with the MGA dri module under that kernel (I'll go looking for a bug soon). I just wanted to ask: Is the scroll-wheel issue due to the psmouse.proto kernel option or a separate issue?
Actually this hasn't fully fixed the problem; though it looked like it had. Now, after I've booted I can switch about on my KVM, but if I leave my Fedora box for an extended period of time (so far all I can say is that it's somewhere between a minute and a few hours) then the problem reoccurs completely. Thoughts? Is there anything I could do to give you more information on this? This is a complete blocker on my using Fedora right now.
As an extra datapoint, the same fix works on the same set-up but with Mandrake 10.0 RC1 replacing the Fedora Core 1. Also, I assume it's a typo, but you wrote "imps2" instead of plain "imps" in comment 5 above. Cheers - nic
See also bug 124371 (dupe?)
Definitely looks like a dupe to me. And since adding "psmouse.proto=imps" to the kernel fixes it for me at least (on FC1, MDK 10, FC2), I don't see why this is still open unless Craig is still having his timeout problem
I'm afraid that I've still got this problem on FC2 (final) kernel-2.6.5-1.358 with the kernel param as above.
*** Bug 124371 has been marked as a duplicate of this bug. ***
This is open because when you use psmoue.proto=bare with an Intellimouse Explorer, you can switch but you get no scroll wheel functionality plus button 4 or 5. Last I heard, there is work being done in the kernel to fix the disconnects issue with Belkin switches.
I haven't checked the kernel mailing list since 2.6.1 for this, but I too have a Belkin switch... (Omni cube 4-port).
Same problem for me on FC2 with kernel 2.6.6-1.435 (from fedora) on X86_64. Sometimes, physically unplug-plug the mouse restores the correct behavior.
Is there any kind of work-around short of rebooting the affected box? I had a somewhat similar problem under 2.4 series kernels, but switching to a VT and back would reset the mouse. This no longer works under 2.6. I hear that unplugging the mouse from the KVM works as well, but digging through the cables is even worse than a reboot. By the way, I've tried all the mouse.proto= settings, and none keep this from happening. kernel 2.6.6-1.435 Belkin OmniView SE 4 port
Bernard: Its psmouse.proto=bare
The kernel guys have apparently fixed this. Can their patch be put into the next Fedora kernel release? http://bugme.osdl.org/show_bug.cgi?id=2082
I think I'm seeing this bug, except I don't have to switch to another KVM port first. I get erratic mouse behavior (move mouse slightly, jumps all over screen and clicks randomly) from both X and gpm. Connect/reconnect mouse doesn't seem to work. psmouse.proto=bare works, but is unacceptable as it kills the mouse wheel. 2.6.5-1.358 WORKS with psmouse.proto=exps and ExplorerPS/2 as the mouse type in X11. 2.6.6-1.427, .435, .435.2.1, and .435.2.3 all do NOT work with psmouse.proto=exps: I just get the same erratic behavior I get without specifying psmouse.proto. I did a "quick" build of 2.6.6-1.435.2.3 with the patch at http://bugme.osdl.org/show_bug.cgi?id=2082, but I just get the same behavior as in that bug's comment 16: constant messages about resetting the mouse, little or no movement most of the time, but an occasional cursor jump. I'm on x86, Belkin OmniView SE PS/2 (model F1D074), MS IntelliMouse Explorer 2.0A. Should I report this on the kernel bug? I'm not sure it's applicable since I'm not running a stock kernel.
darkness: can you try my patch (linkes) in bug 115713.
I have a Linksys 4-cpu switch, and a Logitech cordless trackball. The mopuse works fine in Linux 2.6.5-1.327 #1 Sun Apr 18 04:51:55 EDT 2004 i686 athlon i386 GNU/Linux, but every higher version of 2.6 shows the erratic mouse behavior described above in #18.
I have seen this symptom occasionally, particularly while installating FC2. It also happens sometimes on a fully-up2date-ed FC2 running the Gnome desktop. It's rare, but sometimes when I switch the KVM to the Linux box, I get a mouse pointer jumping wildly--mostly along the right and top edges of the desktop--with any mouse motion. The mouse buttons, however, seem to operate normally. If I get the mouse pointer onto a bit of clear desktop, I can right-click to launch a popup context menu, for example. This happens very rarely with the KVM switch, but I have found another way to produce the same symptoms every time. If I press the soft power button to force a suspend state, then wake the system up *with the keyboard*, then I get what appears to be the same state. (When I woke the system up with the mouse, I got no mouse function at all after wakeup--just a frozen silhouette of a mouse pointer.) This is an old P2/P3 MB, so maybe its power management support isn't quite right. Does anyone else here get this symptom on suspend?
Marko, I tried the patch linked by you from bug 115713 against Fedora Core 2 kernel-2.6.8-1.521 sources. The patch did not work with psmouse.proto=exps: I still experienced erratic mouse behavior (tested with gpm -t imps2, actually, so if you think I need to put exps2 in there I'll reboot and try again). Stock kernel-2.6.8-1.521 works fine with psmouse.proto=imps, as did the past few kernel versions, so I didn't try testing your patch with imps.
Cannot scroll up with mousewheel after switching back on Kernel 2.6.8-1.521, psmouse.proto=imps.
Another thing I noticed is that if I do this: 1) Switch to a different system before you boot the system with the intellimouse 2) Boot the system with the intellimouse without it switched on 3) Wait till you think its done loading into X Windows 4) Switch back I ALWAYS get erratic mouse behavior.
I tried the fix, and it works. By the way, what I mentioned in the previous comment, I noticed was just random luck. It doesn't really matter if I have this particular computer switched on or not when booting. Its just sometimes you can switch without the desynch happening. A fix is in the patch from http://bugzilla.kernel.org/show_bug.cgi?id=2082 works. Thanks to Dmitry Torokhov for the fix. When will this patch appear in Fedora? I'm giving the process I followed to use the patch below on how to use it. If you haven't ever recompiled the kernel, you might not wanna mess with it. It'll take a few seconds, I've found, before you can use the mousewheel to scroll up, but it still does work after the reconnect request. If you know how to compile the Fedora 2 kernel, then you're all set. Otherwise, what you need to do is (don't run each instruction without knowing what it does... You can really screw up your system if you don't know what you are doing). You can replace 2.6.8-1.521 with whatever in each instruction. I'm wondering why you can't use the default /lib/modules/2.6.8-1.521 when building 3rd party drivers such as nvidia after the following instructions (and have to tell it to use usr/src/linux-2.6.8-1.521 instead). Is there some trick that I'm missing?: 1) download the kernel source (for kernel-2.6.8-1.521, you'd use "yum install kernel-sourcecode") 2) cd /usr/src/linux-2.6.8-1.521 3) pushd drivers/input/mouse 4) download patch from http://bugzilla.kernel.org/show_bug.cgi?id=2082 5) mv location/to/the/patch/you/just/downloaded ./diff.txt 6) patch -p4 < diff.txt 7) popd 8) cp /boot/config-2.6.8-1.521 .config (replace kernel-2.6.8-i686.config with the correct architecture) 9) mv Makefile Makefile.bak 10) cat Makefile.bak | sed s/custom// > Makefile 11) make (just press enter for all the questions) 12) tar -cf /boot/2.6.8-1.521.bak.tar /boot/*-2.6.8-1.521* Make sure the following 4 files are backed up into the archive. You'll need them later if things don't go well: System.map-2.6.8-1.521 config-2.6.8-1.521 initrd-2.6.8-1.521.img vmlinuz-2.6.8-1.521 13) tar -cf /lib/modules/modules-2.6.8-1.521.bak.tar /lib/modules/2.6.8-1.521 Make sure that the contents of the archive are the same as /lib/modules/2.6.8-1.521 14) make bzImage 15) cp System.map /boot/System.map-2.6.8-1.521 (yes to overwrite) 16) cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.8-1.521 (yes to overwrite) 17) make modules 18) make modules_install 19) mkinitrd /boot/initrd-2.6.8-1.521.img 2.6.8-1.521 20) Now.... You'll need to rebuild Nvidia and any other 3rd party modules... For some reason, you need to tell it not to use its default source directory of /lib/modules/2.6.8-1.521 (If anyone knows why that is, please tell me). I did this: ./NVIDIA-Linux-x86-1.0-6111-pkg1.run --kernel-source-path /usr/src/linux-2.6.8-1.521 21) And then reboot. Now when you switch back and forth, you should occasionally see something like this in dmesg: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 - driver resynched. psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost sync at byte 4 psmouse.c: Wheel Mouse on isa0060/serio1 reports too many errors, issuing reconnect request
Just a "me too" - the patch from http://bugzilla.kernel.org/show_bug.cgi?id=2082 restores mouse sanity with this cheapo kvm of mine. I'm afraid the answer "when this will be fixed in FC" is "when the patch gets into upstream kernel" however.
*** Bug 128038 has been marked as a duplicate of this bug. ***
*** Bug 127431 has been marked as a duplicate of this bug. ***
*** Bug 132471 has been marked as a duplicate of this bug. ***
*** Bug 123273 has been marked as a duplicate of this bug. ***
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?
Sorry, bug 133616 and kernel bug http://bugzilla.kernel.org/show_bug.cgi?id=3461
I just installed FC3, and this bug is still present. I am using - generic 2 button PS/2 mouse (from a JavaStation) - Belkin 4 port switch - Dell Latitude J650 System installed fine. Installed all updates and rebooted. Still fine. Then I switched away to another machine and back. Crazy mouse. Managed to get terminal up and shut to single user mode. This was working in FC2.
I can confirm this occurs during initial install of FC3. Using: - Microsoft Wheel Mouse Optical USB and PS/2 compatible - Belkin 4-port PS/2 KVM, Model# F1D066 - PIII/450 and Daewoo CB650M-BX mobo. Note: The workaround mentioned, unplug and re-plugging the mouse from the KVM, seems to work, but is not quite where we want to be...
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.
I am experiencing the erratic mouse behavior using FC4 (kernel 2.6.14- 1.1653_FC4smp) and a Microsoft Intellimouse and a Belkin OmniView SOHO 4-port PS/2 KVM. I have added no kernel parameters at boot. My xorg.conf specifies the IMPS/2 protocol. Is there a current bug for this problem? This bug is closed/next version. I think FC4 would qualify as next next version, but the bug remains. Is there are workaround that does not sacrifice mouse functionality? If not, what workaround retains the most functionality? -Chris Hapgood