From nobody Sat Jul 03 20:15:19 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E752F11E307D for ; Sat, 3 Jul 2021 20:15:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GHNVP3bvBz4fv7 for ; Sat, 3 Jul 2021 20:15:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625343323; bh=ME3YKLEHK6dN6TqjD7qzhYAQrw65oukIriB9iaJvC4o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WMSqzn5xLUA3TRWwWmh1NMvt7ZTs4fMWyCmzOadskWcbWjIAmKX7kFQGTzT2b6MZAIApx6KzBzxhUfsY0qu1CYkXE2BAv6OL+VO2s9VhExdtnl4PQ3raodVMsOUnFlqS6mgiexrWaH+KJvcnsTXKlmfPXgsTfOrf48uG0kj1/la72Yh5TVQcJHiqUBSdT3im1Xch0X6bcXDAasuAu9xV++iL/sQttbFqYG71KaovB8anc+2+boCYhEYdfiXC7J0elFaP4ZhTj7W4vK+2flgU7b6Ga+qL2ElOV3uS1wXltl6MFMZJpHANFiKmWNbzfWrZxPawsXVSGpfl3rFrzPTBlQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625343323; bh=tRvT8w5cKNvXv3LBwYq5tZuNAVKpXMsnXSJEGMAOEjs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BuwsO7sdlhkz0dIqyZiFQWw8XXhOpHNELfcd+UYpMnuKwZwjc6qqdiOqeaRDe29Dun+eXLVDxt0W8uM63sm3b17Tq8s+2FNl4e90zeoRsBnpRlcOKUf+YVrDxNshceb23EmG9U1XoQaxh7E1vbOAU1QByh+XpUNG3C/rm70SZET1FcQPxxPLEJcTS2F8PwYvGw9vrWgFNG1PcMIzZt1gbE+dssQ3vSUrW+0n2t/omgiOaSL04w4e17WXZZ5TbAS+GQpZU7StXNWXSbJZa7c5uX/ZQNR1YsRh08jIqHWOId3Y+PdR1skGS24MpaWkAz5Kno4RwrvoSwylK+ohZQ+/qA== X-YMail-OSG: 1gJzA90VM1mHTsKqjPjegW0oGT7Q7KRWn96eRJ_keA8uqt4NeNaC27dZ7vqT86_ 3hE4WVf6l1B6WxLBe_3Ra8fvU6FWpvh.gGMXAGDAMYN1rgo8udtjqgzSejXpku5jEY5EeiJeg7qd i9PmyQ5PvSonxQxDPSHdhAHlXqcNoUaw59Tunav7_iVB62jlXHL8NGbxFNoBQJ4sZ7aQds9aJcZ4 DdSm.bEBUnmESc0UCTBeknzv6lW0psbHLZeaH6SRMmDrboLFjFRnxOlNNAZHOF7owVjHk_pwS4a4 vk1BFmozBbfETFjjEVb5EazXlTUjgkW14gX6Lp2P35AX.bq.okZblXpTxiVaLT7_XykRrYDcgyWF YxxMwgvMRdUi2.m2jpw6f0vNzTJLEjPyLsNJq5Rlvf7D5xwdlC7KEDkTDH6oFe.WVrJoFgCwE0BV iQeCBfwD5EfKcwMipu60MkwTpGvzp1jfzB0prXjA3OTbFddcdVHeoB06Pig0yK1S8XyDZ2GvX7Kd OpZH0D_T4986KKnleoyNCWwNlxXETMV8xwTNuKOrTTw4AMNizAsJSIvvpuqoPQo0MVHCcFAXClM1 wa.2VAn1oPcdvjl_.C4G5PlQXB6IwykBxFIAoF434I8.lf1.1EodsXXA1Jy0syToZmX4iewqriqc Cwy5Pn44J.Vnz7mHgFaa1Kwkl0C8fSAznAToqZUN7QxINN5lrQiZKU4Uf3Q_O10L5HKa22E1sEdM tWgi4sSVDWDuPlTiLv7CbivNg8NrzsJBGXWfA03GFD2IVMnNN9p5sGGECC7aJJSiWTeQXB_s3FHf flC_urF0Q5amFt96kHk_tLct.CtFmp0GiCt0CQYQasVv0xp9jKsyH8cG2jWfZIjFybsTV.kioJD0 oBvFo9TyrjF1N5TweztOXBtQMpm86Upyca8.67En2QqwlqrJzoHWZaRfcO8ttHd3IqqDmTf4yu0E nK7lJSoeiIl7tlOYsbJDwCiAcWL.X_Y_h3UIZ_ESWx05HNwrXY6mp4tn6gwXFs4rV8_AOjI_liQ7 t6A8WGTpxzPmEb_wmhM3542TlngL1mR4iQ7N92OAqwjlhZ5Eor.nwAJWsrJuJ9b5vYI7an3cEtxM ccFQeAdwgAMKKdhxVhVvRWjqzsFpTfyqzYpGtCsFFybGmdJcA1M4q5gfxhItVqJ6.9mE8EmB8O.O n.524TH8rcGS92uVFASHN9QHAz6OOfSwuQbDpzn4h4tyyUfX81KrjuXiSzE0lzT3gWQYcuTb6wvZ ZskkwNcSlVrDqWS1o2R2AJV4N.HhEgZvmTYqkz87xxFCiMZ.3C7bjxA6ztC5URsLWOXSZ8HHn4p9 eZiCy__DhIbn5aalokK1w6JFnpfV22Nw7VF7KQyTQB8M0hbGUIiTT3S6tfc0qU0_BlzQVQEPCp1_ YVMZzeCkHnVdJltuU_TSV754QCLXHxCf3QQzf4eajGsjDHCZniC59NYkEXSo3ViAUYxL8gPo_Yu7 NFRo.FbUQNZSpNdR.xV0iPB3SMhAXAxCbKpGAHZBLK7IPGqxF9SPrIZvefZ5ld3dEUWJ.3tpz63O YV_REC2SrI8cPub9xnd7_TN7dFxRsqcrheRfmR1AOodf3jD62lIRwvF.EOP7y7IStEXbI7bywuKS DKs_.ghGc.wRE.j3J1pYjIO0re5FxwKF2oaD9PcCjhD3.AJkdbcKv_XGBB4UGxdcmm_nHLe1fqvP 7Q1TE6amEulArzkDrYo.ERbc6moSkWmRHdc_Pj2N5BR2c2HNw2BQiaX4Q3wQai2L05LUpX8IWZyt VDz0MMs6sHIzOE6ASjcSUV9wHoShHOYhQH4g3Cbvd6gmC5vgGwdSh0aJGcIgT9EYP0._tnIH.lw4 Y7bMuUDsaSVennZcxH7RrXULYFKAXHeX_h348jaxnbbQmLwFhrKZqXuCgi9kpHIkGawtz1.yBURQ 5Hw.GCz9.Cfj7nq_Ry4.aTbvV1Dpy_STEcrSRfl5lB1lLd9XVED1BUvEmGewvBhet00bb35TRPRn w6fBjNeKqGIPwEG3jcmFji5tcZ2lx6CK.Euo0Oa6zKQTWaOa_UlkGXbq645lJYA2RF..8ipw68qP ze1NsSgsHg0CF1gsfKxQAOg6CuIAOzqWCkmSMMOBJcIzqBLphACTQUYH.qYPPDUx962.7aDn7p8t dsXOJjFowJqxjanKNxkZfzKS.MsHGkpYOjQI4nxi.WiqEAYWzC54mATY6dBTPz.Gok.XG3uW2pjY dpe8SP0f8xjtaQbH6.Ffp4hQxwSNtN1eW1ZUITsIfZzSYaea7kWxoV.Y4Su1aq8tEs.cgmcV9aX2 Tcyzt1dlq6QHX0VEH9q6n_04GpOOYYxj._lOvx3SvUfkAfPPiQS1.5qQPEJ92XruFisfreM5STZ1 od2.8eQ9v2FP28kHZC9ESj.3P4bPBQqLCqmDNr3HZjgOvbAzSBcWtkcANxse4rAQGPuquw8PO9SK mwCp.QZ1qIRU7dx_XiCdr71CZ89E6kb2WccRQb7poWzcu6hVK0_Rd7WBS0AbrwrRtOvBhntiMgHi pBquBNCjRecEJsZNMoLgDhYhXJyXrgf7SZxylhnm1hnRK3xeNpSHLHuNdpLePgJoyJrbQ0kjNAvn YqXLtaLzAsqJFbWaRTrw87r2CrtR1zZYRXLCTalmPfrRj3bkW.0ovw94epDVoyHUsZoYH_6Q7U7A 81TPu9OHx1F82iXVgNAxgkkgxqk6Y3BW9AhrFQO6ZOk5jt4VA6UCKLxe42nkYhGJd9fodbVLBQQI - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 3 Jul 2021 20:15:23 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12efd7a89fdcac6060fd607cc695f452; Sat, 03 Jul 2021 20:15:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210703182546.GA17871@www.zefox.net> Date: Sat, 3 Jul 2021 13:15:19 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <380184FB-6BA1-4C2D-9C6B-E249C2CF1317@yahoo.com> References: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> <9CFE71E2-23C3-4072-A8AD-74EDB339A146@yahoo.com> <60EEFD09-97DE-4B4F-BAFD-61B96EF60E27@yahoo.com> <77A35ACF-275F-44C8-AEEE-4EFE5B5CBEA4@yahoo.com> <20210703182546.GA17871@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GHNVP3bvBz4fv7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-3, at 11:25, bob prohaska wrote: >>>> On 2021-Jul-2, at 19:23, Mark Millard wrote: >>>=20 >>>>> Side note: >>>>>=20 >>>>> It llooks like = http://www.zefox.org/~bob/swaplogs/poudrierellvm10.log >>>>> shows that you tried with: >>>>>=20 >>>>> Device 1K-blocks Used Avail Capacity >>>>> /dev/da0s2b 1048576 25784 1022792 2% >>>>> /dev/mmcsd0s2b 1048576 25124 1023452 2% >>>>> Total 2097152 50908 2046244 2% >>>>>=20 > [hope the quotes are right!] >=20 > That's correct. The sequence of experiments ran something like this: >=20 > The Pi3 was configured with a a pair of ~3 GB swap partitions, one on > microSD, the other on the 1 TB mechanical hard disk. Make was not = limited > in the number of jobs it could parallel. OOMA was restrained by = putting > vm.pageout_oom_seq=3D"4096" > vm.pfault_oom_attempts=3D"20" > in /boot/loader.conf The usual "excessive swap" warnings were = presented > during boot and ignored by me.=20 >=20 > Worlds and kernels built wtihout trouble, so I tried building = www/chromium > using poudriere. It stopped in /devel/llvm10 with the "expected = expression" > error and continued to stop there despite updating /usr/ports several = times.=20 > At no time were there any hints of swap problems. Resorting to a = GENERIC > self-hosted kernel made no difference. /usr/src was not tampered with.=20= So you still have not tried an artifacts or snapshot kernel+world? > Eventually I resorted to running make in devel/llvm10, to my surprise = it > ran to completion. Interesting. Was this -j4? -j1? -j2? Any other interesting characteristics for how it was run? It would be interesting to see if building in a chroot in that make style also worked (or a non-poudriere jail). > It also ran make package successfully. Again I tried to > build just devel/llvm10 using poudriere, again getting "expected = expression".=20 >=20 > At that point I resized the swap partitions to 1 GB each and tried = poudriere > on devel/llvm10. That got rid of the excessive swap warnings, but = didn't help. > Finally I placed=20 > MAKE_JOBS_NUMBER=3D2=20 > in /usr/local/etc/poudriere.d/make.conf and tried again. That still = failed, > still with "expected expression".=20 I'll note that the running build build shows Load Averages of under 3. So the MAKE_JOBS_NUMBER=3D2 seems to be working. > Since devel/llvm10 had created a package successfully, I tried = slipping a copy > into poudriere's package directory, hoping it would find and use the = package > to make further progress. Unfortunately, poudriere seems to remember = the failure > and won't use the proffered package.=20 After things build correctly, things tend to look something like (using an example): 2# ls -FTla /usr/local/poudriere/data/packages/main-CA53-default/ total 12 drwxr-xr-x 3 root wheel 512 Jul 3 07:19:32 2021 ./ drwxr-xr-x 4 root wheel 512 Jul 1 19:25:44 2021 ../ lrwxr-xr-x 1 root wheel 18 Jun 28 04:32:43 2021 .buildname@ -> = .latest/.buildname lrwxr-xr-x 1 root wheel 20 Jun 28 04:32:43 2021 .jailversion@ -> = .latest/.jailversion lrwxr-xr-x 1 root wheel 16 Jul 3 07:19:32 2021 .latest@ -> = .real_1625321972 drwxr-xr-x 4 root wheel 512 Jul 3 07:19:32 2021 .real_1625321972/ lrwxr-xr-x 1 root wheel 11 Jun 28 04:32:43 2021 All@ -> .latest/All lrwxr-xr-x 1 root wheel 14 Jun 28 04:32:43 2021 Latest@ -> = .latest/Latest lrwxr-xr-x 1 root wheel 17 Jun 28 04:32:43 2021 meta.conf@ -> = .latest/meta.conf lrwxr-xr-x 1 root wheel 16 Jun 28 04:32:43 2021 meta.txz@ -> = .latest/meta.txz lrwxr-xr-x 1 root wheel 23 Jun 28 04:32:43 2021 packagesite.txz@ -> = .latest/packagesite.txz But, if a bulk is in process or has finished after some package had a build failure, there is also a: .building/ in there. That is what the message: Using packages from previously failed build: ${PACKAGES}/.building is about when starting poudriere bulk again. This is how poudriere avoids rebuilding what successfully built --but without adjusting the prior successful bulk build (if any). So poudriere would have expected the file for devel/llvm10 's build to be in that .building/ directory instead of down under the .real_*/ directory. (I've not checked if there is other record keeping in .building/ about the materials as well.) Going in a different direction, one way to force a build to start over after a failure is to: rm -fr PATH/.building before starting a new bulk build. This might be appropriate if one suspects a problem of a kind that did not stop a build but produced something for a build that fails to operate correctly. > It's still running, on lang/spidermoneky78. =20 So lang/rust finished. That is interesting because it includes an llvm build internally. Also: had you updated to pick up the workaround for the rust build failures on aarch64? I doubt it because they were commited on 2021-July-02. See, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256864#c18 So that you did not get the process crash/core-dump during lang/rust 's build is interesting. > There were no reboots between experiments. >=20 > My first suspicion is that I've somehow screwed up the poudriere = setup, perhaps > by a fumbled execution of poudriere jail -u, which I mistakenly = thought was > needed after updating /usr/ports. Again, poudriere does not control memory initialization in the processes in the builders. > The fact that the stoppage reported looks like > a syntax error specific to devel/llmv10 which is unaffected by swap = pressure > makes it seem unrelated to kernel or swap constraints.=20 The files with the syntax errors are ones generated by llvm-tblgen during the build and it is the output of llvm-tblgen that is corrupt, showing evidence of having used memory not initialized like it should have been. > AIUI, the hardware of the Pi4 is considerably different from the Pi3 = in terms > of memory management, noted from an interview with Eben Upton on = YouTube. Why would Eben Upton be talking about FreeBSD's memory management? I suspect that the talk is not about what you think it is about, but some narrower aspects than the overall memory managment. > He=20 > didn't go into any detail. Whether that's relevant is unclear to me, = but it=20 > does suggest the Pi4, even with restricted memory, won't behave like a = Pi3. Various reserved memory areas and such will vary but FreeBSD uses the same general memory management code, not completely separate code. > Is there any sort of sanity test for the poudriere system? If I delete = and > re-create the existing jail can the existing package library be = preserved > and re-used? If not, that's OK, I'd just like to know beforehand. >=20 # poudriere jail -jNAME -d # poudriere jail -c -jNAME -m null -M /WORLDPATH -S /SRCPATH -v = 14.0-CURRENT should work fine. But really all that you are doing is (using an example from my environment) is deleting and rewriting a few very small files in a directory with the jail's name: # ls -FTla /usr/local/etc/poudriere.d/jails/main-CA53/ total 36 drwxr-xr-x 2 root wheel 512 Jul 2 21:03:23 2021 ./ drwxr-xr-x 3 root wheel 512 Jul 2 21:03:23 2021 ../ -rw-r--r-- 1 root wheel 14 Jul 2 21:03:23 2021 arch -rw-r--r-- 1 root wheel 5 Jul 2 21:03:23 2021 method -rw-r--r-- 1 root wheel 33 Jul 2 21:03:23 2021 mnt -rw-r--r-- 1 root wheel 2 Jul 2 21:03:23 2021 pkgbase -rw-r--r-- 1 root wheel 14 Jul 2 21:03:23 2021 srcpath -rw-r--r-- 1 root wheel 11 Jul 2 21:03:23 2021 timestamp -rw-r--r-- 1 root wheel 13 Jul 2 21:03:23 2021 version # cat /usr/local/etc/poudriere.d/jails/main-CA53/arch arm64.aarch64 # cat /usr/local/etc/poudriere.d/jails/main-CA53/method null # cat /usr/local/etc/poudriere.d/jails/main-CA53/mnt /usr/obj/DESTDIRs/main-CA53-poud # cat /usr/local/etc/poudriere.d/jails/main-CA53/pkgbase=20 0 # cat /usr/local/etc/poudriere.d/jails/main-CA53/srcpath=20 /usr/main-src # cat /usr/local/etc/poudriere.d/jails/main-CA53/timestamp=20 1625285003 # cat /usr/local/etc/poudriere.d/jails/main-CA53/version=20 14.0-CURRENT The deletion/replacement of timestamp may have rebuild consequences from appearing to have changed (or just being missing). Nothing about any of those is going to change how memory initialization is working in llvm-tblgen's operation for generating any *GenGlobalISel.inc files, other than if the timestamp forces some sort of rebuild from scratch of some build dependencies first. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)