Re: another must-fix: major PS/2 mouse problem

Albert Cahalan
2003-07-30T12:38:58Z

On Wed, 2003-07-30 at 01:08, Pavel Machek wrote:
> Hi!
>
> > > Loosing too many ticks!
> > > TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> > > Falling back to a sane timesource.
> > > psmouse.c: Lost synchronization, throwing 3 bytes away.
> > > psmouse.c: Lost synchronization, throwing 1 bytes away.
> > >
> > > Arrrrgh! The TSC is my only good time source!
> >
> > Arrrgh! More PS/2 problems!
> >
> > I think the lost synchronisation is the problem, would you agree?
> >
> > The person who fixes this gets a Nobel prize.
>
>
> If you set ps/2 synchronization timeout to 20 seconds, you are going to make vojtech
> unhappy (he likes that code :-), but at least 2.6.0 will not be worse than 2.4.x...
>
> Do you want me to create a patch?

No. That will just hide one symptom of the problem,
making things more difficult to debug.

It won't fix my clock, which the ntpd program keeps
complaining about. Under heavy load, my clock falls
behind so much that ntpd gives up on the gentle treatment
and just yanks the clock forward by as much as 10 minutes.

It won't make the mouse run well. Maybe you'd stop the
mouse from going crazy from time to time, but there'd
still temporary freezes from time to time. (not OK!)

It won't convince Linux that my TSC isn't broken.

It won't solve Mikael Pettersson's problem, posted
under the subject "[BUG] 2.6.0-test2 loses time on 486".
He writes:

"My old 486 test box is losing time at an alarming rate
when running 2.6.0-test kernels. It loses almost 2 minutes
per hour, less if it sits idle. This problem does not
occur when it's running a 2.4 kernel."

Gee, I get that too, on a 1 GHz Pentium III. It seems
we're all losing LOTS of clock ticks and other interrupts.

I took the net-related email addresses off the Cc: list.
Please leave me on it so I don't have to break threading.