Really annoying bug in the mouse driver

Really annoying bug in the mouse driver

[Victor Hahn]

Hello,

sorry if this mail goes to the wrong address or if I'm not providing the 
right information, but I'm just a regular user, not a hacker.

There is a really annoying bug in PS/2 mouse driver (this is psmouse.c I 
think). From time to time, the mouse is just going "crazy", just moving 
uncontrolledly over the screen and sometimes even clicking. After a 
short while, this goes back to normal. Sometimes, the uncontrolled 
behaviour does only occur while moving the mouse and the problem does 
not disappear without having the mouse moved a little.
If I switch to a console (e.g. CTRL+ALT+F1) and then back to X, this 
helps, too. After having this problem, I can find the following messages 
in /var/log/messages:

Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad parity
Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at 
isa0060/serio1/input0 lost
 synchronization, throwing 3 bytes away.

Sometimes, only one of these messages appears; the number of bytes in 
the second message varies, but mostly it is 3.

This bug is dependent on the mainboard (on the chipset I think). Here is 
an excerpt from my output of lspci:

00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo 
KT266/A/333 AGP]
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. 
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)

Having installed completely the same operating system this problem does 
not occur on a computer which has an other mainboard (and another chipset).

The problem is also dependend on the mouse. With some mouses, this 
problem occurs very often, with other, it does only occur rarely and 
with others it does not occur at all (unfortunately, I don't have of 
mouse of the last type). It seems that budget mouses are mostly affected 
by this bug while expensive mouses (e.g. Microsoft) are mostly not 
affected. On the internet, I read that this may be due to a low-quality 
mouse cable, but anyway, this problem does not occur with M$ Windows.

It seems that all 2.6-kernels have this problem, although some people on 
the internet wrote that this problem did not occur with kernel 2.6.1. I 
have got the problem with kernel 2.6.3, 2.6.9 and 2.6.10-rc3.

I really hope you can fix this bug, because it sometimes makes work very 
uncomfortable and I neither want to buy a new mainboard nor an expensive 
mouse I don't need actually.

Regards,
Victor

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Saturday 15 January 2005 08:16, Victor Hahn wrote:
> Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad parity
> Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at 
> isa0060/serio1/input0 lost
>  synchronization, throwing 3 bytes away.
> 
> Sometimes, only one of these messages appears; the number of bytes in 
> the second message varies, but mostly it is 3.
> 

Hi,

Could you please try the patch below?

Thanks!

-- 
Dmitry

===== psmouse-base.c 1.88 vs edited =====
--- 1.88/drivers/input/mouse/psmouse-base.c	2005-01-27 02:13:43 -05:00
+++ edited/psmouse-base.c	2005-01-28 00:05:08 -05:00
@@ -154,9 +154,19 @@
 				flags & SERIO_TIMEOUT ? " timeout" : "",
 				flags & SERIO_PARITY ? " bad parity" : "");
 		ps2_cmd_aborted(&psmouse->ps2dev);
+		if (psmouse->resend || serio_write(serio, PSMOUSE_CMD_RESEND)) {
+			psmouse->resend = 0;
+			psmouse->state = PSMOUSE_IGNORE;
+			serio_reconnect(serio);
+		} else {
+			psmouse->pktcnt = 0;
+			psmouse->resend = 1;
+		}
 		goto out;
 	}
 
+	psmouse->resend = 0;
+
 	if (unlikely(psmouse->ps2dev.flags & PS2_FLAG_ACK))
 		if  (ps2_handle_ack(&psmouse->ps2dev, data))
 			goto out;
@@ -173,6 +183,10 @@
 		printk(KERN_WARNING "psmouse.c: %s at %s lost synchronization, throwing %d bytes away.\n",
 		       psmouse->name, psmouse->phys, psmouse->pktcnt);
 		psmouse->pktcnt = 0;
+		if (serio_write(serio, PSMOUSE_CMD_RESEND) == 0) {
+			psmouse->resend = 1;
+			psmouse->last = jiffies;
+		}
 	}
 
 	psmouse->last = jiffies;
===== psmouse.h 1.25 vs edited =====
--- 1.25/drivers/input/mouse/psmouse.h	2004-10-16 06:15:31 -05:00
+++ edited/psmouse.h	2005-01-28 00:04:47 -05:00
@@ -13,6 +13,7 @@
 #define PSMOUSE_CMD_ENABLE	0x00f4
 #define PSMOUSE_CMD_DISABLE	0x00f5
 #define PSMOUSE_CMD_RESET_DIS	0x00f6
