On Thu, 20 Oct 2005, Ingo Molnar wrote:
>
> if the bug is only possible when timesources are changed on the fly,
> then i think it shouldnt happen. We pick our sources at bootup time and
> stick with them.
>
> in the -rt tree we also have clockevents and HRT support, so the clocks
> used should depend on whether you have the APIC enabled in the .config,
> and whether the BIOS has it enabled by default. If the BIOS has the APIC
> disabled then you can force the kernel to enable it by adding "lapic" to
> the boot-line.
On this test machine, I had to add the lapic command line, but that was
there when I first had to get NMI working on this machine back in the V0.7
days :-)
>
> without the APIC active, the equation is simple: we use the PIT for both
> jiffies and HRT. We use the TSC for gettimeofday. No interaction between
> the two.
>
> if the APIC is active, then we have both the local APIC timer interrupt
> for and the PIT for HRT timing. The clockevents framework sees both
> hardware clocks and automatically decides which one to use, based on
> their ranking. A typical PIT reprogramming PIO sequence takes 20-30
> usecs, while a typical APIC timer reprogramming takes ~5 nanoseconds on
> my box, so the choice is rather easy ;-) The jiffies interrupt is still
> off the PIT. gettimeofday is off the TSC counter.
>
> i could imagine the following hardware effects to cause time warps:
>
> - the TSC is in fact the 'read counter' method of the local APIC timer
> hardware. So there can be interactions in theory: programming the APIC
> timer could impact the TSC and vice versa. There have been CPU
> erratums in this area in the past.
Could this cause a 2 second drop backwards?
>
> - powersaving can impact the TSC - and can thus impact the APIC timer
> too. Errata-land as well.
Well, this machine is a normal PC not a laptop, and anyway, this backwards
clock happened during a stress test with pretty much 100% CPU usage, so I
think we can rule out power saving.
>
> - the TSC itself could have short, temporary warps. I had a box that
> showed such effects.
Can this be a 2 second warp?
>
> besides hardware bugs, another, albeit very small possibility is that
> somewhere in the thousands of lines of shiny-new generic-time-of-day,
> ktimers, clockevents and high-res-timers code, there is a software bug,
> which is causing time warps ;-)
>
My older code first used jiffies as a timer, then I switched to TSC and
then to APIC timer, and then finally ktimer. ktimer was the first to show
a backwards get_time.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]