STI, HLT in acpi_cpu_idle_c1

Matthew Dillon dillon at
Thu Jun 17 20:47:00 GMT 2004

:From: Matthew Dillon [mailto:dillon at]
: ...
:OK, i understand.
:>     So, if the emulator is not coming out of the HLT it's a 
:> bug in the 
:>     emulator.  The STI; HLT sequence is correct.
:The emulator is doing the right thing. It breaks the 
:processors out, and shows all the registers etc.
:Its transparent, done via jtag (American Arium). In the 
:lockup case i have, 3 processors are executing HLT, and 
:EFLAGS bit 9 is clear. Thus I was wondering, it doesn't 
:seem obvious as to where in the pipeline the STI will take 
:affect. Is it at the end of the HLT instruction? Is this 'end'
:when an interrupt occurs? The manual just says "after
:the next instruction". Does that mean the instruction
:following needs to start? Does the halt instruction
:'end' when the processor goes to sleep, or when the
:processor wakes up? What should I expect to see in
:bit 9 of eflags when i'm executing HLT?
:I can't otherwise find how my system is behaving.
:The processors will service an NMI in this mode,

    It takes effect after HLT enters its wait state, which occurs 
    near the beginnnig of HLT's execution.

    i.e. the idea is that normal interrupts are supposed to be able to
    cause the HLT to finish and for normal execution to resume, so the
    STI obviously has to take effect just after HLT enters its wait state.

    time:		STI	HLT	  (HLT resumes)
    interrupt:   ----PPPPPPPPPPPPPPPPPPPP 

    time:		STI	HLT	              (HLT resumes)
    interrupt:   ----------------------.........------PPPPPP
				note overlap into the HLT instruction.  The
				STI/HLT sequence performs an interlock so no
				interrupt can occur prior to HLT entering its
				wait state.

    D = interrupts disabled
    E = interrupts enabled
    P = interrupt pending

:as i would expect, but will not service any normal
:interrupts (serial, lan, hardclock). The sole
:'awake' processor doesn't have any physical interrupts
:routed to it, and the ones that do have the physical
:interrupts have interrupts disabled.

    It is unlikely that the emulator is at fault, though I suppose it is
    a possibility.   It is more likely that there are simply no normal
    interrupts being made pending and so your HLT is never waking up.

    If inserting a NOP makes things magically work, then the emulator is
    broken and needs to be fixed.  You can't have a NOP in there for real
    because you blow up the interlock.


More information about the freebsd-current mailing list