+#define PSMOUSE_CMD_RESEND	0x00fe
 #define PSMOUSE_CMD_RESET_BAT	0x02ff
 
 #define PSMOUSE_RET_BAT		0xaa
@@ -45,6 +46,7 @@
 	unsigned char pktsize;
 	unsigned char type;
 	unsigned char model;
+	unsigned char resend;
 	unsigned long last;
 	unsigned long out_of_sync;
 	enum psmouse_state state;

Re: Really annoying bug in the mouse driver

[Victor Hahn]

Hi Dmitry,

thank you for the patch! Unfortunately, I wasn't able to apply it 
correctly, neither to kernel 2.6.10 nor to kernel 2.6.4. Here's the 
error message I got:

root@vic:/mnt/hdb3/Installationsdateien/SOURCES/linux-2.6.10# patch -p1 
< /home/victor/patch-mouse.diff
patching file drivers/input/mouse/psmouse-base.c
Hunk #1 FAILED at 154.
Hunk #2 succeeded at 220 (offset 37 lines).
1 out of 2 hunks FAILED -- saving rejects to file 
drivers/input/mouse/psmouse-base.c.rej
patching file drivers/input/mouse/psmouse.h
Hunk #1 succeeded at 11 (offset -2 lines).
Hunk #2 succeeded at 50 with fuzz 1 (offset 4 lines).

And here's the contents of drivers/input/mouse/psmouse-base.c.rej (same 
in both kernel versions):

***************
*** 154,162 ****
                                flags & SERIO_TIMEOUT ? " timeout" : "",
                                flags & SERIO_PARITY ? " bad parity" : "");
                ps2_cmd_aborted(&psmouse->ps2dev);
                goto out;
        }

        if (unlikely(psmouse->ps2dev.flags & PS2_FLAG_ACK))
                if  (ps2_handle_ack(&psmouse->ps2dev, data))
                        goto out;
--- 154,172 ----
                                flags & SERIO_TIMEOUT ? " timeout" : "",
                                flags & SERIO_PARITY ? " bad parity" : "");
                ps2_cmd_aborted(&psmouse->ps2dev);
+               if (psmouse->resend || serio_write(serio, 
PSMOUSE_CMD_RESEND)) {
+                       psmouse->resend = 0;
+                       psmouse->state = PSMOUSE_IGNORE;
+                       serio_reconnect(serio);
+               } else {
+                       psmouse->pktcnt = 0;
+                       psmouse->resend = 1;
+               }
                goto out;
        }

+       psmouse->resend = 0;
+
        if (unlikely(psmouse->ps2dev.flags & PS2_FLAG_ACK))
                if  (ps2_handle_ack(&psmouse->ps2dev, data))
                        goto out;

I compiled the kernel (2.6.10) like this anyway but this made it even 
worse: The problem still did occur, but it didn't go away any more, 
neither by waiting nor by moving the mouse nor by switching to a 
console. I still get the same error message as before, but this is now 
additionally printed to tty1.

It would be great if you could help me with this.

Regards,
Victor



Dmitry Torokhov wrote:

>On Saturday 15 January 2005 08:16, Victor Hahn wrote:
>  
>
>>Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad parity
>>Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at 
>>isa0060/serio1/input0 lost
>> synchronization, throwing 3 bytes away.
>>
>>Sometimes, only one of these messages appears; the number of bytes in 
>>the second message varies, but mostly it is 3.
>>
>>    
>>
>
>Hi,
>
>Could you please try the patch below?
>
>Thanks!
>
>  
>

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Tue, 01 Feb 2005 09:54:37 +0100, Victor Hahn <victorhahn@web.de> wrote:
> Hi Dmitry,
> 
> thank you for the patch! Unfortunately, I wasn't able to apply it
> correctly, neither to kernel 2.6.10 nor to kernel 2.6.4.

Sorry, I think it will apply to 2.6.11-rc2, I'll try to rediff against
2.6.10 later tonight.

-- 
Dmitry

Re: Really annoying bug in the mouse driver

[Victor Hahn]

Dmitry Torokhov wrote:

>Sorry, I think it will apply to 2.6.11-rc2, I'll try to rediff against
>2.6.10 later tonight.
>

