From mboxrd@z Thu Jan 1 00:00:00 1970 From: Venkatesh Pallipadi Subject: Re: System time drifts when processor idle. Date: Fri, 27 Aug 2010 17:10:19 -0700 Message-ID: References: <1282932708.1946.8.camel@work-vm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1282932708.1946.8.camel@work-vm> Sender: linux-kernel-owner@vger.kernel.org To: john stultz Cc: jean-philippe francois , Lin Ming , "H. Peter Anvin" , linux-acpi@vger.kernel.org, LKML , jslaby@suse.cz List-Id: linux-acpi@vger.kernel.org On Fri, Aug 27, 2010 at 11:11 AM, john stultz wro= te: > 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 l= og. >> 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_clocksour= ce >> 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=3Dacpi_pm" cause the issue to disappear? > > 2) Does booting with "nohz=3Doff" 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=FBt 2010 15:48:44 CEST -0.985908 secondes 15:49:04 | ven. 27 ao=FBt 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