>Sure. I compiled a fresh 2.3.3+2.3.3_andrea1+your_extra_log_msg, and
>(while scrolling an X window) my time checker reports:
>
>Thu May 20 14:59:29 1999: fwd:877179/9:back max 0000003
>Thu May 20 14:59:30 1999: fwd:830353/11:back max 0007821
>Thu May 20 14:59:31 1999: fwd:855415/10:back max 0006035
>Thu May 20 14:59:32 1999: fwd:877045/10:back max 0000003
>Thu May 20 14:59:33 1999: fwd:877482/9:back max 0000003
Ah!! You are perfectly right, I had a bug in my recover_lost_ticks code!
But the bug is really really silly, just look the incremental bugfix:
Index: linux/arch/i386/kernel/time.c
===================================================================
RCS file: /var/cvs/linux/arch/i386/kernel/time.c,v
retrieving revision 1.1.2.24
diff -u -r1.1.2.24 time.c
--- linux/arch/i386/kernel/time.c 1999/05/20 12:15:33 1.1.2.24
+++ linux/arch/i386/kernel/time.c 1999/05/20 23:08:19
@@ -442,7 +442,7 @@
/*
* With APM enabled the TSC can break, so we don't trust it. -Andrea
*/
-#if defined(CONFIG_APM) && ! defined(CONFIG_SMP)
+#if ! defined(CONFIG_APM) || defined(CONFIG_SMP)
lost_ticks += delta;
jiffies += delta;
#endif
:-))
It's been when I had complains by people who didn't liked the idea to make
the kernel robust against lost-irqs. Their complains was that the TSC can
be resetted with APM enabled if I remeber well. So to fix the problem I
added in some second the broken #if sequence above, but I achieved the
opposite effect of what I wanted :-).
Basically so far my code was trusting the irq with APM enabled and was
only giving you a warning without APM compiled...
But with the fix applyed my recover-lost-ticks code will return to go in
read-_write_ mode and it should update your system time to the right value
according to the number of ticks lost.
I would be glad if you would try again my recover_lost_ticks with the
bugfix above applyed and confirm that my code make your machine robust
against frequent lost ticks.
I think there still an issue with settimeofday run in the middle of a lost
irq. But I'll address it leather since it's less priority.
Thanks!
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/