Continue: psmouse.c - synaptics touchpad driver sync problem

Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

In May there was a posting Thorsten Hirsch and a patch reply by Dmitry 
Torokhov that did not help Thorsten.

I have exactely the same problem, and other people too. There's a thread on 
this topic with a more detailed problem description at:
http://www.linuxquestions.org/questions/showthread.php?s=&postid=1004645#post1004645

The problem was pested regarding to Kernel 2.6.6, but an upgrade to Kernel 
2.6.7 did not help me. My problem is even much worse:
 - The touchpad sometimes hangs and jumps.
 - Hitting on the touchpad does no more click the first button.
 - When I connect an external keyboard, the cursor somtimes jumps
   around like crazy and clicks around like fool, even if I don't
   click anything, but only move. When I then touch the keyboard,
   the mouse becomes normal for a while - on SuSE kernel 2.6.5,
   since. Since upgrade to kernel 2.6.7, does not become normal
   any more.
 - Sometimes the keyboard fails too, that means the without touching
   any key, a character is continually written, e.g. hundreds of "5"
   appear on the xterm. If i hit a key, a completely other character
   is printed, but not once but endlessly repeated.
 - Killing and restarting the X Server does not resolve the problem,
   reboot is the only thing that works!

It's really bad, I can't work anymore since I upgraded to SuSE 9.1 and kernel 
2.6...

Kernel messages:

A lot of during use of touch pad:
- psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
- psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4

When using the external mouse and the mouse jumps around (repeated 2-3 times):
- atkbd.c: Spurious ACK on isa0060/serio0. Some program like XFree86, might be 
trying access hardware directly
- psmoouse.c: bad data from KBC - timeout


I'm not subscribed to the kernel mailing list due to the heavy traffic. Please 
CC me in your reply (marc dot waeckerlin at siemens dot com). Thank's.

Regards
Marc Wäckerlin
marc.waeckerlin.org

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

On Tuesday 22 June 2004 02:52 am, Marc Waeckerlin wrote:
> In May there was a posting Thorsten Hirsch and a patch reply by Dmitry 
> Torokhov that did not help Thorsten.
> 
> I have exactely the same problem, and other people too. There's a thread on 
> this topic with a more detailed problem description at:
> http://www.linuxquestions.org/questions/showthread.php?s=&postid=1004645#post1004645
> 
> The problem was pested regarding to Kernel 2.6.6, but an upgrade to Kernel 
> 2.6.7 did not help me. My problem is even much worse:
>  - The touchpad sometimes hangs and jumps.
>  - Hitting on the touchpad does no more click the first button.
>  - When I connect an external keyboard, the cursor somtimes jumps
>    around like crazy and clicks around like fool, even if I don't
>    click anything, but only move. When I then touch the keyboard,
>    the mouse becomes normal for a while - on SuSE kernel 2.6.5,
>    since. Since upgrade to kernel 2.6.7, does not become normal
>    any more.

Here your touchpad can be rest back to relative mode. Does passing
psmouse.resetafter=3 to the kernel helps things a bit?

-- 
Dmitry

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

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

I CC this mail to laflipas and t.hirsch because they have the same problem.

Am Dienstag, 22. Juni 2004 16.18 schrieben Sie unter "RE: Touchpad on Kernel 
Mailinglist: Question":
> Marc Waeckerlin wrote:

> > > Here your touchpad can be rest back to relative mode.
> > How?
> What I meant is that act of plugging in your keyboard may cause
> the touchpad revert back in relative mode and we _do not_ want
> this happening. Hence the option psmouse.resetafter to try to
> re-initialize the touchpad after so many bad packets.

> > > Does passing psmouse.resetafter=3 to the kernel helps things a bit?
> >
> > Do you mean as boot-prompt parameter to GRUB/LILO?
>
> If your psmouse module is compiled it then use "psmouse.resetafter=3"
> as a boot parameter. If psmouse is a module then put
> "options psmouse resetafer=3" in your /etc/modprobe.conf

I am sorry, both options do not help at all - well, perhaps the jumping of the 
cursor when using the touchpad without external keyboard/mouse disconnected 
may be slightly better. But as soon as I plug in the external keyboard, the 
old problem occurs.

Also I have a problem not yet mentioned, but it happened again this morning: 
Sometimes - without external keyboard/mouse, only using touchpad and internal 
keyboard -, sometimes the keyboard does not work anymore. If I hit any 
arbitrary key, nothing happens anymore. The mouse still works with the 
touchpad. Since I am often mobile, I can't acces the notebook through LAN and 
sice keynoard does not work anymore, I cant hit ctrl-alt-f1 or so to switch 
to a terminal or to watch the syslog on ctrl-alt-f10. The only thing I can do 
is to reboot using the mouse only.


> You know, could you send me your dmesg so I get a feeling of your
> laptop. What make/model is that?

It's a Pentium III, SIS-Chipset noname (the only notebook I could buy without 
Microsoft tax), as you can see in the attached dmesg.

I have my notebook for 2 1/2 years now and I never had similar problem with 
the previous 2.4.x kernels. Also there are other people with the same 
problem, so I think it's no hardware defect.


> Also, if you don't use any external 
> devices do you still have touchpad troubles?

Doesn't help.


> Do they go away if you 
> boot with acpi=off boot parameter?

No, that's one of the first things I tried. SuSE sets up a "Failsafe" boot 
parameter, that disables ACPI, APM, ISE-SCSI and other things. But it still 
does not work.


> I wish I could provide you with a canned solution, there just too
> many unknowns.

