STI, HLT in acpi_cpu_idle_c1
jhb at FreeBSD.org
Thu Jun 24 13:11:53 PDT 2004
On Thursday 24 June 2004 03:14 pm, Matthew Dillon wrote:
> :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
> simply wrong?).
> I would try adding a DELAY(10) before the hlt, just to see if it has
> an effect.
The ACPI C1 state is just a normal hlt. Only states >= C2 are real
ACPI-specific states. Gerritt, did these lockups start happening recently
and are these boxes running -current or are they running 5.2.1?
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current