STI, HLT in acpi_cpu_idle_c1
Matthew Dillon
dillon at apollo.backplane.com
Thu Jun 17 20:47:00 GMT 2004
:From: Matthew Dillon [mailto:dillon at apollo.backplane.com]
: ...
: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)
interrupts: DDDDDDDDDDDDDDDDDEEEEEEE
interrupt: ----PPPPPPPPPPPPPPPPPPPP
time: STI HLT (HLT resumes)
interrupts: DDDDDDDDDDDDDDDDDEEEEE.........EEEEEEEEEEEE
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.
-Matt
More information about the freebsd-current
mailing list