acpicpu: Add support for ACPI P-states and T-states on Arm.

Nix trailing whitespace. NFCI.

Disable read of the ACPI timer during idle, fixing performance degradation
observed with acpicpu. C1 (MWAIT) is the deepest sleep currently enabled so
there should be no functional change. Also, the computed nap time is run
through hztoms() which seems incorrect as the ACPI timer is running in the
MHz range.

- add or adjust /* FALLTHROUGH */ where appropriate
- add __unreachable() after functions that can return but won't in
this case, and thus can't be marked __dead easily

branches: 1.59.40;
Set the flag for checking for PCI bus master activity only for C3.

branches: 1.58.2; 1.58.6; 1.58.8;
Remove bogus assertion that came with revisions 1.55-1.56.

Improve a comment.

relax an assert slightly, from jmcneill.

Don't treat C2 states as C1 if the _CST package doesn't have an entry
for C1. ACPI mandates C1 so if it's not present in the _CST package use
the HLT method. Fixes all sorts of performance regressions on AMD CPUs.

Do not disable interrupts at machine-level in the MI idle-loop entry.

Get rid of RUN_ONCE(9). Should fix PR # kern/44043.

Like in rest of the acpi(4) stack, queue all resume hooks.

Add a comment.

branches: 1.50.2;
Remove redundant/wrong increment of a variable.

Move also the evcnt(9) event counters to one place. No functional change.

Use __arraycount(3).

Simplify by moving the debug printfs to one place. No functional change.

Start to derive the percpu(9) (or per-domain) state coordination
mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.

Rename couple of badly named functions for consistency. No functional change.

Adjust the previous and add a comment for it.

Fix previous. Not my day.

Yet another small fix to the C-state parsing. As can be seen from the _CST
object noted in the revision 1.40, there is only one C-state on the machine,
yet the BIOS define its type as C2. Thus, instead of relying on the BIOS
data, sequentially count the parsed C-states.

make this build again

After a closer examination, remove entirely the check that was considered in
the revision 1.38. As noted in the specification (ACPI 4.0, p. 314):

The platform must expose a _CST object for either all or none of its
processors. If the _CST object exists, OSPM uses the C state information
specified in the _CST object in lieu of P_LVL2 and P_LVL3 registers
defined in P_BLK and the P_LVLx_LAT values defined in the FADT.

The _CST is seemingly valid on the system under consideration:

Name (_CST, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO,
0x08, // Bit Width
0x00, // Bit Offset
0x000000000000F800, // Address
0x01, // Access Size
)
},

0x02,
0x0064,
0x00000000
}
})

The check was also unnecessary in the sense that ACPI doesn't use bus_space(9).

Always declare HALT as available. If ACPI_FADT_C1_SUPPORTED is not
set in the FADT, print a warning, as it is obviously a BIOS bug.

Only check if the register address in _CST is valid if the ACPI processor
object address is valid. Some systems define the Processor() as:

Scope (_PR)
{
Processor (C000, 0x00, 0x00000410, 0x06) {}
Processor (C001, 0x01, 0x00000000, 0x00) {}
Processor (C002, 0x02, 0x00000000, 0x00) {}
Processor (C003, 0x03, 0x00000000, 0x00) {}
}

This may be typical to AMD systems that do not seem to use _CST, but instead
operate with HLT (and C1E for the C3-state). The same check is already done
in acpicpu_cstate_fadt(). Note that it is unclear whether this violates the
specification, given:

"PBlockAddress provides the system I/O address for the processors
register block. Each processor can supply a different such address.
PBlockLength is the length of the processor register block, in bytes and
is either 0 (for no P_BLK) or 6. With one exception, all processors are
required to have the same PBlockLength. The exception is that the boot
processor can have a non-zero PBlockLength when all other processors
have a zero PBlockLength. It is valid for every processor to have a
PBlockLength of 0. (ACPI 4.0, p. 626)"

Improve error reporting.

branches: 1.36.2; 1.36.4;
Move the function that counts the CPUs from acpicpu(4) to the MD layer.

Revert the changes made in the commit:

"Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module."

Queueing the checks in the resume hooks was observed to improve the resume
time by several seconds (!) on a system with poorly implemented AML code.
The observed race condition is a wider issue related to modules; things like
sysmon_taskq(9) should be modified to allow cancelling of queued functions.

Add AMD C1E quirk. Tested by cegger@.

