> I was looking at the code, and it seems wrong. It implicitly assumes
> that the processor time stamp counter and the jiffies counter start
> at the same time. Even assuming a hard reset, the processor could
> have spent a very long time booting (or even hours in some other operating
> system before running loadlin) before jiffies got started.
no, we record the current 64-bit time at bootup (take a look at
init_timer_cc), and we always take the time _relative_ to that initial
count. So no, this cannot be the reason, but yes the code is tricky. I
think the init_timer_cc code was already there right at the beginning in
1.3.20 or so, when Linus added the original 'fast pentium time' code.
if any you sees/suspects 'fast' timer code anomalies, please use the
'anomaly.c' code i posted more than a year ago, it records and validates
gettimeofday() timestamps, does a linear fit and filters out anomalies
over a certain treshold. The 2.1 time.c code is also supposed to be
interrupt-safe, we need this eg. for correct networking timestamps, see
get_fast_time() usage in net/core/dev.c. (2.0 does not use 'fast' time
within IRQ contexts)
> (It divides the rdtsc value by jiffies and uses that with the
> difference between the rdtsc value now and the value recorded by
> the last timer interrupt to compute the fraction of a jiffy
> we're currently at.)
No. The only known weeknesses: on overclocked systems one of the first
symptoms is a 'jerky' APIC-clock, which results in zero division errors in
time.c. Also some earlier Cyrix revisions have an unreliable 64-bit time.
> I have some ideas about fixing it, but is there anybody who "owns"
> that code and I should talk to before I start playing with it?
> (I also want to make it work with APM as much as possible.)
i'm sure the APM stuff would be welcome. Although the behavior seems to be
quite inconsistent between pentium clones wether the 64-bit time ticks
during APM powerdown or not. Some boxes even seem to corrupt the counter?
Not sure, maybe Alan knows more about these things, i think he added that
#ifdef CONFIG_APM.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu