# observation: nullenter blob on the NON-INVARIANTS kernel (snapshot noinv-installed)
# kernel binary verified: `strings /boot/kernel/kernel | grep -c "enter is not set"` -> 0
# (KASSERT compiled out; kernel dated Jul  3 17:33)

$ sysctl hw.acpi.cpu0.cx_supported
hw.acpi.cpu0.cx_supported: C1/10
#  -> the _CST C2 SystemIO/addr0 state (trans_lat=10, index 0; label is i+1,
#     not the ACPI type) was ACCEPTED into the live idle table with
#     enter == NULL -- no KASSERT to stop it on this kernel.

$ sysctl hw.acpi.cpu0.cx_usage   (twice, 2s apart)
hw.acpi.cpu0.cx_usage: 0.00% last 1000000us
hw.acpi.cpu0.cx_usage: 0.00% last 1000000us
#  -> usage counters and cst_prev_sleep frozen at their initial values: the
#     idle loop had not completed a state-machine pass during the
#     observation window (guest reachable via ssh the whole time).  The
#     NULL `cx_next->enter(cx_next)` call (acpi_cpu_cstate.c:970) for this
#     shape is proven by code trace; the production-kernel PANIC for the
#     family is instead demonstrated unconditionally by the zerostate blob
#     (panic: C1 startup setup failed: 22 -- plain panic(), no INVARIANTS),
#     see run.noinv_zerostate_panic.log / run.attack_zerostate_panic.log.

$ dmesg | grep -a -c cpu_cst
6
# all six cpu_cst devices attached normally on the planted chain.