Re[2]: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 from nonameless_at_ukr.net on 2020-05-03 (freebsd-current.mbox)

From: <nonameless_at_ukr.net>
Date: Sun, 03 May 2020 18:38:01 +0300

('binary' encoding is not supported, stored as-is) --- Original message --- From: "Mark Millard" <marklmi_at_yahoo.com> Date: 3 May 2020, 17:38:14 > > > On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > > > > > > --- Original message --- > > From: "Mark Millard" <marklmi_at_yahoo.com> > > Date: 3 May 2020, 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 -r360311">360311. > >> > >> Mikaël Urankar sent a note suggesting that I try > >> testing reverting head -r360233">360233 for my head -r360311">360311 > >> 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 1000">1000, > >> 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 2018">2018-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 A1222 (powerpcspe). > (The AmigaOne A1222 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 -r360233 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 2018-Mar) > Just don't want to see again previous situation when jemalloc was committed, then reverted and was forgotten for six months. Received on Sun May 03 2020 - 13:38:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC