Re: Linux 2.6.29-rc6

From: Jesper Krogh
Date: Sun Mar 01 2009 - 08:52:07 EST


john stultz wrote:
On Thu, 2009-02-26 at 22:35 +0100, Jesper Krogh wrote:
john stultz wrote:
On Thu, Feb 26, 2009 at 12:43 PM, Jesper Krogh <jesper@xxxxxxxx> wrote:
Linus Torvalds wrote:
On Thu, 26 Feb 2009, Jesper Krogh wrote:
2.6.26.8 doesnt have this problem.

The "current_clocsource" is the same on both systems.

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
What does the frequency calibrate to? It should be in the dmesg. Does it
differ by a big amount?
Non-working:
$ 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.
I'm surprised the clocksource watchdog isn't catching it.

What's the output from:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies

Hmm. Does booting w/ "clocksourc=acpi_pm" also show the severe (~550ppm,
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.

And you said this only happens under load?

That wasn't true.. I got some real sunday testing done today. A fresh 2.6.28.7 has the same problem with a load of 0.00 0.00 0.00

2.6.27.19 doesn't have problems keeping time.

--
Jesper
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/