There are other with the same problem, e.g. Thorsten on the kernel mailing 
list in Mai and the one on the link I posted in my first mail. Also, there's 
another similar thread in linuxquetions.org:
http://www.linuxquestions.org/questions/showthread.php?s=&threadid=182363&highlight=mouse+jumps+around
Do a search on Google to find more victims (possible keywords: "mouse jumps 
linux" or the syslog messages). Here's one reporting the same in spanish:
http://lists.debian.org/debian-user-spanish/2004/02/msg00127.html


Is there any alternative driver I could try? How is synaptics related to a 
PS/2 mouse and can it be disabled? Can I do something in the kernel 
configuration (please describe the xconfig menu path)?

Can I assist you somehow? I am an experienced C++ programmer, but I have never 
done kernel development or debugging.

If you send me a patch, if possible diff it against 2.6.7, that's my actual 
kernel.


Thank you
Regards
Marc

[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 14663 bytes --]

Linux version 2.6.7 (root@qingwa) (gcc-Version 3.3.3 (SuSE Linux)) #2 Tue Jun 22 12:23:11 CEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
 BIOS-e820: 000000000bff0000 - 000000000bff8000 (ACPI data)
 BIOS-e820: 000000000bff8000 - 000000000c000000 (ACPI NVS)
 BIOS-e820: 00000000ffef0000 - 00000000fff00000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
191MB LOWMEM available.
On node 0 totalpages: 49136
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 45040 pages, LIFO batch:10
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 AMI                                       ) @ 0x000fc740
ACPI: RSDT (v001 AMIINT AMIINT09 0x00001000 MSFT 0x0100000b) @ 0x0bff0000
ACPI: FADT (v001 AMIINT AMIINT09 0x00001000 MSFT 0x0100000b) @ 0x0bff0030
ACPI: DSDT (v001    SiS      630 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x5008
Built 1 zonelists
Kernel command line: root=/dev/hda2 vga=0x317 acpi=force desktop resume=/dev/hda1 splash=silent
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 1097.320 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Memory: 189652k/196544k available (1887k kernel code, 6256k reserved, 876k data, 184k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 2179.07 BogoMIPS
Security Scaffold v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: 0387fbff 00000000 00000000 00000000
CPU:     After vendor identify, caps: 0387fbff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU:     After all inits, caps: 0383fbff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1097.0112 MHz.
..... host bus clock speed is 99.0737 MHz.
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1464k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfdb31, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040326
ACPI: IRQ9 SCI: Level Trigger.
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Uncovering SIS18 that hid as a SIS503 (compatible=0)
Enabling SiS 96x SMBus.
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC0] (gpe 11)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [URP1] (off)
ACPI: PCI Interrupt Link [LNKB] (IRQs 4 6 7 11 12 14 15) *0
ACPI: PCI Interrupt Link [LNKC] (IRQs 6 7 10 12 14 15) *0
ACPI: PCI Interrupt Link [LNKD] (IRQs 11) *0
ACPI: Power Resource [FN10] (on)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
sisfb: Video ROM found and mapped to c00c0000
sisfb: Framebuffer at 0xd0000000, mapped to 0xcc80e000, size 65536k
sisfb: MMIO at 0xdfee0000, mapped to 0xd080f000, size 128k
sisfb: Memory heap starting at 12288K
sisfb: Detected LVDS transmitter and Chrontel TV encoder
sisfb: Detected LCD PanelDelayCompensation 32
sisfb: Default mode is 800x600x8 (60Hz)
sisfb: Initial vbflags 0x3000022
sisfb: Added MTRRs
sisfb: Installed SISFB_GET_INFO ioctl (80046ef8)
sisfb: Installed SISFB_GET_VBRSTATUS ioctl (80046ef9)
sisfb: 2D acceleration is enabled, scrolling mode ypan (auto-max)
fb0: SIS 630/730 VGA frame buffer device, Version 1.6.25
sisfb: (C) 2001-2004 Thomas Winischhofer.
vesafb: abort, cannot reserve video memory at 0xd0000000
vesafb: framebuffer at 0xd0000000, mapped to 0xd0830000, size 3072k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at cae4:0008
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb1: VESA VGA frame buffer device
audit: initializing netlink socket (disabled)
audit(1087978333.470:0): initialized
Total HugeTLB memory allocated, 0
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
Console: switching to colour frame buffer device 100x37
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 630 chipset
agpgart: Maximum main memory to use for agp memory: 149M
agpgart: AGP aperture is 64M @ 0xe0000000
[drm] Initialized sis 1.1.0 20030826 on minor 0: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
Using anticipatory io scheduler
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
SIS5513: IDE controller at PCI slot 0000:00:00.1
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS630 ATA 100 (1st gen) controller
    ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
hda: FUJITSU MHT2080AT, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: QSI DVD-ROM SDR-081, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(33)
 hda: hda1 hda2 hda3
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
i8042.c: Detected active multiplexing controller, rev 1.0.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
Synaptics Touchpad, model: 1
 Firmware: 4.1
 Sensor: 8
 new absolute packet format
input: SynPS/2 Synaptics TouchPad on isa0060/serio2
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
input: AT Translated Set 2 keyboard on isa0060/serio0
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 1
Resume Machine: resuming from /dev/hda1
Resuming from device hda1
Resume Machine: This is normal swap space
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S4 S5)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
SCSI subsystem initialized
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
USB Universal Host Controller Interface driver v2.2
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ohci_hcd 0000:00:01.2: Silicon Integrated Systems [SiS] USB 1.0 Controller
ohci_hcd 0000:00:01.2: irq 11, pci mem d0b59000
ohci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd 0000:00:01.3: Silicon Integrated Systems [SiS] USB 1.0 Controller (#2)
ohci_hcd 0000:00:01.3: irq 11, pci mem d0b67000
ohci_hcd 0000:00:01.3: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
XFS mounting filesystem hda2
Ending clean XFS mount for filesystem: hda2
VFS: Mounted root (xfs filesystem) readonly.
Trying to move old root to /initrd ... failed
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing unused kernel memory: 184k freed
Adding 859436k swap on /dev/hda1.  Priority:42 extents:1
Generic RTC Driver v1.07
ohci_hcd 0000:00:01.2: remote wakeup
usb 1-1: new full speed USB device using address 2
scsi0 : SCSI emulation for USB Mass Storage devices
  Vendor: USB       Model: Flash Drive       Rev: 1.11
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 253949 512-byte hdwr sectors (130 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
 sda: sda1
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
USB Mass Storage device found at 2
XFS mounting filesystem loop0
Ending clean XFS mount for filesystem: loop0
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
Yenta: CardBus bridge found at 0000:00:03.0 [1584:3000]
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000821
usb 1-1: USB disconnect, address 2
hdc: ATAPI 24X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.20
st: Version 20040403, fixed bufsize 32768, s/g segs 256
BIOS EDD facility v0.15 2004-May-17, 1 devices found
ACPI: AC Adapter [AC0] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0370d60(lo)
IPv6 over IPv4 tunneling driver
ACPI: Lid Switch [LIDD]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Power Button (CM) [PWRB]
Disabled Privacy Extensions on device cbdc9000(sit0)
ACPI: Fan [FAN1] (off)
ACPI: Processor [CPU1] (supports C1 C2, 8 throttling states)
    ACPI-0179: *** Warning: The ACPI AML in your computer contains errors, please nag the manufacturer to correct it.
    ACPI-0182: *** Warning: Allowing relaxed access to fields; turn on CONFIG_ACPI_DEBUG for details.
ACPI: Thermal Zone [THRM] (51 C)
XFS: unknown mount option [commit].
XFS: unknown mount option [commit].
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
Non-volatile memory driver v1.2
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
ohci_hcd 0000:00:01.2: remote wakeup
usb 1-1: new full speed USB device using address 3
scsi1 : SCSI emulation for USB Mass Storage devices
  Vendor: USB       Model: Flash Drive       Rev: 1.11
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 253949 512-byte hdwr sectors (130 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
 sda: sda1
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0,  type 0
USB Mass Storage device found at 3
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
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 lost sync at byte 1
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 4
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
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 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
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
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
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
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
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
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
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
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 4
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.

RE: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

Marc Waeckerlin wrote:
> >
> > If your psmouse module is compiled it then use "psmouse.resetafter=3"
> > as a boot parameter. If psmouse is a module then put
> > "options psmouse resetafer=3" in your /etc/modprobe.conf
> 
> I am sorry, both options do not help at all - well, perhaps the jumping of
> the
> cursor when using the touchpad without external keyboard/mouse
> disconnected
> may be slightly better. But as soon as I plug in the external keyboard,
> the
> old problem occurs.
>

Hmm... OK, I see that you have an active multiplexing controller.
I wonder if it gets reset back to legacy mode when you plug your
external keyboard. (btw, it it just a keyboard or a docking station/
port replicator?). Try passing i8042.nomux to the kernel and try using
your touchpad/keyboard. If nomux does not help you may try to use
psmouse.proto=bare or psmouse.proto=imps to disable Synaptics-specific
extensions.

Also, if you have time, please change #undef DEBUG to #define DEBUG in
drivers/input/serio/i8042.c, reboot, play a bit with touchpad; plug
external keyboard and send me output of "dmesg -s 100000".
 
> Also I have a problem not yet mentioned, but it happened again this
> morning:
> Sometimes - without external keyboard/mouse, only using touchpad and
> internal
> keyboard -, sometimes the keyboard does not work anymore. If I hit any
> arbitrary key, nothing happens anymore. The mouse still works with the
> touchpad. Since I am often mobile, I can't acces the notebook through LAN
> and
> sice keynoard does not work anymore, I cant hit ctrl-alt-f1 or so to
> switch
> to a terminal or to watch the syslog on ctrl-alt-f10. The only thing I can
> do
> is to reboot using the mouse only.
> 

Ok, we were getting reports about this happening with Toshibas, no
resolution yet...

--
Dmitry

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Mittwoch, 23. Juni 2004 17.59 schrieb Dmitry Torokhov unter "RE: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> Try passing i8042.nomux to the kernel and try using your touchpad/keyboard.

External mouse does not move anymore. External keyboard still works, so that's 
not the solution...

Well, I can do a long-run test with the internal touchpad/keyboard only, to 
see if at least this works now better. "Unfortunately" the problems with 
internal keyboard/touchpad are less frequent and less reproducible.


> If nomux does not help you may try to use 
> psmouse.proto=bare

No, does not help. :-(


> or psmouse.proto=imps to disable Synaptics-specific 
> extensions.

Well, IMPS seems to be completely incompatible to normal PS/2, so as expected 
things get worse, means now the internal mouse jumps around like crazy.

Please note, that one of the external mice, the one I am actually testing, is 
not a scroll mouse, but a normal PS/2 mouse.

Regards
Marc

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Mittwoch, 23. Juni 2004 17.59 schrieb Dmitry Torokhov unter "RE: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> Also, if you have time, please change #undef DEBUG to #define DEBUG in
> drivers/input/serio/i8042.c, reboot, play a bit with touchpad; plug
> external keyboard and send me output of "dmesg -s 100000".

dmesg looks like this, even with a log_buf_len=131072 boot-parameter, there's 
nothiung else left. These are the interesting parts:

[dmesg starts here, this is first line]
erio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158589]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158592]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158593]
drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [158595]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158596]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158598]
drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158602]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158603]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158605]
drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [158606]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158608]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158609]
drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158614]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158617]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158619]
drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [158622]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158623]
[...]
drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [158974]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158977]
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158978]
psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158980]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158981]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158983]
drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [158985]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158987]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158988]
psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158990]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158991]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158993]
[...]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [159396]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [159398]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [162523]
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be 
trying access hardware directly.
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux3, 12) [162765]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162765]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162765]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [162765]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162769]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162771]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162771]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [162771]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162774]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162776]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162776]
drivers/input/serio/i8042.c: f6 -> i8042 (parameter) [162776]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162779]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162779]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162779]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162782]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162782]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [162782]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162785]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162785]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162785]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162788]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162788]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [162788]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162791]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162791]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162791]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162794]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162794]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [162794]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162797]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162797]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162797]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162800]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162800]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [162800]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162804]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162804]
drivers/input/serio/i8042.c: e9 -> i8042 (parameter) [162804]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162807]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162809]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162810]
drivers/input/serio/i8042.c: 64 <- i8042 (interrupt, aux3, 12) [162812]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162812]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162812]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162816]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162816]
drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [162816]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162819]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162819]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162819]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162822]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162822]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162822]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162825]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162825]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162825]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162828]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162828]
drivers/input/serio/i8042.c: e9 -> i8042 (parameter) [162828]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162831]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, aux3, 12) [162833]
drivers/input/serio/i8042.c: 03 <- i8042 (interrupt, aux3, 12) [162835]
drivers/input/serio/i8042.c: c8 <- i8042 (interrupt, aux3, 12) [162839]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162839]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [162839]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162842]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162842]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [162842]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162845]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162845]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162845]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162848]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162848]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162848]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162851]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162851]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [162851]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162854]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162854]
drivers/input/serio/i8042.c: e9 -> i8042 (parameter) [162854]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162857]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, aux3, 12) [162859]
drivers/input/serio/i8042.c: 03 <- i8042 (interrupt, aux3, 12) [162861]
drivers/input/serio/i8042.c: c8 <- i8042 (interrupt, aux3, 12) [162863]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162863]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162863]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162866]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162866]
drivers/input/serio/i8042.c: c8 -> i8042 (parameter) [162866]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162869]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162869]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162869]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162872]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162872]
drivers/input/serio/i8042.c: c8 -> i8042 (parameter) [162872]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162875]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162875]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162875]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162878]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162878]
drivers/input/serio/i8042.c: 50 -> i8042 (parameter) [162878]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162881]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162881]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [162881]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162885]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162887]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162887]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162887]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162890]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162890]
drivers/input/serio/i8042.c: c8 -> i8042 (parameter) [162890]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162893]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162893]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162893]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162896]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162896]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [162896]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162899]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162899]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [162899]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162902]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162902]
drivers/input/serio/i8042.c: 50 -> i8042 (parameter) [162902]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162905]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [162905]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [162905]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [162908]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [162910]
input: PS/2 Logitech Mouse on isa0060/serio4
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163005]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [163005]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163008]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163008]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [163008]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163011]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163011]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [163011]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163015]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163015]
drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [163015]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163018]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163018]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [163018]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163021]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163021]
drivers/input/serio/i8042.c: ea -> i8042 (parameter) [163021]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163024]
drivers/input/serio/i8042.c: 93 -> i8042 (command) [163024]
drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [163024]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux3, 12) [163027]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux3, 12) [165329]
drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, aux3, 12) [165331]
drivers/input/serio/i8042.c: 03 <- i8042 (interrupt, aux3, 12) [165332]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux3, 12) [165342]
[...]
drivers/input/serio/i8042.c: 88 <- i8042 (interrupt, kbd, 1) [205896]
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [205921]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [206158]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [206238]
drivers/input/serio/i8042.c: 31 <- i8042 (interrupt, kbd, 1) [206335]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, kbd, 1) [206380]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [206415]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [206462]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [206672]
drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, kbd, 1) [206794]
drivers/input/serio/i8042.c: 88 <- i8042 (interrupt, kbd, 1) [206839]
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [206892]
drivers/input/serio/i8042.c: 20 <- i8042 (interrupt, kbd, 1) [207131]
drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, kbd, 1) [207196]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [207317]
[...]
drivers/input/serio/i8042.c: a2 <- i8042 (interrupt, kbd, 1) [207951]
drivers/input/serio/i8042.c: 1c <- i8042 (interrupt, kbd, 1) [209407]
drivers/input/serio/i8042.c: 9c <- i8042 (interrupt, kbd, 1) [209458]
[end of dmesg, that was last line]

