Messages in this thread | | | Date | Thu, 26 Feb 2009 23:04:03 +0100 | From | Jesper Krogh <> | Subject | Re: Linux 2.6.29-rc6 |
| |
Thomas Gleixner wrote: > On Thu, 26 Feb 2009, 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@krogh.cc> 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. > > 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.
My comparison is 2.6.26.8 not 2.6.28.8 .. so fairly old.
It is a small cluster, so I'm slipping some test-kernels in when the cluster is idle.
-- Jesper
| |