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: > > [EMAIL PROTECTED]:~$ cat /var/log/messages | grep reconnect > [EMAIL PROTECTED]:~$ Ok, I was wondering if you hit parity error twice in a row and it decided to reconnect. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
