Bug 427697

Should be fixed in 2.6.23.14-113 and up.

Problem persists with 2.6.23.14-113:

Jan 20 10:23:14 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, 
throwing 5 bytes away.
Jan 20 10:23:21 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, 
throwing 1 bytes away.
Jan 20 10:23:23 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, 
throwing 4 bytes away.
Jan 20 10:23:24 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, 
throwing 3 bytes away.

[wade@milan ~]$ uname -a
Linux milan.localdomain 2.6.23.14-113.fc8 #1 SMP Fri Jan 18 20:04:40 EST 2008 i686 i686 i386 GNU/
Linux
[wade@milan ~]$ 

Problem persists with 2.6.23.14-115, albeit less often/severe:

Feb  7 20:15:56 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost 
synchronization, throwing 2 bytes away.

[root@milan ~]# uname -a
Linux milan.localdomain 2.6.23.14-115.fc8 #1 SMP Mon Jan 21 14:20:50 EST 2008 
i686 i686 i386 GNU/Linux

Problem persists with 2.6.24.3-12.fc8

2.6.23.1-42.fc8 still works fine


[root@milan ~]$ uname -a
Linux milan.localdomain 2.6.24.3-12.fc8 #1 SMP Tue Feb 26 14:58:29 EST 2008 i686
i686 i386 GNU/Linux

[root@milan ~]# grep psmouse.c /var/log/messages
Mar  7 18:40:14 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 4 bytes away.
Mar  7 18:40:15 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 1 bytes away.
Mar  7 18:40:18 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 3 bytes away.
Mar  7 18:40:20 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 3 bytes away.
Mar  7 18:40:22 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 1 bytes away.

What make/model of machine is this happening on?

This is a Dell Inspiron B130.  I'm not at the system right now, but it's a
Centrino platform, all-intel hardware (Pentuim M 1.8GHz, ipw2200, i915, etc)
except for a Broadcom ethernet port and Synaptics touchpad.  Nothing exotic.

I can post the output of lspci or similar... It's also registered with Smolt so
when I get home I can grab the UUID as well.

Smolt: 
http://smolt.fedoraproject.org/client/show/?uuid=pub_e4865162-dd92-4759-a833-dba3a5c3219d

lspci:


[root@milan ~]# lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express
Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express
Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High
Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE
Controller (rev 03)
02:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
02:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network
Connection (rev 05)

Problem still exists on 2.6.24.3-12.fc8 #1 SMP Tue Feb 26 14:21:30 EST 2008
x86_64 x86_64 x86_64 GNU/Linux.

I have a Dell Latitude D830 (smolt ID 664a90b7-d643-4852-a119-2b3150bdb3ce) with
a touchpad.  If I leave the keyboard alone for a minute, then try and move the
mouse, the system doesn't respond.  The output in /var/log/messages is:

Mar 16 14:06:03 mordac kernel: psmouse.c: GlidePoint at isa0060/serio1/input0
lost sync at byte 1
Mar 16 14:06:03 mordac kernel: psmouse.c: GlidePoint at isa0060/serio1/input0
lost sync at byte 1
Mar 16 14:06:04 mordac kernel: psmouse.c: GlidePoint at isa0060/serio1/input0
lost synchronization, throwing 1 bytes away.
Mar 16 14:06:08 mordac kernel: psmouse.c: resync failed, issuing reconnect request
Mar 16 14:07:34 mordac kernel: psmouse.c: GlidePoint at isa0060/serio1/input0
lost synchronization, throwing 1 bytes away.
Mar 16 14:07:38 mordac kernel: psmouse.c: resync failed, issuing reconnect request

After a few hangs, the laptop will blink Caps Lock and Scroll Lock on and off
and is totally unresponsive.  You cannot even ping the laptop from a remote
host.  The only thing that works is a hard power cycle by holding down the power
button.

I have tried the latest development kernel 2.6.24.3-22 and it also exhibits the
lockup.  I have also tried nohz=off and noapic and neither eliminate the problem.

This is issue is critical, as it makes the OS unusable.  I have seen various
posts across many distributions about this problem.  It looks like a problem in
the kernel input code.

Here is the xorg.conf:

[root@mordac sysconfig]# more /etc/X11/xorg.conf
# Xorg configuration created by livna-config-display

Section "ServerLayout"
        Identifier     "single head configuration"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Synaptics" "CorePointer"
EndSection

Section "Files"
        ModulePath   "/usr/lib64/xorg/modules/extensions/nvidia"
        ModulePath   "/usr/lib64/xorg/modules"
EndSection

