On Sat, Aug 28, 2010 at 5:45 AM, jean-philippe francois <jp.francois@xxxxxxxxxx> wrote: > 2010/8/28 john stultz <johnstul@xxxxxxxxxx>: > >>> > 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? >>> > > > Yes, the problem usually show up quite quickly, and I think I have let > my script run > for a long enough time to say it does not occur with clock=acpi_pm > >>> > 2) Does booting with "nohz=off" cause the issue to disappear? >>> > > Not tested yet. > >> >> 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 ? >> > That is interesting ! > I think I have always seen 5 minutes or multiples of this delay. I > will try to leave it running for a longer > period of time and come back to you with more results. If you look at > the first message of this thread > (on linux-acpi) the delay is first 5, then 10 minutes. > OK. So, the problem seems to be limited to HPET and 5 min multiples. > john stultz <johnstul@xxxxxxxxxx>: > 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? John: I don't think it is that we are going tickless beyond HPET wrap length. HPET max delta should be preventing that. We probably need to read out HPET hardware counter to see whether things are OK there. Even if we miss the interrupt, time update should notice that. One potential problem may be that HPET hardware can only do 32 bit mode, but advertising 64 bit mode and we are getting confused when we update time? jean-philippe: What does hpet section of "cat /proc/timer_list" look like? Also, can you boot with "hpet=verbose" option and send the dmesg. 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
