PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx

Sun Sep 11 00:13:02 UTC 2016

On 2016-Sep-10, at 1:41 PM, Krzysztof Parzyszek <kristof at swissmail.org> wrote:
> 
> On 9/9/2016 3:21 PM, Mark Millard wrote:
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458 (from 2015-Dec-20)
>> 
>> It reports as the technique:
>> 
>>> The change is in ofw_sprg_prepare of sys/powerpc/ofw/ofw_machdep.c and could look something like (presented in a form to show new/PowerMacG5-Specific code and old general code):
>>> 
>>> #ifdef POWERMAC_G5_SPECIFIC_BUILD
>>> 	__asm __volatile("mfsprg0 %0\n\t"
>>> 			 "mtsprg1 %1\n\t"
>>> 			 "mtsprg2 %2\n\t"
>>> 			 "mtsprg3 %3\n\t"
>>> 			 : "=&r"(ofw_sprg0_save)
>>> 			 : "r"(ofmsr[2]),
>>> 			 "r"(ofmsr[3]),
>>> 			 "r"(ofmsr[4]));
>>> #else
>>> // The historical code:
>>> 	__asm __volatile("mfsprg0 %0\n\t"
>>> 			 "mtsprg0 %1\n\t"
>>> 			 "mtsprg1 %2\n\t"
>>> 			 "mtsprg2 %3\n\t"
>>> 			 "mtsprg3 %4\n\t"
>>> 			 : "=&r"(ofw_sprg0_save)
>>> 			 : "r"(ofmsr[1]),
>>> 			 "r"(ofmsr[2]),
>>> 			 "r"(ofmsr[3]),
>>> 			 "r"(ofmsr[4]));
>>> #endif
>>> 
>>> In other words: for PowerMac G5's omit the mtsprg0 from ofmsr[1]: leave the register as it already is instead of resetting it. The value in ofmsr[1] is inappropriate to the context. I deliberately kept the change minimal and left in all other code related to the register.
>> 
> 
> Hi Mark,
> 
> I reinstalled 10.3, and it boots *sometimes*.  I cannot try this change though, because it hangs well before the kernel finishes building.
> 
> The custom kernel I had before was quite stable, once it booted, but at the moment I cannot get any kernel to build.
> 
> -Krzysztof

An interesting question might be: Does the TARGET_ARCH=powerpc build still work well on the PowerMac G5? Historically it has (but can not use the extra memory if present). I usually do most of my TARGET_ARCH=powerpc use on a PowerMac G5. But I also use G4's. It has been some time since the iMac G3 example worked, however. (The only G3 context I ever had access to.) FreeBSD stable/10 stopped booting the G3 example long before before I ever had tried 11.0-CURRENT if I remember right.

I've only had 2 boot problem contexts for my normal powerpc64 and powerpc use:

A) TARGET_ARCH=powerpc64 on PowerMac G5's (until my hack made my booting reliable)
B) TARGET_ARCH=powerpc on the iMac G3 example

Once booted I've not had problems on G5's. The G3 has only booted with older 10.x versions and back then booted and operated reliably for my use. (I can not identify when for the G3 change-of-status at this point. As I remember I sent some notes to the list at the time I discovered the problem.)

But my context for powerpc64 and powerpc activity stopped in early 2016-Jun and likely will not restart until 2016-Oct sometime: I temporarily lost access to the powerpc64's and powerpc's.

Your report that you have some sort of failure after booting during the likes of buildkernel is new as far as I know. Sending the list (and/or a bugzilla report) about the failure mode and related information may be appropriate and help in the future. (May be I missed an already existing report.)

Just so you know more about the context I've been using since it is odd. . .

I had been using powerpc64 stable/10 for a long time before switching primarily to 11.0-CURRENT's head. In essence I've never tried anything before 10.0. If I remember right I still have a stable/10 boot media that I'd update on occasion (until I temporarily lost powerpc64 and powerpc access). As I remember this booted and operated fine on the PowerMac G5's last I updated --but it might have been fairly old, even as of early 2016-Jun . (It has my kernel hack for the boot issue.)

But my stable/10 context was a xtoolchain style build via devel/powerpc64-gcc, using libc++, no gcc 4.2.1 present. I did this via what is in essence a "self hosted xtoolchain style build", using devel/powerpc64-gcc on the powerpc64. (There were some workarounds involved in getting this to work --even for getting devel/powerpc64-gcc installed.) My 11.0-??? powerpc64 activity also was this sort of build. I have the builds include building the system clang most of the time --but clang is not used for powerpc64 buildworld or buildkernel.

(My transition from gcc 4.2.1 to xtoolchain for powerpc64 was a very long time ago. I do not remember much about how I got it done. I was not as familiar with various things back then either. More luck was involved.)

[Note: I've never gotten lib32 to work via builds by devel/powerpc64-gcc.]

Back when projects/clang380 was active I switched to it from 11.0-CURRENT's head for my primary activity.

When projects/clang380 merged back into head I switched as well. I kept with 11.0-CURRENT's head until I temporarily lost powerpc64 and powerpc access. For powerpc64 and powerpc I will at some point switch to where clang 3.9.0 has some of its powerpc64 and powerpc problems fixed.

(In my non-powerpc FreeBSD contexts I'm currently tracking stable/11 via updating once and a while.)

The history is even messier but my more modern 11.0-??? TARGET_ARCH=powerpc builds (non-64) have for some time been a kernel built with gcc 4.2.1 and a world built with clang 3.8.0. There are kernel hacks to do this sufficiently for buildworld to operate on the result ("red-zone" for signals). I tended to cross build these and send the updates to the PowerMac in use and then locally update from that material. But not always.

[Note: clang++ 3.8.0 greatly messes up its code generation for exception handling for both powerpc64 and powerpc. This limits what range of things work well in each of those contexts when clang++ 3.8.0 was used to compile things.]

[I use svn for /usr/src and /usr/ports.]

So for a long time my activity has been primarily 11.0-??? based. I do not remember just what my 10.x context was back in early June when my access to the powerpc64s and powerpcs stopped temporarily. But it was stable/10 at some revision. For my 11.0-CURRENT variants: They were updated only a few days before losing access to the machines temporarily, so late 2016-May or early 2016-Jun sometime.

From what I've read in folks reports since early 2016-Jun it looks like I'll need to progress carefully on the powerpc64 and powerpc variants when I get access again, both for stable/10 and stable/11 --and eventually for head (12.0-CURRENT). I'll probably get more boot media so I can setup to revert trivially to known-good (kernel and world).

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