On Thu, 26 Feb 2009, john stultz wrote:On Thu, 2009-02-26 at 22:35 +0100, Jesper Krogh wrote:john stultz wrote:Hmm. Does booting w/ "clocksourc=acpi_pm" also show the severe (~550ppm,On Thu, Feb 26, 2009 at 12:43 PM, Jesper Krogh <jesper@xxxxxxxx> wrote:$ cat /sys/devices/system/clocksource/clocksource0/available_clocksourceLinus Torvalds wrote:I'm surprised the clocksource watchdog isn't catching it.On Thu, 26 Feb 2009, Jesper Krogh wrote:Non-working:2.6.26.8 doesnt have this problem.What does the frequency calibrate to? It should be in the dmesg. Does it
The "current_clocsource" is the same on both systems.
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
differ by a big amount?
$ dmesg | grep -i freq
[ 0.004007] Calibrating delay loop (skipped), value calculated using
timer frequency.. 4620.05 BogoMIPS (lpj=9240104)
2.6.26.8 doesn't have that information.
What's the output from:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies
which NTP can't handle) drift?
>From the dmesg, I don't see any major calibration difference right off.
So I'd suspect something like TSC halting in idle could be causing
problems, but the watchdog should catch that as well. My only guess at
this point is that the ACPI PM is halting in idle along with the TSC.
But why would it do that on 29-rc6 and not on 2.6.28.8 ? I'm not aware
of changes which might cause that.