From nobody Sat Feb 5 03:18:06 2022 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 977C019AAD0F for ; Sat, 5 Feb 2022 03:18:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4JrHff4znRz3jRD for ; Sat, 5 Feb 2022 03:18:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644031091; bh=ucpW3iCBw+ADL+Vro2bPbPlWCeN+DdWNNDR8+dSCeQI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nYUOX00r/rVQt5JUETAO/5nnbc/rDcz+7r7QcEA2+UqM2Fc6MSBlYIBpXbDKVJpVc4nm1jqDslIIW851RUN+L573smfn2YHHz5qlvRLzOrS+haFz3Lz3qFFbjJtAsOMhT+qaqiavFLSG0csaI4KBqjTCBMaWTL4cpy8IAdXP1d/5/qNUN/kd4dpBYRTZRjHiVo2SOfdcjr9bVLfPbjaNszXADsmCO+6BBcToCEGPDcKQTW/gUaFhw2ByIVHIYAvpsgAhLU8OfGEwEzXOhRVl/yIvoRxWiw20WQXf5P/axf7tP9hNuo6n+9sTHX3y/ZseBOiWuWRp6LTizEIka5aV5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644031091; bh=OAKPsu/dHu5hH9fXB9wERMyHfA3o2mz1vI9fg+5GLzJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sZYz9q5b+I9Hy9nrKcbNDcMIsG0lgl9P8OM1uPrYNDuOCTSNd6gIkx97dbuyopRGe499BRhVXOC6L6sFBf55CTUpZrv0iGkCnXQBwaPRmUh+T2SRQYxAfj6u3snormn4PqTYQ1iLx7oBmD/JfkpJgFo9Pexw8n+dgRsNvZSpz4Hx7aXxTXO6Yf2YKi+cFJJ7CWd4sDH8piEK6AajPgvPYpW6kbf4eWT+73wqI71kaeuvhDxjaKSMbo68p6kAi+jW/RoF+93gXG6BhgswFYew3wrnztyvvuW5RSTDZomfKV1DZXSdsaGGsdC4SWVGVBr4k9B5GO+wtRLcijQ8jpNQUQ== X-YMail-OSG: 6Z090YgVM1kqEBCPAVZLpeNrTjSpt28vm5w3y4oZoMcNA2K5KA1O.FpoMxVkrS1 3phrLdPsSHjI9TaQvlj4RVeSQCLKB9Fmzv1CFy5x461KYkl0JSHGpnRcLRr1rxYti4EZLJTTRO.G POJ94_t5H0yGjNebXsFH.qbR0IG4tVzApgSvcXAHKlK6fr4vmqshlSrqqrMdZhIFkvBXi2SDnvSD HCyXBs0tjR7kdnls0kmldn5jUFWgU.QSKExSXaCXq1CUlEXMhnGr1KD4NMHYv8RQvPi8aZr5iAm5 4iczeEb6Ln_Vw6pukez7ZMUGuZfSWU1BrigMSBi2dyvPp9oUevwKbzCm_riIpvO1Xbr7SHA5Zyxl SsiGb9eEoaG2.5xr.yiSlHqylpQ0GkAuYjxVqauZhpx5mtHxQvQY0WMfpdNk1XRdKnAvPMm7ueJ1 lB5WMD_zBl1radfrNjSGKzA6xU4BlzjN8H4vg9hnWf86fCAZNEKVNWyOVz77a6gT5PchCh2jUgHc tVGM7qho9q.3FrVJ31Xzi89sHNB14sbzbd3LCg3FJb7.v_NEsVL0qVanA7req3O.mc3hepUb_6n4 bX8ZFgeV3.1Q06O_agWBHIDtMLuHEiOaPsPbawEs9u5c8LL0i6yfZJZkhp_RvvEpQLUJXOSASOMt qynSFlg7d.uk0UplApxzu.SPQiPuRdNixDYsGj7XPjBa98W_Qyf.yaYUshzQgZQsBeKe8uSmawOx MLMn41ZfGTjIWe98bLMi.sWFMTQr9_NRtNvDB0X6rmdw2XfULLXIqbZ.7eQqeL0RWhHhWxSJDkth NSKchI9VEgX0jz7TsfFytRLh.X5erCLfozPqgRUn81Tc5Mi0vDpxty6a9H8hB7jLF_.1UDdms8we 9qdihB7yIxfblApj0JRAq5az8a89pU5S1ybbUXL7f5gneGaxbRtYpUvHANt8EWmAEhiyTD1Msgii go1mdAUyz8CxhTI_g2_JlDCBsvaUNSHVObr0x0CXK2FNLjOBmAH6HSreIIaItIufF_kz.GIeh3Zn hRg7wzLGq4WYHaaBbBHU5RDVpqF8tSLzRBqr6O1uUL50W8kWtFC4WDSrPBVRJtiWq5ZPaxZQk0Os N4U0KWfqu5q3ZMzR4jkHPclSvprhOnrvovXa.yRv0zPUxEkcD_PB0eYu6jemjqMN37XMuLX5xgnS JCRsYOiPS4_8kQ8LzmER_RTotOPn2rMnFmeEqsLd8Sf_xxtxkg_f8mpUp.vhkdQjc8ftPYXWB6dS z3RIZR8.JGXAdxyiJ.0KWOODlcT4p3PYF77wPZxkUTUt4.QNa1CKvEYHeNQvezyjXAmmgrRvGDhK UObi24BaydllDTmsEFLLJ5cowkm0_hnW9zpqYONR6YfxNgMGm_EkIA_4KNWWr6gxYm8Fi2TKaiP. gGRO_UpeM35TjCMY_gkladLPCgonpRnZo_zbhtk7jEaXS4OXHOv_rZsEPWPDQ_QnA4KSTeWs5AEB uWyzS492j5I708KibV2r.HX0UgI2q9MfWzyqddCuV_f88aQDgrkFveqSnXv9SdE34vqBkUdyaYGT hu67kAjDBQk_3LtLHI499WrlUYBk7xQSNAeRWO7vHaV2PbTC5yVS3hlLMVY4P7S8revB4NWJIdrv ouk9jBIZbrmyghLy2kbdVfbm3op7y7gX1JgJ0ao4AFGsYyGhsbYw4U4eRqoFvv4UCA7Xt_zX_bWE 5PYl.0d10KWcGH9me91i0qjaLy9GzeYGxRCv0q8CKchh8wip.YPaNi1LkzK4iG1ZWM54xJn5tLzm UwaNtjglH8jVnl0RZZq3vIhrc4YHbzY25yk.n40YifaHxCVren_1UhvDTpZEQDkrGJkKJHN2ZIPc tKOONpEVOkHdxzhJtWja55qdDBI07IQxnqhgeatqAaXBNGGkk787aE7vRY76airLepa_tU4ljG.P _oazkD6b2n0R7IcGYInHLaAvrUQC5amJZx3Z7WghzEqEDE_zWJKkVvURz5q0mXGrrT1UekohPi_T _JP7dVf_0qWaV2q4axRHr5NfOQ17.gswnbqtLV0G20KfnO1nMBYhrZ5UAIR9CUw9ddbW4XAybjSo aNg4RalzMgfSXbTRtvEYfYwWjUqOW7fGllzy1iftfAT3uU.vnFMrQmbWmtQbPP7acOjx9JBI060x EIda4o22CAARpabYtrQNAXh.opcAfITDx4bNLb_eaHUsVrJZ5ftF_QPAIAxPj_NjMdAoYBXPxz_Y cU2tHzHzDLeFOaZMxOOO3eTAnaWGUDJ5aAGKpkmq7zjtAnKewhqBAUOr.QU68uZolSFaqrJoxFIB l0VekIfwo5SVHr5xp X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 03:18:11 +0000 Received: by kubenode500.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e6d5c9b873b835a5aaefa42a733a44fb; Sat, 05 Feb 2022 03:18:08 +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.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: Date: Fri, 4 Feb 2022 19:18:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> References: <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrHff4znRz3jRD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nYUOX00r; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4475 Lines: 133 On 2022-Feb-4, at 18:54, Mark Millard wrote: > On 2022-Feb-4, at 18:06, bob prohaska wrote: >=20 >> On Fri, Feb 04, 2022 at 05:00:05PM -0800, Mark Millard wrote: >>> On 2022-Feb-4, at 16:08, bob prohaska wrote: >>>=20 >>>> On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >>>>> On 2022-Feb-4, at 13:44, bob prohaska wrote: >>>>>=20 >>>>=20 >>>> It sounds like I simply have a corrupted c++. Perhaps just >>>> set the old version aside and copy from the chroot directory >>>> to /usr/bin ? Granted, other things might be wrong as well.=20 >>>=20 >>> I'm not so sure. My expectation is that if you first >>> do (presuming not already in place at the time): >>>=20 >>> # sysctl kern.elf64.aslr.enable=3D0 >>>=20 >> On checking, that's already the case. I didn't change it >> knowingly, likely it's been zero all along. >=20 > So you get the failures even when: >=20 > # sysctl kern.elf64.aslr.enable > kern.elf64.aslr.enable: 0 >=20 > ? >=20 > That is different than in my context. I've never > gotten the failure for the above type of context. >=20 > It may be that for stable/13 's kernel the > default is 0 . I looked at the source and it does default to 0 for stable/13 's source vintage that I have. It is too late now for an immediate test, but at some point after a reboot that has the value 0 in kern.elf64.aslr.enable still, try looking at: # sysctl vm.aslr_restarts before and after the .sh/.cpp testing that shows failures. If the value becomes non-zero at any point then some ASLR activity was attempted despite the 0 in kern.elf64.aslr.enable . > I did test and one can actually set: >=20 > kern.elf64.aslr.enable >=20 > from inside a chroot context, at least > when one generally works as root. It > changed the system's overall > kern.elf64.aslr.enable status. >=20 >>> and then to your buildworld buildkernel it will just work >>> -- using your exising c++ compiler (system clang/clang++). >>>=20 >> Well, that hasn't happened yet. On the theme that if a >> problem won't get better find out what makes it worse, >> I've set it to 1 and am re-running buildworld with -j1. >=20 > Okay. That you get the failures even when > kern.elf64.aslr.enable is 0 means that my > existing context for investigation is > still problematical. >=20 >>>=20 >>> It seems very odd that such a setting would "uncorrupt" >>> your clang/clang++ build (used under the name c++). I'm >>> not aware of the compiler doing anything like the ntpd >>> did, for which having ASLR enabled as a problem. >>>=20 >>> For far as I can tell, the setting changes the detailed >>> behavior of mmap calls (including implicit ones in >>> library code and such). >>>=20 >>> I've not found a way to look at the context just before >>> the failure (without disturbing things enough via debugger >>> activity that the failure does not happen). It is likely >>> that I'll not manage to get such evidence that includes >>> the failure. >>>=20 >>> I worry that the failures seen with your c++ involves a >>> kernel bug but I do not see a way to investigate that. >>=20 >> I share your feeling that something isn't right but am >> utterly ill equipped to posit what that might be. The=20 >> most obvious recent strangeness with outbound network >> traffic not working unless accompanied by an outbound >> ping is most peculiar.=20 >>=20 >>=20 >> Might this be a reason to try Peter Holm's stress2 suite? I >> haven't played with it in a long time, not sure it'll even >> compile now. "Success" in stress2 terms is a kernel panic. >=20 > main [so: 14] has: >=20 > # ls -Tld /usr/main-src/tools/test/stress2/ > drwxr-xr-x 8 root wheel 33 Apr 28 15:20:54 2021 = /usr/main-src/tools/test/stress2/ >=20 > But I'm not sure if it would be of any help or not. > It may not have tests for causing vm.aslr_restarts > to increment during operation and then seeing > what works vs. what does not. >=20 > stable/13 and before do not seem to have stress2/ . >=20 >>> Another option might be to use a copy of the >>> compiler from the chroot area to replace the >>> normal system's copies, possibly renaming the >>> old ones first (various names), including >>> deal with clang.debug as well. This presumes >>> that the 2 stable/13 builds are sufficiently >>> compatible for such a substitution to work. >>=20 >> That sounds worth a try if no better ideas emerge. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com