2010/9/13 jean-philippe francois <[email protected]>:
> 2010/9/9 john stultz <[email protected]>:
>> On Fri, 2010-09-03 at 14:23 +0200, jean-philippe francois wrote:
>>> 2010/8/27 john stultz <[email protected]>:
>>> > 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