mouse still losing sync and thus jumping around

mouse still losing sync and thus jumping around

[Nils Kalchhauser]

Hi!


I still get the following messages and my mouse jumps around weirdly 
making work rather difficult regardless of which 2.6 kernel I use (tried 
2.6.8, 2.6.9, 2.6.10, 2.6.11-rc2 with patch-see below, 2.6.11-rc4):

psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 
2 bytes away.
psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 
2 bytes away.
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1

(using either the touchpad or the connected PS/2 mouse)

I tried the patch Dmitry Torokhov supplied in the message with subject 
"Re: Really annoying bug in the mouse driver" from Jan 27 which 
supposedly fixes this problem. unfortunately it only got worse.

the problem is really annoying with windows sometimes closing because of 
sporadic mouse clicks etc. I would happily try patches and help in 
debugging, so if anyone has an idea or if more info about my 
setup/config is needed, just tell me.


thanks a lot,
Nils

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser
<n.kalchhauser@vollwerbung.at> wrote:
> Hi!
> 
> I still get the following messages and my mouse jumps around weirdly
> making work rather difficult regardless of which 2.6 kernel I use (tried
> 2.6.8, 2.6.9, 2.6.10, 2.6.11-rc2 with patch-see below, 2.6.11-rc4):
> 
> psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing
> 2 bytes away.
> psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing
> 2 bytes away.
> psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
> psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> 
> (using either the touchpad or the connected PS/2 mouse)
> 
> I tried the patch Dmitry Torokhov supplied in the message with subject
> "Re: Really annoying bug in the mouse driver" from Jan 27 which
> supposedly fixes this problem. unfortunately it only got worse.
> 

Hi,

There were 2 versions of the psmouse-resend patch, the first one was
indeed producing worse results, the second one should work better.
Could you please try grabbing the patch against 2.6.10 from here:

http://www.geocities.com/dt_or/input/2_6_10/

and letting me know if it gives better results.

Thanks!
 

-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[Nils Kalchhauser]

Dmitry Torokhov wrote:
> On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser
> There were 2 versions of the psmouse-resend patch, the first one was
> indeed producing worse results, the second one should work better.
> Could you please try grabbing the patch against 2.6.10 from here:
> 
> http://www.geocities.com/dt_or/input/2_6_10/
> 
> and letting me know if it gives better results.

sorry for not realising that there was a newer patch. I tried that one 
now and indeed it seems a lot better. I did not have any lost sync 
message for about an hour but then the mouse started jumping again. and 
it seems to me like it is connected to disk activity... is that possible?


Nils

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser
<n.kalchhauser@vollwerbung.at> wrote:
> Dmitry Torokhov wrote:
> > On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser
> > There were 2 versions of the psmouse-resend patch, the first one was
> > indeed producing worse results, the second one should work better.
> > Could you please try grabbing the patch against 2.6.10 from here:
> >
> > http://www.geocities.com/dt_or/input/2_6_10/
> >
> > and letting me know if it gives better results.
> 
> sorry for not realising that there was a newer patch. I tried that one
> now and indeed it seems a lot better. I did not have any lost sync
> message for about an hour but then the mouse started jumping again. and

Was it clicking around or just the movement was jerky?

> it seems to me like it is connected to disk activity... is that possible?

Yes, It usually happens either under high load, when mouse interrupts are
significantly delayed. Or sometimes it happen when applications poll
battey status and on some boxes it takes pretty long time. And because
it is usually the same chip that serves keyboard/mouse it again delays
mouse interrupts.

Btw, what kind of laptop/touchpad is that?

-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[Anthony DiSante]

Dmitry Torokhov wrote:
> Yes, It usually happens either under high load, when mouse interrupts are
> significantly delayed. Or sometimes it happen when applications poll
> battey status and on some boxes it takes pretty long time. And because
> it is usually the same chip that serves keyboard/mouse it again delays
> mouse interrupts.

I have this problem with recent 2.6.10 kernels too, but it has nothing to do 
with load in my case; it happens whenever I switch my KVM to the linux box.

Long ago and far away, it used to be that switching out of X, then back in 
(ctrl-alt-F1, then ctrl-alt-F7) would reset the mouse and stop the jumping. 
  At some point in late 2.4/early 2.6 that stopped working, and the only fix 
