From owner-freebsd-ppc@freebsd.org Fri Mar 3 09:38:17 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 89123CF5404 for ; Fri, 3 Mar 2017 09:38:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-202.reflexion.net [208.70.211.202]) (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 2928C1068 for ; Fri, 3 Mar 2017 09:38:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2760 invoked from network); 3 Mar 2017 09:38:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Mar 2017 09:38:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Fri, 03 Mar 2017 04:38:15 -0500 (EST) Received: (qmail 27602 invoked from network); 3 Mar 2017 09:38:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Mar 2017 09:38:14 -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 107A3EC881F; Fri, 3 Mar 2017 01:38:14 -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: <20170302151959.GA58624@troutmask.apl.washington.edu> Date: Fri, 3 Mar 2017 01:38:13 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current , Justin Hibbits , mjg@freebsd.org, FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8D803761-644A-4E72-928F-2E96525A1A11@dsl-only.net> References: <20170225002300.GC19697@dft-labs.eu> <12339EDD-5663-40E0-8553-821EF9B6CDEB@dsl-only.net> <477BA631-AB85-4E77-8BA3-CD2AFAD5E405@dsl-only.net> <9A63B36E-5F81-4ECD-A2A2-AB442AAC26A6@dsl-only.net> <20170225193103.GA4379@dft-labs.eu> <20170301061350.GA22378@dft-labs.eu> <20170302121021.GA32682@dft-labs.eu> <20170302151959.GA58624@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu, 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: Fri, 03 Mar 2017 09:38:17 -0000 On 2017-Mar-2, at 7:19 AM, Steve Kargl wrote: On Thu, Mar 02, 2017 at 01:10:21PM +0100, Mateusz Guzik wrote: > On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: >>=20 >>> Summary of the transition interval: >>>=20 >>> So for powerpc64 (and powerpc?) It is a good >>> idea to avoid anything that is after -r313254 >>> and before -r314474 in head. (Would this be >>> appropriate for a UPDATING notice given its >>> span?) >>>=20 >>> There may be other architectures that might have >>> a similar status(?): the last fixes involved were >>> not in Machine Dependent code. (Some architectures >>> are apparently insensitive to the errors, such as >>> amd64). >>>=20 >>=20 >> When following current you are expected to be on the newest revision, >> so I don't think mentioning interim broken releases makes much sense. >>=20 >=20 > Documenting the range may aid those bisecting src/ to find a bug.=20 > How is one to know that anything in the range that Mark points > out should be skipped on powerpc64? >=20 > --=20 > Steve I have tested with a TARGET_ARCH=3Dpowerpc -r314473 build and its kernel version has locking problems like TARGET_ARCH=3Dpowerpc64 does for that version. [Note: This was run on a PowerMac G5 so-called "Quad Core" so most of the memory was ignored.] Both TARGET_ARCH=3Dpowerpc64 and TARGET_ARCH=3Dpowerpc need -r314474 or later as of the new locking. I've not explicitly tested other architectures. As I remember armv6/v7 are classified as having some from of a weak memory model compared to the likes of amd64. If so armv6/v7 might be candidates for having problems. There might be other candidates. =3D=3D=3D Mark Millard markmi at dsl-only.net