All the other lines look similar to:
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158654]

There is no more left from the boot process. That means, the trace is so 
frequent, that it overflows long before I can get the dmesg. I also tried 
with 33554432 Bytes, but there seem to be a size limit?

I don't think it makes sense to attach the full trace (>100kB), I don't want 
to send too large messages, what do you think?


Please tell me if you have any idea how to proceed.


Regards
Marc

RE: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

> Am Mittwoch, 23. Juni 2004 17.59 schrieb Dmitry Torokhov unter "RE:
> Continue:
> psmouse.c - synaptics touchpad driver sync problem":
> > Also, if you have time, please change #undef DEBUG to #define DEBUG in
> > drivers/input/serio/i8042.c, reboot, play a bit with touchpad; plug
> > external keyboard and send me output of "dmesg -s 100000".
> 
> dmesg looks like this, even with a log_buf_len=131072 boot-parameter,
> there's
> nothiung else left. These are the interesting parts:
> 
> [dmesg starts here, this is first line]
> erio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [158589]
<skip>

> All the other lines look similar to:
> drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [158654]
> 
> There is no more left from the boot process. That means, the trace is so
> frequent, that it overflows long before I can get the dmesg. I also tried
> with 33554432 Bytes, but there seem to be a size limit?
> 
> I don't think it makes sense to attach the full trace (>100kB), I don't
> want
> to send too large messages, what do you think?

You still need to use "dmesg -s 100000" even if you specifie logbuf_len.
Anyway, the data probably goes into /var/log/messages as well... If it is
there please send it my way (not on the list). I should be able to handle
100K e-mail.

Thanks,

Dmitry 

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

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

Marc Waeckerlin wrote:
> Am Donnerstag, 24. Juni 2004 18.11 schrieb Dmitry Torokhov unter "RE:
> Continue: psmouse.c - synaptics touchpad driver sync problem":
> > You still need to use "dmesg -s 100000" even if you specifie logbuf_len.
> > Anyway, the data probably goes into /var/log/messages as well... If it
> is
> > there please send it my way (not on the list). I should be able to
> handle
> > 100K e-mail.
> 
> Of course, but there are still no other lines left...
> 
> I don't know how big I'd have to set the buffer, but I tried to set it to
> 2^25
> (~33E6), but then the buffer seems to be reset to default? What's the
> limit?
> 
> See the attachment for the 1E5 buffer.
> 

Still don't have the initialization part... Is there any way you could
make your /var/log/messages file accessible via ftp or http?

Anyway, I also have a tiy patch to try out (attached, not tested/
not compiled). Please let me know how ifit makes any improvement.

Thank you.

--
Dmitry