You don't need to do extra work to make it compatible with 2.6.10, I 
just applied it to 2.6.11-rc2, thanks. I'm just compiling it now, I'm 
looking forward to see the result!

Regards,
Victor

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Tuesday 01 February 2005 09:19, Victor Hahn wrote:
> Dmitry Torokhov wrote:
> 
> >Sorry, I think it will apply to 2.6.11-rc2, I'll try to rediff against
> >2.6.10 later tonight.
> >
> 
> You don't need to do extra work to make it compatible with 2.6.10, I 
> just applied it to 2.6.11-rc2, thanks. I'm just compiling it now, I'm 
> looking forward to see the result!
> 

Any luck with the patch?

-- 
Dmitry

Re: Really annoying bug in the mouse driver

[Victor Hahn]

Dmitry Torokhov wrote:

>Any luck with the patch?
>

I'm using 2.6.11rc2 with the patch for some hours now and it seems as if 
it doesn't throw away bytes any more which makes linux 2.6 useable for 
me again - thanks a lot! I just encountered one smaller issue (this 
really is much better than before): The mouse just "jumped" once and 
then got back to normal immediately. This gives me the following message 
in /var/log/messages:

kernel: psmouse.c: bad data from KBC - bad parity

Any idea about this?

Regards,
Victor

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Wednesday 02 February 2005 01:08, Victor Hahn wrote:
> Dmitry Torokhov wrote:
> 
> >Any luck with the patch?
> >
> 
> I'm using 2.6.11rc2 with the patch for some hours now and it seems as if 
> it doesn't throw away bytes any more which makes linux 2.6 useable for 
> me again - thanks a lot!

It still complains in dmesg about throwing away bytes, right? Please try
loading the box some more to make sure mouse survives some abuse.

> I just encountered one smaller issue (this  
> really is much better than before): The mouse just "jumped" once and 
> then got back to normal immediately. This gives me the following message 
> in /var/log/messages:
> 
> kernel: psmouse.c: bad data from KBC - bad parity
> 

Your keyboard controller reported that the byte transmitted from the mouse
was mangled somehow and we should not trust it. I am not sure why it would
make mouse jump.. was there any mention of "reconnect" in the logs? Did it
happen just once?

-- 
Dmitry

Re: Really annoying bug in the mouse driver

[Victor Hahn]

Dmitry Torokhov wrote:

>It still complains in dmesg about throwing away bytes, right? Please try
>loading the box some more to make sure mouse survives some abuse.
>  
>

No, it doesn't. The only message I still get is the one below. I've 
tried it with aprox. 90% CPU usage already and I didn't have any 
additional problems.

>>kernel: psmouse.c: bad data from KBC - bad parity
>>    
>>
>Your keyboard controller reported that the byte transmitted from the mouse
>was mangled somehow and we should not trust it. I am not sure why it would
>make mouse jump.. was there any mention of "reconnect" in the logs? Did it
>happen just once?
>

It happened once when I was at the computer and several times while I 
wasn't. There's no "reconnect" in the logs:

victor@vic:~$ cat /var/log/messages | grep reconnect
victor@vic:~$ 

Regards,
Victor

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Wed, 02 Feb 2005 11:22:43 +0100, Victor Hahn <victorhahn@web.de> wrote:
> Dmitry Torokhov wrote:
> 
> >It still complains in dmesg about throwing away bytes, right? Please try
> >loading the box some more to make sure mouse survives some abuse.
> >
> >
> 
> No, it doesn't. The only message I still get is the one below. I've
> tried it with aprox. 90% CPU usage already and I didn't have any
> additional problems.
>

Processor load we usually handle well, loaded disks are usually the
ones that cause >= 0.5 sec delays between bytes received by psmouse.
Please let me know if it still works with busy disks.

> >>kernel: psmouse.c: bad data from KBC - bad parity
> >>
> >>
> >Your keyboard controller reported that the byte transmitted from the mouse
> >was mangled somehow and we should not trust it. I am not sure why it would
> >make mouse jump.. was there any mention of "reconnect" in the logs? Did it
> >happen just once?
> >
> 
> It happened once when I was at the computer and several times while I
> wasn't.

