Date: Wed, 26 Jun 2013 22:03:54 -0700 From: Justin Hibbits <jhibbits@freebsd.org> To: Adam Martin <adamartin@freebsd.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Strange panic on ppc64 Message-ID: <CAHSQbTAnzfq_AQ8yRdTbztCpnYjeKtWp3zayE7o1evzBasULbQ@mail.gmail.com> In-Reply-To: <CAHSQbTAV19xUasD7v_gw5wcLGoVvefyP5F%2BUbiGeX1=raiVrig@mail.gmail.com> References: <CAHSQbTAZTc9puGaH0rbhyY11s0%2BL0xGjSabK1kj65UMm1t7j3w@mail.gmail.com> <51AF6661.3060007@freebsd.org> <CAHSQbTBjza0u7nZf4z%2BxpTCcWj-TW-ZigV2-CZexuBOYQX5=3A@mail.gmail.com> <CAHSQbTCvFXDZPsOnmogc0FkZeMXwOP6h40F2kFUu2s6UmffyPw@mail.gmail.com> <51B345BE.5030905@freebsd.org> <CAHSQbTDnwne3KJWN7xjcUw4PhF-uiD4B-4y1Lf90Bfou-2Ppvw@mail.gmail.com> <51B4A389.4020607@freebsd.org> <CAHSQbTACtejaRKiG4qScSV_EdTC8y_k5Qghx_FYebWzstBP61g@mail.gmail.com> <51B5D28C.505@freebsd.org> <51B5D539.8050102@freebsd.org> <CAHSQbTCposTE1AwHS0Ov=FT4w8gNkgpE4x_7-cHhyzMDfZr5UA@mail.gmail.com> <CAHSQbTB6bXpqFM5n8FMmpbbfKik0szDvp9M6KfCWreXKHTaR1g@mail.gmail.com> <CAJTQnqYaeBt690G0Nxv8gO1PpmTan3rXbARgTb-s63EEo_LiQQ@mail.gmail.com> <CAHSQbTAV19xUasD7v_gw5wcLGoVvefyP5F%2BUbiGeX1=raiVrig@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
>
> On Jun 12, 2013 11:31 PM, "Justin Hibbits" <jhibbits@freebsd.org> wrote:
>>
>>> On Mon, Jun 10, 2013 at 9:20 PM, Justin Hibbits <jhibbits@freebsd.org
>>> >wrote:
>>>
>>> > On Mon, Jun 10, 2013 at 6:31 AM, Nathan Whitehorn <
>>> nwhitehorn@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
[-- Attachment #2 --]
0x0000000000a7ac00: at .kdb_trap+0x108
0x0000000000a7acb0: at .db_trap_glue+0x6c
0x0000000000a7ad30: at dbtrap+0x128
r0 0
r1 0
r2 0xc0d480 mac_policy_list
r3 0xbb1840
r4 0x741a58 .ofwcall+0xa8
r5 0
r6 0xc0d4f0 mac_labeled
r7 0xc00000000004770
r8 0x1
r9 0xc11280 __pcpu
r10 0x1c35ec0
r11 0
r12 0x24000022
r13 0xbdb710 thread0
r14 0
r15 0
r16 0
r17 0
r18 0
r19 0
r20 0xf0d000
r21 0x4
r22 0x1801b44
r23 0x1803698
r24 0xc00000000004770
r25 0xb63130 smp_no_rendezvous_barrier
r26 0xb83848 ofw_rendezvous_dispatch
r27 0x741a58 .ofwcall+0xa8
r28 0x741a58 .ofwcall+0xa8
r29 0x24000022
r30 0x900000000001032
r31 0xc0d478 mac_static_policy_list
srr0 0x102ca4 k_trap+0x28
srr1 0x900000000001032
lr 0x102c74 u_trap+10
ctr 0xff846d78
cr 0x2000d4b0
xer 0
dar 0xfffffffffffffd60
dsisr 0x42000000
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTAnzfq_AQ8yRdTbztCpnYjeKtWp3zayE7o1evzBasULbQ>