On 21.06.2013 04:02, Adrian Chadd wrote: > On 20 June 2013 16:45, Adrian Chadd <adrian_at_freebsd.org> wrote: >> Hi, >> >> I'm having issues with HPET + C3 state on this Atom N450 based >> netbook. This is (shocking, I know!) running -HEAD (r251605.) >> >> If I use C2, HPET is fine. >> >> If I use RTC, i8254, LAPIC, C3 is also fine. LAPIC use probably disables C3 usage automatically there. RTC and i8254 use only periodic modes and so system will wakeup with at least HZ rate, so it is hard to say whether C3 will be used. >> But C3 + HPET results in multi-second pauses where it should be 1 second. What timecounter are you using? Have you tried to check what is going on in that moment: timecounter stoped, eventttimer interrupt losd or system is completely stuck somehow? >> I've disabled powerd and verified that dev.cpu.0.freq=1667; so it's >> not CPU frequency related. >> >> Doug found this: apparently SMI + timer fondling doesn't quite work out? >> >> http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00842.html SMI is a black box that can give us any kind of unexpected surprises. Theoretically there could be number of scenarios: HPET counter or comparator values corrupted by SMI code (not sure we can protect), SMI code can open race window on HPET comparator programming (that should be handled now), SMI code can have own bugs triggered by some specific HPET usage pattern (not our area). > .. and the resolution: > > http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00957.html > > "clockevents: Prevent oneshot mode when broadcast device is periodic > > When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only > can switch into oneshot mode, when the backup broadcast device > supports oneshot mode as well. Otherwise we would try to switch the > broadcast device into an unsupported mode unconditionally. This went > unnoticed so far as the current available broadcast devices support > oneshot mode. Seth unearthed this problem while debugging and working > around an hpet related BIOS wreckage. > > Add the necessary check to tick_is_oneshot_available()." > > does that help? That looks more like workaround for Linux-specific issue. Linux can use different timers hardware when CPU is active and when in deep sleep, and, as I understand from description, it tried to improperly use one of devices. Our code doesn't have that magic. Also I think this fix fixes not the original problem, but different one they've found during debugging. HPET always has ONESHOT capability, so this check is irrelevant when it is used as a broadcast device. -- Alexander MotinReceived on Fri Jun 21 2013 - 07:34:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC