Strange panic on ppc64

[Super Bisquit]

Wouldn't the error be correctable in ofwcall64.S ?
Just asking.


On Thu, Jun 27, 2013 at 1:03 AM, Justin Hibbits <jhibbits at freebsd.org>wrote:

> >
> > On Jun 12, 2013 11:31 PM, "Justin Hibbits" <jhibbits at freebsd.org> wrote:
> >>
> >>> On Mon, Jun 10, 2013 at 9:20 PM, Justin Hibbits <jhibbits at freebsd.org
> >>> >wrote:
> >>>
> >>> > On Mon, Jun 10, 2013 at 6:31 AM, Nathan Whitehorn <
> >>> nwhitehorn at freebsd.org>wrote:
> >>> >
> >>> >> On 06/10/13 08:20, Nathan Whitehorn wrote:
> >>> >> > This is now getting interesting. Reading the tea leaves, what has
> >>> >> > happened is that the kernel has called into Open Firmware. Open
> >>> Firmware
> >>> >> > has then crashed early on, before setting up its own trap
> handlers,
> >>> >> > which has then flung you back into FreeBSD's handlers with a
> totally
> >>> >> > bogus environment, causing a second panic, which then causes a
> >>> *third*
> >>> >> > panic when trying to acquire a lock. It would be interesting to
> know
> >>> >> > what the OF environment looked like and what commands it was
> trying
> >>> to
> >>> >> > execute (in r3), but that may be tricky to get...
> >>> >> > -Nathan
> >>> >> > _______________________________________________
> >>> >>
> >>> >> One other point: you can trace this pretty easily by just putting
> >>> >> something like:
> >>> >>
> >>> >> if (pmap_bootstrapped) printf("Open Firmware call %p\n", args);
> >>> >>
> >>> >> in the top of openfirmware(). If I understood the debugger output
> >>> >> correctly, something should be making a firmware call immediately
> >>> before
> >>> >> the crash.
> >>> >>
> >>> >> As a random guess about what is happening, it is possible OF is
> trying
> >>> >> to allocate memory for itself. We just ignore the possibility that
> it
> >>> >> might want to do that at present, but that is not necessarily a good
> >>> >> assumption.
> >>> >> -Nathan
> >>>
> >>
>
> Here's where I stand on the panic:  The panic was actually caused within a
> bad return from Open Firmware, or something like that.  I eliminated the
> runtime panic by removing the necessity of Open Firmware to retrieve CPU
> ivars and instead caching them.  Now, after discussing with Nathan a bit, I
> added a trace and register dump to the db_main() function, so that every
> entry into DDB, even at the very beginning which is one place I see this
> problem, it would dump the needed information.
>
> I ran this twice, and go the exact same register dump, which is attached.
>  Any further insights are welcome.
>
> Oh, the actual entry is on an illegal instruction 0 at address 0, or so it
> claims.
>
> - Justin
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>