[-- Attachment #2: i8042-muxerr.patch --]
[-- Type: text/plain, Size: 653 bytes --]

diff -urN 2.6.7/drivers/input/serio/i8042.c linux-2.6.7/drivers/input/serio/i8042.c
--- 2.6.7/drivers/input/serio/i8042.c	2004-06-23 15:09:26.091494400 -0500
+++ linux-2.6.7/drivers/input/serio/i8042.c	2004-06-25 08:51:48.125136000 -0500
@@ -406,12 +406,12 @@
 	if (i8042_mux_values[0].exists && (str & I8042_STR_AUXDATA)) {
 
 		if (str & I8042_STR_MUXERR) {
+			printk(KERN_INFO "i8042.c: MUX reports error condition %02x\n", data);
 			switch (data) {
 				case 0xfd:
 				case 0xfe: dfl = SERIO_TIMEOUT; break;
 				case 0xff: dfl = SERIO_PARITY; break;
 			}
-			data = 0xfe;
 		} else dfl = 0;
 
 		dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s)",

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> Anyway, I also have a tiy patch to try out (attached, not tested/
> not compiled). Please let me know how ifit makes any improvement.

Sorry for the delay.

No, unfortunately no improvement at all.

I tested with no special kernel option (no i8042.nodemux or similar).


Regards
Marc

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

Marc Waeckerlin wrote:
> Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
> Continue:
> psmouse.c - synaptics touchpad driver sync problem":
> > Anyway, I also have a tiy patch to try out (attached, not tested/
> > not compiled). Please let me know how ifit makes any improvement.
> 
> Sorry for the delay.
> 
> No, unfortunately no improvement at all.
>
 
Yeah, I figure there would not be any. Still I have a nagging suspicion
that the mux gets confused and I would like to see the full dmesg with
this patch applied and DEBUG enabled. Is there any change of getting it?

Actually, if you could change the patch so it would print not only data
but also str, like this:

printk(KERN_INFO "i8042.c: MUX reports error condition %02x (%02x)\n",
       data, str);

it would be even better.

Thanks!

--
Dmitry 

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

On Tuesday 29 June 2004 11:08 am, Marc Waeckerlin wrote:
> Am Dienstag, 29. Juni 2004 16.32 schrieben Sie unter "Re: Continue: psmouse.c 
> - synaptics touchpad driver sync problem":
> > Marc Waeckerlin wrote:
> > > Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
> > > Continue:
> > > > Anyway, I also have a tiy patch to try out (attached, not tested/
> > > > not compiled). Please let me know how ifit makes any improvement.
> > > No, unfortunately no improvement at all.
> >
> > Yeah, I figure there would not be any. Still I have a nagging suspicion
> > that the mux gets confused and I would like to see the full dmesg with
> > this patch applied and DEBUG enabled.
> 
> "dmesg" won't help, because the buffer gets filled too quickly. I send you the 
> part from /var/log/messages since last boot. File size is 386KB, so I send it 
> to you directly, not through the mailing list. You are free to forward it, if 
> you think it's useful for others.
>

Ok, this is much better, it confirms my suspicions... It seems that your
keyboard controller gets confused where the data is coming from. Please
try the patch below (against vanilla 2.6.7, not compiled/tested). 

> 
> > Is there any change of getting it? 
> 
> What do you mean by this?
>

Nevermind ;)
 
-- 
Dmitry

--- 2.6.7/drivers/input/serio/i8042.c	2004-06-22 01:23:15.000000000 -0500
+++ linux-2.6.7/drivers/input/serio/i8042.c	2004-06-29 12:48:21.000000000 -0500
@@ -400,19 +400,35 @@
 		goto out;
 	}
 
-	dfl = ((str & I8042_STR_PARITY) ? SERIO_PARITY : 0) |
-	      ((str & I8042_STR_TIMEOUT) ? SERIO_TIMEOUT : 0);
-
 	if (i8042_mux_values[0].exists && (str & I8042_STR_AUXDATA)) {
+		static unsigned long last_transmit;
+		static unsigned char last_str;
 
+		dfl = 0;
 		if (str & I8042_STR_MUXERR) {
+			printk(KERN_INFO "i8042.c: MUX reports error condition %02x, data is %02x\n", str, data);
 			switch (data) {
+				default:
+/*
+ * When MUXERR condition is signalled the data register can only contain
+ * 0xfd, 0xfe or 0xff if implementation follows the spec. Unfortunately
+ * it is not always the case. Some KBC just get confused which port the
+ * data came from and signal error leaving the data intact. They _do not_
+ * revert to legacy mode (actually I've never seen KBC reverting to legacy
+ * mode yet, when we see one we'll add proper handling).
+ * Anyway, we will assume that the data came from the same serio last byte
+ * was transmitted (if transmission happened not too long ago).
+ */
+					if (time_before(jiffies, last_transmit + HZ/10)) {
+						str = last_str;
+						break;
+					}
+					/* fall through - report timeout */
 				case 0xfd:
-				case 0xfe: dfl = SERIO_TIMEOUT; break;
-				case 0xff: dfl = SERIO_PARITY; break;
+				case 0xfe: dfl = SERIO_TIMEOUT; data = 0xfe; break;
+				case 0xff: dfl = SERIO_PARITY;  data = 0xfe; break;
 			}
-			data = 0xfe;
-		} else dfl = 0;
+		}
 
 		dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s)",
 			data, (str >> 6), irq,
@@ -421,9 +437,14 @@
 
 		serio_interrupt(i8042_mux_port + ((str >> 6) & 3), data, dfl, regs);
 
+		last_str = str;
+		last_transmit = jiffies;
 		goto irq_ret;
 	}
 
+	dfl = ((str & I8042_STR_PARITY) ? SERIO_PARITY : 0) |
+	      ((str & I8042_STR_TIMEOUT) ? SERIO_TIMEOUT : 0);
+
 	dbg("%02x <- i8042 (interrupt, %s, %d%s%s)",
 		data, (str & I8042_STR_AUXDATA) ? "aux" : "kbd", irq,
 		dfl & SERIO_PARITY ? ", bad parity" : "",

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

On Tuesday 29 June 2004 12:53 pm, Dmitry Torokhov wrote:
> On Tuesday 29 June 2004 11:08 am, Marc Waeckerlin wrote:
> > Am Dienstag, 29. Juni 2004 16.32 schrieben Sie unter "Re: Continue: psmouse.c 
> > - synaptics touchpad driver sync problem":
> > > Marc Waeckerlin wrote:
> > > > Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
> > > > Continue:
> > > > > Anyway, I also have a tiy patch to try out (attached, not tested/
> > > > > not compiled). Please let me know how ifit makes any improvement.
> > > > No, unfortunately no improvement at all.
> > >
> > > Yeah, I figure there would not be any. Still I have a nagging suspicion
> > > that the mux gets confused and I would like to see the full dmesg with
> > > this patch applied and DEBUG enabled.
> > 
> > "dmesg" won't help, because the buffer gets filled too quickly. I send you the 
> > part from /var/log/messages since last boot. File size is 386KB, so I send it 
> > to you directly, not through the mailing list. You are free to forward it, if 
> > you think it's useful for others.
> >
> 
> Ok, this is much better, it confirms my suspicions... It seems that your
> keyboard controller gets confused where the data is coming from. Please
> try the patch below (against vanilla 2.6.7, not compiled/tested). 
> 

Ok, just to explain the problems that I see in the log you sent (I am also
CCing Vojtech Pavlik as he might be interested in some of the analysis):

> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux3, 12) [178780]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [178792]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: f2 <- i8042 (interrupt, aux3, 12) [178795]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [178797]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [178806]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: f0 <- i8042 (interrupt, aux3, 12) [178808]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 09 <- i8042 (interrupt, aux3, 12) [178810]
> Jun 28 16:01:16 qingwa kernel: i8042.c: MUX reports error condition 18 (35)
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux0, 12) [178822]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: fb <- i8042 (interrupt, aux3, 12) [178825]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 0a <- i8042 (interrupt, aux3, 12) [178827]
> Jun 28 16:01:16 qingwa kernel: drivers/input/serio/i8042.c: 08 <- i8042 (interrupt, aux3, 12) [178835]

The mux got confused as to where the byte came from. They byte itself seems to
be in line with other data in the stream. At this moment your mouse has probably
started jumping around. The patch I send earlier should help with this kind of
problem. 

