_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