[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=8MXx9L0+V-JqXoO5PCWq5EPRW9fqpr913OTyC@mail.gmail.com>
Date: Fri, 27 Aug 2010 17:10:19 -0700
From: Venkatesh Pallipadi <venki@...gle.com>
To: john stultz <johnstul@...ibm.com>
Cc: jean-philippe francois <jp.francois@...ove.com>,
Lin Ming <lin@...g.vg>, "H. Peter Anvin" <hpa@...or.com>,
linux-acpi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
jslaby@...e.cz
Subject: Re: System time drifts when processor idle.
On Fri, Aug 27, 2010 at 11:11 AM, john stultz <johnstul@...ibm.com> wrote:
> 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?
>
> 2) Does booting with "nohz=off" cause the issue to disappear?
>
>
> Venkatesh: You have any experience with HPETs that halt in idle?
>
No. Haven't seen anything like this before with HPET.
The jump was
system | hardware(RTC)
15:48:43 | ven. 27 août 2010 15:48:44 CEST -0.985908 secondes
15:49:04 | ven. 27 août 2010 15:54:04 CEST -0.032800 secondes
We lost ~300 seconds and from dmesg
hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Which is close to 2^32 HPET ticks. So, looks like we have some 32 bit
wraparound somewhere..
Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists