[lkml]   [2006]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fix time going backward with clock=pit [1/2]
    On Thu, 18 May 2006 01:11:16 -0700, Andrew Morton <> wrote:
    > Tim Mann <> wrote:
    > >
    > > Currently, if you boot with clock=pit on the kernel command line and
    > > run a program that loops calling gettimeofday, on many machines you'll
    > > observe that time frequently goes backward by about one jiffy. This
    > > patch fixes that symptom and also some other related bugs.
    > It might be a bit late to get this into 2.6.17. Although it does look
    > pretty safe and simple.
    > Are many people hitting this problem?

    No, since pit is a lower-priority clock source than tsc, pmtmr, or hpet,
    and most systems can use one of the latter. However, we currently
    recommend clock=pit to VMware users because clock=tsc and clock=pmtmr
    have bugs in their lost-tick compensation that makes them actually gain
    extra time, and those bugs get tickled often in a VM, making the time
    gain quite bad. (See
    So it would be nice for us if clock=pit didn't go backward, but most
    people wouldn't care.

    > And for 2.6.18 we're hoping to get John's x86 timer rework merged up.

    That would be great. I'm much more excited about seeing John's rework
    go in than this little patch of mine. I only sent out this patch
    because John said he wasn't sure how soon his rework would get in.

    > John, do those patches address this bug?

    I can answer that. Yes -- John's patch had a similar bug, but I sent
    him a similar fix for it and he has merged it in his version C2.
    (However, the issues that Roman and I are discussing apply there too, so
    more work may still be needed to make pit a good clocksource, and maybe
    it can be good only on UP systems...)

    > So if we decide these two patches are not-for-2.6.17 then I'll sit on them
    > until we decide whether or not to merge John's patches. If we do, and if
    > those patches fix this problem then your two patches aren't needed. If
    > John's patches don't get merged then I'll need to merge these two.
    > Hope that all makes sense ;)

    It makes perfect sense to me and sounds like the right thing to do. Thanks!

    Tim Mann work: home:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-19 03:57    [W:0.048 / U:8.844 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site