Date: Thu, 17 Jun 2004 13:46:35 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Bowman <don@sandvine.com> Cc: "'current@freebsd.org'" <current@freebsd.org> Subject: RE: STI, HLT in acpi_cpu_idle_c1 Message-ID: <200406172046.i5HKkZMJ009568@apollo.backplane.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337051D9014@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:From: Matthew Dillon [mailto:dillon@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406172046.i5HKkZMJ009568>