(a) This should be removed once C-states are supported.

(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.

Other entry points beyond x86_cpu_idle_halt() may use HLT as the
idle-mechanism. Send an IPI also for these in cpu_need_resched().

Use acpi_timer_read_fast() instead of acpi_timer_read_safe().

Fix fix of a bug: first initialize sc, check sc != NULL, then KASSERT(9).

build fix: first initialize sc then KASSERT

branches: 1.29.2;
Now that the deferred configuration actually works as expected and documented,
use config_defer(9) instead of config_finalize_register(9), and simplify the
code paths around the initialization.

Add comments and raise the minimum allowed T-state duty cycle to 10 %.

Do not accidentally write zeros to (PSTATE_CNT and CST_CNT) registers.

Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module.

Move the PIIX4-quirk to the MD file and disable T-states for PIIX4.

Merge T-state a.k.a. throttling support for acpicpu(4).

Remarks:

1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.

2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.

3. There is no rationale to export controls to user land.

4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.

5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.

branches: 1.23.2;
Print the state information only once. The per-CPU information was quite
pointless as identical parameters are expected across processors.

Pretty printing.

Fix xref in a comment.

Add a XXX-comment as a TODO. From jmcneill@:

/*
* XXX: The pci_find_device(9) function only deals with
* attached devices. Change this to use something like
* pci_device_foreach(), and implement it for IA-64.
*/

Use evcnt(9) for the counters.

Remove a redundant function.

Downgrade the currently supported maximum C-state to C1. There appears to be
timer-related interrupt issues also in C2. With C1 it is guaranteed that
acpicpu(4) will not cause any slowdowns due stalled local APIC timer.

Improve error and debug messages.

Merge P-state support for acpicpu(4).

Remarks:

1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.

2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.

3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.

Store the MADT-derived CPU ID to <x86/cpu.h>. This is required to properly
match the ACPI processor object ID with the ID available in the APIC table.

On second thought, rename the mutex so it can be (logically) shared. We will
not need such granularity that different states would require a different lock.

Add a per ACPI CPU mutex for C-states. Protect the _CST update with this:
when the idle-information is being updated (e.g. due acpiacad(4) events),
we can not enter the idle-loop. The lock must run at the same priority
(IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a.
AcpiOsCreateSemaphore(). Also check want_resched as the first thing and
clarify the suspend/resume path.

There is still one race condition identified: when the driver is loaded as a
module, we must gracefully kick all CPUs out from the ACPI idle-loop upon
detachment.

Move the GAS definition to the header so it can be shared. Make a basic
sanity check before casting to the GAS. Rename the _CSD structure; the
optional "cross logical processor dependency information" is almost
identical in C, P, and T states. Add some comments to the header.

Improve comments. Move the #ifdef around.

Remove the currently unnecessary mutex.

Make sure we use MWAIT with MONITOR.

Also clarify when we have interrupts disabled.

Add a new flag that determines whether we should check for bus master
activity (BM_STS) by reading from the PM1 register. According to the Intel
processor specification for ACPI, the FFH GAS encoding may provide a hint
that the check is not required. This may help some systems to enter C2/C3
even when e.g. usb(4) keeps the BM_STS bit always enabled.

Remove the recently added ACPICPU_FLAG_INIT and instead operate with the
existing ACPICPU_FLAG_C, as was intended. Set that flag only after the
idle-loop has been installed, so that the notify handler errors out if an
interrupt is received before the idle-loop is in place.

XXX: If this is not correct, revert or fix.
This makes my laptop boot instead of panic:

panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155
fatal breakpoint trap in supervisor mode
type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10

trace
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41

1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Fix build failure in i386/ALL. Again caused by a missing _COMPONENT
declaration required for ACPI_DEBUG. Noted by cegger@ -- thanks.

The first bug: do not error out if the latency values supplied in _CST are
larger than the upper limit constants. Only sanity check against these
defaults when operating with FADT. This is also noted in a fine print of the
specification (ACPI 4.0, p. 314): "[...] The worst-case latency to enter and
exit the C State (in microseconds). There are no latency restrictions."

Add missing CVS identifiers.

Merge a driver for ACPI CPUs with basic support for processor power states,
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).

Remarks:

1. Commented out in the GENERICs; more testing exposure is needed.

2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.

3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.

Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.

4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.

ok jmcneill@, joerg@, and discussed with various people.

Nix trailing whitespace. NFCI.

Disable read of the ACPI timer during idle, fixing performance degradation
observed with acpicpu. C1 (MWAIT) is the deepest sleep currently enabled so
there should be no functional change. Also, the computed nap time is run
through hztoms() which seems incorrect as the ACPI timer is running in the
MHz range.

- add or adjust /* FALLTHROUGH */ where appropriate
- add __unreachable() after functions that can return but won't in
this case, and thus can't be marked __dead easily

branches: 1.59.40;
Set the flag for checking for PCI bus master activity only for C3.

branches: 1.58.2; 1.58.6; 1.58.8;
Remove bogus assertion that came with revisions 1.55-1.56.

Improve a comment.

relax an assert slightly, from jmcneill.

Don't treat C2 states as C1 if the _CST package doesn't have an entry
for C1. ACPI mandates C1 so if it's not present in the _CST package use
the HLT method. Fixes all sorts of performance regressions on AMD CPUs.

Do not disable interrupts at machine-level in the MI idle-loop entry.

Get rid of RUN_ONCE(9). Should fix PR # kern/44043.

Like in rest of the acpi(4) stack, queue all resume hooks.

Add a comment.

branches: 1.50.2;
Remove redundant/wrong increment of a variable.

Move also the evcnt(9) event counters to one place. No functional change.

Use __arraycount(3).

Simplify by moving the debug printfs to one place. No functional change.

Start to derive the percpu(9) (or per-domain) state coordination
mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.

Rename couple of badly named functions for consistency. No functional change.

Adjust the previous and add a comment for it.

Fix previous. Not my day.

Yet another small fix to the C-state parsing. As can be seen from the _CST
object noted in the revision 1.40, there is only one C-state on the machine,
yet the BIOS define its type as C2. Thus, instead of relying on the BIOS
data, sequentially count the parsed C-states.

make this build again

After a closer examination, remove entirely the check that was considered in
the revision 1.38. As noted in the specification (ACPI 4.0, p. 314):

The platform must expose a _CST object for either all or none of its
processors. If the _CST object exists, OSPM uses the C state information
specified in the _CST object in lieu of P_LVL2 and P_LVL3 registers
defined in P_BLK and the P_LVLx_LAT values defined in the FADT.

The _CST is seemingly valid on the system under consideration:

Name (_CST, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO,
0x08, // Bit Width
0x00, // Bit Offset
0x000000000000F800, // Address
0x01, // Access Size
)
},

