From owner-freebsd-ppc@freebsd.org Sat Feb 25 04:52:29 2017 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 D4710CEC423 for ; Sat, 25 Feb 2017 04:52:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-93.reflexion.net [208.70.210.93]) (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 95515128D for ; Sat, 25 Feb 2017 04:52:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16194 invoked from network); 25 Feb 2017 04:25:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Feb 2017 04:25:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Fri, 24 Feb 2017 23:25:48 -0500 (EST) Received: (qmail 29692 invoked from network); 25 Feb 2017 04:25:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Feb 2017 04:25:47 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B833AEC8534; Fri, 24 Feb 2017 20:25:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works] From: Mark Millard In-Reply-To: <20170225002300.GC19697@dft-labs.eu> Date: Fri, 24 Feb 2017 20:25:46 -0800 Cc: mjg@freebsd.org, Justin Hibbits , svn-src-head@freebsd.org, FreeBSD PowerPC ML , FreeBSD Current , Nathan Whitehorn Content-Transfer-Encoding: 7bit Message-Id: <12339EDD-5663-40E0-8553-821EF9B6CDEB@dsl-only.net> References: <2FD12B8F-2255-470A-98D4-2DCE9C7495F5@dsl-only.net> <20170220191044.GA8526@dft-labs.eu> <5D5235E1-6F84-4329-8ED5-35FCDB0A6A71@dsl-only.net> <20170225002300.GC19697@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.3259) 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: Sat, 25 Feb 2017 04:52:29 -0000 On 2017-Feb-24, at 4:23 PM, Mateusz Guzik wrote: > > On Tue, Feb 21, 2017 at 01:37:25AM -0800, Mark Millard wrote: >> [Back to the powerpc64 context.] >> >> On 2017-Feb-20, at 11:10 AM, Mateusz Guzik wrote: >> >>> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote: >>>> [Note: I experiment with clang based powerpc64 builds, >>>> reporting problems that I find. Justin is familiar >>>> with this, as is Nathan.] >>>> >>>> I tried to update the PowerMac G5 (a so-called "Quad Core") >>>> that I have access to from head -r312761 to -r313864 and >>>> ended up with random panics and hang ups in fairly short >>>> order after booting. >>>> >>>> Some approximate bisecting for the kernel lead to: >>>> (sometimes getting part way into a buildkernel attempt >>>> for a different version before a failure happens) >>>> >>>> -r313266: works (just before use of atomic_fcmpset) >>>> vs. >>>> -r313271: fails (last of the "use atomic_fcmpset" check-ins) >>>> >>>> (I did not try -r313268 through -r313270 as the use was >>>> gradually added.) >>>> >>>> So I'm currently running a -r313864 world with a -r313266 >>>> kernel. >>>> >>>> No kernel that I tried that was from before -r313266 had the >>>> problems. >>>> >>>> Any kernel that I tried that was from after -r313271 had the >>>> problems. >>>> >>>> Of course I did not try them all in other direction. :) >>>> >>> >>> I found that spin mutexes were not properly handling this, fixed in >>> r313996. >>> >>> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64 >>> fcmpset to simulate failures. Everything works, while it would easily >>> fail without the patch. >>> >>> That said, I hope this concludes the 'missing check for not-reread value >>> of failed fcmpset' saga. >>> >>> -- >>> Mateusz Guzik >> >> -r313999 is an improvement for powerpc64: it boots and I can >> log in on the old PowerMac G5 so-called "Quad Core". >> >> But, e.g., buildworld buildkernel eventually hangs and later >> the powerpc64 panics for "spin lock held too long". >> > > Allright, play time is over. > > Can you please: > 1. verify r313254 is stable for you > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and > https://people.freebsd.org/~mjg/.junk/ppc.diff on top of it and retry > the test? > > This is a workaround which effectively disables the powerpc-specific > primitive and makes it use a cmpset wrapper instead. I don't have the > hardware to test right now and my attempts to boot in qemu also failed. > > That said, does not look like there are general fcmpset bugs left and > the remaining issue seems powerpc-specific. > > If this works, I'll commit the workaround for the time being as in few > weeks I'd like to start merging the work back to stable/11. > > -- > Mateusz Guzik I've started a self-hosted powerpc64 -r313254 build based on running the -r313266 kernel. (The context sometimes do cross builds in is tied up with other things. -r313266 is what my prior bisection came up with as the last appearently-working kernel at the time.) So it will be a while before I have a -r313254 in place to try: the self-hosted build takes longer and so will not be installed for a while. To judge stability I'll probably have -e313254 build the patched update that you want me to test, initially doing a cleanworld. So that too will take a while. (The above wording presumes all goes well.) I'll let you know as I go along if I run into anything interesting. My builds are rebuilding both world and kernel since what turns into /usr/include/sys/* has changes in your patch. The builds are without MALLOC_PRODUCTION but are otherwise not debug builds. I've not seen anything indicating that anyone has been trying TARGET_ARCH=powerpc. I've been trying TARGET_ARCH=powerpc64 . While I do not have access to a true TARGET_ARCH=powerpc machine currently, such a build can be used on a PowerMac G5 so-called "Quad Core". So I could eventually build and try such on the one powerpc family machine that I currently have access to. clang 3.9.1 has a significant code generation problem for TARGET_ARCH=powerpc and so I'd have to use a gcc 4.2.1 based build for that sort of experiment. (There is no xtoolchain for 32-bit powerpc.) I use clang 3.9.1 or xtoolchain for TARGET_ARCH=powerpc64 and have been using clang 3.9.1 in recent times. My primary powerpc family use has been to experiment with building based on the modern libc++ and reporting issues discovered in the attempts. This explains the clang/xtoolchain context. clang 3.9.1 has major problems for C++ exception handling for both powerpc64 and powerpc but a lot of FreeBSD is independent of throwing C++ exceptions. By contrast xtoolchain-based works for C++ exception handling but lib32 fails to operate when built by a xtoolchain build. === Mark Millard markmi at dsl-only.net