Date: Sun, 3 May 2020 07:38:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: nonameless@ukr.net Cc: svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-ID: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> In-Reply-To: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369.ref@yahoo.com> <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > --- Original message --- > From: "Mark Millard" <marklmi@yahoo.com> > Date: 3 May 2020, 04:47:14 >=20 >=20 >=20 >> [I'm only claiming the new jemalloc is involved and that >> reverting avoids the problem.] >>=20 >> I've been reporting to some lists problems with: >>=20 >> dhclient >> sendmail >> rpcbind >> mountd >> nfsd >>=20 >> 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=3D"360311">360311</span>. >>=20 >> Mika=C3=ABl Urankar sent a note suggesting that I try >> testing reverting head -r<span = data-ukrnet-code=3D"360233">360233</span> for my head -r<span = data-ukrnet-code=3D"360311">360311</span> >> context. He got it right . . . >>=20 >>=20 >> Context: >>=20 >> The problem was noticed by an inability to have >> other machines do a: >>=20 >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >>=20 >> sort of operation and to have succeed. By contrast, on >> the old PowerMac G4 I could initiate mounts against >> other machines just fine. >>=20 >> I do not see any such problems on any of (all based >> on head -r360311): >>=20 >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) >> armv7 (OrangePi+ 2ed) >> aarch64 (Rock64, RPi4, RPi3, >> OverDrive <span data-ukrnet-code=3D"1000">1000</span>, >> Macchiatobin Double Shot) >> amd64 (ThreadRipper 1950X) >>=20 >> So I expect something 32-bit powerpc specific >> is somehow involved, even if jemalloc is only >> using whatever it is. >>=20 >> (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.) >>=20 >>=20 >> Recent experiments based on the suggestion: >>=20 >> Doing the buildworld, buildkernel and installing just >> the new kernel and rebooting made no difference. >>=20 >> 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): >>=20 >> # find / -name "*.core" -print >> /var/spool/clientmqueue/sendmail.core >> /rpcbind.core >> /mountd.core >> /nfsd.core >>=20 >> 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. >>=20 >>=20 >> Other notes: >>=20 >> 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. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early <span data-ukrnet-code=3D"2018">2018</span>-Mar) >>=20 >=20 > Hi Mark, >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?922FBA7C-039D-4852-AC8F-E85A221C2559>