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

Albert Cahalan <[email protected]> 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?