was to unplug the mouse from the KVM switch and re-plug it.

In Oct 2004 I posted to lkml with subject "KVM -> jumping mouse... still no 
solution?"  Dmitry Torokhov (hi :) responded that this would work on 2.6.9-rc3+:

	echo -n "reconnect" > /sys/bus/serio/devices/serioX/driver

That was GREAT and it worked for a while, but now my last few 2.6.10 kernels 
don't seem to care when I do that, and again, unplugging the mouse is the 
only thing that works.  I'm currently running 2.6.10-gentoo-r6.

-Anthony DiSante
http://nodivisions.com/

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On Wednesday 23 February 2005 22:05, Anthony DiSante wrote:
> Dmitry Torokhov wrote:
> > Yes, It usually happens either under high load, when mouse interrupts are
> > significantly delayed. Or sometimes it happen when applications poll
> > battey status and on some boxes it takes pretty long time. And because
> > it is usually the same chip that serves keyboard/mouse it again delays
> > mouse interrupts.
> 
> I have this problem with recent 2.6.10 kernels too, but it has nothing to do 
> with load in my case; it happens whenever I switch my KVM to the linux box.
> 

Hi Anthony,

This is a bit different problem and we trying to find a reliable solution
for it.

> Long ago and far away, it used to be that switching out of X, then back in 
> (ctrl-alt-F1, then ctrl-alt-F7) would reset the mouse and stop the jumping. 
>   At some point in late 2.4/early 2.6 that stopped working, and the only fix 
> was to unplug the mouse from the KVM switch and re-plug it.
> 
> In Oct 2004 I posted to lkml with subject "KVM -> jumping mouse... still no 
> solution?"  Dmitry Torokhov (hi :) responded that this would work on 2.6.9-rc3+:
> 
> 	echo -n "reconnect" > /sys/bus/serio/devices/serioX/driver
> 
> That was GREAT and it worked for a while, but now my last few 2.6.10 kernels 
> don't seem to care when I do that, and again, unplugging the mouse is the 
> only thing that works.  I'm currently running 2.6.10-gentoo-r6.
> 

It still should work fine, but in a bit different form:

	echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl

I.e. substitute "driver" with "drvctl" as now "driver" is a symlink to
a currently bound driver that is set up by driver core.

-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[Anthony DiSante]

Dmitry Torokhov wrote:
>>In Oct 2004 I posted to lkml with subject "KVM -> jumping mouse... still no 
>>solution?"  Dmitry Torokhov (hi :) responded that this would work on 2.6.9-rc3+:
>>
>>	echo -n "reconnect" > /sys/bus/serio/devices/serioX/driver
>>
>>That was GREAT and it worked for a while, but now my last few 2.6.10 kernels 
>>don't seem to care when I do that, and again, unplugging the mouse is the 
>>only thing that works.  I'm currently running 2.6.10-gentoo-r6.
>>
> 
> 
> It still should work fine, but in a bit different form:
> 
> 	echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl
> 
> I.e. substitute "driver" with "drvctl" as now "driver" is a symlink to
> a currently bound driver that is set up by driver core.

Ah, sweet, thank you.  This should all be documented somewhere!  For now 
I've been keeping my notes here:

http://nodivisions.com/tech/linux/jumpingmouse/

-Anthony DiSante
http://nodivisions.com/

Re: mouse still losing sync and thus jumping around

[Bennie Kahler-Venter]

Using SuSE 9.1 Professional with kernel 2.6.11  running on a AOpen 1845
Laptop.

Currently running without APM & ACPI

If I turn either or both on I get an erratic mouse and entries such as
these:
Mar  3 15:06:55 bventer01 kernel: psmouse.c: Mouse at
isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
Mar  3 15:07:23 bventer01 kernel: psmouse.c: Mouse at
isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.

Kernels 2.6.x all reproduce the above symptoms.  I'm currently running
on 2.6.11

Must say that the occurance of these erratic problems are a lot less in
2.6.11 but they still persist.  I did do a test to see if it was ACPI
related.

With ACPI and APM turned on and when I restart "powersaved" mouse goes
crazy without me touching it.  I'm not too sure how to progress to
locate/fix this problem.

Tnx & Bi
Bennie Kahler-Venter

Re: mouse still losing sync and thus jumping around

