svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]
markmi at dsl-only.net
Mon Dec 12 00:44:57 UTC 2016
On 2016-Dec-11, at 3:11 PM, Mark Linimon <linimon at lonesome.com> wrote:
> On Sun, Dec 11, 2016 at 02:59:36PM -0800, Mark Millard wrote:
>> I tend to have powerpc64 and powerpc patches because of my
>> experimenting with clang targeting them and that the standard
>> powerpc64 build does not boot PowerMac G5's reliably.
> Is that on 10, 11 or -current?
Note: My powerpc64 and powerpc experiments have been targeted
to exploring having/using a modern context on these processors.
I only use gcc 4.2.1 for the TARGET_ARCH=powerpc kernel. I've
used more modern gcc's and/or clang for the buildworld's and
the powerpc64 buildkernel .
I've seen the problem on all 3 and I've used the patch on all 3.
Note that the TARGET_ARCH=powerpc builds had no problem booting
the G5's, only TARGET_ARCH=powerpc64 did. So I only patched
powerpc64. (I've no evidence that the patch would be appropriate
on non-PowerMac powerpc64 contexts: these comments are limited
I no longer actively use 10. I was using 11 once I started
testing use of clang 3.8.0 for targeting powerpc64 and
powerpc --until I switched to testing clang 3.9.0 and so
switched to 12.
I'm told that the amount of ram changes how likely the PowerMac
G5 boot failures are for TARGET_ARCH=powerpc64. My experience with
8GByte, 12 GByte, and 16 GByte would suggest that this is true:
less often on 8GByte than on 16 GByte, for example. The same for
12 vs. 16 --and these two are both so-called "Quad Core" G5s. But
I've seen the problem in all 3 contexts for 10, 11, and 12 absent
my patch (or variations of it).
Nathan Whitehorn recently came up with the explanation of why my
patch helped. I'll not go into all the details unless you care.
The summary is that FreeBSD's kernel was handling something during
Openfirmware being in use but a special register involved did not
have the value that FreeBSD required: it had the old Openfirmware
value restored to it instead. The patch avoids that restore so
that the FreeBSD value is in place.
Nathan has made a stab at removing the live Openfirmware use that
is involved in the problem but as of yet I've not been able to
boot what he last had me try for this.
> On 10 I remember being able to boot reliably but would get random crashes
> every few days. That machine has been offline for months, however.
I had frequent times of trying a dozen times or more (power-on,
power-off, power-on, . . .) to boot various 10.x's on the 16
GByte G5 Quad Core that I mostly used. I figured out the patch
during 10's time frame as far as my use goes. I've only tried
without the patch a little for later 10.x's, 11, and 12.
Once booted odd crashes were comparatively rare so solid
judgements about that are problematical for my context as
far as observed crashes go: I had no evidence to attribute
the cause with and a low frequency.
The patched code is also used after booting and so should avoid
the specific issue later as well. That does not imply that there
could not be other problems: FreeBSD and OpenFirmware are likely
still not fully matched, just less likely to crash.
I've no such odd after-boot-complete crashes under 11 that I
remember --nor with the patch under 10.x . 12 has suddenly
shutdown without even a console message once. I build it to
go to the ddb> prompt --which it also did not do.
I will note that at least one other person has made variations
of my patch because they had similar problems booting. (I
encouraged some testing of disabling more than I'd disabled.)
Other folks have reported having the boot problems but as far
as I know have not tried some variant of my patch.
(I made the smallest change that I could that changed the
behavior: I removed just one instruction for the specific
markmi at dsl-only.net
More information about the freebsd-ports