Strange panic on ppc64

[Justin Hibbits]

>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zhabar.panic
Type: application/octet-stream
Size: 784 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20130626/5dd634b1/attachment.obj>