Section "ServerFlags"
        Option      "AIGLX" "on"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us+inet"
EndSection

Section "InputDevice"
        Identifier  "Synaptics"
        Driver      "synaptics"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "auto-dev"
        Option      "Emulate3Buttons" "yes"
        Option      "LeftEdge" "120"
        Option      "RightEdge" "1100"
        Option      "TopEdge" "120"
        Option      "BottomEdge" "650"
        Option      "FingerLow" "14"
        Option      "FingerHigh" "15"
        Option      "MaxTapMove" "110"
        Option      "VertScrollDelta" "20"
        Option      "HorizScrollDelta" "20"
        Option      "MinSpeed" "0.6"
        Option      "MaxSpeed" "1.1"
        Option      "AccelFactor" "0.6"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        Option      "NoLogo"
        Option      "AddARGBGLXVisuals" "True"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Section "Extensions"
        Option      "Composite" "Enable"
EndSection

Sorry, smolt id =
http://www.smolts.org/client/show/?uuid=pub_7faf2724-77d5-4fd5-845a-24774ff25393

After spending time testing this freeze, I discovered that the FC8 x86_64 LiveCD
did not exhibit the problem.  This made me realize that it was a kernel issue.

Further testing of the following kernels:

kernel-2.6.23.15-137.fc8.x86_64.rpm
kernel-2.6.23.14-115.fc8.x86_64.rpm
kernel-2.6.23.14-107.fc8.x86_64.rpm
kernel-2.6.23.9-85.fc8.x86_64.rpm
kernel-2.6.23.8-63.fc8.x86_64.rpm

all exhibited the freeze -- which incidentally occurs approximately 30 seconds
after the mouse is no longer being moved on the desktop.

The problem does not exist on:
kernel-2.6.23.1-49.fc8.x86_64.rpm
kernel-2.6.23.1-42.fc8.x86_64.rpm (kernel on LiveCD)

Something changed between 1-49 and 8-63 which causes the system to freeze
momentarily (even the Gnome System Monitor freezes), and then when the mouse is
moved, the kernel spits out the error messages from psmouse.c.  I now believe
that the psmouse.c messages are a symptom that results after the freeze occurs.  

I tried various combinations of kernel parameters such as:
psmouse.proto=exps
nohz=off highres=off
noapic
apic=force irqpoll

none of which worked.

Correction -- it is also occurring in 2.6.23.1-49.fc8.x86_64.  It just takes a
much longer time for the freeze to happen.

Try adding:

  i8042.nomux=1

to the kernel boot options.

Also try:

  i8042.noloop=1

Just tested on 2.6.24.3-34 with both boot options.  Neither fixed the lockup.

Neither boot option helped in my case either.  Problem persists.

[root@milan ~]# uname -a && uptime && grep psmouse /var/log/messages

Linux milan.localdomain 2.6.24.3-50.fc8 #1 SMP Thu Mar 20 14:47:10 EDT 2008 i686
i686 i386 GNU/Linux

 15:03:39 up 7 min,  2 users,  load average: 1.39, 1.25, 0.64

Mar 30 15:02:24 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 1 bytes away.

At least in my case, this isn't Fedora-specific.  Out of curiosity I tested out
OpenSuse 11.0 beta, Debian testing, and Mandriva 2008.1.

I get this exact same issue in all of the above except Mandriva. Mandriva 2008.1
runs kernel 2.6.24, Debian kernel is 2.6.25.

I'm not sure if or which kernel config option is triggering this.  FWIW, I'll
attach the Mandriva 2.6.24 kernel config, which doesn't reproduce this issue. 
I'll also attach the Debian 2.6.25 kernel config, which does reproduce this issue.

So far all Fedora 8 kernels I've tested above and current kernels produce this
issue.  Haven't tested Fedora 9 yet.

Created attachment 304496 [details]
Mandriva 2.6.24 kernel config

This kernel configuration does not reproduce this issue.

Created attachment 304497 [details]
Debian 2.6.25 kernel config

This kernel config does reproduce this issue.

I'm experiencing the same problem on my Dell Latitude D630.  It seems to be at
least partially related to my Intel wireless card.  I had the mouse resync
problem on Fedora 8 with an Intel 3945 card, but as soon I switched to an Intel
4965AGN card, the resyncs got much more frequent and the system started to
freeze with the caps lock and scroll lock lights flashing.  I installed Fedora 9
yesterday, but the problems are still occurring.  I noticed today that the WiFi
light also flashes during the system freeze.  Could there be some conflict
between the Intel wireless and touchpad drivers/firmware?

