Successfully installed FreeBSD 10.1 on Apple PowerMac G5 -- BUT -- system freezes after a few minutes of running.

[Mark Millard]

Unfortunately when things fully-hang (e.g, both video and ssh stopped, not just video failing) frequently log files are not flushed to media. Before the crash buffered material might be accessible that would not end up flushed out(?). (Probably very dependent on settings that I do not know the defaults for.)


Some more PowerMac G5 notes follow. They are just based on my experience with G5 Quad-Core use (mostly) for FreeBSD 10.x-? (mostly).


Likely burning any older powrpc64 .iso from the download areas would have failed to boot. Memory stick booting likely would work for such. Plain powerpc .iso's would also work but limit themselves to 2G Byte of RAM even if more is present.


Be warned for powerpc64 contexts: At least for PowerMac G5's with lots of RAM (> 4GBytes?) there are intermittent early-boot-time-frame problems that make for early hang-ups. I've never used less RAM (other than just briefly on rare occasions) so I'm not sure if the "lots of RAM" is actually a requirement for these problems. Others have reported expecting that it is based on their experiences.

Many times I've had to retry booting over a dozen times in a row (I've been using lots of RAM), at least before...

I've been gradually trying to get evidence about the early-boot-time-frame issues. One discovery allowed detecting evidence of a problem and retrying. But it is a PowerMac G5 specific hack that is not appropriate to the normal FreeBSD code base. Especially true because it deliberately continues from evidence of a corruption. Also the hack is only based on observed call-return behavior, not on an analysis of Apple's openfirmware code. For me this is fine but for more serious use? I do not think so. With the hack in place I rarely have to retry booting for an intermittent problem and I've not ever had the problem at the most frequent place it had been happening before.

(The actual evidence is the wrong stack pointer (r1) value when openfirmware returns after it was called and/or an inappropriate status return value in r3 from that same return. I only observed both being wrong at the same time, in fact r1==r3 as well. I saw no evidence of the 64-bit call standard's nonvolatile registers having been corrupted, even considering full-width values despite the 64 vs. 32 bit environment distinctions when Apple's openfirmware is involved.)

With the relocatable powerpc64 kernel work that is going on in 11.0-CURRENT one of the originally hacked source files had to be changed for that context. The adjusted hack uses the 64-bit call standard's nonvolatile registers for storage more then my original hack did, depending on the non-volatile status where the original code did not. I do not really use 11.0-CURRENT for anything but to periodically make sure that I've got a form of the hack that is appropriate for my use in that context. (Someday it will be the RELEASE/RELENG/STABLE context.) Rarely someone has asked me for a PowerMac G5 experiment that involved some 11.0-CURRENT variant.

I should also note that in recent times my personal builds of world and kernel boot normally only for 10.1-RELEASE based builds (currently 10.1-RELEASE-p5 based). For 10.1-STABLE and 11.0-CURRENT I have to boot those builds in two steps, where the first step uses my 10.1-RELEASE-p5 build initially/part-way, then I unload and boot my kernel10.1S or my kernel11C explicitly. I've no clue why this is yet. I have made my own memory stick based on my 10.1-RELEASE-p5 so that I could boot reliably from it if I mess up boot-ability on the SSD.

My recent activities suggest that the 11.0-CURRENT's world is not fully compatible with 10.1 kernels as stands, trying to use at least one parameter value that does not exist for 10.1-? contexts: there were messages reporting such. I've not used the other direction recently. In my experiments I generally try to avoid such mixes (in either direction). Nothing says that 11.0-CURRENT and 10.x-? should generally mix usefully, although some folks may know more about the detailed mixing-status at any given time. 11.0-CURRENT is normally built with extensive debugging/validation software enabled. (My build is not that way but is as close to my 10.1 builds as I can get for such properties.)




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

On 2015-Feb-2, at 12:20 PM, Rick Thomas <rbthomas at pobox.com> wrote:

Thanks!

I hope to be able to get the log files by removing the disk and putting it in a different machine, or by booting the install disk as a “live” system and extracting the log files from the disk to a USB stick.  I’ll report when I have something.

As for tracking down the specific versions of things, I installed from unmodified
	FreeBSD-10.1-STABLE-powerpc-powerpc64-20150121-r277483-disc1.iso
