Bugzilla – Bug 115683
PS2 mouse loses sync sporadically - sudden wrong cursor moves and clicks
Last modified: 2006-04-21 13:39:11 UTC
Independent from any application - PS2 mouse loses sync sporadically. During this event - sudden wrong cursor moves and clicks occur. This happens a few times per hour. During such events there are the following entries in /var/log/messages: "[...]Sep 7 20:47:50 fischilinux2 kernel: psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away. [...]" Tested with X86 Laptop (Gericom Blockbuster 2440 XL DVD/CD-RW Uniwill N251S6 Series / see hwinfo.txt) for details. Tested with Genius Netscroll+EyePS/2 mouse and "noname" mouse. Problem exists since SuSE Linux 9.1. (Tested with SuSE 9.1 and OSS 10.0 beta4). Under SuSE 9.1 I found two measures to resolves the problem (only workaround). 1. Workaround: Stop Powersave Daemon Yast2 completely (Runlevel Editor "powersaved") 2. Workaround: Prevent ACPI modules from beeing load by editing /etc/sysconfig/powersave/common: # POWERSAVE_ACPI_MODULES="ac battery button fan processor thermal" # Note: One of the modules: "ac battery fan processor thermal" causes unintended mouse jumps and clicks POWERSAVE_ACPI_MODULES="button" Did not run any deeper debugging in OSS 10.0 beta4 so far. Thanks in advance!
Created attachment 49108 [details] /tmp/hwinfo.txt
Could that be thermal polling again?
Possibly, but as it's only a few times per hour, I more expect (doubled?) battery readings? You could do watch -n1 cat /proc/acpi/battery/*/* in the background. Mouse problems should be much worse now if it's the battery. If your BIOS provides constant battery events you could try to: /etc/sysconfig/powersave/battery FORCE_BATTERY_POLLING="no" and/or increase the battery polling interval.
Thanks for your hints. I tried "watch -n1 cat /proc/acpi/battery/*/*" (1 second polling). See attachment/etc/sysconfig/powersave/battery "output_battery_polling.txt" for a console screenshot. This test did not cause a 1 second "malfunction intervall". But when doing this test --> problem occured about every two minutes. See /var/log/messages entries below: ******** Sep 12 20:15:21 fischilinux2 kernel: psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away. [...] Sep 12 20:17:07 fischilinux2 kernel: psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away. Sep 12 20:19:36 fischilinux2 kernel: psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away. Sep 12 20:22:04 fischilinux2 syslog-ng[4455]: STATS: dropped 0 Sep 12 20:24:47 fischilinux2 kernel: psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away. ************ The mouse problem still occours sporadically. I can't determine a very strong dependency to the battery polling test. I will try the changes in /etc/sysconfig/powersave/battery (described above) and report later! Thanks and best regards, Uwe I will try the change
Created attachment 49672 [details] output of "watch -n1 cat /proc/acpi/battery/*/*"
Today I tried the following: 1. In /etc/sysconfig/powersave/battery, set 'FORCE_BATTERY_POLLING="no"' --> No improvement, still a few sync losses per hour (~3...10) 2. In /etc/sysconfig/powersave/battery, set 'FORCE_BATTERY_POLLING="yes"' and set 'BATTERY_POLLING_INTERVAL="3600"' --> No improvement, still a few sync losses per hour (~3...10) What shall I test next?
I have the same problem on an IBM thinkpad R31 (celeron 1.06GHz) with a trackpoint mouse and SuSE 10.0 retail installed. It seems to me that it's even worse, as I have only to make some very fast movements, to produce the sync loss message. psmouse.c : Mouse at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away. Updating to the latest bios version (3.11) did not change anything to the problem. I also transfered the HD on an other R31, no change. Starting the laptop failsafe is a workaround that works.
Seen the same problem with the Dell Inspiron 8500 provided I use the pad. If I use the little joystick-type lever the problem doesn't appear.
Sorry for answering that late... the severity of this bug should have been higher. Could someone please retry with the latest OpenSuse 10.1 Alpha XY version. If you still see this problem, this needs to be fixed urgently. However, a lot of changes have been done in ACPI code, I could try to backport if it's already fixed, but that could get difficult as chances are high that it breaks other machines. You should also make sure you are running the latest BIOS provided by your vendor.
Could someone please try the latest OpenSuse 10.1 distribution and verify whether it is fixed there.
You should be able to workaround the problem by: a) Setting: THERMAL_POLLING_FREQUENCY="0" in /etc/sysconfig/powersave/thermal and avoid batttery reads as far as possible as described in comment #6. or b) Avoid loading of thermal and battery module at all by throwing out thermal and battery modules in: INITRD_MODULES /etc/sysconfig/kernel (invoke mkinitrd after that) and in ACPI_MODULES="" (e.g. only add button,ac,...) Also be sure you have the latest BIOS installed! I saw similar things vanishing on some machines by doing a BIOS updated. No answer for a long time, therefore I close this one for now. Please reopen if this is still happening.