Created attachment 158193 [details]
Crash details as saved in /var/crash
I have a Mac Mini G4 running FreeBSD stable-10, originally installed on September 2014. During this period, the system has been updated along the stable-10 branch a few times (last as of June 21st).
Over all this time, and today, I have been unable to successfully build a (reduced) set of packages using poudriere. The machine panics and reboots at some point or another with:
panic: data storage interrupt trap
cpuid = 0
KDB: stack backtrace:
#0 0x45f3e0 at vpanic+0x138
#1 0x45f480 at panic+0x54
#2 0x77da3c at trap_fatal+0x1bc
#3 0x77ea04 at trap+0xfa0
#4 0x76ee9c at powerpc_interrupt+0x170
(I do not know now if the crashes happen at a deterministic point during the reduced bulk build.)
I am attaching the full core.txt file for details.
Any hints on how to gather additional data will be welcome.
Here is another data point, fresh off the grill.
I was advised at BSDCan that 10.1R had known problems with stability on powerpc. Indeed I had attempted to run an Xserve G4 earlier this year on 10.1R (in 32-bit mode) and it would simply power off shortly after I started poudriere. The results were the similar with the same bits moved to a newly-borrowed PowerMac G5, but with a panic/reboot instead of a powerdown.
As of yesterday I installed 10.2PRE of July 1 on the PowerMac and it has now been running for a few hours, having built 117 packages with poudriere. I have not yet powered up the Xserve.
I do not know if this is the exact same problem. Is it feasible for you to test with 10.2PRE?
As I said, this is with stable-10 updated several times along this period. The currently running kernel is:
FreeBSD g4.meroh.net 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #2 r284682: Sun Jun 21 11:20:05 EDT 2015 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC powerpc
... which is only a week old. I do not see any recent changes in sys/powerpc, so I doubt updating would make a difference.
That address looks very familiar: 0x7c0803ce is the encoding of an instruction. If I decoded it correctly, it's 'stvxl 0,8,0', so somehow it tried to use this instruction as an address. I would look at what function 0x511238 (srr0) is in, that might give a clue.