Atom N450 + C3 + HPET == bad timer behaviour
mav at FreeBSD.org
Fri Jun 21 09:34:02 UTC 2013
On 21.06.2013 04:02, Adrian Chadd wrote:
> On 20 June 2013 16:45, Adrian Chadd <adrian at freebsd.org> wrote:
>> 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?
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:
> "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.
More information about the freebsd-current