RE: STI, HLT in acpi_cpu_idle_c1

From: Don Bowman <don_at_sandvine.com>
Date: Thu, 17 Jun 2004 16:20:12 -0400
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
instruction?

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?

--don
Received on Thu Jun 17 2004 - 18:20:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC