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?
-
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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:38 EST