> Jun 28 16:01:19 qingwa kernel: drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, kbd, 1) [181671]
> Jun 28 16:01:19 qingwa kernel: drivers/input/serio/i8042.c: 81 <- i8042 (interrupt, kbd, 1) [181738]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [181815]
> Jun 28 16:01:20 qingwa kernel: psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: ff <- i8042 (interrupt, aux3, 12) [181818]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [181819]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [181828]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux3, 12) [181830]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 01 <- i8042 (interrupt, kbd, 1) [181838]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [181840]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 38 <- i8042 (interrupt, aux3, 12) [181848]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: fd <- i8042 (interrupt, aux3, 12) [181850]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 81 <- i8042 (interrupt, kbd, 1) [181860]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: ff <- i8042 (interrupt, aux3, 12) [181862]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, kbd, 1) [181875]
> Jun 28 16:01:20 qingwa kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
> Jun 28 16:01:20 qingwa kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux3, 12) [181878]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [181880]

Not quite sure what all this is about... Did you plug external keyboard here?

> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 28 <- i8042 (interrupt, aux3, 12) [182553]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [182555]
> Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: ff <- i8042 (interrupt, aux3, 12) [182558]
> Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [184572]
> Jun 28 16:01:22 qingwa kernel: psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.
> Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c: ff <- i8042 (interrupt, aux3, 12) [184574]
> Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux3, 12) [184576]
> Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [184585]

It seems that we are missing a byte between ff and 18, delay between 2 bytes
is about a second... Where did the byte go? Do you have DMA turned on on your
hard driver? Anything polling battery status? Can't do anything here...

> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [188150]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 9c <- i8042 (interrupt, aux1, 12) [188152]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 05 <- i8042 (interrupt, aux1, 12) [188154]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [188155]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 8b <- i8042 (interrupt, aux1, 12) [188157]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [188474]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 9c <- i8042 (interrupt, aux1, 12) [188503]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 05 <- i8042 (interrupt, aux1, 12) [188503]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 85 <- i8042 (interrupt, aux1, 12) [188835]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 98 <- i8042 (interrupt, aux1, 12) [188835]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 80 <- i8042 (interrupt, aux1, 12) [188836]
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [188838]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [188839]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [188841]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [188843]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:26 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [188844]
> Jun 28 16:01:26 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1

Ok, here we lost byte right after 8b before 80 so it took 80 as the last byte
of a packet instead of first byte of the next packet. The gap between bytes
is about 300ms so timeout was not detected. Because of that it had hard time
synching aftewards. This is a classic example when having too big timeout
actually hurts.

Could you change drivers/input/mouse/psmouse-base.c - psmouse_interrupt()
in call to time time_after HZ/2 to HZ/4. You may see more "lost x bytes"
messages but I bet touchpad handling will feel much better.

Vojtech, what is your opinion?

> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191319]
> Jun 28 16:01:29 qingwa kernel: i8042.c: MUX reports error condition b3 (35)
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux0, 12) [191325]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 52 <- i8042 (interrupt, aux1, 12) [191327]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191328]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 2e <- i8042 (interrupt, aux1, 12) [191330]
> Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191331]
> Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191333]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux1, 12) [191335]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 50 <- i8042 (interrupt, aux1, 12) [191336]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191338]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 29 <- i8042 (interrupt, aux1, 12) [191339]
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191342]
> Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
> Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191343]

Again MUX got confused momentarily, the patch should fix that.

> Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: b8 <- i8042 (interrupt, kbd, 1) [193334]
> Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: 9d <- i8042 (interrupt, kbd, 1) [193359]
> Jun 28 16:01:33 qingwa kernel: i8042.c: MUX reports error condition fd (f5)
> Jun 28 16:01:33 qingwa kernel: drivers/input/serio/i8042.c: fd <- i8042 (interrupt, aux3, 12, timeout) [195950]
> Jun 28 16:01:33 qingwa kernel: psmouse.c: bad data from KBC - timeout
> Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 13 <- i8042 (interrupt, kbd, 1) [198170]
> Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 93 <- i8042 (interrupt, kbd, 1) [198243]

This one seems to be legit and handled OK although I am not sure what caused
AUX3 to report timeout - it wasn't transmitting for quite some time.

> Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206317]
> Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [206320]
> Jun 28 16:01:44 qingwa kernel: i8042.c: MUX reports error condition 00 (35)
> Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux0, 12) [206326]
> Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206327]

Confused again...

Anyway, please try the patch and the change to the timeout in
psmouse_interrupt. I am anxiously awaiting result of your testing.

-- 
Dmitry

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Vojtech Pavlik]

On Wed, Jun 30, 2004 at 01:02:16AM -0500, Dmitry Torokhov wrote:

> Vojtech, what is your opinion?
> 
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191319]
> > Jun 28 16:01:29 qingwa kernel: i8042.c: MUX reports error condition b3 (35)
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux0, 12) [191325]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 52 <- i8042 (interrupt, aux1, 12) [191327]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191328]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 2e <- i8042 (interrupt, aux1, 12) [191330]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191331]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191333]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux1, 12) [191335]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 50 <- i8042 (interrupt, aux1, 12) [191336]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191338]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 29 <- i8042 (interrupt, aux1, 12) [191339]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191342]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191343]
> 
> Again MUX got confused momentarily, the patch should fix that.
> 
> > Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: b8 <- i8042 (interrupt, kbd, 1) [193334]
> > Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: 9d <- i8042 (interrupt, kbd, 1) [193359]
> > Jun 28 16:01:33 qingwa kernel: i8042.c: MUX reports error condition fd (f5)
> > Jun 28 16:01:33 qingwa kernel: drivers/input/serio/i8042.c: fd <- i8042 (interrupt, aux3, 12, timeout) [195950]
> > Jun 28 16:01:33 qingwa kernel: psmouse.c: bad data from KBC - timeout
> > Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 13 <- i8042 (interrupt, kbd, 1) [198170]
> > Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 93 <- i8042 (interrupt, kbd, 1) [198243]
> 
> This one seems to be legit and handled OK although I am not sure what caused
> AUX3 to report timeout - it wasn't transmitting for quite some time.
> 
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206317]
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [206320]
> > Jun 28 16:01:44 qingwa kernel: i8042.c: MUX reports error condition 00 (35)
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux0, 12) [206326]
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206327]
> 
> Confused again...
> 
> Anyway, please try the patch and the change to the timeout in
> psmouse_interrupt. I am anxiously awaiting result of your testing.

This looks like the i8042 chip is busy with something else than getting
the touchpad data to us.

This could, for example, be getting battery/thermal data to ACPI,
because it's commonly used as an ACPI EC (Embedded Controller) as well
as for handling the keyboard/mouse.  I'd suggest disabling ACPI
completely (not just ACPI=off, but CONFIG_ACPI=n), same for APM,
frequency scaling, and everything else that could access the BIOS. 

If that helps, then we'll need to find a way how to make sure we let
ACPI use the chip reasonably so that it doesn't cause these problems.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Vojtech Pavlik]

On Wed, Jun 30, 2004 at 01:02:16AM -0500, Dmitry Torokhov wrote:

