STI, HLT in acpi_cpu_idle_c1
don at sandvine.com
Thu Jun 17 20:20:51 GMT 2004
From: Matthew Dillon [mailto:dillon at apollo.backplane.com]
> :> In acpi_cpu_idle_c1, it does:
> :> sti
> :> hlt
> :> shouldn't there be a NOP in there so that interrupts
> :> are guaranteed on?
> :I think your reading of it is right..
> :but I also think that if it was ALWAYS right we'd see processors
> :go idle and never wake up again....
> :Since this doesn't seem to happen, maybe ther eis a bug in
> the emulator?
> :We can always add a nop I guess and see what happens..
> No no no no!
> The whole point is for interrupts to be disabled when the
> HLT instruction
> *begins* execution (they're only disabled for one cycle).
Ummm, doesn't STI *enable* interrupts?
so you're saying the point is that on entry to
acpi_cpu_idle_c1, that the caller has done a CLI?
And that the STI then enables interrupts during the HLT
But if this is the case, my jtag emulator shows
me that i'm executing 'HLT' and bit 9 of eflags
is 0, which is why i don't come out.
Is there a possible race condition on an HTT cpu
here? I run into this problem rarely, more frequently
now with a good test, and the box is locked up
solid. The emulator shows me that only 1 processor
is still alive, and the others are in the _c1 idle.
The processor that's alive has no interrupts routed
to it, and it has nothing to do, so it keeps spinning.
The system never wakes up, the other 3 stay in _c1,
and have interrupts off.
Suggestions on how i might be analyzing this wrong?
More information about the freebsd-current