It was a plain vanilla install — nothing special.
It’s worth noting that the machine stayed up happily all through the install process.
I did check the MD5sum so I’m pretty sure I got a good copy.
And a big “Thank You!” to Bill Sorenson for confirming that this is the latest/best…

I will follow up on your point about removing parts until I get a working config.  I’ll start by stripping out all RAM above 2GB and any unneeded PCI cards.

Enjoy!
Rick

On Feb 2, 2015, at 12:05 AM, Mark Millard <markmi at dsl-only.net> wrote:

> If every boot gives some time before things freeze up you might be able to extract and report the outputs of commands like:
> 
> $ freebsd-version -ku; uname -a
> 10.1-RELEASE-p5
> 10.1-RELEASE-p5
> FreeBSD FBSDG5M1 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r277808M: Fri Jan 30 00:58:33 PST 2015     root at FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc  powerpc
> 
> (There is more than one 'powerpc64 FreeBSD 10.1 "disk1" CD' that can be burned, such 10.1-RELEASE vs., say, a recent 10.1-STABLE. But it turns out that until very recently powerpc64 CD burns did not work for booting PowerMac G5s so more than normal is known about which versions could have be installed from a CD.)
> 
> Despite the mention of there being no console messages I list some basics below about dumping messages out anyway...
> 
> $ tail /var/log/messages
> Feb  1 21:37:40 FBSDG5M1 kernel: uhid1: <vendor 0x05ac product 0x9218, class 0/0, rev 1.00/1.0e, addr 7> on usbus1
> Feb  1 21:37:40 FBSDG5M1 kernel: hid_get_item: Number of items truncated to 255
> Feb  1 21:37:40 FBSDG5M1 last message repeated 2 times
> Feb  1 21:37:41 FBSDG5M1 ntpd[991]: ntpd 4.2.4p5-a (1)
> Feb  1 21:37:43 FBSDG5M1 dbus[924]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)
> Feb  1 21:37:43 FBSDG5M1 dbus[924]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)
> Feb  1 21:37:43 FBSDG5M1 dbus[924]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
> Feb  1 21:37:43 FBSDG5M1 dbus[924]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
> Feb  1 21:37:52 FBSDG5M1 ntpd[992]: time reset +1.748777 s
> Feb  1 21:38:01 FBSDG5M1 login: ROOT LOGIN (root) ON ttyv0
> 
> $ dmesg -a | tail
> Configuring vt: blanktime.
> Performing sanity check on sshd configuration.
> Starting sshd.
> Starting sendmail_submit.
> Starting sendmail_msp_queue.
> Starting cron.
> Starting background file system checks in 60 seconds.
> 
> Sun Feb  1 21:37:42 PST 2015
> Feb  1 21:38:01 FBSDG5M1 login: ROOT LOGIN (root) ON ttyv0
> 
> tail by itself may not give enough context. Full copies would be nice but I do not know about fitting the time before the hangup.
> 
> The intent is to have a more complete specification of which 10.1 variant and to see if problems are being logged before the complete hangup.
> 
> Others may well have better suggestions than mine for getting evidence.
> 
> 
> You should probably indicate if you are using just the console vs., say, X11. (Although it is probably just the console if it never stayed up long enough to establish more context.) Some folks may want to know the video card involved or other configuration information, even for simple console usage.
> 
> 
> 
> Historically for a base system configuration (video card & monitor, SSD appropriate to the SATA vintage, appropriate superdrive vintage/variant that FreeBSD would tolerate) if I've made it to the login prompt and I had not mixed and matched distinct kernel and world vintages for some reason then I've had no later troubles with panics, hangups, or the like for 10.0 or 10.1 vintages that I've installed.
> 
> But that was after I removed all the PCI-Express cards (G5 quad-core) but the video: My earlier attempts at using the pre-existing SATA cards and SSD's/disks from them was unreliable even for simple console usage. I took the direction of simplifying/removing stuff until what was left just worked, such as the built-in SATA. I've not gone back yet to figure out if I can make anything that I removed work well. (I'm still learning/investigating other things for FreeBSD and am in no rush about what I removed.)
> 
> I temporarily had my hands on a PowerMac G5 that would overheat if kept busy. But its fan would be going faster than normal after warming up while idle. The fans would go full speed well before the shutdown when it would overheat. So that sort of issue is not a match to what you report.
> 
> 
> ===
> 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"
>