[Andrew Morton]

Bennie Kahler-Venter <bennie.venter@shoden.co.za> wrote:
>
> Using SuSE 9.1 Professional with kernel 2.6.11  running on a AOpen 1845
> Laptop.
> 
> Currently running without APM & ACPI
> 
> If I turn either or both on I get an erratic mouse and entries such as
> these:
> Mar  3 15:06:55 bventer01 kernel: psmouse.c: Mouse at
> isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
> Mar  3 15:07:23 bventer01 kernel: psmouse.c: Mouse at
> isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
> 
> Kernels 2.6.x all reproduce the above symptoms.  I'm currently running
> on 2.6.11
> 
> Must say that the occurance of these erratic problems are a lot less in
> 2.6.11 but they still persist.  I did do a test to see if it was ACPI
> related.
> 
> With ACPI and APM turned on and when I restart "powersaved" mouse goes
> crazy without me touching it.  I'm not too sure how to progress to
> locate/fix this problem.
> 

Bennie, has this been fixed in 2.6.12-rc1?

Thanks.

Re: mouse still losing sync and thus jumping around

[Andrew Morton]

Bennie Kahler-Venter <bennie.venter@shoden.co.za> wrote:
>
> Using SuSE 9.1 Professional with kernel 2.6.11  running on a AOpen 1845
> Laptop.
> 
> Currently running without APM & ACPI
> 
> If I turn either or both on I get an erratic mouse and entries such as
> these:
> Mar  3 15:06:55 bventer01 kernel: psmouse.c: Mouse at
> isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
> Mar  3 15:07:23 bventer01 kernel: psmouse.c: Mouse at
> isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
> 
> Kernels 2.6.x all reproduce the above symptoms.  I'm currently running
> on 2.6.11
> 
> Must say that the occurance of these erratic problems are a lot less in
> 2.6.11 but they still persist.  I did do a test to see if it was ACPI
> related.
> 
> With ACPI and APM turned on and when I restart "powersaved" mouse goes
> crazy without me touching it.  I'm not too sure how to progress to
> locate/fix this problem.
> 

Could you please retest 2.6.12-rc5?

Re: mouse still losing sync and thus jumping around

[Bennie Kahler-Venter]

Andrew Morton wrote:

>
> Could you please retest 2.6.12-rc5?

I would like to, but I'm not sure which kernel to use when I only can
get the patch, tried to look around to find out which kernel to use,
but it does not appear to be around somewhere...

Tnx & Bi
Bennie Kahler-Venter

Re: mouse still losing sync and thus jumping around

[Bennie Kahler-Venter]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

Andrew Morton wrote:

>
> Could you please retest 2.6.12-rc5?

Did test the kernel with both ACPI and APM enabled:

As you can see from dmesg.out there is till a sync loss.

config.gz contains the configuration I built the kernel with
(a copy from /proc/config.gz)

Tnx & Bi
Bennie Kahler-Venter



[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 14436 bytes --]

