2010/9/13 jean-philippe francois <jp.francois@xxxxxxxxxx>: > 2010/9/9 john stultz <johnstul@xxxxxxxxxx>: >> On Fri, 2010-09-03 at 14:23 +0200, jean-philippe francois wrote: >>> 2010/8/27 john stultz <johnstul@xxxxxxxxxx>: >>> > On Fri, 2010-08-27 at 16:12 +0200, jean-philippe francois wrote: >>> >> My Timekeeping bug is still present, here is an updated script and log. >>> >> I am willing to make test, but I don't know what kind of debugging >>> >> info is needed. >>> >> >>> >> cat /sys/devices/system/clocksource/clocksource0/available_clocksource >>> >> hpet acpi_pm >>> >> cat /sys/devices/system/clocksource/clocksource0/current_clocksource >>> >> hpet >>> > >>> > Huh. hpet was not what I would have expected. >>> > >>> > >>> > So first, two experiments: >>> > >>> > 1) Does booting with "clock=acpi_pm" cause the issue to disappear? >>> > >>> >>> Hi, >>> >>> The same bug happens with clock=acpi_pm. >>> My apologies for a previous mail where I said it was not hapenning with acpi_pm. >>> >>> With both clock, the timekeeping gap augments by amount of 5 minutes. >> >> Huh. So this still seems strange, but assuming we're still using the >> hpet for irqs, its possible the event somehow gets pushed back 5 minutes >> and we miss an timekeeping interval accumulation (with acpi_pm, the >> counter wraps ever 5 seconds or so, so we could miss many accumulation >> intervals and still be 5 minutes off if the tick timer was late). >> >> Again, seeing if the issue goes away with nohz=off would be helpful. >> > > It goes away witj nohz=off > A little update on this time keeping bug : - the system time drifts by amount of 5 minutes - it happens with both hpet and acpi_pm as clock source - it goes away when booting with nohz=off - it goes away when booting with processor.max_cstate=1 Jean-Philippe François -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
