svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

Sun May 3 15:38:10 UTC 2020

 --- Original message ---
 From: "Mark Millard" <marklmi at yahoo.com>
 Date: 3 May 2020, 17:38:14

> 
> 
> On <span data-ukrnet-code="2020">2020</span>-May-3, at 01:26, nonameless at ukr.net wrote:
> 
> 
> 
> 
> > --- Original message ---
> > From: "Mark Millard" <marklmi at yahoo.com>
> > Date: 3 May <span data-ukrnet-code="2020">2020</span>, 04:47:14
> > 
> > 
> > 
> >> [I'm only claiming the new jemalloc is involved and that
> >> reverting avoids the problem.]
> >> 
> >> I've been reporting to some lists problems with:
> >> 
> >> dhclient
> >> sendmail
> >> rpcbind
> >> mountd
> >> nfsd
> >> 
> >> getting SIGSEGV (signal 11) crashes and some core
> >> dumps on the old 2-socket (1 core per socket) 32-bit
> >> PowerMac G4 running head -r<span data-ukrnet-code="<span data-ukrnet-code="360311">360311</span>"><span data-ukrnet-code="360311">360311</span></span>.
> >> 
> >> Mikaël Urankar sent a note suggesting that I try
> >> testing reverting head -r<span data-ukrnet-code="<span data-ukrnet-code="360233">360233</span>"><span data-ukrnet-code="360233">360233</span></span> for my head -r<span data-ukrnet-code="<span data-ukrnet-code="360311">360311</span>"><span data-ukrnet-code="360311">360311</span></span>
> >> context. He got it right . . .
> >> 
> >> 
> >> Context:
> >> 
> >> The problem was noticed by an inability to have
> >> other machines do a:
> >> 
> >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt
> >> 
> >> sort of operation and to have succeed. By contrast, on
> >> the old PowerMac G4 I could initiate mounts against
> >> other machines just fine.
> >> 
> >> I do not see any such problems on any of (all based
> >> on head -r360311):
> >> 
> >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each)
> >> armv7 (OrangePi+ 2ed)
> >> aarch64 (Rock64, RPi4, RPi3,
> >> OverDrive <span data-ukrnet-code="<span data-ukrnet-code="1000">1000</span>"><span data-ukrnet-code="1000">1000</span></span>,
> >> Macchiatobin Double Shot)
> >> amd64 (ThreadRipper 1950X)
> >> 
> >> So I expect something 32-bit powerpc specific
> >> is somehow involved, even if jemalloc is only
> >> using whatever it is.
> >> 
> >> (A kyua run with a debug kernel did not find other
> >> unexpected signal 11 sources on the 32-bit PowerMac
> >> compared to past kyua runs, at least that I noticed.
> >> There were a few lock order reversals that I do not
> >> know if they are expected or known-safe or not.
> >> I've reported those reversals to the lists as well.)
> >> 
> >> 
> >> Recent experiments based on the suggestion:
> >> 
> >> Doing the buildworld, buildkernel and installing just
> >> the new kernel and rebooting made no difference.
> >> 
> >> But then installing the new world and rebooting did
> >> make things work again: I no longer get core files
> >> for the likes of (old cores from before the update):
> >> 
> >> # find / -name "*.core" -print
> >> /var/spool/clientmqueue/sendmail.core
> >> /rpcbind.core
> >> /mountd.core
> >> /nfsd.core
> >> 
> >> Nor do I see the various notices for sendmail
> >> signal 11's that did not leave behind a core file
> >> --or for dhclient (no core file left behind).
> >> And I can mount the old PowerMac's drive from
> >> other machines just fine.
> >> 
> >> 
> >> Other notes:
> >> 
> >> I do not actively use sendmail but it was left
> >> to do its default things, partially to test if
> >> such default things are working. Unfortunately,
> >> PowerMacs have a problematical status under
> >> FreeBSD and my context has my historical
> >> experiments with avoiding various problems.
> >> 
> >> ===
> >> Mark Millard
> >> marklmi at yahoo.com
> >> ( dsl-only.net went
> >> away in early <span data-ukrnet-code="<span data-ukrnet-code="2018">2018</span>"><span data-ukrnet-code="2018">2018</span></span>-Mar)
> >> 
> > 
> > Hi Mark,
> > 
> > It should be fixed, but not by reverting to old version. We can't stuck on old version because of ancient hardware. I think upstream is not interested in support such hardware. So, it have to patched locally.
> 
> Observing and reporting the reverting result is an initial
> part of problem isolation. I made no request for FreeBSD
> to give up on using the updated jemalloc. (Unfortunately,
> I'm not sure what a good next step of problem isolation
> might be for the dual-socket PowerMac G4 context.)
> 
> Other than reverting, no patch is known for the issue at
> this point. More problem isolation is needed first.
> 
> While I do not have access, https://wiki.freebsd.org/powerpc
> lists more modern 32-bit powerpc hardware as supported:
> MPC85XX evaluation boards and AmigaOne A<span data-ukrnet-code="1222">1222</span> (powerpcspe).
> (The AmigaOne A<span data-ukrnet-code="1222">1222</span> seems to be dual-ore/single-socket.)
> 
> So folks with access to one of those may want to see
> if they also see the problem(s) with head -r<span data-ukrnet-code="360233">360233</span> or
> later.
> 
> Another interesting context to test could be single-socket
> with just one core. (I might be able to do that on another
> old PowerMac, booting the same media after moving the
> media.)
> 
> If I understand right, the most common 32-bit powerpc
> tier 2 hardware platforms may still be old PowerMac's.
> They are considered supported and "mature", instead of
> just "stable". See https://wiki.freebsd.org/powerpc .
> However, the reality is that there are various problems
> for old PowerMacs (32-bit and 64-bit, at least when
> there is more than one socket present). The wiki page
> does not hint at such. (I'm not sure about
> single socket/multi-core PowerMacs: no access to
> such.)
> 
> It is certainly possible for some problem to happen
> that would lead to dropping the supported-status
> for some or all old 32-bit PowerMacs, even as tier 2.
> But that has not happened yet and I'd have no say in
> such a choice.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early <span data-ukrnet-code="2018">2018</span>-Mar)
> 

Just don't want to see again previous situation when jemalloc was committed,
then reverted and was forgotten for six months.