Subject: Re: floating point test
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 05/11/2001 00:42:10
On Thu, May 10, 2001 at 09:04:03PM -0000, email@example.com wrote:
> I got my DEBUG enabled kernel crashed with the attached test,
> first it breaks system to ddb and an attempt to continue
> ends up in ofw 'ok' prompt. Commenting out lines below helps.
> #ifdef DEBUG
> tst %g2
> tz 1 ! tpc NULL? Panic
> tst %i6
> tz 1 ! %fp NULL? Panic
> That check is there to make sure the cpu is not trying to return from a
> trap with either a NULL pc or stack pointer. The machine is unlikely to
> recover in that event, and this the trap lets you determine what the problem
That's what I started with. If I change DEBUG to DEBUG_NOTDEF
then the same test doesn't cause any of the problems, i.e even
%g2 is still 0 it doesn't lead to crash.
I concluded that %g2 at this point not necessarily will become tpc
and that trap to debugger won't return normally.
That's interesting. As far as I can tell, those values will eventually
be loaded into those registers. If not immediately, then they will be
stored in a location that will eventually be loaded into the stack pointer
or tpc register.
Anyway, I would be interested to know which register is zero and how it
got to be set to zero. It would be better to fix the root cause than
work around a potential bug.