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

Andrew Morton
2003-07-29T03:15:21Z

Albert Cahalan <albert@users.sourceforge.net> wrote:
>
> OK, I did this. Now, in microseconds, I get:
>
> ------------------------
> IRQ use min max
> --- -------- --- -------
> 0 timer 40 103968
> 1 i8042 14 1138 (was 389773)
> 2 cascade - -
> 3 - - -
> 4 serial 29 56
> 5 uhci-hcd - -
> 6 - 690 690
> 7 - 40 40
> 8 - - -
> 9 - - -
> 10 - - -
> 11 eth0 73 31332 (was 1535331)
> 12 i8042 18 215 (was 102895)
> 13 - - -
> 14 ide0 7 43846
> 15 ide1 7 12
> ------------------------
>
> boomerang_interrupt itself takes 4 to 59 microseconds.

So this looks OK, yes? (Is that instrumentation patch productisable?
Looks handly, albeit a subset of microstate accounting)

> Then I switched to 2.6.0-test2. Testing more, I get the
> problem with or without SMP and with or without
> preemption. Here's a chunk of my log file:
>
> 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.

> Remember that this is a pretty normal system. I have
> a Red Hat 8 install w/ required upgrades, ext3, IDE,
> a 1-GHz Pentium III, a boring VIA chipset, etc.
>
> To reproduce, I do some PS/2 mouse movement while
> doing one of:
>
> a. Lots of concurrent write() and sync() activity to ext3.
> b. Lots of NFSv3 traffic.

ie: lots of interrupt traffic causes the PS2 driver to go whacky?