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
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;
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!
>
>
>
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!
On Tue, 01 Feb 2005 09:54:37 +0100, Victor Hahn <[email protected]> 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
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
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
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
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
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
On Wed, 02 Feb 2005 11:22:43 +0100, Victor Hahn <[email protected]> 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
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
On Thu, 03 Feb 2005 16:05:40 +0100, Victor Hahn <[email protected]> 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 - [email protected]
--
Dmitry