STI, HLT in acpi_cpu_idle_c1
dillon at apollo.backplane.com
Thu Jun 24 12:14:24 PDT 2004
:Nothing pending or currently executing. Its ok for this one to be halted
:(CPU3), but neither CPU2 nor CPU1 should be halted. CPU2 claims to be
:executing Xhardclock which does an EOI in < 20 instructions after it starts.
:Does the ISR for CPU 2 clear if you let it continue for a bit?
:John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve" = http://www.FreeBSD.org
I wonder if something in the ACPI code is blocking - allowing queued
interrupts to be processed and breaking the 'cli' atomicy. But that
would not explain why the ISR shows a delivered but un-EOI'd interrupt.
Another possibility is that there is some sort of required DELAY before
entering into HLT after calling the ACPI idle code. It is possible that
whatever the ACPI idle code is doing to the cpu (e.g. delayed effect
from power management adjustments) does not take effect quickly
enough and a real interrupt is interrupting the HLT before
the hw changes ACPI makes take effect. The changes then take effect
in the middle of the real interrupt. This would account for the
ISR state though I still don't understand how that cpu could return
to the HLT without EOI'ing (maybe the reported instruction address is
I would try adding a DELAY(10) before the hlt, just to see if it has
<dillon at backplane.com>
More information about the freebsd-current