Re: STI, HLT in acpi_cpu_idle_c1

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