Atom N450 + C3 + HPET == bad timer behaviour

[Alexander Motin]

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 Motin