0x02,
0x0064,
0x00000000
}
})

The check was also unnecessary in the sense that ACPI doesn't use bus_space(9).

Always declare HALT as available. If ACPI_FADT_C1_SUPPORTED is not
set in the FADT, print a warning, as it is obviously a BIOS bug.

Only check if the register address in _CST is valid if the ACPI processor
object address is valid. Some systems define the Processor() as:

Scope (_PR)
{
Processor (C000, 0x00, 0x00000410, 0x06) {}
Processor (C001, 0x01, 0x00000000, 0x00) {}
Processor (C002, 0x02, 0x00000000, 0x00) {}
Processor (C003, 0x03, 0x00000000, 0x00) {}
}

This may be typical to AMD systems that do not seem to use _CST, but instead
operate with HLT (and C1E for the C3-state). The same check is already done
in acpicpu_cstate_fadt(). Note that it is unclear whether this violates the
specification, given:

"PBlockAddress provides the system I/O address for the processors
register block. Each processor can supply a different such address.
PBlockLength is the length of the processor register block, in bytes and
is either 0 (for no P_BLK) or 6. With one exception, all processors are
required to have the same PBlockLength. The exception is that the boot
processor can have a non-zero PBlockLength when all other processors
have a zero PBlockLength. It is valid for every processor to have a
PBlockLength of 0. (ACPI 4.0, p. 626)"

Improve error reporting.

branches: 1.36.2; 1.36.4;
Move the function that counts the CPUs from acpicpu(4) to the MD layer.

Revert the changes made in the commit:

"Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module."

Queueing the checks in the resume hooks was observed to improve the resume
time by several seconds (!) on a system with poorly implemented AML code.
The observed race condition is a wider issue related to modules; things like
sysmon_taskq(9) should be modified to allow cancelling of queued functions.

Add AMD C1E quirk. Tested by cegger@.

