Date: Sun, 03 May 2020 11:26:09 +0300 From: nonameless@ukr.net To: Mark Millard <marklmi@yahoo.com> Cc: =?us-ascii?q?vangyzen=40freebsd=2Eorg?= <vangyzen@freebsd.org>, 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[2]: 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: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> In-Reply-To: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369.ref@yahoo.com> <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Original message --- From: "Mark Millard" <marklmi@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 -r<span data-ukrnet-code="360311">360311</span>. > > Mikaël Urankar sent a note suggesting that I try > testing reverting head -r<span data-ukrnet-code="360233">360233</span> for my head -r<span data-ukrnet-code="360311">360311</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="1000">1000</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="2018">2018</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. Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1588493689.54538000.et1xl2l8>