_CPU_Fatal_halt does not "halt" on Cyrix MediaGX MMX-S CPU(pc586 BSP)

Ralf Corsepius ralf_corsepius at rtems.org
Mon Oct 18 09:50:11 UTC 2004


On Mon, 2004-10-18 at 11:33, Valery Pykhtin wrote:
> > Now, IMO, it actually is a question of what you expect "halting the CPU"
> > to do. Some BSPs/users/applications will expect a "reset/reboot on fatal
> > error", some will expect "busy waiting until reset-button pressed",
> > others will expect program execution flow to "enter a monitor".
> >
> > So, in general, I'd expect a "_CPU_Fatal_error" to return to whatever
> > started the RTEMS executable (startup code, monitor, gdb-stub or
> > similar) and "busy-waiting etc." to be handled there.
> >
> > To put it differently: IMO, the currently implementation is questionable
> > and so is your proposal.
> >
> > Ralf
> >
> 
> >From the previous implementation I would expect that _CPU_Fatal_halt just 
> stops the processor.
> At least a board with i386 processor does so :).
> 
> My proposal does the same - there no busy waiting as you can imagine from 
> while(1) - this is just the way to force the processor to halt.
I disagree.

AFAIU, the "while(1)" you are adding is a busy-wait, not a "preprocessor
guard".

>  As I've 
> tested this - the cycle terminates quite soon. Here can be some processor's 
> specific, I don't know.
> 
> The worse thing is that I've missed _Internal_error_Occurred (which uses 
> _CPU_Fatal_halt) and spend a lot of time to find it out.
> 
> Valery 
> 





More information about the users mailing list