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? --donReceived 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