17:15:42 psmouse.c: Lost synchronization, throwing 1 bytes away.
17:15:42 psmouse.c: Lost synchronization, throwing 2 bytes away.
17:16:59 psmouse.c: Lost synchronization, throwing 2 bytes away.
17:16:59 psmouse.c: Lost synchronization, throwing 1 bytes away.
17:18:13 psmouse.c: Lost synchronization, throwing 1 bytes away.
17:18:13 psmouse.c: Lost synchronization, throwing 2 bytes away.
17:31:48 psmouse.c: Lost synchronization, throwing 1 bytes away.
17:31:48 psmouse.c: Lost synchronization, throwing 2 bytes away.
17:31:51 psmouse.c: Lost synchronization, throwing 1 bytes away.
17:31:51 psmouse.c: Lost synchronization, throwing 2 bytes away.
appear in the log.
Since packets are 3 bytes long and subsequent pairs of messages
(with the same time stamp) always throw out 3 bytes, the conclusion
is that in reality sync was never lost.
Indeed, it is only with 2.5 that this mouse has problems.
So, the test
if (psmouse->pktcnt && time_after(jiffies, psmouse->last + HZ/20)) {
printk(KERN_WARNING "psmouse.c: Lost synchronization, "
"throwing %d bytes away.\n",
psmouse->pktcnt);
psmouse->pktcnt = 0;
}
is no good. I just replaced HZ/20 by 5*HZ.
If mouse sync is really lost (which I never observed in the past ten years)
then I am quite willing to wait a moment. But it is bad when nothing
is wrong, just a slow machine, and the kernel invents and creates
the problems itself.
Andries
[This was 2.5.44.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/