Well, we won't be able to do anythng about parity errors themselves
but hopefully the patch will make them almost invisible for you. I
wonder if the jump could be explained by having a byte with 2 bits
flipped. KBC then would not detect parity error and psmouse would
process the byte as if it was good. This should not be happening too
often.

> There's no "reconnect" in the logs:
> 
> victor@vic:~$ cat /var/log/messages | grep reconnect
> victor@vic:~$

Ok, I was wondering if you hit parity error twice in a row and it
decided to reconnect.

-- 
Dmitry

Re: Really annoying bug in the mouse driver

[Victor Hahn]

Dmitry Torokhov wrote:

>Processor load we usually handle well, loaded disks are usually the
>ones that cause >= 0.5 sec delays between bytes received by psmouse.
>Please let me know if it still works with busy disks.
>  
>
Yes, it does work. I was copying several gigs from one partition to 
another and in the meantime copying some data to another computer via a 
100Mbit link and I didn't encounter any problems.

Since I use kernel 2.6.11-rc2 with your patch, I sometimes get a lot of 
very strange messages in /var/log/messages and on the terminal I'm 
currently working with. I mean something like this:

Feb  3 16:02:08 localhost kernel: Badness in local_bh_enable at 
kernel/softirq.c:140
Feb  3 16:02:08 localhost kernel:  [<c0122058>] local_bh_enable+0x88/0x90
Feb  3 16:02:08 localhost kernel:  [<f8a4e1d5>] 
ppp_send_frame+0x225/0x460 [ppp_generic]
Feb  3 16:02:08 localhost kernel:  [<c0125b69>] __mod_timer+0xf9/0x140
Feb  3 16:02:08 localhost kernel:  [<f8a4df42>] 
ppp_xmit_process+0x62/0xd0 [ppp_generic]
Feb  3 16:02:08 localhost kernel:  [<f8a4dbdc>] 
ppp_start_xmit+0xdc/0x250 [ppp_generic]
Feb  3 16:02:08 localhost kernel:  [<c03590bd>] qdisc_restart+0x14d/0x1c0
Feb  3 16:02:08 localhost kernel:  [<c034cbaf>] dev_queue_xmit+0x1cf/0x270
Feb  3 16:02:08 localhost kernel:  [<c0369a4d>] ip_finish_output2+0xdd/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0357fa1>] nf_hook_slow+0xf1/0x130
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c03673b5>] ip_finish_output+0x205/0x210
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c0369954>] dst_output+0x14/0x30
Feb  3 16:02:08 localhost kernel:  [<c0357fa1>] nf_hook_slow+0xf1/0x130
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c03679bd>] ip_queue_xmit+0x3cd/0x4f0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c036243b>] 
ip_route_output_slow+0x40b/0x880
Feb  3 16:02:08 localhost kernel:  [<c037e8e1>] tcp_v4_send_check+0x51/0xf0
Feb  3 16:02:08 localhost kernel:  [<c03787d0>] tcp_transmit_skb+0x440/0x730
Feb  3 16:02:08 localhost kernel:  [<c037af59>] tcp_connect+0x2c9/0x370
Feb  3 16:02:08 localhost kernel:  [<c037da54>] tcp_v4_connect+0x604/0xb90
Feb  3 16:02:08 localhost kernel:  [<c0342f76>] sock_aio_write+0xf6/0x120
Feb  3 16:02:08 localhost kernel:  [<c038dd1b>] 
inet_stream_connect+0x8b/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0343f43>] sys_connect+0x83/0xb0
Feb  3 16:02:08 localhost kernel:  [<c0342886>] sock_map_fd+0x116/0x140
Feb  3 16:02:08 localhost kernel:  [<c034385b>] __sock_create+0xfb/0x2a0
Feb  3 16:02:08 localhost kernel:  [<c020b522>] copy_from_user+0x42/0x70
Feb  3 16:02:08 localhost kernel:  [<c03449d1>] sys_socketcall+0xb1/0x260
Feb  3 16:02:08 localhost kernel:  [<c016ff4a>] sys_ioctl+0xaa/0x220
Feb  3 16:02:08 localhost kernel:  [<c0103257>] syscall_call+0x7/0xb
Feb  3 16:02:08 localhost kernel: Badness in local_bh_enable at 
kernel/softirq.c:140
Feb  3 16:02:08 localhost kernel:  [<c0122058>] local_bh_enable+0x88/0x90
Feb  3 16:02:08 localhost kernel:  [<f8a4dbdc>] 
ppp_start_xmit+0xdc/0x250 [ppp_generic]
Feb  3 16:02:08 localhost kernel:  [<c03590bd>] qdisc_restart+0x14d/0x1c0
Feb  3 16:02:08 localhost kernel:  [<c034cbaf>] dev_queue_xmit+0x1cf/0x270
Feb  3 16:02:08 localhost kernel:  [<c0369a4d>] ip_finish_output2+0xdd/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0357fa1>] nf_hook_slow+0xf1/0x130
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c03673b5>] ip_finish_output+0x205/0x210
Feb  3 16:02:08 localhost kernel:  [<c0369970>] ip_finish_output2+0x0/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c0369954>] dst_output+0x14/0x30
Feb  3 16:02:08 localhost kernel:  [<c0357fa1>] nf_hook_slow+0xf1/0x130
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c03679bd>] ip_queue_xmit+0x3cd/0x4f0
Feb  3 16:02:08 localhost kernel:  [<c0369940>] dst_output+0x0/0x30
Feb  3 16:02:08 localhost kernel:  [<c036243b>] 
ip_route_output_slow+0x40b/0x880
Feb  3 16:02:08 localhost kernel:  [<c037e8e1>] tcp_v4_send_check+0x51/0xf0
Feb  3 16:02:08 localhost kernel:  [<c03787d0>] tcp_transmit_skb+0x440/0x730
Feb  3 16:02:08 localhost kernel:  [<c037af59>] tcp_connect+0x2c9/0x370
Feb  3 16:02:08 localhost kernel:  [<c037da54>] tcp_v4_connect+0x604/0xb90
Feb  3 16:02:08 localhost kernel:  [<c0342f76>] sock_aio_write+0xf6/0x120
Feb  3 16:02:08 localhost kernel:  [<c038dd1b>] 
inet_stream_connect+0x8b/0x1b0
Feb  3 16:02:08 localhost kernel:  [<c0343f43>] sys_connect+0x83/0xb0
Feb  3 16:02:08 localhost kernel:  [<c0342886>] sock_map_fd+0x116/0x140
Feb  3 16:02:08 localhost kernel:  [<c034385b>] __sock_create+0xfb/0x2a0
Feb  3 16:02:08 localhost kernel:  [<c020b522>] copy_from_user+0x42/0x70
Feb  3 16:02:08 localhost kernel:  [<c03449d1>] sys_socketcall+0xb1/0x260
Feb  3 16:02:08 localhost kernel:  [<c016ff4a>] sys_ioctl+0xaa/0x220
Feb  3 16:02:08 localhost kernel:  [<c0103257>] syscall_call+0x7/0xb

