Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 19 Oct 2005, john stultz wrote:
> > >
> > > Now here's the results that I got between two calls of do_get_ktime_mono
> > >
> > > 358.069795728 secs then later 355.981483177.  Should this ever happen?
> >
> > Definitely not. monotonic time must go forwards.
>
> Steven: What clocksource are you using? Could you send me your dmesg?

I have both a PIT/TSC and apic. So, as Thomas told me, the ktimer code
should figure out what to use. So that's pretty much all I can say on
clocksource ;)

As for the dmesg, there isn't really one. I have my own logging code that
flagged this, as well as a check that would BUG on the system when this
happened.  So my messages may not mean much to you.  I'm currently
compiling Ingo's -rt12 (with a fix to his checking) to see if I can
trigger it there too.  My custom kernel doesn't touch the ktimer/timeofday
code so I'm assuming that I can. But until I can trigger this on a kernel
that I didn't taint, I'll stop bothering you :-)


>
>
> > > I haven't look to see if this happens in vanilla -rt10 but I haven't
> > > touched your ktimer code except for my logging and the patch with the
> > > unlock_ktimer_base (since I was based off of -rt9)
> >
> > The ktimer code itself calls the timeofday code, which provides the
> > monotonic clock. I have no idea what might go wrong.
> >
> > Is this reproducible ?
>
> Last night I just caught a bug I accidentally introduced with the fixed
> interval math (oh, if only optimizations didn't dirty code so!), where
> time inconsistencies were possible when clocksources were changed. I'm
> not sure if that's the issue being seen above, but I'll wrap things up
> and send out a B8 release today if I can.
>

Hmm, I believe that the ktimers use the apic (when available) and let the
jiffies still be calculated via PIT/TSC.

Thomas, is the above correct?

Would that have triggered your bug?

Thanks,

-- Steve