From owner-svn-ports-head@freebsd.org Mon Dec 12 00:44:57 2016 Return-Path: Delivered-To: svn-ports-head@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 34278C6F56F for ; Mon, 12 Dec 2016 00:44:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-169.reflexion.net [208.70.211.169]) (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 E71681230 for ; Mon, 12 Dec 2016 00:44:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14949 invoked from network); 12 Dec 2016 00:45:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Dec 2016 00:45:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 11 Dec 2016 19:44:55 -0500 (EST) Received: (qmail 25552 invoked from network); 12 Dec 2016 00:44:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2016 00:44:55 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 75D20EC8FDE; Sun, 11 Dec 2016 16:44:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?] From: Mark Millard In-Reply-To: <20161211231120.GA30251@lonesome.com> Date: Sun, 11 Dec 2016 16:44:53 -0800 Cc: Gerald Pfeifer , svn-ports-head@freebsd.org, Dimitry Andric , vbox@FreeBSD.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <86C72DB2-B9ED-4512-A88C-BD1D9A23806F@dsl-only.net> <9D54F0CC-F38C-4CCE-BC33-25C1457BD44B@FreeBSD.org> <5C936BA8-6941-431A-B05F-31030816F85C@dsl-only.net> <487153E5-EF53-4960-9364-23992D7E0F76@dsl-only.net> <20161211231120.GA30251@lonesome.com> To: Mark Linimon X-Mailer: Apple Mail (2.3251) X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 00:44:57 -0000 On 2016-Dec-11, at 3:11 PM, Mark Linimon 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 in scope.) 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 special register.) > mcl === Mark Millard markmi at dsl-only.net