> Vojtech, what is your opinion?
> 
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191319]
> > Jun 28 16:01:29 qingwa kernel: i8042.c: MUX reports error condition b3 (35)
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux0, 12) [191325]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 52 <- i8042 (interrupt, aux1, 12) [191327]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191328]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 2e <- i8042 (interrupt, aux1, 12) [191330]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191331]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191333]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: b3 <- i8042 (interrupt, aux1, 12) [191335]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 50 <- i8042 (interrupt, aux1, 12) [191336]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: d0 <- i8042 (interrupt, aux1, 12) [191338]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 29 <- i8042 (interrupt, aux1, 12) [191339]
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: 30 <- i8042 (interrupt, aux1, 12) [191342]
> > Jun 28 16:01:29 qingwa kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
> > Jun 28 16:01:29 qingwa kernel: drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, aux1, 12) [191343]
> 
> Again MUX got confused momentarily, the patch should fix that.
> 
> > Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: b8 <- i8042 (interrupt, kbd, 1) [193334]
> > Jun 28 16:01:31 qingwa kernel: drivers/input/serio/i8042.c: 9d <- i8042 (interrupt, kbd, 1) [193359]
> > Jun 28 16:01:33 qingwa kernel: i8042.c: MUX reports error condition fd (f5)
> > Jun 28 16:01:33 qingwa kernel: drivers/input/serio/i8042.c: fd <- i8042 (interrupt, aux3, 12, timeout) [195950]
> > Jun 28 16:01:33 qingwa kernel: psmouse.c: bad data from KBC - timeout
> > Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 13 <- i8042 (interrupt, kbd, 1) [198170]
> > Jun 28 16:01:36 qingwa kernel: drivers/input/serio/i8042.c: 93 <- i8042 (interrupt, kbd, 1) [198243]
> 
> This one seems to be legit and handled OK although I am not sure what caused
> AUX3 to report timeout - it wasn't transmitting for quite some time.
> 
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206317]
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: c0 <- i8042 (interrupt, aux1, 12) [206320]
> > Jun 28 16:01:44 qingwa kernel: i8042.c: MUX reports error condition 00 (35)
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux0, 12) [206326]
> > Jun 28 16:01:44 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux1, 12) [206327]
> 
> Confused again...
> 
> Anyway, please try the patch and the change to the timeout in
> psmouse_interrupt. I am anxiously awaiting result of your testing.
 
We may also want to disable the timer polling the chip - that might be
confusing it as well.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Mittwoch, 30. Juni 2004 08.02 schrieb Dmitry Torokhov unter "Re: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> The mux got confused as to where the byte came from. They byte itself seems
> to be in line with other data in the stream. At this moment your mouse has
> probably started jumping around. The patch I send earlier should help with
> this kind of problem.

Well, there are several things:
 1) Cursor hangs on system load with internal mousepad
    (no external mouse connected)
 2) Cursor jumps a bit with internal mousepad
    (no external mouse connected)
 3) Cursor jumps like crazy when moving external mouse
 4) Cursor randomly clicks when moving external mouse
 5) Hitting the mouse pad does not do a button1-click
 6) Sometimes the keyboard does not work anymore or 
    sends neverending random events - even with no
    external mouse/keyboard

I did not recognize that the previous patch helped in any of these problems, 
but No. 2 is the hardest to check, because I have to work for a while until 
it occurs.

The second patch does not help either.

The i8042.nodemux option only "resolved" No. 3 and No. 4, because the external 
mouse was no more available. Until now, nothing makes anything better.


> > drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux3, 12) [181878]
> > Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <- i8042
> > (interrupt, aux3, 12) [181880]

> Not quite sure what all this is about... Did you plug external keyboard
> here?

Possible.


> > [184574] Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c: 00
> > <- i8042 (interrupt, aux3, 12) [184576] Jun 28 16:01:22 qingwa kernel:
> > drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12) [184585]

> It seems that we are missing a byte between ff and 18, delay between 2
> bytes is about a second... Where did the byte go? Do you have DMA turned on
> on your hard driver? Anything polling battery status? Can't do anything
> here...

Do you mean hard disk DMA? Then Yes for DMA and yes for polling.


> Could you change drivers/input/mouse/psmouse-base.c - psmouse_interrupt()
> in call to time time_after HZ/2 to HZ/4. You may see more "lost x bytes"
> messages but I bet touchpad handling will feel much better.

I'll try if I can find out what you mean...
...ok, did the change.

As far as I understand, it has only effect on internal touchpad. I will 
therefore need some time for long time check. You'll hear from me later, but 
this surely won't resolve problems No. 2 - 6.

It is now together with your second patch, you first patch is no more in my 
sources. Is this good? (I understand that by "Vanilla" you mean the original 
source without your first patch?)


Regards
Marc

RE: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

> Am Mittwoch, 30. Juni 2004 08.02 schrieb Dmitry Torokhov unter "Re:
> Continue:
> psmouse.c - synaptics touchpad driver sync problem":
> > The mux got confused as to where the byte came from. They byte itself
> > seems to be in line with other data in the stream. At this moment your
> > mouse has probably started jumping around. The patch I send earlier
> > should help with this kind of problem.
> 
> Well, there are several things:
>  1) Cursor hangs on system load with internal mousepad
>     (no external mouse connected)

You mean when the system load is high? Yes, that can happen.. 

>  2) Cursor jumps a bit with internal mousepad
>     (no external mouse connected)
>  3) Cursor jumps like crazy when moving external mouse
>  4) Cursor randomly clicks when moving external mouse

Has the external mouse ever worked in 2.6? Or is it always
just randomly clickng stuff? Have you tried connecting another
mouse?

>  5) Hitting the mouse pad does not do a button1-click

I gather you do not have the X Synaptis driver installed?
Check out http://w1.894.telia.com/~u89404340/touchpad/index.html

>  6) Sometimes the keyboard does not work anymore or
>     sends neverending random events - even with no
>     external mouse/keyboard
> 
> I did not recognize that the previous patch helped in any of these
> problems, but No. 2 is the hardest to check, because I have to work
> for a while until it occurs.
> 
> The second patch does not help either.
> 
> The i8042.nodemux option only "resolved" No. 3 and No. 4, because the
> external mouse was no more available. Until now, nothing makes anything
> better.
>

Just to confirm - you are saying that the touchpad + external mouse
worked together fine in 2.4 but in 2.6 with i8042.nomux the external
mouse does not work, correct?
 
> 
> > > drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux3, 12)
> [181878]
> > > Jun 28 16:01:20 qingwa kernel: drivers/input/serio/i8042.c: 00 <-
> i8042
> > > (interrupt, aux3, 12) [181880]
> 
> > Not quite sure what all this is about... Did you plug external keyboard
> > here?
> 
> Possible.
> 
> 
> > > [184574] Jun 28 16:01:22 qingwa kernel: drivers/input/serio/i8042.c:
> 00
> > > <- i8042 (interrupt, aux3, 12) [184576] Jun 28 16:01:22 qingwa kernel:
> > > drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, aux3, 12)
> [184585]
> 
> > It seems that we are missing a byte between ff and 18, delay between 2
> > bytes is about a second... Where did the byte go? Do you have DMA turned
> > on on your hard driver? Anything polling battery status? Can't do
> > anything here...
> 
> Do you mean hard disk DMA? Then Yes for DMA and yes for polling.
>

Ok, what program does the polling? What is the polling interval? Does
it help if you stop the program?

> 
> > Could you change drivers/input/mouse/psmouse-base.c - psmouse_interrupt()
> > in call to time time_after HZ/2 to HZ/4. You may see more "lost x bytes"
> > messages but I bet touchpad handling will feel much better.
> 
> I'll try if I can find out what you mean...
> ...ok, did the change.
> 
> As far as I understand, it has only effect on internal touchpad. I will
> therefore need some time for long time check. You'll hear from me later,
> but this surely won't resolve problems No. 2 - 6.
> 
> It is now together with your second patch, you first patch is no more in
> my sources. Is this good? (I understand that by "Vanilla" you mean the
> original source without your first patch?)

Yes.

--
Dmitry

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

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

Dmitry: On synaptics page, I've seen that you've got tons of bugfixes for 
2.6.7 on http://www.geocities.com/dt_or/input/2_6_7. Do I need something from 
there and is there a patch that contains all patches?


Sorry, I was in a hurry and forgot to attach the new kernel log file in my 
last mail. It is in the attachment, a log with the second patch you sent me.
The patch is installed in messages-noacpi and ACPI disabled.
 -> Why is the trace now so small? Did you disable DEBUG in your patch?
    ...oh yes! Then I'll have to recompile and retry...


Also I deinstalled the Powermanagement and ACPI in kernel configuration, as 
suggested by Pavlik. Result is:
No, it still does not work, problem No. 3/4 reproduced, the powermanagement is 
not the problem (see messages-noacpi)!


