linux-kernel - Re: System time drifts when processor idle.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Aug 2010 18:09:01 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Venkatesh Pallipadi <venki@...gle.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, 2010-08-27 at 17:10 -0700, Venkatesh Pallipadi wrote:
> 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..

Huh. So you're thinking the timer tick scheduler is pushing way past the
HPET wrap length, and then we're missing an accumulation point and
things wrap under us? 

We have some code to try to limit the nohz length to avoid hardware
wrapping, but honestly I'd be surprised if the system is actually that
idle for that long (no timers firing for 5 minutes? that'd be really
impressive!).

jean-philippe: Is the drift always in 5 minute increments? Can you leave
it idle for 3 minutes and see a similar 3 minute delay, or is it always
in units of 5 ?

thanks
-john



--
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/