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 root@g4.meroh.net:/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.
This is not a FreeBSD supported version anymore.