Am Mittwoch, 30. Juni 2004 15.23 schrieb Dmitry Torokhov unter "RE: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> > Am Mittwoch, 30. Juni 2004 08.02 schrieb Dmitry Torokhov unter "Re:
> > Continue:
> >
> > psmouse.c - synaptics touchpad driver sync problem":
> > > The mux got confused as to where the byte came from. They byte itself
> > > seems to be in line with other data in the stream. At this moment your
> > > mouse has probably started jumping around. The patch I send earlier
> > > should help with this kind of problem.
> >
> > Well, there are several things:
> >  1) Cursor hangs on system load with internal mousepad
> >     (no external mouse connected)
>
> You mean when the system load is high? Yes, that can happen..

System load does not have to be really high, so it happens quite often. This 
is very disturbing, like in MacOS 15 years ago! (That was one of the main 
reasons for me not to use Mac, besides the fact that an application could 
crash the whole system!) I think we now have a multitasking OS, haven't 
we?!? :-(

It is sometimes better, sometimes worse, but not really depending on system 
load, it seems. Just a minute ago it was really bad. Strange.


> >  2) Cursor jumps a bit with internal mousepad
> >     (no external mouse connected)
> >  3) Cursor jumps like crazy when moving external mouse
> >  4) Cursor randomly clicks when moving external mouse
>
> Has the external mouse ever worked in 2.6? Or is it always
> just randomly clickng stuff? Have you tried connecting another
> mouse?

No and yes. At home I have a wheel mouse, at work a normal PS/2 mouse, both 
with diffrent keyboards and both with the same problem. I never successfully 
used an external mouse since I upgraded to SuSE 9.1 (Kernel 2.6). I had no 
problems with kernel 2.4 and the same hardware.


> >  5) Hitting the mouse pad does not do a button1-click
>
> I gather you do not have the X Synaptis driver installed?
> Check out http://w1.894.telia.com/~u89404340/touchpad/index.html

I see. I'll try the tool. In kernel 2.4, no addidional driver was necessary, 
it always worked out of the box.

Isn't there an apt4rpm repository for SuSE 9.1 with these tools anywhere? 
Obviously not in the repositories of my sources.list. :-(

Pavlik: You work for SuSE? If synaptics is so vital for a touchpad to  work, 
why aren't tools and driver installed and configured by SuSE 9.1 per default? 
It is even not part of the distribution!?!


> >  6) Sometimes the keyboard does not work anymore or
> >     sends neverending random events - even with no
> >     external mouse/keyboard
> >
> > I did not recognize that the previous patch helped in any of these
> > problems, but No. 2 is the hardest to check, because I have to work
> > for a while until it occurs.
> >
> > The second patch does not help either.
> >
> > The i8042.nodemux option only "resolved" No. 3 and No. 4, because the
> > external mouse was no more available. Until now, nothing makes anything
> > better.
>
> Just to confirm - you are saying that the touchpad + external mouse
> worked together fine in 2.4 but in 2.6 with i8042.nomux the external
> mouse does not work, correct?

Yes, I had none of all six problems in 2.4.

For i8042.nomux, I check it again, just to be sure...
...yes, the external keyboard works, but not the external mouse


> > > It seems that we are missing a byte between ff and 18, delay between 2
> > > bytes is about a second... Where did the byte go? Do you have DMA
> > > turned on on your hard driver? Anything polling battery status? Can't
> > > do anything here...
> >
> > Do you mean hard disk DMA? Then Yes for DMA and yes for polling.
>
> Ok, what program does the polling? What is the polling interval? Does
> it help if you stop the program?

I don't really know how many daemons are polling. On the desktop, I run 
kpowersave and I configured powersaving so that it should shotdown before 
battery is ampty, so there must be a daemon polling. It's just configure with 
normal KDE/YaST powersaving controls.


Regards
Marc

[-- Attachment #2: messages-noacpi --]
[-- Type: text/plain, Size: 5889 bytes --]

Jul  1 12:36:24 qingwa syslogd 1.4.1: restart.
Jul  1 12:36:24 qingwa hcid[1994]: HCI daemon ver 2.4 started
Jul  1 12:36:25 qingwa sdpd[2005]: sdpd v1.5 started 
Jul  1 12:36:27 qingwa rcpowersaved: INFO: Your system does neither support ACPI nor APM. the powersave service does not provide any features for this machine, therefore the service is skipped.
Jul  1 12:36:28 qingwa rcpowersaved: CPU frequency scaling is not supported by your processor.
Jul  1 12:36:28 qingwa rcpowersaved: enter 'POWERSAVE_CPUFREQD_MODULE=off' in /etc/sysconfig/powersave/common to avoid this warning.
Jul  1 12:36:28 qingwa [powersaved][2145]: ERROR in Function checkACPI; line 30: Neither APM nor ACPI is supported!
Jul  1 12:36:28 qingwa sshd[2202]: Server listening on :: port 22.
Jul  1 12:36:29 qingwa kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jul  1 12:36:29 qingwa kernel: Inspecting /boot/System.map-2.6.7
Jul  1 12:36:29 qingwa kernel: Loaded 27761 symbols from /boot/System.map-2.6.7.
Jul  1 12:36:29 qingwa kernel: Symbols match kernel version 2.6.7.
Jul  1 12:36:29 qingwa kernel: No module symbols loaded - kernel modules not enabled. 
Jul  1 12:36:29 qingwa kernel: XFS mounting filesystem loop0
Jul  1 12:36:29 qingwa kernel: Ending clean XFS mount for filesystem: loop0
Jul  1 12:36:29 qingwa kernel: Linux Kernel Card Services
Jul  1 12:36:29 qingwa kernel:   options:  [pci] [cardbus]
Jul  1 12:36:29 qingwa kernel: PCI: Found IRQ 11 for device 0000:00:03.0
Jul  1 12:36:29 qingwa kernel: PCI: Sharing IRQ 11 with 0000:00:01.4
Jul  1 12:36:29 qingwa kernel: Yenta: CardBus bridge found at 0000:00:03.0 [1584:3000]
Jul  1 12:36:29 qingwa kernel: Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Jul  1 12:36:29 qingwa kernel: Socket status: 30000821
Jul  1 12:36:29 qingwa kernel: Bluetooth: Core ver 2.5
Jul  1 12:36:29 qingwa kernel: NET: Registered protocol family 31
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI device and connection manager initialized
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI socket layer initialized
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI USB driver ver 2.6
Jul  1 12:36:29 qingwa kernel: usbcore: registered new driver hci_usb
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI UART driver ver 2.1
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI H4 protocol initialized
Jul  1 12:36:29 qingwa kernel: Bluetooth: HCI BCSP protocol initialized
Jul  1 12:36:29 qingwa kernel: Bluetooth: VHCI driver ver 1.1
Jul  1 12:36:29 qingwa kernel: Bluetooth: L2CAP ver 2.2
Jul  1 12:36:29 qingwa kernel: Bluetooth: L2CAP socket layer initialized
Jul  1 12:36:29 qingwa kernel: NET: Registered protocol family 10
Jul  1 12:36:29 qingwa kernel: Disabled Privacy Extensions on device c0343c40(lo)
Jul  1 12:36:29 qingwa kernel: IPv6 over IPv4 tunneling driver
Jul  1 12:36:29 qingwa kernel: Disabled Privacy Extensions on device c9f65000(sit0)
Jul  1 12:36:33 qingwa ifup: No configuration found for sit0
Jul  1 12:36:49 qingwa kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
Jul  1 12:36:49 qingwa kernel: usbcore: registered new driver usbserial
Jul  1 12:36:49 qingwa kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
Jul  1 12:36:58 qingwa /usr/sbin/cron[7758]: (CRON) STARTUP (fork ok) 
Jul  1 12:36:59 qingwa kernel: Non-volatile memory driver v1.2
Jul  1 12:37:00 qingwa kernel: end_request: I/O error, dev fd0, sector 0
Jul  1 12:37:00 qingwa kernel: end_request: I/O error, dev fd0, sector 0
Jul  1 12:37:00 qingwa kernel: hdc: ATAPI 24X DVD-ROM drive, 512kB Cache
Jul  1 12:37:00 qingwa kernel: Uniform CD-ROM driver Revision: 3.20
Jul  1 12:37:00 qingwa /etc/hotplug/block.agent[7835]: grep: /sys/class/scsi_host/ide1/proc_name: No such file or directory
Jul  1 12:37:00 qingwa /etc/hotplug/block.agent[7835]: grep: /sys/class/scsi_host/ide1/proc_name: No such file or directory
Jul  1 12:37:00 qingwa kernel: st: Version 20040403, fixed bufsize 32768, s/g segs 256
Jul  1 12:37:00 qingwa kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
Jul  1 12:37:00 qingwa /etc/hotplug/block.agent[7835]: new block device /block/hdc
Jul  1 12:37:01 qingwa kernel: BIOS EDD facility v0.15 2004-May-17, 1 devices found
Jul  1 12:37:12 qingwa kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
Jul  1 12:37:12 qingwa kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
Jul  1 12:37:12 qingwa kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
Jul  1 12:37:14 qingwa kdm: :0[8104]: pam_unix2: session started for user marc, service xdm-np 
Jul  1 12:38:10 qingwa gconfd (marc-8863): (Version 2.4.0.1) wird gestartet, Prozesskennung 8863, Benutzer »marc«
Jul  1 12:38:10 qingwa gconfd (marc-8863): Die Adresse »xml:readonly:/etc/opt/gnome/gconf/gconf.xml.mandatory« wurde an der Position 0 zu einer nur lesbaren Konfigurationsquelle aufgelöst
Jul  1 12:38:10 qingwa gconfd (marc-8863): Die Adresse »xml:readwrite:/home/marc/.gconf« wurde an der Position 1 zu einer schreibbaren Konfigurationsquelle aufgelöst
Jul  1 12:38:10 qingwa gconfd (marc-8863): Die Adresse »xml:readonly:/etc/opt/gnome/gconf/gconf.xml.defaults« wurde an der Position 2 zu einer nur lesbaren Konfigurationsquelle aufgelöst
Jul  1 12:38:46 qingwa kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
Jul  1 12:38:46 qingwa kernel: input: PS/2 Logitech Mouse on isa0060/serio4
Jul  1 12:39:03 qingwa kernel: psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away.
Jul  1 12:39:06 qingwa kernel: psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away.
Jul  1 12:39:29 qingwa kernel: psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

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

Ok, here's the /var/log/messages with your patch *and* DEBUG enabled. I 
gzipped it, otherwise it's too big.

Regards
Marc

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

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

On Thursday 01 July 2004 07:34 am, Marc Waeckerlin wrote:
> Dmitry: On synaptics page, I've seen that you've got tons of bugfixes for 
> 2.6.7 on http://www.geocities.com/dt_or/input/2_6_7. Do I need something from 
> there and is there a patch that contains all patches?
>

These are serio sysfs integration patches, they should not change the behavior
of the system.
 
> > >
> > > Well, there are several things:
> > >  1) Cursor hangs on system load with internal mousepad
> > >     (no external mouse connected)
> >
> > You mean when the system load is high? Yes, that can happen..
> 
> System load does not have to be really high, so it happens quite often. This 
> is very disturbing, like in MacOS 15 years ago! (That was one of the main 
> reasons for me not to use Mac, besides the fact that an application could 
> crash the whole system!) I think we now have a multitasking OS, haven't 
> we?!? :-(
> 
> It is sometimes better, sometimes worse, but not really depending on system 
> load, it seems. Just a minute ago it was really bad. Strange.

I usually feel some hesitation in cursor movement under high disk load -
do you experience something like that? Although, now that I think about it,
it's usually not the cursor itself but KDE is lagging to redraw...

> 
> 
> > >  2) Cursor jumps a bit with internal mousepad
> > >     (no external mouse connected)
> > >  3) Cursor jumps like crazy when moving external mouse
> > >  4) Cursor randomly clicks when moving external mouse
> >
> > Has the external mouse ever worked in 2.6? Or is it always
> > just randomly clickng stuff? Have you tried connecting another
> > mouse?
> 
> No and yes. At home I have a wheel mouse, at work a normal PS/2 mouse, both 
> with diffrent keyboards and both with the same problem. I never successfully 
> used an external mouse since I upgraded to SuSE 9.1 (Kernel 2.6). I had no 
> problems with kernel 2.4 and the same hardware.
> 

