svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]
mjguzik at gmail.com
Sat Feb 18 20:58:32 UTC 2017
On Sat, Feb 18, 2017 at 12:49:29PM -0800, Mark Millard wrote:
> On 2017-Feb-18, at 4:18 AM, Mark Millard <markmi at dsl-only.net> 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. :)
> [Of course: "either direction".]
> I'll note that the -r313864 buildworld was without
> MALLOC_PRODUCTION being defined. (Unusual for me but
> I'm testing if a jemalloc assert problem on arm64
> also happens on powerpc64.)
> By contrast the buildkernels were production style
> (as is normal for me unless I'm trying to track
> something down that I think might be exposed by
> the extra checks).
Well either the primitive itself is buggy or the somewhat (now) unusual
condition of not providing the failed value (but possibly a stale one)
is not handled correctly in locking code.
That said, I would start with putting barriers "on both sides" of
powerpc's fcmpset for debugging purposes and if the problem persists I
can add some debugs to locking priitmives.
Mateusz Guzik <mjguzik gmail.com>
More information about the freebsd-current