Continue: psmouse.c - synaptics touchpad driver sync problem

DISCUSSION Dmitry Torokhov 3 participants 6 messages Jun 29, 2004 – Jun 30, 2004 1 message not in the archive

Share & tools

Dmitry Torokhov

author

2004-06-29 14:32 UTC #0 lore raw

Quoted 10 lines · Marc Waeckerlin

Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
Continue:
psmouse.c - synaptics touchpad driver sync problem":
Quoted 2 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Dmitry Torokhov

author

2004-06-29 17:53 UTC #2 lore raw

Quoted 9 lines · Marc Waeckerlin

Am Dienstag, 29. Juni 2004 16.32 schrieben Sie unter "Re: Continue: psmouse.c
- synaptics touchpad driver sync problem":
Quoted 7 lines
Quoted 5 lines · Marc Waeckerlin
Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
Continue:
Quoted 2 lines
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.

Quoted 9 lines

Quoted 3 lines
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).

Quoted 5 lines

Quoted 2 lines
Is there any change of getting it?
What do you mean by this?

Nevermind ;)

Signature · 62 lines

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" : "",

Dmitry Torokhov

author

2004-06-30 06:02 UTC #3 lore raw

Quoted 20 lines · Dmitry Torokhov

Quoted 9 lines · Marc Waeckerlin
Am Dienstag, 29. Juni 2004 16.32 schrieben Sie unter "Re: Continue: psmouse.c
- synaptics touchpad driver sync problem":
Quoted 7 lines
Quoted 5 lines · Marc Waeckerlin
Am Freitag, 25. Juni 2004 16.02 schrieb Dmitry Torokhov unter "Re:
Continue:
Quoted 2 lines
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.
Quoted 9 lines
Quoted 3 lines
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.

Quoted 4 lines

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):

Quoted 4 lines

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]

Quoted 8 lines

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.

Quoted 11 lines

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]

Quoted 8 lines

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?

Quoted 8 lines

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...

Quoted 15 lines

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

Quoted 8 lines

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?

Quoted 9 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Signature · 1 line

Dmitry

Vojtech Pavlik

2004-06-30 08:24 UTC #4 lore raw

Quoted 39 lines · Dmitry Torokhov

Vojtech, what is your opinion?

Quoted 9 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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]

Quoted 4 lines

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.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs, SuSE CR

Vojtech Pavlik

2004-06-30 08:43 UTC #5 lore raw

In reply to Dmitry Torokhov

Quoted 39 lines · Dmitry Torokhov

Vojtech, what is your opinion?

Quoted 9 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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]

Quoted 4 lines

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.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs, SuSE CR

Marc Waeckerlin

2004-06-30 12:58 UTC #6 lore raw

In reply to Dmitry Torokhov

Am Mittwoch, 30. Juni 2004 08.02 schrieb Dmitry Torokhov unter "Re: Continue:
psmouse.c - synaptics touchpad driver sync problem":

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
[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.

Quoted 3 lines

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