Just out of curiosity, what happens when you pass psmouse.proto=bare to the
kernel as a boot option (or put "options psmouse proto=bare" in your
/etc/modprobe.conf file if psmouse is compiled as a module)?	

-- 
Dmitry

RE: Continue: psmouse.c - synaptics touchpad driver sync problem

[Dmitry Torokhov]

Marc Waeckerlin wrote:
> 
> Ok, here's the /var/log/messages with your patch *and* DEBUG enabled. I
> gzipped it, otherwise it's too big.
> 

I see absolutely nothing wrong in the data stream from your external
mouse, so... how is it configured in X{Free86|org}? What type is it?
Does it work in text console (with GPM)? What is your GPM setup?

Try this - in the text console do:

gpm -k
gpm -m /dev/input/mice -t ps2

Try working the mouse, is it good?

--
Dmitry   

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Donnerstag, 1. Juli 2004 15.03 schrieb Dmitry Torokhov unter "Re: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> On Thursday 01 July 2004 07:34 am, Marc Waeckerlin wrote:

> I usually feel some hesitation in cursor movement under high disk load -
> do you experience something like that? Although, now that I think about it,
> it's usually not the cursor itself but KDE is lagging to redraw...

No, definitely the cursor. And not only if the HD usage is high, sometimes if 
the CPU load is high, the problem starts, and if CPU and HD usage are low 
again, the problem is still remaining. I cannot really see a clear 
correlation between system load and mouse waiting, but there seems to be some 
sort of weak correlation.


> Just out of curiosity, what happens when you pass psmouse.proto=bare to the
> kernel as a boot option (or put "options psmouse proto=bare" in your
> /etc/modprobe.conf file if psmouse is compiled as a module)?

I'll try later, but what should habben, what should I look for?


Regards
Marc

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Donnerstag, 1. Juli 2004 15.54 schrieb Dmitry Torokhov unter "RE: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> I see absolutely nothing wrong in the data stream from your external
> mouse, so... how is it configured in X{Free86|org}? What type is it?

XFree86-4.3.99.902-40


> Does it work in text console (with GPM)? What is your GPM setup?
> Try this - in the text console do:
> gpm -k
> gpm -m /dev/input/mice -t ps2
> Try working the mouse, is it good?

Cool! I get exact the same weird problem!

So the problem of the wild clicking Mouse is *not* limited to X11!!!

That means, it must be the kernel...

Regards
Marc

Re: Continue: psmouse.c - synaptics touchpad driver sync problem

[Marc Waeckerlin]

Am Donnerstag, 1. Juli 2004 15.03 schrieb Dmitry Torokhov unter "Re: Continue: 
psmouse.c - synaptics touchpad driver sync problem":
> Just out of curiosity, what happens when you pass psmouse.proto=bare to the
> kernel as a boot option (or put "options psmouse proto=bare" in your
> /etc/modprobe.conf file if psmouse is compiled as a module)?    

I tested again with psmouse.proto=bare and psmouse.resetafter=3 and *internal* 
touchpad/keyboard *only*. Last time, I told you, there's no ovious effect and 
it still does not work. That might be correct for the external equipment, but 
with internal mouse, the effects are much more subtile:


psmouse.proto=bare

 -> Now the internal mouse behaves as bad as the external one! It jumps around 
like crazy and clicks everywhere. That means, problems No. 3 and No.4 now 
also apply to the internal mouse!

 -> But problem No. 5 is resolved! Clicking on the touchpad does a button-1 
click.


psmouse.resetafter=3

 -> Problems No. 1 and No. 2 now become much worse! That means when moving the 
mouse cursor, cursor often stops/blocks. Then I have to keep the fingers off 
the touchpad for several seconds, before I can continue to move the mouse. 
Either regardless of the system load, or the lowest system load can start 
this effect, that's not so clear.

 -> Also the cursor now jumps much more than ever before.

So, that might be a way for a workaround: Can "reset" be disabled, e.g. 
secifying "psmouse.resetafter=0"?


Regards
Marc