STI, HLT in acpi_cpu_idle_c1

[Matthew Dillon]

: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.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>