Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Sep 2016 20:52:09 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        Nathan Whitehorn <nwhitehorn@freebsd.org>
Cc:        Krzysztof Parzyszek <kristof@swissmail.org>, freebsd-ppc@freebsd.org
Subject:   Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx
Message-ID:  <77F66C6E-CFA2-4C10-B296-9DBF62575480@dsl-only.net>
In-Reply-To: <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org>
References:  <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <E90BB066-47C9-4626-BE6C-5D15ECA0E4EE@gmail.com> <db0aa91b-aa79-689a-e901-437e18b49b81@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <b39a5ae1-7aa5-a71f-3aff-221fc9c2e4da@swissmail.org> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> <3EC34F05-EF27-404B-816E-9A104105D097@dsl-only.net> <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2016-Sep-12, at 8:33 PM, Nathan Whitehorn <nwhitehorn@freebsd.org> =
wrote:
> On 09/12/16 14:50, Mark Millard wrote:
>> On 2016-Sep-12, at 2:00 PM, Nathan Whitehorn <nwhitehorn at =
freebsd.org> wrote:
>>=20
>>> On 09/11/16 12:04, Krzysztof Parzyszek wrote:
. . .
>>>> Regarding your "hack": it works perfectly! So far, my system (10.3 =
at the moment) has booted every single time, no exceptions, traps, =
unexpected conditions. This is too good to remain as a "hack". I have no =
experience debugging the kernel and I don't know ABI the OFW follows, =
but I wouldn't mind digging a bit deeper into it, if someone shared some =
pointers.
>>> I've finally understood why this helps. Open Firmware runs in =
virtual mode on the Powermac G5. This runs inside the kernel page table, =
which preserves all address translations made by OF before the kernel =
starts; as a result, the kernel address space is a strict superset of =
OF's.
>>>=20
>>> Where this explodes is if OF uses an unmapped SLB entry. The SLB =
fault handler runs in real mode and refers to the PCPU pointer in SPRG0, =
which blows up the kernel. Having a value of SPRG0 that works for the =
kernel is less fatal than preserving OF's value in this case.
>> Actual theory of operation material! Great! I've no clue how I would =
have figured out the Apple Open Firmware side of the context so I'd =
still be stuck with just observation of the overall change in behavior.
>>=20
>> Presuming that you are correct: no longer "just a hack". That is =
great news.
>>=20
>> It does sound like the Open Firmware side gets some risk of picking =
up the wrong address map with the change. So avoiding Open Firmware in =
the kernel via the usefdt=3D1 sounds like it would still be appropriate.
>>=20
>>> I believe that OF's SPRG0 is maintained only for compatibility with =
some G4 Apple hardware, the eMac in particular, but will check and we =
can move on with this. I think it should be safe to wrap this in an =
#ifdef __powerpc64__.
>>> -Nathan
>> Again I've no clue how I would figure such a thing out. But, if some =
powerpc Macs are the only reason GENERIC preserves SPRG0 and preserving =
works for the other powerpcs so that detecting PowerMac vs. not is not =
really required to decide on the SPRG0 handling (at least for =
powerpc64), that too is great news.
>>=20
>>=20
>> Thanks for continuing to look into why the SPRG0 change might have a =
solid justification!
>=20
> Here's a patch that I think is commitable. I've tested it on a =
PowerMac 11,2 with no ill effect. I would appreciate testing on any =
other models of PowerMac G5 (or iMac G5) before committing. This only =
changes behavior on powerpc64 kernels running on Apple-branded systems, =
so no need for testing on non-Apple or non-G5 hardware.
> -Nathan
> <sprg0-preserve-ppc64.patch>

Unfortunately I'll not have access for a few weeks yet. Once I have =
access again it would be a PowerMac7,2 that I'd test. The only other =
G5's that I'd have access to are PowerMac11,2's (with varying amounts of =
RAM).

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77F66C6E-CFA2-4C10-B296-9DBF62575480>