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

[Mark Millard]

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.


===
Mark Millard
markmi at dsl-only.net