A PowerMac G5 rarity: explicit fatal kernel trap (data storage interrupt) instead of Copyright notice and boot text

[Mark Millard]

Based on a couple of the after-Copyright-notice data storage interrupt reports from my 10.1-BETA1 GENERIC64 build used on a PowerMac G5 Quad-core (different addresses then back on 2014-Sep-2):

Using objdump -t on /boot/kernel/kernel it appears that...

srr0            = 0x883158 points into .moea64_zero_page
and
lr              = 0x8b7c8c points into .pmap_zero_page

both reports showed:

vert addr 7f5e0000
dsisr 42000000
srr1 9000000000001032
curthread db8b90
pid=0 comm=


Because "options DDB" and "options GDB" were enabled: instead of a back trace there was just a report of where it "stopped at" (0x883158) and the instruction (dcbz r0,r10) and then the PowerMac G5 was hung (no input allowed). dcbz and the "2" from dsisr match up from what I can tell.


===
Mark Millard
markmi at dsl-only.net

On Sep 2, 2014, at 1:14 AM, Mark Millard <markmi at dsl-only.net> wrote:

On G5 PowerMac's (with lots of RAM) I frequently have boots that after clearing (going black) never display anything from where the Copyright notice should display on --and the fans gradually spin up indicating that it failed somehow.

Rarely an error message shows up instead of the Copyright and later boot text. This happend today and I wrote the one generated down so that I could leave a note about it. I've no clue how to repeat it in any reasonable time frame.


The text on screen was (not a copy of the detailed spacing):

fatal kernel trap
exception       = 0x300 (data storage interrupt)
virtual address = 0x2fb1948
dsisr           = 0x40000000
srr0            = 0x88fa84
srr1            = 0x9000000000003030
lr              = 0x8903e8
curthread       = 0xd0ccc0
pid = 0, comm =

Panic: data storage interrupt trap
cpuid = 0
KDB: stack backtrace
#0: 0x533d30 at ??+0
#1: 0x86346c at ??+0
#2: 0x864630 at ??+0
#3: 0x8595e0 at ??+0
Uptime: 1s


If I interpret what I found about this correctly the dsisr value indicates that the data's address was not-found in primary or secondary "page table entry group"s (so a page fault occurred that was not expected to need to be handled): indicated by DSISR[1] = '1'...

> Set if MSR[DR] = ’1’ and the translation for an attempted access is not found in the primary page table entry group (PTEG), or in the secondary PTEG (page fault condition); otherwise cleared. 
Context: FreeBSD FBSDG5S0 10.0-STABLE FreeBSD 10.0-STABLE #0 r268571: Sun Jul 13 06:28:19 UTC 2014     root at grind.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERIC64  powerpc

===
Mark Millard
markmi at dsl-only.net