What is it?

Regards,
Victor

Re: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Thu, 03 Feb 2005 16:05:40 +0100, Victor Hahn <victorhahn@web.de> wrote:
> Dmitry Torokhov wrote:
> 
> >Processor load we usually handle well, loaded disks are usually the
> >ones that cause >= 0.5 sec delays between bytes received by psmouse.
> >Please let me know if it still works with busy disks.
> >
> >
> Yes, it does work. I was copying several gigs from one partition to
> another and in the meantime copying some data to another computer via a
> 100Mbit link and I didn't encounter any problems.
> 

Great, thank you very much for testing it! I guess I should push it
upstream... I think that there is a small problem with the patch (it
may get upset on the boxes that don't have mouse connected and KBC
reports timeouts during probing), but it is fixable and shoudl not
affect your case.

> Since I use kernel 2.6.11-rc2 with your patch, I sometimes get a lot of
> very strange messages in /var/log/messages and on the terminal I'm
> currently working with. I mean something like this:
> 
...

Looks line network is upset - I'd ask networking guys - netdev@oss.sgi.com

-- 
Dmitry

Re: Really annoying bug in the mouse driver

[zhilla]

Dmitry Torokhov wrote:

>> Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad 
>> parity Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at 
>> isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.
>> Sometimes, only one of these messages appears; the number of bytes
>> in the second message varies, but mostly it is 3.
> Hi, Could you please try the patch below?

hello.. i have 100% same problem.
(mouse misbehaving, and being unable to use this patch against 2.6.10)
mouse is MS-600, a relatively cheap no name optical mouse. cable is OK.
thank you for your patch, but could you post a version that can be
applied against 2.6.10 version? thanks!