I am running into similar errors on my Dell m1530.  I am running the iwl4965
driver and an Alps touchpad (synaptics).  I have tried numerous synaptic changes
to no avail, so I think it is either a kernel issue or network/touchpad driver
conflict.  I have received the same errors in dmesg on both Fedora 8 & 9:

psmouse.c: Failed to reset mouse on isa0060/serio1
input: PS/2 Generic Mouse as /class/input/input13
psmouse.c: Failed to enable mouse on isa0060/serio1
psmouse.c: bad data from KBC - bad parity
psmouse.c: bad data from KBC - bad parity
psmouse.c: bad data from KBC - bad parity
psmouse.c: bad data from KBC - bad parity
psmouse.c: bad data from KBC - bad parity
psmouse.c: bad data from KBC - bad parity

Please try adding _both_ of these options to the kernel boot options:

  i8042.nomux=1 psmouse.proto=imps

Created attachment 306926 [details]
dmesg output

I tried booting with both parameters and am still experiencing the
freezing/resync problem after about 30 seconds of inactivity with kernel
2.6.25.3-18.fc9.x86_64.  My dmesg output is attached.

hi,
i'm seeing the same problem on a compaq laptop.
it only happens when reading from the dvd drive.
during this time the sound also stutters (snd-ati-ixp).

there are no problems if i read a similar avi file from the hard disk.

booting with "i8042.nomux=1 psmouse.proto=imps"
works in that the "lost synchronization, throwing n bytes away" messages
disappear, but the mouse lags a lot (it feels like high latency) and the sound
still stutters.

i'll attach a dmesg of the machine without the above boot options.

Created attachment 307287 [details]
compaq touchpad dmesg no extra boot options

sorry i forgot to mention that this problem is on f9.
there was no such problem on f8 with the same machine.

