> On Thu, 2005-12-08 at 09:24 +1030, Jonathan Woithe wrote:
> > > Odd. I'm not sure why the acpi_pm wasn't chosen by default if it was
> > > available and the TSC fell back to the c3tsc. It might be something in
> > > the -RT tree that's changed that bit. Could you try the following and
> > > see if it doesn't resolve the timekeeping problems you're seeing?
> > >
> > > echo "acpi_pm" > /sys/devices/system/clocksource/clocksource0/current_clocksource
> >
> > Upon executing the above command the system time started behaving correctly
> > once more.
> Ok, something in the -rt patches is probably changing the selection
> order.
Is there any way to change the clock source in a normal 2.6.14 kernel? If
there was I could force the source to c3tsc in that and see if the problem
affects the c3tsc in vanilla kernels.
> > I'm also wondering whether this might be related to one other thing I
> > noticed a week or so back (also reported to the list, but thus far no
> > followups). If I enabled the (new) "High resolution timers" feature (as
> > distinct from HPET), things like /usr/bin/sleep run for far longer than
> > they should irrespective of machine load. For example, "sleep 1" from bash
> > actually delays 38 seconds, not 1 second as expected.
>
> Does disabling the "High resolution timers" feature change the behavior
> all?
I should clarify. Everything I've given you thus far has been with the
"high resolution timers" feature disabled. Two or so weeks ago I tried
enabling it and that's when "sleep 1" took 38 seconds to complete.
Disabling "high resoltion timers" at least made "sleep 1" behave somewhat
saner. I don't know if having the high res timers enabled affects the
accuracy of the system clock however. I'll test this tonight.
> > In other words, c3tsc wasn't there but tsc was. In terms of time accuracy
> > it seemed that with idle=poll the system time was kept accurately in this
> > case as well. I also noted in dmesg output the following:
> >
> > Time: tsc clocksource has been installed.
> >
> > Unlike the normal case (where idle=poll was not specified) there was no
> > mention of a "fallback" to a "C3-safe tsc".
>
> Thats very interesting that idle=poll worked around the issue. More
> digging will be necessary.
It possibly suggests that it's the c3tsc timer which is faulty as opposed to
the tsc timer (or maybe it's just a mode thing). Note that even with
idle=poll it was the tsc timer (instead of the acpi_pm timer) which was
selected, so "idle=poll" doesn't work around the timer selection issue. It
seems that there might be two separate problems: timer source selection and
c3tsc accuracy. Whether they are both present in vanilla 2.6.14 (or simply
masked due to selection of acpi_pm) is not clear.
Regards
jonathan
-
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]
