From owner-freebsd-ppc@freebsd.org Tue Sep 13 04:18:53 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FE2ABD750D for ; Tue, 13 Sep 2016 04:18:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49BB6EE4 for ; Tue, 13 Sep 2016 04:18:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9957 invoked from network); 13 Sep 2016 03:52:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 03:52:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Mon, 12 Sep 2016 23:52:03 -0400 (EDT) Received: (qmail 2906 invoked from network); 13 Sep 2016 03:52:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 03:52:03 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 86F57EC8AEF; Mon, 12 Sep 2016 20:52:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx From: Mark Millard In-Reply-To: <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org> Date: Mon, 12 Sep 2016 20:52:09 -0700 Cc: Krzysztof Parzyszek , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <77F66C6E-CFA2-4C10-B296-9DBF62575480@dsl-only.net> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <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> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 04:18:53 -0000 On 2016-Sep-12, at 8:33 PM, Nathan Whitehorn = wrote: > On 09/12/16 14:50, Mark Millard wrote: >> On 2016-Sep-12, at 2:00 PM, Nathan Whitehorn 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 > 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