svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

[Rodney W. Grimes]

> On 2017-Mar-2, at 7:19 AM, Steve Kargl <sgk at troutmask.apl.washington.edu> 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:
> >> 
> >>> Summary of the transition interval:
> >>> 
> >>> 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?)
> >>> 
> >>> 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).
> >>> 
> >> 
> >> When following current you are expected to be on the newest revision,
> >> so I don't think mentioning interim broken releases makes much sense.
> >> 
> > 
> > Documenting the range may aid those bisecting src/ to find a bug. 
> > How is one to know that anything in the range that Mark points
> > out should be skipped on powerpc64?
> > 
> > -- 
> > Steve
> 
> I have tested with a TARGET_ARCH=powerpc -r314473 build and
> its kernel version has locking problems like
> TARGET_ARCH=powerpc64 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=powerpc64 and TARGET_ARCH=powerpc 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.

I also had locking issues on amd64 around this build time that
sent me down a week long rabbit hole chasing what I thought was
a bug in the new AMD/IOMMU code.  IMHO if we can at least
flag prior snapshot builds as "Broken for reason X" it might
save someone some time and time is a one way depleting resource
usually worth saving if possible.

If needed I can dig out the specifc build.  Oh, nvm, let me
just do that, it was r309302.  This revision I beleive is
a november snapshot.  It has kernel panics due to spinlock
timeout and sparatic deadlock that is undetected.


-- 
Rod Grimes                                                 rgrimes at freebsd.org