On Fri, Aug 27, 2010 at 11:11 AM, john stultz <johnstul@xxxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