[-- Attachment #3: dmesg.out --]
[-- Type: text/plain, Size: 17083 bytes --]

Linux version 2.6.11.7 (root@Rescue) (gcc version 3.3.4 (pre 3.3.5 20040809)) #5 Mon Apr 25 14:30:12 SAST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000ffe0000 (usable)
 BIOS-e820: 000000000ffe0000 - 000000000fff8000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65504
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61408 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 Acer                                  ) @ 0x000fe030
ACPI: RSDT (v001 Acer   TMH2     0x00000001 Acer 0x00000000) @ 0x0ffe0000
ACPI: FADT (v001 Acer   TMH2     0x00000001 Acer 0x00000000) @ 0x0ffe0054
ACPI: BOOT (v001 Acer   TMH2     0x00000001 Acer 0x00000000) @ 0x0ffe002c
ACPI: DSDT (v001    H2       H2  0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0xf108
Allocating PCI resources starting at 10000000 (gap: 0fff8000:efff8000)
Built 1 zonelists
Kernel command line: root=/dev/hda3 vga=0x317 selinux=0 resume=/dev/hda2 desktop elevator=as splash=silent
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01201000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 1800.559 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 253832k/262016k available (2488k kernel code, 7568k reserved, 988k data, 220k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 3563.52 BogoMIPS (lpj=1781760)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 04
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
 tbxface-0118 [02] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control Methods:...............................................................................................................................................................
Table [DSDT](id F004) - 519 Objects with 50 Devices 159 Methods 34 Regions
ACPI Namespace successfully loaded at root c04d6840
ACPI: setting ELCR to 0200 (from 0c00)
evxfevnt-0094 [03] acpi_enable           : Transition to ACPI mode successful
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1042k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
evgpeblk-0979 [06] ev_create_gpe_block   : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-0987 [06] ev_create_gpe_block   : Found 3 Wake, Enabled 3 Runtime GPEs in this block
evgpeblk-0979 [06] ev_create_gpe_block   : GPE 10 to 1F [_GPE] 2 regs on int 0x9
evgpeblk-0987 [06] ev_create_gpe_block   : Found 1 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:....................................................................................
Initialized 34/34 Regions 10/10 Fields 30/30 Buffers 10/17 Packages (528 nodes)
Executing all Device _STA and_INI methods:.......................................................
55 Devices found containing: 55 _STA, 1 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [PILA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [PILC] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILE] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILG] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: Embedded Controller [EC0] (gpe 29)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 11 devices
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
pnp: 00:0a: ioport range 0xf100-0xf17f could not be reserved
pnp: 00:0a: ioport range 0xf200-0xf23f has been reserved
pnp: 00:0a: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:0a: ioport range 0x580-0x587 has been reserved
Simple Boot Flag at 0x6e set to 0x1
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x0f (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1117204892.838:0): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
vesafb: framebuffer at 0x88000000, mapped to 0xd0880000, using 3072k, total 32768k
vesafb: mode is 1024x768x16, linelength=2048, pages=20
vesafb: protected mode interface info at c000:5229
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt Link [PILB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 10 (level, low) -> IRQ 10
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH2: IDE controller at PCI slot 0000:00:1f.1
ICH2: chipset revision 5
ICH2: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xbc90-0xbc97, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xbc98-0xbc9f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: FUJITSU MHR2020AT, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: SR243T, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 1024KiB
hda: 39070080 sectors (20003 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3
hdc: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PS/2 Generic Mouse on isa0060/serio2
Synaptics Touchpad, model: 1
 Firmware: 5.8
 180 degree mounted touchpad
 Sensor: 18
 new absolute packet format
 Touchpad has extended capability bits
 -> 4 multi-buttons, i.e. besides standard buttons
 -> multifinger detection
 -> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio4
input: PC Speaker
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 8
NET: Registered protocol family 20
PM: Reading swsusp image.
swsusp: Resume From Partition: /dev/hda2
<3>swsusp: Suspend partition has wrong signature?
swsusp: Error -22 resuming
PM: Resume from disk failed.
ACPI wakeup devices: 
SLPB OZ68 OZ69 OBLN OBMO ICH2  LID 
ACPI: (supports S0 S3 S4 S4bios S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
ReiserFS: hda3: found reiserfs format "3.6" with standard journal
ReiserFS: hda3: using ordered data mode
ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda3: checking transaction log (hda3)
ReiserFS: hda3: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Trying to move old root to /initrd ... failed
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing unused kernel memory: 220k freed
8139too Fast Ethernet driver 0.9.27
ACPI: PCI interrupt 0000:02:05.0[A] -> GSI 10 (level, low) -> IRQ 10
eth0: RealTek RTL8139 at 0xd083e800, 00:00:e2:7f:66:34, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ndiswrapper version 1.1 loaded (preempt=yes,smp=no)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
USB Universal Host Controller Interface driver v2.2
ACPI: PCI Interrupt Link [PILD] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:1f.2[D] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:1f.2: Intel Corp. 82801BA/BAM USB (Hub #1)
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: irq 11, io base 0x8000
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [PILH] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:1f.4[C] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:1f.4: Intel Corp. 82801BA/BAM USB (Hub #2)
PCI: Setting latency timer of device 0000:00:1f.4 to 64
uhci_hcd 0000:00:1f.4: irq 11, io base 0x8060
uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
hw_random: RNG not detected
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i845 Chipset.
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 256M @ 0xe0000000
ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org>
ACPI: PCI Interrupt Link [PILF] enabled at IRQ 11
ACPI: PCI interrupt 0000:02:03.0[A] -> GSI 11 (level, low) -> IRQ 11
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11]  MMIO=[80100000-801007ff]  Max Packet=[2048]
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[ffff9be000000000]
SCSI subsystem initialized
st: Version 20041025, fixed bufsize 32768, s/g segs 256
ACPI: PCI Interrupt Link [PILC] enabled at IRQ 11
ACPI: PCI interrupt 0000:02:09.0[A] -> GSI 11 (level, low) -> IRQ 11
Yenta: CardBus bridge found at 0000:02:09.0 [1025:1027]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:09.0, mfunc 0x01001022, devctl 0x64
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000006
ACPI: PCI Interrupt Link [PILG] enabled at IRQ 11
ACPI: PCI interrupt 0000:02:09.1[B] -> GSI 11 (level, low) -> IRQ 11
Yenta: CardBus bridge found at 0000:02:09.1 [1025:1027]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:09.1, mfunc 0x01001022, devctl 0x64
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000006
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
subfs 0.9
Adding 265064k swap on /dev/hda2.  Priority:42 extents:1
cs: IO port probe 0xc00-0xcff: clean.
cs: IO port probe 0xc00-0xcff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0x800-0x80f: clean.
cs: IO port probe 0x800-0x80f: clean.
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x100-0x3af: excluding 0x378-0x38f
cs: IO port probe 0x100-0x3af: excluding 0x378-0x38f
cs: IO port probe 0xa00-0xaff: clean.
cs: IO port probe 0xa00-0xaff: clean.
NET: Registered protocol family 10
Disabled Privacy Extensions on device c041ff80(lo)
IPv6 over IPv4 tunneling driver
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49384 usecs
intel8x0: clocking to 48000
Disabled Privacy Extensions on device ce166000(sit0)
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
acpi_processor-0561 [08] acpi_processor_get_pow: count given by _CST is not valid
ACPI: Thermal Zone [THR1] (47 C)
ACPI: Thermal Zone [THR2] (45 C)
powernow: This module only works with AMD K7 CPUs
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Non-volatile memory driver v1.2
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
lp0: using parport0 (interrupt-driven).
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt Link [PILA] enabled at IRQ 11
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized radeon 1.14.0 20050125 on minor 0: ATI Technologies Inc Radeon Mobility M6 LY
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
psmouse.c: Mouse at isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
psmouse.c: Mouse at isa0060/serio2/input0 lost synchronization, throwing 1 bytes away.
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NET: Registered protocol family 17
psmouse.c: Mouse at isa0060/serio2/input0 lost synchronization, throwing 2 bytes away.
eth0: no IPv6 routers present
psmouse.c: Mouse at isa0060/serio2/input0 lost synchronization, throwing 1 bytes away.

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On 5/27/05, Bennie Kahler-Venter <bennie.venter@shoden.co.za> wrote:
> Andrew Morton wrote:
> 
> >
> > Could you please retest 2.6.12-rc5?
> 
> Did test the kernel with both ACPI and APM enabled:
> 
> As you can see from dmesg.out there is till a sync loss.
> 

Could yo uplease try the following patch:

http://www.geocities.com/dt_or/input/2_6_11/psmouse-resync-2.6.11-v11.patch.gz

You will still see the messages but I expect mouse not jump like crazy
when it happens.

-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[Voluspa]

On 2005-02-23 16:53:04 Dmitry Torokhov wrote:
> On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser wrote:
[...]
>> it seems to me like it is connected to disk activity... is that
>> possible?

> Yes, It usually happens either under high load, when mouse interrupts
> are significantly delayed. Or sometimes it happen when applications
> poll battey status and on some boxes it takes pretty long time. And
> because it is usually the same chip that serves keyboard/mouse it
> again delays mouse interrupts.

My notebook is an Acer Aspire 1520 (1524) with a Synaptics Touchpad,
model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000

Kernels 2.6.11.11 and 2.6.12-rc6
Synaptics driver 0.14.2

The "lost sync at byte" and "driver resynched" began flooding the logs
when I enabled Sensors --> Temperatures --> thermal_zone [THRC/THRS] in
the system monitor gkrellm. I haven't tried battery monitoring.

There are only occasional mouse pointer jumps, but the logfiles grow
very quickly. I tried reducing the gkrellm updates from 10 times a
second to 2, but it only had a marginal effect. It seems a bit silly
that this powerful notebook (AMD64 Athlon 3400+) can't 'multitask'
correctly.

I thought about just erasing the warning messages from the kernel
source (don't want to disable warn in syslog completely), but when I
found the gkrellm culprit I turned off the monitoring instead,
reluctantly.

My system has no taxing desktop, just a window manager.

Mvh
Mats Johannesson
--

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On Monday 13 June 2005 16:40, Voluspa wrote:
> 
> On 2005-02-23 16:53:04 Dmitry Torokhov wrote:
> > On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser wrote:
> [...]
> >> it seems to me like it is connected to disk activity... is that
> >> possible?
> 
> > Yes, It usually happens either under high load, when mouse interrupts
> > are significantly delayed. Or sometimes it happen when applications
> > poll battey status and on some boxes it takes pretty long time. And
> > because it is usually the same chip that serves keyboard/mouse it
> > again delays mouse interrupts.
> 
> My notebook is an Acer Aspire 1520 (1524) with a Synaptics Touchpad,
> model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000
> 
> Kernels 2.6.11.11 and 2.6.12-rc6
> Synaptics driver 0.14.2
> 
> The "lost sync at byte" and "driver resynched" began flooding the logs
> when I enabled Sensors --> Temperatures --> thermal_zone [THRC/THRS] in
> the system monitor gkrellm. I haven't tried battery monitoring.
> 
> There are only occasional mouse pointer jumps, but the logfiles grow
> very quickly. I tried reducing the gkrellm updates from 10 times a
> second to 2, but it only had a marginal effect. It seems a bit silly
> that this powerful notebook (AMD64 Athlon 3400+) can't 'multitask'
> correctly.
> 

Try setting frequency to once a minute, that should help.

-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[Voluspa]

On Mon, 13 Jun 2005 16:47:53 -0500 Dmitry Torokhov wrote:

> Try setting frequency to once a minute, that should help.

I don't think I'd get much work done if the mouse was updated once a
minute only...

Gkrellm can go as low as 1 update per second for its graphical output.
Don't know if the "below the hood" polling is reduced to the same freq.

Mvh
Mats Johannesson
--

Re: mouse still losing sync and thus jumping around

[bhaskara]

> On 2005-02-23 16:53:04 Dmitry Torokhov wrote:
> > On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser wrote:
> [...]
> >> it seems to me like it is connected to disk activity... is that
> >> possible?
>
> > Yes, It usually happens either under high load, when mouse interrupts
> > are significantly delayed. Or sometimes it happen when applications
> > poll battey status and on some boxes it takes pretty long time. And
> > because it is usually the same chip that serves keyboard/mouse it
> > again delays mouse interrupts.
>
> My notebook is an Acer Aspire 1520 (1524) with a Synaptics Touchpad,
> model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000
>
> Kernels 2.6.11.11 and 2.6.12-rc6
> Synaptics driver 0.14.2
>
> The "lost sync at byte" and "driver resynched" began flooding the logs
> when I enabled Sensors --> Temperatures --> thermal_zone [THRC/THRS] in
> the system monitor gkrellm. I haven't tried battery monitoring.
>
> There are only occasional mouse pointer jumps, but the logfiles grow
> very quickly. I tried reducing the gkrellm updates from 10 times a
> second to 2, but it only had a marginal effect. It seems a bit silly
> that this powerful notebook (AMD64 Athlon 3400+) can't 'multitask'
> correctly.
>
> I thought about just erasing the warning messages from the kernel
> source (don't want to disable warn in syslog completely), but when I
> found the gkrellm culprit I turned off the monitoring instead,
> reluctantly.
>
> My system has no taxing desktop, just a window manager.
>

I had this problem with the ps2 mouse on my desktop even under very light
load. This problem went away the very instant I started using a USB mouse.
So, I don't buy the delayed interrupts explanation.

My 2 cents

-G

Re: mouse still losing sync and thus jumping around

[Dmitry Torokhov]

On Monday 13 June 2005 16:59, bhaskara wrote:
> > On 2005-02-23 16:53:04 Dmitry Torokhov wrote:
> > > On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser wrote:
> > [...]
> > >> it seems to me like it is connected to disk activity... is that
> > >> possible?
> >
> > > Yes, It usually happens either under high load, when mouse interrupts
> > > are significantly delayed. Or sometimes it happen when applications
> > > poll battey status and on some boxes it takes pretty long time. And
> > > because it is usually the same chip that serves keyboard/mouse it
> > > again delays mouse interrupts.
> >
> > My notebook is an Acer Aspire 1520 (1524) with a Synaptics Touchpad,
> > model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000
> >
> > Kernels 2.6.11.11 and 2.6.12-rc6
> > Synaptics driver 0.14.2
> >
> > The "lost sync at byte" and "driver resynched" began flooding the logs
> > when I enabled Sensors --> Temperatures --> thermal_zone [THRC/THRS] in
> > the system monitor gkrellm. I haven't tried battery monitoring.
> >
> > There are only occasional mouse pointer jumps, but the logfiles grow
> > very quickly. I tried reducing the gkrellm updates from 10 times a
> > second to 2, but it only had a marginal effect. It seems a bit silly
> > that this powerful notebook (AMD64 Athlon 3400+) can't 'multitask'
> > correctly.
> >
> > I thought about just erasing the warning messages from the kernel
> > source (don't want to disable warn in syslog completely), but when I
> > found the gkrellm culprit I turned off the monitoring instead,
> > reluctantly.
> >
> > My system has no taxing desktop, just a window manager.
> >
> 
> I had this problem with the ps2 mouse on my desktop even under very light
> load. This problem went away the very instant I started using a USB mouse.
> So, I don't buy the delayed interrupts explanation.
>

You do not have to buy anything, you just need to read the code. pmouse
driver emits this warning if delay between 2 bytes in a middle of a packet
exceeds 0.5 sec. USB works slightly differently.
  
-- 
Dmitry

Re: mouse still losing sync and thus jumping around

[bhaskara]

> On Monday 13 June 2005 16:59, bhaskara wrote:
> > > On 2005-02-23 16:53:04 Dmitry Torokhov wrote:
> > > > On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser wrote:
> > > [...]
> > > >> it seems to me like it is connected to disk activity... is that
> > > >> possible?
> > >
> > > > Yes, It usually happens either under high load, when mouse interrupts
> > > > are significantly delayed. Or sometimes it happen when applications
> > > > poll battey status and on some boxes it takes pretty long time. And
> > > > because it is usually the same chip that serves keyboard/mouse it
> > > > again delays mouse interrupts.
> > >
> > > My notebook is an Acer Aspire 1520 (1524) with a Synaptics Touchpad,
> > > model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000
> > >
> > > Kernels 2.6.11.11 and 2.6.12-rc6
> > > Synaptics driver 0.14.2
> > >
> > > The "lost sync at byte" and "driver resynched" began flooding the logs
> > > when I enabled Sensors --> Temperatures --> thermal_zone [THRC/THRS] in
> > > the system monitor gkrellm. I haven't tried battery monitoring.
> > >
> > > There are only occasional mouse pointer jumps, but the logfiles grow
> > > very quickly. I tried reducing the gkrellm updates from 10 times a
> > > second to 2, but it only had a marginal effect. It seems a bit silly
> > > that this powerful notebook (AMD64 Athlon 3400+) can't 'multitask'
> > > correctly.
> > >
> > > I thought about just erasing the warning messages from the kernel
> > > source (don't want to disable warn in syslog completely), but when I
> > > found the gkrellm culprit I turned off the monitoring instead,
> > > reluctantly.
> > >
> > > My system has no taxing desktop, just a window manager.
> > >
> >
> > I had this problem with the ps2 mouse on my desktop even under very light
> > load. This problem went away the very instant I started using a USB mouse.
> > So, I don't buy the delayed interrupts explanation.
> >
>
> You do not have to buy anything, you just need to read the code. pmouse
> driver emits this warning if delay between 2 bytes in a middle of a packet
> exceeds 0.5 sec. USB works slightly differently.

No offense ..... but, I did some googling and figured out where the mesg
was being printed from. So I ripped out all the unnecessary stuff from the
kernel and also stopped all the unnecessary services, but still got this
behavior (with XFCE and KDE). By the way , my desktop
started exhibiting this behaviour after  a couple of months of usage and
not immediately after a kernel upgrade (2.6.8+).  However, I remember not
seeing this behavior on older 2.6.* kernels.

The .5 second delay is a symptom rather than the cause ( bad hardware ? ).

-G