(In reply to comment #20)
> Please try adding _both_ of these options to the kernel boot options:
> 
>   i8042.nomux=1 psmouse.proto=imps
> 

i was having the same problems noted on my dell D420 laptop.  setting
i8042.nomux=1 along with unchecking the gnome power manager preferences
configuration option "Dim display when idle" from the "On Battery Power" tab.

setting the psmouse.proto=imps kernel option causes the touchpad to not be
recognized in Xorg.  this is all using fedora 8 recently updated with
2.6.25.4-10.fc8.

FYI

replying to my own comment since i left out the meat of it:

(In reply to comment #25)
> (In reply to comment #20)
> > Please try adding _both_ of these options to the kernel boot options:
> > 
> >   i8042.nomux=1 psmouse.proto=imps
> > 
> 
> i was having the same problems noted on my dell D420 laptop.  setting
> i8042.nomux=1 along with unchecking the gnome power manager preferences
> configuration option "Dim display when idle" from the "On Battery Power" tab.

the above should have said:

i was having the same problems noted on my dell D420 laptop.  setting
i8042.nomux=1 along with unchecking the gnome power manager preferences
configuration option "Dim display when idle" from the "On Battery Power" tab
resolved the issue for me.

sorry for any confusion.

> setting the psmouse.proto=imps kernel option causes the touchpad to not be
> recognized in Xorg.  this is all using fedora 8 recently updated with
> 2.6.25.4-10.fc8.
> 
> FYI
> 

enjoy.

None of the aforementioned kernel parameters made any difference for me.  The
problem persists on Fedora 9. The "lost synchronization" messages occur on their
own, but they also occur whenever I get "ipw2200: Firmware error detected. 
Restarting." message.

The changes to "Dim displayu when idle" and i8042.nomux=1 kernel parameters did
not fix the problem on a Dell D830.  I still can only run on the 2.6.23.1-42 kernel.

Some combination of the latest kernel (2.6.25.6-55.fc9.x86_64), setting both
i8042.nomux=1 and psmouse.proto=imps as kernel parameters, and disabling "Dim
display when idle" in BOTH on AC and on battery seems to have fixed the problem
on my Dell Latitude D630.  I haven't experienced the freezing for several days
now when before it would be almost once every minute or two.

After toying around i can confirm comment #29, this combination of the following
alleviates the issue on my system (Dell Inspiron B130, all Intel hardware 'cept
the touchpad & ethernet):

1) setting "i8042.nomux=1 psmouse.proto=imps2" kernel options
2) unchecking "Dim display when idle" in Gnome's power preferences

I haven't had time to play around enough to determine if it's just Gnome's "Dim
display when idle" that's causing issues or if the boot options are helping as well.

it appears not all freezing is solved for me.  earlier this evening while
viewing a flash video over the network the video started skipping after some
period of inactivity from keyboard or mouse.   this happened before but i
associated it with the mouse freezing and the same psmouse.c log messages as
reported earlier.

here is my smolt profile in hopes that it will give some additional information
in common with the others already reported:

http://www.smolts.org/client/show/pub_e333c4ec-3d18-4fec-903f-b56d8da8f5db

the mouse freezing portion of the issue is going very well - no recent freezes
until the flash video over the net problem this evening.

Unchecking "Dim display when idle" on BOTH "On AC Power" and "On Battery Power"
in the GNOME Power Manager preferences tab fixed the problem with my Dell D830.
 After 30 seconds, my mouse no longer freezes up with the CPU running full bore
and dmesg logging the psmouse.c errors.  Thanks for finding the solution David.
 Should we open a bug against the Power Manager?

well, since we're not getting any feedback from the actual developers on this
bug i don't know what may really be at fault.  there is definitely an
interaction that involves the power subsystem for the display (dim while idle on
battery issue), the i8042 driver and the psmouse driver at a minimum.

it would be useful if a developer could chime in here and help us help them to
get this actually fixed instead of band-aided.

the stuttering and mouse freeze issue _only_ happens while on battery power for
my Dell D420 laptop.  on AC power it works just fine w/o any issues.

Well, it seems that Gnome's "Dim display when idle" is causing problems.  I can
adjust the screen brightness manually without any issues.  Booting the default
11.0 kernel without any special boot params and disabling Gnome's "Dim display
when idle" for both AC and battery power seems to eliminate the problem.

I do, however, *occasionally* get the following messages when switching from AC
to battery power.  It doesn't happen every time.  There is a display brightness
change when going back & forth between AC & battery power as well.


"grep -B2 -A2 psmouse /var/log/messages" (last few occurrences):

Jun 25 17:11:19 milan kernel: ipw2200: Firmware error detected.  Restarting.
Jun 25 17:12:21 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 4 bytes away.
Jun 25 17:12:23 milan kernel: ipw2200: Firmware error detected.  Restarting.
Jun 25 17:12:56 milan syslog-ng[1598]: last message repeated 2 times
--
Jul  7 10:53:20 milan kernel: ipw2200: Firmware error detected.  Restarting.
Jul  7 10:53:34 milan syslog-ng[1621]: last message repeated 4 times
Jul  7 10:53:34 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 2 bytes away.
Jul  7 11:07:19 milan syslog-ng[1621]: STATS: dropped 0
Jul  7 11:07:37 milan smartd[2490]: Device: /dev/sda, SMART Usage Attribute: 194
Temperature_Celsius changed from 39 to 36
--
Jul  8 10:04:51 milan kernel: ipw2200: Failed to send SYSTEM_CONFIG: Already
sending a command.
Jul  8 10:04:52 milan kernel: ipw2200: Firmware error detected.  Restarting.
Jul  8 10:04:52 milan kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 2 bytes away.
Jul  8 10:04:54 milan kernel: ipw2200: Firmware error detected.  Restarting.
Jul  8 10:04:54 milan kernel: ipw2200: Firmware error detected.  Restarting.

(In reply to comment #34)
> Booting the default 11.0 kernel 
Sorry, head in the clouds, meant updated F9 kernel

possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power

shaharf, blorb

This bug is not present in Fedora 10 kernels.

The bug was gone... but now it's back for a while.
Same problem. System is on battery and gnome tries to dim the display.
Mostly the system hook up for a second... sometime it ends with a complete freeze.

I'm using a Dell Latitude D820 and I suppose, the most affected notebooks seems to be from Dell.

### cut begin ###

# uname -a
Linux santa 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 i686 i386 GNU/Linux

### cut end ###

Is someone out there, who also have the problem again?

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I am still experiencing the issue on kernel-2.6.36, and kernel-2.6.34, reopening

Now I am having this weird behaviour.

Sometimes, when booting F-14, touchpad fails to be detected with kernel 2.6.36 ( rebuilt for f14 from koji). Rebooting doesn't do any good, rebooting F-13 with latest stock kernel doesn't do any good either. However, booting with ubuntu 10.04 liveusb makes the mouse work ok, then restarting in both F-14 or F-13 makes the touchpad work again.

I've seen it on 2.6.40.

And in 2.6.40.4-5 (but the touchpat occasionally loses advanced configuration like scrolling or stops working entirely leaving mouse pointer frozen).

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Is this still a problem with 3.9 based F19 kernels?

This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks.  If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.