backtrace information from the 2nd(?) most common boot crash place on PowerMac G5's: just after real memory = ... (... MB)

[Nathan Whitehorn]

How much RAM is in the machine? I've never ever heard of this happening 
before and have been using one of these daily for four years. Clearly, 
there's something special about your configuration. This error, in 
particular, means that the direct map has been evicted from the page 
table. I can't imagine any possible way for that to happen; it's 
basically the least likely fault that I can think of and almost 
certainly indicates memory corruption or a hardware fault. Do you see 
this with an unmodified 10.1-BETA2 kernel?
-Nathan

On 09/27/14 00:47, Mark Millard wrote:
> The following includes backtrace information from the 2nd most common boot crash place in the boot message sequence on PowerMac G5's: just after it reports
>
> real memory = ... (... MB).
>
> Classically it reports data storage interrupt here and it did again. But more is dumped in my current configuration than before.
>
> FreeBSD FBSDG5M1 10.1-BETA2 FreeBSD 10.1-BETA2 #16 r271944M: Fri Sep 26 23:01:54 PDT 2014     root at FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64  powerpc
>
> but with options DDB and DGB in GENERIC64, WITH_DEBUG_FILES=, WITHOUT_CLANG=, WIHT_DEBUG= in /etc/make.conf. Also: DDB hacked to dump various things automatically so it happens during early boot crashes/hangs.
>
> The information reported was...
>
> fatal kernel trap
>
> exception = 0x300 (data storage interrupt)
> virtual address = 0x75e0000
> dsisr = 0x42000000
> curthread = 0xdbc290
> pid = 0, comm =
>
> srr0: 0x885608 .moea64_zero_page+1ac (a dcbz r0,r10)
> lr: 0x8ba31c .pmap_zero_page+0x7c
> ctr: 0x88545c .moea64_zero_page
>
> 0x8ba318: .pmap_zero_page+0x78
> 0x84167c: .kmem_back+0x2d0
> 0x8417fc: .kmem_malloc+0x7c
> 0x840dc4: .vm_ksubmap_init+0x8c
> 0x882130: .cpu_startup+0x10c
> 0x4d9c10: .mi_startup+0x10c
> btext+0xbc (???)
>
> r0: 0x1
> r1: 0xc000000000008740
> r2: 0xd19468
> r3: 0xe4d3a8 mmu_kernel_obj
> r4: 0xc000000002bfc290
> r5: 0xc7dfa0 mmu_zero_page_desc
> r6: 0xc000000000063af8
> r7: 0x2
> r8: 0xe0c310 vm_phys_free_queues
> r9: 0x80 dbsize+0xc
> r10: 0x7f5e0000
> r11: 0x80 dbsize_0xc
> r12: 0x24042042
> r13: 0xdbc290 thread0
> r14-r19: all 0
> r20: 0x10c2000
> r21: 0x4
> r22: 0x163f000
> r23: 0xc0000000d03fd000
> r24: 0x3800
> r25: 0x262
> r26: 0x400000000000000
> r27: 0xe4d3a8 mmu_kernel_obj
> r28: 0xc000000002bfc290
> r29: 0xc000000002bfc290 (yes: again)
> r30: 0x75e0000
> r31: 0xc000000000008740
>
> cr: 0x44042044
> xer: 0
> (I did not write down srr1. Drat.)
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> _______________________________________________
> 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"
>