(a) This should be removed once C-states are supported.

(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.

Other entry points beyond x86_cpu_idle_halt() may use HLT as the
idle-mechanism. Send an IPI also for these in cpu_need_resched().

Use acpi_timer_read_fast() instead of acpi_timer_read_safe().

Fix fix of a bug: first initialize sc, check sc != NULL, then KASSERT(9).

build fix: first initialize sc then KASSERT

branches: 1.29.2;
Now that the deferred configuration actually works as expected and documented,
use config_defer(9) instead of config_finalize_register(9), and simplify the
code paths around the initialization.

Add comments and raise the minimum allowed T-state duty cycle to 10 %.

Do not accidentally write zeros to (PSTATE_CNT and CST_CNT) registers.

Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module.

Move the PIIX4-quirk to the MD file and disable T-states for PIIX4.

Merge T-state a.k.a. throttling support for acpicpu(4).

Remarks:

1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.

2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.

3. There is no rationale to export controls to user land.

4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.

5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.

branches: 1.23.2;
Print the state information only once. The per-CPU information was quite
pointless as identical parameters are expected across processors.

Pretty printing.

Fix xref in a comment.

Add a XXX-comment as a TODO. From jmcneill@:

/*
* XXX: The pci_find_device(9) function only deals with
* attached devices. Change this to use something like
* pci_device_foreach(), and implement it for IA-64.
*/

Use evcnt(9) for the counters.

Remove a redundant function.

Downgrade the currently supported maximum C-state to C1. There appears to be
timer-related interrupt issues also in C2. With C1 it is guaranteed that
acpicpu(4) will not cause any slowdowns due stalled local APIC timer.

Improve error and debug messages.

Merge P-state support for acpicpu(4).

Remarks:

1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.

2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.

3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.

Store the MADT-derived CPU ID to <x86/cpu.h>. This is required to properly
match the ACPI processor object ID with the ID available in the APIC table.

On second thought, rename the mutex so it can be (logically) shared. We will
not need such granularity that different states would require a different lock.

Add a per ACPI CPU mutex for C-states. Protect the _CST update with this:
when the idle-information is being updated (e.g. due acpiacad(4) events),
we can not enter the idle-loop. The lock must run at the same priority
(IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a.
AcpiOsCreateSemaphore(). Also check want_resched as the first thing and
clarify the suspend/resume path.

There is still one race condition identified: when the driver is loaded as a
module, we must gracefully kick all CPUs out from the ACPI idle-loop upon
detachment.

Move the GAS definition to the header so it can be shared. Make a basic
sanity check before casting to the GAS. Rename the _CSD structure; the
optional "cross logical processor dependency information" is almost
identical in C, P, and T states. Add some comments to the header.

Improve comments. Move the #ifdef around.

Remove the currently unnecessary mutex.

Make sure we use MWAIT with MONITOR.

Also clarify when we have interrupts disabled.

Add a new flag that determines whether we should check for bus master
activity (BM_STS) by reading from the PM1 register. According to the Intel
processor specification for ACPI, the FFH GAS encoding may provide a hint
that the check is not required. This may help some systems to enter C2/C3
even when e.g. usb(4) keeps the BM_STS bit always enabled.

Remove the recently added ACPICPU_FLAG_INIT and instead operate with the
existing ACPICPU_FLAG_C, as was intended. Set that flag only after the
idle-loop has been installed, so that the notify handler errors out if an
interrupt is received before the idle-loop is in place.

XXX: If this is not correct, revert or fix.
This makes my laptop boot instead of panic:

panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155
fatal breakpoint trap in supervisor mode
type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10

trace
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41

1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Fix build failure in i386/ALL. Again caused by a missing _COMPONENT
declaration required for ACPI_DEBUG. Noted by cegger@ -- thanks.

The first bug: do not error out if the latency values supplied in _CST are
larger than the upper limit constants. Only sanity check against these
defaults when operating with FADT. This is also noted in a fine print of the
specification (ACPI 4.0, p. 314): "[...] The worst-case latency to enter and
exit the C State (in microseconds). There are no latency restrictions."

Add missing CVS identifiers.

Merge a driver for ACPI CPUs with basic support for processor power states,
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).

Remarks:

1. Commented out in the GENERICs; more testing exposure is needed.

2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.

3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.

Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.

4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.

ok jmcneill@, joerg@, and discussed with various people.