From nobody Mon Jul 22 00:12:41 2024 X-Original-To: current@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 4WS12P140Dz5Qrnk for ; Mon, 22 Jul 2024 00:13:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WS12M5gWWz4dHw for ; Mon, 22 Jul 2024 00:12:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=L60X2V3D; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721607177; bh=PEjHMjBWeARPajcpmbzG2+bB0iFskfiMlCrDt8Q1gII=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=L60X2V3D/l+r4FDmt3S/tmkK8eocOu7EeKepvb+F1Tt41Yuh0eCpCRQr8ZqdCTsVG29AncnA+lPi/104r6M8jlbJk+oht7MQS4iXnBYKYaA6RnG1TMDMGufQJVkUT4CIn0RLVuKmi/njoqQtAt7aidrB1WI09gwL6saZoTBCr0JqHP5QOB/gjIHwdsXMpyAFlq+476K/AdWxNJxXweijMrjpD5nZ1M2hjJ0VD8ZLGo4hBnwvx1mpYhn5HpvCy59RucJsnRoHYyJT0WIRy4RHMeGZgna+fqniYxIK2SYwunt3xINaOo+c1n54vMLNOvvAAv+FMv5qvr/Awz2DewroLA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721607177; bh=Jmx/DRlhG0AubfcVCPtfvboBS3N1OorMmBd4LRWoBgA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Vch8R4ahfezMJGXeXFzIP/XrKuF4v49wG0Fn22c7w4t5AurMX4Ud/ThGkb8Ir24uIpCoHwxxVU57elZjoxYgHJJxJ38UuQad+5QOTGsqHVPsxWcv7sQs5rfE3hHEeSBcIXRMvpbb4T+oVeQg68i+FTpugqKgqyKjOZdvyBoJ6aEYSVW0e7sCD690L2105wvPSROQ3ciRYs/Hlo/QTTAhpnNbPthVw4hwenD4xiJ/8iZE82+uN71z3Bw3XYymLgcuqSiEweFj+VGNX787Ig0RWbrUU3FHw+lfWEOD9PisO5rXi6MTYbAWyZ7R51l4qlWvqEdNvSs2u36o9ip8zG/NhA== X-YMail-OSG: EY51KSYVM1nPM1whoJNw2AW9qzaESBCqNU1HEg80jrWhDLEvoPjbB7buEKnWKcA 7YBR4Ss_WC9izmtTDZBWcNYRBj60OZaRlmaGu8byeW4QsXih6lrGRwtCADBPvoCQjS4Yc9uxEgP4 shkmhmPoCdQLHD18CQin8XoqHlPXjsYqKxm5WnQWJYERNJnZUtLZMJ4GkXtolD1qe5WxJz7AkPP2 tu6KpmxDQq_Wd_E4kjDWZYCsXacpBXmuZaVvz0_Lt3CSUkOteA330fDbsLUSO9iU5WUQ.YWjnwUE XtnHrxIRMRToQQSFL6I1NEIJ28eqw7BlKawiFGexgkZhXA3fZcAdKyJ8VSz9vu7K0G7medEGfeAv gCOPWIDhoS9lKj3FKblnAjKv8POAJ.7l2J8MkxmJw_gOumR6vik0JHXUXaJsATdP6.FDXUF_kN5e umgQ3upBkVEXiXc.KRFaL_KFyJ6JYcFsyaX8Y_CfrXs2_.XubT6B_JnF8x9J.IZPWe2gOx7SFBfp 5uq48ITFooVobCcuuKpn9fCu.ohBKkoR55EXWtSW_sZony.GJSd8deoaS3IFyiWagN5jQukjq1M0 KiFFsSOl0Pda2wB87ZEOM9PAuthlGiEnZceEN8PWO9sOVVcvg0XXMJPSZ1AvGLWE5nxX7Ke8rf.t ounpoVFBnCr2foS15umCIs8MeUWymqdV06R4NKtEiHlbpgIgk_7bquc.QOg.RNFFYCH6QAry152w 8BcmWc.AzKt45s6TS7ZOSbzmxEFJsBmgWFIIK2Tof4M96OUbViNpWlUwCyYUxiSCdZ_17JZTdb8U Ncjp5TMXc66flanBbBD6M2eRoCCtWmQUJ5HF1Vod93AynGr2Pu8HYaVSnSqBrzyXpsneedFAFT5L wvlMHYUgQy.DzBGpszY0PEM1RhjC6sUuQoeOrnsmI3aYlAZ.3jK7PdFE10zRCuAhIvD52MeZ49mx SOJAjROhDGf_yxpZAhJNm9yRPmU__58aGYQanvlm5YHfr9V0j.aCLBVKN.t171KTNh4967m.urJI 4rLY_PzOxnDFig4tQTqnYf0PGS__3y4mKoGMfn7Wt76GpkiAtuWMEDnYn7l_6rzAy8UBTHDMno0i UZV3e2Me2w8RBxOdethGDMg8FxGh0vNQENBB4r6kT7fBcVUmZA1CAYMpEVPZ77OCcgzompVmmIlM diNQGW3hSboTaLwL6MhAp0hLYZA6pQh9ErYmb2tTZeQuZAaWfoZYQtL60FDKckKCs9QU51.J4HTj HQ6JA6iApY3ijV3GKhM1TpHDGlAi_wYIIrf6yfXStiZ67B4Q38wUmlJ2GTYl6hsd4.p9PONHINQ9 Hbcd1yJVwNY7GK6t3gHKeVdPPbnmPeOSxHZf2v6T1MAIUYm1701QqtsvxaUE8wwpmli8zpTVQkHu 7xvT3Gk6D4YNTgDgX_TIQEV33ICGQLojBo2nTHx9N9ErXyj8jVJjg1IlMm5p7Q2hxdUzKDfV4AhL 5bBDpSucOyLCAJjSjAjhIyrU3jLMz.IQYxDRgXKtATN9B_dxpoDnXnIlRo1.6c6DsFPf5d6VinyZ aWGnQfzbcyWJjIDtIzVE1UHXmjUz4kWjp0PbC00IZ4sgZTbN4V5kHvVMti2E0JwqkzUDkvkAc7Ps rUAcPLBuYQ3Fst9MT6dha6GXnp2G7ivOgRNeNTEHhbAvO5TLUAS0bk5GjaANsLaKBqJoCd.5Q4Gm VZAA6phl1bFOsoZsbN2kgJbgJ710iGseObLIbLtVENiwyrP4ZBTdoTXEfDei62ihcGsdmKdUv3sN Gk70wDbVyLPAoGTiWuuvZOFeJdKEw_u9FCv12oEMLQsIM6PvbnvbCByTqGXSwQP2Untj0imPzlU0 EJ6wFhODESQVU.DzUPGx5P2vjB.pWrcqTjFgsV5n8s_fS_s5Qx4n6qbv2.hVYYHLgOunoupfEa.0 hCjyx9Tz6S8the3urFGeWTrcCjqBCKSH_LsHRdqIdIOVP5b1vO5HuZecnrhGEOtanBaVlfCmkcXV veqOZ2LaLikekPEmqe5kMrPZ9_Un.BVcFYa_5HjIyLFt.KKvkWVPDnWyzsaj1vGp3CfLzjulamTq 622FfDJIPuL5fLuJ.PYSaACRQYvg0CLue9ZsAoTntAMycixD9k2rm.wmcM3dRT9.L_mSLgwfDkhL 9JDhjTXhHuFMepnDMfDkZKwvnkr0qDR6aJy3NNjnl2zFbXKFpbaId3szr5E.79uZU5Eid67pA6Cp NnecPWuu.GPeptm6_2.mIyvSPEAZ_yBv2LwuBiXF0sVkZibdcaNhJuYyL2BRQ4jTvq097TrfuGX8 o6g-- X-Sonic-MF: X-Sonic-ID: 4a934df9-d093-4aff-8d1c-ac6993f130f3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 00:12:57 +0000 Received: by hermes--production-gq1-799bb7c8cf-hh58k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 18c9d6e88dfa470d4495856163e5bd03; Mon, 22 Jul 2024 00:12:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: Date: Sun, 21 Jul 2024 17:12:41 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4WS12M5gWWz4dHw [Correction to a rather misleading wording in my description of the failure sequencing.] On Jul 21, 2024, at 03:36, Mark Millard wrote: > On Jul 20, 2024, at 16:42, Mark Millard wrote: >=20 >> On Jul 20, 2024, at 01:57, Konstantin Belousov = wrote: >>=20 >>> [Everything and everybody in Cc: are stripped for good]. >>>=20 >>> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote: >>>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3 >>>>=20 >>>> (gdb) bt >>>> #0 0x201aeec0 in __pthread_map_stacks_exec () from /lib/libc.so.7 >>>> #1 0x2005d1e4 in ?? () from /libexec/ld-elf.so.1 >>>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>>> (gdb) disass >>>> Dump of assembler code for function __pthread_map_stacks_exec: >>>> =3D> 0x201aeec0 <+0>: ldr r0, [pc, #8] @ 0x201aeed0 = <__pthread_map_stacks_exec+16> >>>> 0x201aeec4 <+4>: add r0, pc, r0 >>>> 0x201aeec8 <+8>: ldr r0, [r0, #156] @ 0x9c >>>> 0x201aeecc <+12>: bx r0 >>>> 0x201aeed0 <+16>: andseq r6, r7, r4, lsr #12 >>>> End of assembler dump. >>>>=20 >>>=20 >>> Do the following: >>> 1. Rebuild rtld/libc/libthr with the debugging info and no = optimization, >>> i.e. ensure that flags are "-O0 -g" or "-Og -g" and not -O2. See >>> the first comment in libexec/rtld-elf/Makefile for the hint how to >>> do it. >>=20 >> I did a full buildworld with "-Og -g" via temporary >> use of: >>=20 >> diff --git a/share/mk/sys.mk b/share/mk/sys.mk >> index 44db9266784f..9c6c7ce575a4 100644 >> --- a/share/mk/sys.mk >> +++ b/share/mk/sys.mk >> @@ -145,7 +145,8 @@ CC ?=3D c89 >> CFLAGS ?=3D -O >> .else >> CC ?=3D cc >> -CFLAGS ?=3D -O2 -pipe >> +#CFLAGS ?=3D -O2 -pipe >> +CFLAGS ?=3D -Og -g -pipe >> .if defined(NO_STRICT_ALIASING) >> CFLAGS +=3D -fno-strict-aliasing >> .endif >>=20 >> I installed the result armv7 world into a >> directory tree and installed pkg and cairo. >>=20 >>> 2. Reproduce the issue >>=20 >> The dlopen_test.c based case does not fail under the world >> built with "-Og -g": >>=20 >> # cc -g -std=3Dc11 -pedantic -Wall -pthread dlopen_test.c ; ./a.out >> #=20 >>=20 >>> under gdb >>=20 >> (gdb) run >> Starting program: /root/a.out [Inferior 1 (process 36680) exited = normally] >> (gdb)=20 >>=20 >> So it does not reproduce in gdb when buildworld was based >> on "-Og -g". >=20 > I found another context that has useful debugger information > and also fails. It avoids graphviz being involved: >=20 > ) a pkgbase install that I had around (pkgbase has debug information) > ) also set up /home/pkgbuild/worktrees/main/ to refer to the /usr/src/ = that pkgbase put in place > ) pkg install cairo > ) use of my simple dlopen program >=20 > (gdb) run > Starting program: /root/a.out =20 > Catchpoint 7 > Inferior loaded /lib/libgcc_s.so.1 > /lib/libthr.so.3 > /lib/libc.so.7 > /lib/libsys.so.7 > r_debug_state (rd=3D, m=3D) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4485 > 4485 } > (gdb) c > Continuing. >=20 > Breakpoint 3, get_program_var_addr (name=3D0x20042f2a "__progname", = lockstate=3D0x0) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4523 > 4523 symlook_init(&req, name); > (gdb) c > Continuing. >=20 > Breakpoint 3, get_program_var_addr (name=3D0x20043c97 "environ", = lockstate=3D0x0) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4523 > 4523 symlook_init(&req, name); > (gdb) c > Continuing. >=20 > Breakpoint 3, get_program_var_addr (name=3D0x20043c9f = "__elf_aux_vector", lockstate=3D0x0) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4523 > 4523 symlook_init(&req, name); > (gdb) c > Continuing. >=20 > Breakpoint 3, get_program_var_addr (name=3D0x200442e8 "__libc_atexit", = lockstate=3Dlockstate@entry=3D0xffffd668) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4523 > 4523 symlook_init(&req, name); > (gdb) c > Continuing. >=20 > Catchpoint 7 > Inferior loaded /usr/local/lib/libcairo.so.2 > /usr/local/lib/libpixman-1.so.0 > /usr/local/lib/libfontconfig.so.1 > /usr/local/lib/libfreetype.so.6 > /usr/local/lib/libEGL.so.1 > /usr/lib/libdl.so.1 > /usr/local/lib/libpng16.so.16 > /usr/local/lib/libxcb-shm.so.0 > /usr/local/lib/libxcb.so.1 > /usr/local/lib/libxcb-render.so.0 > /usr/local/lib/libXrender.so.1 > /usr/local/lib/libX11.so.6 > /usr/local/lib/libXext.so.6 > /lib/libz.so.6 > /usr/local/lib/libGL.so.1 > /lib/libm.so.5 > /usr/local/lib/libexpat.so.1 > /usr/lib/libbz2.so.4 > /usr/local/lib/libbrotlidec.so.1 > /usr/local/lib/libGLdispatch.so.0 > /usr/local/lib/libXau.so.6 > /usr/local/lib/libXdmcp.so.6 > /usr/local/lib/libGLX.so.0 > /usr/local/lib/libbrotlicommon.so.1 > r_debug_state (rd=3D, m=3D) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4485 > 4485 } > (gdb) c > Continuing. >=20 > Breakpoint 3, get_program_var_addr (name=3D0x200435bf = "__pthread_map_stacks_exec", lockstate=3D0xffffd290) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:4523 > 4523 symlook_init(&req, name); > (gdb) c > Continuing. >=20 > Breakpoint 8.3, _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > 140 round_up(thrd->attr.guardsize_attr), > (gdb) bt > #0 _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > #1 __thr_map_stacks_exec () at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:178 > #2 0x2005d1e4 in map_stacks_exec (lockstate=3D0xffffd290) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:5946 > #3 dlopen_object (name=3Dname@entry=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D, fd@entry=3D-1, = refobj=3D, lo_flags=3D, mode=3D1, = lockstate=3D0xffffd290) > at /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3872 > #4 0x20059e4c in rtld_dlopen (name=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D-1, mode=3D1) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3751 > #5 0x00020510 in main () at dlopen_test.c:14 > (gdb) s > 139 mprotect((char *)thrd->attr.stackaddr_attr + > (gdb) s > 141 round_up(thrd->attr.stacksize_attr), > (gdb) s > 140 round_up(thrd->attr.guardsize_attr), > (gdb) s > round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb) s > 130 size =3D ((size / _thr_page_size) + 1) * > (gdb) bt > #0 round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:130 > #1 _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > #2 __thr_map_stacks_exec () at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:178 > #3 0x2005d1e4 in map_stacks_exec (lockstate=3D0xffffd290) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:5946 > #4 dlopen_object (name=3Dname@entry=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D, fd@entry=3D-1, = refobj=3D, lo_flags=3D, mode=3D1, = lockstate=3D0xffffd290) > at /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3872 > #5 0x20059e4c in rtld_dlopen (name=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D-1, mode=3D1) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3751 > #6 0x00020510 in main () at dlopen_test.c:14 > (gdb) si > 129 if (size % _thr_page_size !=3D 0) > (gdb) 130 size =3D ((size / _thr_page_size) + 1) * > (gdb) bt > #0 round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:130 > #1 _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > #2 __thr_map_stacks_exec () at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:178 > #3 0x2005d1e4 in map_stacks_exec (lockstate=3D0xffffd290) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:5946 > #4 dlopen_object (name=3Dname@entry=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D, fd@entry=3D-1, = refobj=3D, lo_flags=3D, mode=3D1, = lockstate=3D0xffffd290) > at /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3872 > #5 0x20059e4c in rtld_dlopen (name=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D-1, mode=3D1) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3751 > #6 0x00020510 in main () at dlopen_test.c:14 > (gdb) disass /s > Dump of assembler code for function __thr_map_stacks_exec: > . . . > 130 size =3D ((size / _thr_page_size) + 1) * > 0x20112eec <+340>: mov r0, r6 >=20 > 129 if (size % _thr_page_size !=3D 0) > 0x20112ef0 <+344>: ldr r4, [pc, r4] >=20 > 130 size =3D ((size / _thr_page_size) + 1) * > =3D> 0x20112ef4 <+348>: mov r1, r4 > 0x20112ef8 <+352>: bl 0x20116b60 >=20 > NOTE: 0x20116760 - 0x20116f30 is .plt in /lib/libthr.so.3 >=20 > --Type for more, q to quit, c to continue without paging-- > 0x20112efc <+356>: mov r9, r0 > 0x20112f00 <+360>: mov r0, r5 > 0x20112f04 <+364>: mov r1, r4 > 0x20112f08 <+368>: bl 0x20116b60 >=20 > NOTE: 0x20116760 - 0x20116f30 is .plt in /lib/libthr.so.3 >=20 > 0x20112f0c <+372>: mls r1, r0, r4, r5 > . . . > (gdb) si > 0x20112ef8 130 size =3D ((size / _thr_page_size) + 1) * > (gdb) 0x20116b60 in ?? () from /lib/libthr.so.3 > (gdb) bt > #0 0x20116b60 in ?? () from /lib/libthr.so.3 > #1 0x20112efc in round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:130 > #2 _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > #3 __thr_map_stacks_exec () at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:178 > #4 0x2005d1e4 in map_stacks_exec (lockstate=3D0xffffd290) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:5946 > #5 dlopen_object (name=3Dname@entry=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D, fd@entry=3D-1, = refobj=3D, lo_flags=3D, mode=3D1, = lockstate=3D0xffffd290) > at /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3872 > #6 0x20059e4c in rtld_dlopen (name=3D0x1042d = "/usr/local/lib/libcairo.so.2", fd=3D-1, mode=3D1) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:3751 > #7 0x00020510 in main () at dlopen_test.c:14 > (gdb) si > 0x20116b64 in ?? () from /lib/libthr.so.3 > (gdb) si > 0x20116b68 in ?? () from /lib/libthr.so.3 > (gdb) si > 0x20116760 in ?? () from /lib/libthr.so.3 > (gdb) si > 0x20116764 in ?? () from /lib/libthr.so.3 > (gdb) si > 0x20116768 in ?? () from /lib/libthr.so.3 > (gdb) si > 0x2011676c in ?? () from /lib/libthr.so.3 > (gdb) si > _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:78 > 78 stmdb sp!,{r0-r5,sl,fp} > (gdb) bt > #0 _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:78 > #1 0x201373b0 in ?? () from /lib/libthr.so.3 >=20 > NOTE: 0x201373a8 - 0x201375a0 is .got.plt in /lib/libthr.so.3 >=20 > Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >=20 > Turns out that _thr_rtld_rlock_acquire is looping when the > process is stuck: >=20 > . . . > (gdb) bt > #0 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 > #1 0x20060788 in rlock_acquire (lock=3D0x2008af10 , = lockstate=3Dlockstate@entry=3D0xffffd0ec) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld_lock.c:259 > #2 0x20059098 in _rtld_bind (obj=3D0x2008f404, reloff=3D496) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:1035 > #3 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 > #4 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 > #5 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 > . . . >=20 > (gdb) info threads > Id Target Id Frame * 1 LWP 100174 of process = 97711 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 >=20 > So: Only the one main thread. >=20 > It is repeating the _thr_rwlock_rdlock loop (lines 121/122): The above wording is greatly misleading for what I was trying to refer to (by being greatly incomplete). Correcting via a different description . . . For starting with (via breakpoint activity stopping there): #0 _umtx_op () at _umtx_op.S:4 #1 0x2036845c in _umtx_op_err (obj=3D0x20137c40, op=3D12, val=3D0, = uaddr=3D0x0, uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 #2 0x20115da8 in __thr_rwlock_rdlock (rwlock=3Drwlock@entry=3D0x20137c40,= flags=3D0, tsp=3D) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:294 #3 0x2010ebf4 in _thr_rwlock_rdlock (rwlock=3D0x20137c40, flags=3D0, = tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.h:229 #4 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 . . . I get the sequence below that involves one ^C to get out of the hung-up status for some activity (that eventually hangs up again). It is true that _thr_rtld_rlock_acquire does not return but loops for this kind of sequence. It is just an insufficient overall description. (gdb) finish Run till exit from #0 _umtx_op () at _umtx_op.S:4 ^C Program received signal SIGINT, Interrupt. Sent by kernel. _umtx_op () at _umtx_op.S:4 4 in _umtx_op.S (gdb) finish Run till exit from #0 _umtx_op () at _umtx_op.S:4 0x2036845c in _umtx_op_err (obj=3D, op=3D, = val=3D, uaddr=3D, uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 36 if (_umtx_op(obj, op, val, uaddr, uaddr2) =3D=3D -1) (gdb) finish Run till exit from #0 0x2036845c in _umtx_op_err (obj=3D, op=3D, val=3D, uaddr=3D, uaddr2=3D0x0) at /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 0x20115da8 in __thr_rwlock_rdlock (rwlock=3Drwlock@entry=3D0x20137c40, = flags=3D, tsp=3D) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:294 294 return (_umtx_op_err(rwlock, UMTX_OP_RW_RDLOCK, flags, Value returned is $3 =3D 4 (gdb) finish Run till exit from #0 0x20115da8 in __thr_rwlock_rdlock = (rwlock=3Drwlock@entry=3D0x20137c40, flags=3D, = tsp=3D) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:294 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 121 while (_thr_rwlock_rdlock(&l->lock, 0, NULL) !=3D 0) Value returned is $4 =3D 4 (gdb) finish Run till exit from #0 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 Breakpoint 1, _thr_rwlock_rdlock (rwlock=3D0x20137c40, flags=3D0, = tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.h:229 229 return (__thr_rwlock_rdlock(rwlock, flags, tsp)); (gdb) finish Run till exit from #0 _thr_rwlock_rdlock (rwlock=3D0x20137c40, flags=3D0,= tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.h:229 Breakpoint 2.1, __thr_rwlock_rdlock (rwlock=3Drwlock@entry=3D0x20137c40, = flags=3D0, tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:284 284 if (tsp =3D=3D NULL) { (gdb) finish Run till exit from #0 __thr_rwlock_rdlock = (rwlock=3Drwlock@entry=3D0x20137c40, flags=3D0, tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:284 Breakpoint 4.2, _umtx_op_err (obj=3D0x20137c40, op=3D12, val=3D0, = uaddr=3D0x0, uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 36 if (_umtx_op(obj, op, val, uaddr, uaddr2) =3D=3D -1) (gdb) finish Run till exit from #0 _umtx_op_err (obj=3D0x20137c40, op=3D12, val=3D0, = uaddr=3D0x0, uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 Breakpoint 5.2, _umtx_op () at _umtx_op.S:4 warning: 4 _umtx_op.S: No such file or directory (gdb)=20 > (gdb) list 115 > 110 _thr_rtld_rlock_acquire(void *lock) > 111 { > 112 struct pthread *curthread; > 113 struct rtld_lock *l; > 114 int errsave; > 115=20 > 116 curthread =3D _get_curthread(); > 117 SAVE_ERRNO(); > 118 l =3D (struct rtld_lock *)lock; > 119=20 > (gdb)=20 > 120 THR_CRITICAL_ENTER(curthread); > 121 while (_thr_rwlock_rdlock(&l->lock, 0, NULL) !=3D 0) > 122 ; > 123 curthread->rdlock_count++; > 124 RESTORE_ERRNO(); > 125 } >=20 >=20 >>> , and backtrace all threads from userspace. >>> I only need userspace backtrace, not either kernel-side stacks nor >>> the syscall history. >>>=20 >>> Are you sure that the issue is specific to armv7, might be it takes = more >>> efforts to reproduce on host native? >=20 >=20 I'll note that my personal builds of armv7 are set up to use -mcpu=3Dcorext-a7 . It appears in my experiments that such may generally avoid the hangups. It may be why my initial attempts to reproduce the problem months back did not manage to reproduce it. It may also contribute to the "-Og -g" test not getting a hangup failure. My reproductions are based on having installed and used official pkgbase builds mostly, and a little official snapshot based activity (not updated via pkgbase). This avoids such personal oddities as -mcpu=3Dcorext-a7 use from being involved in my builds. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 03:58:18 2024 X-Original-To: current@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 4WS62g2pTjz5RDZl for ; Mon, 22 Jul 2024 03:58:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WS62d5MdLz424r for ; Mon, 22 Jul 2024 03:58:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y+5p7tEr; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721620712; bh=x7pFIdtt4oRR+lxpO2H3yFWRrcrumNMB4y8KxdVPFAo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y+5p7tEr2zFa4wuPkB0hKau6g8CaqpXAQ0LQouoZqUu1vn94rrGXpcxPpGWxPRnqywVTfdYxzC/5LSHjRHVypqvJ1lx5cIlmi56hmYmYtqPaBfLBRErr6PdekDdqvxDc48GufJ2tx4oe+jXjURdrkEBcCddU6yeAYsJDR5IGBdaB1No3SI4LunRpF058UI3WmwSIM/irg+GspbpBJmNkMkP5XPtp4793UafibdImzbE4B9VpKdsJulkPWKr6bo0UhGovqPLen7L2JmvXa2m0nsfmX2jx+ecVp8HE8nRTHfdvn+4t+YLt03cLvpfZnkzusJH1ZPHWa5VZKL9psmthEA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721620712; bh=7NqtAYSB0pqhd/m+4tPoVFHunMqw4uos88Jvb6O7SUa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PitPauiFF9SQ1J7kjl1PzRQPVMyaM9Dfc/Uc7WUquSljRGa+7y49gmEvJOdzJCoaGZNPIetRYUCXdGRTb0QOuZLs0My+Afq85A9gPRS80zXnL/DbNFiIIpmbXxRLG17z/q59R6PAhj+xvoCsQ5xaPVTQjZo9DTON0NcabwNDO3SCMNVuiko/bP7j0kxDNuZ1eK9E+6XIQb+PmEZlzRbOgbt8c82VzRwX2OKqQ+yEf0UyD0yjGnAcZ8N6UkWlHhyozUFcRPDMpR9w8d8Y1cYpeOmpp/2DrXBhfL8dF/lRjX2pRbGXeeHZUzDXqcS6X8QWx/zqVug+wmOQVQnAhANmFQ== X-YMail-OSG: 7g0Z1bEVM1n3vSdE_4UkJOFFfi3UZUEmkAgHPkh9D67Nc_ZkuVPhHYs1f2r6Pra R7SqIlYzopREwSkEE0QKipJBDvrSu2FLo2nXcBTmp9rh.5fJPFugvbnC6Txfv13ZoKd1s8aqDbCh jB5dR59uHswx2ejn.o7Tw695ByZYt6Z.ZLu3_k_p__upbxl.axh.VDk2VByAD_1z7sm3P5dmj1KQ qFDZXkmrGa2zrjNMP1fFepKoX6yylEJ5KqDp2IEtTHK_gIcSH4cTORXgB8jo8Cz.kmQBhc6hMxCC jiz38NXwTvGeErff6Ytk7T6Jh2.hGo9X3pJHMLVivveoqNdAhJE2zOxxjTzrHtmA85ZN48krBgMo skF9r.KvlueOtMx.TvRXnfsMWsRfiKp8Ytmi5gaslYrjZUUFl8v9MVnrb8t2N3t7qrYLrx4_UEpW oAYe9ul5Ew.AkZxPfXCFUi6I8hoU0v662f4wLFxeH5gDH9GfNw0uF_3HdZ755ILqWQJbg23GsJQm RL3nn62zKZcvGZTzm5CdzxkQ_3a1U6l2l5PNJnyR1Iayi_5JMWJFa4o8fd2Oz94PArIC_8DH3sw7 RaKiNItgcLV3WbBgpsgq9uE7eh0kFF_NBJzjAMhfB0ixPujsGUYFiK8T.FobhE4WWJLjGfdc68sI 8ig0VCF8cRHzj0EQVS7ehbSKAlp2DZx4FYLr1hYJTpjLm9qN8iwjqg.lAivwBH1N7pdjrY3d6d25 TXC3Lnn0MBoN4iYtBSTZPSS4zirhLMON3K4gkcZuT_IPQrF90QxoV0yV9rMtG_gaMbvSkopjrml_ pdUuYy_7vgXOzFVQaxyYlFL8EBcfvte6FGVXnjLeQu46NrWPUoj2zSGctVGDToXobuBJmY8FhIh7 9Wuz6Cqg1DeaRwHCcRjJG_S8s.wDq1jPKF7r4hYpb6DPYjmbylT4hkA9ZhgugWEp5sEofmwz5Xck dXOZ1wcYMxe2E1HLwbaPWpfzWp_j8VjBSmDsiikSWwOY6IyvgeaIslKXbUvXLEwMt5MiW_hAepq2 zSm5LFO.b6m_E.VqySuh6FVUu59AtXOLvEzkHO5vS9ztQT3YenveRdWstKdtHFMFBKkYVsaBXd_6 XhYjlDMTRcnHJXlgG_bzrcBrPrn1kegZcecnrsNGrN0yZJbHeA_9umB8uqLvwA_P.RvwxCW8CvbD 78W8zy3HVE7mVAcK0RikgiJLcxrhn11L_1a09xHHZSQhkR5XcYw4EzNWYFVmO9ueL9_30mWt7n2F g.TFzBflVdtTVj5P2mbuMzdzc1fcHM0iWJjg9SbZmudQJTPts2YOcK8vDEa_3vVJ5Nb452oeKiN3 L9rblMYfqRgH4g4S2qi2LxLVxXcWNqP9HbEt9pfis1XcNs27HC.9x2yNNAOdp0w_lSISnbiXVc.L 9zIn2KW3cqhADC2szpldt6IrRQ9jt83hnK6VP17oZbNrdxdsv7hvFZ1xtH6hIydpk.1aN05zuP7U y567yJoGjOGUQkJJBOkrHVtfeZDJdHU9Yzb2VkBcP_z__rV1A8qlf_LdZ.1A3arzejlruIPW8SAX Mq8Lvw2lo.z.dDxf4Dy4.EMJdfHnc4u1q3N0LdK.dz2Ky18mBNmHlNYIkPYB5f5ToOX7xgan.jG2 OSnCuifeKmrdz7_8z6ayQI6x_iRiSs9Xx7OHlTzf7ulG6x837mucOc_7TeBF5SWyXF0PdY8fsNFH 3YF3l2J6Kb_5ayI52Tto_4IRJaMZS22YyhBEx0ntitKn0jE.ROPG1yT2Y9ORZp.KbMA8m4.wo2Ev 03BGfm.HDJVtIYOqIQBaGZbn0W5vlQB3eeLq3_3vZYJ8YrhPALQyB4URrs_1ndIiHuwZ1UJ5aJyX PjdxUe6EdYCZni8ON38djWZSDZgSH7XFj1bTb14qHEAAmNijSKHHq_YmJopWaR5t69BRhun0e.Dx Xh15XwEin1DByhsslovsp6477MfGMJSdoB0mbzdvT5Qfneczz9ncGWVn2Y2MuD7SXN5PsAbf3rEr 6z02EdmkJiK_RFjY0vt2CZhOVxbZX57VbHTmOz5xK8BJW8Xs0JZceNUs5Rncgj1q4_Tzj9zw6geD VXSXzrrLNVAPJcvaB0YCauToxAonh37l9LqvpeTuG1c7QSFlBpWB8u3ni9Vk8WP0L8ASwAC5bZXC ELoWMVxyc2T1MRKGqLRcYCiJTD9wskEEoXY12Dq.91AsrfrznNiOIBmb0zDqckXRXhQMxnbRWJ7Z DSFaM0s.TL4vdZpb7EwAgRbAclFI6BPA2yLpDOLzwN22r1AHQMgAbD0Q8cyUGQOVBCxr9NP3UkCC 6pHNG9.uX X-Sonic-MF: X-Sonic-ID: 757b0104-4d8a-47b2-99f9-79c6522e1225 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 03:58:32 +0000 Received: by hermes--production-gq1-799bb7c8cf-mlhxz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b98fa44d8f83b1df02d5d9c44384a4d; Mon, 22 Jul 2024 03:58:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: Date: Sun, 21 Jul 2024 20:58:18 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> <9E98F6F6-6896-4958-9D88-FF68C4AB57F2@mit.edu> To: John F Carr , Konstantin Belousov , Baptiste Daroussin X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[mit.edu,gmail.com,FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WS62d5MdLz424r I found a significant difference in my failing vs. working armv7 contexts as installed: Presence vs. Lack of a .symtab entry for the symbol _rtld_get_stack_prot in /libexec/ld-elf.so.1 . gdb inspection of operation shows distinctions based on the difference. This is related to the code: (gdb) list 140 135 void 136 _thr_stack_fix_protection(struct pthread *thrd) 137 { 138=09 139 mprotect((char *)thrd->attr.stackaddr_attr + 140 round_up(thrd->attr.guardsize_attr), 141 round_up(thrd->attr.stacksize_attr), 142 _rtld_get_stack_prot()); 143 } Working context (Personal build): NOTE THE .symtab ENTRY BELOW. It allows the gdb run to work: # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less ELF Header: Elf file type is DYN (Shared object file) Entry point 0x14548 There are 10 program headers, starting at offset 52 Program Headers: There are 24 section headers, starting at offset 0x1f2b8: Section Headers: Key to Flags: Dynamic section at offset 0x199f8 contains 15 entries: Relocation section (.rel.dyn): r_offset r_info r_type st_value st_name Symbol table '.dynsym' contains 27 entries: 5: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) Symbol table '.symtab' contains 911 entries: 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot Notes at offset 0x00000174 with length 0x00000018: Histogram for bucket list length (total of 6 buckets): Histogram for bucket list length (total of 27 buckets): Version symbol section (.gnu.version): Version definition section (.gnu.version_d): Attribute Section: aeabi File Attributes Breakpoint 8.3, _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 139 mprotect((char *)thrd->attr.stackaddr_attr + (gdb) si 141 round_up(thrd->attr.stacksize_attr), (gdb)=20 140 round_up(thrd->attr.guardsize_attr), (gdb)=20 round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110b8 129 if (size % _thr_page_size !=3D 0) 130 size =3D ((size / _thr_page_size) + 1) * (gdb)=20 0x201110c0 130 size =3D ((size / = _thr_page_size) + 1) * (gdb)=20 0x201110c4 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:130 130 size =3D ((size / _thr_page_size) + 1) * (gdb)=20 0x201110c8 130 size =3D ((size / = _thr_page_size) + 1) * (gdb)=20 round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110d0 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110d4 in round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110d8 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110dc in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 0x201110e0 129 if (size % _thr_page_size !=3D 0) (gdb)=20 _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 139 mprotect((char *)thrd->attr.stackaddr_attr + (gdb)=20 142 _rtld_get_stack_prot()); (gdb)=20 0x20114880 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20114884 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20114888 in ?? () from /lib/libthr.so.3 (gdb)=20 Breakpoint 9.1, _rtld_get_stack_prot () at = /usr/main-src/libexec/rtld-elf/rtld.c:5884 5884 return (stack_prot); (gdb)=20 0x2005b9b0 5884 return (stack_prot); (gdb)=20 0x2005b9b4 5884 return (stack_prot); Failing context (Official PkgBase build): NOTE THE *LACK OF* THE .symtab ENTRY ABOVE. _rtld_bind_start ends up in use instead, which looks to lead to the gdb run not working. IN FACT, NOTE THE LACK OF ANY "Symbol table '.symtab' contains" TEXT AT ALL! # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less ELF Header: Elf file type is DYN (Shared object file) Entry point 0x147b0 There are 10 program headers, starting at offset 52 Program Headers: There are 22 section headers, starting at offset 0x1a960: Section Headers: Key to Flags: Dynamic section at offset 0x1a4cc contains 15 entries: Relocation section (.rel.dyn): r_offset r_info r_type st_value st_name Symbol table '.dynsym' contains 27 entries: 5: 000000000001bcd8 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) Notes at offset 0x00000174 with length 0x00000018: Histogram for bucket list length (total of 6 buckets): Histogram for bucket list length (total of 27 buckets): Version symbol section (.gnu.version): Version definition section (.gnu.version_d): Attribute Section: aeabi File Attributes Breakpoint 2.3, _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 140 round_up(thrd->attr.guardsize_attr), (gdb) si 139 mprotect((char *)thrd->attr.stackaddr_attr + (gdb)=20 141 round_up(thrd->attr.stacksize_attr), (gdb)=20 round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:129 129 if (size % _thr_page_size !=3D 0) (gdb)=20 130 size =3D ((size / _thr_page_size) + 1) * (gdb)=20 129 if (size % _thr_page_size !=3D 0) (gdb)=20 130 size =3D ((size / _thr_page_size) + 1) * (gdb)=20 0x20112ef8 130 size =3D ((size / = _thr_page_size) + 1) * (gdb)=20 0x20116b60 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20116b64 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20116b68 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20116760 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20116764 in ?? () from /lib/libthr.so.3 (gdb)=20 0x20116768 in ?? () from /lib/libthr.so.3 (gdb)=20 0x2011676c in ?? () from /lib/libthr.so.3 (gdb)=20 _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:78 78 stmdb sp!,{r0-r5,sl,fp} (gdb) si 80 sub r1, ip, lr /* r1 =3D 4 * (n + 1) */ (gdb)=20 81 sub r1, r1, #4 /* r1 =3D 4 * n */ (gdb)=20 82 add r1, r1, r1 /* r1 =3D 8 * n */ (gdb)=20 84 ldr r0, [lr, #-4] /* get obj ptr from = GOT[1] */ (gdb)=20 85 mov r4, ip /* save GOT location */ (gdb)=20 87 mov r5, sp /* Save the stack = pointer */ (gdb)=20 88 bic sp, sp, #7 /* Align the stack = pointer */ (gdb)=20 _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 89 bl _rtld_bind /* Call the binder */ I have not checked for other .symtab entry problems. Nor have I figured out why the installed materials are different for Symbol table '.symtab' . So this is not yet root-cause information. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 04:08:04 2024 X-Original-To: current@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 4WS6Fv6zKGz5RFMW for ; Mon, 22 Jul 2024 04:08:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WS6Fv1P1mz447h for ; Mon, 22 Jul 2024 04:08:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=An6V9Fm5; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721621297; bh=Z3TaY0LOICU38oaFqGxmBTMbV7g3JLFOELFQXfpVtAc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=An6V9Fm5phhHR4vsL62WcVh8LRRzsRD9rO/UXq/5v5vdkeN2/DGmCcjWHNgVGDSrsex6B79JPQW1xCR5pUsjyvJiICmIaS14PnTDAteByj4mKjqi9NRndM9Rind8mpTJ71CdMjcpmwgFsIZNdflsK1K73BBfimY0x1z2XCh5NH1FoXNsg038v1v/eaK8YKGHedyTsO6qTJ6Q6wQ7KLD3hiX0RruJTbwFmIZSRHQOd1b3B8DRoplALGH4xusCHIxRLuCzbHS6P7VyH6mX3aKUVxPDxmPAq8eGqC7+iYmShg1/de3by0xrHNor7Cc//8oxzp72ddLztB/C9otD+pWNKw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721621297; bh=IKCS0kIZPbD1ywsYE0v92+aG9Rui3vvLweQOP/bE6Nu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oa51B7FRIIt3fIRGdl0eh4oLl0XsIms2f+vJQrrHdG1mOID0rJymdGsaREjZ66MJn2VFg4uzpV1Plorc92hSkFYayNtkkKrv88xIH/4TrA1iNvzPZ7EOfCZ6mN33aOQYFlXdfoOnqSzDW4tldPps9b0s9jpkpY2kJwSGZCA2lZks1rr2MWSbxu8PkSvBTOxL/1b5o4i59RG5bYbWLcu+XMT95xptkBBHH1E0ANZz1B6GPfQkioPqumgY4WFf+8/MSgV+gl3C3m9OVuf4g43aDX8OFQyZiNyEBPkK7YhKoZvW+teJnKPPT0//WSCA5ZW1cLCFXnfQ4/+hT0ti9UU7rA== X-YMail-OSG: mB85qEQVM1lwZf4x_7QEf580nFlypge.rwRKXfmHV8SZYItiXrqi2..QRBfH1YD hzq9ZemvxhC7HhlM2zFmRXOq2hRaEpcmEioY7iMJn5q.1HI6y.3UDJKlWdigh2ZfEw2SVKwXxIwv b.6Ui.kr6mU.qXWOcfpOhMJbbaaBTIDUKKHX_lYqoBZCYH6viKKjMjUKcqcI_ta2P4SvtTiiC1oE UA_dNcDLODY5ZBjp1yr2GklWQBMN42D5FcIuKTblblk6uaUdGeHmti7MQhYjcKoaFERQ914hWa1R rwJHp.ID29P1E5khY60IKYOzfGRfs9OA0djmSpRcMBo4PXH08MyWpllF1DSP0lVAlJopFi8_TxJF Nrmvri3YThjfNCkxkSqZn1Ue9AH2KAc8OL9ApwSYyaYsw8GvJx4XMzYh_MlwB.6EsizZf4TDZ.Oh 0kxAMnTv1NZa8X5Dl6.WCR.6n9tqBM6iJiwyY17PfLaUa925.d3ji3vJvc5IxLc9FPwbRMMo66jB VUVMQsYVBKG8FfNL4.8IOa9u2H4sf9DD7w2WdqviSJFi6xRtsTFxfsWnIsNz48H1v0pbypeGLxKd jVpP0Mzr.pNEmZvKzUtZpXofCbXrm96DtaRILX0xwQvm5Qheyfl5uf2fkmgonmRbm_XS13Zjp0OO ztI67885uHBVK3ZFUOUDCj2rTPkm4Ku9ExKfy1J4D1vZ1XUNbjQDMZTrP4S.Y1HhriH30zP.GaBZ DJHFC_01RJe_V87wuh7jhAcHEWgzdaOjmiNzvQWnL9LDN9LG442ddlRFBfqKvWhZvfzwYfnUber9 XKcPNcNBUlfpKDFbemgh8JXtiM9Tj8872rn663g8Y0hajFZfUSp3KLDa.Dt9d0FA_dB1TWDSaedk NLyj.nlYVTONPYtbCN1oIXcRq9.CAmBQuOqaGLDmzEeWvgKTlgP0_yVM67m.c8dVr7c5KG4g2b7C Tx7oeDonpeUCJ65qh_EicSfx2XmMj2PwyWqQNOJzPveZDGPNePCayvNbVuXaRy9IuPDDiFaY6TZe kWCpeXOHVibaSm8A9dh_D8idwY9UjAL20yTuIXufTt1JXjHxBBxbd5D4Akyq94QgmYAGSbG5EstQ WjG9YJ6m9fSqYibAG0ff_SvPGOZNV4KymT3t2MVmSYHmFG2dGZnWNvwjPZBtB2I9tsXPiRNVfIXt XMGJQRsReuKdyA_ENokJkNzsUlbr.JU0r5ArBk.tiVXJKlFbiWyHP9zHsufgX7phC0cD45djBGkR T0CsTFbn1TLcqaN7YRLOqLInwb6ZBgRx4CUzovzTFqp8B98Z4wbpE1tB5AhnqZAEyLq0h5ETAtd_ 4IT7RVhk_4Ezzq1YlOCh5RYzeM.rrCkGCizHMNNCmm.kgI.2RAokdxdHD.eaIA9GFPRjn02weIkr NxIT6ZWlLfHwzsVWhvWn5NCrOH437YDxCFSSolIDqsbR1jwWGyIZ31E54A0HJizm43T4hnmZgB3q N4R5_ohv50n1HXVr5YJ4xXB09wz41r6F8y69J9xYysji7sMXv.dWv9eqbJXQWYVy7aJMqpf4FlHp GSkb783MSHJQiC53Ht08.KT3YWcq_4dr4sQSEaMrmOZdNwYV1uwfOnCc0MTQbytwKvbA3Q9YIpzd BvW8C9.VIZ9j1Euz5JkZSx_i3RAv_Ht6.2dL7iLGPUkomKajWK0Rr_DFXUkn.cmzH49OVPd0tuZD Ckkw7p2SFPVuq52PvFdjDFsJjJVenF7.l7Vo4qsx3UtRGPGZie_lqIEFG3iKVreLl43NRwwAjFfP cDllY9A6sUL2wsXdBIkVNa23_7mYi5DD0IIjxrzsvtBLy2GKypzxx77y0uetmp02ihbQyvc.RhFn 89Uo1u8cO96keQFRMm.Z1D3.2eL.uVbl7CakdsBW4gYbI7ZTdgBW073TIYoUcDVXCZ0jfOxedgzJ y.qznbTyUS6qToJjKdcO.gs26Lhm6TU.lliQxgwH7Kkr.HB7Mx2RHfCyzaltQ7ICu.vwf_4EOxkO OiynXypDYUx.WuWICnJalYfsAvXm1xjUmyQizALp9agT2_uyDmtEyKU0zZUd_oUb.ffcoZrymfN3 KitDIlbi8BJ1m70SsnqPc3FcDnjk518CzW_0sfTFK.eeC5AEj6vXXK3mMJcg2wZFxL1I89n2wExm W5RbYDfKDnaaBS.3tE2ogMfb4IJuiz.FrvZfzP9PHpAlB.I45KMV6kWJNvW2GHMLBh_G4YICpsmp pEvnv5gPlEX_RmuAoCwm1lyZeQC26N2URAsZmvYg9ZCAqjfvCNOrrR.yX_ioWVKIFhDIplaE3b1N 1hhmyiwLw X-Sonic-MF: X-Sonic-ID: 8f03e7db-4e36-469c-9a19-dc374cf4e5b8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 04:08:17 +0000 Received: by hermes--production-gq1-799bb7c8cf-l6wmw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0eb7cae8457e6c1f76772f17e2954fb2; Mon, 22 Jul 2024 04:08:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> Date: Sun, 21 Jul 2024 21:08:04 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3D644314-7F84-4AA8-81A5-DCD29D4ABBC1@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> <9E98F6F6-6896-4958-9D88-FF68C4AB57F2@mit.edu> <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> To: John F Carr , Konstantin Belousov , Baptiste Daroussin X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[mit.edu,gmail.com,FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WS6Fv1P1mz447h On Jul 21, 2024, at 20:58, Mark Millard wrote: > I found a significant difference in my failing vs. working > armv7 contexts as installed: Presence vs. Lack of a .symtab > entry for the symbol _rtld_get_stack_prot in > /libexec/ld-elf.so.1 . >=20 > gdb inspection of operation shows distinctions based on > the difference. >=20 > This is related to the code: >=20 > (gdb) list 140 > 135 void > 136 _thr_stack_fix_protection(struct pthread *thrd) > 137 { > 138=20 > 139 mprotect((char *)thrd->attr.stackaddr_attr + > 140 round_up(thrd->attr.guardsize_attr), > 141 round_up(thrd->attr.stacksize_attr), > 142 _rtld_get_stack_prot()); > 143 } >=20 >=20 > Working context (Personal build): >=20 > NOTE THE .symtab ENTRY BELOW. It allows the gdb run to work: >=20 > # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less > ELF Header: > Elf file type is DYN (Shared object file) > Entry point 0x14548 > There are 10 program headers, starting at offset 52 > Program Headers: > There are 24 section headers, starting at offset 0x1f2b8: > Section Headers: > Key to Flags: > Dynamic section at offset 0x199f8 contains 15 entries: > Relocation section (.rel.dyn): > r_offset r_info r_type st_value st_name > Symbol table '.dynsym' contains 27 entries: > 5: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) > Symbol table '.symtab' contains 911 entries: > 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot > Notes at offset 0x00000174 with length 0x00000018: > Histogram for bucket list length (total of 6 buckets): > Histogram for bucket list length (total of 27 buckets): > Version symbol section (.gnu.version): > Version definition section (.gnu.version_d): > Attribute Section: aeabi > File Attributes >=20 >=20 > Breakpoint 8.3, _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 > 139 mprotect((char *)thrd->attr.stackaddr_attr + > (gdb) si > 141 round_up(thrd->attr.stacksize_attr), > (gdb)=20 > 140 round_up(thrd->attr.guardsize_attr), > (gdb)=20 > round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110b8 129 if (size % _thr_page_size !=3D 0) > 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 0x201110c0 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 0x201110c4 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:130 > 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 0x201110c8 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110d0 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110d4 in round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110d8 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110dc in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 0x201110e0 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 > 139 mprotect((char *)thrd->attr.stackaddr_attr + > (gdb)=20 > 142 _rtld_get_stack_prot()); > (gdb)=20 > 0x20114880 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20114884 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20114888 in ?? () from /lib/libthr.so.3 > (gdb)=20 >=20 > Breakpoint 9.1, _rtld_get_stack_prot () at = /usr/main-src/libexec/rtld-elf/rtld.c:5884 > 5884 return (stack_prot); > (gdb)=20 > 0x2005b9b0 5884 return (stack_prot); > (gdb)=20 > 0x2005b9b4 5884 return (stack_prot); >=20 >=20 >=20 > Failing context (Official PkgBase build): >=20 > NOTE THE *LACK OF* THE .symtab ENTRY ABOVE. Not "ABOVE": BELOW! Sorry. > _rtld_bind_start ends > up in use instead, which looks to lead to the gdb run not working. >=20 > IN FACT, NOTE THE LACK OF ANY "Symbol table '.symtab' contains" > TEXT AT ALL! >=20 > # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less > ELF Header: > Elf file type is DYN (Shared object file) > Entry point 0x147b0 > There are 10 program headers, starting at offset 52 > Program Headers: > There are 22 section headers, starting at offset 0x1a960: > Section Headers: > Key to Flags: > Dynamic section at offset 0x1a4cc contains 15 entries: > Relocation section (.rel.dyn): > r_offset r_info r_type st_value st_name > Symbol table '.dynsym' contains 27 entries: > 5: 000000000001bcd8 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) > Notes at offset 0x00000174 with length 0x00000018: > Histogram for bucket list length (total of 6 buckets): > Histogram for bucket list length (total of 27 buckets): > Version symbol section (.gnu.version): > Version definition section (.gnu.version_d): > Attribute Section: aeabi > File Attributes >=20 >=20 > Breakpoint 2.3, _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 > 140 round_up(thrd->attr.guardsize_attr), > (gdb) si > 139 mprotect((char *)thrd->attr.stackaddr_attr + > (gdb)=20 > 141 round_up(thrd->attr.stacksize_attr), > (gdb)=20 > round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:129 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 129 if (size % _thr_page_size !=3D 0) > (gdb)=20 > 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 0x20112ef8 130 size =3D ((size / _thr_page_size) + 1) * > (gdb)=20 > 0x20116b60 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20116b64 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20116b68 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20116760 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20116764 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x20116768 in ?? () from /lib/libthr.so.3 > (gdb)=20 > 0x2011676c in ?? () from /lib/libthr.so.3 > (gdb)=20 > _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:78 > 78 stmdb sp!,{r0-r5,sl,fp} > (gdb) si > 80 sub r1, ip, lr /* r1 =3D 4 * (n + 1) */ > (gdb)=20 > 81 sub r1, r1, #4 /* r1 =3D 4 * n */ > (gdb)=20 > 82 add r1, r1, r1 /* r1 =3D 8 * n */ > (gdb)=20 > 84 ldr r0, [lr, #-4] /* get obj ptr from GOT[1] */ > (gdb)=20 > 85 mov r4, ip /* save GOT location */ > (gdb)=20 > 87 mov r5, sp /* Save the stack pointer */ > (gdb)=20 > 88 bic sp, sp, #7 /* Align the stack pointer */ > (gdb)=20 > _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 > 89 bl _rtld_bind /* Call the binder */ >=20 >=20 > I have not checked for other .symtab entry problems. >=20 > Nor have I figured out why the installed materials are > different for Symbol table '.symtab' . So this is not > yet root-cause information. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 08:00:11 2024 X-Original-To: freebsd-current@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 4WSCPW1Kf2z5Q8l8 for ; Mon, 22 Jul 2024 08:00:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSCPW0ZV9z4RHr; Mon, 22 Jul 2024 08:00:15 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721635215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=0YKlRXZxjq5NJcxUN9NM0VVWKCHoiAO1QAyC10AUYoc=; b=CeQh8LaF6CaMN8M3bf0X+CSEG2pDx20fnyrBrY+I44iawOE9w3h59KitB/rpaU79r5Ulbf g5aoL+iDXFlvpyI+K/PqYl8K+3ufirlzDo3E1fnZuKXHVpzr6KgwhNpPsyP6ATPqkjPBUB 4iemhgXv3+aqB+WxuFZ1ydW9DZfxQzJkOlQTCbMsZGjz0g+6pzg5RN7CxWvCeZpoBJQnt5 aWjnBgAMsxBHMlUCHsuUf3w0v8NqykMBAxNbssaDATJWL6fSD7187Q9fMyY6T+VNIvZOul YytIWjvBqB4MJuRG+tZEACst49RceJ1AsNxurVr1r782Vxju3T9qcEELfOrqhw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721635215; a=rsa-sha256; cv=none; b=Kw/PQkqxD6SFmawWlcUzMqTCaxHwYwQSSHCyfZmY9n69M2KefI+k7V9gTrogIyOPl0BKtF wZD5P2p9thbkg9N5nNw/2wBNGacw3NrI28Nc0MqcYTByrPI3LxtXlXqNiB6JNi1ivB0pxI 9OHOzAWazlbtxGwyMnNl2JUPehG0LFfwcpUsn2v0LWZUjM9Mr6yZz3+QDIaxXkUjgpVrdg tcDMeVNMciy7TX53h7rM6XumDEV3j0ptNMk/JFKn3XJlP65pVfU1N6oXXsgh+4aigQN/JB O/bYT3EFCKfXeneVN0kXCsMVrljFzq6iIygC7sNbCra+LjY8AVgto1vnNNFjyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721635215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=0YKlRXZxjq5NJcxUN9NM0VVWKCHoiAO1QAyC10AUYoc=; b=XMVNwAh+Gl7rlrp6HXanlkyLmBcTBJHwzVByJxTxyXWPxB2xlKZ392YcI3o1ZZicDnHrqv 0qqTLCggVoCwmuCphHUryDBGuoLs0btfLm/qCm72lyEE3c0Y8OQaEQqmT2UOvWbY6oC4oD YSkAxVV60nzTUNRKPAIhJh/TOcVrSpzwGfI4LVj27jHjwKwJo4dN4rG4yFCZ8+k1p5isNe ka1o1oJ/vk08qrPM4nkfP8DXIa76C+si6BIoVRXXtaM7D8Va5Ee+4vQVEG9CZH5Uw2WpXe AjStEKiscn1KRwnm/61l9H/MTGK6LhsRkmf/fM6dMDPjCpWjzBIu7t+Z4Oyt6Q== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WSCPV4WknzT63; Mon, 22 Jul 2024 08:00:14 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 22 Jul 2024 01:00:11 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: July 2024 stabilization week Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi FreeBSD/main users & developers: This is an automated email to inform you that the July 2024 stabilization week started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as main-stabweek-2024-Jul. The tag main-stabweek-2024-Jul has been published at https://github.com/glebius/FreeBSD/tags. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. Developers are encouraged to avoid pushing new features to FreeBSD/main, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Jul 22 11:38:00 2024 X-Original-To: current@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 4WSJF76Y2Wz5QV7k for ; Mon, 22 Jul 2024 11:38:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSJF63scQz4mvn for ; Mon, 22 Jul 2024 11:38:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hqf1n+Lc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721648295; bh=CQeUZ4xi/FWw/93HGvtiTYggIUVU0XgGM+meSdtv/gQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hqf1n+LcSaQuA2PMF2OcwlNGdH+fNad1VbQ6/OV30wQ8RZABNtIugV+4fbo2BfCPYbnHFkxeLCUSmeJ/+r0EEGmKqnjvfLiKkLt56LM3Oj15EDIdbC22/U/bV8Wa9Gas9o/PGk3u5PYN1FTYCMJSyYXM6BS/EJmeHpWpd1fdFyphN02sgwAZPSDuAzjStviLk34eIwiMCKSXX6v/oqPRz43P9spKVdWW0t0PLMFXE+qHZI4xrXoPU0Wuur86UyPrNrU2mjV37jHh6zEUgdHuaTNjOZIQYEdqcDkttRo/Tv6CuqnXfVmweMW/SWpszaRRW6RaBPWVRihVLU9d2Z035g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721648295; bh=NOyyRKeOGj7Ll7W5X5wIWIUT39PbPnSVDtYBgG0mYKp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Mflp7WmYsKozJOy6+GkE31xPRRQXIK7hQHw4nDdKIdC+/3HO7qKx0TMQeK9yWusa3/t93INliivQBizxwEqwZpy4qdXH8LQWfMzTluDrYJ/oNaQF416L6MpcvWs1aYcFZVfri3L6VRoQFCXjcO3Yyd9/cXZQIamB2W1j/FX76LtUeA3EStRbr/WsU7VnwtMtNC/oWGsWHHWjtT6HZm6sgYzp6ybQgimsnPNZzgnWT+MHJBVomDGzbUusyOYDFnOJAUYO2qVLWFcjLdC48a214WHtu8i4mOrfMUxZ9R333yVXYDqnjvoocXdHT4vfTPn9A1AnOTl9FyTgTV4ct3flvw== X-YMail-OSG: lkm_.GoVM1m7hE_EvdrrIvRccCLlXl5dj0hfbv6jgLrfOUldmlS1TIuyg9miVOB CgdhPB8Lu.J.rrCTg3e4OzfOuse5x_NqDqM2RIlbGdTWfhIB.cnOvo5Dm2OAMro6F97WlSyaw0jP osVi5cR9xA1AtO2da.O39wa9BFnsYeVO5u6Gw5cFYQxYM6EgaGiDSxmQJjbkp7zfQer9FCnXjXnf AExdbrgZZb01_V74SJjCxcyiLMlx3ULQ3w8wB2bMa.U01PFKY_K5viw9DWXycrHFsmsekt.AL6uc oIdI2qbIzm2uWejmrfoXhiaqUk852HsKCvBDWrxcoeZZvaVLdl_fxU_Y0K_eEGfF2O7Wu4WXIEy2 oNCaMb9u6M2M1ee98Nu7ilnX5CCjxgfQkfTdA4io1vtLRkpF4m31GtX9VueQFY1Y5tuEme03Q23X MvrasPXAWvX7.e21XM9bvecOyUM._7qutTd7KFxhVcbm28my2UYgtZBWsEFSO9QTnsxnIsJ2OntU LHy8cJd.bMItOUogywxOMmbhf7vTYM7jGaPe3IJva4RC577HVddr8Ue.r0iyGUqu3At0M2Ghl7IY U7qACxI5e13DP9ra4jVcsnO0a6yH6uXg2sHw_xLo9.u63d7dL4x3AD1m8XP9EsOP8RkZWQhHhb7Y uzMRLQ40lTiM05duCY8FfSrQWjtxIHi3CbU.3xqDo1bnPhX2l_pjaaAHxsy1soE8F39.1JP4PJ.7 .jtFR1P3vtKKZ_64xYmCEUx9n.qF1yi04mRJJ2pCB6JOkHIqHYLdoVb3Tj1pjTQRMLMvPmQi5EoU 3Mfe3fwHZCq1YzNoA_zBlnjw696YYRtkEUF6.l_LGvOuDwhCRMuu2hZi.FmNj0IW2ufQ1yqYYCyT hHuGugf_YnoGXi_iMeTg7b6UIeN5qZ7MF2VImS6NfCeE2IKzZNSHtyze4hDuQA39UuXMTbFbbWeF BTz_0NyRCSlz7HQPxocwz0xWJotQbkbXsys5gSolbLRmJ5k7DfvmPH.xi.yA5R.lZ2T8GIJH2F0T fyvoh2Xln_htOoQpRnVQ3F0yJQML0L.6gtmACogeH3qS3X3Q63ytWrEecrKY59AlM4h5j7fDJyz0 1_A9F9ciLkkSxYd_tC1a7d11LWDFNbBlUy60W2LC.S1utF4TiOZISX7YjwXj5mZ0ULyBviA9kkZE Xz4Hwl.J2.4qbgUHMTOL.DFKYWh6gV8eyPRnDjDuEdv4RuQ.1xbg_xCBS_KJ11FLMVX0KdS9JRo7 _MgzWRQsJvJjhiBdHsjHxF4Vl8orddNAv6OZmfFAkzYBKfBkKPuJEvbd_M.sglt2Sy54hgr85Ixs DIFQMuqFKZJgY2xSi6lHiAxx9JzsRg0AvlUn8VLKyR_796UBkp7PrEAxIP4eZ7enzjmaEXwkv1xm 6JcSq3ekyWBr7QowBLcxKeyy12ubKYar15IkThIk_YsN4mBp14cZdIqmBb3tody3hGKgXr8z4kb. nKflTitdod3wsFEZQD5BgjdyaaOJ5mdHp4gKWbqIl_pitQ2dO5MlyACDb0n7OawfzPS5ZDDxf2Ve 7oCPiST42Wm.OWQw3HWxnRYKb__h2Txxn2WEtHoyGWGnyclouV2LBCb5Focbog5SAXoT4itey4wY E43m0tZFnbrFIJsIe9dMn5sfIfizLkJSBTUS_S1KVDpkVCAAUh0PhIzPQwsrt1qlzOECzv5DKydn 09aTOopCino02DqsBkSPbt9ueFa.FNTPLksKbiRxTicGpoEd897ciG_JuSaHXjwQKGkmQ8C6BE11 Zwz955Bh9HCdDmUYFq3GzXv1mDgzcVsU7JKVy0JCWSxRJqOhAL1Tw5u7QaHtmykRM4CD8W1MjzA0 fadzd1HIV_1FXLkvY0FRoBIzJUpok9bC5f.PIfYSasLL8hQfSyWVYd2iXNolcgm5x.EhxT6XaN82 ViTXKt_e_T2ujYHORw4VXK8uLbF2ihaNIv18PAKrdbIXReRlfwyVihTs1Xw1PhMZhcrVvrsmrWB6 aghPZBR59f.tEOJWRg9IJsz_YaQscQarwqJDz1c48iq2ooSUnSi4wxhqmnyAhkV3Y85mAN9gwvue L0cQ1voQIcRURebYzewi_MxTR8JOekEpm7kcuoY0Z25umrWhXZLZjTljggFA6AfXTUt70LAwWYe4 drjxdI6398ubXbvyso6refeE5RVVsj4eEy_xA5BvOMGPF460PHl.KmFWQxbPAQi60YV42KvfoIY6 o292JdSNEMjPkkNtsM2LMZXw6jsTBd.TnEnaPzxyQSKjw.TraTqU47qIjLEQdiXw.IE5Ou.HHX.n oLSbyT5EfBsNvFQ-- X-Sonic-MF: X-Sonic-ID: a575e83c-d104-4b6c-ad10-b834aa0fc90f Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 11:38:15 +0000 Received: by hermes--production-gq1-799bb7c8cf-t9jf4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea6df577ae12922c19a61e70302569e0; Mon, 22 Jul 2024 11:38:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: <3D644314-7F84-4AA8-81A5-DCD29D4ABBC1@yahoo.com> Date: Mon, 22 Jul 2024 04:38:00 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0FD31A4D-DE2C-400A-B6DB-FA3EAB94E374@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> <9E98F6F6-6896-4958-9D88-FF68C4AB57F2@mit.edu> <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> <3D644314-7F84-4AA8-81A5-DCD29D4ABBC1@yahoo.com> To: John F Carr , Konstantin Belousov , Baptiste Daroussin X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.686]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[mit.edu,gmail.com,FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WSJF63scQz4mvn On Jul 21, 2024, at 21:08, Mark Millard wrote: > On Jul 21, 2024, at 20:58, Mark Millard wrote: >=20 >> I found a significant difference in my failing vs. working >> armv7 contexts as installed: Presence vs. Lack of a .symtab >> entry for the symbol _rtld_get_stack_prot in >> /libexec/ld-elf.so.1 . >>=20 >> gdb inspection of operation shows distinctions based on >> the difference. >>=20 >> This is related to the code: >>=20 >> (gdb) list 140 >> 135 void >> 136 _thr_stack_fix_protection(struct pthread *thrd) >> 137 { >> 138=20 >> 139 mprotect((char *)thrd->attr.stackaddr_attr + >> 140 round_up(thrd->attr.guardsize_attr), >> 141 round_up(thrd->attr.stacksize_attr), >> 142 _rtld_get_stack_prot()); >> 143 } >>=20 >>=20 >> Working context (Personal build): >>=20 >> NOTE THE .symtab ENTRY BELOW. It allows the gdb run to work: >>=20 >> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less >> ELF Header: >> Elf file type is DYN (Shared object file) >> Entry point 0x14548 >> There are 10 program headers, starting at offset 52 >> Program Headers: >> There are 24 section headers, starting at offset 0x1f2b8: >> Section Headers: >> Key to Flags: >> Dynamic section at offset 0x199f8 contains 15 entries: >> Relocation section (.rel.dyn): >> r_offset r_info r_type st_value st_name >> Symbol table '.dynsym' contains 27 entries: >> 5: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) >> Symbol table '.symtab' contains 911 entries: >> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot >> Notes at offset 0x00000174 with length 0x00000018: >> Histogram for bucket list length (total of 6 buckets): >> Histogram for bucket list length (total of 27 buckets): >> Version symbol section (.gnu.version): >> Version definition section (.gnu.version_d): >> Attribute Section: aeabi >> File Attributes >>=20 >>=20 >> Breakpoint 8.3, _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 >> 139 mprotect((char *)thrd->attr.stackaddr_attr + >> (gdb) si >> 141 round_up(thrd->attr.stacksize_attr), >> (gdb)=20 >> 140 round_up(thrd->attr.guardsize_attr), >> (gdb)=20 >> round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110b8 129 if (size % _thr_page_size !=3D 0) >> 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 0x201110c0 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 0x201110c4 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:130 >> 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 0x201110c8 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110d0 in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110d4 in round_up (size=3D67108864) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110d8 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110dc in round_up (size=3D4096) at = /usr/main-src/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 0x201110e0 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> _thr_stack_fix_protection (thrd=3D0x2006f000) at = /usr/main-src/lib/libthr/thread/thr_stack.c:139 >> 139 mprotect((char *)thrd->attr.stackaddr_attr + >> (gdb)=20 >> 142 _rtld_get_stack_prot()); >> (gdb)=20 >> 0x20114880 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20114884 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20114888 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >>=20 >> Breakpoint 9.1, _rtld_get_stack_prot () at = /usr/main-src/libexec/rtld-elf/rtld.c:5884 >> 5884 return (stack_prot); >> (gdb)=20 >> 0x2005b9b0 5884 return (stack_prot); >> (gdb)=20 >> 0x2005b9b4 5884 return (stack_prot); >>=20 >>=20 >>=20 >> Failing context (Official PkgBase build): >>=20 >> NOTE THE *LACK OF* THE .symtab ENTRY ABOVE. >=20 > Not "ABOVE": BELOW! Sorry. >=20 >> _rtld_bind_start ends >> up in use instead, which looks to lead to the gdb run not working. >>=20 >> IN FACT, NOTE THE LACK OF ANY "Symbol table '.symtab' contains" >> TEXT AT ALL! >>=20 >> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" | less >> ELF Header: >> Elf file type is DYN (Shared object file) >> Entry point 0x147b0 >> There are 10 program headers, starting at offset 52 >> Program Headers: >> There are 22 section headers, starting at offset 0x1a960: >> Section Headers: >> Key to Flags: >> Dynamic section at offset 0x1a4cc contains 15 entries: >> Relocation section (.rel.dyn): >> r_offset r_info r_type st_value st_name >> Symbol table '.dynsym' contains 27 entries: >> 5: 000000000001bcd8 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) >> Notes at offset 0x00000174 with length 0x00000018: >> Histogram for bucket list length (total of 6 buckets): >> Histogram for bucket list length (total of 27 buckets): >> Version symbol section (.gnu.version): >> Version definition section (.gnu.version_d): >> Attribute Section: aeabi >> File Attributes >>=20 >>=20 >> Breakpoint 2.3, _thr_stack_fix_protection (thrd=3D0x20070000) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:140 >> 140 round_up(thrd->attr.guardsize_attr), >> (gdb) si >> 139 mprotect((char *)thrd->attr.stackaddr_attr + >> (gdb)=20 >> 141 round_up(thrd->attr.stacksize_attr), >> (gdb)=20 >> round_up (size=3D4096) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_stack.c:129 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 129 if (size % _thr_page_size !=3D 0) >> (gdb)=20 >> 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 0x20112ef8 130 size =3D ((size / _thr_page_size) + 1) * >> (gdb)=20 >> 0x20116b60 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20116b64 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20116b68 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20116760 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20116764 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x20116768 in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> 0x2011676c in ?? () from /lib/libthr.so.3 >> (gdb)=20 >> _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:78 >> 78 stmdb sp!,{r0-r5,sl,fp} >> (gdb) si >> 80 sub r1, ip, lr /* r1 =3D 4 * (n + 1) */ >> (gdb)=20 >> 81 sub r1, r1, #4 /* r1 =3D 4 * n */ >> (gdb)=20 >> 82 add r1, r1, r1 /* r1 =3D 8 * n */ >> (gdb)=20 >> 84 ldr r0, [lr, #-4] /* get obj ptr from GOT[1] */ >> (gdb)=20 >> 85 mov r4, ip /* save GOT location */ >> (gdb)=20 >> 87 mov r5, sp /* Save the stack pointer */ >> (gdb)=20 >> 88 bic sp, sp, #7 /* Align the stack pointer */ >> (gdb)=20 >> _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 >> 89 bl _rtld_bind /* Call the binder */ >>=20 >>=20 >> I have not checked for other .symtab entry problems. >>=20 >> Nor have I figured out why the installed materials are >> different for Symbol table '.symtab' . So this is not >> yet root-cause information. I know why. My personal FreeBSD builds have long had my equivalents of src.conf (under normal naming) contain: # # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+=3D This likely replaces my earlier -mcpu=3Dcortex-a7 hypothesis for what a systematic difference might be that could contribute to the personal builds not having the problem. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 11:46:53 2024 X-Original-To: freebsd-current@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 4WSJRH10X8z5QWTW for ; Mon, 22 Jul 2024 11:47:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSJRG5fqyz4prG for ; Mon, 22 Jul 2024 11:47:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721648825; bh=63EJltZVAmmkhkxbye5xV802hwYGfmel046wCZhkO24=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=n4/T3vV9szYXDWox2p3k8JTc7DEM65p/BN6Zh/8KlAbjWQCzZWCMHDL0VU9Rz0AbHQaRHR6rGf+DU54JFshD6f9KoaGr0HueH9Fcu0ysGdOlMP2ox9nIkuSBzzrMXxuKRNp5IbQnU7cDqZMsTXJ2ROgB6hJ9Sbr54ZYBfz9WO3g62v2YxSrBkkay6mmz90FCHzQLHZtcYqHhTsC53fh1XzvX8ughN/JK6GtdGLQiMmSVFRpDv3U8Cm05K7bhO9hguBkWjIbHcjU4w8SOwPdDLbqaO7DctG+mWPGiPmlufXkXAMma/nENuInL3MShnw5Yp/xSyLFE4kSe0V9MNTfUNA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721648825; bh=IcOiakDHE49WCRDeiLps3GXTZCxdIDijH1cIm/7zqwX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DNuthLb5n5elXnkm9i0d336XkZsTKjNR1dVDAJswwVtTDlnrsCiH91wd3Y7S50ft/JPWovwDto54yRuztQBY4XaoBHzoF3AkmNdtlGWgPvG7hTUIstwszjHws/+B2nl63dSI+uKfMvqL6dan0htNg4cXgy7EOQ7pjV/FRI31OrM4/ieD9Rt66Rr8JvuI4Eih84I1jiS+CStQKAtF96Oi2phnCOlJwjeOuRdDlavb6+g6VKuY3utgeMl1Tab8mx4ldSildUR5w5q32bq+zDd+73TMZ75Qsq9UHB8cLLaFrjfZGsHceXiqRRIhOQZ63mneqR8QA5o/W67Sfs8JX7FmfA== X-YMail-OSG: _4.QQBAVM1koycDZZhKzdi85wCd4DmNTUfTF74Np4EHFEPFZFG51GSzv23r6SNT eiaI2IqU0NDemGEZNLw6oz2NUqBQjixErmmEK1awNFcuZSKW6i4QcQltt8hNAU_ixKKozS16Q0nV v4_5d0OTNsJQYKZOkw2mASbQXMCnOxKeFCj_evbamApUQG5ZbiX_etxAaFPG9oEas0wb1CelqcvT 3r4RZNHvDIica3YBUivcYWSHc8XV_blmyVa2gjK.K99P.MInecQrW8ctmmkgnqpYmeOc.fh_7qYi bFVsZvbzrLrOil98nhy_kNYjQEDc5tmcxWyCPI.ZWtmLsMoUkc5NFkt9jmJPki8V07Yb_rZvl25k g63QLq3N0fu1nGcxUx08anM.6vQnhKUe72Vb4SVPvQYIEibxyIdsLEJImPuWS7VxJW4ejx7GKjkq wUAftO1N0qAQc64i2yA3Tq6gXcH69PvDnzAwWBhtmUnKGb0RnEQ_M.w3jbMgUs86YmcCRTg9D_04 hQpxGK7EH4Yi.ryAlt_D2lYkOTqHLpnDmwqrudAcQzD_27_hw7dXpXw.LKjDVvq7doqupSyaUCuC iejOIHA5vjlTXLneO5Q3uOutEgar6f_2dXH8KfBgHIgEKLOby2.aMYSWkPKQefOa3FzOYXHnVjDa a8gIltv4ZxLCL0YhWSI8Bnkqp8kzAknN9eQe214Uef...XYNjhm8cSVG..gsHUlNo5TH89rBi6ji TC3HSMdVGCEiv6syZuxEAoQfNV87zRos2ZQ4aBOE53XqY9nss272YKoB.MDYwODbcG8J.F1EP5t3 Qt0kGVbu_YFn4GFeeB.T60xe1tsbGr1dDilG_Z1hrmqetMBFX5TSTXV4qi1zS6xa2nMaBHNIYo.e mkbxhVDTzyaNPxJSIxYGzvA.hL0g0aKlEfbJV6ysmbREFMLT6rDGjETM.zFWgDjm6FKOoStFZGme NEAU6Is8GyDVIyNz90MasBbkj6SUIH7tzYFHWmvVfQOMjjy8e.EQ2Fdps1JSCaAC3IKTcJnM.rdf 86S22IGqR1MLYnFEdH2UUseCOYxDPgmdEzQxTfyPYDVKDD.QilNx_PnHYLo45WhCHLWm_1Tlmx8S rFa4896mpBGzXI8fEe1_EcJzqgdMqXGAlFeJQ8mebfSVG7mog8WZ0nLTTOLz7LCnglx.Obr3Sg3F sKX0VZ60Ym0wtZ8OxDn1DWFh.zrvwtxvw3n5R8gt2Y8p.l2UYLQ9B76Xh5px_XevWi5.SpmO3svM o1ZmOcnsBuizEVb6TeGiUxZieHXboEjixCijl6gAmPv8QaOSSwqPT_M8L9gzVVTM9Yrdv8rqnd61 7GJ3yE_JGd5lJydo657gu.b8_BdQS3i7lvc53TwlJ5W.KP2ZrfjTGz06iFIZxgejAQEzsDXvpF1k qzqFdtdBsX4NKTeByaLRQXtmb_iR61RMYlqPGLfTZg3FVDoLqf30ZNK2gQkg8r.n.YBiov7udEBZ t3zw9Sy4TQCr7UMCWiKOb_m7BNWhuzgc__1EUQBbhCkkK7k7_9ZpsfZNZbmnPlbOiFRltmnAuQY5 PcElDLNfy5NBBdD5Mee6x3jNE1v6Z4iAWhG.HWaaWYXWQ0z9AdWgIkT3HSpdvVpsINL5LpwEi6jO hQqLO9d4e1y3Nkha_2XbWeLEBiCzwpocfS.k2ovd4Vc77sXnsDf_XGBKVL3a8Pp37DxKf5qqnZiZ S_XZftxmEfdFAaJOI3JRbdOaxi5Rd2xExBtAeOpxnHKOjsZzZTDTMdXDCBq3HFbDpbScclJQS98X k2jSbsVhjc.fHaf4_CVk8aTl5_X1rolkwFuk8QxtV_BYYc.QKME2vWuYc4AQ_YASuatVUcP5C33E P255jJjzT3bYF1jbT3uauz9nuJ0pTCcEGe5m4Hszw1umz6QvIG6XK_ravK_iSOmyKVjLvRclZUrz ycBuofEP2AFOPcy_t8FEjiBvfKgqTr4YZT9NRPUQRJ1VQPz1Q5f0ERUkyItkidkrK8CsDJgGA4xW TqzNJEf6B_PStf_ZYI_2_FKO2ylTS6fi6MdBZbHL23_s_.zslZxtg3B_YvXfpXoI6mj_g2lZYm6H uBSXYxzUUbIvt22jwWiyvM1KcXCVMwCilh_E7SUIy1G9Zv4lgPJN8Tm0aj4a_ylMcnqixnx3nfZA bLIa_SzVvnkAcJyuPakT9mwX0nMTWScripBVEgwq5rch.2Hv.qu0F1LigHJzIQ3AS2eFm_Qo_wva gldn2wzfuOSK4v5fSKAhHOWp8XWWsBYnQhRnYXiYLNyD2o5tQt0wPWTVZbfXVCPHUJ5oF6MAJm2w c5_I- X-Sonic-MF: X-Sonic-ID: 0d093491-3307-465f-8baa-7c5f1950cdc2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 11:47:05 +0000 Received: by hermes--production-gq1-799bb7c8cf-cvhk6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 00c4f873f014e2e036bea220e4a23d2a; Mon, 22 Jul 2024 11:47:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck From: Mark Millard In-Reply-To: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> Date: Mon, 22 Jul 2024 04:46:53 -0700 Cc: FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" Content-Transfer-Encoding: quoted-printable Message-Id: References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WSJRG5fqyz4prG On Jul 21, 2024, at 22:59, Michal Meloun = wrote: > I don't want to hijack the original thread, so I'm replying in a new = one. >=20 > My tegra track current, has been running 24/7 by building kernel/world = and kde5 in a loop for a few years now. But I have never encountered the = aforementioned lockup in native armv7. >=20 > I have seen usermode mutex lockup in arm32 jail on aarch64, but only = very rarely (once a month or so) and all my attempts to reproduce it in = a more deterministic way have failed. Also, I don't think I've ever seen = this with the debug version of libc. >=20 > Unfortunately I also failed to reproduce given lockup using = dlopen_test.c, neither on native armv7 or arm32 jail. >=20 > Michal Meloun What is the output of: # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" in your armv7 context(s)? Does it include for likes of: QUOTE Symbol table '.symtab' contains 911 entries: 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot END QUOTE vs. not? Note that the "debug version of libc" being involved likely means that DEBUG_FLAGS was defined. That in turn likely means that strip is not being used. In such a case, I expect that the .symtab entry for _rtld_get_stack_prot (and more) exists for such a context. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 16:02:46 2024 X-Original-To: freebsd-current@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 4WSQ6R5g0dz5RBFx for ; Mon, 22 Jul 2024 16:02:55 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSQ6R2m7lz41wg for ; Mon, 22 Jul 2024 16:02:55 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1721664172; x=1721923372; bh=pZMBBHCasA+jVdtd3pZaJXK7RelxYBZmb2gvNkdZUNs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Bkh2nFHqYI69knnTHoIBlaKg9w5Rg4OHCFqHw0TJgHEohcbP5U2BmWNiXOKyam9v/ ORIk3PN+z0p6Ms2vQw9yPNFofLwt4lfdo1S4zhsfASPbgcj5ia0Eb4VweH33D1OIIV NLKpGf53m2qkAlHDS64lS6+kdcdGYcuuzMZLQgqJboaiHWNutZ1rB/AUbJIXPGu8KE 5mW/ExJkyMso8ArqyjJDm6H6Sc984PS45WPuxCjMa+AF6yvPR6c1bcjm45bRtql1LO 9R3VlV6/TrX8o9ArTkf85uieuZ+V6cVJOwOgcvvkd34XXTHM733mhPKMfk199yTCsc mOAm4CCymokNA== Date: Mon, 22 Jul 2024 16:02:46 +0000 To: Warner Losh From: Minsoo Choo Cc: cglogic , FreeBSD CURRENT Subject: Re: Long time outdated jemalloc Message-ID: In-Reply-To: References: Feedback-ID: 45891198:user:proton X-Pm-Message-ID: b44aa0d59ad3ca6ef0b479a5c0abb2f9e4f75cd2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_2CN0eIvAXtmDNhcURyNl2gaNqbZyxUM7UUypAEujAQ" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Queue-Id: 4WSQ6R2m7lz41wg This is a multi-part message in MIME format. --b1_2CN0eIvAXtmDNhcURyNl2gaNqbZyxUM7UUypAEujAQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Rmlyc3QsIHNvcnJ5IGZvciBsYXRlIHJlc3BvbnNlLgoKY2dsb2dpYywgdGhhbmsgeW91IGZvciBi cmluZ2luZyB1cCB0aGlzIGlzc3VlIGFnYWluIHNpbmNlIEkgbmVhcmx5IGZvcmdvdCB0aGF0IHRo aXMgaXNzdWUgd2FzIHN0aWxsIG9wZW4uCgpXYXJuZXIsIGFzIEkgY2FuJ3QgYWNjZXNzIHRvIG15 IEZyZWVCU0QgaW5zdGFuY2UgdW50aWwgdGhlIGVuZCBvZiBBdWd1c3QsIGJ1dCBJIGNhbiBzdGls bCBlZGl0IGFuZCBwdXNoIHRoZSBjb2RlIHRocm91Z2ggbXkgQXJtIE1hYy4gVGhpcyBtZWFucyB0 aGF0IEkgY2FuJ3QgdGVzdCB0aGUgdXBkYXRlZCBjb2RlIG9uIG15IG1hY2hpbmUsIGJ1dCBJIGNh biBqb2luIHRoZSByZXZpZXcgcHJvY2VzcyBhbmQgbGlzdGVuIHRvIGNoYW5nZSBwcm9wb3NhbHMu CgpJJ2xsIG9wZW4gYSBHaXRodWIgUFIgaW4gYSBmZXcgaG91cnMuIChUaGUgcGhhYnJpY2F0b3Ig cmV2aWV3IHdpbGwgc3RheSBvcGVuZWQganVzdCBpbiBjYXNlKQpPbiBNb25kYXksIEp1bHkgMjJu ZCwgMjAyNCBhdCA1OjA4IEFNLCBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+IHdyb3RlOgoK PiBPbiBTdW4sIEp1bCAyMSwgMjAyNCBhdCAyOjAz4oCvUE0gY2dsb2dpYyA8Y2dsb2dpY0Bwcm90 b25tYWlsLmNvbT4gd3JvdGU6Cj4KPj4gT24gU3VuZGF5LCBKdWx5IDIxc3QsIDIwMjQgYXQgNjo1 NCBBTSwgV2FybmVyIExvc2ggPGltcEBic2RpbXAuY29tPiB3cm90ZToKPj4KPj4+IE9uIFNhdCwg SnVsIDIwLCAyMDI0IGF0IDE6NTnigK9BTSBjZ2xvZ2ljIDxjZ2xvZ2ljQHByb3Rvbm1haWwuY29t PiB3cm90ZToKPj4+Cj4+Pj4gSGVsbG8gRnJlZUJTRCBjb21tdW5pdHksCj4+Pj4KPj4+PiBBZnRl ciBKYXNvbiBFdmFucyBzdGVwcGVkIGFzaWRlIGZyb20gbWFpbnRhaW5pbmcgamVtYWxsb2MgaW4g RnJlZUJTRCwgaXQncyBub3QgdXBkYXRpbmcgaW4gdGltZSBhbnltb3JlLgo+Pj4+IFZlcnNpb24g NS4zLjAgd2FzIHJlbGVhc2VkIE1heSA2LCAyMDIyIGFuZCBGcmVlQlNEIHN0aWxsIG5vdCBpbXBv cnRlZCBpdCBpbnRvIHRoZSB0cmVlLgo+Pj4+Cj4+Pj4gVGhlcmUgaXMgYSBwZW5kaW5nIHJldmll dyBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDQxNDIxIGZyb20gQXVnIDExLCAyMDIzLgo+ Pj4+IEknbSBzdWNjZXNzZnVsbHkgcnVubmluZyBGcmVlQlNEL2FtZDY0IHN5c3RlbSB3aXRoIEQ0 MTQyMSBhcHBsaWVkIGZvciA4IG1vbnRocywgYXMgd2VsbCBhcyBtYW55IG90aGVyIHBlb3BsZS4K Pj4+Pgo+Pj4+IENhbiBpdCBiZSByZXZpZXdlZCBhbmQgY29tbWl0dGVkIHRvIENVUlJFTlQ/Cj4+ Pj4gT3IsIGlmIHRoZXJlIGlzIG5vIGNvbW1pdHRlcnMgd2lsbGluZyB0byBkbyBpdCwgY2FuIGNv bW1pdCBiaXQgYmUgZ2l2ZW4gdG8gc3VibWl0dGVyIG9yIGFub3RoZXIgcGVyc29uIHdpbGxpbmcg dG8gZG8gdGhpcz8KPj4+Pgo+Pj4+IEl0J3MgdmVyeSBkaXNhcHBvaW50aW5nIHdoZW4gdXNlcnMg c3BlbmQgdGhlaXIgdGltZSB0byBmaWxsIHN1Y2ggZ2FwcyBhbmQgdGhlaXIgZWZmb3J0cyBqdXN0 IGlnbm9yZWQgYnkgdGhlIGRldmVsb3BlcnMuCj4+Pj4KPj4+PiBFdmVyeSB5ZWFyIEZyZWVCU0Qg Q29tbXVuaXR5IFN1cnZleSBhc2tpbmcgYWJvdXQgdXNlciBleHBlcmllbmNlIGluIGNvbnRyaWJ1 dGluZyB0byBGcmVlQlNELgo+Pj4+Cj4+Pj4gSGVyZSB5b3UgY2FuIHNlZSBhbiBleGFtcGxlIG9m IHN1Y2ggY29udHJpYnV0aW5nLgo+Pj4KPj4+IEZpcnN0LCB0aGFuayB5b3UgZm9yIGJlaW5nIHBl cnNpc3RlbnQgYW5kIGNvbnRpbnVpbmcgdG8gYnJpbmcgaXQgdXAuIEl0J3MgaW1wb3J0YW50IHRv IGRvIHRoYXQgdG8gbWFrZSBzdXJlIHRoaXMgKGFuZCB5b3VyIG1hbnkgb3RoZXIpIGNvbnRyaWJ1 dGlvbiBkb2Vzbid0IGZhbGwgb24gdGhlIGZsb29yLgo+Pj4KPj4+IEFuZCB0byBiZSBmYWlyLCB3 ZSdyZSBvbmx5IDMgbW9udGhzIHNpbmNlIHRoZSBsYXN0IHVwZGF0ZS4gU3RpbGwsIHF1aXRlIGEg Yml0IGxvbmdlciB0aGFuIHlvdSBzaG91bGQgaGF2ZSB0byB3YWl0LCBidXQgbm90IG5lYXJseSB0 aGUgeWVhciB0aGUgb3JpZ2luYWwgZGF0ZSBzdWdnZXN0cy4KPj4+Cj4+PiBBbmQgdGhpcyBpcyBh IHBlcmZlY3Qgc3Rvcm0gb2YgImhvdyB0aGUgcHJvamVjdCBpcyBiYWQgYXQgYWNjZXB0aW5nIGNv bnRyaWJ1dGlvbnMiOgo+Pj4gKDEpIFRoZSBvcmlnaW5hbCBzdWJtaXNzaW9uIHdhcyBjbG9zZSB0 byB0aGUgMTQgYnJhbmNoIGNyZWF0aW9uIHRpbWUuIFRoaXMgbWVhbnQgdGhhdCB3ZSB3ZXJlbid0 IHdlbGwgcHJlcGFyZWQgdG8gbG9vayBhdCBpdCBzaW5jZSBpdCBpcyBzdWNoIGFuIGludmFzaXZl IGNoYW5nZSAoYXQgbGVhc3Qgb24gaXRzIHN1cmZhY2UpLiBJdCBhbHNvIHNsb3dlZCB0aGUgaW5p dGlhbCByZXNwb25zZS4uLgo+Pj4gKDIpIFRoZXJlIHdhcyBhIG51bWJlciBvZiBiYWNrIGFuZCBm b3J0aCByZXF1ZXN0cyBmb3IgY2hhbmdlcywgd2hpY2ggdG9vayB0aW1lIHRvIHNvcnQgb3V0Li4u Cj4+PiAoMykgVGhlIHNpemUgb2YgdGhpcyBpcyBodWdlLCB3ZWxsIGJleW9uZCB0aGUgY2FwYWNp dHkgb2YgUGhhYnJpY2F0b3IgdG8gcmV2aWV3IGFjY3VyYXRlbHkuLi4KPj4+ICg0KSBJdCdzIGEg dmVuZG9yIGltcG9ydC4gVGhhdCBtZWFucyB3ZSBjYW4ndCBqdXN0IGRyb3AgdGhlIFBoYWJyaWNh dG9yIHJldmlldyBpbnRvIHRoZSB0cmVlLi4uCj4+PiAoNSkgSXQncyBwaGFicmljYXRvcjogdGhp cyBpcyBhIGdyZWF0IHRvb2wgZm9yIGRldmVsb3BlcnMsIGJ1dCB3ZSBoYXZlIGEgdGVycmlibGUg dHJhY2sgcmVjb3JkIG9mIHVzaW5nIGl0IGZvciBpbnRha2UgZnJvbSBuZXcgY29udHJpYnV0b3Jz LiBXZSBkb24ndCBoYXZlIGFueSBvdmVyc2lnaHQgYXQgYWxsIG92ZXIgdGhpcyB0b29sLCBhdCB0 aGVyZSdzIGF0IGJlc3QgdGVwaWQgYW5kIGx1a2Ugd2FybSBhdHRlbXB0cyB0byBsb29rIGZvciBk cm9wIGJhbGxzLgo+Pj4KPj4+IEFsbCBvZiB0aGVzZSB0aGluZ3MgYXJlIGEgdGVycmlibGUgZXhw ZXJpZW5jZS4gSSBjYW4gb25seSBhcG9sb2dpemUuIFRoZXNlIGRheXMsIHdlIG1pZ2h0IHN0ZWVy IHRoaXMgdG93YXJkcyBnaXRodWIsIGJ1dCB0aGUgJ3ZlbmRvciBpbXBvcnQnIG1lYW5zIHlvdSBy ZWFsbHkgbmVlZCBzb21lb25lIG9uIHRoZSBpbnNpZGUsIG9yIHlvdSBuZWVkIHRvIGJlIG9uIHRo ZSBpbnNpZGUgdG8gbWFrZSB0aGF0IHdvcmsuCj4+Pgo+Pj4gU28sIGhvdyB0byBtb3ZlIGZvcndh cmQ/IFdlbGwsIEknZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoKPj4+ICgxKSBzdWJt aXQgYWxsIHRoZSBvdGhlciBQaGFicmljYXRvciByZXZpZXdzIHlvdSBoYXZlIG9wZW4gKHRoZXkg YXJlIG1vc3RseSBnb29kLCBvciBjbG9zZSB0byBnb29kKSB0byBnaXRodWIuIEdpdGh1YiBpcyBi ZWluZyBhY3RpdmVseSBtYW5hZ2VkIGFuZCB3aWxsIG1ha2UgaXQgZmFzdGVyIHRvIGdldCB0aGlu Z3MgaXQuIEl0J3MgYSBtdWNoIGJldHRlciB0b29sIGZvciBuZXcgY29udHJpYnV0b3JzIChhbmQg ZXZlbiBmcmVxdWVudCBjb250cmlidXRvcnMgb2Ygc21hbGxpc2ggdGhpbmdzKS4KPj4+ICgyKSBJ IHNob3VsZCBkbyBhbiB2ZW5kb3IgaW1wb3J0IG9mIDUuMy4wIGZyb20gZ2l0aHViLCBhbmQgZG8g dGhlIG1lcmdlIHRvIGEgYnJhbmNoIGFuZCBwdXNoIHRoYXQgdG8gZ2l0aHViLiBZb3UgY2FuIHRo ZW4gbGF5ZXIgb24geW91ciBjaGFuZ2VzIGFuZCB0aG9zZSBjYW4gYmUgcmV2aWV3ZWQgbW9yZSBj bG9zZWx5IGFzIGEgcHVsbCByZXF1ZXN0IGFnYWluc3QgdGhlIGJyYW5jaCBJIHB1c2guIEkgc3Vz cGVjdCB0aGF0IG1vc3Qgb2YgdGhlIGlzc3VlcyBhcmUgc29ydGVkIG91dCBhbHJlYWR5Cj4+PiAo MykgSSdsbCBsYW5kIGl0IHZpYSB0aGF0IHJvdXRlLi4uCj4+Pgo+Pj4gQW5kLCBpZiB0aGUgc3Vt IG9mIHRoZSBvdGhlciBwdWxsIHJlcXVlc3RzIGFuZCB0aGlzIGFyZSBnb29kIChhbmQgSSBzdXNw ZWN0IHRoZXkgd2lsbCBiZSksIHRoZW4gd2UgY2FuIHRhbGsgYWJvdXQgY29tbWl0IGJpdHMgYW5k IHN1Y2guCj4+Pgo+Pj4gSXQncyBleHBlcmllbmNlcyBsaWtlIHRoaXMgd2hpY2ggaXMgd2h5IEkn bSB0cnlpbmcgdG8gc3RhbmQgdXAgZ2l0aHViIHB1bGwgcmVxdWVzdHMgYXMgYSByZWxpYWJsZSB3 YXkgdG8gZ2V0IHRoaW5ncyBhbmQgYW5kIHRoZSBiZXN0IHBsYWNlIHRvIHNlbmQgcGVvcGxlLi4u Cj4+Pgo+Pj4gVGhhbmtzIGFnYWluIGZvciBwZXJzaXN0aW5nLCBhbmQgYWxzbyBmb3IgZXhwcmVz c2luZyB0aGlzIGNyaXRpY2lzbSB0aGF0IHdlIChob3BlZnVsbHkpIGNhbiB1c2UgdG8gbWFrZSBp dCBiZXR0ZXIuCj4+Pgo+Pj4gV2FybmVyCj4+Cj4+IEhlbGxvLgo+Pgo+PiBJJ20gbm90IHRoZSBh dXRob3Igb2YgRDQxNDIxLiBKdXN0IGFwcGxpZWQgdGhlIHBhdGNoIHRvIHRlc3QgaXQgOCBtb250 aHMgYWdvLiBBbmQgcmVjZW50bHkgZGlzY292ZXJlZCB0aGF0IGl0J3Mgc3RpbGwgbm90IGNvbW1p dHRlZC4KPj4gSSBjYW4ndCBjb3B5IHlvdXIgbWVzc2FnZSB0byBQaGFicmljYXRvciBiZWNhdXNl IGRvbid0IGhhdmUgYW4gYWNjb3VudC4gUGxlYXNlLCBpZiB5b3UgaGF2ZSB0aW1lLCBoZWxwIHRo ZSBhdXRob3IgaW4gRDQxNDIxLgo+Cj4gQWggeWVzLiBJJ3ZlIGJlZW4gaW4gdG91Y2ggd2l0aCB0 aGUgYXV0aG9yIGZvciBvdGhlciB0aGluZ3MsIGFuZCBzb21laG93IHRob3VnaHQgaXQgd2FzIHlv dS4uLi4gSSdsbCByZWFjaCBvdXQgdG8gaGltIHZpYSBvdGhlciBtZWFucy4uLgo+Cj4gV2FybmVy --b1_2CN0eIvAXtmDNhcURyNl2gaNqbZyxUM7UUypAEujAQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5GaXJzdCwgc29ycnkgZm9yIGxhdGUgcmVzcG9uc2UuPC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5jZ2xvZ2ljLCB0aGFuayB5b3UgZm9yIGJyaW5naW5nIHVwIHRoaXMgaXNzdWUgYWdhaW4g c2luY2UgSSBuZWFybHkgZm9yZ290IHRoYXQgdGhpcyBpc3N1ZSB3YXMgc3RpbGwgb3Blbi48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPldhcm5lciwgYXMgSSBjYW4ndCBhY2Nlc3MgdG8gbXkgRnJl ZUJTRCBpbnN0YW5jZSB1bnRpbCB0aGUgZW5kIG9mIEF1Z3VzdCwgYnV0IEkgY2FuIHN0aWxsIGVk aXQgYW5kIHB1c2ggdGhlIGNvZGUgdGhyb3VnaCBteSBBcm0gTWFjLiBUaGlzIG1lYW5zIHRoYXQg SSBjYW4ndCB0ZXN0IHRoZSB1cGRhdGVkIGNvZGUgb24gbXkgbWFjaGluZSwgYnV0IEkgY2FuIGpv aW4gdGhlIHJldmlldyBwcm9jZXNzIGFuZCBsaXN0ZW4gdG8gY2hhbmdlIHByb3Bvc2Fscy48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPkknbGwgb3BlbiBhIEdpdGh1YiBQUiBpbiBhIGZldyBob3Vy cy4gKFRoZSBwaGFicmljYXRvciByZXZpZXcgd2lsbCBzdGF5IG9wZW5lZCBqdXN0IGluIGNhc2Up PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSI+DQogICAgICAgIE9uIE1vbmRheSwg SnVseSAyMm5kLCAyMDI0IGF0IDU6MDggQU0sIFdhcm5lciBMb3NoICZsdDtpbXBAYnNkaW1wLmNv bSZndDsgd3JvdGU6PGJyPg0KICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9x dW90ZSIgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj48ZGl2IGRpcj0i bHRyIj48YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGNsYXNzPSJn bWFpbF9hdHRyIiBkaXI9Imx0ciI+T24gU3VuLCBKdWwgMjEsIDIwMjQgYXQgMjowM+KAr1BNIGNn bG9naWMgJmx0OzxhIGhyZWY9Im1haWx0bzpjZ2xvZ2ljQHByb3Rvbm1haWwuY29tIiByZWw9Im5v cmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIj5jZ2xvZ2ljQHByb3Rv bm1haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIw NCk7cGFkZGluZy1sZWZ0OjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij48YnI+PC9kaXY+PGRpdj4N CiAgICAgICAgT24gU3VuZGF5LCBKdWx5IDIxc3QsIDIwMjQgYXQgNjo1NCBBTSwgV2FybmVyIExv c2ggJmx0OzxhIHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86aW1wQGJzZGltcC5jb20iIHJl bD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+aW1wQGJzZGltcC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAg PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGJyPjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+PGRpdiBjbGFzcz0iZ21haWxfYXR0ciIgZGlyPSJsdHIiPk9uIFNhdCwgSnVs IDIwLCAyMDI0IGF0IDE6NTnigK9BTSBjZ2xvZ2ljICZsdDs8YSB0YXJnZXQ9Il9ibGFuayIgaHJl Zj0ibWFpbHRvOmNnbG9naWNAcHJvdG9ubWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxv dyBub29wZW5lciI+Y2dsb2dpY0Bwcm90b25tYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rp dj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFp bF9xdW90ZSI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNp emU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1 KSI+SGVsbG8gRnJlZUJTRCBjb21tdW5pdHksPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxzcGFuIHN0eWxlPSJkaXNwbGF5OmlubGlu ZTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPkFmdGVyIDwvc3Bhbj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj5KYXNvbiBFdmFucyBzdGVw cGVkIGFzaWRlIGZyb20gbWFpbnRhaW5pbmcgamVtYWxsb2MgaW4gRnJlZUJTRCwgaXQncyBub3Qg dXBkYXRpbmcgaW4gdGltZSBhbnltb3JlLjwvc3Bhbj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCwwLDAp O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+VmVyc2lvbiA1LjMuMCB3YXMgcmVs ZWFzZWQgPHNwYW4+TWF5IDYsIDIwMjIgYW5kIEZyZWVCU0Qgc3RpbGwgbm90IGltcG9ydGVkIGl0 IGludG8gdGhlIHRyZWUuPC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFs LHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNTUsMjU1LDI1NSkiPjxzcGFuPjxicj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCww LDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+VGhlcmUgaXMgYSBwZW5kaW5n IHJldmlldyA8c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly9yZXZpZXdzLmZy ZWVic2Qub3JnL0Q0MTQyMSIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIj5odHRw czovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDQxNDIxPC9hPiBmcm9tIDxzcGFuPkF1ZyAxMSwgMjAy My48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMt c2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPjxzcGFuPjxzcGFuPkknbSBzdWNjZXNzZnVsbHkgcnVubmluZyBGcmVl QlNEL2FtZDY0IHN5c3RlbSB3aXRoIEQ0MTQyMSBhcHBsaWVkIGZvciA4IG1vbnRocywgYXMgd2Vs bCBhcyBtYW55IG90aGVyIHBlb3BsZS48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCww KTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxzcGFuPjxzcGFuPjxicj48L3Nw YW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUs MjU1LDI1NSkiPjxzcGFuPjxzcGFuPkNhbiBpdCBiZSByZXZpZXdlZCBhbmQgY29tbWl0dGVkIHRv IENVUlJFTlQ/PC9zcGFuPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlh bCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1j b2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48c3Bhbj48c3Bhbj5PciwgaWYgdGhlcmUgaXMgbm8gY29t bWl0dGVycyB3aWxsaW5nIHRvIGRvIGl0LCBjYW4gY29tbWl0IGJpdCBiZSBnaXZlbiB0byBzdWJt aXR0ZXIgb3IgYW5vdGhlciBwZXJzb24gd2lsbGluZyB0byBkbyB0aGlzPzwvc3Bhbj48L3NwYW4+ PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6 MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+ PHNwYW4+PHNwYW4+PGJyPjwvc3Bhbj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+PHNwYW4+PHNwYW4+PHNwYW4+SXQncyB2ZXJ5 IGRpc2FwcG9pbnRpbmcgd2hlbiB1c2VycyBzcGVuZCB0aGVpciB0aW1lIHRvIGZpbGwgc3VjaCBn YXBzIGFuZCB0aGVpciBlZmZvcnRzIGp1c3QgaWdub3JlZCBieSB0aGUgZGV2ZWxvcGVycy48L3Nw YW4+PGJyPjwvc3Bhbj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWws c2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29s b3I6cmdiKDI1NSwyNTUsMjU1KSI+PHNwYW4+PHNwYW4+PHNwYW4+PHNwYW4+RXZlcnkgeWVhciBG cmVlQlNEIENvbW11bml0eSBTdXJ2ZXkgYXNraW5nIGFib3V0IHVzZXIgZXhwZXJpZW5jZSBpbiBj b250cmlidXRpbmcgdG8gRnJlZUJTRC4gPC9zcGFuPjxicj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTox NHB4O2NvbG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48 c3Bhbj48c3Bhbj48c3Bhbj48c3Bhbj5IZXJlIHlvdSBjYW4gc2VlIGFuIGV4YW1wbGUgb2Ygc3Vj aCBjb250cmlidXRpbmcuPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdi KDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxzcGFuPjxzcGFuPjxz cGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFy aWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5k LWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxzcGFuPjxicj48L3NwYW4+PC9kaXY+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+Rmlyc3QsIHRoYW5rIHlvdSBmb3IgYmVpbmcgcGVyc2lz dGVudCBhbmQgY29udGludWluZyB0byBicmluZyBpdCB1cC4gSXQncyBpbXBvcnRhbnQgdG8gZG8g dGhhdCB0byBtYWtlIHN1cmUgdGhpcyAoYW5kIHlvdXIgbWFueSBvdGhlcikgY29udHJpYnV0aW9u IGRvZXNuJ3QgZmFsbCBvbiB0aGUgZmxvb3IuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ QW5kIHRvIGJlIGZhaXIsIHdlJ3JlIG9ubHkgMyBtb250aHMgc2luY2UgdGhlIGxhc3QgdXBkYXRl LiBTdGlsbCwgcXVpdGUgYSBiaXQgbG9uZ2VyIHRoYW4geW91IHNob3VsZCBoYXZlIHRvIHdhaXQs IGJ1dCBub3QgbmVhcmx5IHRoZSB5ZWFyIHRoZSBvcmlnaW5hbCBkYXRlIHN1Z2dlc3RzLjxicj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFuZCB0aGlzIGlzIGEgcGVyZmVjdCBzdG9ybSBvZiAi aG93IHRoZSBwcm9qZWN0IGlzIGJhZCBhdCBhY2NlcHRpbmcgY29udHJpYnV0aW9ucyI6PC9kaXY+ PGRpdj4oMSkgVGhlIG9yaWdpbmFsIHN1Ym1pc3Npb24gd2FzIGNsb3NlIHRvIHRoZSAxNCBicmFu Y2ggY3JlYXRpb24gdGltZS4gVGhpcyBtZWFudCB0aGF0IHdlIHdlcmVuJ3Qgd2VsbCBwcmVwYXJl ZCB0byBsb29rIGF0IGl0IHNpbmNlIGl0IGlzIHN1Y2ggYW4gaW52YXNpdmUgY2hhbmdlIChhdCBs ZWFzdCBvbiBpdHMgc3VyZmFjZSkuIEl0IGFsc28gc2xvd2VkIHRoZSBpbml0aWFsIHJlc3BvbnNl Li4uPGJyPjwvZGl2PjxkaXY+KDIpIFRoZXJlIHdhcyBhIG51bWJlciBvZiBiYWNrIGFuZCBmb3J0 aCByZXF1ZXN0cyBmb3IgY2hhbmdlcywgd2hpY2ggdG9vayB0aW1lIHRvIHNvcnQgb3V0Li4uPC9k aXY+PGRpdj4oMykgVGhlIHNpemUgb2YgdGhpcyBpcyBodWdlLCB3ZWxsIGJleW9uZCB0aGUgY2Fw YWNpdHkgb2YgUGhhYnJpY2F0b3IgdG8gcmV2aWV3IGFjY3VyYXRlbHkuLi48L2Rpdj48ZGl2Pig0 KSBJdCdzIGEgdmVuZG9yIGltcG9ydC4gVGhhdCBtZWFucyB3ZSBjYW4ndCBqdXN0IGRyb3AgdGhl IFBoYWJyaWNhdG9yIHJldmlldyBpbnRvIHRoZSB0cmVlLi4uPC9kaXY+PGRpdj4oNSkgSXQncyBw aGFicmljYXRvcjogdGhpcyBpcyBhIGdyZWF0IHRvb2wgZm9yIGRldmVsb3BlcnMsIGJ1dCB3ZSBo YXZlIGEgdGVycmlibGUgdHJhY2sgcmVjb3JkIG9mIHVzaW5nIGl0IGZvciBpbnRha2UgZnJvbSBu ZXcgY29udHJpYnV0b3JzLiBXZSBkb24ndCBoYXZlIGFueSBvdmVyc2lnaHQgYXQgYWxsIG92ZXIg dGhpcyB0b29sLCBhdCB0aGVyZSdzIGF0IGJlc3QgdGVwaWQgYW5kIGx1a2Ugd2FybSBhdHRlbXB0 cyB0byBsb29rIGZvciBkcm9wIGJhbGxzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxsIG9m IHRoZXNlIHRoaW5ncyBhcmUgYSB0ZXJyaWJsZSBleHBlcmllbmNlLiBJIGNhbiBvbmx5IGFwb2xv Z2l6ZS4gVGhlc2UgZGF5cywgd2UgbWlnaHQgc3RlZXIgdGhpcyB0b3dhcmRzIGdpdGh1YiwgYnV0 IHRoZSAndmVuZG9yIGltcG9ydCcgbWVhbnMgeW91IHJlYWxseSBuZWVkIHNvbWVvbmUgb24gdGhl IGluc2lkZSwgb3IgeW91IG5lZWQgdG8gYmUgb24gdGhlIGluc2lkZSB0byBtYWtlIHRoYXQgd29y ay48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvLCBob3cgdG8gbW92ZSBmb3J3YXJkPyBXZWxs LCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmc6PC9kaXY+PGRpdj4oMSkgc3VibWl0 IGFsbCB0aGUgb3RoZXIgUGhhYnJpY2F0b3IgcmV2aWV3cyB5b3UgaGF2ZSBvcGVuICh0aGV5IGFy ZSBtb3N0bHkgZ29vZCwgb3IgY2xvc2UgdG8gZ29vZCkgdG8gZ2l0aHViLiBHaXRodWIgaXMgYmVp bmcgYWN0aXZlbHkgbWFuYWdlZCBhbmQgd2lsbCBtYWtlIGl0IGZhc3RlciB0byBnZXQgdGhpbmdz IGl0LiBJdCdzIGEgbXVjaCBiZXR0ZXIgdG9vbCBmb3IgbmV3IGNvbnRyaWJ1dG9ycyAoYW5kIGV2 ZW4gZnJlcXVlbnQgY29udHJpYnV0b3JzIG9mIHNtYWxsaXNoIHRoaW5ncykuPC9kaXY+PGRpdj4o MikgSSBzaG91bGQgZG8gYW4gdmVuZG9yIGltcG9ydCBvZiA1LjMuMCBmcm9tIGdpdGh1YiwgYW5k IGRvIHRoZSBtZXJnZSB0byBhIGJyYW5jaCBhbmQgcHVzaCB0aGF0IHRvIGdpdGh1Yi4gWW91IGNh biB0aGVuIGxheWVyIG9uIHlvdXIgY2hhbmdlcyBhbmQgdGhvc2UgY2FuIGJlIHJldmlld2VkIG1v cmUgY2xvc2VseSBhcyBhIHB1bGwgcmVxdWVzdCBhZ2FpbnN0IHRoZSBicmFuY2ggSSBwdXNoLiBJ IHN1c3BlY3QgdGhhdCBtb3N0IG9mIHRoZSBpc3N1ZXMgYXJlIHNvcnRlZCBvdXQgYWxyZWFkeSA8 YnI+PC9kaXY+PGRpdj4oMykgSSdsbCBsYW5kIGl0IHZpYSB0aGF0IHJvdXRlLi4uPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5BbmQsIGlmIHRoZSBzdW0gb2YgdGhlIG90aGVyIHB1bGwgcmVxdWVz dHMgYW5kIHRoaXMgYXJlIGdvb2QgKGFuZCBJIHN1c3BlY3QgdGhleSB3aWxsIGJlKSwgdGhlbiB3 ZSBjYW4gdGFsayBhYm91dCBjb21taXQgYml0cyBhbmQgc3VjaC48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pkl0J3MgZXhwZXJpZW5jZXMgbGlrZSB0aGlzIHdoaWNoIGlzIHdoeSBJJ20gdHJ5aW5n IHRvIHN0YW5kIHVwIGdpdGh1YiBwdWxsIHJlcXVlc3RzIGFzIGEgcmVsaWFibGUgd2F5IHRvIGdl dCB0aGluZ3MgYW5kIGFuZCB0aGUgYmVzdCBwbGFjZSB0byBzZW5kIHBlb3BsZS4uLiAgPGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzIGFnYWluIGZvciBwZXJzaXN0aW5nLCBhbmQg YWxzbyBmb3IgZXhwcmVzc2luZyB0aGlzIGNyaXRpY2lzbSB0aGF0IHdlIChob3BlZnVsbHkpIGNh biB1c2UgdG8gbWFrZSBpdCBiZXR0ZXIuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2Fy bmVyPGJyPjwvZGl2PjwvZGl2PjwvZGl2Pg0KDQogICAgICAgIDwvYmxvY2txdW90ZT48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2Nv bG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48YnI+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRw eDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+SGVs bG8uPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNp emU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1 KSI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9u dC1zaXplOjE0cHg7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiPkknbSBub3QgdGhlIGF1dGhvciBvZiA8c3Bhbj5ENDE0MjEuIEp1c3QgYXBwbGllZCB0 aGUgcGF0Y2ggdG8gdGVzdCBpdCA4IG1vbnRocyBhZ28uIEFuZCByZWNlbnRseSBkaXNjb3ZlcmVk IHRoYXQgaXQncyBzdGlsbCBub3QgY29tbWl0dGVkLjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOnJnYigwLDAs MCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48c3Bhbj5JIGNhbid0IGNvcHkg eW91ciBtZXNzYWdlIHRvIFBoYWJyaWNhdG9yIGJlY2F1c2UgZG9uJ3QgaGF2ZSBhbiBhY2NvdW50 LiA8L3NwYW4+UGxlYXNlLCBpZiB5b3UgaGF2ZSB0aW1lLCBoZWxwIHRoZSBhdXRob3IgaW4gRDQx NDIxLjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkFoIHllcy4gSSd2ZSBi ZWVuIGluIHRvdWNoIHdpdGggdGhlIGF1dGhvciBmb3Igb3RoZXIgdGhpbmdzLCBhbmQgc29tZWhv dyB0aG91Z2h0IGl0IHdhcyB5b3UuLi4uICBJJ2xsIHJlYWNoIG91dCB0byBoaW0gdmlhIG90aGVy IG1lYW5zLi4uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XYXJuZXI8L2Rpdj48L2Rpdj48L2Rp dj4NCg0KICAgICAgICA8L2Jsb2NrcXVvdGU+PGJyPg0KICAgIDwvZGl2Pg== --b1_2CN0eIvAXtmDNhcURyNl2gaNqbZyxUM7UUypAEujAQ-- From nobody Mon Jul 22 16:26:14 2024 X-Original-To: freebsd-current@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 4WSQdh5gY4z5RDTH for ; Mon, 22 Jul 2024 16:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSQdh36PRz43bZ for ; Mon, 22 Jul 2024 16:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721665590; bh=D6nZ/hxGdoQq2bADSUPeKnuhwvQTt8AHNPL4Ld8+HEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X7iNHw5m/o6EBR/ntkxb+qknLEqNOdO/AnNgdAjnecPUymhqCXTOkwoY0OnK6mLfZezKk45K1aSGX2HO7JahNYnQOGgz+jVUajJo87S8QIl+c4Es6nlSuzqTMkElG4IM3b9bsg+sY9c7K3ii2rgGXvp0ZAFnWZpeUaLq+xDDr659GPiytdj8VWxkjXwWUIqeFPLdVKEsv3bL8ux/5D02LIGROYllr0/SkO9bAhd071WlGFef6sSQDTPWhw/OZyfb5Q6iQcZJw+21m8l9MAHe4KD8L7o8Ql+mu2j0DzYof0mOSWeXD6oX18415BJXV26xgda7GA34fvEbCsXvbb2I5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721665590; bh=ReH5nAtWY1k6Gap8+NhU8KrviyFgjAG90FWJo7Frdrt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=J9ce6WCbh0cX8YLvGa9N2uRlEvLCvstbaG84ZvQc5yJoOgmTCbe1G8jlOfw/kU2MMI7EOUkLbWB90iujrkDlSfM0/XuYu8VFjjuGxHxfQElhrBuowdNEmi7Q3ul2DVrqn+k6wu8IR5o6LnEWQNLDRktrPCcYm541Noweb23opPTUgAL2FolYOmOWXsjnwy9hMuHWWV1E3dovIaekGDJBZBz+Xs4eWc/rBb6vfEDmJG6JJGIgkkSXCqoEyHi2/NVag8OCDPBmhrE9MQdYaKyYlbd8kObwVuvrV8lAyO3VHyrFDEktQWjK+KchxuDcQHv9V+62IXc8KT9S9Bbw5XS+Og== X-YMail-OSG: BPrGsMQVM1mdrgLgCi.301nVjX9VcELozFCwY_dr2j6c7eQH5DI1HFt9MdkEJMC FGgoRweIP4bdORbUv06TqZ3P7CLuytOXkWB68uEaCO22ZI.5gJbpJ6hDJ4J6soHm1eH2FBN0ccim UYOgzl1SN25TgIwR.BBjQKPUFJnCJzJiR_QIwS0c0vI81CsHGNHkOOBdZ5bADvTeEzoljfGj4KsZ LY7nZMUjBc.MWJ7bby6KXYjHIUgh951b6CcFQ23SAXRlqcDNVBVyK4XdCas8hU2ee.JRv8LskU.k m57SY4V.l0eVKrqAcsLOO9Jt6VFt8mgGDc6ZatjK2hIe0vkjrKDfsKuyGONlCoKwmi.5ve5YROtb yX62t6qfL1DvFOXg3_PEvIqe9wy_K5aHHnvkXkZVe5MGLg5i5c4vON39NSObwNGoLaffEeVOJiJh G.rEIsP_UnAsMnujLGgCNxD.GF10UIeQV8Zs4iWZF4Q2_80ioK6iw4Nba2Lar8EXeFwnEjuJCQ3K 3rIjegusWYPEqLOG9ZfUCLwaz20mIhtXh_LWh.i.xbIRi6R2caoZdzWod6sxY7akWuyQjA7xO1So KloGMZilQNVIwbZUVX8mskDj1a.Te0ANvJKLbDf.f3tn3IZwew._Soump2_Qxv8_xcFyfTcSyUEo w6HL8kGJRJnOCXcG3ioiHLaLbAWVwmWyrtAqgesWq1EPPVBm18aClOVZVY6zgVDIAJ387aYhu1MF 6.GLxDBVrQzws9rb6wPBnq8ghUThNJsAjrOU51Pp_QfE6XAZhv8l6fOhtVRfMbGcU9aBLbJD8GIe L90i.Fc0Qq8deYsBeYS1RqaxyZE2j0Q7Q5C6.TnLUfJ1iv.gKAF0Nz2BmOoKBjjQ7WpljJenRNO3 NSrTfYJXI5lHiLz4wTg2j3.uRLFd1G4FvrUG38B4awQ7zdVxgg5nMMi68KV1nsYwljcyQ5RwOrC5 WV7ArTYTYmD1uAGcqqMgr3oO4ofKdq194Uss6mZ1kV9c82u4xQ8.oaF4SSIUJESvrZuxDiaq.vRm xmta3.YfNudtZfykIG_OlbisBafOIkmBDuv6S8c5Qzm0TTxblFju.bQ1PRuE_uFEuM5KX5lBZa6M 00ygMxP5l8YlcSzFfD_mTPcKymxMgv.hyMBHVgwmiJwDbMnKzf4RmBk.7B8k55y_N85yLevXvcBZ b.eA5oPiOP48YxdRqb.zpTxsNYptSCjTjtleW2thcSJlm8wFmUdGNRISTT7wKWTEoPyXE8pQcJy9 z6ehWuNP.b9dwwIDS0kN7K0IKvDdEFU47wy.VHuhK1LHR8mAtk7NL9amnCn65VSAbsTWaPi_JGVz FrZ.zUfZWWxt1fn27vZBl4GM_o3.zj5mxewOon67yXuInEIO6B3rc957peiJBvR.Kpxtlfp2xown y1KGaeiFOufjhrREibEHXjAT8NMATx0P5UUhmbSQvmgQh9c_Oeqzl9rF7uPafa4YboqcPTrCjHeE 5zbwO14JoM59XE_aI9iH0UYNgZ595WrBkcVSUtoA.CxBjqzZHae326vRj6c2yUD1oqIs1aI9OD8y CqPZ3WhIIAXO3ARPdRQz7gyKj5z.FpJnm_hXdDKf7V5v7_ExA7rbyDWM.BFy7nj1mt8BDQ3OjPL7 72xErUoZ5pTBQr44A8QxoxHyJYiNA1_1sV1UwVk5hzd5spBda_u_S05mzTiJLUBDgL3EtUEeYWF3 hPjxCkISF6CYxREIPNJASO466cnnpn0wYbjF5afjs59qEVd3lysLD3kJyi1qf97FDANEnRTFN3f2 8w6Ka2nCa.aYLfdTdPoDnXA7FbN2vtDIWf.4mgpm6juyZ2T7cjRJ75E7LvM8j0HWD7xNLmzZwFFx 67akKO4B3JLx5V8pjO1ukN7OiADiTqEFwBIVsOXot8JYush5ogiSK9AgHtxMy4XjC4nUN8kPsdaJ i6tm0TUYh9rGOdI4o.ho7S0mbAgK.Nh4Yluf2hEcAi2fCmASsHjqbnXfhFHJrAwMQ2lbxbNWrDyw V7ABCfozPrquRb8QAsdVtpkSfX5DntrD025Lv4AIILPpBHPfh_EXeHJnGZFBLREASw66sW6QhrKt TIWtXgf1rbg2CWBiefcV.jY64RHtACcfcfossO7an1szj5uwnbZEAWO7F5IQA0bAnJcxE8rtut.V dIjL0ywbZzOI_nXmEIHCo0Vix4MDT_vZWLxMczsq2FzQcXBOkAKz6toIvXEJ2LA031FC5zrN1Zx. 0.HmaniqNGTOkxLReD1KSTKoiwhnzHmnnmxzPdVkuwSp2dI8Mrh1fmC.Xkx_CESvZo8jrNMkFWYZ _01Q- X-Sonic-MF: X-Sonic-ID: 4cda7c25-14a7-4c5e-992e-c7bddb5fe3a1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 16:26:30 +0000 Received: by hermes--production-gq1-799bb7c8cf-2sgrv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c89e7fcf82c31228c985f178405d8b42; Mon, 22 Jul 2024 16:26:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck From: Mark Millard In-Reply-To: <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> Date: Mon, 22 Jul 2024 09:26:14 -0700 Cc: FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" Content-Transfer-Encoding: quoted-printable Message-Id: <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WSQdh36PRz43bZ On Jul 22, 2024, at 06:40, Michal Meloun = wrote: > On 22.07.2024 13:46, Mark Millard wrote: >> On Jul 21, 2024, at 22:59, Michal Meloun = wrote: >>> I don't want to hijack the original thread, so I'm replying in a new = one. >>>=20 >>> My tegra track current, has been running 24/7 by building = kernel/world and kde5 in a loop for a few years now. But I have never = encountered the aforementioned lockup in native armv7. >>>=20 >>> I have seen usermode mutex lockup in arm32 jail on aarch64, but only = very rarely (once a month or so) and all my attempts to reproduce it in = a more deterministic way have failed. Also, I don't think I've ever seen = this with the debug version of libc. >>>=20 >>> Unfortunately I also failed to reproduce given lockup using = dlopen_test.c, neither on native armv7 or arm32 jail. >>>=20 >>> Michal Meloun >> What is the output of: >> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" >> in your armv7 context(s)? Does it include for likes of: >> QUOTE >> Symbol table '.symtab' contains 911 entries: >> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot >> END QUOTE >> ` >> vs. not? >> Note that the "debug version of libc" being involved likely means = that >> DEBUG_FLAGS was defined. That in turn likely means that strip is not >> being used. In such a case, I expect that the .symtab entry for >> _rtld_get_stack_prot (and more) exists for such a context. > At tis time, I have standard (thus stripped, non-debug) version of = runtime linker library installed. Thus it have only dynamic relocation = record for _rtld_get_stack_prot: >=20 > root@tegra124:~/dlopen_test # readelf -a /libexec/ld-elf.so.1 | grep = -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" > ELF Header: > Elf file type is DYN (Shared object file) > Entry point 0x1449c > There are 10 program headers, starting at offset 52 > Program Headers: > There are 23 section headers, starting at offset 0x1a448: > Section Headers: > Key to Flags: > Dynamic section at offset 0x19fa4 contains 15 entries: > Relocation section (.rel.dyn): > r_offset r_info r_type st_value st_name > Symbol table '.dynsym' contains 27 entries: > 5: 000000000001ba0c 16 FUNC GLOBAL DEFAULT 12 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) > Notes at offset 0x00000174 with length 0x00000018: > Histogram for bucket list length (total of 6 buckets): > Histogram for bucket list length (total of 27 buckets): > Version symbol section (.gnu.version): > Version definition section (.gnu.version_d): > Attribute Section: aeabi >=20 > ------ >=20 > root@tegra124:~/dlopen_test # ./dlopen_test > root@tegra124:~/dlopen_test # Just to be sure . . . Did you at some point "pkg install cairo" (or analogous) so that the following (or some vintage) were in place? # ls -lodT /usr/local/lib/libcairo.so* lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so -> libcairo.so.2.11704.0 lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2 -> libcairo.so.2.11704.0 -rwxr-xr-x 1 root wheel - 1118272 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2.11704.0 # file /usr/local/lib/libcairo.so.2.11704.0=20 /usr/local/lib/libcairo.so.2.11704.0: ELF 32-bit LSB shared object, ARM, = EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 = (1500018), stripped (Installing cairo would also install other things it needs.) For the failing contexts, the a.out from dlopen_test.c will only hang if the library (and what it requires) is actually there to load. =3D=3D=3D Mark Millard marklmi at yahoo.com= From nobody Mon Jul 22 16:51:00 2024 X-Original-To: current@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 4WSRBC1jpNz5RGbC for ; Mon, 22 Jul 2024 16:51:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSRBB4QJSz46y3 for ; Mon, 22 Jul 2024 16:51:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HJbzkI9v; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721667072; bh=tSnOPeOVHdwcZauSe5jXXmrcz0AvqnOTjhc/geZSUlk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HJbzkI9vy+nbDrSxN3tRodzUKGvU+DNWbFdtJRF+35x8ufLiJY+swwpZIUJLHFvGLXRGa+KVH+Jxsh0ZCi+CEcTyfQdiiegVn+fmHRwfoDAikgmnX64LRAOTFGOIbvMMkphL1qjurTNcAktaIy0vKI600uPXYdf35ds6tikIAywcDkMiaB0Y61Q3EyGe+3VfQC0lusOs3R+rptPcXEclJzHXSwgd6++rol1C3wj7HIBx6ml153vc5SnDf6DCiICEhMZuHS79SA6S/mYDWLWGd5aYYapHGradJ4SreLvejNIXTLU3WtH8l7I0EV/4goXqmGiJhJZNWJ4uXzHgk18brA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721667072; bh=3N43E/OyEm9utxAF1TghhseYnFrWOcWKpfrYGeAyoqH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=O/Opuva1OFaVvKP5pVzpaiWJe8zJnWgoh4bmasmhqKyEB0jY981ohu+Qe3MtMNEJlCr8Avx51W+HzhAO7WK+pes5iYROyrmZUIpv5MeHFeDv5XZmxac+44d3hQ5E4TbH7kQK6AVHjcUxFTt6IjY4Uwv2b4RJNGAHr7VWFsJRsuN6kJLsQM1hz4Wrpz0W/qICB6I09U18p3dBV+JPdqtT2OiHrbiYel+Oo7n+oVyAmSFcB57DcFX7rIuG/SjJRTVTEeszVCADtmc20bmEP35/65uY30Xc+kitck3hSdzfb01O3GndyBKCJVSioHJNDYQJMhTKYKgGw7AF+tZ2YjSHxw== X-YMail-OSG: whMR3MIVM1nKP29Q_x.C8KJG8hDKbCIm9UUyxuMqv4P4fjQl7FrBv7ajs.JAQy7 QgADvKQnYtJqCPy1hiZqiF2kA8VR4utJElJtTXyGxlRegwhlkxHC1BAyUKZjqcFtZn2wHMdo0fHr uwaa8T2QXA9SINV7MWBgfgaZACKCiG4X8W2dfnD2QQqehwvbSm8pNFNxBDF1mng_mYS.S47ZP80V 2uWS_MBDfHva3qVa0J4cWKxPxD22B56g5PtihWm9kqBq6ONcx7XEeDYmN0rHAL3TwmKxVinYVhny jxFef50yxaV9XFx_.YrI7KeJP6cyFAeaqskQad1C8V3xUvccJSFfviEUNm8fjiGbRpuqouZAzHq1 mSbXUMkV2UY52JfWKbdAqt.uzZxEZ_s9b4kVVH.fVAQM8m50BkqhaE4GrSwF98FqB7nWof1IKeHj ocU2JS3C4Ul9RRUDBZ_a_vGuFcREjdJBWUze_kd1lT9aUxBd9DUE6pGYpz4Z9Ko8HqiNF5q8IT3a Ddfrgt.RQcmsxziLEc5zEFpZ5ejhW1ZYnrBj8Mz_CEGfZedUApjRBDEyvGnFKiy18YvtSyqg4aGQ 48PncPBlbeQ9fQRaWrNI01SZqsoBt5_w.MNkGciQ4s5UBPv2sD6_kEpZVNjfKcRYKEq5EspjJucC nFh_1AlqGtlfx6L07z6sDRnKehG5EBHSDpm0.hTCby6ezKRGYT8.MBIY645hZ9j00vxzHjROyxVw KBTB0djXAMO25mJttkMhyyWToe0TeaxCaeD7bf2HZvObHPxSarHUJQDqB5QO2cbmBEtGYxCrHAF3 r6XC.GBKqUe.THWI_936AEdsovfrW1jrQ1ybC2H7vTamDAqKCu1hvpQG9dXb4nIZjSLFGVi2zC59 ScdeSrXR.KbYXd4oo1R.TT.dkDJdvp_9nxGfcb8jQLhl5h19sW0VC9U5YYXpp7HuNgN74VO0yqvG gm7kok55h7NxJfJ_y1.Rtju2S_wxfyndJhLLrVHidO_bvEi6S0WcZw.EO0_NrTGzhyk.102krVK0 OLmyDMq_ZiRUMV1t6wl3mmRMwtrx_nlRt1GXuTJBjZ_gRnqZDJV_GzDv63_SyzFDLPaVU8Xdr5f6 KzkU7m_.DOeyJxP_7XXske0jra.LiyhHwlSIpLUZrbC1uY35EKedvDqKCYgxDHqp7l7AUXiwqHhx 4vQfZpriHY3aEzsZJ6ZPLMWzgbxyKDUGM6_4kCP92MtrJUNrpBKtRkf1bLP2h8Kmr4_KfOXDscF0 h4TC7C85Q.um4FNwXEoxiCS2i5iip9MvtHY4vactwKoHnj7Y0l5onztR32bTcxtbNeDyEvS0Wt1q mQVaQJFq67_9ovxtLTIYY5R2Iy6hcpi_xb85J1Z81bP2elC8RkbHEoJc6yaK3ua3W0.VJPd732nP nM2UKZ4yZdyUv6m0cpDNSszWexrNOSMd5GA7v761f1_mVRy9AWZwz5pvQS4UIxboi.aPT5tnYfzi oz8WpROtaRnmAW.HrZuwt7LjyZi4tKiUJy2TsTDbkgc4CgeNzAmkMQDl23wUsH8SURCYxIdDCEaW mA7R1CwYn5UTWr_E3LYffceIAD_jPPSS9CWGy96Vl4kwa_mbyTtIQxy3vpBU_AQ3ZcJLRZww5wDv 0OY2eSGtltLogDCI9z0nonnxlIXjYD0I.6UONFpV4a8pNtznM05Ey.Fou7m73JQ3pJcCZ5exZlyF HVxTOjxYMDm1Wvho0u2AXC92Mgq7cOstxd91y0soZcBHCW7nwlS120BMGfaCufTgBZXDmEGShfd5 1iFsVEnAQM3xFD8KOGLGiCQ3j3PtnJQ9TuH.CFS2e1EJn2Oz3L6d2jd4c0mExwBYduVgM_1qmrZP FCwnEpaUIdmCMTlAmZ3EdilYs80rM0DvxMyvHgInJ6a427PZ7CEpxQgtebmUblwFLL890.c.7FcF 8ibLNnRPeu5H5UKKgS4_j_xevp4vN4eim05wvNYlLyjXIFbvVtRAHof2Un1zPAljdh5OCuyJvLpO L75TRmoZjtV11VXtNL6UXjdC5gKLFaNQxoBwi7d_ki2yrQgJKsOdslzMemMcn928L1Hfpw.qOJ4F qRuQ3CBEIM9CBAGVfUysv4y6Sk8N9ZWcvVBIjf2.aOnmmWBtuvYslDggwdh8fbHke0jMmEhPnmms FzXwFBMPTo0o5q_00desP0bqaDwmiyyYdXChCkyzzxOqAz10m9W2S2ZjidWxex33CSZFiCBGFXoC DEAr9iZUHqERJcsS0LKOcYCTIic2EfL8InfcKUO9AiY2oKlDOOZZIIQonumZHjJVe480M9pvQEJe SMslb2LvXKw-- X-Sonic-MF: X-Sonic-ID: 2e6dce74-5947-42bc-81ec-1afb0a77e599 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 16:51:12 +0000 Received: by hermes--production-gq1-799bb7c8cf-mlhxz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 16aa94160da09089d2624f64b4e6beb5; Mon, 22 Jul 2024 16:51:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: <0FD31A4D-DE2C-400A-B6DB-FA3EAB94E374@yahoo.com> Date: Mon, 22 Jul 2024 09:51:00 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <03D4EE34-321B-4DE3-948C-844503916B5B@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> <9E98F6F6-6896-4958-9D88-FF68C4AB57F2@mit.edu> <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> <3D644314-7F84-4AA8-81A5-DCD29D4ABBC1@yahoo.com> <0FD31A4D-DE2C-400A-B6DB-FA3EAB94E374@yahoo.com> To: John F Carr , Konstantin Belousov , Baptiste Daroussin X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[mit.edu,gmail.com,FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WSRBB4QJSz46y3 Another systematic difference in my personal builds vs. official pkgbase builds, snapshots, releases, etc. is that my armv7 builds are built on aarch64-as-armv7, not on amd64. Not that I have any specific evidence that such matters here. But Michal Meloun's report indicated not using builds done on amd64 as well. ("Tegra" models and examples of ARMv7-A and of ARMv8-A.) For John Carr, I do not know if amd64 based builds of the world were systematically in use, never in use, or some mix in his tests. === Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 17:27:20 2024 X-Original-To: freebsd-current@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 4WSS096fcpz5RJwD for ; Mon, 22 Jul 2024 17:27:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSS086Q1Hz4FVb for ; Mon, 22 Jul 2024 17:27:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721669255; bh=gWXKJb84kxqj8C+bR6NsKAoh+Jiq6enochyzyJX/bFQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=K+rXZL8KZdq2yDoiDmwUn8lXoiGd3VXisU+qnFtXvy+KqVcoyb6lE3AOjypKblTb/Gy1kEyvofBCc9+sdbBiyhN3c9CjG2pPtMNHZm6y9Z5/L4DjHCnz6xTdNQmFYYKUhCklLw2Wk7mu+jPlYf164sJSgsXgz/TeXw6oROB8iQwxbDJKiOoww4plPZU0Y1To9hquU7sENKoyw2ZupuUpW5gtF4fqUoXOSYWeFey6BHK3XBDXOssfkSP5xU8OOYhgm2ps4yD+wbW/u/pdy1OFTYMsgdxYoxC8wDawANJESArTdC1mhsmzFGiOm7j0VdczPYRp7+kuPer+jBz8autU8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721669255; bh=NnGmI9m2XnRV9+IwgiBe75VpRxbSOAou/KbUSSyMlai=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QLIsue0rZs1Mp3/1YpgfBVivirNhoo1m/PWIc71XwbT87AsRjGyDSj8yJsjpWmq123ZFg78jYw2J0dO437Zj3jLQKYAc5zaPZCqecqFMXkjcePVVjee4em0/Olo1RHJif782YSi8ekYHhN4pM5XmHk98gssJX2GL9R3Yma72DwWuO6lVeLbQMvsQUS5BDgjJcS9ES4WnFVosU9xUwuoszqCKp1cV9SyL8gAMMAY6DU9YzLBQP9VfZUEViGf/oUpt6rfUFYz025q7rS713yfXTbm4m2CtkrUktYD5kN/lO8yD+I0md+J0S+iP2EyNgU80zL1HLf4W/wSOgkkkmA2NlA== X-YMail-OSG: 4H9VackVM1mFYpKKm9uofl0JO.kxW5_dpGNfE1hdWc7eQvliU.2Bdc.FPDfYwgU I6w410VYLYHJxKmz_hK_ecl_BPyVUXKBwErTM9gIcw0.b9xaP3S.T.NYKsdqqoyTcRq2EwkBLLLz Sty4S_M7_DcIa99l8eW4bS5aMFJnuzDBOVJZsWG3SCsXuTcqPz6tFOHGiYyrIW2ZxZElH1t2vKHe IgVlVMshTnpVbD7Ma8dnWA362kbVcd1Tt.Cl8FPr02iO7zFHCbmgwA4_cxtJ4qXZ4dPm7WES4Xmo asRJjZcV5nvuK0DZLB.k3FRnk.kF.qp_5NUBxm3N7oGMz3xidtjzYSQSdnbfg1zPTT2GHr_aI2Of tnYDYwrI4xriZfB5ZQ9K__5g1EVLfqUGZAb3Df1oi84y7.l4oJ6OyseJ7Vcio2CDLkbwwjcndrF2 rC3hH62MvFAbDT7s3bhsBT_88xQ47zH9KrGhkcNuEpPbjwRxPMuXswMxDgEN7V2uD.MNjQRE4tkN 1G5SZRjDieBA_zhVfGMIUnU5Ot5Ax579N3TUHFoi2nN0lNq_eGOFrjyuzkS.UgoWoG8w8uBvOlkB RQZsTeE02uiVvUZfdS7qa9QgZVIWbPSit8mOaHSb_7vWmmIO49EvLTHNTglem1sBprJlaL0VrTXK sUxuMN9J70L1HT2R9WnBYnU3moNd4NdUNGV7qqWm.kQfPmE_XCCZQvGC15loINGPOYx2mUSXpZO1 mYvPqDWbedkr2TTLwKG5Y2VdVsBgR1F065xFaXAAy.nYVe9uVakyqjog_lcrpJaG43_Mb6ta3rDG VaWF57UTan1mEETMKa5zrbH2dGY4UHy4UMeZGGilf6JhZSd7e6Ead2KFMgKrv_bhKGxPSVXEfJ8P iBlo2Pyt34WgAdSfJQXnwW83H6zorccrbMITue5Z9rTA7Dj8LVirFfF5t7vN_z28ToJe1swka2qN k3CHAtDciyPeEFmyGu69n2xBWvk1yhACRMo9Ieon_uYD0wulIr1gQ36dRilVXUk78hucH76vz.QT muO2d9I7QGDgKeK.glYikjW9aWES1lum5i86u0GbFdJKbknSOcvtivG5XruxmwW5X4sM1qQAQf6X anFud54tWzrcbUn4a4G44iqE4ToeSAq7jOymCEZQcuZwkKDdYUTWg.Z3gyXfPNDYEPCuoGhu7FR1 zsoSgg1MWxCeel9LhngCKMNjmotaXcOY6eTqa.AeS1eXjsrjxiVItiYIsGTLY3bc5SSbhNdPZhr4 4KEwEcXXUnqJkb7itq3Gur.R3AexEtSZPJ.z5uSPXtI0qU6w0MKxxl7IMXi0lP8Ub0HaASAim1Kt vqONz0L6ZFH4J3N_tR5Jd.aOqk0KbN_ERisp.WYxzhda4Uws65iv_yAXakfP5wT_SIwWWVsTz_nO F8IQ2YjLYC6_OPSs7YZblqfX6GKmKylzTDHnNW7a9HZo50NEDcdB_q2277ij9cMKOCcnrU36OsvE AWkAH.Xy1E2aBSr0_ehlBvS8e0ZqxzHS0ajXMyPX9_D1BGZ2JjAem63FMc.c7uXgg47ZiL2qb72X fT1V8KiiuqnGpZOxL52ScAsOLSvasWbbAme1aApoNeWg9wTICz6PAT_IPIydCTfp.TZhb996zjGE 1a2FG54sFu9w8aPM44_4FwCCSGLbd65dz4IWop8ONqTZxWfxrc8P5zn58QOOkYlPtOLRv6Z5dwXY VUJkON2Ucrj9h1uEZl_CRuEZIbFKrseZ3bsLhxJlj9xJwyIqvpvEOeL2dRGJdthM9UUY1HdArVRQ joMyr.qUjuGav3zZ4ZGOk3eLdZwjpmGP.A3Qz0F71NFKSJ6LYmoEnDDzqzreeH0_0a7uQYAcRGRU Axnr0.tpSn9g4miN.RLs.jddqU1mX7ckPSLN.qUUFdJdA4rA7CB0MLV7PVYV1LfEF5IzqggKyfMR f5Pi1JWy1i6UHSPb3jfJ__CkxlKJJslB32nQpXjZxttcBoySN_3OmvaLDidGDjZ6olRZZpUEhF4F 4wP50yi2eaPuAYX5sxT1ALRFXDFLDPpsynrHmKsGSYAWh7bE7t00XM8bKP60pgeBwkQiBvQUkKVY vxNwPvDZjBd0_EJIlasdLBdxX7jNMqph6EZWmNMlGA00WU1nZ6i0KfxTAc3ALpAJ6ehjKFhVWgE5 PgCBR3HdG5zrx9lIGD9i_4pZn0HdOydyig5O9voX_EqCLJgsvzXk44WImqNmvHqv2enUOhxtDgLz yD2emZDkIQHXEGbvsX4Y.0FvquV7TTDSfUknw3t8CvWB4pS4F3VlG_vEIACnp8ZoODaQ7Yg3wHdU S5Mw- X-Sonic-MF: X-Sonic-ID: d4be4be0-89b7-4151-837c-91ad9c0df497 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 17:27:35 +0000 Received: by hermes--production-gq1-799bb7c8cf-b6h6x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0b1c46225ddb57335b8c024386159b3e; Mon, 22 Jul 2024 17:27:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck From: Mark Millard In-Reply-To: Date: Mon, 22 Jul 2024 10:27:20 -0700 Cc: FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" Content-Transfer-Encoding: quoted-printable Message-Id: References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WSS086Q1Hz4FVb On Jul 22, 2024, at 09:41, meloun.michal@gmail.com wrote: > On 22.07.2024 18:26, Mark Millard wrote: >> On Jul 22, 2024, at 06:40, Michal Meloun = wrote: >>> On 22.07.2024 13:46, Mark Millard wrote: >>>> On Jul 21, 2024, at 22:59, Michal Meloun = wrote: >>>>> I don't want to hijack the original thread, so I'm replying in a = new one. >>>>>=20 >>>>> My tegra track current, has been running 24/7 by building = kernel/world and kde5 in a loop for a few years now. But I have never = encountered the aforementioned lockup in native armv7. >>>>>=20 >>>>> I have seen usermode mutex lockup in arm32 jail on aarch64, but = only very rarely (once a month or so) and all my attempts to reproduce = it in a more deterministic way have failed. Also, I don't think I've = ever seen this with the debug version of libc. >>>>>=20 >>>>> Unfortunately I also failed to reproduce given lockup using = dlopen_test.c, neither on native armv7 or arm32 jail. >>>>>=20 >>>>> Michal Meloun >>>> What is the output of: >>>> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" >>>> in your armv7 context(s)? Does it include for likes of: >>>> QUOTE >>>> Symbol table '.symtab' contains 911 entries: >>>> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot >>>> END QUOTE >>>> ` >>>> vs. not? >>>> Note that the "debug version of libc" being involved likely means = that >>>> DEBUG_FLAGS was defined. That in turn likely means that strip is = not >>>> being used. In such a case, I expect that the .symtab entry for >>>> _rtld_get_stack_prot (and more) exists for such a context. >>> At tis time, I have standard (thus stripped, non-debug) version of = runtime linker library installed. Thus it have only dynamic relocation = record for _rtld_get_stack_prot: >>>=20 >>> root@tegra124:~/dlopen_test # readelf -a /libexec/ld-elf.so.1 | grep = -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" >>> ELF Header: >>> Elf file type is DYN (Shared object file) >>> Entry point 0x1449c >>> There are 10 program headers, starting at offset 52 >>> Program Headers: >>> There are 23 section headers, starting at offset 0x1a448: >>> Section Headers: >>> Key to Flags: >>> Dynamic section at offset 0x19fa4 contains 15 entries: >>> Relocation section (.rel.dyn): >>> r_offset r_info r_type st_value st_name >>> Symbol table '.dynsym' contains 27 entries: >>> 5: 000000000001ba0c 16 FUNC GLOBAL DEFAULT 12 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) >>> Notes at offset 0x00000174 with length 0x00000018: >>> Histogram for bucket list length (total of 6 buckets): >>> Histogram for bucket list length (total of 27 buckets): >>> Version symbol section (.gnu.version): >>> Version definition section (.gnu.version_d): >>> Attribute Section: aeabi >>>=20 >>> ------ >>>=20 >>> root@tegra124:~/dlopen_test # ./dlopen_test >>> root@tegra124:~/dlopen_test # >> Just to be sure . . . >> Did you at some point "pkg install cairo" (or analogous) so that >> the following (or some vintage) were in place? >> # ls -lodT /usr/local/lib/libcairo.so* >> lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so -> libcairo.so.2.11704.0 >> lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2 -> libcairo.so.2.11704.0 >> -rwxr-xr-x 1 root wheel - 1118272 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2.11704.0 >> # file /usr/local/lib/libcairo.so.2.11704.0 >> /usr/local/lib/libcairo.so.2.11704.0: ELF 32-bit LSB shared object, = ARM, EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 = (1500018), stripped >> (Installing cairo would also install other things it needs.) >> For the failing contexts, the a.out from dlopen_test.c will only >> hang if the library (and what it requires) is actually there to >> load. > Yep, i have cairo installed (but compiled from sources, not installed = by pkg). And i have verified that dlopen() return success. > In the meantime I tried all combinations (debud/stripped) of ld_elf = and libthr. All combinations work without problems on the native system = and in arm323 jail. Thanks for the information. My personal builds, which are the ones that work in my testing, are built on aarch64 as armv7 instead of on amd64. The known failing ones are built on amd64. But I've no more specific information suggesting a tie to the type of build host for the world used. > Btw, gdb has long had problems with stepping inside ld_elf. It's = better to run the test program without it and connect to the test = program to get the "correct" stack trace. >=20 In part I was deliberately exploring what sequence leads to the hangups vs. lack of hangups and the like: more context than a backtrace of the stuck state can provide. But doing "./a.out &" and then "gdb -p..." to attach to it: _umtx_op () at _umtx_op.S:4 warning: 4 _umtx_op.S: No such file or directory (gdb) bt #0 _umtx_op () at _umtx_op.S:4 #1 0x2036845c in _umtx_op_err (obj=3D0x4, op=3D12, val=3D0, uaddr=3D0x0, = uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 #2 0x20115da8 in __thr_rwlock_rdlock (rwlock=3D0x4, = rwlock@entry=3D0x20137c40, flags=3D3, tsp=3D) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:294 #3 0x2010ebf4 in _thr_rwlock_rdlock (rwlock=3D0x20137c40, flags=3D0, = tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.h:229 #4 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 #5 0x20060788 in rlock_acquire (lock=3D0x2008af10 , = lockstate=3Dlockstate@entry=3D0xffffd114) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld_lock.c:259 #6 0x20059098 in _rtld_bind (obj=3D0x2008f404, reloff=3D496) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:1035 #7 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 #8 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 #9 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 . . . It does not seem significantly different than I'd reported for the hungup state. An issue here is that the pkgbase world possibly is -O2 based despite having debug information (but is stripped). This can make details less reliable. So, for example, the rwlock=3D0x4 vs. rwlock@entry=3D0x20137c40 for __thr_rwlock_rdlock could well be suspect. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 22 18:42:47 2024 X-Original-To: freebsd-current@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 4WSTg00lKtz5PxDV for ; Mon, 22 Jul 2024 18:42:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSTfz3B9Hz4MjS for ; Mon, 22 Jul 2024 18:42:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=cschubert.com; spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id Vqyhsurl5MArNVxzmsSMVm; Mon, 22 Jul 2024 18:42:50 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id VxzksGLliE0IVVxzmsaIz5; Mon, 22 Jul 2024 18:42:50 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=cI9DsUeN c=1 sm=1 tr=0 ts=669ea82a a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=4kmOji7k6h8A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=BC7gEX-hzanKcXZTYOwA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 3D8A636E for ; Mon, 22 Jul 2024 11:42:48 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id F3090BC; Mon, 22 Jul 2024 11:42:47 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: WPA 2.11 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jul 2024 11:42:47 -0700 Message-Id: <20240722184247.F3090BC@slippy.cwsent.com> X-CMAE-Envelope: MS4xfBiLKpyzDFDAqpNw+RAGcfZ2GU9Jh5n0VK39a8uaYE1kdmUrKG+1yCr5cYDrHVgcSBGIuyzoRJyc/9KfTbCq60S4IF/Vu7sId+znKk/CiyAMQTCyQkLf ZehKddZNaXuVMetzxFzZnvkXvG0DBkuDWb/QYRo5kSDa3gNRpZyGymKYn178eoaE1qcpNlp92GgVelTm8ekSnpeFnQhJ+AOiIlU= X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJ_ALL_CAPS(0.60)[8]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[cschubert.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4WSTfz3B9Hz4MjS As this is stabilization week and as I'm virtually AFK next week, WPA 2.11 will be imported into main the week of August 12. If people do want to try it out I can make it available for testing. But my time to work on problems next week, starting this Friday, will be severely limited next week. It's currently in use here. I've experienced no problems so far. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Mon Jul 22 20:22:53 2024 X-Original-To: current@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 4WSWtS2gGHz5Q6q6; Mon, 22 Jul 2024 20:22:56 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11020108.outbound.protection.outlook.com [52.101.61.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSWtS0Stmz4Yfs; Mon, 22 Jul 2024 20:22:56 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e/mpvWaKzM4cKVG8SVhtvqJaDNDjdzBhLfQ6MustVcMElQtil72+jEBxAVieAPz32Zs2cVuC6HSTYHGXCvOK+g7BT0hD9v2Ux0QcUqwyg9jw3L8yjzfjqJe36wBGa8ojsDuAhqnVpnwp+234bqhI1ESBmH1J+r35zvNrNVzkUPYIl+oZ0+/VL+UJTgLyrIgf2PMb5Gl9cuRv8+Tc2mMn1RbKOY8/NJSHHpyK+X21JssU6GWA4vbjmHPjJVIgX8T9tvCsOJgdb+uec988wQnwjKADQ7ZeXxg3Y7LsoME3HS1wE2+Fb0AfvLZdhudCPMZU/eZ9cMOl9vAdI6denBfg7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Tiq+FjLr9tayieDpQj/TVYUKTTkvfmD+AZO+POI+UkI=; b=kDTbMpr3yE/BcTtDKv8+MxCCI4Wp5xVZX3mBg0PlYYj38EObksfYf1LJbMLeBBNi6SYUxjInhKi7spY5pLDJHyn6ZYHKjj8JhJQVD6iG7i8dZ0Mu+Dv8r0cx4A53v3hq0h2HYbQGNcvtXhI2TQx2NawqKcJhqdnf/NjFo1H/t8qsScio/un/66n7eNkaVBiTXa5gvrdkcWmRW8WfF1YxcKtM8OyJxqe+fs5iifChmhhbkOkDb4qmEz0DMwkYQSEOe6Guuyd4Gw3GqFKZp6MkmyKBik8zpccKIdrQg2HyIQmZw7FL8fsXGQ29E5kQy1Yey+PSvCuIcCyhEwQignp5ZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tiq+FjLr9tayieDpQj/TVYUKTTkvfmD+AZO+POI+UkI=; b=isyZQbhYfnTZofR/cgjkJlakRQgQHF+M7A6GZ99DeSi2gNOKihTBa/y/tUcpRNiXbrNsyHsPZjIzGyDU+81SDEYJHyP3Pb0zPyqRGZ48T0179o/8zyIowi/41iyzPxneVLd3csHEJiU7pCG6FaGtsMnnh68NXe6gTOrbUxvc0do= Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by DM8PR01MB6917.prod.exchangelabs.com (2603:10b6:8:12::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.18; Mon, 22 Jul 2024 20:22:53 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d%6]) with mapi id 15.20.7762.027; Mon, 22 Jul 2024 20:22:53 +0000 From: John F Carr To: Mark Millard CC: Konstantin Belousov , Baptiste Daroussin , "arm@freebsd.org" , "current@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Thread-Topic: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Thread-Index: AQHa169N7HO9yymad0CPtZXPbon3W7H6JZYAgABUwACAAatfgIAC+Q4AgAA3jQCAAPdBgIAAtuEAgADj64CAAAFFAIAAC/oAgAAxygCAAAK7AIAAfbYAgABXcwCAADsmAA== Date: Mon, 22 Jul 2024 20:22:53 +0000 Message-ID: <021DC7F9-0B04-4544-9711-E7413C21BB52@mit.edu> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <8E9579B7-2ABF-4446-B65E-E993E7B67C5C@yahoo.com> <9E98F6F6-6896-4958-9D88-FF68C4AB57F2@mit.edu> <705AE360-C1C3-4B54-B6EE-FC81548D46B8@yahoo.com> <3D644314-7F84-4AA8-81A5-DCD29D4ABBC1@yahoo.com> <0FD31A4D-DE2C-400A-B6DB-FA3EAB94E374@yahoo.com> <03D4EE34-321B-4DE3-948C-844503916B5B@yahoo.com> In-Reply-To: <03D4EE34-321B-4DE3-948C-844503916B5B@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|DM8PR01MB6917:EE_ x-ms-office365-filtering-correlation-id: 64fc2df4-ec18-4610-0bcd-08dcaa8c10c1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?FvNfvRYOF5IWTulicTSWhH5tYC5QNPnPuaIzdnPab5vV2lBUfts0y9DluB2B?= =?us-ascii?Q?j+AjWpaooDDK+JTD++3Hi7dPF2nEIUw6oY0FICA+/fFPEGO9YMbTFYM7aqkP?= =?us-ascii?Q?rRABowdf1xdFAtl//jHJNx9ce9myR5dWvqDwKTb2sYAjh5JxtemHCCzU6rT4?= =?us-ascii?Q?lir+Mjk2PdYmEh+/HhUc1FLeMlxW3lI4uGAbqKotrESfduVKoaVvRIBFMU/g?= =?us-ascii?Q?A6fyMPwCQvuGJ8Q87VBarWigVEYaT0RNEKUTpysyfqOltojzplq5HDtnj7ij?= =?us-ascii?Q?fqEq5zOJiIEp6f7r1x/L9/fBTRBOPngv1tgYnbjiHXeUBms+JtHsW4qdSOT7?= =?us-ascii?Q?bQuiw/j8S6vSEgsKMy0pH3jTIPkg3WZ/UBfFHSxQIIUBaORH8jYDS2UXJk90?= =?us-ascii?Q?A0bXckAr1Z62nrz0I64A5I4fROLA6idq6MrU/a5jLgTraxwU2yk/ecA9vXxh?= =?us-ascii?Q?67vtjAqPWepzjkXnkN3qxZnJQ5oZHyT5QATEPuvD/wcbX2gQ14PSRQoGjtIB?= =?us-ascii?Q?xS2IwS3oKLl17yB0VuiLJy+dtLfY0jtDT5ArgowjLbi7QAmgzhntczGXAmnw?= =?us-ascii?Q?bKqgJGsGnMWQOH32VTvjVPmKrVGoHAW6pMz8dhdlFal14khRkgTQ8sHz/1Ut?= =?us-ascii?Q?FyXsj30rgjrvuKw82OsaeYnPQhrW7HZtJ5IVW+jU3lRnXXvldWt2IYzeMRfJ?= =?us-ascii?Q?wAPI6huagE9sdOJxb0bnxbTBVwo9QSYRgO8g02Eenunsr5w+7PxwF4IMzlUt?= =?us-ascii?Q?XdTZvHrXyP0KOHWnfcxhSfeXq8qIgUbRiGEAtHMGPgi6foj0VuH+wtlRksxS?= =?us-ascii?Q?ZIQMm+4jr6B2Teu/ZmTYgiAeHJ4rX1HGWCFkMmcnyyQNWso2j6qvjXYadsS2?= =?us-ascii?Q?3dwHAU97oq3A88j2dQ6vmgMlbM8RxqVufi75KgO25S1Rff0XdAfN4wFjyanG?= =?us-ascii?Q?95bi+5FH41d/BFU4CbZUtGpZ8cCvnVxZPs45pbfCZvbxdJ+HuzRKR04mLLFr?= =?us-ascii?Q?8LyjNP7UXaBgfpulGYtk54MSuT4kuBBlUUKLQvqGN3PevcmniML9QpII9iCs?= =?us-ascii?Q?HDPdXIY5idpLflQ7gh8D2zYh2/DnpkLrEGXizC087Gu7nGINaB0r055LP5Tv?= =?us-ascii?Q?37L3tEtJVs+ZiunigWJZSI2Dqznj5UtqognkTxL450WpgrHq5cUBaKygOaBp?= =?us-ascii?Q?PYGsHbJdqPyKk6KLXIDBcz9itefnVLUe+CH38PIJ5mjA7Bq5PakeJLOrB7V5?= =?us-ascii?Q?vNnS+zXu1S/S0lwiIfU23xoE/8vcJvR+SYBtuypwrCwwyCM/dLSQEFi3txll?= =?us-ascii?Q?IdniCzTkp87MVzxDbWibZtAAT3pGe/vp+W0Hc7oqJahxc7+gpcSy7iphhFta?= =?us-ascii?Q?rs4BvMYUfTwbMIfoqR6Jap6rGAOw6ZLUslOibvXI77gM89cxqQ=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ZXwDm2qynzn8XGRU42IYbAfa01dsWfmcxiELrt4+P7fnu+UPF2R0DUk3Zdwb?= =?us-ascii?Q?I3p8m4Bdqe+q+wV5j9a6V18I58GVKOf8RAMbGKKLJRVH30N1o2QoASENhAjU?= =?us-ascii?Q?hJm0z7Dbm9Q3Dk4iakQgDT/0m2sol6OYbd10rVC3Id+rVlaEV/t/vC15ZrFo?= =?us-ascii?Q?lgjyy71yauJaa2RfSBM2SvjIvSld8h68LyTKFlMCit3v7EIsjZcoau04jxek?= =?us-ascii?Q?Vi2nq6woogMnq4nDMhxMR5xSz2r5/iyQj14jeDTnzldSOoCqU6eRMjgG6lio?= =?us-ascii?Q?v6Bqj657aERKaLhKQpTf1QVxSfFdvrZmv6Nzw9ai/6CagRIYhx6lXRlSVAaz?= =?us-ascii?Q?8/vz8foBb3M6oLLxgmguDkpwXJrBUo6SWmUQi2lRNimw7JJ1MhJjAY4XSbk+?= =?us-ascii?Q?S1UXXFvP7Z/bln7bB1IKtHTRDyhPHr7DMn+6mUZdiXMqk+M81Ymv8RuQyAAR?= =?us-ascii?Q?0ZZQogY84z1Gbe+kOULDqtGOnT6Apu/gLr4QTxHuw6jHu8SYm7onYRthp3Xf?= =?us-ascii?Q?ajfYwHbDtglViol8B6+qe5FtkM1oNEbHPOXxMchJsFCAnDd2NDVWVWD5Uk6f?= =?us-ascii?Q?zhrBn0MzgF51GhiCNN/xD+iOmYN6uErNd4OybBA8rnWtsyuN+mc0rH0oELjz?= =?us-ascii?Q?4hUehFPMYtspKmgF/g6ChtuLRnrKiPUp8p97suoPXKrpEXYe8kj1Q3VrMRqY?= =?us-ascii?Q?zVMKNxcDm8zb106AA4wXiljrfnZ4cEqsbFJ8OFJlsVBti+TNWw3Vt3CH70qG?= =?us-ascii?Q?Lk2S7/Vlz9DIDllT1vh8GJNgSJcbsWK5KFiu0JzhQ5UwsyS53YRTsFLrE+A2?= =?us-ascii?Q?YjkYzt3HIiUih35gtG5CQLYE6B8J5YInutu1Aj/d2mY1X1GiIl5zJXt6i6g9?= =?us-ascii?Q?IjxgCOSQ/8BeAuH5pJlPE9pi/xvScXHn4/N30CSwdPIUoTD1wntXbXAQBnCM?= =?us-ascii?Q?Bz8e5gXcmQom2A03JKhtZs5UOfuzEHnJ0CTJ1bS0XimK1a261Z5R++4i+NUE?= =?us-ascii?Q?cOkDZrbEvNHydJWAespBAskkTou2eI+gbsSJwff0KymfQzBOQBSlKAp6jeTx?= =?us-ascii?Q?gQ/GbqBgB4Pbs30B61XgW95FtPCzukKN/+ULJvyJrbE8XZulAPKCqK7hDTKP?= =?us-ascii?Q?k+eGJdUEp+bypk0E7p3Q9H5AXX2PymRvyoguYQnOl1VGxjP2zu6avBIBz67e?= =?us-ascii?Q?gMbA64I//V3S8quy2yqqTNs4ccaC3v6x9hy+aEOxj7K6VRaMI5E08FmiDW77?= =?us-ascii?Q?MtXtnDgZAQVPiapkgh6F+jAdv48VuRrviz3mXkGLrjIjby7DQY1zFrt0peuT?= =?us-ascii?Q?5Xm1EYWW7YzJDped8HSAkiaqQrAFYHx38kSsJrsSTByZ61nznJJLMnxahISV?= =?us-ascii?Q?yBez4djssC6aZMiZHRzhoJzceja4B4FfgJUxvvoCBGL/s+qGEqCxAiRrhMBG?= =?us-ascii?Q?RZb8YQkLGd7O7qAY8l4QbonDHrpuEnwScnXDG62c00zETi3uB3Md3yk7ZR40?= =?us-ascii?Q?UCnMIR2SKOjTXQRovoe7j6nc9ZhapcxJcXnv9blY7xtLOHlvJnTBodIl3mln?= =?us-ascii?Q?LEK6j80Jr6cN0dEJPvgUxXDKDnne7cMjqvNRe8fZvFE4Z99FxLKu73DWevmp?= =?us-ascii?Q?Ug/EF1pIFN8rRKRsDP41c+Ia7W5Km6YMCuJmaYBxCZ4y?= Content-Type: text/plain; charset="us-ascii" Content-ID: <22846C703911F84FB84F31E296A3068F@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64fc2df4-ec18-4610-0bcd-08dcaa8c10c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2024 20:22:53.2609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /aQaUnWTDdT5M7G72h00BtJ3Pi5oNuAsww6H12GOu7HDRmMHdCtAzZJIUJVMkva7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR01MB6917 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US] X-Rspamd-Queue-Id: 4WSWtS0Stmz4Yfs > On Jul 22, 2024, at 12:51, Mark Millard wrote: >=20 > Another systematic difference in my personal builds vs. > official pkgbase builds, snapshots, releases, etc. is > that my armv7 builds are built on aarch64-as-armv7, not > on amd64. Not that I have any specific evidence that > such matters here. >=20 > But Michal Meloun's report indicated not using builds > done on amd64 as well. ("Tegra" models and examples of > ARMv7-A and of ARMv8-A.) >=20 > For John Carr, I do not know if amd64 based builds of > the world were systematically in use, never in use, > or some mix in his tests. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 I reproduced the hang with code built on aarch64. I have not been cross-compiling from amd64. For poudriere I use armv7 jails running on aarch64. One of them just hit the hang with 14.1-STABLE kernel and 15.0-CURRENT userspace. # ps -d -J 1021 PID TT STAT TIME COMMAND 77550 1 IJ 0:00.27 /usr/bin/make -C /usr/ports/graphics/librsvg2-rust s= tage 77574 1 IJ 0:00.00 - /bin/sh -e /wrkdirs/usr/ports/graphics/librsvg2-ru= st/work/makeiFVIOP 77575 1 IJ 0:00.06 `-- gmake -f Makefile DESTDIR=3D/wrkdirs/usr/ports/g= raphics/librsvg2-rust/wo 77576 1 IJ 0:00.06 `-- gmake INSTALL_PROGRAM=3D/bin/sh /wrkdirs/usr/p= orts/graphics/librsvg2-r 77577 1 IJ 0:00.06 `-- gmake install-recursive 77578 1 IJ 0:00.00 `-- /bin/sh -c fail=3D; \\\nif (target_option= =3Dk; case ${target_option- 77709 1 IJ 0:00.01 `-- gmake install 77710 1 IJ 0:00.00 `-- /bin/sh -c ( /usr/local/bin/gdk-pixbuf= -query-loaders ./libpi 77711 1 IJ 0:00.01 `-- /usr/local/bin/gdk-pixbuf-query-load= ers ./libpixbufloader- # ps -l -p 77711 UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 65534 77711 77710 27 20 0 27520 16660 urdlck IJ 1 0:00.01 /usr/local/= bin/gdk-pixbuf-query-l Poudriere told me I shouldn't run a newer userspace than kernel. It usually works despite the warning. From nobody Mon Jul 22 22:50:31 2024 X-Original-To: freebsd-current@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 4WSb8w1TQCz5QMFD; Mon, 22 Jul 2024 22:50:40 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSb8v2nDvz4nxH; Mon, 22 Jul 2024 22:50:39 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46MMoWA2057098; Tue, 23 Jul 2024 01:50:35 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46MMoWA2057098 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46MMoVbi057097; Tue, 23 Jul 2024 01:50:31 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 23 Jul 2024 01:50:31 +0300 From: Konstantin Belousov To: Michal Meloun Cc: Mark Millard , mmel@freebsd.org, FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-1.48 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; FREEFALL_USER(0.00)[kib]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WSb8v2nDvz4nxH On Mon, Jul 22, 2024 at 09:36:00PM +0200, Michal Meloun wrote: > IMHO, -O2 shouldn't be able to modify function arguments for public > functions, so this memory corruption fits perfectly with the > observed behavior. > > But , out of curiosity, a quick look at _thr_rwlock_tryrdlock() in > thr_umtx.h:208 makes me wonder: How is the "state" variable inside the loop > guaranteed to be updated? IMHO nothing inside the loop emits a global memory > modification attribute, so the compiler is free to move the assignment to a > "state" variable outside the loop. > I think that you are formally right, because there is only the _acq atomic in the loop body, an evil compiler is allowed to move all loads before the start of the loop iteration. But, since e.g. on arm32 atomic_cmpset_acq implementation contains dmb() which provides the full barrier both for compiler memory accesses, and for hw, it is not the case (for arm32). From nobody Tue Jul 23 03:49:08 2024 X-Original-To: freebsd-current@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 4WSjnd108yz5R6RP for ; Tue, 23 Jul 2024 03:49:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSjnb0LPjz4LFY for ; Tue, 23 Jul 2024 03:49:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=haGeNt72; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721706560; bh=HAy4FU2B/7uySxnzLucWmPj6GrD/wz/Oh1ZqHzvCN+E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=haGeNt72a1wIIRDlasZ4uI6HuBgltKwe7IjnqqTFxuUOo4vK4coMxqIyiHV40Ye5i4leuPsbdbIB0RXEkpJZv/wubXJ6cTdCo1sbu2rE5FtM9paHAYg6Gpr7aSGhws+dmzUHNi68orf93q9mnXGkT/XCdoqDVQwKz+5zzCj3PTY3u0sECsWO94Zc0nCJve1wdDnl/N+o+nWrJ/VGnZfJVd0IhJeEnq4623a916AC6HU1bLdWdPKnCHzP0VaQiiF+QT/hppwzqCd+btjkzS+vkFBSaIE96qlpJoFwoWuEbLn25mpy2/gg8C9pdbrMSNHLtl/NYFwaeXtRNQwMJTDsww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721706560; bh=BMiSQHQlek8t48k+bJpBLF2666L9yCDiW+ZFJyc7X9i=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=R0EF2noxQQ6+OngZBI9qV5iJfuh+Vk5kafo3AcyWALtH52msxL+R+FWPhIv/B938JKk0U6TN0fSzZ5A7Bj+d4wM7g/jaS54mNa9omHvdtDC3tkLe4p9S51GJGdwQVZD2968GekUV8aQ20NGfYYcGfzR7s7nr2gDsy5eSIPRhB01tmEJ1aPnRkvmMG67PL2JvOYTRCHPnEL7n1JSn8f7a8MFkj5tHXOUe+EOlfUNQaggtc1XsMmtLOJD6hpp3gkTRcdyadQQa0gKRFXMVCGU198jAwBaGl7aOPAUsv5PVHs27ZggydHVEs1GxWQs+ATM29fiy/gW4hClRMZeo2ypKLw== X-YMail-OSG: hyLlAPIVM1mKpUFXrea4_J5FqAJIcZ0_5SxdYokGXThSDaFbbuBOoufvQcir.5S YxprKGkt_xKGBK30f2n1G3GsT.vf4NSyxymZav8UtY019K8vZAtkgzCHB5sCd56_4wPaU827qvuR 6Iy0QwBLu09N1emsKv3XYP3TfAj_xrI54HYuSE9sXHkJ2sygpK55UxpwbysACWR4t6Qo13Q9r6nO urdJtFa3uznH1NzetMczF6QjtMz.1wxotCjLwb4w9_FrQgp4Ax1A_OIMf.aemtcJy.AgUP75hhOV 8RNdLPAb8WFDrA6Fspi8pYJ3dAFUFUqZKq4jzI_OGUQHZmj8GvpvAsHYhekAi1G.n1TR6riySg4u BypP7PhT9E8UIr3mQOswu9SYZZQetvIoeM72fL4hiWYf5p6HaITl8H35QJ_NqO35L90l5pC1NBzt bmwRDviauO6NLOf1Lv7a63QNP4CpFYcGYRjMGXGPIts04h_NqtnJWR4xFjRQ2xO3exZkSXiq9X8F OAuoBmE62lhljn.gdE4usH_6ZyItcIVYbDSnltI_VM5sVxeNUw0A0LBvdAWqtAgX_bckJpqO_DTB 19xLZLkjKK4_uGFETlvEh0lxGiJ9Y8Dt9HJD5fHlmGNgLZIIWkrsGtuM9c7ZowZ8gsgVxaYTZ4pk VM5f.vtUheYd_ZRnbyqZURPlcj1eMO1.Kn8cstOMEhLYI9qDWi4jZVE_zorIMIbKR4JmjztLHTYR bmFOOrDLJJOxI.y4.LKZf1PmK3Cfb9IQ4iV62VXBXo.mxYAyM9WAs23fUu.pFZ5lnPZTzq.WgHCy ahyFl8vm0ES7HFbp.iY9ZI3bARAb6G32ZVq8_3XnDZdx8GRR2qI3YIm0EN4YTuCP41O8A96.bYQ1 ELVzCBMICwKoCgpfl2Sf2HrC2Hu0OtlYFxKoJlJbtuFcq8lsr2sQBWix.ezOixjyYCnAkcXksgjW Ep2kZr00cM7exOFIYk6itIoeg0Y573DbrsA9VKxnPEvbvF2aPZ83cSzGQu.eHLxfztAAqiWuiDZM 1V12NLubuRK5GcVfW_3SywvlkOzOEIkGA1dZ1boYN12w6MToNQTE33AHjgp8a8mGeojhnHHu3H61 P6ZMhcDv1lRi9CR9TgWQcik4QjqjbFa81HHmjc9rJLOMN5NUPOWraVitwx50NJ8uyMQwfZW4eaeS yUJMmfd7expo8ELKYwuk_9Re5yHu51fylLms3Z5lKYt853dJh5dlQiNtrY09egCfcFoeP0j2KCtT yUwKPQZD3Otrfyf3dHNAPeoYn_ZFLtwlh8nsw6xcGro2FQbbquHJ5KTFwrX.Ox9RpFA69_UPn_GO T3mxtioWRq.nAz3rGlTz.wWVpOO1ZxQOMPwtFvk2OWpUKOLVM9UTu.t7W84DUk7u20.WtIjzILYe A6gAPN4Tfxqa.DA.K9TCbVmTKtJL5oUFIuxVhsQ40KxpNv18aR1iQIBVjKnkbV5u9Xb9suDuZlJf IjQBlLCIlHYKrz58mBaYVxhaB9X98tNA8yhn33AT1nj_wihjmG4Qcxci6JD0Jl0qLmwYu6dpF4y2 ICf2G3mVProsoAlAajD8s68GN0koOAVsjVkOizgMqyzsBdtFNf.0c1fqglwW7.vsbPp5V50iUHkd gbUqxTjbu82TPKRa_qARksr7lAV7Ej2G2K1GBdfuP_d0uLwUL18CKp9mRsyCyAoPUGG0MAZN8_Re N2Us4XvlEEsHUjVOVeg_E1AeowAShvUb43MKCl1kGkJi7uJ_5gzUUzkfXUYxsP1RKD2MyzKs.gjd vYlDiNugCc4HLXcm8qqpwpuFR0uklkDd3_hT.av6zoKy5jgU6c2axsExMPpEINCAsztzJnd3C6J1 3XlS16A8s4.iwCvcWKzt.YG1kcbWrR051C1YmA2zbfJ9mwsAIIxiovT2SFMzh9aqZ6IHRt60X2Cb c_3QsroGKtrHApdKpP_qHJSddkYK3n_NOMn7XqHcCGWJRp3_rJcUnQrC7KF_.XcEtLhpXQWgQGg3 M5rhpXFwOxKAYsGR.eEWeJOe5bmlDoAPsR1.8omZ0OqE3cCYMonlvk1ta23BsG2Ic0u7x38b5QIm ExMmoGfaniQzycs0DT7t3CUTllIpf8xXtZnMylDBmowNhgOxs3Yiq8syquCsNAai5_NaMJDsP5Uv veNRkaDxrx_TSx46AnKr8A159mWxYhIHpiNeooixX4JuJN6SjwCqnPmx5WVpabSymtweNye5OV4l 59eUVs.ksqqgUndjza4KUgETGFkaDmYwkqyZuux5vnZldGoDXTj45tQUTzkZzVcggb0gzr4Vmq01 d X-Sonic-MF: X-Sonic-ID: 90a01516-1769-4e23-b980-4b576a49c66b Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Jul 2024 03:49:20 +0000 Received: by hermes--production-gq1-799bb7c8cf-cvhk6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b3f95e0e59f30c50daea71cc2fe4aca4; Tue, 23 Jul 2024 03:49:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck From: Mark Millard In-Reply-To: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> Date: Mon, 22 Jul 2024 20:49:08 -0700 Cc: mmel@freebsd.org, FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" Content-Transfer-Encoding: quoted-printable Message-Id: <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> To: Michal Meloun X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.73 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.734]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WSjnb0LPjz4LFY On Jul 22, 2024, at 12:36, Michal Meloun = wrote: > On 22. 7. 2024 19:27, Mark Millard wrote: >> On Jul 22, 2024, at 09:41, meloun.michal@gmail.com wrote: >>=20 >>=20 >>> On 22.07.2024 18:26, Mark Millard wrote: >>>=20 >>>> On Jul 22, 2024, at 06:40, Michal Meloun = wrote: >>>>=20 >>>>> On 22.07.2024 13:46, Mark Millard wrote: >>>>>=20 >>>>>> On Jul 21, 2024, at 22:59, Michal Meloun = wrote: >>>>>>=20 >>>>>>> I don't want to hijack the original thread, so I'm replying in a = new one. >>>>>>>=20 >>>>>>> My tegra track current, has been running 24/7 by building = kernel/world and kde5 in a loop for a few years now. But I have never = encountered the aforementioned lockup in native armv7. >>>>>>>=20 >>>>>>> I have seen usermode mutex lockup in arm32 jail on aarch64, but = only very rarely (once a month or so) and all my attempts to reproduce = it in a more deterministic way have failed. Also, I don't think I've = ever seen this with the debug version of libc. >>>>>>>=20 >>>>>>> Unfortunately I also failed to reproduce given lockup using = dlopen_test.c, neither on native armv7 or arm32 jail. >>>>>>>=20 >>>>>>> Michal Meloun >>>>>>>=20 >>>>>> What is the output of: >>>>>> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ = 0-9]|.*_rtld_get_stack_prot)" >>>>>> in your armv7 context(s)? Does it include for likes of: >>>>>> QUOTE >>>>>> Symbol table '.symtab' contains 911 entries: >>>>>> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 = _rtld_get_stack_prot >>>>>> END QUOTE >>>>>> ` >>>>>> vs. not? >>>>>> Note that the "debug version of libc" being involved likely means = that >>>>>> DEBUG_FLAGS was defined. That in turn likely means that strip is = not >>>>>> being used. In such a case, I expect that the .symtab entry for >>>>>> _rtld_get_stack_prot (and more) exists for such a context. >>>>>>=20 >>>>> At tis time, I have standard (thus stripped, non-debug) version of = runtime linker library installed. Thus it have only dynamic relocation = record for _rtld_get_stack_prot: >>>>>=20 >>>>> root@tegra124:~/dlopen_test # readelf -a /libexec/ld-elf.so.1 | = grep -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" >>>>> ELF Header: >>>>> Elf file type is DYN (Shared object file) >>>>> Entry point 0x1449c >>>>> There are 10 program headers, starting at offset 52 >>>>> Program Headers: >>>>> There are 23 section headers, starting at offset 0x1a448: >>>>> Section Headers: >>>>> Key to Flags: >>>>> Dynamic section at offset 0x19fa4 contains 15 entries: >>>>> Relocation section (.rel.dyn): >>>>> r_offset r_info r_type st_value st_name >>>>> Symbol table '.dynsym' contains 27 entries: >>>>> 5: 000000000001ba0c 16 FUNC GLOBAL DEFAULT 12 = _rtld_get_stack_prot@@FBSDprivate_1.0 (11) >>>>> Notes at offset 0x00000174 with length 0x00000018: >>>>> Histogram for bucket list length (total of 6 buckets): >>>>> Histogram for bucket list length (total of 27 buckets): >>>>> Version symbol section (.gnu.version): >>>>> Version definition section (.gnu.version_d): >>>>> Attribute Section: aeabi >>>>>=20 >>>>> ------ >>>>>=20 >>>>> root@tegra124:~/dlopen_test # ./dlopen_test >>>>> root@tegra124:~/dlopen_test # >>>>>=20 >>>> Just to be sure . . . >>>> Did you at some point "pkg install cairo" (or analogous) so that >>>> the following (or some vintage) were in place? >>>> # ls -lodT /usr/local/lib/libcairo.so* >>>> lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so -> libcairo.so.2.11704.0 >>>> lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2 -> libcairo.so.2.11704.0 >>>> -rwxr-xr-x 1 root wheel - 1118272 Apr 29 19:45:15 2024 = /usr/local/lib/libcairo.so.2.11704.0 >>>> # file /usr/local/lib/libcairo.so.2.11704.0 >>>> /usr/local/lib/libcairo.so.2.11704.0: ELF 32-bit LSB shared object, = ARM, EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 = (1500018), stripped >>>> (Installing cairo would also install other things it needs.) >>>> For the failing contexts, the a.out from dlopen_test.c will only >>>> hang if the library (and what it requires) is actually there to >>>> load. >>>>=20 >>> Yep, i have cairo installed (but compiled from sources, not = installed by pkg). And i have verified that dlopen() return success. >>> In the meantime I tried all combinations (debud/stripped) of ld_elf = and libthr. All combinations work without problems on the native system = and in arm323 jail. >>>=20 >> Thanks for the information. My personal builds, which are the >> ones that work in my testing, are built on aarch64 as armv7 >> instead of on amd64. The known failing ones are built on amd64. >> But I've no more specific information suggesting a tie to the >> type of build host for the world used. >>=20 >>=20 >>> Btw, gdb has long had problems with stepping inside ld_elf. It's = better to run the test program without it and connect to the test = program to get the "correct" stack trace. >>>=20 >>>=20 >> In part I was deliberately exploring what sequence leads to the >> hangups vs. lack of hangups and the like: more context than a >> backtrace of the stuck state can provide. >>=20 >> But doing "./a.out &" and then "gdb -p..." to attach to it: >>=20 >> _umtx_op () at _umtx_op.S:4 >>=20 >> warning: 4 _umtx_op.S: No such file or directory >> (gdb) bt >> #0 _umtx_op () at _umtx_op.S:4 >> #1 0x2036845c in _umtx_op_err (obj=3D0x4, op=3D12, val=3D0, = uaddr=3D0x0, uaddr2=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libsys/_umtx_op_err.c:36 >> #2 0x20115da8 in __thr_rwlock_rdlock (rwlock=3D0x4, = rwlock@entry=3D0x20137c40, flags=3D3, tsp=3D) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.c:294 >> #3 0x2010ebf4 in _thr_rwlock_rdlock (rwlock=3D0x20137c40, flags=3D0, = tsp=3D0x0) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_umtx.h:229 >> #4 _thr_rtld_rlock_acquire (lock=3D0x20137c40) at = /home/pkgbuild/worktrees/main/lib/libthr/thread/thr_rtld.c:121 >> #5 0x20060788 in rlock_acquire (lock=3D0x2008af10 , = lockstate=3Dlockstate@entry=3D0xffffd114) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld_lock.c:259 >> #6 0x20059098 in _rtld_bind (obj=3D0x2008f404, reloff=3D496) at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/rtld.c:1035 >> #7 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 >> #8 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 >> #9 0x2005483c in _rtld_bind_start () at = /home/pkgbuild/worktrees/main/libexec/rtld-elf/arm/rtld_start.S:89 >> . . . >>=20 >> It does not seem significantly different than I'd reported >> for the hungup state. >>=20 >> An issue here is that the pkgbase world possibly is -O2 based >> despite having debug information (but is stripped). This can >> make details less reliable. So, for example, the rwlock=3D0x4 >> vs. rwlock@entry=3D0x20137c40 for __thr_rwlock_rdlock could well >> be suspect. >>=20 >>=20 >=20 > IMHO, -O2 shouldn't be able to modify function arguments for public = functions, so this memory corruption fits perfectly with the = observed behavior. It is not a memory corruption. r0 is "argument 1/scratch = register/result" and the code in question in my example is (__thr_rwlock_rdlock via disass /s = use): 280 { 0x20115d50 <+0>: push {r11, lr} 0x20115d54 <+4>: mov r11, sp 0x20115d58 <+8>: sub sp, sp, #32 0x20115d5c <+12>: mov r12, r1 . . . 291 tm_p =3D &timeout; 292 tm_size =3D sizeof(timeout); 293 } 294 return (_umtx_op_err(rwlock, UMTX_OP_RW_RDLOCK, flags, 0x20115d98 <+72>: str r1, [sp] 0x20115d9c <+76>: mov r1, #12 0x20115da0 <+80>: mov r2, r12 0x20115da4 <+84>: bl 0x201167a0 =3D> 0x20115da8 <+88>: mov sp, r11 0x20115dac <+92>: pop {r11, pc} After the "bl 0x201167a0" the value of r0 is the return value from 0x201167a0, not the first argument value for 0x20115d50 . A better reporting would indicate that rwlock was at that point: locally the value has not been preserved at that point because there is no more use of the value. But such is the kind of thing I expect to run into for the likes of -O2 use with debug information. Anyway, _umtx_op_err returned the 0x4 value that is shown for rwlock . > But , out of curiosity, a quick look at _thr_rwlock_tryrdlock() in = thr_umtx.h:208 makes me wonder: How is the "state" variable inside the = loop guaranteed to be updated? IMHO nothing inside the loop emits a = global memory modification attribute, so the compiler is free to move = the assignment to a "state" variable outside the loop.=20 > Kib, please, do you have any comment on this?=20 > MIchal Meloun =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jul 23 09:36:42 2024 X-Original-To: freebsd-current@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 4WSsVf26Xcz5Rcmc; Tue, 23 Jul 2024 09:36:58 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSsVd1fypz4rVT; Tue, 23 Jul 2024 09:36:57 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46N9agKt093429; Tue, 23 Jul 2024 12:36:45 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46N9agKt093429 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46N9ag8b093428; Tue, 23 Jul 2024 12:36:42 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 23 Jul 2024 12:36:42 +0300 From: Konstantin Belousov To: Michal Meloun Cc: Mark Millard , mmel@freebsd.org, FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: / X-Spamd-Result: default: False [-0.40 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; NEURAL_SPAM_SHORT(0.10)[0.098]; RCVD_TLS_LAST(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[kib]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; TAGGED_RCPT(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WSsVd1fypz4rVT On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > The good news is that I'm finally able to generate a working/locking > test case. The culprit (at least for me) is if "-mcpu" is used when > compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > If it is not used, libthr is broken (regardless of -O level or debug/normal > build), but -mcpu=cortex-a15 will always produce a working libthr. I think this is very significant progress. Do you plan to drill down more to see what is going on? From nobody Tue Jul 23 17:46:51 2024 X-Original-To: freebsd-current@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 4WT4My1FK4z5SJKg; Tue, 23 Jul 2024 17:46:54 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT4Mx6Zr7z4lwV; Tue, 23 Jul 2024 17:46:53 +0000 (UTC) (envelope-from melounmichal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-426636ef8c9so41805895e9.2; Tue, 23 Jul 2024 10:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721756812; x=1722361612; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:from:to:cc:subject:date:message-id:reply-to; bh=T/OxNgsLkcDjtcabClmbDUS6GHlRL4lIOJ6tDCdO+6M=; b=ebx7omKUmi7Ib6FZbmvTJEGj9l8rZhofgkqFZEcg27OlmGXtXanto5IGZwPCjTr+Ci DTjGSOYmo/6Di+lGZiHVa9ErayL2lFuTgCWw4tdU/TvDolILSKnNrEpPfeNnMubDauIM 89uU3UjL1yYRqz/0PIVeHUNooT4rRaydXKFef5mPp7U1NcNNsFYI0ArBIuCDD3b7tc2V cWVvyUm+QhjDmx7/3VFE94fCaxs65PNvU2TSzAwcBZxZBbCQKzbb4dzLY//V6czbYoAL 4UNaUBs0+14kmFxvvPa7IVRLI5aHSPNDwoU9CLTbMi2Ynbcf992VgMU7aqsnOBONBg88 EFWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721756812; x=1722361612; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T/OxNgsLkcDjtcabClmbDUS6GHlRL4lIOJ6tDCdO+6M=; b=d6o2HJWTS/FRwn5clM1wksqWV3AREXCZe6EfMMiIEe6hBUo9FHGWS1ZC/4xR3OTVI3 GpPSxxHKq7ExkHpTT6Oa5OhbYIkjFXhU7JkPh/uiDv254YqqMvjsRtiYS3bgbpHBhmgk W/IIgjCA5nj+N3Hr6oERERUgz/qhi4w6VahGMjk5uxylfueRAABlyWDTXmTcpAnzrFH4 8J0DLFi/JY5b7j3Ri5XXHFdRM9tWmSGg7gnWOEXc/lvsUUuiZ9dTKPhF7x4DOXltogj0 Lhi4hGwOo/2MqNuFZbgjjaZAKeHstECYg3QgLBoDTjqLHZSqsKpqwliQPZW4b2NI5IV+ H+AQ== X-Forwarded-Encrypted: i=1; AJvYcCWTQn9K1UifCK5PrQEr7iHoiGXWuu46EiYFfYSWG5h7ROtdkBzc1uEZzooAHdjffHRGt76qjkm4YVwJYVXT7v76f+36h4zdagMT88N2We1LjZBjoCLy8S4+wG8vdsaLPECsemUF X-Gm-Message-State: AOJu0YxJ2dwF96if0t3fgCUuIPyN+U2er2UNmGQl2R4D8TeYnUaWtjCc bkXFL4QS2OxvuSlJcIl82SF/maR4t6ELxrLkCZStpMyCSvMVyjEF09JNAdSA X-Google-Smtp-Source: AGHT+IHvAIHzW/78+lvjhwenOnhTP45EJu9CXBEUesogv7ExlBYkEexSDswDU2nPeJSirBq/RFt8wQ== X-Received: by 2002:a05:600c:4f4d:b0:425:7796:8e2c with SMTP id 5b1f17b1804b1-427dc520498mr64200175e9.12.1721756812415; Tue, 23 Jul 2024 10:46:52 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:55eb:52e:1154:1d18? ([2001:67c:14a0:5fe0:55eb:52e:1154:1d18]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-427e29d11d5sm116168975e9.38.2024.07.23.10.46.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jul 2024 10:46:51 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Message-ID: <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> Date: Tue, 23 Jul 2024 19:46:51 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@freebsd.org Subject: Re: armv7-on-aarch64 stuck at urdlck To: Konstantin Belousov Cc: Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4WT4Mx6Zr7z4lwV On 23.07.2024 11:36, Konstantin Belousov wrote: > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: >> The good news is that I'm finally able to generate a working/locking >> test case. The culprit (at least for me) is if "-mcpu" is used when >> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). >> If it is not used, libthr is broken (regardless of -O level or debug/normal >> build), but -mcpu=cortex-a15 will always produce a working libthr. > > I think this is very significant progress. > > Do you plan to drill down more to see what is going on? So the problem is now clear, and I fear it may apply to other architectures as well. dlopen_object() (from rtld_elf), https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. In this case, it round_up() in _thr_stack_fix_protection, https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. Michal From nobody Tue Jul 23 18:08:46 2024 X-Original-To: freebsd-current@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 4WT4sN16Wdz5SLcG; Tue, 23 Jul 2024 18:08:56 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT4sM4RBvz4qjB; Tue, 23 Jul 2024 18:08:55 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46NI8k1o016912; Tue, 23 Jul 2024 21:08:49 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46NI8k1o016912 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46NI8kdU016911; Tue, 23 Jul 2024 21:08:46 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 23 Jul 2024 21:08:46 +0300 From: Konstantin Belousov To: mmel@freebsd.org Cc: FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4WT4sM4RBvz4qjB On Tue, Jul 23, 2024 at 07:46:51PM +0200, Michal Meloun wrote: > > > On 23.07.2024 11:36, Konstantin Belousov wrote: > > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > > > The good news is that I'm finally able to generate a working/locking > > > test case. The culprit (at least for me) is if "-mcpu" is used when > > > compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > > > If it is not used, libthr is broken (regardless of -O level or debug/normal > > > build), but -mcpu=cortex-a15 will always produce a working libthr. > > > > I think this is very significant progress. > > > > Do you plan to drill down more to see what is going on? > > So the problem is now clear, and I fear it may apply to other architectures > as well. > dlopen_object() (from rtld_elf), > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > holds the rtld_bind_lock write lock for almost the entire time a new library > is loaded. > If the code uses a yet unresolved symbol to load the library, the rtl_bind() > function attempts to get read lock of rtld_bind_lock and a deadlock occurs. > > In this case, it round_up() in _thr_stack_fix_protection, > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). > > Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> > in any place, and I'm not sure if it can resolve all the symbols used by > rtld_eld and libthr beforehand. This is a common issue, we pre-resolve a lot of symbols to avoid lock recursion. Please take a look at lib/libthr/thread/thr_rtld.c _thr_rtld_init(). From nobody Tue Jul 23 20:11:13 2024 X-Original-To: freebsd-current@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 4WT7Zb0n3qz5QKj0; Tue, 23 Jul 2024 20:11:19 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [IPv6:2a01:111:f403:c111::9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7ZZ3FM0z4CW4; Tue, 23 Jul 2024 20:11:18 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pkXZ5p9F9qagekLy0OaY75GEgYHvhWs7LraeNLbCqHJtsFen0ozn5KHn+gctV/CaPLqA4yXV75kr3bOSByKpROhk1xdgK8OPGRv9jcs28pXd358Wldh1z512AbvJMRuL3k0gZMhDTXQdQpMiiRHcrmaF8+tBU8LrrN+y0/rCPDlb8ImW8a38gH0b2trhvMDO08rlX5QNgDRaxAwE1zdtF/D5WmXKl+6b+D8aWr+F7rtUB5zr8ISD/9084W96cxrX2hl9vebC9kYdF1jRsDWc6DcdC6KG6BsDnM/VWKcw8xfMYuqfbzgEKiQ6gYWiIKbH634AMuEVr/pdQFy4jt9t2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+plYhsLWINIA4XeQ8sxA6k8eBrmXrWwzZjHPndbm9I8=; b=WARfIAWOUabRsUXSAOhlVCQrQpJIMfsRrtTefTzVJbWZ+8U6fBaeY+n/JaEEN6PYhQXKr+1tSfhd51iocJkwAj2c0IbVlZSC9l8R3XfIhKGQ+wIHTZfidu1c1IycqbgvV+t9Qht8DXxfKO2PpkJpvLL3kXM+p14X7wi+UbKG+2J0AewwRaz3vMm+ClokWn4YanQmM9lO5NRojbNbOMeGejOWQXjQ9ZUhWCCjFHDRiIaAZqrOGrp6HLnPeuekvEHdmmCXLpU6hKQ9/mmoPBwtbOkzXTNlPSJAD4EkiRdvgkYLZYhNBlaxYaL/VlfRGNxsw6EXWHT3gqvkO1QY5zPtCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+plYhsLWINIA4XeQ8sxA6k8eBrmXrWwzZjHPndbm9I8=; b=dRYze598b4FG3pnbgOTpcJeWvwoBCTfuhxcST6qBAOxCTo/afaKOT0GsEjIUQk0sr792mitCbs6r79rJFNR40XnQzCoCn3/+26tqWoc08ZaeiXw6h+zz6ahEXHec+3E8mX2tGdCkx56SV7SeoGfIYLpNm2zEcpL4Fm0SvcOSX38= Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by SJ0PR01MB6301.prod.exchangelabs.com (2603:10b6:a03:29e::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.20; Tue, 23 Jul 2024 20:11:14 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d%6]) with mapi id 15.20.7762.027; Tue, 23 Jul 2024 20:11:13 +0000 From: John F Carr To: "mmel@freebsd.org" CC: Konstantin Belousov , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Thread-Topic: armv7-on-aarch64 stuck at urdlck Thread-Index: AQHa2/xL/eBpVtdzuUaKV+38IPbVfLICobiAgAAf4ACAAC4tAIAABE8AgAAMwwCAACPzAIAAiccAgABEVICAABzIAIAAiPOAgAAoSAA= Date: Tue, 23 Jul 2024 20:11:13 +0000 Message-ID: References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> In-Reply-To: <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|SJ0PR01MB6301:EE_ x-ms-office365-filtering-correlation-id: af333be8-0f0f-48ea-1088-08dcab539a2b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?mpAqdbqvPJwIffV9FJ7GUjwycV2R1ntgGz8qf1/rTxeBNVfqbCjn/Ru0Y0E0?= =?us-ascii?Q?NIk4XpLhfgdo9CfhKbIhnyC55V34Tiwzsb3VGrYLkoFlgFKBupGj/LPnPyJH?= =?us-ascii?Q?RyoJ1lEIjzE6Kmh4Ct+kNoK70i4yMws5z+1geoBXygzl5eDiGw/U+XTm9rsJ?= =?us-ascii?Q?YH3J9U3hSGSD45Fyz7fz/IrmhjVMR48eqBJyjYq9fdWqr3/82MdaO7KxStfo?= =?us-ascii?Q?Vs6t+Ag/TeHGaVkHtBt8uaXuqlfM+hGCzKNy3Gh+ZwJqlK34SfdPXS4a8ny9?= =?us-ascii?Q?W4tz0wj9cSflOXkAJ5hSIpMPYHEbiav308nOI2Xdc7UkfJRqycr63YlOGmDC?= =?us-ascii?Q?MfG9w7uIjGoOsZ82cUg3Wd5dNfqivvmxB+AcKYwKP0pQetsfBKoEwUEFRvWg?= =?us-ascii?Q?xVSm5OCsDUcqVRsLfLkXzymxZLbVQft3q4+/X/zd1U5/0QiMKnnkvuHUiUAA?= =?us-ascii?Q?33SEIEtXzELIHEOjYwgrDWYPpLS3NUA4NcsniDLNEm87MnEabU2HqZBpIz86?= =?us-ascii?Q?2TaILhHzkmP83tASHbyy0Y7vL+WeOQpb7Cor9orSYWHJLwS/EbxBvYKwh/Xt?= =?us-ascii?Q?H16JYxIadCw9bXUtx8e4n/tKtIl/Sit+iB7Ub+mGBYxWIG84Jfq3Rc2fZVyp?= =?us-ascii?Q?9fbTJnUucJgKldjMjUMxbmABVqBni7vZPmph1GajadnBINnt1h3DJRIcHY3x?= =?us-ascii?Q?tOZFWWelmDdoPzG+zl3t6fVKzAU4ppMBlszAhFTfvV+Qn1D5C3B3RDe0tUyL?= =?us-ascii?Q?ig3yCGQUT7CD4pOm9V/rD/2EntvP+SwiP0muFUGCv0/BpF7UolGvf+jgS41s?= =?us-ascii?Q?D0eYp4gcND66LurS9MdIs1EJwBIQVuRijPB1lyk+Z5kwJMhGlpViW78sa/Uz?= =?us-ascii?Q?60H0F5AAAxrD6DczxeVYpywZ9M272Tz5B/0HiwoUXzjGMSQkaFmMOwhp4HzZ?= =?us-ascii?Q?6kl9Ie4X2PfYu8yzV6vcFyIaAeJ18kFM3TV8ItNn2w63OXECDkVNbND3k3Z4?= =?us-ascii?Q?hlE1WOTXY0M1KSsRuLPGZEcVNfk44sJMWtC0W5cAo86k4EDub89NONTT4/iS?= =?us-ascii?Q?Y2etkV0Lgw8w0f+kBuqKlYxwLdRPrMqdrAVau1veifgX4NGkZ7U4WurFq52h?= =?us-ascii?Q?5hD/csGSLus1aVn0SRiwSDLyehmLAz4rV5blI9j0QCQZaG0wESnBzxfloC7X?= =?us-ascii?Q?7B8/mgRAa9bepmqzh8PWdcakuJHf4ZFeo0Is/wJEAnO+c1RrDyqNRqvx7NHj?= =?us-ascii?Q?Z1r2ErQ+TdyMRinpJIwnOhkau+hpjf1UZ8HPrejR8uf6R39CFADVVIhj77HO?= =?us-ascii?Q?9bLJqPZhpDpwNN/8I86ICi2rvq0HRtDnz+EVHnigM8ZzAc/Nk2/cFPsbuMZ0?= =?us-ascii?Q?ksELpEA=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5EUEuPftSqRC0Z6qVzQVTCcJH89Mk+cjH9l8JCJ+Jx9dFJPtjDCFKyfLN2Im?= =?us-ascii?Q?c/qG4eNQKaaYlVm3a0di6OuUXNCUKpQ45mVFyydPSUEETA8C0UKVaHw+9+fr?= =?us-ascii?Q?n3bLIKGRkrGUfx6nLrZOGLMQjx6yqIK9D7qtBmpSrIhzpm9ap61dy8nGUpRE?= =?us-ascii?Q?nGsrOj0+MGki87o7Ak35vk8FwUQIuNlhoA4GQoXnf7kjUpzQH/FhrTIzjaht?= =?us-ascii?Q?olMrqKjlUtQTBshqvzb0U6frUjK4FHHjkPsludrtkq33tZksZI5q09yxOv7W?= =?us-ascii?Q?bKZDZKSA8qskPVA5KP+WP3QjC5bwanVmiZh1Vd0gMnpfVl4NbVlJn6rKGFQg?= =?us-ascii?Q?Yqw1287uwl+umcdDr2Dtnu+hUcFnjFZA5qU1KR9OAToFZryMbvLQO9EZSG47?= =?us-ascii?Q?rw7BjhfrbFBdEkqSPP/yo7Zto6dDHg3gP9Txj5IYbAUviV2TODDEQjdO0MM3?= =?us-ascii?Q?GGynn0N+WGZOHU0o4mG1a+Dk2YI0w7Ufi7xjdlWP85BpDlXf5jwa/RT54OYY?= =?us-ascii?Q?wV6k3cxj3IELEjycbCXM6o1DsBZzKfu8jL+wNN7+wAOpsRoWcrcxNo457Crg?= =?us-ascii?Q?7C5sTajq73inqP/IttTiUYeJzxcqYp3ClwWSHz6ow4ldBoBhYzB4r6o15aIa?= =?us-ascii?Q?gX+KsIPanrX3380Sl53Epc7zqA9EUXYJUt0KxBWsv9pzQ7CFnWVOafr9dZV0?= =?us-ascii?Q?mqf1/Q8kN3YdRMYeEcMlJ9xLb2Wbj7Yl77tZc3C4g9WNoOBrXBOKaytBF2CD?= =?us-ascii?Q?lrGmqXOeKpN22BDhVOyexTNhx2FOqjgupBivcPY8cq97BRLtS4b/0hDIVUwZ?= =?us-ascii?Q?IlKiLbjsSa0cB2zQknE7nMUZ904vQCYrB7daJu7h+tBqi9wiO++V4mtbB8JO?= =?us-ascii?Q?LXzGcNP/ePRQW68w+i3NnaMffwzxgCkE0bEsEIC5tYO93Gc12U161/BIryu3?= =?us-ascii?Q?8+awcYu3jRihhAc8h95fsIr+GSM56uQvGM/tnP5s3G2nOG5xAbkmAPQ5zIB/?= =?us-ascii?Q?tl1lVjKLvVf6WnmPxKnOSwv/QlaxsY39n4+ovnuzjMEC+Ico5J9DywuD0P2+?= =?us-ascii?Q?uPpslrwbtO9elRQokA+l1Gdfzc4oSRqvHbgt6UtMDNT9ol/0wEENEpubLpyv?= =?us-ascii?Q?Mi0ai7UsThwikEiJBodY6gmdOtQwg85gx+mTexq8oVqjig2El58v6+kzSB4s?= =?us-ascii?Q?6FK6jmh7kmPf2gWNXDenDmyp5JTTXcvWkCxlndwq6YnUTJtUxFAoqQ8KKaBT?= =?us-ascii?Q?htS121MV0lAqenyF/ssR2EwP0A+9jRWd44ry2mfenmhPfjTFn9XUdzrRrpCJ?= =?us-ascii?Q?5feCV6Hxnqlgs96xyYix0R34nKWX0vXGirigkNnVExJpNDRKvrxHVMyvwz7f?= =?us-ascii?Q?eoCSXQi4cXLjhyrrQoOSK6PLjljFj69bCOB3Y/2tm4sJqFrioCsJ08aJbzwp?= =?us-ascii?Q?fmrkMXqFl5XyqQqh2DEUAM6EVAwnUlYsg/ijXyEtUZMAz5d12UYkBLzOoyHz?= =?us-ascii?Q?gIhXIVWASmdBlrGzuhAnXD1Qc5ZeECDa2oH2vHc9WuL0Yo3soNOr1BLtDzNj?= =?us-ascii?Q?kPYTEp5bZzuiPDhGkldDhK/NllFYdGFEskUdijg5xpy086PzlUN0VPpHC2fZ?= =?us-ascii?Q?MBe23r2gYKJZYVKm87rinb5N1DL+k7ygE7yGEm8gNNdi?= Content-Type: text/plain; charset="us-ascii" Content-ID: <3C1289ACC911024FA23CCA9F8DC63333@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: af333be8-0f0f-48ea-1088-08dcab539a2b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2024 20:11:13.6466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QLj36hS/OJQpxOXWIkulHPASiK//m0GjKq5VaXaXYzpQ2GmbXtdIrLySH2+0Debe X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR01MB6301 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US] X-Rspamd-Queue-Id: 4WT7ZZ3FM0z4CW4 On Jul 23, 2024, at 13:46, Michal Meloun wrote: >=20 > On 23.07.2024 11:36, Konstantin Belousov wrote: >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: >>> The good news is that I'm finally able to generate a working/locking >>> test case. The culprit (at least for me) is if "-mcpu" is used when >>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.con= f). >>> If it is not used, libthr is broken (regardless of -O level or debug/no= rmal >>> build), but -mcpu=3Dcortex-a15 will always produce a working libthr. >> I think this is very significant progress. >> Do you plan to drill down more to see what is going on? >=20 > So the problem is now clear, and I fear it may apply to other architectur= es as well. > dlopen_object() (from rtld_elf), > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > holds the rtld_bind_lock write lock for almost the entire time a new libr= ary is loaded. > If the code uses a yet unresolved symbol to load the library, the rtl_bin= d() function attempts to get read lock of rtld_bind_lock and a deadlock oc= curs. >=20 > In this case, it round_up() in _thr_stack_fix_protection, > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide= ). >=20 > Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi= _<> in any place, and I'm not sure if it can resolve all the symbols used b= y rtld_eld and libthr beforehand. >=20 >=20 > Michal >=20 In this case (but not for all _aeabi_ functions) we can avoid division as long as page size is a power of 2. The function is static inline size_t round_up(size_t size) { if (size % _thr_page_size !=3D 0) size =3D ((size / _thr_page_size) + 1) * _thr_page_size; return size; } The body can be condensed to return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); This is shorter in both lines of code and instruction bytes. John Carr From nobody Tue Jul 23 20:39:23 2024 X-Original-To: freebsd-current@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 4WT8C25cZvz5QNT1 for ; Tue, 23 Jul 2024 20:39:26 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT8C23gKTz4LcR; Tue, 23 Jul 2024 20:39:26 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721767166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nIa/Ah13ops2tryTV7D9NuZZto4vrN2XLa4vEpGzJ1o=; b=gjRiXCEPJsufAyl8fhcUCPjjVvi5hOgTKrLPYtvcOiRiy5Gq6tQsXm+/03AoW4Cx7YVjUN xpsBlmnVw6iVhwt6+yyLyuYcKGQmqZJj8Y1GLpHLT6EHNfgm1Uip0i6qKz9eJSjSgWPzGg c5YNkhqQEeCcfrSL+ksKnIWQ4CIOB9iBuoOrjW+mI96hmsWb3YeiQmZczUh78/I9L/POer 2uSuJrgBkWOaVkajtTBjSWkvWpiOGeLCzvg7K4qHBuRx+IR4Dl/U9kOPaBpE6ImFZcVnfN 02HdbWdOukkqac4EuPY/dTDhXn4xzx4OpApG+u/jNour0nWumvzWVeTnMv1hXQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721767166; a=rsa-sha256; cv=none; b=GNyDn1q+nclghI/VNUmXk/lWdUetZIEUmgAQf7wS1mEUQrB0lf6lbtbhE70iKLRRTwHDwe Nnz1xmcJcFjXdDaJrtI+VN6EVOcrj/FESrz1O1xpFuOIW+Sm/a+JzD2lg/oTj2DT6WbCaa X4htorStLHqHSNxRt0U41EC+Edw+HdahdQIXPdZnel9TpqWTiHqrYyZbT+tlJmVBv18lQg DyM5qpaNkY/riw/f2qvEy3JnIBoLeeQ15YcGCROtz7NlOClF0mDRN6yW+NqNMzCrip3BXs WOM3S74nd5nqaO7YDKqMBiGv8HtiTcQZBGc8PBjQmUJTGK+OWcPWprlAXi/0OQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721767166; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nIa/Ah13ops2tryTV7D9NuZZto4vrN2XLa4vEpGzJ1o=; b=IAlYVfQNVSjGbNotsdrpHMQEKFW4Hg3QD4fkfWb7JXpYCWH90QI0jhlyjDGl79dVKJsFCT nptT/3Skk/coRajgSBp/MxVUGkqPW6C6+0uIUDiVRbsvG4hF8Pt3iHfzDVcC5nCLuzR5AF Gz7sh0NmJlJRIMROJRCqrt/0Gh7mDFgROoZ7cjHODMBNvxQe6w0G+L42sBRvD6J+h5TZt8 SU2MfFQwEqps2ZiRGqXa9Ln7LLxq5Wku85NHXWRw5kMlzfp6ZI+rDNeTUjvltKGyFS92qe nC6gC0G5vPn8osSb93hEzCDqY2Hi+CDz6l+iwtSVpwSEK8StxJ3t09CJ/H4I1g== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT8C206VnzFM3; Tue, 23 Jul 2024 20:39:25 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 23 Jul 2024 13:39:23 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: wulf@freebsd.org Subject: Re: July 2024 stabilization week Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the July 2024 stabilization week T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as T> main-stabweek-2024-Jul. Testing at Netflix didn't discover any stability or performance regressions compared to June stabweek snapshot. My personal use in a desktop environment also didn't show any problems. Everybody are advised to update their FreeBSD 15.0-CURRENT :) There is one bug report that seems to be a regression: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280290 and it is related to hms(4). Unless we receive any regression report in this email thread until Wednesday morning at 8:00 UTC, let's declare the stabilization cycle done by that time. -- Gleb Smirnoff From nobody Tue Jul 23 20:54:46 2024 X-Original-To: freebsd-current@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 4WT8Xz38Pkz5QtyR for ; Tue, 23 Jul 2024 20:54:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT8Xz0FQCz4N9D for ; Tue, 23 Jul 2024 20:54:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2cb81c0ecb4so181562a91.0 for ; Tue, 23 Jul 2024 13:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721768097; x=1722372897; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cz8R2UYvv77GONRqv65jCsmANNFDPXoWDq/mo087bpc=; b=OleAi1Xqcp9ifZPsOPEBnT5P/htJtoCBN6qlBaehgG2al71n0hBX8kjwgVAEUQ4yHc 39WtaWuCnd2ziCMoZ6P+dZsMDBVZZdSIoA/qIUn3cema57w7wQ7lEffcULQJqB08JXi8 fnFOjK2QK0bxatCS5VHbsHj7StY2p/X2XriBvRP1pDy2dzRl0hyPvNXClFNlPc9DqAIQ n5iLA6roIUnwiY6hGGWoPYK8ChuZzFb3K/ABfNKq34uCGA1zjVU+PiEbBp6JSonMVP/g KSvP6Jv/fzRp9tJuDCkfnXthf4s/Yh/iO/JmymYFsPtQhUE8OlcB4gqDmwseS3SBCesn XivQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721768097; x=1722372897; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cz8R2UYvv77GONRqv65jCsmANNFDPXoWDq/mo087bpc=; b=Xv61DbKhU3SOnqsJc7e0OMVWY6u4i5llKLCEws7wQyysr4zhpT/av2L6VD2h6RnKL3 joNTow+vAapIByPD2JElb3detFZkXy1T+OWQlBNCBqX3D43ICmEhZOFiPd27frQNR+a7 6Ez+zh0e9EtvorxsKxrKemq3jKSIllgUs1S6T2Kb+/U6fHR1hof0DO/u3PRdh7SgtY6n zJ4kuuD6UHyGFRbjPORBWo6L82lRUCeS7+7XlSftHpmSAS4ZN1bGU/iECq4wEsWnf6PS yYPxB4cZBrAzqWDZoSnaEDQx0wlKwgOeQ2msZdAPrgSYo5Zxkgs8vx33dNzvxzRY0x9n vCiw== X-Forwarded-Encrypted: i=1; AJvYcCWqz6KXoQsDBLXxYUNBAAdvjBkrNt7vN8n1MKwgdOrerr82kj85ArRCY6X1j9jk/VD5EaVUeMMubxsOPX+x/eO+g5Diiy7tdJIJiSo= X-Gm-Message-State: AOJu0Yy5wdbXNLQPC8HC1JzJqk75Dbn8w8vMxHR7AeG3PBwFIxqfEbVY QErNH+MDCJLdV+TnT72fUTJ33L6Yp4UkV7GvgwDrb2sUI+/2gbzcgaMf5CNQX71Q3TGsddWgTKs BdkkZLF2evk/qpXUq8ugWN16BOjhD4sdtkN4uBw== X-Google-Smtp-Source: AGHT+IGxJ0MYUO89Zmlc7e2mvDzmOhAli8X8tRvzBI7E6CXSy4fHKxSbNCmbEp9Q+hTwctFmjWXWWD5h5R1rHuBNHC0= X-Received: by 2002:a17:90b:378c:b0:2c7:c5f5:1c72 with SMTP id 98e67ed59e1d1-2cd8ce63cf9mr5014765a91.13.1721768097254; Tue, 23 Jul 2024 13:54:57 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> In-Reply-To: From: Warner Losh Date: Tue, 23 Jul 2024 14:54:46 -0600 Message-ID: Subject: Re: armv7-on-aarch64 stuck at urdlck To: John F Carr Cc: "mmel@freebsd.org" , Konstantin Belousov , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000d2acd8061df05f05" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WT8Xz0FQCz4N9D --000000000000d2acd8061df05f05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024 at 2:11=E2=80=AFPM John F Carr wrote: > On Jul 23, 2024, at 13:46, Michal Meloun wrote: > > > > On 23.07.2024 11:36, Konstantin Belousov wrote: > >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > >>> The good news is that I'm finally able to generate a working/locking > >>> test case. The culprit (at least for me) is if "-mcpu" is used when > >>> compiling libthr (e.g. indirectly injected via CPUTYPE in > /etc/make.conf). > >>> If it is not used, libthr is broken (regardless of -O level or > debug/normal > >>> build), but -mcpu=3Dcortex-a15 will always produce a working libthr. > >> I think this is very significant progress. > >> Do you plan to drill down more to see what is going on? > > > > So the problem is now clear, and I fear it may apply to other > architectures as well. > > dlopen_object() (from rtld_elf), > > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > > holds the rtld_bind_lock write lock for almost the entire time a new > library is loaded. > > If the code uses a yet unresolved symbol to load the library, the > rtl_bind() function attempts to get read lock of rtld_bind_lock and a > deadlock occurs. > > > > In this case, it round_up() in _thr_stack_fix_protection, > > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > > Issued by __aeabi_uidiv (since not all armv7 processors support HW > divide). > > > > Unfortunately, I'm not sure how to fix it. The compiler can emit > __aeabi_<> in any place, and I'm not sure if it can resolve all the symbo= ls > used by rtld_eld and libthr beforehand. > > > > > > Michal > > > > In this case (but not for all _aeabi_ functions) we can avoid division > as long as page size is a power of 2. > > The function is > > static inline size_t > round_up(size_t size) > { > if (size % _thr_page_size !=3D 0) > size =3D ((size / _thr_page_size) + 1) * > _thr_page_size; > return size; > } > > The body can be condensed to > > return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); > > This is shorter in both lines of code and instruction bytes. > I like this change... But we do need to fix the deadlocks... They seem to be more likely when building in bsd-user emulation... Warner --000000000000d2acd8061df05f05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 23, 2024 at 2:11=E2=80=AF= PM John F Carr <jfc@mit.edu> wrote= :
On Jul 23, 202= 4, at 13:46, Michal Meloun <meloun.michal@gmail.com> wrote:
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
>>> The good news is that I'm finally able to generate a worki= ng/locking
>>> test case.=C2=A0 The culprit (at least for me) is if "-mc= pu" is used when
>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc= /make.conf).
>>> If it is not used, libthr is broken (regardless of -O level or= debug/normal
>>> build), but -mcpu=3Dcortex-a15 will always produce a working l= ibthr.
>> I think this is very significant progress.
>> Do you plan to drill down more to see what is going on?
>
> So the problem is now clear, and I fear it may apply to other architec= tures as well.
> dlopen_object() (from rtld_elf),
> https://cgit.freebsd.org/src/tre= e/libexec/rtld-elf/rtld.c#n3766,
> holds the rtld_bind_lock write lock for almost the entire time a new l= ibrary is loaded.
> If the code uses a yet unresolved symbol to load the library, the rtl_= bind() function attempts to get read lock of=C2=A0 rtld_bind_lock and a dea= dlock occurs.
>
> In this case, it round_up() in _thr_stack_fix_protection,
> https://cgit.freebsd.org/sr= c/tree/lib/libthr/thread/thr_stack.c#n136.
> Issued by __aeabi_uidiv (since not all armv7 processors support HW div= ide).
>
> Unfortunately, I'm not sure how to fix it.=C2=A0 The compiler can = emit __aeabi_<> in any place, and I'm not sure if it can resolve = all the symbols used by rtld_eld and libthr beforehand.
>
>
> Michal
>

In this case (but not for all _aeabi_ functions) we can avoid division
as long as page size is a power of 2.

The function is

=C2=A0 static inline size_t
=C2=A0 round_up(size_t size)
=C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (size % _thr_page_size !=3D 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size =3D ((size / _= thr_page_size) + 1) *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _thr_= page_size;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return size;
=C2=A0 }

The body can be condensed to

=C2=A0 return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);

This is shorter in both lines of code and instruction bytes.

I like this change...

But we= do need to fix the deadlocks... They seem to be more likely
when= building in bsd-user emulation...

Warner=C2=A0
--000000000000d2acd8061df05f05-- From nobody Wed Jul 24 10:24:09 2024 X-Original-To: freebsd-current@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 4WTVVw3R7gz5RhLP; Wed, 24 Jul 2024 10:24:24 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTVVv71H1z4Q2R; Wed, 24 Jul 2024 10:24:23 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46OAOAYA049066; Wed, 24 Jul 2024 13:24:13 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46OAOAYA049066 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46OAO9mx049065; Wed, 24 Jul 2024 13:24:09 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Wed, 24 Jul 2024 13:24:09 +0300 From: Konstantin Belousov To: John F Carr Cc: "mmel@freebsd.org" , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4WTVVv71H1z4Q2R On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: > On Jul 23, 2024, at 13:46, Michal Meloun wrote: > > > > On 23.07.2024 11:36, Konstantin Belousov wrote: > >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > >>> The good news is that I'm finally able to generate a working/locking > >>> test case. The culprit (at least for me) is if "-mcpu" is used when > >>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > >>> If it is not used, libthr is broken (regardless of -O level or debug/normal > >>> build), but -mcpu=cortex-a15 will always produce a working libthr. > >> I think this is very significant progress. > >> Do you plan to drill down more to see what is going on? > > > > So the problem is now clear, and I fear it may apply to other architectures as well. > > dlopen_object() (from rtld_elf), > > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > > holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. > > If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. > > > > In this case, it round_up() in _thr_stack_fix_protection, > > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). > > > > Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. > > > > > > Michal > > > > In this case (but not for all _aeabi_ functions) we can avoid division > as long as page size is a power of 2. > > The function is > > static inline size_t > round_up(size_t size) > { > if (size % _thr_page_size != 0) > size = ((size / _thr_page_size) + 1) * > _thr_page_size; > return size; > } > > The body can be condensed to > > return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); > > This is shorter in both lines of code and instruction bytes. Lets not allow this to be lost. Could anybody confirm that the patch below fixes the issue? commit d560f4f6690a48476565278fd07ca131bf4eeb3c Author: Konstantin Belousov Date: Wed Jul 24 13:17:55 2024 +0300 rtld: avoid division in __thr_map_stacks_exec() The function is called by rtld with the rtld bind lock write-locked, when fixing the stack permission during dso load. Not every ARMv7 CPU supports the div, which causes the recursive entry into rtld to resolve the __aeabi_uidiv symbol, causing self-lock. Workaround the problem by using roundup2() instead of open-coding less efficient formula. Diagnosed by: mmel Based on submission by: John F Carr Sponsored by: The FreeBSD Foundation MFC after: 1 week diff --git a/lib/libthr/thread/thr_stack.c b/lib/libthr/thread/thr_stack.c index f576a2c04104..d249bb5606fd 100644 --- a/lib/libthr/thread/thr_stack.c +++ b/lib/libthr/thread/thr_stack.c @@ -126,10 +126,7 @@ static char *last_stack = NULL; static inline size_t round_up(size_t size) { - if (size % _thr_page_size != 0) - size = ((size / _thr_page_size) + 1) * - _thr_page_size; - return size; + return (roundup2(size, _thr_page_size)); } void From nobody Wed Jul 24 10:34:57 2024 X-Original-To: freebsd-current@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 4WTVl82smhz5Rj17; Wed, 24 Jul 2024 10:35:00 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTVl80kQsz4RyW; Wed, 24 Jul 2024 10:35:00 +0000 (UTC) (envelope-from melounmichal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-3686b554cfcso3254662f8f.1; Wed, 24 Jul 2024 03:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721817298; x=1722422098; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:from:to:cc:subject:date:message-id:reply-to; bh=mXWNOFIbZTQB0C+Lci5G/wZK34fXBGR60XXmvO6lmU0=; b=Nm68IkH2VJjVz4EEY4rv8y6u7jEKf0Vv6k4PbbBBpFh7o8l7g0CVwQCK3Xsr7LmeV5 piMC6WGIuDKprRmNeFCH7R5BXVVF/DBLFoufbmjOck4yLj28tGkNVvJSZZBD0+vPurvV lrI23g+KS/36aFe5YSsOg/N4hDV0Jw/HWCfjpWnR4A56a72Ij3t3UF9eFIGO9/tmy082 Q9M33x4Tq5s9tLQLboy2QTiXk8dmgB6fxb27AZdRgTteXzZWrtqlcm3F7GqlfvbXFGFk rpGoRmEC4DPI2gKhm2wpeMVCnyzZCefDH05qNr9AI1FjUTRr3GAlAZ88cfb+QW2r819B Cy5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721817298; x=1722422098; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mXWNOFIbZTQB0C+Lci5G/wZK34fXBGR60XXmvO6lmU0=; b=e8maBPhQym6N39eYFfE10Zy0uPaZNxRgeTvBN7W7mGZk2noqAFBFaQG8dgSIjINFjL uKtdBFq8wWaFDt4Q9gWCFCFYN+bXk1XFdNhcYPsGA14e/PWQsXGakpnv++23qozpmLCK vxjuvu/GCfmho716IvFnAMCP8Vb3QUctO5Ll1QUlIU+q9JT7q8wHSOWNVodu8yRPbBCz NGZ0uIeb/QwvjeXwLM27APa21h0oUuTSkI5FM3FyNZWrowdQStjom1wRyeHyb97SSTjP FdOWlKZeq2Yrwfl3CqiPekkezVEjJVnqxF1rDwivzEB7+PqQv4yNA2e+OzgncQc5KWGa 66CQ== X-Forwarded-Encrypted: i=1; AJvYcCVUW4domGbVDd1jx+U417dq8u25dXdwx7qmxmaC6a+xbMsOa/Z/zSCU9K4w0d10zx4mMW24hsWPDfpAd4hpAp84BScp0qEcvUYy79yCELIGBQ3j1N4x+hy6p/yHtLSPp0wg0tLw X-Gm-Message-State: AOJu0YzQGFaga2gstMGgIow2KzvGZrf7FGx4TZ4K+R0h4WwfRKMXOGHT 7pVZmaatEuJ3dM+yxuwCLSz8cRhPFQEHO2IOz6pSA/4bYr4lC7KkMKh4ZlJS X-Google-Smtp-Source: AGHT+IGUq/JDzTQGjFJqhycW0Pc+FSq8+X2aRe+nVEfFl7ap097Fb3MATZkSSJ6/q5sgextx5l+3vQ== X-Received: by 2002:adf:f9cb:0:b0:368:68d3:32b3 with SMTP id ffacd0b85a97d-369f5a8f8c1mr1148706f8f.26.1721817298118; Wed, 24 Jul 2024 03:34:58 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:841e:45d2:e338:10c2? ([2001:67c:14a0:5fe0:841e:45d2:e338:10c2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-368787ed580sm13824230f8f.112.2024.07.24.03.34.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jul 2024 03:34:57 -0700 (PDT) From: "mmel@freebsd.org" X-Google-Original-From: "mmel@freebsd.org" Message-ID: Date: Wed, 24 Jul 2024 12:34:57 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@freebsd.org Subject: Re: armv7-on-aarch64 stuck at urdlck To: Konstantin Belousov , John F Carr Cc: Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" References: <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4WTVl80kQsz4RyW On 24.07.2024 12:24, Konstantin Belousov wrote: > On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: >> On Jul 23, 2024, at 13:46, Michal Meloun wrote: >>> >>> On 23.07.2024 11:36, Konstantin Belousov wrote: >>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: >>>>> The good news is that I'm finally able to generate a working/locking >>>>> test case. The culprit (at least for me) is if "-mcpu" is used when >>>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). >>>>> If it is not used, libthr is broken (regardless of -O level or debug/normal >>>>> build), but -mcpu=cortex-a15 will always produce a working libthr. >>>> I think this is very significant progress. >>>> Do you plan to drill down more to see what is going on? >>> >>> So the problem is now clear, and I fear it may apply to other architectures as well. >>> dlopen_object() (from rtld_elf), >>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, >>> holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. >>> If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. >>> >>> In this case, it round_up() in _thr_stack_fix_protection, >>> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. >>> Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). >>> >>> Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. >>> >>> >>> Michal >>> >> >> In this case (but not for all _aeabi_ functions) we can avoid division >> as long as page size is a power of 2. >> >> The function is >> >> static inline size_t >> round_up(size_t size) >> { >> if (size % _thr_page_size != 0) >> size = ((size / _thr_page_size) + 1) * >> _thr_page_size; >> return size; >> } >> >> The body can be condensed to >> >> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); >> >> This is shorter in both lines of code and instruction bytes. > > Lets not allow this to be lost. Could anybody confirm that the patch > below fixes the issue? > > commit d560f4f6690a48476565278fd07ca131bf4eeb3c > Author: Konstantin Belousov > Date: Wed Jul 24 13:17:55 2024 +0300 > > rtld: avoid division in __thr_map_stacks_exec() > > The function is called by rtld with the rtld bind lock write-locked, > when fixing the stack permission during dso load. Not every ARMv7 CPU > supports the div, which causes the recursive entry into rtld to resolve > the __aeabi_uidiv symbol, causing self-lock. > > Workaround the problem by using roundup2() instead of open-coding less > efficient formula. > > Diagnosed by: mmel > Based on submission by: John F Carr > Sponsored by: The FreeBSD Foundation > MFC after: 1 week > For final resolving of deadlocks, after a full day of digging, I'm very much incline of adding -znow to the linker flags for libthr.so (and maybe also for ld-elf.so). The runtime cost of resolving all symbols at startup is very low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_* symbols, since they don't have an official C prototypes, and some are not compatible with C calling conventions. Warner, Konstantin, could you please comment on this? Michal From nobody Wed Jul 24 10:50:18 2024 X-Original-To: freebsd-current@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 4WTW4y4SyJz5RkMV; Wed, 24 Jul 2024 10:50:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTW4y2RCSz4Tqg; Wed, 24 Jul 2024 10:50:26 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46OAoIAw049940; Wed, 24 Jul 2024 13:50:21 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46OAoIAw049940 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46OAoIfO049939; Wed, 24 Jul 2024 13:50:18 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Wed, 24 Jul 2024 13:50:18 +0300 From: Konstantin Belousov To: mmel@freebsd.org Cc: John F Carr , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4WTW4y2RCSz4Tqg On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote: > > > On 24.07.2024 12:24, Konstantin Belousov wrote: > > On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: > > > On Jul 23, 2024, at 13:46, Michal Meloun wrote: > > > > > > > > On 23.07.2024 11:36, Konstantin Belousov wrote: > > > > > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > > > > > > The good news is that I'm finally able to generate a working/locking > > > > > > test case. The culprit (at least for me) is if "-mcpu" is used when > > > > > > compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > > > > > > If it is not used, libthr is broken (regardless of -O level or debug/normal > > > > > > build), but -mcpu=cortex-a15 will always produce a working libthr. > > > > > I think this is very significant progress. > > > > > Do you plan to drill down more to see what is going on? > > > > > > > > So the problem is now clear, and I fear it may apply to other architectures as well. > > > > dlopen_object() (from rtld_elf), > > > > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > > > > holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. > > > > If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. > > > > > > > > In this case, it round_up() in _thr_stack_fix_protection, > > > > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > > > > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). > > > > > > > > Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. > > > > > > > > > > > > Michal > > > > > > > > > > In this case (but not for all _aeabi_ functions) we can avoid division > > > as long as page size is a power of 2. > > > > > > The function is > > > > > > static inline size_t > > > round_up(size_t size) > > > { > > > if (size % _thr_page_size != 0) > > > size = ((size / _thr_page_size) + 1) * > > > _thr_page_size; > > > return size; > > > } > > > > > > The body can be condensed to > > > > > > return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); > > > > > > This is shorter in both lines of code and instruction bytes. > > > > Lets not allow this to be lost. Could anybody confirm that the patch > > below fixes the issue? > > > > commit d560f4f6690a48476565278fd07ca131bf4eeb3c > > Author: Konstantin Belousov > > Date: Wed Jul 24 13:17:55 2024 +0300 > > > > rtld: avoid division in __thr_map_stacks_exec() > > The function is called by rtld with the rtld bind lock write-locked, > > when fixing the stack permission during dso load. Not every ARMv7 CPU > > supports the div, which causes the recursive entry into rtld to resolve > > the __aeabi_uidiv symbol, causing self-lock. > > Workaround the problem by using roundup2() instead of open-coding less > > efficient formula. > > Diagnosed by: mmel > > Based on submission by: John F Carr > > Sponsored by: The FreeBSD Foundation > > MFC after: 1 week > > Just realized that it is wrong. Stack size is user-controlled and it does not need to be power of two. > For final resolving of deadlocks, after a full day of digging, I'm very much > incline of adding -znow to the linker flags for libthr.so (and maybe also > for ld-elf.so). The runtime cost of resolving all symbols at startup is very > low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_* > symbols, since they don't have an official C prototypes, and some are not > compatible with C calling conventions. I do not like it. `-z now' changes (breaks) the ABI and makes some symbols not preemtible. In the worst case, we would need a call to the asm routine which causes the resolution of the _eabi_* symbols on arm. > > Warner, Konstantin, could you please comment on this? > > > Michal From nobody Wed Jul 24 13:07:39 2024 X-Original-To: freebsd-current@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 4WTZ7N58vrz5RwcX; Wed, 24 Jul 2024 13:07:44 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11020138.outbound.protection.outlook.com [52.101.61.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTZ7N2Zqlz4mXR; Wed, 24 Jul 2024 13:07:44 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rJSPUKDXMRiVxiBDKLtK90OFLO78/bBUeTF3qIbbYIOt/L52w5okx4zvVG6f1hNYjwYsA9ltwm0f5VYGocjb3xVRztHyQ5DItlcWcBUzJMpRFftZ1RDG6qqhgFGQQC/kSoOD7YbTfdQ60yvuBhS0naLMBUrnkjn+1oWQ36Er9lZLHUsqvgrdz8BXwi7uhPg/nmkGyJq05/+WF1l+VJyH7eo373a5lsQOx6WN3lkVvnsPUcGCKF4Lf9OSZ7Qxu7NoTgdp9EYrYdywuFmsPE4PLq/wkp8+wkYr811aGK3KiGSogbia2bnr2qb/89mKFQRWIYD1EJMWdH062XnHq6eX9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s35BjKfbmEqCB0ldjE92Bb9PddiXCbtAiLJ2c9VSr9I=; b=JHy///AVpmjbnpnTGSj41tcCIEikw+8lETdyAfaIR3/gqlvf5Civ4l8DgkQ+8txv5e07NTXmgIBxVQB4Tymw8xNnolVoJwlF3SGzrm560/Lmfus/BmSQfu8AMbnvVXH3YE1/zPBKxeByNThc19Ddwia2MJmGYMCMs4i2FVEVy9o9jOZM7GaLBBNC9Ba+8N103pmlHHNFlLrskQyFFKjsOxhYv9FQYFH6poYs04YCUWLCKIO6tai5t0YJ5hl2v09Z7DDgGDHqxLao0tZPPToQRWoIr1n2JiTu7DmiutGVksK2p8MJZ41uC6/tW2lBp1HzDhrAeH+xzrnh32L3Xft78Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s35BjKfbmEqCB0ldjE92Bb9PddiXCbtAiLJ2c9VSr9I=; b=QXu3tQCvmYEdwv5XEa2z02SP7H6fQkNVARysvW155pJsornvT0/dWhJFxZLxQGOlM1zZWk/2+JuAiMMifpgxl9yzo8hfBXfILOPFgphmoDQwIpeM6aqo6aEcLTCxLed4lwIcfSUs9iu23gnMhG6nqvaq6w7GGPcrP9Q3Ajpvb6s= Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by SJ0PR01MB8059.prod.exchangelabs.com (2603:10b6:a03:4ea::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7762.20; Wed, 24 Jul 2024 13:07:40 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::bb39:d8c:f575:6b9d%6]) with mapi id 15.20.7784.017; Wed, 24 Jul 2024 13:07:39 +0000 From: John F Carr To: Konstantin Belousov CC: "mmel@freebsd.org" , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Thread-Topic: armv7-on-aarch64 stuck at urdlck Thread-Index: AQHa2/xL/eBpVtdzuUaKV+38IPbVfLICobiAgAAf4ACAAC4tAIAABE8AgAAMwwCAACPzAIAAiccAgABEVICAABzIAIAAiPOAgAAoSACAAO5cgIAAAwWAgAAESQCAACZVgA== Date: Wed, 24 Jul 2024 13:07:39 +0000 Message-ID: References: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|SJ0PR01MB8059:EE_ x-ms-office365-filtering-correlation-id: fc4c91e8-51cb-4f5f-42bb-08dcabe198ce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?p0SrxcG+91jZZXObxsNolStZ08rjzjGIoRqSvjrUpJRy5gYH7yjdiY+rVL65?= =?us-ascii?Q?MqpZZplJNdGaL5OE4f8rvYV52TkO/lg76EL4bo2HobcF3i6iL6EvvD8FBb+N?= =?us-ascii?Q?r3/lKSu0PxMSRfYREJdQvSJJ/aKj7lS5sSJqcE5B8pthDC2U4k7GQ66CpfFF?= =?us-ascii?Q?fInCFkf1EhngtRb/tRXM6zW38J/c3SvPqU4VL9K/Xu2wm6W0+AvRKuTdU2G0?= =?us-ascii?Q?YRYa0jG1jf4Bpj+mQOorOct1+91ip4m7QhrmwGA/r0TKE4f+2zSutKwP7Vyx?= =?us-ascii?Q?fkDMFmQnaBIoT+Zh8oYY7cdy2KJhKsya+kTdZHHcXw9FYnNSbMJDdFBRYwF/?= =?us-ascii?Q?mQtVlNy0KH0C7P3xd8Td2t2++UcCtGlFPdkF5+ZGbPorG156F5jiTqQuvtW4?= =?us-ascii?Q?JmTyM5T0xo36TEsVYcd2mX4FdM/7NQ5S6hA5sE04gP8bhJWRR0OKXt1cec1Q?= =?us-ascii?Q?7b18lSdvj+vH3c+F+LEy1NUcG4ylNQJdhHk75UMr20aMMAWTApotjLwpu1v0?= =?us-ascii?Q?SBoN08bCv8XQU/NrwGI/3g+aHd2KmvnijpUm+TFo8+1qbc+JRTzSalpSMYEr?= =?us-ascii?Q?Xf/TvnQEHWqNZ+4CnB1+479CcSwaviMTT0cF0cb7MgKnkHsgDDuSMOLFVO7X?= =?us-ascii?Q?Qu4DVL/Wm81P29gIiAsnOWP+T/+wKqb3+3fHOalrD0roK2aU8bZkZ59056EZ?= =?us-ascii?Q?F19U4Q4zZajOEVnMYIIEvpM2hsxRv9TNKRBbIrLwe14eoEb+tN7P57Vc21EY?= =?us-ascii?Q?j8mDVMRVOXy7hGJScgoiiHDjAiik0dWZ7iDvaqLRSuBEuPPLKLmKz0A5uQmh?= =?us-ascii?Q?OYAMVcOhWZjHPUJGdveeOLl+mYGy6gOau1UO7oSm0wPEJ3fb+ePT17Vo1cP/?= =?us-ascii?Q?LA3ibmsY9zrOVMhDd7bGCcablAn/104Okwc+orB/zGw9HZyhstlggP7UrMjo?= =?us-ascii?Q?Zk3LOOhB2zK7yN3FlewQGoSQdUuZ9sDQY6dRv+Kdyg1q8wAXde8gtHQ49buL?= =?us-ascii?Q?JuF5yCZQQtg3YCxUsch92whS+q1lyGO5KcMOoO8ZvL28iU7LFjLRe7bz4iK4?= =?us-ascii?Q?LevHeSXvhCti5gV2okJxdnLW7Ne8wdVUVgGn5fAEJVJy+gwtdvl7Ams1pakx?= =?us-ascii?Q?3vDb5+dU7OGrbEsAJH/U7Gh5i0PBACXZkJLY4e2F5832cav/Wb5XoHR5oB1V?= =?us-ascii?Q?N9YNkUONz1K1Wj0VVxsunvOv7Fat8qDVV8NKLmc8kqT/jLYTJvPhr4bKSN2g?= =?us-ascii?Q?N5Ymjc1XUu1BKwo93JclW17wQzPV4d5pMOatIpURx03WdnR1Wkkw6M0oY5ow?= =?us-ascii?Q?j4OmSlTUeCB08za2omlrtVe8wYpnl+bA/FWnLKu3+roKAGEkqIDOvlTlNO1j?= =?us-ascii?Q?1ZEQxHI=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rnWxWt4TkFJ5I2dRYhcgkujMVMcAaeHiEce2jLTIiX/XBDWbj2jcbdiNZngJ?= =?us-ascii?Q?fsKYDMxr6iJtZTKu+tJ8MeAwNC6cc/oB0Reed46h4tOKNvLvWMbPhE+Ms78m?= =?us-ascii?Q?OcKnhY7jmzo0YVSFiHfmZLrWEtLr3UwZc07sXHi49mX2odpnu724Et7FnN+T?= =?us-ascii?Q?hcZPS+sbSN3KND9QRMiaqmet7aezd9wcKg16Km+3Fp8Y6S9q9Ki9WCipdmvl?= =?us-ascii?Q?v3QHaZ5GAQOFLd9JqhghZJj6wgaDyPL7kVndsdSdDChzhfQ/U661gCKmbFuc?= =?us-ascii?Q?A76tKpHoA/Vnqo14QgJJf5bFiuoShNGNPEwaEbaRR1wMUj9icqAL2U3Cbybu?= =?us-ascii?Q?DhYt9mXQAp4VHB0zgvz4Ruqa2wVnTyUImRiSNea9FS3vmzAluroh3QMze4k8?= =?us-ascii?Q?UvpQC73iBSi21CPro/Jb7bqPtzrUvf0SbSjiNDS3vE41oZPLXDqLkPuU7WUb?= =?us-ascii?Q?ArQ2OWKWNN70ARpyNHDbCddDeIUttyxs/7iFcp3RlNLZDUAkkD0b4zikS0im?= =?us-ascii?Q?fUWV98v3QfLixp0UrDld2yzjPN687N9pHEpUIbUjGSa1CWHbTc6fbs9VWL3V?= =?us-ascii?Q?tVD78go78krAVZ4pVdY8p9wjwQozoBiYwe6w0q7Al1XiID5Hy30r3kSkRJ8U?= =?us-ascii?Q?QLUP2qvUrR7RExr8FfZii5g0cOcy6UKppGo6fRJ4rsAi/NljWmBtlUjUMKC7?= =?us-ascii?Q?zzo068ra9XD14oOTMz8UWpNPqmskFAS7NUWxjDa/iGn4AfzhuG7QiPx+PZA2?= =?us-ascii?Q?vjReVOKA1kSEzak9qZ506zsr9zpWs46qvi6wFpMi97FYYmbxuoK5brrOwN0o?= =?us-ascii?Q?Rv/fzFCXnikQ+OwO0YjSUz023TEJUZd0nhs0Thn2/R0S8UQYmWBJ4p+21ijz?= =?us-ascii?Q?9ND0gf647Ulxl701fVcYezCLLoSIiIoewLy2mp6HVnZ5j0am6Tlph7pblpqs?= =?us-ascii?Q?BvT2QUxH2g+N1d/w7k63zr709JpEeSfWKUsizVZ/r9hbpweJry0ux2vI0uIC?= =?us-ascii?Q?IyxHuG8E8cOL4WuzWO4bW/aGB4zFV38fRSFFiUnD2DPhlyvuQOfXmbsIQ0uc?= =?us-ascii?Q?OyxWLFksBaThof17zUJt+m/4BCv3zC4w01pzW0mnQrhSB9D8Yby/KuPJ4/m9?= =?us-ascii?Q?tp/yQHiizTMPmYN1NkPoZArIndii8LgaABrWfKUq2ZPiPj+J+zYGsTzncjxz?= =?us-ascii?Q?V3rZmy96FRmU8uujCv/5Mvx+PlW8JdmivoKhWw/XlM5FdmELeO+tU0GI0v08?= =?us-ascii?Q?1EqTAAB5rhyRttWB8r3ayUOzcATpbvlZ6+92KRGhY7ihQf2QoW/kLbcLaaJo?= =?us-ascii?Q?qMUhsPAPv1cP42Gg8lpGvcJT9ociAqTFm9+nSQ5/UEZGedF/rVLpcvalkZAv?= =?us-ascii?Q?q8IbTwYBonSXyJmlydJ8Ya49S4yNketq1E7/FaecebvLPe0W33EkMXHBzKss?= =?us-ascii?Q?t3B8KTzD/uJKy3GVkHM8BoxsQKiTAYTGwywGANJ7c5XKtljXvGiYKsBEjhl+?= =?us-ascii?Q?X8lvrVBIxXkFhREJqP+NXlsUR0LLDvAWJ7ksxb0dnx78vAT8xmauRB6LFSyh?= =?us-ascii?Q?FTk6oqcKW9g0v9NwSrRBU+teiOmsyorgd33V5ChAT3XsAfwpbhVH3PMJuFXD?= =?us-ascii?Q?VB2FT0Yhhsm9GYQaFPWSqx7Aii/UrWcuMt/XsnoDABoN?= Content-Type: text/plain; charset="us-ascii" Content-ID: <8279D1131CCE394C9C9113200642E6B5@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc4c91e8-51cb-4f5f-42bb-08dcabe198ce X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2024 13:07:39.8919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rP9/+Plrxcs84oX5ZgADBLRZXRJE5yuC2CsqPefTwCADjVHo8rumMW3GOMWlp9d2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR01MB8059 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US] X-Rspamd-Queue-Id: 4WTZ7N2Zqlz4mXR > On Jul 24, 2024, at 06:50, Konstantin Belousov wrote: >=20 > On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote: >>=20 >>=20 >> On 24.07.2024 12:24, Konstantin Belousov wrote: >>> On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: >>>> On Jul 23, 2024, at 13:46, Michal Meloun wro= te: >>>>>=20 >>>>> On 23.07.2024 11:36, Konstantin Belousov wrote: >>>>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: >>>>>>> The good news is that I'm finally able to generate a working/lockin= g >>>>>>> test case. The culprit (at least for me) is if "-mcpu" is used whe= n >>>>>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make= .conf). >>>>>>> If it is not used, libthr is broken (regardless of -O level or debu= g/normal >>>>>>> build), but -mcpu=3Dcortex-a15 will always produce a working libthr= . >>>>>> I think this is very significant progress. >>>>>> Do you plan to drill down more to see what is going on? >>>>>=20 >>>>> So the problem is now clear, and I fear it may apply to other archite= ctures as well. >>>>> dlopen_object() (from rtld_elf), >>>>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, >>>>> holds the rtld_bind_lock write lock for almost the entire time a new = library is loaded. >>>>> If the code uses a yet unresolved symbol to load the library, the rtl= _bind() function attempts to get read lock of rtld_bind_lock and a deadloc= k occurs. >>>>>=20 >>>>> In this case, it round_up() in _thr_stack_fix_protection, >>>>> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. >>>>> Issued by __aeabi_uidiv (since not all armv7 processors support HW di= vide). >>>>>=20 >>>>> Unfortunately, I'm not sure how to fix it. The compiler can emit __a= eabi_<> in any place, and I'm not sure if it can resolve all the symbols us= ed by rtld_eld and libthr beforehand. >>>>>=20 >>>>>=20 >>>>> Michal >>>>>=20 >>>>=20 >>>> In this case (but not for all _aeabi_ functions) we can avoid division >>>> as long as page size is a power of 2. >>>>=20 >>>> The function is >>>>=20 >>>> static inline size_t >>>> round_up(size_t size) >>>> { >>>> if (size % _thr_page_size !=3D 0) >>>> size =3D ((size / _thr_page_size) + 1) * >>>> _thr_page_size; >>>> return size; >>>> } >>>>=20 >>>> The body can be condensed to >>>>=20 >>>> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); >>>>=20 >>>> This is shorter in both lines of code and instruction bytes. >>>=20 >>> Lets not allow this to be lost. Could anybody confirm that the patch >>> below fixes the issue? >>>=20 >>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c >>> Author: Konstantin Belousov >>> Date: Wed Jul 24 13:17:55 2024 +0300 >>>=20 >>> rtld: avoid division in __thr_map_stacks_exec() >>> The function is called by rtld with the rtld bind lock write-locked= , >>> when fixing the stack permission during dso load. Not every ARMv7 = CPU >>> supports the div, which causes the recursive entry into rtld to res= olve >>> the __aeabi_uidiv symbol, causing self-lock. >>> Workaround the problem by using roundup2() instead of open-coding l= ess >>> efficient formula. >>> Diagnosed by: mmel >>> Based on submission by: John F Carr >>> Sponsored by: The FreeBSD Foundation >>> MFC after: 1 week >>>=20 > Just realized that it is wrong. Stack size is user-controlled and it doe= s > not need to be power of two. Your change is correct. _thr_page_size is set to getpagesize(), which is a power of 2. The call to roundup2 takes a user-provided size and rounds it up to a multiple of the system page size. I tested the change and it works. My change also works and should compile to identical code. I forgot there was a standard function to do the rounding. > For final resolving of deadlocks, after a full day of digging, I'm very m= uch >> incline of adding -znow to the linker flags for libthr.so (and maybe al= so >> for ld-elf.so). The runtime cost of resolving all symbols at startup is = very >> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeab= i_* >> symbols, since they don't have an official C prototypes, and some are no= t >> compatible with C calling conventions. > I do not like it. `-z now' changes (breaks) the ABI and makes some symbol= s > not preemtible. >=20 > In the worst case, we would need a call to the asm routine which causes t= he > resolution of the _eabi_* symbols on arm. >=20 It would also be possible to link libthr with libgcc.a and use a linker map to hide the _eabi_ symbols. From nobody Wed Jul 24 15:47:16 2024 X-Original-To: freebsd-current@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 4WTdgf4hJdz5S8nr; Wed, 24 Jul 2024 15:47:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTdgd0cv0z43PL; Wed, 24 Jul 2024 15:47:24 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 46OFlHrM059204; Wed, 24 Jul 2024 18:47:20 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 46OFlHrM059204 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 46OFlG22059203; Wed, 24 Jul 2024 18:47:16 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Wed, 24 Jul 2024 18:47:16 +0300 From: Konstantin Belousov To: John F Carr Cc: "mmel@freebsd.org" , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: References: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4WTdgd0cv0z43PL On Wed, Jul 24, 2024 at 01:07:39PM +0000, John F Carr wrote: > > > > On Jul 24, 2024, at 06:50, Konstantin Belousov wrote: > > > > On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote: > >> > >> > >> On 24.07.2024 12:24, Konstantin Belousov wrote: > >>> On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: > >>>> On Jul 23, 2024, at 13:46, Michal Meloun wrote: > >>>>> > >>>>> On 23.07.2024 11:36, Konstantin Belousov wrote: > >>>>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > >>>>>>> The good news is that I'm finally able to generate a working/locking > >>>>>>> test case. The culprit (at least for me) is if "-mcpu" is used when > >>>>>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > >>>>>>> If it is not used, libthr is broken (regardless of -O level or debug/normal > >>>>>>> build), but -mcpu=cortex-a15 will always produce a working libthr. > >>>>>> I think this is very significant progress. > >>>>>> Do you plan to drill down more to see what is going on? > >>>>> > >>>>> So the problem is now clear, and I fear it may apply to other architectures as well. > >>>>> dlopen_object() (from rtld_elf), > >>>>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > >>>>> holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. > >>>>> If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. > >>>>> > >>>>> In this case, it round_up() in _thr_stack_fix_protection, > >>>>> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > >>>>> Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). > >>>>> > >>>>> Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. > >>>>> > >>>>> > >>>>> Michal > >>>>> > >>>> > >>>> In this case (but not for all _aeabi_ functions) we can avoid division > >>>> as long as page size is a power of 2. > >>>> > >>>> The function is > >>>> > >>>> static inline size_t > >>>> round_up(size_t size) > >>>> { > >>>> if (size % _thr_page_size != 0) > >>>> size = ((size / _thr_page_size) + 1) * > >>>> _thr_page_size; > >>>> return size; > >>>> } > >>>> > >>>> The body can be condensed to > >>>> > >>>> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); > >>>> > >>>> This is shorter in both lines of code and instruction bytes. > >>> > >>> Lets not allow this to be lost. Could anybody confirm that the patch > >>> below fixes the issue? > >>> > >>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c > >>> Author: Konstantin Belousov > >>> Date: Wed Jul 24 13:17:55 2024 +0300 > >>> > >>> rtld: avoid division in __thr_map_stacks_exec() > >>> The function is called by rtld with the rtld bind lock write-locked, > >>> when fixing the stack permission during dso load. Not every ARMv7 CPU > >>> supports the div, which causes the recursive entry into rtld to resolve > >>> the __aeabi_uidiv symbol, causing self-lock. > >>> Workaround the problem by using roundup2() instead of open-coding less > >>> efficient formula. > >>> Diagnosed by: mmel > >>> Based on submission by: John F Carr > >>> Sponsored by: The FreeBSD Foundation > >>> MFC after: 1 week > >>> > > Just realized that it is wrong. Stack size is user-controlled and it does > > not need to be power of two. > > Your change is correct. _thr_page_size is set to getpagesize(), > which is a power of 2. The call to roundup2 takes a user-provided > size and rounds it up to a multiple of the system page size. > > I tested the change and it works. My change also works and > should compile to identical code. I forgot there was a standard > function to do the rounding. Right, my bad, thank you for correcting my thinko. > > > For final resolving of deadlocks, after a full day of digging, I'm very much > >> incline of adding -znow to the linker flags for libthr.so (and maybe also > >> for ld-elf.so). The runtime cost of resolving all symbols at startup is very > >> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_* > >> symbols, since they don't have an official C prototypes, and some are not > >> compatible with C calling conventions. > > I do not like it. `-z now' changes (breaks) the ABI and makes some symbols > > not preemtible. > > > > In the worst case, we would need a call to the asm routine which causes the > > resolution of the _eabi_* symbols on arm. > > > > It would also be possible to link libthr with libgcc.a and use a linker map > to hide the _eabi_ symbols. In principle yes, but if the ARM ABI states that _eabi symbols must be used, and exported from libc, then this is also some form of ABI breakage. From nobody Wed Jul 24 17:34:47 2024 X-Original-To: freebsd-current@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 4WTh3Z0NFhz5SJvZ; Wed, 24 Jul 2024 17:34:50 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTh3Y5XSRz4FTB; Wed, 24 Jul 2024 17:34:49 +0000 (UTC) (envelope-from melounmichal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-427ffae0b91so393485e9.0; Wed, 24 Jul 2024 10:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721842488; x=1722447288; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:from:to:cc:subject:date:message-id:reply-to; bh=SjSGpB4QpVM2BXFXdUT/fDhKrwfkBWOrmcznpVw5Vbc=; b=IE67eL9e7/gSDEv6EjdMyvpAdJ0YR/6IA6hlkBtU0DLJdPmJDs2vGQf3cnY4NsuGXF jaG5qI6BBVMP9Vbh2A1UL+aL8IboBbBzdq4ZnRRFrBp54pdwf0WpZGtjLo8h3d6likee mGOfsb0Ae3M2oHhkh0xxm6RmCuo/Vh07Q8EG8CLnvDXjBM30JJyy8swV97v5k2qR8bM2 V6GSJ5iWt1wpN6X46I5vfjmmwqKygwIQsR0ckcNIiqdpyi7f3sJRuFd3Td6FYAC+9NxA /s8uB0YOdoyV5uPDn5lM3qRQgsteGoum7pl1it90Lp2XQXnXO3s4/fuVsIHovO4q4ytf dxig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721842488; x=1722447288; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SjSGpB4QpVM2BXFXdUT/fDhKrwfkBWOrmcznpVw5Vbc=; b=ix1zAS55TdfRe/tIaXAVSmMgq+fxPyu2RuDUwIImZwOw06hGkVZ+190JZLLoi2b3+f VTgV/H4vnEQwKPzm91xXD9yzXqfgyYa2Z/mrjRpP8OPyPJsT4NaMT6cSKZm7/V7NAP+a zRjaSKvUUe+X7pZQH6YoahtUm4Fkh9SL7Crv6XfZPynYYEl4PeIN9yq1mksSYwWJ53YY 2jRpiwT0xqLErTyo/CmHJOAEtxh7SLG8Igf5Ju1EIss9XVDXolkE7U5GvGqaJt9XW2ca OfQf4IJLzARCPi2tmEnxT+XqnQKVnc1cx8yAILiKwraOfJdj933gdmc5UsDh60517B8f 48ig== X-Forwarded-Encrypted: i=1; AJvYcCWbqXztlII/BNR8sSJoGjyllz8jBp59ieYWhsrJmKNKQJTEQH8YA5cKun41u8y4LKDm4tjx5LyjjZliT47dHXCzqtbWnG8IKE6aZDdP8VK+TkZD7830yE+KGcmTzvg0mZVHqwWK X-Gm-Message-State: AOJu0Ywx4FXx26s7AJZpxvv2bLA44aK4+jrbhFYBfzganuI5+TmkEYJz +E8lVwmhylnXnT0TZpGEgziO3hTPYPBX0d0kgVvf8svIPYYydCdxH2mbpdDW X-Google-Smtp-Source: AGHT+IFw2kEL2k4ETosin8jlOOUczci9UOeaZNc9h6pez8p+oGufKVEDfwHOoKXgq/njEaCUmAXpDQ== X-Received: by 2002:a05:600c:1c95:b0:426:59fe:ac27 with SMTP id 5b1f17b1804b1-427f7ad53a8mr28267615e9.26.1721842487402; Wed, 24 Jul 2024 10:34:47 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:841e:45d2:e338:10c2? ([2001:67c:14a0:5fe0:841e:45d2:e338:10c2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-368786949f5sm14900497f8f.57.2024.07.24.10.34.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jul 2024 10:34:46 -0700 (PDT) From: "mmel@freebsd.org" X-Google-Original-From: "mmel@freebsd.org" Message-ID: <28484869-05fd-4391-9501-10b93280f7a4@freebsd.org> Date: Wed, 24 Jul 2024 19:34:47 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@freebsd.org Subject: Re: armv7-on-aarch64 stuck at urdlck To: Konstantin Belousov , John F Carr Cc: Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" References: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4WTh3Y5XSRz4FTB On 24.07.2024 17:47, Konstantin Belousov wrote: > On Wed, Jul 24, 2024 at 01:07:39PM +0000, John F Carr wrote: >> >> >>> On Jul 24, 2024, at 06:50, Konstantin Belousov wrote: >>> >>> On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote: >>>> >>>> >>>> On 24.07.2024 12:24, Konstantin Belousov wrote: >>>>> On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: >>>>>> On Jul 23, 2024, at 13:46, Michal Meloun wrote: >>>>>>> >>>>>>> On 23.07.2024 11:36, Konstantin Belousov wrote: >>>>>>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: >>>>>>>>> The good news is that I'm finally able to generate a working/locking >>>>>>>>> test case. The culprit (at least for me) is if "-mcpu" is used when >>>>>>>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). >>>>>>>>> If it is not used, libthr is broken (regardless of -O level or debug/normal >>>>>>>>> build), but -mcpu=cortex-a15 will always produce a working libthr. >>>>>>>> I think this is very significant progress. >>>>>>>> Do you plan to drill down more to see what is going on? >>>>>>> >>>>>>> So the problem is now clear, and I fear it may apply to other architectures as well. >>>>>>> dlopen_object() (from rtld_elf), >>>>>>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, >>>>>>> holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. >>>>>>> If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. >>>>>>> >>>>>>> In this case, it round_up() in _thr_stack_fix_protection, >>>>>>> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. >>>>>>> Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). >>>>>>> >>>>>>> Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. >>>>>>> >>>>>>> >>>>>>> Michal >>>>>>> >>>>>> >>>>>> In this case (but not for all _aeabi_ functions) we can avoid division >>>>>> as long as page size is a power of 2. >>>>>> >>>>>> The function is >>>>>> >>>>>> static inline size_t >>>>>> round_up(size_t size) >>>>>> { >>>>>> if (size % _thr_page_size != 0) >>>>>> size = ((size / _thr_page_size) + 1) * >>>>>> _thr_page_size; >>>>>> return size; >>>>>> } >>>>>> >>>>>> The body can be condensed to >>>>>> >>>>>> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); >>>>>> >>>>>> This is shorter in both lines of code and instruction bytes. >>>>> >>>>> Lets not allow this to be lost. Could anybody confirm that the patch >>>>> below fixes the issue? >>>>> >>>>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c >>>>> Author: Konstantin Belousov >>>>> Date: Wed Jul 24 13:17:55 2024 +0300 >>>>> >>>>> rtld: avoid division in __thr_map_stacks_exec() >>>>> The function is called by rtld with the rtld bind lock write-locked, >>>>> when fixing the stack permission during dso load. Not every ARMv7 CPU >>>>> supports the div, which causes the recursive entry into rtld to resolve >>>>> the __aeabi_uidiv symbol, causing self-lock. >>>>> Workaround the problem by using roundup2() instead of open-coding less >>>>> efficient formula. >>>>> Diagnosed by: mmel >>>>> Based on submission by: John F Carr >>>>> Sponsored by: The FreeBSD Foundation >>>>> MFC after: 1 week >>>>> >>> Just realized that it is wrong. Stack size is user-controlled and it does >>> not need to be power of two. >> >> Your change is correct. _thr_page_size is set to getpagesize(), >> which is a power of 2. The call to roundup2 takes a user-provided >> size and rounds it up to a multiple of the system page size. >> >> I tested the change and it works. My change also works and >> should compile to identical code. I forgot there was a standard >> function to do the rounding. > Right, my bad, thank you for correcting my thinko. > >> >>> For final resolving of deadlocks, after a full day of digging, I'm very much >>>> incline of adding -znow to the linker flags for libthr.so (and maybe also >>>> for ld-elf.so). The runtime cost of resolving all symbols at startup is very >>>> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_* >>>> symbols, since they don't have an official C prototypes, and some are not >>>> compatible with C calling conventions. >>> I do not like it. `-z now' changes (breaks) the ABI and makes some symbols >>> not preemtible. >>> >>> In the worst case, we would need a call to the asm routine which causes the >>> resolution of the _eabi_* symbols on arm. >>> >> >> It would also be possible to link libthr with libgcc.a and use a linker map >> to hide the _eabi_ symbols. > In principle yes, but if the ARM ABI states that _eabi symbols must be used, > and exported from libc, then this is also some form of ABI breakage. I hope that https://reviews.freebsd.org/D46104 is acceptable :) From nobody Wed Jul 24 20:20:23 2024 X-Original-To: freebsd-current@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 4WTlks0vcKz5Qt47 for ; Wed, 24 Jul 2024 20:20:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTlkr49Jgz4YmP for ; Wed, 24 Jul 2024 20:20:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2cb5e0b020eso188662a91.2 for ; Wed, 24 Jul 2024 13:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721852435; x=1722457235; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EBS/A41SY9zh6PTQAtretONmuyLFnn98ICkaFnngjLs=; b=TcnpMUUy4ZI/ryip3m3cPz8Rzbw/eFKeR76c6XTbiX1cXmvbYV4xnglZFhOqv4Gh/2 nribLztb4NnMUKMiHG6CTB0uyl+eGVNnmDdg8xK1q/bh1WgXKWs2p9HUOWRorzvt3SXP OfI8ezcqY1M3sPMp1kJ5L66sFqjLNZlwQVKT6PCZqDlj4uasmIU+8ChtJ3LazEIxW9FI 5lIl5mIfvikQDXkZUytVVpia7WTLlUQ6yhb5sW0KPcuGiI5wSSoNrNag/rfu71jxWstj 5suheIc81DXiXjZGQ6rbINDUtmHsX6xoYz/ACnptLVTelrAcXQlWdMbEEOltAxO4M8rO Wyqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721852435; x=1722457235; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EBS/A41SY9zh6PTQAtretONmuyLFnn98ICkaFnngjLs=; b=oKDnTFUr+FToVWQRWp7wkTcj36rFVBJ7tkVeKxONNeCYyTH00O7OaZilK+eNyGNXPu h6LRA6hng3RPvyg2ONnhbIdY+evawmstoEuI7YopcHspzrgTEFKLfXCOtiNiVuSJ13oC MmhR4EL7zLF3R29Nw35TKxYKDiGh9Tc3skOmfMkzC8YrT0bZ4X/nSFnMBno26l8bmk+N hELz6aArOzp7Ois4p6TnX7z3w49MGPrHL4qSYZG5mv5TP3gB4l6d/WpsNw2ErMZgdPb+ gkp+fQO+u2pkljIXQal7XF/cpxRBTgxDiKPtl0r6pVVtQBQnm2+Ekn37r5TcRQ682lpp IY0g== X-Forwarded-Encrypted: i=1; AJvYcCWkhngQmU3n5zPOrUckuW/WkGYVZ+6/M3+qhEhicfmrdIXSzc2xtUMxSpr8Jd7Q/M30U6gpT2RWgWs4WcaTKjHSzMGbzHB+n23YqJ4= X-Gm-Message-State: AOJu0Yy+2bmlFLiikPdGANx/zTZJ3Kbt2rqmx0TQco8O/2o9ZLGsm1WX mW4iOj27qh4RgmRX3DDnxqdIbWL4aYNcYQqHXH4foznbuAC2sggsE5MrVLLb1anqCAF9L+mXQ9m mKGjzE07BF/7Q9y2hbjW52nztKxamrXMU1alYBMWds8ekVHbwJVA= X-Google-Smtp-Source: AGHT+IEl5v2t0eZJ9owPr6J7pDMgStX6Y/20WMICSexGY1dNbFA/GiBHFoplOUoPszsxW+hfLDq9OVmrHdG42ghMoyA= X-Received: by 2002:a17:90a:7187:b0:2ca:8b71:21f4 with SMTP id 98e67ed59e1d1-2cf237dac2cmr830264a91.18.1721852434748; Wed, 24 Jul 2024 13:20:34 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> <0DD19771-3AAB-469E-981B-1203F1C28233@yahoo.com> <6a969609-fa0e-419d-83d5-e4fcf0f6ec35@freebsd.org> <28484869-05fd-4391-9501-10b93280f7a4@freebsd.org> In-Reply-To: <28484869-05fd-4391-9501-10b93280f7a4@freebsd.org> From: Warner Losh Date: Wed, 24 Jul 2024 14:20:23 -0600 Message-ID: Subject: Re: armv7-on-aarch64 stuck at urdlck To: mmel@freebsd.org Cc: Konstantin Belousov , John F Carr , Mark Millard , FreeBSD Current , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000bab606061e040273" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WTlkr49Jgz4YmP --000000000000bab606061e040273 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2024 at 11:34=E2=80=AFAM mmel@freebsd.org wrote: > > > On 24.07.2024 17:47, Konstantin Belousov wrote: > > On Wed, Jul 24, 2024 at 01:07:39PM +0000, John F Carr wrote: > >> > >> > >>> On Jul 24, 2024, at 06:50, Konstantin Belousov > wrote: > >>> > >>> On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote: > >>>> > >>>> > >>>> On 24.07.2024 12:24, Konstantin Belousov wrote: > >>>>> On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr wrote: > >>>>>> On Jul 23, 2024, at 13:46, Michal Meloun > wrote: > >>>>>>> > >>>>>>> On 23.07.2024 11:36, Konstantin Belousov wrote: > >>>>>>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > >>>>>>>>> The good news is that I'm finally able to generate a > working/locking > >>>>>>>>> test case. The culprit (at least for me) is if "-mcpu" is used > when > >>>>>>>>> compiling libthr (e.g. indirectly injected via CPUTYPE in > /etc/make.conf). > >>>>>>>>> If it is not used, libthr is broken (regardless of -O level or > debug/normal > >>>>>>>>> build), but -mcpu=3Dcortex-a15 will always produce a working > libthr. > >>>>>>>> I think this is very significant progress. > >>>>>>>> Do you plan to drill down more to see what is going on? > >>>>>>> > >>>>>>> So the problem is now clear, and I fear it may apply to other > architectures as well. > >>>>>>> dlopen_object() (from rtld_elf), > >>>>>>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > >>>>>>> holds the rtld_bind_lock write lock for almost the entire time a > new library is loaded. > >>>>>>> If the code uses a yet unresolved symbol to load the library, the > rtl_bind() function attempts to get read lock of rtld_bind_lock and a > deadlock occurs. > >>>>>>> > >>>>>>> In this case, it round_up() in _thr_stack_fix_protection, > >>>>>>> > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > >>>>>>> Issued by __aeabi_uidiv (since not all armv7 processors support H= W > divide). > >>>>>>> > >>>>>>> Unfortunately, I'm not sure how to fix it. The compiler can emit > __aeabi_<> in any place, and I'm not sure if it can resolve all the symbo= ls > used by rtld_eld and libthr beforehand. > >>>>>>> > >>>>>>> > >>>>>>> Michal > >>>>>>> > >>>>>> > >>>>>> In this case (but not for all _aeabi_ functions) we can avoid > division > >>>>>> as long as page size is a power of 2. > >>>>>> > >>>>>> The function is > >>>>>> > >>>>>> static inline size_t > >>>>>> round_up(size_t size) > >>>>>> { > >>>>>> if (size % _thr_page_size !=3D 0) > >>>>>> size =3D ((size / _thr_page_size) + 1) * > >>>>>> _thr_page_size; > >>>>>> return size; > >>>>>> } > >>>>>> > >>>>>> The body can be condensed to > >>>>>> > >>>>>> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1); > >>>>>> > >>>>>> This is shorter in both lines of code and instruction bytes. > >>>>> > >>>>> Lets not allow this to be lost. Could anybody confirm that the pat= ch > >>>>> below fixes the issue? > >>>>> > >>>>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c > >>>>> Author: Konstantin Belousov > >>>>> Date: Wed Jul 24 13:17:55 2024 +0300 > >>>>> > >>>>> rtld: avoid division in __thr_map_stacks_exec() > >>>>> The function is called by rtld with the rtld bind lock > write-locked, > >>>>> when fixing the stack permission during dso load. Not every > ARMv7 CPU > >>>>> supports the div, which causes the recursive entry into rtld t= o > resolve > >>>>> the __aeabi_uidiv symbol, causing self-lock. > >>>>> Workaround the problem by using roundup2() instead of > open-coding less > >>>>> efficient formula. > >>>>> Diagnosed by: mmel > >>>>> Based on submission by: John F Carr > >>>>> Sponsored by: The FreeBSD Foundation > >>>>> MFC after: 1 week > >>>>> > >>> Just realized that it is wrong. Stack size is user-controlled and it > does > >>> not need to be power of two. > >> > >> Your change is correct. _thr_page_size is set to getpagesize(), > >> which is a power of 2. The call to roundup2 takes a user-provided > >> size and rounds it up to a multiple of the system page size. > >> > >> I tested the change and it works. My change also works and > >> should compile to identical code. I forgot there was a standard > >> function to do the rounding. > > Right, my bad, thank you for correcting my thinko. > > > >> > >>> For final resolving of deadlocks, after a full day of digging, I'm > very much > >>>> incline of adding -znow to the linker flags for libthr.so (and mayb= e > also > >>>> for ld-elf.so). The runtime cost of resolving all symbols at startup > is very > >>>> low. Direct pre-solving in _thr_rtld_init() is problematic for the > _aeabi_* > >>>> symbols, since they don't have an official C prototypes, and some ar= e > not > >>>> compatible with C calling conventions. > >>> I do not like it. `-z now' changes (breaks) the ABI and makes some > symbols > >>> not preemtible. > >>> > >>> In the worst case, we would need a call to the asm routine which > causes the > >>> resolution of the _eabi_* symbols on arm. > >>> > >> > >> It would also be possible to link libthr with libgcc.a and use a linke= r > map > >> to hide the _eabi_ symbols. > > In principle yes, but if the ARM ABI states that _eabi symbols must be > used, > > and exported from libc, then this is also some form of ABI breakage. > > I hope that https://reviews.freebsd.org/D46104 is acceptable :) > Can't speak for kib, but it looks good to my eye (though I agree with his naming quibble). And helps avoid -znow, though I could have gone either way on that. It's also simple enough not to be a burden. Warner --000000000000bab606061e040273 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 24, 2024 at 11:34=E2=80= =AFAM mmel@freebsd.org <meloun.michal@gmail.com> wrote:<= br>


On 24.07.2024 17:47, Konstantin Belousov wrote:
> On Wed, Jul 24, 2024 at 01:07:39PM +0000, John F Carr wrote:
>>
>>
>>> On Jul 24, 2024, at 06:50, Konstantin Belousov <kib@freebsd.org> wrote: >>>
>>> On Wed, Jul 24, 2024 at 12:34:57PM +0200, mmel@freebsd.org wrote:
>>>>
>>>>
>>>> On 24.07.2024 12:24, Konstantin Belousov wrote:
>>>>> On Tue, Jul 23, 2024 at 08:11:13PM +0000, John F Carr = wrote:
>>>>>> On Jul 23, 2024, at 13:46, Michal Meloun <meloun.michal@gmail= .com> wrote:
>>>>>>>
>>>>>>> On 23.07.2024 11:36, Konstantin Belousov wrote= :
>>>>>>>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, = Michal Meloun wrote:
>>>>>>>>> The good news is that I'm finally = able to generate a working/locking
>>>>>>>>> test case.=C2=A0 The culprit (at least= for me) is if "-mcpu" is used when
>>>>>>>>> compiling libthr (e.g. indirectly inje= cted via CPUTYPE in /etc/make.conf).
>>>>>>>>> If it is not used, libthr is broken (r= egardless of -O level or debug/normal
>>>>>>>>> build), but -mcpu=3Dcortex-a15 will al= ways produce a working libthr.
>>>>>>>> I think this is very significant progress.=
>>>>>>>> Do you plan to drill down more to see what= is going on?
>>>>>>>
>>>>>>> So the problem is now clear, and I fear it may= apply to other architectures as well.
>>>>>>> dlopen_object() (from rtld_elf),
>>>>>>> https://= cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
>>>>>>> holds the rtld_bind_lock write lock for almost= the entire time a new library is loaded.
>>>>>>> If the code uses a yet unresolved symbol to lo= ad the library, the rtl_bind() function attempts to get read lock of=C2=A0 = rtld_bind_lock and a deadlock occurs.
>>>>>>>
>>>>>>> In this case, it round_up() in _thr_stack_fix_= protection,
>>>>>>> htt= ps://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
>>>>>>> Issued by __aeabi_uidiv (since not all armv7 p= rocessors support HW divide).
>>>>>>>
>>>>>>> Unfortunately, I'm not sure how to fix it.= =C2=A0 The compiler can emit __aeabi_<> in any place, and I'm not= sure if it can resolve all the symbols used by rtld_eld and libthr beforeh= and.
>>>>>>>
>>>>>>>
>>>>>>> Michal
>>>>>>>
>>>>>>
>>>>>> In this case (but not for all _aeabi_ functions) w= e can avoid division
>>>>>> as long as page size is a power of 2.
>>>>>>
>>>>>> The function is
>>>>>>
>>>>>>=C2=A0 =C2=A0 static inline size_t
>>>>>>=C2=A0 =C2=A0 round_up(size_t size)
>>>>>>=C2=A0 =C2=A0 {
>>>>>>=C2=A0 =C2=A0 =C2=A0if (size % _thr_page_size !=3D = 0)
>>>>>>=C2=A0 =C2=A0 =C2=A0size =3D ((size / _thr_page_siz= e) + 1) *
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_thr_page_size; >>>>>>=C2=A0 =C2=A0 =C2=A0return size;
>>>>>>=C2=A0 =C2=A0 }
>>>>>>
>>>>>> The body can be condensed to
>>>>>>
>>>>>>=C2=A0 =C2=A0 return (size + _thr_page_size - 1) &a= mp; ~(_thr_page_size - 1);
>>>>>>
>>>>>> This is shorter in both lines of code and instruct= ion bytes.
>>>>>
>>>>> Lets not allow this to be lost.=C2=A0 Could anybody co= nfirm that the patch
>>>>> below fixes the issue?
>>>>>
>>>>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c
>>>>> Author: Konstantin Belousov <kib@FreeBSD.org> >>>>> Date:=C2=A0 =C2=A0Wed Jul 24 13:17:55 2024 +0300
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 rtld: avoid division in __thr_map_= stacks_exec()
>>>>>=C2=A0 =C2=A0 =C2=A0 The function is called by rtld wit= h the rtld bind lock write-locked,
>>>>>=C2=A0 =C2=A0 =C2=A0 when fixing the stack permission d= uring dso load.=C2=A0 Not every ARMv7 CPU
>>>>>=C2=A0 =C2=A0 =C2=A0 supports the div, which causes the= recursive entry into rtld to resolve
>>>>>=C2=A0 =C2=A0 =C2=A0 the=C2=A0 __aeabi_uidiv symbol, ca= using self-lock.
>>>>>=C2=A0 =C2=A0 =C2=A0 Workaround the problem by using ro= undup2() instead of open-coding less
>>>>>=C2=A0 =C2=A0 =C2=A0 efficient formula.
>>>>>=C2=A0 =C2=A0 =C2=A0 Diagnosed by:=C2=A0 =C2=A0mmel
>>>>>=C2=A0 =C2=A0 =C2=A0 Based on submission by: John F Car= r <jfc@mit.edu><= br> >>>>>=C2=A0 =C2=A0 =C2=A0 Sponsored by:=C2=A0 =C2=A0The Free= BSD Foundation
>>>>>=C2=A0 =C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 1 w= eek
>>>>>
>>> Just realized that it is wrong.=C2=A0 Stack size is user-contr= olled and it does
>>> not need to be power of two.
>>
>> Your change is correct.=C2=A0 _thr_page_size is set to getpagesize= (),
>> which is a power of 2.=C2=A0 =C2=A0The call to roundup2 takes a us= er-provided
>> size and rounds it up to a multiple of the system page size.
>>
>> I tested the change and it works.=C2=A0 My change also works and >> should compile to identical code.=C2=A0 I forgot there was a stand= ard
>> function to do the rounding.
> Right, my bad, thank you for correcting my thinko.
>
>>
>>> For final resolving of deadlocks, after a full day of digging,= I'm very much
>>>> incline=C2=A0 of adding -znow to the linker flags for libt= hr.so (and maybe also
>>>> for ld-elf.so). The runtime cost of resolving all symbols = at startup is very
>>>> low. Direct pre-solving in _thr_rtld_init() is problematic= for the _aeabi_*
>>>> symbols, since they don't have an official C prototype= s, and some are not
>>>> compatible with C calling conventions.
>>> I do not like it. `-z now' changes (breaks) the ABI and ma= kes some symbols
>>> not preemtible.
>>>
>>> In the worst case, we would need a call to the asm routine whi= ch causes the
>>> resolution of the _eabi_* symbols on arm.
>>>
>>
>> It would also be possible to link libthr with libgcc.a and use a l= inker map
>> to hide the _eabi_ symbols.
> In principle yes, but if the ARM ABI states that _eabi symbols must be= used,
> and exported from libc, then this is also some form of ABI breakage.
I hope that https://reviews.freebsd.org/D46104 is acceptable := )

Can't speak for kib, but it looks= good to my eye (though I agree with his naming
quibble). And hel= ps avoid -znow, though I could have gone either way on that.
It&#= 39;s also simple enough not to be a burden.

Warner= =C2=A0
--000000000000bab606061e040273-- From nobody Thu Jul 25 16:48:51 2024 X-Original-To: freebsd-current@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 4WVH0M3Pbcz5SLBH for ; Thu, 25 Jul 2024 16:49:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVH0L3G8mz4qdc for ; Thu, 25 Jul 2024 16:49:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eJfXYEpS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721926143; bh=Wj0xHi4kUFozfiOCo1bJUYtFOb1Q5sCBlR1V86ZHOJc=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=eJfXYEpS5pAyiR5rQHsPvKUrrCvkUHsGW+ItenoGmh7xOi821xPIBI98QsO793ZPM5tldn81Gwf3w1PG0e4gzSd1d3bQxO3jjFpcdHtuQsb1THknma9je3WQSeBxjyIwKg46YDx3xTsmM/zSv4kEQBKpWcr4zTXL+KiD/0CQu2ny04y5yVH0kiX9sHdtu90oF4AF8Hgel/+M26XXFZnRpwlVyjc0d3IKeamEn8lg8lSqbRvhcJ18qLzrSs2K2I73K9G+WuUwDeLImGukycz82Dda7sXpJmGveKBg9CQyGo9U3yEM6RX6eDx03JdDOlStjm2O6/brJg8WCHPyEfE2fA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721926143; bh=vZw2RZwnEzlbmpTiMUgNSMABqTI7UMSK6aU70CULpGn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SWBeMlOVjz3MxPssEHMUbEq+oIAu7BISRgrjb/bNvwnJgNlcBbzjOMTcYNB9lRk4CvyUGXrmjCzFmdYGdacOYbsBgr4lTxp+ha4VcUr7p6NDVsdHoj4oa29vtyw5msi0vNWH7a1mnFM+3kTCXqftbMZx1A1Yc91vhwYXLAQ12mKgoVc8MZeAUnqKZ7FXl62C8w7ojlUC5fMXL9WfjV/OAYFm8pdisGeYtxYSc4bPouEB6Hn1czkiDd5dfkz2xo7pjC6JniBgq/uPrrTPb4ysBnQRKbrkxK36usoPOSxHfTlKioUF321cFRLrFaNeoQRwCDrPaHBt9ncUOyJi+mvcxw== X-YMail-OSG: RUv35SYVM1lFMc1_BSgttkVQ5mYYCXZA6ksDsS0sYbopfnCn1o1qLrz.WrCj.HY VKHQ6nGbL7j0GVx..rMyyrrXIqOlidKh_wXtEXnvYlhJ7_.AlAuAbMz8ectcG.yZlEoQSwDc0ZMz iTEfwYojBhcf2tApYI0lAz6688IfLGlVujydsTD7Fa8Pcqz3nv1lvI3N8sfxHimkjT588S_PmoR_ _PgV8abgS36UOyctq.hl5m3kX7V69nMNvi6Sp.uhGScbgMtQ.uWNSFFlJ02P0h7Xh.ZJkT7S5gDv 4zOLGCMGg3SRSNRSiG7On545NQVEk10teVMEkaQQiYRnX52.OcuhHq6JCUua6Fs27HJdvkOyjnBk 1g.CKuijImKkSuMnNKN6u1FUT4GcNlqAIlo0vyXXiNk41FH1k4s2VjJ5qOgrsyG.WEjBBG6hR9aZ b0JWipNEl3XBjfot9D0YThzsdbK5PLxwrACjN7POVt8U2cxwCpmktJbVdFTal8NBx7xzqQq0O5Li OlrzU_2k_eH6KmNOw1Odl1EWfB2dEKXO_X4BndRRKPCdimqHS0TAUujaM_B5dh2xATnYpke3YjY_ jRNWBVLeSKrAvZdeTVFBYYv7yImhWXg_Hkf8IrZyv6AXCRHsmyMMT5SHGtATC7hpVQLFqBGF9oQD 8iiZZP5NP_jmqzx57QoHr3bOxJ7eZYyM7zDBIM9OP2MnTH5VFm3dzZCCICFYJlcKNd3F6JLbl3uT vvrqnyNfUGl3qJOQYQIOYbCbGT57Lw_VK8Pe_OH4eFmCBy1iuZ87cL5y73_Y_s63kfYe37txaDa4 _0gcJtkbWIcJJ8xT1JiqtIt.AHmtF0X7rgr5mlJ_o12oPLn1FzCFm0UaoO9c0X_bysJQW1at1v4p y7U78MIskB5GikrU4KAPyf1Gl6SH40901MyEW8jRu9Frfc_jKqB_h4F3PXR1ZqZI9vwsyMX3EFDV 7Qc7akFjX6Bvg_zwHWp4Cw2rSmgKF6.MLFjtCow0LZSib.UUmHvngsLe7mjJ.Qv2JhO.k1OzYws_ eTCFIo.GzW_DOpA8eeZhop7f55jFdW0fsnH3NvGrRFYwz9QIdTTDp9QJS6xYAVuwJX6PyVDJOE1J b5WAEfeO3uiBIrW4R1b7sbTOo1m4TUFH1TMAeYlRt0NQFg7gIxo9orYLAKiU1gfDnbTp5QweE9wm .N7d8I94c_XEBNDqKNYTHaMn92H8dKtPWRQDWvoDl_ZgpKaJqsxbDsfIOQ2CDKW6EagwxinieF8t hEwdbSB388eA7NidzR.2C6CWsagDQie2R4dFdF8ObE4UENXX2IaFNP8.zCZ80zH..ACvWFfYfriq b6Hy.KZkZtMhBbgy_nJc3CwGrhX8iblGyFgVvXrEpnPptUvJy0qiFZ9RjWn4XpVQEYiAovVKNXWh 62XFQPlkobqLVEaLvcfiyiybkbZWa2N_g2LwIP7ISdA7MlxRXbPmuFIw78.QG.quXPUiOyzxo3hc 1aIr2kgKbdy2L4jPbZkrLyRqcCvRImHfWjTbBehnn0woQugkojSxSw1KZ6OIK45VcymILYMYSagr F0yK4g5x1A30nGi8NakenkM_f28cXTWBO7IohmLMtIAYO4bAmt5oFfzHT8IvOOw1DqTyGSLXGRmq 0mMufbX.PQW3WQTawupKNdvnd6dfQNtzWwN4jXBNFe0GNgssMxUoAqnDknmjiW2fUmiVNmLuxv7X .SX7x9VneXz9mU6yiJ1iipF3.LduPQhOiJOOouWzKJHX1bUmlWGU6FBK5_YolKkNBDMTqfwo.usl _aOOEaF1o3.WmfCCR83oCe2JeIAhdjP.lwxgduzoq3lR5FMsQ7MNx817tZxeIAv_0ln02RycwplD f43BleE_IYqh8mzmcs5vbUzBbWssKe0qrnMlUzBBKSuozlR043Q4lou91Ff6YB2AuXgXwfebcyHi UPYOD16ulcdSp0swcNRauh9RlnxqaqrUBH55Ymz5TNlOnZ4PqaA9LgKLnX9v6JV6Eon5QktyXaNx OK6nMZrLivpCM_ul0JGeVIDduPBamxJjiRVFLuio0pVnQkxM1u3hh.iCCiP2akBij01F6fIppnSo Q9Wa5C1Xtvg3Nlpf_EGJhrmnjXtQryNPfVb5HauTjaoAIQnOaXDxNP1vWSAg2aC4IXcDRtV6hS.7 oH4HGE_PbJzHL9607qL19WKuDXGnErQxLkG8TMw5a7DrCVzEt0MYHL0_1rxjOgN23WQvglZJ3qKc PyklLkk3axuPthp2OZfwEBmBwtxiW8MwwcrMlD5Jk2gr2Kb2SrEUwVPAhu7DLL6pSiKLO5yijXi0 i1Ij3.Qd0_misJlcY5w-- X-Sonic-MF: X-Sonic-ID: 9f0337d5-e4c0-4341-976b-c8508af2f73d Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 Jul 2024 16:49:03 +0000 Received: by hermes--production-gq1-799bb7c8cf-l4fvm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 146d47a83d99a14bf4deb149e0c9007b; Thu, 25 Jul 2024 16:49:02 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: [main has a fix for] Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Date: Thu, 25 Jul 2024 09:48:51 -0700 References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> To: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD In-Reply-To: Message-Id: <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.01)[0.011]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from] X-Rspamd-Queue-Id: 4WVH0L3G8mz4qdc Michal Meloun has committed a fix in main: See: = https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.h= tml that starts with: From: Michal Meloun Date: Thu, 25 Jul 2024 16:25:09 UTC=20 The branch main has been updated by mmel: URL: = https://cgit.FreeBSD.org/src/commit/?id=3D5670b8cc3672d5a6bc2c41eb48d7d013= 43c43ad0 commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 Author: Michal Meloun AuthorDate: 2024-07-24 15:11:27 +0000 Commit: Michal Meloun CommitDate: 2024-07-25 16:24:22 +0000 libthr: Preresolve selected EABI symbols on arm. Add the ability to pre-resolve architecture-specific EABI symbols and use it on arm for selected EABI functions. These functions can be called with rtld bind lock write-locked, so they should be resolved in forward. Reported by: Mark Millard , John F Carr Reviewed by: kib, imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D46104 --- lib/libthr/arch/aarch64/include/pthread_md.h | 5 +++ lib/libthr/arch/amd64/include/pthread_md.h | 5 +++ lib/libthr/arch/arm/Makefile.inc | 3 ++ lib/libthr/arch/arm/thr_rtld_arm.c | 67 ++++++++++++++++++++++++++++ lib/libthr/arch/i386/include/pthread_md.h | 5 +++ lib/libthr/arch/powerpc/include/pthread_md.h | 5 +++ lib/libthr/arch/riscv/include/pthread_md.h | 5 +++ lib/libthr/thread/thr_private.h | 1 + lib/libthr/thread/thr_rtld.c | 3 ++ 9 files changed, 99 insertions(+) . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jul 26 14:46:57 2024 X-Original-To: freebsd-current@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 4WVrFJ2r8Vz5SF42 for ; Fri, 26 Jul 2024 14:47:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVrFG6WRTz3wfs for ; Fri, 26 Jul 2024 14:47:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="M0/dgcW0"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722005232; bh=oNGJtF1RObKovM/xJ2B6MtvkMv06F6/qhd3EUL9h5g4=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=M0/dgcW0VhMuxy7IdNm4Cpd0ta6vlxB9STRctjDb4DUc6ppb/4rNN0TLKlZ/LUR6zyjL4kZriLei4g2OM5gB7wKRZxasNPu3W7y88vh1N2NIn0TZOtZCSjS+MPx/5KJDxv3Kvrr1UDg1HALGzdY/tbn0ZGzl8pvj+1YXTPDIl+kAMNDPOf36xsEK7s3nMVtXbRHuQ65ifVmWd3UxkJp35ymNSOln557KyEKkCKhJre4i9Lplk2le6ibyzov1EKMk4iyDmuTEpqqlbJE493E52Py0tjqo17LuA3efkIexMRlMUym42TYYOWQETNRADN93G2o/WxUGlGNNmwcPjdtx8Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722005232; bh=6s6Gm56pCryZeNjS+00NOPbPjimungME1ZXdayOpdCZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Tllv5oxRjLlkHO1ieko0t+0ux7j71Lx5kQ9avhid18e6EKjT327QLo9A6wY8Jh4Wla6NSWSa1x3d9BCxD/NIFaEy66eUZ3O76ZFEQvMdixlTHVulgCkasENZFZVJo0vUZ3JntpvVWQApar15AmH+IVLwLjCS+x7IT+5X98lZwX3LlJniWk9VYeGhoa0MaU+iDJmT8YLY50htslsAwDJzk2X7nnQobP9faFQismRxhJwX9cz+g2nlvikPsty+LWp9A8semkQpWbSJk7pjA0ZNgEGSdZthdsprXrqHKlSYlO4+4r9eXU4MRSP3IF8Bk4BHjaLV7WsglKsovzVre2Db6w== X-YMail-OSG: o.OLqHoVM1nYndN_v8CNP1I8IeWQDy1GraBF5qmK82ewB0g0VNpYq.hNQX.f8TO CuQhVDs.osHTeUb_JN1Flba0o.KHCyMFjAetJFeDnXvM6Wk8SN70E1kwRZCjIT8Yk71YLfQP37Mp Iv.v1IibOzOJ8FjfAbNLA8_m4gDaExLgBT2inxVfU9ChHQD1IyuBIMosWsmMhyzEBVKY044r1Sl6 ezoYoXBchUNi7aSZ5Wb4hGNR4AVzQk.m6zRAkePST6aG0Ub6ZZ6A2vzXKBfIH0M8njoVfoByn8_g rrqtzicg5nwURr3frDshfdJndEfMIL.9AvjzoPvu3h03JJPni7jUI7.Lk1oHJBBHO88._LnZmbiS EtuGqGVxf7ab6Sq0zdfqI1qe6pvfeujvHyXA13IZqkMY7wCy_brJT1vRcK4O4kYlaqsr2vK2fiJM bPXLwK6HDymhXXNMMyXlMg9K5WCtVGfbwUVcw68HYPvkJTrBtXuP5At7dnxO8nbxkx9JDa7lRY_n vSo7_kwvHHztCpK.KQZkEPc6t82ZLgf98s7e5Yb4UJxpLqPZYh_SEwoF7rj5jUrB5BY2RQjsoH.s ws53f3kNzzvwKumzLeCCIuzU61nr3kEdFZ0S9Fwcb.1i1NIzYLKZ5RGeZMW_PzaqIwQyiiYVpvUS oMbdU7uvhOHLnULvdJylCgDJcIAooAStNh_7YFAglyj3xL4YMlZFzyQxfMbLlbAiTICnorPNR2Om mTIN1wYo_rYONvBmdJPOiWNlIcCr03AWwUq2Y00Bj5cdwIIYsFkVJ5SC4AY9x96XGVr.43yaBRIV IUP6uDqEssDLeRrXKhmRlpj8z1G3Ky1ddO9J5XH4q3645BTQhuYt387aHC7ugBAQGVvFZn2iq3Ku AfVKotIU41bXlYfeW6fzWfBmShiVktzNeDpsaxUt2sPc3.uhyNNhjrnr0_q8EALMIZKyBmQ2vmfa d8vEGBQCIqPJZ.ualmkxYit59BqH89XrR6hVtgAWQDMcC4euFT9Gms86OXc85tGEKFia06i6JnaG viFc9ryjE05pVkqwWg2ppsGI85iCsLNnrthQ0gY1ApOaAQC6t1o._CcOFvMotqycowWrMHxEkl3l ncqtZwkfihWseDmW3xLBU6PSLxfBUuWs0B5pRMC5rkaZWXOUrbhYD7CpizH44XHyZDciHy3sCTL1 R8vm6zXquIAlXnzHmHwY_i7EtXSB0sVVU3CAqQSOlVaOAsBeGy7mvXAs.xOngR33RiEylE18GolY eFUiHe5oqqT3C_KKCfBQ50evsKPMG0MBtRdhvlQnxYi91ncmFg.yD240x9a42OY2Xsj9ITkVUBId QxSTomf2XjMiBh.Z4_8ulDWhq6N0iyWfyYBtS_fsSKh2QB9VBzCMSgQcu3wV6EbfTFh4ZxVq9GIB 2DhcPD.tsYZmx58FTzibLzGdifHS8t_UX1Buqww2A87HIqQt2q8xRdBeNG3NkrAxQkeEq9r0TSf_ znC_5rcAwqgjluj9hGd5bPlQhWU2kqH7d20AXwIZxsMqkK1eCp6BK3Pm9lfZKYbNRZHv4750gE28 x579CcdKckdJfkNpBgj.I.gIfpzv6rz4hVM5OhDgbkdnxHIKoYKx4MXUatcmHftSyNnILxvoZ8qD vVwnbHcRRt5EQJqgCbJJXSa_hdy_sjOerTpFZ06Y1vuYw672aamktZWkz5t6iMW.A_N0SGxEtOS7 R7SsgFp3IFt3O4UaMrZnF5vaUlwzdT0PA.K9YTThUhD4HUnB9dmMZBiIV9ihwLLNI_nE3cQD456b x3vKEsOwhnij_XrZeoggosHzmXITZywrOjmShYV8SlTWgLSk7hJql8f6A8Vi84gE7RCx.a3VLbzC jGeoWkeqr4FgY5mK4kQ5dqonwZSXjzEBuNT1a2Q7qDDVvKvA1I99Q8d8KjcXG1twaWYK0jr4mFfl t_U4Uuz_l32Z_WtT5ANJRFBo60u3kADIaMBk5aSxUYUj0D17t7_9u6CH1hiGB_keiHb3b4m2Pb6p k3_oAXrbwt.PPOiF1mNop01ah197YdV5s2s50sSIyotLRIio1FMKby6dDZVCNUsoPEvI.Oql6W2w QB4Q4ttCfqcOFl9LmKqalBdYJtSn.ZPwLcc0ssJEn2XPJTkD.OGs1VDlACwCjhfd2RkxfIRnGTd4 QHrFDN3sKqyl7RS2B6kf9iJFWvp2sFtSkmXObA15T3c9Yngei5gCSBtWP1MxZy6TCoFhd5Tp9Gi6 RfS3IGWNt3f7mwYqh6t8ooYMKbxkPlnFP29sx8uh2gOKRLR_rvDLBJCOcfPdvoYKzzy1aZqHSjzS kRbLuRe8eKLMAJhU4FzUC X-Sonic-MF: X-Sonic-ID: 373ac1e9-a001-4410-8c0a-7af4dfeaaf62 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 26 Jul 2024 14:47:12 +0000 Received: by hermes--production-gq1-799bb7c8cf-hxpdl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8494b3fa5cb93eb71c93061f68f13b88; Fri, 26 Jul 2024 14:47:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Date: Fri, 26 Jul 2024 07:46:57 -0700 References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> To: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD In-Reply-To: <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.43)[-0.429]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from] X-Rspamd-Queue-Id: 4WVrFG6WRTz3wfs On Jul 25, 2024, at 09:48, Mark Millard wrote: > Michal Meloun has committed a fix in main: >=20 > See: > = https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.h= tml >=20 > that starts with: >=20 > From: Michal Meloun > Date: Thu, 25 Jul 2024 16:25:09 UTC=20 > The branch main has been updated by mmel: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D5670b8cc3672d5a6bc2c41eb48d7d013= 43c43ad0 >=20 > commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 > Author: Michal Meloun > AuthorDate: 2024-07-24 15:11:27 +0000 > Commit: Michal Meloun > CommitDate: 2024-07-25 16:24:22 +0000 >=20 > libthr: Preresolve selected EABI symbols on arm. >=20 > Add the ability to pre-resolve architecture-specific EABI symbols and > use it on arm for selected EABI functions. These functions can be = called > with rtld bind lock write-locked, so they should be resolved in = forward. >=20 > Reported by: Mark Millard , John F Carr = > Reviewed by: kib, imp > MFC after: 1 week > Differential Revision: https://reviews.freebsd.org/D46104 > --- > lib/libthr/arch/aarch64/include/pthread_md.h | 5 +++ > lib/libthr/arch/amd64/include/pthread_md.h | 5 +++ > lib/libthr/arch/arm/Makefile.inc | 3 ++ > lib/libthr/arch/arm/thr_rtld_arm.c | 67 ++++++++++++++++++++++++++++ > lib/libthr/arch/i386/include/pthread_md.h | 5 +++ > lib/libthr/arch/powerpc/include/pthread_md.h | 5 +++ > lib/libthr/arch/riscv/include/pthread_md.h | 5 +++ > lib/libthr/thread/thr_private.h | 1 + > lib/libthr/thread/thr_rtld.c | 3 ++ > 9 files changed, 99 insertions(+) >=20 > . . . https://pkg.freebsd.org/FreeBSD:15:armv7/base_latest/ has = 15.snap20240726110821 and updating to it leads to avoiding the hang-up in my dlopen_test.c = testing. It is based on: 126 static inline size_t 127 round_up(size_t size) 128 { 129 if (size % _thr_page_size !=3D 0) 130 size =3D ((size / _thr_page_size) + 1) * 131 _thr_page_size; 132 return size; 133 } that uses the _aeabi_* routine(s) in standard armv7 builds. But that no longer causes the recursive locking deadlock problem. So, it looks like updating the kernel and world on ampere2 and enabling builds of main-armv7-default should no longer have main-armv7-default hang-up during graphviz installation (or analogous contexts). Hopefully, that means that main-armv7-default builds will then complete and be distributed. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jul 26 14:56:00 2024 X-Original-To: freebsd-current@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 4WVrRV2Zk8z5SFRy; Fri, 26 Jul 2024 14:56:06 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVrRV1r3zz40Z3; Fri, 26 Jul 2024 14:56:06 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722005766; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XYfrGhIlGsNjt86Gp4NF1aYIThg3hEZfkdyPza5JE7U=; b=pNLnxZDtAZqXCNw6UQfUNjvjcIKiAECxBFO16ZzpTLiY262cOrL0ZkKgS+MukyHSwd2LDd +QtRuD5GD6qymY9TtCJURpB72rrygT+sAc9BiHw2Ty77igPm2G3oWmeezMBGB4fzdNRr/U 1KJJbndW59hFcyfj14jI6bwfRfqkB/otZ2VpHEQlJ3IRrCcyGv9E36jJqp3m6ziVC5mvMC pXqaQz3r0IhMmbMExmm2xpYTbgl+F6JZf+Ylm+dMcBEGEDWWnpdCrycZng4zxvatuD9icU oLKDUCzLN+yWkG9U/nA0tJzHtmdeQg7ATChIk0QsGSmsX/z4UzUY9PQP1XTXtw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722005766; a=rsa-sha256; cv=none; b=LuYPepq92GEVSW0wyO7wPXaorMj/Kcl/w/tQ3WL3A42SclSYDem2gjWG13mj8kKG7/xB5Q 0cxAbieJQ/F1zboCANZfVXL8m5YGwhpS+hcwrtuLTeWM+C8jHL/cq5WCyNugW+yMcaGuq7 K+G4U4Yy1h4PM86Mkhph10zYn2Q8jE0X51Gr29s383zYiEO8aQUAvmd54Ak4nn+KgWGDqR 9juZ71/OlWqjeOfPKQWZ6CdHmiWDvMjJIIIG6PwiakOqMhAdMq6rIlUq7/BqQ7fAezeZGT SUJMJ0n/e+IYICfZGJMXNbCc3ndCPccFIkqJmF4RnINz1S78r3uM1yDscWfPAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722005766; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XYfrGhIlGsNjt86Gp4NF1aYIThg3hEZfkdyPza5JE7U=; b=G32RAKKdTBsMkxyHD4nJixcIM79RlItnxEYphwVL7mjLKOJ3/eVHvnov9FJ06J80A9IE5A t70k3QKUI0OJJE4GuA9pSgRtBQ5bUyFA9miFlbj//XpxSFeklznnpnTfrwbLcQl9+4Q1tl awrb1F+7MNsyKLg8RMkdk+flZjWs786OTwLpK6gNj7ODoFQt9a8VB0P3QWp1v5QxHjwXV+ x5oeSTnc3Ff0cu82+aphKCXpf50MMRTtwSCdDY4NQh1iomi4qwGkyH9A7QkEE5PpZ3Ep/s 8kIMPHfBKcmeVnfII+TtfTM1gwaYsT8dJpuLaOVaSxU6hz3H0S3PKc4nnhnNJA== Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com [103.168.172.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WVrRV02Wqzf2l; Fri, 26 Jul 2024 14:56:05 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfauth.nyi.internal (Postfix) with ESMTP id 269A2120006D; Fri, 26 Jul 2024 10:56:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 26 Jul 2024 10:56:05 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieehgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffoffkjghfgggtsehttdhmtdertddtnecuhfhrohhmpefrhhhilhhi phcurfgrvghpshcuoehphhhilhhiphesfhhrvggvsghsugdrohhrgheqnecuggftrfgrth htvghrnhepgffgfeeigeettdeltdfgvedtffdtgedvheeuieetheetfeeifeevveetvddv keegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepph hhihhlihhpodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiiedviedv geekqddvfeehudektddtkedqphhhihhlihhppeepfhhrvggvsghsugdrohhrghesthhroh husghlvgdrihhspdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 26 Jul 2024 10:56:03 -0400 (EDT) From: Philip Paeps To: Mark Millard Cc: FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 Date: Fri, 26 Jul 2024 22:56:00 +0800 X-Mailer: MailMate (1.14r6052) Message-ID: In-Reply-To: References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: > So, it looks like updating the kernel and world on ampere2 and > enabling builds of main-armv7-default should no longer have > main-armv7-default hang-up during graphviz installation (or > analogous contexts). Hopefully, that means that > main-armv7-default builds will then complete and be distributed. I've set the stop-builds flag on the ampere machines. I'll kick off a cluster build and upgrade them when they finish their current builds (or get stuck). Thanks for chasing this down. Philip From nobody Fri Jul 26 23:37:19 2024 X-Original-To: freebsd-current@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 4WW41B6Jrqz5RZb9 for ; Fri, 26 Jul 2024 23:37:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WW41B3mbKz3xQM for ; Fri, 26 Jul 2024 23:37:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722037052; bh=I8OIrgNUQVY+ONpkd3CfXxjehbEW0LwmSkMeFUBafJ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=f9OhaP2mPGq2Sy89dcoUUYk+n1Qa+AF+GXKx0+a8RONWHsxbvuYW3LITXjFCIa6DJ1ZSzec6GW+vyuKH+hbeNXsMLRlMwGn72qvijhzLLEeygzlX0y7v5oxCnzFPPnxgsoV1uDqNziE31lkp8PfdQV+5SrKv9g5PpWj5OtxXKlDFOvWbnKfjsY/1yAcJ1nWno3KU2Q9ms6Jxboy7a2bhCO53qRwfl0fxsLmAWHejQOHRQPU/qZAicn6+mh2PvG/ToL47qr+BqdlF2TDQ7XKzK/HhrG5gTGg1cZjgPCe0072Fr0VWUI7L9DTdpghLmxS8k6XLiAW8tq0lv0EkBhvRMw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722037052; bh=foCUw76C8+hN8Kwzw+42o/yecCSxy/SkEB3pJoHPPh8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DDNgeVv8JasGyrE6/ajOoJ54z+gt6wXWsg9bMgftJg0Qc7qR43o6a6Cg2vGuDh8wgMV/shjyxQ/EvHPpq4e7r3Fvwc2FDYbh0geqJvwPbZsop0++0j6zraBMGngkwSQvNmYcZMUKKfbM7jTT4HUrW3tsiovEbBw8Tqyd7LQ7R4Nujn1fwpanHTJz9FwxEtTVQZv/C2e/JArwVFxnH1iHgGB2VeS6iQoAVuHtDAbsqzoWNwnSz/fW5azQ4E0OK9KKM1tdKtADIOHVx53W+7wEUYjXsc02w2JWdUAmrXV53tkT5SvZkwbDPowiT8MOxKUs2nqU+wqfwbT5wKGPSrDREQ== X-YMail-OSG: b9yPBTEVM1nxp46p.rK5qRXmAF7H0hDS1zAASqDEeZ5JRXLCwmQrezYVhYCmw_C ZDs8_0siK5DEItlWaIiwOxDYoqn9iqr8ESTilLS3u3AljxWBSTbFNlKBwem_.Wj33JUHs282f.g5 bv1j9xa2c3XHRUrOD1MdUMosxGbsVh1Ar3VQxihim3EtTIx5HDApyAzw.FNioeTdkn2EtPRoDvup IWJ3O5OBBoReO6L9Azau0uPN6Uam62NNV7R3NWzHroMADXMYx1QN4rnjyZ.dgXNsEWdiBPIVVRg9 XjcmsBkErIoLzhLfjFfGboZzysfuafd5M.e04vVVThTisxWvKmwMEDDZJZVgGupG1IpOxUiAST9B 0wqvB37CXj2K59GxqNoZjUCsPpabwaDbAgW.rcQhXxVaHn3r3TTZ_6kO_Y_oZ4Wyw92kxRWSAW2l AvDkD6cbKoJg8FS1hSqMa3MfWLQCDNefp1RNFKMjXjeInW3PjMrIM6z3rvT_.wiEpOgTR0.OVlx4 h65CDwBPmWFsQv.Nb.bwkc82_2Gn7UMrtW46iRo_WpShkBtzB_Ng6PhPtzndttlagg.PMwkBGSpD kBiGLWrMKqSE1DfeTqtx2v7r4EsrqA0tOwRuh13rO527Is8NsZHx_xHHEurkiJ07.Ibs9Oauqrgn ENLQpGhbzjTbA.9FjJydmCilcSsulL0_QS3_ej5FWqP9TpBfNliKW7zcZAh9anfv2ugeeNmcBcn. gb9d_Uc2fr0bnwjR3X9JM93DSrAqAVp3tx3Uy1sUhh_XFd2laFQv4hIbiyOn_st8AHS.NIom7Ehz .1GjoN0jUnhWDA7Ymifi5nTlvXgU4Rp0tV2mQUPPfbVyYdgjgWP9_.8ro8orpIp0CZ7L6qh3hda6 BJ7sJaCtLmiXG4__r3RD.jbArB4mc5bG0JZapqWxzbJfnpHKhu9Nfj_Z9gc19NzTgvW3AbecCKFN xRza87U03gRs_vB68xlAX.Gu8tmLECa5lWDUaAy4cf1kJJQOwU4TUN0tryqNS.gw.1Ins15gcoD2 Q9P_SmdK.X3ACk0MV59pTscJ1_oiHW9WJgDLS0AjfKXJPHkTIMnv.T2HtHPD8DhhHwwvy3kSAGQ. ra3h0DsO4qt1eQqV_Wx1ARikPwKvbJJxRPUlUDRqKsfuRudluIII_hHfGH_atE5L_4xRTTNm.hn3 18GFwxpgyAk_Z2tlON79tZ4RivpEeoLZCvG.Ot5ISrnBAxSJJs2V6FCPfI0qDfrKdWWjARgNwo3h KO.oUce_fptqc2QfdUU2uOY2H2h_tglpioxObEx0qadGBBZd9xKf5FWK4taQXx_383uFsIGu0uU4 HaUXHjXG4oNEXs4YNSi98yEghhbH.bNvB_QgfNAuzar2RG5lYlHY7ytgt4elhVZODalKUQp6CbXc yrmQfhPIk787oxGhRZ_mzj_Rs4sT90XdSAkFcVJVnzfZAtijF7EKEgls5O611gS6v_Q_HMZMr9GX YUQdNVKRlcTjQWIieH4WTVsEJ6W8B_H5dSMDAG2C_dv.jsKBj3eWGLY7L_SwrbeBvEw55zZivQvr _pUlDv3VvwMzt.IxfHRvYXY7AOQU1C3SEltAePjmNnSkFoO6ZeAEVSVvYjJ4rg4Jg0N7BUTV3G3n 84XUfC4DwazUtYr5NQXBFi6rZywe_NsUCNpb8932dliLInufHybdZIjPB7B1bvEJ.lbhO4dFMuob EzGWoA_sfzC..q74mnD_.3GtibyQbCI3.Nt_s6tKvAaYs8pRLEcJRkprCQa7.DnskRod.nwCaBYV k5CyH07PFsupU_xPf4Pz1ZcPzkq7vV5mzHT7OrBdq1Q8YZcR3GdaFjD86KQOmMRBke27SXVeG0S0 4YYRQ1u_YQmpe1GiRZNKvhlf55xaFWBTPprLW7.U3h1kczksvRCnxwVGAvrPzO_wS0Xgvme_gBOy 48yIsZseBpLPVD2H321kv908rOjiIOmAOIrMXjDeovt2iRng5gbhKmlU5gETU1WMNVFhdaXbi1PY un7.IwGehYKvSUQzF8.160DgxZa6aSSQbChHbQlM6CpdMCOoi5ifzfsbh_NMX0DNNGeJtLKHFNkh AWJY1OSg9lQqqv6CQ.K3EpIrYxmrGRtwjGv_Mf5JPBUpcufmiLylJY797jK3uv1kjRP2ERBIpalW Q_A6PpHC5jYVXLvcTSWcbTZEksL7yPCsv9tx3gZ7CyuBDyfqDA8WQN5IjLljaNUjg_lcvSl2y1KC EY6mRket0RHOX1qTn5rBbTIZkGEOny06tJ.JrGaeVyzTVMmqnMqeItJdw9dKY3zJ8oJtQzBi91_P 5QQ-- X-Sonic-MF: X-Sonic-ID: acf2d210-7a45-4f57-b510-a39fa282e45a Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 26 Jul 2024 23:37:32 +0000 Received: by hermes--production-gq1-799bb7c8cf-cvhk6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ee03a68b986289cdb5103aaf6912c454; Fri, 26 Jul 2024 23:37:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: Date: Fri, 26 Jul 2024 16:37:19 -0700 Cc: FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> To: Philip Paeps X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WW41B3mbKz3xQM On Jul 26, 2024, at 07:56, Philip Paeps wrote: > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: >> So, it looks like updating the kernel and world on ampere2 and >> enabling builds of main-armv7-default should no longer have >> main-armv7-default hang-up during graphviz installation (or >> analogous contexts). Hopefully, that means that >> main-armv7-default builds will then complete and be distributed. >=20 > I've set the stop-builds flag on the ampere machines. I'll kick off a = cluster build and upgrade them when they finish their current builds (or = get stuck). >=20 > Thanks for chasing this down. FYI: As stands, only main has the update. The MFC will not happen for about a week. ampere1 and ampere3 should probably wait to upate until after the MFC since they do not build main-armv7-* . Note: The fix is a world change, not a kernel change. So it is the jail's world that matters. I'm not sure if any existing releng/13.*/ or releng/14.*/ will get an update for this. stable/13/ and stable/14/ are likely to. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jul 26 23:44:13 2024 X-Original-To: freebsd-current@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 4WW4960Q3dz5Rb6S for ; Fri, 26 Jul 2024 23:44:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WW4955lq4z41hg for ; Fri, 26 Jul 2024 23:44:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2cb81c0ecb4so1004844a91.0 for ; Fri, 26 Jul 2024 16:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1722037464; x=1722642264; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TRrdqoTZVyVV33KteZeGTJufcVpFaaJ5wYCoSrm6dqk=; b=Lag8qXPWto8BrPilCHFpn4WxwKKwPPomAJBfPMXU+jIt6o3aBMtpS4L4bcGs5nGL/g PLrIE5XltD5ozQEn6i6F8iKHKcbuhl21btQXJyCc4y87ppcq7TJKmwvcWqz5vKvOzR9U 5+Q7vjgB+jRCLNE3w/eYoaGJtgQ6ozzKwrpVwQtcylL4rKX5bw7GpwGKqXCPprXw4V+q IpExvh3qAE0wIoPjTu9z1O3gPCrrLEROsQ/nFSOokCWmuXKtCQ+fHsGSuracGFPVIKXA jc59MZSynhvXl9dqKbnoLfur+/T20E3G/JIgIiyHTKnGj/IbMjclcfPqWwagz6F8Ldja LLwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722037464; x=1722642264; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TRrdqoTZVyVV33KteZeGTJufcVpFaaJ5wYCoSrm6dqk=; b=ojM0gH2ZWQ7niJ3/OEcdgCWfxI62HLIkp+jWl/dHUxZKYb8H+yJN5CW2gCIJFQ8grE vpxF69HSX26GOaJYxKLMrFUbkI9JSMv7wmTNB9lWJb9wd21nHzT66lj14JSmCiDwcTbl tV17p0rYoKh/bfg8e+knQmltzS85BzJJ6EHl2Jk6zq6pUB8TT6GT/aUd03clVPNYpcGz 7Urkxz/cS+l5dwlHoFig0EEEQc7c0vFHueFdbojqDZJ59ouyDFsSy8EyoVIONpboH24a tC8uWMUVR8T4ZAypNmeXwFjNG8fDGD8iWthW9L8lFJdJmqSflE7+wPdPCec+xu8MhGO+ aeDg== X-Forwarded-Encrypted: i=1; AJvYcCXJixxfnFdwWfO9B6z8qyGFa4f/15ixKcYQT9AsxZLXhAIWb6MjLPjeqtQ99ZRn7G6cJU5oSQxHN7BbBBelVQRGYNy10pHWg5Auq+w= X-Gm-Message-State: AOJu0YzX8/mCPuDgF4qmlAqcMkwFTf3QGAzbVfkZSwnujV6TJpnegX0Q x2YA46yRF0oR/8nw9iHm+lYSOEyiu+3FT9DFeyO0QMoeYQCIvb8MDUV6CIWsyLUY45+hAvvLOAU KmqpjsMlXzabQ0SMCxuazBbQOClMzPCLh4dlUng== X-Google-Smtp-Source: AGHT+IG5sH53XMszp2sgZ/FJmwRfnybpg22ororQ8dJf4OsWhq4TqzXb87l6pGLt6abXivbNKVByS8tmeCVZ3op2nl8= X-Received: by 2002:a17:90b:4a81:b0:2c3:34f4:5154 with SMTP id 98e67ed59e1d1-2cf7ce8754bmr1794598a91.1.1722037464395; Fri, 26 Jul 2024 16:44:24 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> In-Reply-To: From: Warner Losh Date: Fri, 26 Jul 2024 17:44:13 -0600 Message-ID: Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 To: Mark Millard Cc: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD Content-Type: multipart/alternative; boundary="0000000000005b0db1061e2f1772" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WW4955lq4z41hg --0000000000005b0db1061e2f1772 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 26, 2024, 5:37=E2=80=AFPM Mark Millard wrot= e: > On Jul 26, 2024, at 07:56, Philip Paeps wrote: > > > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: > >> So, it looks like updating the kernel and world on ampere2 and > >> enabling builds of main-armv7-default should no longer have > >> main-armv7-default hang-up during graphviz installation (or > >> analogous contexts). Hopefully, that means that > >> main-armv7-default builds will then complete and be distributed. > > > > I've set the stop-builds flag on the ampere machines. I'll kick off a > cluster build and upgrade them when they finish their current builds (or > get stuck). > > > > Thanks for chasing this down. > > FYI: As stands, only main has the update. The MFC will not happen > for about a week. ampere1 and ampere3 should probably wait to > upate until after the MFC since they do not build main-armv7-* . > > Note: The fix is a world change, not a kernel change. So it is > the jail's world that matters. > > I'm not sure if any existing releng/13.*/ or releng/14.*/ will > get an update for this. stable/13/ and stable/14/ are likely to. > I wonder if a rebuilt system will make it through an armv7 bsd-user poudriere bulk.... Warner =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --0000000000005b0db1061e2f1772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 26, 2024, 5:37=E2=80=AFPM Mark Millard <= ;marklmi@yahoo.com> wrote:
<= /div>
On Jul 26, 2024, at 07:56, Philip Paeps= <philip@freebsd.org> wrote:

> On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> So, it looks like updating the kernel and world on ampere2 and
>> enabling builds of main-armv7-default should no longer have
>> main-armv7-default hang-up during graphviz installation (or
>> analogous contexts). Hopefully, that means that
>> main-armv7-default builds will then complete and be distributed. >
> I've set the stop-builds flag on the ampere machines.=C2=A0 I'= ll kick off a cluster build and upgrade them when they finish their current= builds (or get stuck).
>
> Thanks for chasing this down.

FYI: As stands, only main has the update. The MFC will not happen
for about a week. ampere1 and ampere3 should probably wait to
upate until after the MFC since they do not build main-armv7-* .

Note: The fix is a world change, not a kernel change. So it is
the jail's world that matters.

I'm not sure if any existing releng/13.*/ or releng/14.*/ will
get an update for this. stable/13/ and stable/14/ are likely to.

I wonder if= a rebuilt system will make it through an armv7 bsd-user poudriere bulk....=

Warner


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--0000000000005b0db1061e2f1772-- From nobody Sat Jul 27 00:14:31 2024 X-Original-To: freebsd-current@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 4WW4r76S9Pz5Rddp for ; Sat, 27 Jul 2024 00:14:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WW4r72YbYz45H4 for ; Sat, 27 Jul 2024 00:14:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722039285; bh=U28IbIZzFO413VIXC386atriOoKY0ktzgudp1Spwfaw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dIA3TGGNzPlCLBocTahkCboXtD03Ln8yr5LUOLs92kfIkJszjqM6ACfY2V4CgVBBY5oKbjuQCU3b4rS3HOzaiFcynpyyAgsGQzGBf2hsyUJFO6ii7Hme01jKHCrTqflZTGacXBdf2llz45oRNw43yeWrOLzuARhpPzS31Mf6eY1ZNUI6VoE1F0+j8DocoaF8jyqu+95G4ok7aKI1dDzU3VNwiQGy+EkOyvGS/rjBDku91EzwPo6+7Rm/a8NsQ/nVbcge/LO0bvtAuxHFLRx+i+sJDaWc3OlVBHmQPLxege7v6zIMiTK0VUucAEkXgIAkzi7qZj7+CXXSzLhuCdGBIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722039285; bh=pm3kYsonIlOMGNH228MMUsR06If12qWUo2rZEv+ls8c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=A/4vbIYoiWXa/lZTDL3HdbWNIZmq8MLamRYJzaYcYD5msbugZGRd+ptbqubZ5A/KLCcCM+7rRt2tJdNnMRv9FXnUc77S5kUf3e4fgGclUpdvE87/cFpmfBWyLCrBhqxgXjg8pJyRyCR3VhLk0mVXbloHkUoHJzK/gKnge7Vb0d3z6iKaCZvt4as6hIrJLOkcMjrsnAU6msGLSSXTKEFQctNq5mmI+qh0MzMfadyVTXLR0TgyGgCA0btenulvMeBO24dh7aAqjgU/EJEfML6WrwEEF/Bolu1cDs7QlQsbrsMjhuKPymSv7wqGoW1klyfo554Xs7WZFpuQI+G+xzbpHQ== X-YMail-OSG: rOG0ouAVM1meo2UfNiFdCpBgmPAud9QqafVLyLOjBuGPNRHomjHO7MTIupd6PvD kJ6VZX2ur7kMxhFY0c_.GqRkv_diEDyjH_hYi7UUQkJ9ZMhd9pjIEa46jHMkeevolikz4ryWK9vE yMVFXz2xANaFFCmHC4fuYkABuvROuNMQ7bkpd3.0GNyvxnGuvjyCXFqnWTEnrC7Sp0oG0EWa64KG wCoiyy5fOA8g6rgeGeJIjtz2in3OgQqaPHmBYh1lqreuuVcW2Q.DQOVgiGiiolBOpB7NZirOFdWs 5OUiBAFgweh4NQKybMkoEZU6gkLgUC037AAxblBF3vKNdCULNSlOnqq.ZF8Gc9be9Rm1pt8Ms8mS NtNhec7BzSttvUX1H_tcHP9vkDd4j_BlP3WR7s1QwyHx25qSILId4Q.D5FMrtNyKZwDO94jCXc3b rSLW0hRtP9gy_vpN_E0al09luHCHw1VhLx2lyIGfW9iye2GFZYf6SFRe9IiG_uyb.dCZharKF_iu VDhmQmNrd2pdL2V3Fn46l_3r5p2Ph4CYJxP5diLbIp6ywyPRw.g.DlGwL12ja723mupf4o4csYah vq7eXOvankvVV60poo0miJclRP66jY_8F8jj5F4bGO.d5S9z5UJWCk2iBmj3bMfiSp1RdM83wgo2 ozLMzNeWVZEI9HWb0fi6HtRvPSmNGeS28gzwHL.hl.KrvUAcZP1hUn1JKXt0GHpmVUAVJHgsvxU. 5bC8_EOkRFLytJY2szT09rGvWkJS0RYdXaXJECfOZx8hggs4wD5ujosLUOf.51g35wzmeDACjnd4 5M4fCJtYSm3_nX29WlHZ6uHik7Lml52RoM4RYmHcU8KySehfHJa.ymUYkvixKcLHCQ2CkVQZ79NN OHKdWSQrE7_cbh56HhjYn6UyZv4Pp5gI68AAFMFjy9fJQng2950EKkHd2Jr.yBbDYy4sdvpaOyps ZwIqPkkpzvPglvF9KTyZ8UnyJh8g9zMwsbgYmAkXYOgCMvmbZ.N9Pr21eWUInezRlIcm.PZDCXsY la7rIIVbQoYk5F6fZh5D7hjqSviiIwz8yK4EHx6Xy1T9kV_AYoRPv0sqgBRe.VfzI6EuW2UOSVDF xP742NqPZAkAvOkGFjiTzMDtdNZJcEqnQWI9ZjqnUku6jgLJqcyI0x1TbAHAKS01EViw914LD9JJ 2QmtR.IRYdayP0S6DlucwqVoT6rUcd8f067sYhGyJqHNN5ljjDX0LeQpyyVVTBvF5cG_vBW38r7v W6bM6n9qj3hzl5CzzXizREgSt7096GOqBKJFNQFcGCbZ9djbBLXRJLeKW0luLzpHEIywNPZJHJ7W FOFhNBinciPft7Odcb7vxPG0om56g5S_3nACaokAerwfswqVOAxzVwKHCcMvlV3JQS7kfjsfxr2W lv.GTFLdhgjD2Spt9hVxfa4aGAAlgv1Vuc..BX1guQBX6orPLLughFM_a25zIDkunUObVsdIkYtu UERg_xHUV26NLRCimcjJ9YWPMGIBMOM1KYSqFLp00D1Y1vLWvS1xEvdQmvkjfKSwrAQ82p_uhKUU DbckLUpRj1Fo0Y6xfbAObCudwDKFhOsWcj9EoJRyJnIDD0NJdSJClDxF_o4OZtiGbeZGFsd4StB5 lURsiP8NeQDRqg0fXbDrzOzr9.msQ2MeLUNiYs.1OnsdYmmkTQih.usxakF9ycl135dPec1BiTn. C6rJ_6KABuFeFXVdjGBfka1N5GLMJ7O9EKdAwtbDhAjIGhac20QmrMaa9H4gSFd3lk3CbTMaRT8u GXMNeJyxkHuPo74N2qF.NHjj.dEFH3FKXF_UNNRvFz_P_GIbyxGxkvaR54BDrVVQjM3mJZfo7Csd AXfHTGsRUDm5bSmrSIrfIsfo6K3CU8lWEJNsErvRIoFU_V_m3G4Ja.wBW3pdN2T7_V4vQniiAE3T 6DeQyeeJQMZQ4MfL3dlU6IFw407lRFv6m_qMjP_fqLomXdSrpiJk90tolKUZMKMLh6l.oeYZKxlT YQHojJj3snIX4Okk7ahnN_VRhAQpkeGGwvYd2Ay_ydK7M0VjiSYG0LJ4KsJQ4W7AH6R3WW.oCcwH gyOr4HadcGyeQp8saEn3U.qarjBOUURzUBN88bU36xyG1h3Q37KL1d4kzvZ6yotPxHxTLU7kebWA q_.0ztvME83vD7qSsvIVRtNV4g4Qvbgdrs2V9JDD7.fMCLq8O0rhETwN3PZnukAoa1nnhDYVpA6d xf4VsrEVNvFtgM6hxDXn54WU49ZNYiPq8cAJg2O21iAa8PD86AsFnQOsscvox_MOuSUck0zm5uUF 2DkCA X-Sonic-MF: X-Sonic-ID: eec0a9f1-6408-4533-af8f-b2ddb7991b3c Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 00:14:45 +0000 Received: by hermes--production-gq1-799bb7c8cf-l6wmw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b26f48a6143d5ecb081275db1ed9733; Sat, 27 Jul 2024 00:14:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: Date: Fri, 26 Jul 2024 17:14:31 -0700 Cc: Philip Paeps , FreeBSD ARM List , FreeBSD Mailing List , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <68C09CB4-92AF-4369-A1E0-A6EADF092449@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <561E4947-6D56-4431-AE08-C843FF232066@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WW4r72YbYz45H4 On Jul 26, 2024, at 16:44, Warner Losh wrote: > On Fri, Jul 26, 2024, 5:37=E2=80=AFPM Mark Millard = wrote: >> On Jul 26, 2024, at 07:56, Philip Paeps wrote: >>=20 >> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: >> >> So, it looks like updating the kernel and world on ampere2 and >> >> enabling builds of main-armv7-default should no longer have >> >> main-armv7-default hang-up during graphviz installation (or >> >> analogous contexts). Hopefully, that means that >> >> main-armv7-default builds will then complete and be distributed. >> >=20 >> > I've set the stop-builds flag on the ampere machines. I'll kick = off a cluster build and upgrade them when they finish their current = builds (or get stuck). >> >=20 >> > Thanks for chasing this down. >>=20 >> FYI: As stands, only main has the update. The MFC will not happen >> for about a week. ampere1 and ampere3 should probably wait to >> upate until after the MFC since they do not build main-armv7-* . >>=20 >> Note: The fix is a world change, not a kernel change. So it is >> the jail's world that matters. >>=20 >> I'm not sure if any existing releng/13.*/ or releng/14.*/ will >> get an update for this. stable/13/ and stable/14/ are likely to. >=20 > I wonder if a rebuilt system will make it through an armv7 bsd-user = poudriere bulk.... I assume that this wording is about having amd64 with qemu attempting bulk -a for building amv7 packages, not about having aarch64 (without qemu) bulk -a with armv7 jails do so (which are now being done). Have I got that right? (It appears that main used to have some prior use of the __aeabi_* in question before the failure point, thereby historically avoiding the recursive lock use deadlock. 13 and 14 are still operational for bulk -a on aarch64 for armv7 jails --but are subject to breakage, just like main was.) If spreading the package-building load around more to amd64 contexts was a goal, and if amd64 with qemu worked well for aarch64, one could imagine having some of the aarch64 package builds on amd64 but all the armv7 ones on the ampere*'s. This may be more likely to work better overall than amd64 with qemu ever handling a 32-bit context well (armv7 here). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jul 27 04:20:45 2024 X-Original-To: freebsd-current@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 4WWBJK1RG9z5RHVH for ; Sat, 27 Jul 2024 04:21:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWBJH6lNfz4VcS for ; Sat, 27 Jul 2024 04:21:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hJ5gLexm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722054061; bh=Q+AWwuV4WL3zKiu4XP6WbGGeIER+J/cl/iIspA2irgU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hJ5gLexmPAJucGNg7QmMBnb8oPmBJ27PfYu1JD70YlYalmIlss8ueyt76loSILWeVpmWZsrzU7Hi0nr87SVo9j82LAJWw//vNBtjeRydfqjTWcmPY4hebmvReynJ9Pv4OSFG4KvCg1m59BQWmym9yM3f1Q8ya8ybmL36NWRLRbc8UZSCBmPh56+uDAlgfFmDgKcx0kMag6NyPwIxXcC5CWgzsYAIvBSVdxMwZZAwo5dzlBZivHnV6ooBChqHE/3eMJVs85x9Q0lQhoMkHDCV//fXHfJL5IGFHG16DGJIUR2yq6FQof0xdjWWrM3RhNQMN9yg63T1LjMXP37tLE7Gmw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722054061; bh=Rv2t41zsZKYDeGQX0odzrsMdd+DOfCtgdV7AcprNzFT=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=l+mkuZpPUzo/RCiKQAGKG89bk+QwPKWsCwrVey/nDSUhrYgPnFCiAZn5nCN25mLfTjRxrGCctJnZi3URsMOTzzFNE55aMXs1Gx8XnaZg70b029FjS1jyu3icoRLQHlR8ftkjaPViHTAWiAMChpB56bNl9cM4C/mNc6zWDneJg0JjnqIo7De+lSyJDQLiiqSKY6ERVJ/WB3vaPi4n5Kgagd6V8e6FBWo5+A1v+Ol3abjtNHeuKBvbSIEZeaRHqBUZBQmj004iTQkzZZQ8Bv8KWws5h2VLFIle00D+s3IBPiOxgW+V+n9a2hQMd1T8KMvkjId2YeL31+z+pcLvufRHSQ== X-YMail-OSG: F339B.cVM1mLZMlV9O5J88sIYj8rsF0MKgQnPNLj4hTtKE.B4ytObkrFoDtKjFp S5YOqgnTZ_XcBpnJU9jeyWkUlNpwvedD3SJcidjBj_1WL66YjB4.saFHxK5DJQZvYCJQO4B84ir. VsVJlLLyqd2BIpG2DCRFuL_Zl7sUFuk091GEdHWnu1bW8UiePcn8N.Is_UOTh7AYv8JcgI0AtSGr T_JlrGASujkP46cyRA6TqzSrwpnQyULuSynBIF07fa8Z5NOca6tPQefWpamoKPYlVL1xRFE96yL8 l1hZdPWyuQkbX8zDWz4QX.Slsx.tpM9l5kcu1Sp1jeYnD6swjkN6.altTZ.jI.ndkVUv9bmR.THS KChI3S6tvCc0K02DVADUsYKArNtllelUDijJ0WgWPN3.VLUhJea08c7NP5IRVv9VvUr5QEZzQsEg VSHa7bylQ11JbIJQq8IQIy3becJSRwA4lnvYvpqBJRxb3M08bX9b9.WoSlShrVtnzgeesslKE0aS TWg.rOyDpYgvyDW_lTahmLQdL2OpiBGKto.5aGXFf19JC2VgpgbfBqJafcv4dcsavkSe25npeWi4 kCbkmPc3WG.nMor4aXxi254VbYAEPe3lTdI7ZXzzSe_bhBurcPx5OLw9bSXnDB.3WP1oD4NGLYj4 z.32GXqErKYB6Sm0Ow_YYYQvKNGx2ob0DSGRG9IdHXO3wCS0xzJbFuU8zjQ6gLjnvVWmi_RIVG9O Ej8GU5RuvjTETg0pI_tJVAoylPMDAw16Lfo2MIXTesoyKpPLtkuEIlD9Skd_8sjJ6T_mbKnpXnGP nsfywG.1n2ygK5jIFfmFn_Sr5Enu8Xz6.8fQVHReV00u_oIFE2LxnBOOqgD8z5.hMv3TEoelHJiX 8JPvWsO2ImMn8E1bUNYByK9NGSGxGLfE9hmp5s00nVJfpApSfEc_OaVQzmrB8FL_93IYnL_CvRD5 .myAM5JJEX2gx2oST4v7iMFIX6QhbqrcFZWRRLi.RTFoFczeZDG5fIP9xZWF2i0UnI4lOTOtTY9z 3Gy4Y4EuTF0Lv5Mb0xiTikqay7t7MZc_AOWB4XJbk_OAUSUOPidRxAdsZqRuWgJccgNSXqEGvT6u sdK43WWADiwT_5eSm0fX_aJbK2FVFgwXzJYYHrlfXpQF0UlcJu.d7AUxmKcIWi7V56uuh3hbzYTK zz0Aj0bYJ5q7Iiplza56uHlMlTtFQMpGgkPCwJJpu_h.CDfCJV0O6k7.6XYYR5pwoulnCzSeRNES yNmV66Al9sxfGw1yopWnmc.rmhJgkvFF.p9TM2o3FWltSSsjGA9vcjny8g.lmZz73HmJyhmIb556 G6ZbvgOdsiipCty3aNfPT54y1H1Yb4_TF4mLChgZa_yii71AL7ZjiL9vAX.WkAFwtw6Iwo0sZTcI rhv9WxGW7UtYjoCcmwEwhC3JkunJCSd9919t3KNb4MfG3d1cLh1cHqCJnjmje74SSbHyoYP40VK8 k1KnI_evmGL_4vwczTsNH352azhuRc0JNGxl2L4PznW3NDM8iLBqfpMPmpjBBPH2tkKnToDgaODr A3NwAymxRVPwKlChqZcNgpZnWOYQLKAnrV.SL7SbXhQdKsuD0LGpPfJuhnmDw4pBOog5Vf7IA8.8 qI6in_K5zup3sA.Av3B2kGbLgbFhz7fD0O3_PKUprqqTOT78Bc8ZRi3I4tfaC_dAnzhPDCGpuq3t IPJml6ViSA__qrspgAykQfFfzmodfyv4CuH1b_j2RJUblSpDSYKVFCF1xmY_tJeJOZZznGEOqQZ_ yOCqL2VLKNHExrDCArEadq47aMv1un9l4FBe0jIBHWyPAjJpDc1HCtYkzzyMP6WKIqX4ewMjQghE dseXsimjl_fzYOd4a39Pzx.qdPXkWcwggC1aN3iOobzPVCmgNBKsJEAsy.x62VSQnVzhW2ebEm1z kHrEbHyCfqYo49cUWo9LHPvLC_HUrKun.qkaOddbPcczs9hstwAAj4r4e0Z6jZrqB4iEgk1.Q9OT SG1vcKWxyky5qKhz9B.1JHajPmPNRoEwWndGwcn4T8QVtcrqfPJ8cwMgiwV4pO4SoCpAqvLAQfr3 hGp3DbjF0l9ccFAlz4s4AqvK9nITQR3.8ZdNrHaUpECwd5TbNbWq0rIFTi9_uAap3Hze8mykjXTf 0o2BCIkusTNy1aKU_bXlEnmqDnNKt8GT0Eir3CNwavygmaBccu6lxHErJzzmgD0poYmCemjlb4l8 04DwHQCqQc6mrLy7YhCG1z59k37MM07y.zcCXubnSn74bTbAmkkjB5Yrj79zQ6ABdXz_hS0pG02f Bww-- X-Sonic-MF: X-Sonic-ID: e87e8892-2b10-4936-b94d-93005d0c2833 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 04:21:01 +0000 Received: by hermes--production-gq1-799bb7c8cf-mlhxz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8f1f9e752d62df4942add574c97ffc40; Sat, 27 Jul 2024 04:20:56 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: armv7 chroot on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system Message-Id: <87D92513-97C9-4CFC-8A11-9819375FACAF@yahoo.com> Date: Fri, 26 Jul 2024 21:20:45 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3774.600.62) References: <87D92513-97C9-4CFC-8A11-9819375FACAF.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4WWBJH6lNfz4VcS The original mount was: mount -onoatime 192.168.1.140:/ /mnt For reference: 192.168.1.140:/ on = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt (nfs, noatime) gdb reports: Reading symbols from /sbin/umount... Reading symbols from /usr/lib/debug//sbin/umount.debug... [New LWP 100137] Core was generated by `umount /mnt'. Program terminated with signal SIGSYS, Bad system call. Sent by kernel. #0 nfssvc () at nfssvc.S:4 warning: 4 nfssvc.S: No such file or directory (gdb) bt #0 nfssvc () at nfssvc.S:4 #1 0x00021be8 in umountfs (sfs=3Dsfs@entry=3D0xffffce90) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:396 #2 0x00022400 in checkname (mntname=3D0xffffddfb "/mnt", = typelist=3Dtypelist@entry=3D0x0) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:327 #3 0x000218a4 in main (argc=3D, argv=3D) = at /home/pkgbuild/worktrees/main/sbin/umount/umount.c:195 truss's output ends with: . . . = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537321472 (0x2006e000) statfs("/mnt",{ = fstypename=3Dnfs,mntonname=3D/usr/obj/DESTDIRs/main-armv7-chroot-ports-off= icial/mnt,mntfromname=3D192.168.1.140:/,fsid=3D18ff003a3a000000 }) =3D 0 = (0x0) fstatat(AT_FDCWD,"/mnt",{ mode=3Ddrwxr-xr-x = ,inode=3D2,size=3D1536,blksize=3D4096 },0x0) =3D 0 (0x0) fstatat(AT_FDCWD,"/mnt/..",{ mode=3Ddrwxr-xr-x = ,inode=3D73557804,size=3D512,blksize=3D32768 },0x0) =3D 0 (0x0) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 537219072 (0x20055000) = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537341952 (0x20073000) nfssvc() ERR#78 'Function not implemented' SIGNAL 12 (SIGSYS) code=3DSI_KERNEL process killed, signal =3D 12 (core dumped) For reference: if (nfssvc(NFSSVC_DUMPMNTOPTS, &dumpmntopts) >=3D 0) { armv7 chroot: # uname -apKU FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021 # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru FreeBSD-.snap20240726110821 aarch64 host: # uname -apKU FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021 # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru FreeBSD-.snap20240726112037 After exiting the chroot, the aarch64 environment did the unmount /mnt = just fine. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jul 27 04:58:52 2024 X-Original-To: freebsd-current@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 4WWC8G3ZfPz5RM4X for ; Sat, 27 Jul 2024 04:59:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWC8F2f4lz4Z6q for ; Sat, 27 Jul 2024 04:59:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PGXdwqTz; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722056347; bh=DbJMWjGJfCUA2fYDBct/OFGhkG19s31T1NWocPM0Jp0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=PGXdwqTzm4ckWLSMJb5Ttt9VUbfS1zPybrzWDP5o7l59wdX0yZCTujLWDLP4utfNFlobI8V4P1FhaujiaTdZbnLSaFKQ13lyVp+BQlcfaSdt6DCpC3lYaaFGTkonFiBU1qwRTxEkHMBo8I/r6wl9D+YE4eOK7XlpyByH0P0wuChEPhjcoUwk+4YlHoVxIKVjHmFNjWKuL4ZiW8YdqXdVfkq7aiA/QynrG63SsIBj7azKfSiMHIk6IZyhTb0QRHhe7jY1Vu2c1zLvRRkgGfxRA12TM6Pc6axPfd0+KFTNxy79gE++RjVKP5HLtCK6wGqfrjTFPY9iZJ85D+opUSbViQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722056347; bh=kAijMb3ojDycdQopt++HWCL2v+bvi1/P+shVs17h8gt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=A/IkxoAq1NL9jS0/Sq3bT2LJJEN+53bmPnjblfjpLKv0zK1xMTnGCJX//5C4EpqfAWhs2Na8jtDHkFkO4evvKEMLrBVYjOhHmagwChQOxBf9WpfpEbW1AdeeKWCLG6E9b2c/p0DhSDqAiSxjDAyzOG+ktSmHIw3Ty6XVESxKF74Zg3bjXSWzilPVDWRKk2jwAYMTkgTu98LQ4wTpVy0KQ30taI0bAN+hX9I9T0g/1J7+ox4oyEDNKlfJmRcZLWqyJ3PWG0r+FCS2mf8+58caG8xSBW930EtPAcJaUBJAsJb0LcwMsfRcrIdzKQOWhxEKzmMZ4/mu95ikNRYgVCTguQ== X-YMail-OSG: 7Yt3PdMVM1mm08Fkys9xtXdfy0sLbNd3Ljfi.br1hSyt5KQywnahEa9H0_NVAUs Fo4Zf_.T3tA5ZyaE1MF6NCAQr_yjR7.EjuKTLlDx7P.k0yzQYJcNIFZHavlONpnh2KZ_kQAlJxus BhAGsmlj87Pph1BRLtUk5sfJlSJL66TWXabESZvzuuiyU3ANJij9Bzlt4T7FKkdExkfCZ64if3.u KDvhua.OOhxFyLc9iTmkr_NIwXbMrs1smO83wUSN6XtQjJ3Mdfr3gkw3snFQqtIPEd9Jglh.tUpQ tfEOQsZKfMz3jbnYg03Oq6CiB6IOdSWG8ZRsYqU0npzBuodHIRxWIRhWglmhnf2olKCCJFhaBeeF puBIhf7.vY9zEQPueakEkGAuJPrb3tQOw2ByNSrMdipSI7sMB76c5pFF47Z_CJCoyM3RoXDVe8j2 nNb94pb37bd3xM_o_zmJIvJ260lq4jgxMxwJdISfPIY09vSBMiAvnozNdsHnJHlCvxRi0tL4eX6R a00preKWNDJCn4hqXVuMcxAkLI57hvl.KBGoNF8k_pHK.b43bk_DAqsxpbadIHFo1xABgXpmZtgP 9yX4CFSxSP06dt3qo7X7FGntZyKdPWZSGXWBSuxoboHp_qSd4slxJniREWIY67j04M5DlCJL2uH_ Md3zIA31HtjbLYjSOJrmDwso46aNEyYsG7kjz3wo24Ga.iEQSuYJowKcIpXjFWmG3wRXJ.TodesJ gDPrBKGiSXA_CYqyb5srUzDGv7.DDTSpdpMLCy3pBbeM50340T6YKHN32Iclkgb7w2PuEnunt1J7 sy05GP1Mkd357DVrDonIFSo56tMpo23uCEg_T31sk_l7YvboH13YtzZjSQ.RVnauBoYJhSkqCl6k vtxv7fVcWXYzVZ.ZAxt7lH2u_NkF9v8H632BamoAsI4XSUEW2aFc1_zQNh6iQLr1oiWHRlHQRocM ngxrQ1MV2MRQazqtIkBG9SOTkv5CkJa2JykPvWmsYMiCoJfVbRlRP28o01eomgI5GkyHVLmAxFei pZ.bf1XRZ8BOoBiBAIuwWcXPL0p.ccANFehP2fWi499Nm__0SWSqCcOepdLaEHLSQcbhP.Va6lJ0 EMacZVDwVah7gEbqjMh_qyDYniMuspRGHmbgMIl0ZFyD1PCGf4Uo49M31M2mjkgKItaT._jCYkwv bADJkVfRgG2Ciu2OcDZW31Y_0NVn03dzw4NGgjAyMZ96ojQJpE246PPlCG57hTvSW61kMYziqjHR 9V5QcsyGanOnyqEvGHUMnwzqCybME_2FZyNVz_FqVN_kFAqmIgBZvFJdZZmhGmZZuBwFKwfDtxru 39MDQi5RijuqSzM5wk6eKRFgl4wP2dewQf1OGojtwEPAb1Q49snX03JK4hoLQ6LDivC03pAJ8Ns9 2QIjhQzZEpFC9i5oHiCqEk74qzWNoqb8KHaTFvpWYKiEPhrUqI17LDh2QanVnvchpkErj02qSAIO IdpEzU3Rk1i7p_W9dXRQKwV.VfDAF8yuyHz5aeMMGj4ebMV8x8aqgefmdLX0tRPGbGa2_vT4dpRR XZJT17Adcu6L9xeDQ9OEsQU3xB7txDx5_L75SLV3GbIpUvZv.6AaMU31Wqq3_GOWAYZfZi90Ksct dPB9uWXJWKIaR8Cq8XdkiKHwzPcKI5FJQ29q77nGTKLyzCpkvTC_laAqPo6kNq6mBZBF_idxoOtp m_V8EanIxUdnKIEFc2AS_BezEfqmx0hWeJc1KlMKBipp44I4mALKF_8iOsCWc5pHYppKb7jop5zR R_E2LuqUD8YpthBeSTsW98bcOdi0fiJ9SH5Ko9R.4tjxTUW8HP3ghNoJ4CXUQS4SM94oVOYz47pj qyHZrzb.aE90y0xThvV3b1FGZhSGK3KlKl3obV45dL7CMrylPRv98dHBxVYLK.foLg4Jul972VTY oMiv45REITv.RtZ1ZDdLhsydBCI_EcyCgD72QaiXeRFWh3eIq_1TYxilv_UTblk4UB9yvk2fE3jB WOjW6HGiTLEQK4XONYcxfEOj1_E1cyEAq6yaUs8dC6cRkiZcb1_ByRvPgzdKEuPnhctYEBGSUYhZ PNtBi9MzMIZCohx8woDCXPne_y6bvv7BkEogGrcuyrpcx_var1nRAsv0xLvfX2AyiWQfjycd44PD cQcsGbcnlgW1ILUkBWEZz6Jhap7PBQUcJoPKrzNIkRt.WnPyiXmNewBQS4.fWiOJdNxmN1Ggvg32 qtY_T_FM6DK9X9aT.QeB7G9IbZTjpYx27VEaQqh_UVxVJUZtS1zOtfPiaoKZBEY.KTOBJ0gxg4.4 z5A-- X-Sonic-MF: X-Sonic-ID: 689c3d76-c41f-410c-aaa2-561833572e8c Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 04:59:07 +0000 Received: by hermes--production-gq1-799bb7c8cf-dkgg4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 600a5b9332022d8375e2a8327fe714ad; Sat, 27 Jul 2024 04:59:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7 chroot [and lib32] on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system Date: Fri, 26 Jul 2024 21:58:52 -0700 References: <87D92513-97C9-4CFC-8A11-9819375FACAF@yahoo.com> To: FreeBSD ARM List , Current FreeBSD In-Reply-To: <87D92513-97C9-4CFC-8A11-9819375FACAF@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4WWC8F2f4lz4Z6q On Jul 26, 2024, at 21:20, Mark Millard wrote: > The original mount was: >=20 > mount -onoatime 192.168.1.140:/ /mnt >=20 > For reference: > 192.168.1.140:/ on = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt (nfs, noatime) >=20 > gdb reports: >=20 > Reading symbols from /sbin/umount... > Reading symbols from /usr/lib/debug//sbin/umount.debug... > [New LWP 100137] > Core was generated by `umount /mnt'. > Program terminated with signal SIGSYS, Bad system call. > Sent by kernel. > #0 nfssvc () at nfssvc.S:4 >=20 > warning: 4 nfssvc.S: No such file or directory > (gdb) bt > #0 nfssvc () at nfssvc.S:4 > #1 0x00021be8 in umountfs (sfs=3Dsfs@entry=3D0xffffce90) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:396 > #2 0x00022400 in checkname (mntname=3D0xffffddfb "/mnt", = typelist=3Dtypelist@entry=3D0x0) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:327 > #3 0x000218a4 in main (argc=3D, argv=3D) at /home/pkgbuild/worktrees/main/sbin/umount/umount.c:195 >=20 >=20 > truss's output ends with: >=20 > . . . > = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537321472 (0x2006e000) > statfs("/mnt",{ = fstypename=3Dnfs,mntonname=3D/usr/obj/DESTDIRs/main-armv7-chroot-ports-off= icial/mnt,mntfromname=3D192.168.1.140:/,fsid=3D18ff003a3a000000 }) =3D 0 = (0x0) > fstatat(AT_FDCWD,"/mnt",{ mode=3Ddrwxr-xr-x = ,inode=3D2,size=3D1536,blksize=3D4096 },0x0) =3D 0 (0x0) > fstatat(AT_FDCWD,"/mnt/..",{ mode=3Ddrwxr-xr-x = ,inode=3D73557804,size=3D512,blksize=3D32768 },0x0) =3D 0 (0x0) > = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 537219072 (0x20055000) > = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537341952 (0x20073000) > nfssvc() ERR#78 'Function not implemented' > SIGNAL 12 (SIGSYS) code=3DSI_KERNEL > process killed, signal =3D 12 (core dumped) >=20 >=20 > For reference: >=20 > if (nfssvc(NFSSVC_DUMPMNTOPTS, &dumpmntopts) >=3D 0) { >=20 >=20 > armv7 chroot: >=20 > # uname -apKU > FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021 >=20 > # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru > FreeBSD-.snap20240726110821 >=20 >=20 > aarch64 host: >=20 > # uname -apKU > FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021 >=20 > # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru > FreeBSD-.snap20240726112037 >=20 >=20 > After exiting the chroot, the aarch64 environment did the unmount /mnt = just fine. I set up a context where aarch64 ends up seeing (after chroot exit): # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/PBaseUFS 1114846 184896 840761 18% / devfs 0 0 0 0% /dev /dev/gpt/PBaseEFI 244 26 218 11% /boot/efi 192.168.1.140:/ 823229 74755 682616 10% = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt I then used the armv7 umount: # /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/sbin/umount = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt Bad system call (core dumped) The truss output for such shows: . . . freebsd32_getfsstat(0x2004e000,11720,MNT_NOWAIT) =3D 4 (0x4) = freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALI= GNED(12),-1,0x0) =3D 537411584 (0x20084000) = freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIG= NED(12),-1,0x0) =3D 537423872 (0x20087000) = freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALI= GNED(12),-1,0x0) =3D 537427968 (0x20088000) #155() ERR#78 'Function not implemented' SIGNAL 12 (SIGSYS) code=3DSI_KERNEL process killed, signal =3D 12 (core dumped) Side note: # more ~/pkgbase-snapshot-list.sh=20 #! /bin/sh ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(-[0-9][0-9]\.snap[^~]*)~[^.]*\.pkg)$@\2*\4@= ' | sort -ru results in the likes of: # ~/pkgbase-snapshot-list.sh FreeBSD-*-15.snap20240726112037 that reads a little better. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jul 27 13:49:49 2024 X-Original-To: freebsd-current@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 4WWQwf26xYz5SGbn for ; Sat, 27 Jul 2024 13:49:54 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWQwd3VVGz4MhC for ; Sat, 27 Jul 2024 13:49:53 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b="UXZiBe/3"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=g0XiKN7f; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.148 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 0A1F4138015E for ; Sat, 27 Jul 2024 09:49:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 27 Jul 2024 09:49:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1722088192; x=1722174592; bh=AT0NMghAtVm/t63tNgWzVK4Gfm5L68Fi jeyp4kL9i0o=; b=UXZiBe/3Ewp2ODOG3XXrGUI3TXq8PDGMWtdjoE1Fs2jVHEAx kLS8NRU+sMFVCOeuC1WYHy8PpxF9iPSTwK5gC7dxv9FtReYCy9X3S4hCtiNQbwZE S+6NO73zAW9MSGrsm6ybm2xcjxG+i0L0/8T5TtxR5SeKlMkAwSUfZov1qRYcRQfy C8KnljJtt5L66195aEW+0Jj/FxaTDHla3vQ9R6clx2rkSnQg/mRhPkIRxhnTuQne DiUynA5vuPyQ9WHMtrEk3VDGu4uV+4dJSLH7m2I6UAonI9rYrZ3h3HVOlcq0X7V3 yD5WjrQwFyDVuxnqY/Ddx37svkBNooDhCyEReQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1722088192; x=1722174592; bh=AT0NMghAtVm/t63tNgWzVK4Gfm5L68Fijey p4kL9i0o=; b=g0XiKN7frdKjQ1xw+TfnTJ/HmS1GRhkc/1EXhgDLWzg+Gqy0Gex T4ThWG+304YCUXDC6wge7DJwq16579j0KTpGXhJNcsFT6GFhGi9EYN5qVRvmWgZC DsssVKBineLl0f2vCV/0HbNXhjA0QrWAuVB8S6It6CL4Z32qvf5ATa3I6mbAmN8w 1PxZXKqa3oOoR398wMFqWyXwuMcTY8kLaOKEvkufW0oIvRigyTwcfDs1o2/Wkd7g +VoZXIRH0hp47RWp1p68v2C+D7nzHnr0ywSvsmR3kwBiMsueM0koXr4HPgtdOSiF LOGribYBpjQOT48EWJm+MHc8Tdu90lVjpfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieejgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehgeffue enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi ugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 27 Jul 2024 09:49:51 -0400 (EDT) Date: Sat, 27 Jul 2024 14:49:49 +0100 From: void To: freebsd-current@freebsd.org Subject: filemon Message-ID: Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.148:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WWQwd3VVGz4MhC Is it better to load filemon as kldload filemon, or to have it set as a device via 'device filemon' in the kernel config file? or to just load it when rebuilding the system? There is man 4 filemon but nothing there to describe usage as .ko or device. System is n271321-9ae91f59c500 on arm64. -- From nobody Sat Jul 27 14:24:46 2024 X-Original-To: freebsd-current@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 4WWRj44BzFz5SKDL for ; Sat, 27 Jul 2024 14:24:56 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWRj43WHHz4QmC; Sat, 27 Jul 2024 14:24:56 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722090296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fSehPZrXtYOhgyDfm2X/n9NuIRivlrzRl4hxvgSaoWQ=; b=srzvVjHgI0a0IT1/Kd6fb9ZWypa0XF20Igd8jZet4sv1rPkd3g44zDJAkMSfqepX7+1Q4P OSD3p4URqcBX0JaXT4aac2+CaAqfGE5k/3O8/EwwEBYxi4s4RPuXjDxUmbqH7gV1/QKuFO TFf6yleIr3q9H91xPzdS69Dl4vhUP3F1VLv8Iq9WcZIph84BILoXCwQxTDPgCL1RmBih1n sTL+NFtseCo9hVNkMtancL4lRVmQVyZFfVxCjTiZs/jfgPANh0HCU745ZDzMtHPAHYsbDi xCnioYtm3J8k8zbGkmH5fkz5QUsd7Q4cORn8pKqOsMkBMscJirPPRkELeOgF0g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722090296; a=rsa-sha256; cv=none; b=RLa8p+8/RbTU3naXePfDMdQ74TYGdgmpsLx0vq6K+j9I8/6xkSbDmkD2uoAZ0mB91kHYDu bmxG8J+KGWrglV7ZpDO86X+X/CuvBYkWS99k2O7VDPcrQ0uB4BUXtwocWTOfggz+1slx6b 4SJzoVTfeii5n5Vr1CETgnC1/Mfe3+XS7qkvu3TM/qgtfO0CSbv3JCZ9WBv/UqPwWYd0MM jsGRPoPRfHBnbBz6Y+FUPX6MkcWrkAQobXtvcE/2F3LIF8l3xfwAzHo5IlOhRdfCtLbwPx Mc3j7+YB/fhOwxOWrfRnTk05sigtVIMito9khTLHiN46NS4y6uY7cdCXPfydMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722090296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fSehPZrXtYOhgyDfm2X/n9NuIRivlrzRl4hxvgSaoWQ=; b=T3fIqC64hUgfvDkK//M0HwgF5cvnztgV76DQttAmDZbDRMWM9zmzETvSwCC8KEJNwF0Ppq mtroIIrH/uSEMO852f0a3JTkXQ6zoioefQgvzKqlTIpORGONejSNDVDBkzDBATXwlpnnr4 pVZzirb19uqq7dSFbZ3TIH/BycaTL0vStcSb2/OBn7ACOBd5s+zEh9fOw4VhWuiQ0GX4yY 1uqbfZ8dFTRiwAJHR6g6RA6XVrW5C7xH+DYr7ng0AVlqHNklwB8aqRNphgZtAKT4C/Bz0R lMTclFkgWAdYtxLjh5UEhtY8GDZNXV+R2XhnJ1EIAjcfLgzVLrVuvGEDi2di+A== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WWRj34tLPz1P5J; Sat, 27 Jul 2024 14:24:55 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: filemon From: Zhenlei Huang In-Reply-To: Date: Sat, 27 Jul 2024 22:24:46 +0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <8E616DF1-8AA6-430D-8E99-E4D676CF0F17@FreeBSD.org> References: To: void X-Mailer: Apple Mail (2.3696.120.41.1.8) > On Jul 27, 2024, at 9:49 PM, void wrote: >=20 > Is it better to load filemon as kldload filemon, or to > have it set as a device via 'device filemon' in the kernel config = file? or to just load it when rebuilding the system? >=20 > There is man 4 filemon but nothing there to describe usage as .ko > or device. System is n271321-9ae91f59c500 on arm64. Some module needs to be statically linked ( aka device FOO ) to serve = its function. Since filemon can be dynamically loaded I guess it ( dynamically loaded = ) has no differences on usage with statically linked one. If it does have, then it should be warned in the man page. >=20 > --=20 >=20 From nobody Sat Jul 27 14:27:19 2024 X-Original-To: freebsd-current@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 4WWRm30TZ9z5SKSr for ; Sat, 27 Jul 2024 14:27:31 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWRm26vwNz4Rnp for ; Sat, 27 Jul 2024 14:27:30 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722090451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8YXZtnT9QKXmOBL4gK86e0MxB1Ha2vUruvEjqfylSBw=; b=Uodz/mzM6gOKVdCiiPv8erkyIuwVpyxnYHm3d6X/HdwGn3fvFaaklXaj7h0jBhCL6AXJso eHZBsQfIoBntAZ+RYFtGzhyChvb6lNRWghqFmtbjq8275XmtMo7Vv6iMIYuYmNFkkMHxqV LkxPq6atrxaaqPlUCn/w3Uwb5Peit2sMp8WeW76JdD7bRmhWpj5/9Z3Aw73vWjPupMK7ai sNHrdhjOc0iGVqtO/Y8qhVBVmiL2XZR73EGCE1QmvzwdVX0eBJe+c7QuOoQRgfnu3RUm7F EWrysvkzs7S+WQud1R14rdOJVLkMsfSkNeuXYr/DONH4Cb1cIiqeL2gfzus+zw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722090451; a=rsa-sha256; cv=none; b=VrOlZiLqMJwGrg9YGI+p+i6oElX3HKWqE0d/CTsIY0ituyQilv9iIqR9TSWUH/PHQQmjvo abYvaMM9k49jEajj8apSK+Q1tWOBVGBdgi+et0Nw3HCx0MSeYdceI3fsZ7VRK6FT52qSIO Rxi7GcIFbTx9IN9qfssDMAOdVjwnFMkG5NiGOERhJ1Dz1STYQIFMVdS7mzkyx2TYI1yTnX qKsXOlFBx55zA2Na7H6cRXDzWxkH6mG4Yl4bhTPdVrjuDloU6phuGceD37Si/3UvQaApTA YwGqx+d3GM8eYChuxt8ITcmfYKJDW0ESybgJCNRNC4JwP9xkEtgrutwbwUfjvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722090451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8YXZtnT9QKXmOBL4gK86e0MxB1Ha2vUruvEjqfylSBw=; b=L6GkrPFnAZaKDjrzZVxCx9TUaP5eyz0h7B12dI+623FtpxwHQVh5ghUDspPKtsYRsAxV4d WukYQg/Go3hfrSFisHGz/4vaM5OpVn0Gfq0YgDKoaQ90KuKu9L4MVsC6UxmUDikVkTkQLO y+JojXD4R8rwjTkeskkZm2PvblsJxtx8nLDK4HlXu92bqTzqvJ15vIzJm6gUVL4wViUyrI /G0jelvbWFghkfEOYls2IeNNsWFXV9Pb2b7stj0nyk8G6Qoubbu6yBm2oMcHFi7hTCD4JL etOA4FUNe0PSc3HMiZMSw53EZ9STyQg/nA7JwFB18v3/LGna6eoWrCUrmdQoCg== Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WWRm26N9cz1Pbm for ; Sat, 27 Jul 2024 14:27:30 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-44fe106616eso8870661cf.1 for ; Sat, 27 Jul 2024 07:27:30 -0700 (PDT) X-Gm-Message-State: AOJu0YwsnygiTK+f48GK68RcHYn664U/4bkv8at/G0wiY3f7FPHj74lW 2YcBLqPmlqoz5C2vJuorSOZ0cChgTzvySzXeOnTRO4iWCpofRd7+N0Ui17GRFCXv9d/BNOrOaGB 6MgUPRnhNaL8lcqIl5Tr6RvqSFgM= X-Google-Smtp-Source: AGHT+IHglOBET4TJxeJSdrJRR1Xw+GGPrRhkJmgM2cZUz+6Y+TfpnKpcmVHr0ZVc6dyaIRBSz9AzofWe8RS4A5f82q8= X-Received: by 2002:a05:622a:1aa1:b0:44f:8870:185b with SMTP id d75a77b69052e-45004db0367mr34790561cf.22.1722090450127; Sat, 27 Jul 2024 07:27:30 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Nuno Teixeira Date: Sat, 27 Jul 2024 15:27:19 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: filemon To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008d1ae1061e3b6d83" --0000000000008d1ae1061e3b6d83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I use filemon for builds with WITH_META_MODE loaded from rc.conf: kld_list=3D"... filemon" for some years on both amd64 and aarch64. Cheers, void escreveu (s=C3=A1bado, 27/07/2024 =C3=A0(s) 14:50): > Is it better to load filemon as kldload filemon, or to > have it set as a device via 'device filemon' in the kernel > config file? or to just load it when rebuilding the system? > > There is man 4 filemon but nothing there to describe usage as .ko > or device. System is n271321-9ae91f59c500 on arm64. > > -- > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000008d1ae1061e3b6d83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I use filemon for bui= lds with WITH_META_MODE loaded from rc.conf:
kld_list=3D"...= filemon" for some years on both amd64 and aarch64.

Cheers,

void <void@f-m.fm= > escreveu (s=C3=A1bado, 27/07/2024 =C3=A0(s) 14:50):
Is it better to load filemon a= s kldload filemon, or to
have it set as a device via 'device filemon' in the kernel
config file? or to just load it when rebuilding the system?

There is man 4 filemon but nothing there to describe usage as .ko
or device. System is n271321-9ae91f59c500 on arm64.

--



--
Nuno Teixeira
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000008d1ae1061e3b6d83-- From nobody Sat Jul 27 15:01:22 2024 X-Original-To: freebsd-current@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 4WWSWP5DScz5SMYh for ; Sat, 27 Jul 2024 15:01:37 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWSWN5tJnz4VbL for ; Sat, 27 Jul 2024 15:01:36 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.de header.s=s31663417 header.b=BIkGCJx1; dmarc=pass (policy=quarantine) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.17.22 as permitted sender) smtp.mailfrom=garyj@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1722092494; x=1722697294; i=garyj@gmx.de; bh=DHmf7BiIJrrLfnc31YPnkB7eiot6mCqRAROHyngeEZw=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:In-Reply-To: References:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=BIkGCJx1LaTEEeD3hp7YyHHK1wTKz/hFd6S7Aw5JqNQxB3lYT0Ses/quV6jNHPe0 wCpGyUFmSUpnxS/bEYUVbEPHSEmZy72PQul/VaavJnp/AwQJ6IHo7q5BVnSQIn134 itcVMS7s4qkomkotpTnbH5ok3hJ4gnSH0oALPQy7/BaVCxODldSLmvchQiR3UxAgR R+JCbJjScR1WakvXH2k08ujGIYR7bpYPJhgzTRq0DGCfy9rjdbGpa1r7VQZZJslt/ SixkwWkV+1cQ3S9YW+gbE38kGxjXrAlp22zjXSZhaKpTwHDcTfRlabTdrM1RTLnof LkBrJdkZx9l5yCau3g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.2.58.134]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MAONX-1sRQCj21DH-0074AB for ; Sat, 27 Jul 2024 17:01:34 +0200 Date: Sat, 27 Jul 2024 15:01:22 +0000 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: <20240727170122.675f6bfe@ernst.home> In-Reply-To: References: Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.20.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:qTk31GbBLlPSip8umIAuHTkGeVRweebkaY3XaL51hdr24JhlHkE KTDZWnWeRrr9yas/s4THYkkmIPvgkySJNeZx1OhIOe3LJNcJaEpps53Rzg+7z2aqQ0I7Y/9 QPT8qRMN5/XwjJj0ES0b8cRirvSC3BQS5ii99J8HRZOmB57I0BMYGrrEOI8y5B9j/U9TSdx oHrTaz6k+Y42OOAGlcM+Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:+hHnltWXXhg=;IMnxuYzOj2/JvxrDem3PlRG3s5U 9YA7xkQDjaECrUign3kPVftFo/kOgZN0CRl+tUjkhFmF6fPC+cXoA0BkcSbkNqyYMMAy4YLw7 PsmgQNZjVJ6LAf9WmFSND2+LGKQd1uCbNCmB6SA1OI/IcUJTqoomUYpckf3Yc2E+mJxXN8y3h jw7C/GvxL5r8c/Wf++3hOqVWVBnbYQglNwz5ao/MDbJr3RG4zwyPiTfjyD2JrPUfDTwajOvMB +8H+VrClvWQyGa21vfgMYvaHdqIDSYlOsyFGPHJfJU4E82a6D0sv16DrZ4SPFpXJPq/dBSrDv 7sMw2g4LkcGrtZScbEJL/Hu1/cS0dl0XVQlWKpFXJPg4jX13BSMz8epp8YRHCjjRaCpai8oNu 1CD0G0c7FHFvvs4fIN/d4j3Ltwv99F9+2QgfmYT77RnHMMLwIbBDqN0SlPMBukyndtwnfbgZU yTrtXKPMRZYdxoKkqU/vObCswPE19IQ6oQ/+H8IuOvMwjcZn4WGP8PKgqaqoRQ6MveTxmwt2/ +wWjqfKrgHQJAu+Oew79sNBkmbpUiWF0yqIjO/Xs+7rhWr8zlLSS/y2SEgo6u7kJOO4NlF4PW 5TlNMN6XmfFSdoP5NnvGo533k7jES94pS9fgVB5TU6qrxknzh3dnH9RfmhtDbBKG48HfeLE1j N/qCOrz/Lz5X0DUEJ42/hFSbp9Pnhk058S2tp07w+lOExwpbpUJg5cxhMgX4km3D8XVZLtrkz UEnedq4N1u8G/1aubuCvZ1R03uuS/P1kvOkJRgfm+yfECJzFsIN6cdXzm8bM2hTaDAsgQtcUE XrGpJ0JW5crXHBefz9kzaJ1g== X-Spamd-Bar: - X-Spamd-Result: default: False [-1.81 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.998]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.81)[-0.810]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,quarantine]; R_SPF_ALLOW(-0.20)[+a:mout.gmx.net]; R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmx.de]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.de:+]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_REPLYTO(0.00)[gmx.de]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[garyj@gmx.de] X-Rspamd-Queue-Id: 4WWSWN5tJnz4VbL On Sat, 27 Jul 2024 15:27:19 +0100 Nuno Teixeira wrote: > Hello, > > I use filemon for builds with WITH_META_MODE loaded from rc.conf: > kld_list=3D"... filemon" for some years on both amd64 and aarch64. > > Cheers, > > void escreveu (s=E1bado, 27/07/2024 =E0(s) 14:50): > > > Is it better to load filemon as kldload filemon, or to > > have it set as a device via 'device filemon' in the kernel > > config file? or to just load it when rebuilding the system? > > > > There is man 4 filemon but nothing there to describe usage as .ko > > or device. System is n271321-9ae91f59c500 on arm64. > > > > -- > > > > > filemon is not a device, it's an option. So you can't have "device filemon" in your kernel config file. I compile it with makeoptions MODULES_OVERRIDE=3D"filemon ..." in my kernel config file. I also load it from /boot/loader.conf using filemon_load=3D"YES" So, there are various ways to get filemon loaded. =2D- Gary Jennejohn From nobody Sat Jul 27 15:04:34 2024 X-Original-To: freebsd-current@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 4WWSb25jcxz5R7pg for ; Sat, 27 Jul 2024 15:04:46 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWSb20TGnz4X1v for ; Sat, 27 Jul 2024 15:04:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPS id 46RF4Yja076505 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 27 Jul 2024 17:04:34 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1722092674; bh=9dbqBGkGq554sn632GVNepQhtpXw2Pi+qxtFqrrZIkA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Xjgx6WbNayjy3xZdvvjx+98TN5JkCxeX0S2lwA00zWxcCd+mFi2VpvvIkkQZ++Q3x W16Eq4/BIvesBKliMHtjlAR9zlT0skeFY6fVCpkcLmxtwlkivMX74m+fcceGrTgNwE 0/Vkz56EXRQO8siLWRzLxfSxZOx0SeoVBZJFjR/TjRUT6fvgqgvojy/E3KaL1hW+jZ dd8JIhgeiE55rem6kxMkDyN5vLpUKvJ8f0O0TA9MVKZ9WcrjNI9u2lpZXoC4GwNxWx 5HYy9ptr7L07EWLMDTf1a2P8Opivy3G/Til6VLv8WntDiM9h9Q9LHWdEawHcae5LHZ 5a0U2BulWlBZg== Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.18.1/8.18.1/Submit) id 46RF4YEb076504; Sat, 27 Jul 2024 17:04:34 +0200 (CEST) (envelope-from zarychtam) Date: Sat, 27 Jul 2024 17:04:34 +0200 From: Marek Zarychta To: Nuno Teixeira Cc: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Queue-Id: 4WWSb20TGnz4X1v Dnia Sat, Jul 27, 2024 at 03:27:19PM +0100, Nuno Teixeira napisał(a): > Hello, > > I use filemon for builds with WITH_META_MODE loaded from rc.conf: > kld_list="... filemon" for some years on both amd64 and aarch64. What about filesystem perfomnace ? Have you benchmarked your FS and whole system with and without filemon loaded ? I am not questionining the usecase, but loading this module only when it's required seems to be more resonable for me. -- Marek Zarychta From nobody Sat Jul 27 17:14:53 2024 X-Original-To: freebsd-current@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 4WWWTW6ZRvz5RLYj for ; Sat, 27 Jul 2024 17:15:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWWTV15wrz4grV for ; Sat, 27 Jul 2024 17:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pMbReMYM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722100507; bh=X7xrehhMcW+MKE/n7S3AkRtUiU1s+XkiOQ3oUM6eY0M=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=pMbReMYMoNHCcCDKGZPlFRi7dG35EgmTlLADoaBapmhLfsgWWqjQFXrNCd4+ftraaIde5+chDAtldaFfP6g5Z6prJ4MBslrMroE/EMUjhjQAF4Jd3Uc3rU/5L1Yx1DZ4dHDFSxuFLLBz/oUcXptuk9GRFDde7Fp7JKjNMG/t2tw5ZFX34Sa6Jxu0zKXJbFsC01ay5GpIaOs5kRBJChgiZmiwMqUi7FUtpkZ3yLKhPSYbheaDogevav7NzaZTa4WCNmxwQXJoXKISUmShExiVL4QCjvsLh5hAUWWdxlSTa00ftv4RIXsXDrbq9JyvT4Nho1dm6GIgrUSz2yUr/bQ1XQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722100507; bh=yQ5FkOdjv0B2rE+lUQdMYG8b0Je/s9UJcWpB2gbbvYi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=mV2Qt33V/aS5xcd5X6RWSUA6WIcw0UHmYc0+5oa8BJbslCoI4sfOWhMGbXvaRc4geBc0RDigwQpgUQq4yXXFGbxAyVNEuO6JBvRcRa6ry4gJyn4ndiEQP8WYCawAiOo9dpuRDHIFSJaAwNju+csVWb8Jp8yHg30Fsbrmlv9Wh//y3HF8Uz48LU2sjn5IMbxhQaNlLjWQBVQeFpShvke38XZGttYOH2cBK2awApFTxf0P5lhYgtK0W65G0qRDse6jcg4R648PU9thrXxrIZzpl6Y4S92vDN1x61Ci3rLL1Zt58phLQK3VmEuGMVR7QzsOKSZ0Q03Q6A6O97NyRsxx0w== X-YMail-OSG: nKuWcXYVM1lSmuO4mpHdPdQiMmTC16DJGtOtfi8KeCTIezbxm7tFcq.Hxf3QF9i aXX6guOCzeFL4hAAnw3C_jRrISxepgg36ukyE2gkgK26Ufbakr27l3gL2wvoAmBThvXPatgS6PDC l5qY9c9JLOMflunWrHK2e9uwT1_RLmkTcsm4lRZLPJ..J3oEsZ0HiqqyyFxIfOBqoBwt3x.kyrhc WDjJloSvHy45pVPRgZEnKyPgGZPT57NbcPqhouOxbhkQRYl3VE4vFmSjrI6Cy0qi1xfRY9z41dj2 b6fC8BIqa4Lxdx6FRdlV1oWuW_gfuhBYQjMm3M46DI38Hck7eEzskD1BVB4z.PAVcqAaNvVEBl48 NcuZjr9F6xuHkaTeT0tEu2GaeDI4lYGHROkGfUrMfo1Xiu0uaC_0.X.3fqSr8Mka0xDFvfhzYpzf kEip3VuwfGDGiUB2vZVhi.VXyjNomJU7H6e7.csetiN1EWN4pupBet5axqz35uCo_41pbbJ0CbJL RxPn.T5JqHfFWuvFGaEYPCNo5H.MpyZR8dsQ7x7BJraRT83Ugye7vfj1uUOhOyySFgJXGOfg1AHi eFeK6EIE73QZFEg1OcZSrMXBVJB762rX5BbjVQDExpHGFA3UKzOagw81hBGNd0_Cn3JUh2RQ1Vrv fOOHQflWbjUcAo0plsj8g5Pno6_P_bJYpxjf5_MkUvoFpgMP55iD.xcr.hPj6B5HR0zlMkVAw5D6 cnPg716WMt_jR1YoonPxSrRyVtc8Ee_nHgUc0u5w14.cY98Vpe9h3HAKtniHJnh73lB1oyMxnx_5 fPQXCaqNYY_UDyzWQTFG7jcnGmDCde7MUwcxeaUkmSELJn1.nru08a_igDD8PLGW7ApikbLuZx3r MgvEhD4bH9xoxGVGtPVUi1eCZvfOS6.eVKDalFysVp.oAfeN6nUzOT9JMgYTCP7innRrg6IX440m kbTae6y1mtlctFnfrjlG9fgWIMS2clX3W1YOuqjDddHdDh9n7K87aXwpIbGFUq3dcQdTtAwDGZpk f1MFI89ekVbfRkIyZNJ_cdiUnXSANFmnblbFv_.IhFbNJ3oOKN3jIYkzoLAtSrt8LijSr3Z7zhXa bQU7hZQzytEWl5AZDhUd6zCm3.C.BDIYe41CZ9wEkxb8iZnshVxOkhL04k4651U0Q_olrkQVzEAW I904sPxSMArh5s1U4FwcfJl8a6.CMqIxk8tfNVfb6ph0RqI.K0RSjxNSzLL66PPxVZ1DMtn90AJS IWiFBaz01XLT3.L.wQ9LWoAqzphAPpmPY5Nj_RN0dS5jV2MTbRmUKPVE15XZ3F_gz..fFBtja8bp _FNOWpHY1nqayeXOIgrqwLdF3OejxJLc9I2aOHarMYQh9CTIY2p6SfTTSqTtan_CJJ.NMwZKtHCy wtiQ5So7JsVqLiIogeXu6QHvMeqBPwe.LialjxzPi8vjBNWSE23HWrVw3Q4lW_v.mjzhTFXI4JWG OP5KA1h0IlL7mm5ngaxDjGZOHNOB1IzlR4RhjvmbcOMvDqDovJGmWKS83luWmmAWY2ENJJlylLV0 i1xoG12xLMEpbVwZxrj0za8KLik5O7Lm5hyCqdTN2VFEmm2O33nHrGx6PDPxaz1RXSJZtM2CVDMk RNastVofHwK24jzLIYkVXqrH26GVwLS8jLqrf_HJFlJv8VTW5Tgs7Vd692WGkBF_mqtvpSxe9L9H 1L5TuG2.YmQXiWdwb9iJM_VTCLo_QBvjRu3Pi3FKXK.rx80trsqpFVfXTO60QB7cujcIDbKNuDfp N2heYIpfihPUu6.FA72rtb4QFcR2SZyaEUBZqm_8CuOVaOh.QA8j0HOpD1IqU8WbP56MVs1Ftc1n efG0IJHnVYg0tgza.mailZZKv6wO9ztAGcfPmU8wy8J8qd_MXd0cQz1mRAF7vnJGxjq.yqcEZaW2 Pd8w0q8WlNRK3iEZb5AyrbmhteJeWauiCIIQ.1TiqgfiorKOgW6sjuv0z.DC7txpLtqwv3kAgfmH rZta6sqr4RSNceey7Z2My36uynmFcJthpZlxp5ebxa8kNNUA4ZtoBu1qMMwlf4mjvgvdeBDjrJgl 5cwmXIYfGzSO3s3xHsaAmRyaQoZKnJSgkJTu18bCniHZnEnE8a8xpzxeYheOSw1SeY86MNi29OTo vx.L1my3XIia2V7rhmSMZSjqIUC.0zOvO3jidV6pMEuyWwQjkAHH8Ho0i6ap2Sy_an9iKzAKjOGV sJMC22jh6BL9JobG1xkmt1cI6xbUH5aGvPifzFIhpRRqnKkCUVc9QjdYjZvI7FeTSbDLyFbZwD0M salaa X-Sonic-MF: X-Sonic-ID: 5785cf82-8dc8-468e-b22d-f1c9cd91f52a Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 17:15:07 +0000 Received: by hermes--production-gq1-799bb7c8cf-t9jf4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3934b490e8ebfdbfc481e5badadba27a; Sat, 27 Jul 2024 17:15:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7 chroot [and lib32] on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system Date: Sat, 27 Jul 2024 10:14:53 -0700 References: <87D92513-97C9-4CFC-8A11-9819375FACAF@yahoo.com> To: FreeBSD ARM List , Current FreeBSD In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.919]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from] X-Rspamd-Queue-Id: 4WWWTV15wrz4grV On Jul 26, 2024, at 21:58, Mark Millard wrote: > On Jul 26, 2024, at 21:20, Mark Millard wrote: >=20 >> The original mount was: >>=20 >> mount -onoatime 192.168.1.140:/ /mnt >>=20 >> For reference: >> 192.168.1.140:/ on = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt (nfs, noatime) >>=20 >> gdb reports: >>=20 >> Reading symbols from /sbin/umount... >> Reading symbols from /usr/lib/debug//sbin/umount.debug... >> [New LWP 100137] >> Core was generated by `umount /mnt'. >> Program terminated with signal SIGSYS, Bad system call. >> Sent by kernel. >> #0 nfssvc () at nfssvc.S:4 >>=20 >> warning: 4 nfssvc.S: No such file or directory >> (gdb) bt >> #0 nfssvc () at nfssvc.S:4 >> #1 0x00021be8 in umountfs (sfs=3Dsfs@entry=3D0xffffce90) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:396 >> #2 0x00022400 in checkname (mntname=3D0xffffddfb "/mnt", = typelist=3Dtypelist@entry=3D0x0) at = /home/pkgbuild/worktrees/main/sbin/umount/umount.c:327 >> #3 0x000218a4 in main (argc=3D, argv=3D) at /home/pkgbuild/worktrees/main/sbin/umount/umount.c:195 >>=20 >>=20 >> truss's output ends with: >>=20 >> . . . >> = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537321472 (0x2006e000) >> statfs("/mnt",{ = fstypename=3Dnfs,mntonname=3D/usr/obj/DESTDIRs/main-armv7-chroot-ports-off= icial/mnt,mntfromname=3D192.168.1.140:/,fsid=3D18ff003a3a000000 }) =3D 0 = (0x0) >> fstatat(AT_FDCWD,"/mnt",{ mode=3Ddrwxr-xr-x = ,inode=3D2,size=3D1536,blksize=3D4096 },0x0) =3D 0 (0x0) >> fstatat(AT_FDCWD,"/mnt/..",{ mode=3Ddrwxr-xr-x = ,inode=3D73557804,size=3D512,blksize=3D32768 },0x0) =3D 0 (0x0) >> = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 537219072 (0x20055000) >> = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537341952 (0x20073000) >> nfssvc() ERR#78 'Function not implemented' >> SIGNAL 12 (SIGSYS) code=3DSI_KERNEL >> process killed, signal =3D 12 (core dumped) >>=20 >>=20 >> For reference: >>=20 >> if (nfssvc(NFSSVC_DUMPMNTOPTS, &dumpmntopts) >=3D 0) { >>=20 >>=20 >> armv7 chroot: >>=20 >> # uname -apKU >> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021 >>=20 >> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru >> FreeBSD-.snap20240726110821 >>=20 >>=20 >> aarch64 host: >>=20 >> # uname -apKU >> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021 >>=20 >> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort = -ru >> FreeBSD-.snap20240726112037 >>=20 >>=20 >> After exiting the chroot, the aarch64 environment did the unmount = /mnt just fine. >=20 >=20 > I set up a context where aarch64 ends up seeing (after chroot > exit): >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/gpt/PBaseUFS 1114846 184896 840761 18% / > devfs 0 0 0 0% /dev > /dev/gpt/PBaseEFI 244 26 218 11% /boot/efi > 192.168.1.140:/ 823229 74755 682616 10% = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt >=20 > I then used the armv7 umount: >=20 > # /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/sbin/umount = /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt > Bad system call (core dumped) >=20 > The truss output for such shows: >=20 > . . . > freebsd32_getfsstat(0x2004e000,11720,MNT_NOWAIT) =3D 4 (0x4) > = freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALI= GNED(12),-1,0x0) =3D 537411584 (0x20084000) > = freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIG= NED(12),-1,0x0) =3D 537423872 (0x20087000) > = freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALI= GNED(12),-1,0x0) =3D 537427968 (0x20088000) > #155() ERR#78 'Function not implemented' > SIGNAL 12 (SIGSYS) code=3DSI_KERNEL > process killed, signal =3D 12 (core dumped) >=20 >=20 > Side note: >=20 > # more ~/pkgbase-snapshot-list.sh=20 > #! /bin/sh > ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E = 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(-[0-9][0-9]\.snap[^~]*)~[^.]*\.pkg)$@\2*\4@= ' | sort -ru >=20 > results in the likes of: >=20 > # ~/pkgbase-snapshot-list.sh > FreeBSD-*-15.snap20240726112037 >=20 > that reads a little better. I looked around and this lack of support is deliberate and has been long term. That tells me that, despite the amount of nfs mount/umount activity of UFS file systems I've done over the years, I just happened to have not done such from a chroot context before, at least for the umount side of the pair. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jul 27 18:31:37 2024 X-Original-To: freebsd-current@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 4WWY9n4gbBz5RS4V for ; Sat, 27 Jul 2024 18:31:41 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWY9m4rQWz4nxC for ; Sat, 27 Jul 2024 18:31:40 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b="tBhyFzr/"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ic6wzMxG; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.155 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 991AD11400D7 for ; Sat, 27 Jul 2024 14:31:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 27 Jul 2024 14:31:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1722105099; x=1722191499; bh=Z6jjhqYbzK BXANVv/CIcXhm7/jI8fds3Umr4014WXu0=; b=tBhyFzr/InfYQ/fFnpNLM2MtUt Fn0A1OcRhL6pE6FPGpiUnn31Ioqp5iWtcN/gk+DR+uuBbbqky/sbUoBJRjoZKYa2 mupEVCYwuI2gUHYtJA5JR5jGF/plV8B9eQl3PsaLqvOv8659YOLFN6sjZz+KTLjm fzniAXOaQUaYfrNjQl0eHCIhiMYEpfDt3df0wMGE67RqDGF6dweCgN3AX+EP5rQi oqdG3nl6nmPehiTIwTp1rxEqmxBYoHuoOY2PvgMEyV3qEZrE8lEW7ARoHSSyJm9/ Va09j2GLNmqC+nn+ra75gJI150SIlxhFT96l8b9hFEW4uQkoaf97CMEtWnSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1722105099; x=1722191499; bh=Z6jjhqYbzKBXANVv/CIcXhm7/jI8 fds3Umr4014WXu0=; b=ic6wzMxGI5FenPonn2qo22C8tDNE3usq8FjeWOyOboBG 6MAWJ3iiWjd2p8Il1vgKo5KRU9Ll+VjqDGlhaHJXt0w9TRqJGFwEImx7FGvlk0P7 DkzFPs6XVvGTgFvbDo86KgwTn3fbv2E/Yl+YX8zwDkrrC0itxKdGybfE9RKFRq/b 9LtnUsJ+Us2lQMRXp4HxKoAMFb2RZJ2gjwGpZpEXejaWS0kGVagmquERszAMNDiF Q7K8qbfsqGOXfXwwYAQMSZjj/lCP/JuLFzhM6JJLTpBe6NJMEp9vQSeePKT2/L79 UaycG1Y67W4I9XxwtSrj2nTB+ccylwdcaBfpdCUAHQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieejgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 27 Jul 2024 14:31:39 -0400 (EDT) Date: Sat, 27 Jul 2024 19:31:37 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20240727170122.675f6bfe@ernst.home> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20240727170122.675f6bfe@ernst.home> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.773]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.155:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WWY9m4rQWz4nxC On Sat, Jul 27, 2024 at 03:01:22PM +0000, Gary Jennejohn wrote: >filemon is not a device, it's an option. So you can't have "device >filemon" in your kernel config file. > >I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my >kernel config file. What's the actual line in your kernel config file please? >I also load it from /boot/loader.conf using filemon_load="YES" Why do you do both? (I presume both as you're saying you 'also load') -- From nobody Sat Jul 27 18:34:51 2024 X-Original-To: freebsd-current@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 4WWYFX1Qfnz5RRgS for ; Sat, 27 Jul 2024 18:34:56 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWYFW2ySrz4plk for ; Sat, 27 Jul 2024 18:34:55 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=haGzsXS5; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="f 2X97bq"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.155 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 82BF0114012F for ; Sat, 27 Jul 2024 14:34:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 27 Jul 2024 14:34:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1722105293; x=1722191693; bh=hVY8wL0F0bwgmKHVTzpzLfIsSswmCwMwCTz8g2tA6UQ=; b= haGzsXS5VFP2v7teE2OcECVICgwPzvbE8T+cXdWokcp0R3gqf3i5KTK9bJEZfXJP 17iRhOL8ldXCqRMfpnrhpLzLsVWon0rPBiXKRG177i/s6VRLIisb1D9C+vrVpuMc hmerEh9Mi1ItPxy4RWHVC+kJcuRyY9xju4hGBajL3oW8HjaztscOjnbhY5JUjFs9 UYG4nRGwAqTmLKKGIMmDaCC3+xjtRSrTKeX4CTTY8d0gTt+TqOrZnbtTXVls5ehs w12pl2uCfTsU/37cWoBDbAw5l48ItkMZ6TCymy3bKexhZfo+I2ILo+sgqrSsOLI6 vtZ5OvDYgPLdinyDuPDgRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1722105293; x= 1722191693; bh=hVY8wL0F0bwgmKHVTzpzLfIsSswmCwMwCTz8g2tA6UQ=; b=f 2X97bq/fcLmsCohLZbbdu7MONiEnG98+okC4bGeiSI16z8RzXorim7yVRTClxg43 Q2ENuReXvhSOK/ndfu6D6ECeqymdAnq799sJ9Jr5gBchBAA5RTYInBM+TklUqncH YrOf79CEAL/2HeCEHyTAcznWm1uJMDlI7LUYtEq3rqw7v/B/hMfHlApDlYiR58jB GdBExF7hMxU4KLAGtCSZIFJQ8wDS0DeioEW9V74BcvxfZnbu6PQpLqpqyWK7wv4J tbKIj9xKrvSJ4q/t6gUqTY39wDyroywwDoH20zHiYZrZcYEOFEIXA3OqmGoMH4cI TPMyyMNFJRQusYVO29FzQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieejgdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 27 Jul 2024 14:34:53 -0400 (EDT) Date: Sat, 27 Jul 2024 19:34:51 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20240727170122.675f6bfe@ernst.home> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240727170122.675f6bfe@ernst.home> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.769]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.155:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WWYFW2ySrz4plk On Sat, Jul 27, 2024 at 03:01:22PM +0000, Gary Jennejohn wrote: >filemon is not a device, it's an option. So you can't have "device >filemon" in your kernel config file. man 4 filemon has the following NAME filemon – the filemon device [...] DESCRIPTION The filemon device allows a process to collect file operations data of its children. The device /dev/filemon responds to two ioctl(2) calls. [...] Are you sure it's not a device? The man page suggests otherwise. -- From nobody Sat Jul 27 19:41:06 2024 X-Original-To: freebsd-current@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 4WWZkB2xWYz5RYMx for ; Sat, 27 Jul 2024 19:41:22 +0000 (UTC) (envelope-from moonlapse81@gmail.com) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWZk94HMtz3xkP for ; Sat, 27 Jul 2024 19:41:21 +0000 (UTC) (envelope-from moonlapse81@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=h61YrTDk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of moonlapse81@gmail.com designates 2607:f8b0:4864:20::d2e as permitted sender) smtp.mailfrom=moonlapse81@gmail.com Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-81f96eaa02aso40262139f.2 for ; Sat, 27 Jul 2024 12:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722109278; x=1722714078; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=dDVLe73uCi0n/3K3s4AYDxOkB6DleXLGUpdPkGjcbpw=; b=h61YrTDkdLubTuBrrdqJ6W/HPRHbUrTnNiar9U/CSWUEwN3Qyd43KR+kU6nsjdqIj9 eX+eXVqIUjs0TD8zjdNEKVHLIqZnVuWXZn5dIqn3wc9ClRYAnkHqEMazFLlJbrFReepL Fn677AO8wIIHSB1bVOK7dPD1POBOtnuYg/xeV0EnhZ6DP29eN65ArxZhHJpzDyZBi+Qg D0dy3iKZTqZu6Pm/TNAUwpANlej4rkG8q5b+/3VcovPZ1Khmu25Am2Aj6BGE6TOAVTCg boATFSG8eLad54UCQbK7LCldr6aAdXU/MflnO3NCz71KELZ9CoN13u64uuPFM8WuGvDS vRCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722109278; x=1722714078; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dDVLe73uCi0n/3K3s4AYDxOkB6DleXLGUpdPkGjcbpw=; b=kzdKAIg+yeefpRKrC0k6JPOt9LInEc2blhZtzWUeVj11+xAXpb5Wk8Ei8dawMlDObG zGaGRjczKBoIf2yOkPUBqDwirgEfM0953oUzC/HK4gOuaY8Ajt2tFym4Fsx+pLr2jwx1 quXg84jB7c2rvh/OjFfdPlBqiaNmDvZWw3BG0xWecPb0JuuzoGFiQTzXy2lr1V/Svf+U Rb05YADW7M3EdoZpi8xojpI2mPGHrGdlgDQJli7kFtObOTtxpJQXaZucPGXB0uMpf0qu DaTyy6MOyDXjrVI2B64xAKBzoY8nLG2D+Xr0clQJanmbtLaMtu+Sj1wYMqNh+enSCSEX kTHw== X-Gm-Message-State: AOJu0YyPBf+R/MVJyvqrsAqaM5nHD4fdlQAUWJQkf2S9OjNTZ/BEkXLv aDeliwDOLtHpof+AYE7GC3E6mkO5326AYATSbrXECBHyfE/V8UjfLRmS6o8JoMZElz9ARTccEwc 8o6StXbowJNadm+e3RCYBbSPWLcwEiQ== X-Google-Smtp-Source: AGHT+IG/tDab+aXf2vQpKgMZU/rMVerq3NiQ8abNhBkVYXGzdjEMjN4jFrm0byTFI5ojVZ2DqixdifurQSwBSbG8e1Q= X-Received: by 2002:a05:6e02:1fcb:b0:375:8fa1:529a with SMTP id e9e14a558f8ab-39aec26da53mr36695615ab.10.1722109278215; Sat, 27 Jul 2024 12:41:18 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <20240727170122.675f6bfe@ernst.home> In-Reply-To: From: =?UTF-8?B?0J7Qu9C10LM=?= Date: Sat, 27 Jul 2024 19:41:06 +0000 Message-ID: Subject: Re: filemon To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cae780061e3fcfd7" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2e:from] X-Rspamd-Queue-Id: 4WWZk94HMtz3xkP --000000000000cae780061e3fcfd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable slightly tangent question but does filemon and consequently WITH_META_MODE=3DYES work, when /usr/obj is on tmpfs? In my test, it is not and i tested without reboot, so /usr/obj is not removed. Reason is to avoid disk use when building world/kernel. On Sat, Jul 27, 2024 at 6:35=E2=80=AFPM void wrote: > On Sat, Jul 27, 2024 at 03:01:22PM +0000, Gary Jennejohn wrote: > > >filemon is not a device, it's an option. So you can't have "device > >filemon" in your kernel config file. > > man 4 filemon has the following > > NAME > filemon =E2=80=93 the filemon device > > [...] > > DESCRIPTION > The filemon device allows a process to collect file operations data > of > its children. The device /dev/filemon responds to two ioctl(2) > calls. > > [...] > > Are you sure it's not a device? The man page suggests otherwise. > > -- > > --000000000000cae780061e3fcfd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
slightly tangent question but does filemon and conseq= uently WITH_META_MODE=3DYES work, when /usr/obj is on tmpfs? In my test, it= is not and i tested without reboot, so /usr/obj is not removed. Reason is = to avoid disk use when building world/kernel.

On Sat, J= ul 27, 2024 at 6:35=E2=80=AFPM void <void= @f-m.fm> wrote:
On Sat, Jul 27, 2024 at 03:01:22PM +0000, Gary Jennejohn wrote:

>filemon is not a device, it's an option.=C2=A0 So you can't hav= e "device
>filemon" in your kernel config file.

man 4 filemon has the following

NAME
=C2=A0 =C2=A0 =C2=A0 filemon =E2=80=93 the filemon device

[...]

DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 The filemon device allows a process to collect file op= erations data of
=C2=A0 =C2=A0 =C2=A0 its children.=C2=A0 The device /dev/filemon responds t= o two ioctl(2) calls.

[...]

Are you sure it's not a device? The man page suggests otherwise.

--

--000000000000cae780061e3fcfd7-- From nobody Sat Jul 27 23:01:22 2024 X-Original-To: freebsd-current@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 4WWg9D6cJkz5RrhJ for ; Sat, 27 Jul 2024 23:01:36 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWg9D4w18z4GyD; Sat, 27 Jul 2024 23:01:36 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 46RL2Fna015857; Sat, 27 Jul 2024 16:01:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=wCdROQXRKZLNu /GRRQv+BEzOkTxoGozXMj/u6Prujq4=; b=k0K6nwvOMr1jtSx3+TAvU+mAc8s5+ eUoPqGvJf3IFZI4S/NmkRorBqjxs086dArm1xW2lKcrrwXGT1RxpDAAG4dAU5Dk9 z7Hv45IeSEZJljqEMzIx1ZhqQ7SeJHd1aTmS2Bh5gyhUDxAC2YCh8mbFx3+vmGCA 1ICokrQGmqh0+FwjKlqx9B/dri/4a8wQ4tglL5oJl1IwYi+LgN0uCW7g/nT/vLcQ FcZEOfyC1JxnIur+0OnJb40ED8MtSFw1lb9CAiqEWRL/qWanBo2+V2GWDK2GPvzI a1zLK1+Zc4SLXbVu9EUnuCSAZDe5XsrhJ3qECi/hkq3YlIMyaDirPl9hA== Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azlp17011029.outbound.protection.outlook.com [40.93.12.29]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 40n00tgthk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jul 2024 16:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SYw4jehfyaPcdgBc52+xodiL2zUUdLsDP2MeHgl8of1MbWcxX0mCSWQO+4blO2QaI0U2R7gis77kOWvMqEo5BE7rnIA0L7nH/7KNR9m6g5qblMxCZ1mhBy22ujeJ2L/7cpE4lw00ufu7IGHT/0SnHyW8vG7agNSHV3D0ZjT37OvdQB7wfwHNvfimKU+leoljTEPq9ZEANMzyCXjO+MdMEZfJAapML08Ej2wLtIkcZsjs6nHqGk96Rz3xh9/FPWq0XlSO+bcSAL8qExsh3RzJsnBhyvQp9ik5qQbH6f7L/nBBVNIzlcCFYfcUXGSzaHmXdR0pzmsNnLY8aOIuIBMtqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wCdROQXRKZLNu/GRRQv+BEzOkTxoGozXMj/u6Prujq4=; b=wwxAQO/g146WpbFWFzN1yI601XW5f7ZPhj08iVHLJXIsmQSoxLsOGbg3QUtmfTOFxMr3PfZzlmSehRVORug6j8rIEVQj1fqDd/+Ob8ftbfEAJun0l8I1nmiU1oekVRDTWjZz1DisiRvTjqW8EhRIpPfVosDQlA1e3QTJHJ4E8EI7kV4Z8kS3uVVNH9DQvShmSmBGAY9Ux55e+J1cauFAAP4MznqCncf7LV1J9fxu5q447kGS5Co+SbHUyv6dPW2T1uylFsH02VNaJu7BTAYs6DRrTzKay/xKyK9n9WqtCpULf51TcKeqDxzjIQfsNClhLnXkP3RA86xrK8JNfa+eGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=plan-b.pwste.edu.pl smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wCdROQXRKZLNu/GRRQv+BEzOkTxoGozXMj/u6Prujq4=; b=Ciq13kt0l3yo2UQHX9qzx64n3s+byISOihKW8M5cTRA2pcRr0zvO6ZszjTuuUHjGTceW4XbPWbtn6HWgkDYcllnZ7wFIMVKahxhGvpP+YHA2AXRnQ9GZKxCaD1SkiQXntBdyDnFvYub37clMpW1k3zUH7KqW4eHmr3mnzrPR7Ro= Received: from MW4P220CA0002.NAMP220.PROD.OUTLOOK.COM (2603:10b6:303:115::7) by PH0PR05MB7671.namprd05.prod.outlook.com (2603:10b6:510:24::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.29; Sat, 27 Jul 2024 23:01:31 +0000 Received: from SJ1PEPF00002327.namprd03.prod.outlook.com (2603:10b6:303:115:cafe::66) by MW4P220CA0002.outlook.office365.com (2603:10b6:303:115::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.20 via Frontend Transport; Sat, 27 Jul 2024 23:01:31 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by SJ1PEPF00002327.mail.protection.outlook.com (10.167.242.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.11 via Frontend Transport; Sat, 27 Jul 2024 23:01:30 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Sat, 27 Jul 2024 18:01:30 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Sat, 27 Jul 2024 18:01:29 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4 via Frontend Transport; Sat, 27 Jul 2024 18:01:29 -0500 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 46RN1St1021750; Sat, 27 Jul 2024 16:01:29 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 7FB2950CF9; Sat, 27 Jul 2024 16:01:22 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 7F50150CF8; Sat, 27 Jul 2024 16:01:22 -0700 (PDT) To: Marek Zarychta CC: Nuno Teixeira , , Subject: Re: filemon In-Reply-To: References: Comments: In-reply-to: Marek Zarychta message dated "Sat, 27 Jul 2024 17:04:34 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 29.3 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23.1722121282.1@kaos.jnpr.net> Date: Sat, 27 Jul 2024 16:01:22 -0700 Message-ID: <1083.1722121282@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002327:EE_|PH0PR05MB7671:EE_ X-MS-Office365-Filtering-Correlation-Id: 437971f1-0c86-4992-ba38-08dcae900d5d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?lVj4nZsO+tq0uBWmgaZkBlfIb9+DY2MrO8q9VtXqgz8Q2pc/CMqobcSVDC3q?= =?us-ascii?Q?S3dt32hn1Vox9xJTasY7P/eKee1Cs8773XormnXo3PGqoux4/jd+zx/tiCUa?= =?us-ascii?Q?jdv0xAT3x2oPAKf4sWNIPRYlUahYAdk2LM6sNT5oQs+aKaFbLexFrty/A6Kj?= =?us-ascii?Q?WcWJ4UIQM5uytyUdBYmCSkH/xLF5G41ymp5Sgb3eeZDqF3QucjxpTWvEmwz9?= =?us-ascii?Q?Ojfo1cM9J6o25Js2zwvRSyC7ZNCnkhFXuou1hcvQOlZKYKonW1gnZ0iYXGgl?= =?us-ascii?Q?eoqG4u81oAfiFC+M07+bnx9ZD5LjZi17iLHD9tP69z+DmbCXOy92QvdGT44M?= =?us-ascii?Q?0aq+1NEpxObQrKZb7z1fTxUz/LajneEGlRvct9ZXLI2p2SX+3jp8jzFnh4NC?= =?us-ascii?Q?pPc/KarQai4hiWnJW0VD/SP6WG/09zj0MKF62f0/h70spBxV1zFBfYgBR8oD?= =?us-ascii?Q?6jcDP5Dmi8huzR6DNPvCCWx+X9RDnS9ro2+/TSp+SP7p7TdnBSVnaAOLtS0R?= =?us-ascii?Q?d+HxFxSiCtuk3kWdcimcwpouCmvs7tr9HtZhM36B0v1mrU8wt2pEBaR1rHka?= =?us-ascii?Q?EMFHi5flmiqNkxo4XG9VG4qqLTnTt+lxVbUgBNg9n3jl58dEpTgAlzVba0Sf?= =?us-ascii?Q?mNFFK0Co3zISPCnjAgtrCPkzUkc5d3NQulPaqhCl4LktQNWc2SpupvDqw1gI?= =?us-ascii?Q?TfUfPN1fwdc5yOF2uxAYy6Rc5Rt7V9iGOPkRB3p7S/9DfGojr7fkjo/YxOOd?= =?us-ascii?Q?Pr0QfR6EgTHG7618pNi+aV0ZCa/Pp5OLYqmX4442zLoC5CbR/Fw4olQX9S15?= =?us-ascii?Q?gS+6OX92Yugh/gdoi8mQniodorHXimuoSVXkmCR3Bo2XE0OyUBBwYcHP+Y+3?= =?us-ascii?Q?EtdaffMhx8tJBx8hmT9OKpLS6KHI+OyO1965+xUtJgMxCfxiNt7HV/vQ2Qd0?= =?us-ascii?Q?/oIM7b83ZaGE1/WfxyBdSNwjFT/R/PVSJRpoenro81qYv7HxVDpSYUtqx1tm?= =?us-ascii?Q?XSxqlD8h/xs0WXGiDs+r/HcNkx3Z8eYjyszuPp8Y48tky2dcPgtU88gl51qg?= =?us-ascii?Q?uuHso/mHf8XqszpbkY3tMlAg2OaAHqTBQfLSUO100aT6xDqMbcfWphBNpjm8?= =?us-ascii?Q?b9ipF9kecbypWyu/y/tQowiKW7IQvhqLOARg/9az+YwkPNVAMi8PzS9F0m3i?= =?us-ascii?Q?YkicgMUqqoPtt7klNu83Iq1gXDg8ihopFo3nvQYN7o6FwDILGQsshDIxTAq3?= =?us-ascii?Q?xLuwdu98ak/DI3RubiWeSs1UfYHSZG5wrV1MIrBnPYjKGB+5OIWm3QNG19jR?= =?us-ascii?Q?a3yLw5/2onFbN6bZByYTb18bWkY6Cx6vxSmP4GUrQBELZIzsOyFJuUJD/mVA?= =?us-ascii?Q?xd4PqO2kAP1RfXR5jGJ9mZpzstS8/HghXGyE5J/kVBHsNMRfSEYX9SP095mL?= =?us-ascii?Q?vyZF9y6jkSksKJjf1FpqLrWQh8fz/Lmg?= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2024 23:01:30.2537 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 437971f1-0c86-4992-ba38-08dcae900d5d X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002327.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7671 X-Proofpoint-GUID: ZuFdB3i8WCwkla0vjLCVIL2TptjV3Hh9 X-Proofpoint-ORIG-GUID: ZuFdB3i8WCwkla0vjLCVIL2TptjV3Hh9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-27_17,2024-07-26_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 spamscore=0 suspectscore=0 clxscore=1011 phishscore=0 impostorscore=0 mlxscore=0 adultscore=0 bulkscore=0 mlxlogscore=453 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2407110000 definitions=main-2407270160 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Queue-Id: 4WWg9D4w18z4GyD Marek Zarychta wrote: > > What about filesystem perfomnace ? Have you benchmarked your FS and > whole system with and without filemon loaded ? FWIW filemon does nothing unless make opens the device. and then it only impacts syscalls done by that pid and its children. > I am not questionining the usecase, but loading this module only when > it's required seems to be more resonable for me. > > -- > Marek Zarychta From nobody Sat Jul 27 23:07:23 2024 X-Original-To: freebsd-current@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 4WWgJD71Hwz5Rs9w for ; Sat, 27 Jul 2024 23:07:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWgJD1kydz4JSH for ; Sat, 27 Jul 2024 23:07:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QVb6H7GQ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722121658; bh=lXYOntD90UOK0VuwpRPX58nVOS8oHSOSFT6okVGOpw0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=QVb6H7GQxBKbGMb0bIhEKzsYoCCujT0/iZf1psYEuY9Psp5slo3XPuM9qoxl8/FhTrp9lu1FfP/oTPo/UVUy4IExSc22tKd+DjJU4D0rSWv/GyQTkDmtIVMpyKQm7lgYdZxpyVDQOP3H72C6P6egxYPace0Hvm+Nu4PNmGtxlVy5jIO0DKLcTPqCRrgMHRyNpNSL1ArpaVNlyxvF5VgLgksiIgb65wMIlvGXKLA0OvPMJDDqhMYGFdsAU+FELA6wbrpjnd8RXk9Crn/Zf/5D6cwtZAopoF3UYfZVVpy6fzVqfLBTF//KOInHX8QeSNuj7+agvQ5InVhHIHNkFTRgFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722121658; bh=+wLobvv87as0ziq24NDyVR1Ucpn5jn/TrbHK2kSziEK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=lyAgCFTqfwDKnYTK20uNPtSM90rkUaSiPmel1fQB3XGUK4YOTsYci/phYO6CWsYw+Mhmp13riGhnV1wDyz2ULNthREFvxxOYDZ8sy2jTIWxtgmmN53o3SAzz/KHz7lcZkH+uyDvmL4Xm47TZh6KXn1VVZbykd62waHWmT3D1kt3TzVcA3w7tvRjbnVSwKthD6BnaIaQkd/NYmwEmwlwbj8UhQ4Fexu/grmZ+tjo5NLWeFb7Gv67si8OhF6vMZqg2PSaxUbU62cK83APkx/eH4GgNS3w7mSZP4AgDyjp4vWRNFrCM+0bZmMfJ0euWKUlI3dvWmETw7+vp+SB/Nd3MKg== X-YMail-OSG: QRCnDEEVM1mu.h65_rz1yXb.VFhb2B4ZzQyTeMWKv6L1WXznKF09CtF__4zLkvY eMED.RxnJHjB.lWqytMH7Mms41SW4br_XALM.dxW.evmGyHLXZXNrxgaiTr6RbEokQ273GzhSoK0 VnwXMHf7u1ssLHP.0RorzQelBe8fOhbHvQfRDNEh2xX9YUUietJVTA8Lwna0s_qjvHiCfsvJ5YHL 3WtCYYGmDgMH0e2N_qbMnUWJPvWu39xC9.TQVK6YB5MWz_Gc77AkUiW80AIBU6i4xxG2h8RGy5BA CJdci7c.9ovY.isASc9XNHRgMixNKUCvGp.nvJo9SWFmmofp_0HbCcpw5tMO56FialLEjzBbRD8d PmtHXRJBnuOLXEXQb0zdy5BmHFq_lbR0MxrLKi70v052N.b28tTSHUcS2Ig.E9QvJfhJg.33c5Fk EAEyNP.9xZQAqyRrVKO4RQLwnX6yNrtFi39bGGNrP7lIJy0wgSQ7coPRRVGgC2Uq9Vf7tAAStmq4 DXrRPoJ5fhI.DAXL_WHZveAO9c_SOzqScubBT.twN3qjCaDoSSu9Z3QLM41pj.s495USUtLA86sC 3oT95.8KuvnxxdlYikgC7h6r33fLvGkoLhl9nW_VnVW.N3cNLyRcUYngFJ5KtzxF9qNUCWFcB1ri v3qG5F1nCK1AoYoAn_rJ8I7082PNxzGlyBpDkc2vSvozaHkSQZibByOYr6xdi58oc9hhXGGe0kgF nPImhGYXZRxHnI3x3LoPMYf8qpi76klDHsHy0p9zwWjfCZXZ_t.XoA0jz8N0rixzrt35kRACdAhs Wr85J52mIjMXMLkUHT5Ku3SdxhklBNul9zO9qcDHtfe6IU5nuP2oX5xF5x8EYTexkC.Byen1aXGC piKr_S7jE8i161Sv9Bzf8xapOQLpeHC8JNK7ExMT5HcARjI7zWPo4E76ZUVueSeveBL5EqlKfMX9 Rz602x3QHoR.JtZVeDdJrlTifQwpKSOlIqOjvhhiHNAOGJFtuVCv3mf9.O3tWnDXH9rLhWulqfAH xWMJfgauBr6D7gaWcSm64V1NioLj.7eDNS0YSlXm7ZxHYL3reFg.Ag2UslWZF8Rtqy4C3rHdAwGF ghfSm9V4slc1dWICdZUzWByy65xKit199o65_eVQWlWbf_O.M8UmXPfvlhFtxtiuoYbzq9Dpofed YVT4sRWERulNxCY7uNv7dBxWV5Na6JQ.AMCW0Qnu0WvgpFUii4ApraM.3DCV7csoFT9wLvnkT2f3 6fMVfvv_SSyEuUYVVrBjU1ll7Cx4GdrBOPBi3uJESkiQ2.lYPD4L9lpjfxdFEFUt3Uw.FHL2SWY1 VhNr54.STK0.G7ID59FtNgasTYNy_r6.x1QlfY0t_79ScH8IyZObR6VlC_neYztrH3sGnWVgfrEX 6hxM8WYeXHiWRUaEoTTdkAOk_VHbOgi2uNgFCNTYcoz8NxwhqUh3PEJ6ofWUIJUn3OXraLmoozyf SEnpqp8BI2_O9q1uAf2pCnxywVs_IMKpZ4Kcw.CrlV6_LiHqS1VGV.YPVwsmvRwa9PdujH.4Wfk_ 1ypZIQYM262H.BbP205a014VdYC2xIEE0E5newHP.gbgm1Bb68yA4aNomDKNsX8MRhejBFK8Jx0S P2YLZF54l96Plt40e9F.8ELvofUCtoE2hIUchO0XAF86QTIt5C.wyV2Or7MfdXLBHGvK5SXzJoQY e3TKvOGRSl6oLS617J1awtIgLad7MaPaHDTd7.ieNCvWHYwfkASxDA4d_75aK4Sli4iPYwqcz78G Rn1xCuB62tyZTT49z4BlHbfcyjvCtk23BQauLOEzcCHhy069J.qmi0yRC_KtEwz9FiGrzuAusL7H filO7U8FQn8taYkpw9kzUQlultxuIkvmVGmnL6.SuUUKlDHWGQ1pQREz3bAFGn.aOtMrpfxUUMD2 jYhlFDgsSh_B_Q19KSSzVMotxV2B_7rgqc3NR3fT7FWKUZkhjzpv3QyXXTsvMXkzkWHwM2df154y 2JWTeR8O.tBOiZecigwX0AAvVUDHX5fDL.Kk_qxKdiaPhPksLqlUsZxPc0r607LR5ejHy1ANC4II hJdFX7LPr7X90fDV1738u4HvZEyVVJslqG6XmGFfKD4yWAR9nXmMNGvV.93cBY8hiA4PHQtzSCtK cQlr6teMZxeFH1GQ9t10dtnVyg8Ckj51v6s5mJRKsvy_.UfzEBwJdBgO6JT_2k6jOXqIIrkEUOub M7kK52.qMHqjHXwG70KbjPmLT.4UWTh934BldihWZoNtrbZFT.yxiPOkeghGL X-Sonic-MF: X-Sonic-ID: 4561f74b-bb8b-4849-acec-5d8ba812518f Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 23:07:38 +0000 Received: by hermes--production-gq1-799bb7c8cf-l6wmw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 57d5aa12886b46444e7e7ab6ae78d3b8; Sat, 27 Jul 2024 23:07:33 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Files not deleted via update procedure: rescue/gbde usr/include/machine/fiq.h usr/lib/include/machine/fiq.h usr/share/man/man4/CAM.4.gz Message-Id: <79733ECA-6700-467D-BA4D-CB33540D2F62@yahoo.com> Date: Sat, 27 Jul 2024 16:07:23 -0700 To: Current FreeBSD X-Mailer: Apple Mail (2.3774.600.62) References: <79733ECA-6700-467D-BA4D-CB33540D2F62.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.33)[-0.332]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from] X-Rspamd-Queue-Id: 4WWgJD1kydz4JSH The following old files were in the historically incrementally updated directory tree but not in the installation to an empty directory tree (checked via diff -rq): /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde /usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz === Mark Millard marklmi at yahoo.com From nobody Sat Jul 27 23:28:40 2024 X-Original-To: freebsd-current@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 4WWgmm4Gfjz5RtqC for ; Sat, 27 Jul 2024 23:28:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWgml2Thqz4Lcy for ; Sat, 27 Jul 2024 23:28:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nMoQ8wGi; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722122932; bh=LOp8IoM/Hu/miIDRnuMkzpdzkKI2mbDxfQl/WD193Kc=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=nMoQ8wGiPNRBPpVYY9ikABlQcvFJFeybQSlctFPA9nQ0539xUts+idoi9QyFu4kTXudmyIXWRiIoR0hVPbMq7Ig7uOFATHW1diEI61mIEakzw9+XwSDlZ9hW6s/f3VEXWiTIYnlZn0v5xGdfLchUPlT8oa8xO+ebJeV8nIM04s1pSbTFDDQ7i94SoU0a4k96y4+PxXzQyMhP35Ot1DX0IWcYBqRfT8Etfdj/6cfSpCW4mFYdZ3nsnvr+caqnBWxY6kWWRCULp9+KKtor/3RWO9kKLBm3EPykt00AK60MmoCRokP3s6vdgQ8opWHa5z1lROMWDc3KMCAYmdXrED9EqQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722122932; bh=0RVyQMM3oTFJVQ59N+R+8hwTJxMgT0Lo05QuznktgAz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=q71DJBLFQQq634HAppjRL55Mpt9k+W3gMgXtiffJY+duSas/vFiyEfa/fEXefNu9Mu4meVAevNVtJnh1XVOdcOY1dmXRrhiGY/ud00Wujh7edVP4iUJH5ZUFNL98rNxkmPpGi1xx+JKYi57OIYA8EuArw7ouvLDcraFrHfE+n0zjQucNXDOL/R3u/YfaYIbQZEJzyPTCQFbDVSTUow8t4gCR4his9pvaqYxSzbjUW/CO878LIKMPUmY2xerSYvY8g3JMyl8xbMTlKPzAkIAms8swVvpqn3SfFELGnVdTNUkGBc8qGfbiHs9o8SryijIBYwXIcwTMYHkfS+wUczjXLA== X-YMail-OSG: eeSlpBsVM1mLPQUNiMkrQonnCbXc8dQDMRDnbEHTQ8ZRvz6P.DO272H.0OusQSC tGPFi4.kLhjftg8jlHE9ZIc3pRMkxyVwVM2Srhb4SKl59A78QLngKnyaOTjEQcmtrGWjfgEKDJy. uHO0Jnb01iJ3XdEfOd3QvZtG8KChZxQZ3HW4Uvm2zlzeUcuNUFDK8BkoVspHteL6320hZV4U2oqJ HWd3PYIF2MM2QBopUOYVcG83D9NWpxJmxcBW6geajOUxDkU3XHdod8UGJ4ckakqn5RICNfGF0Yxf mIM1ksSo6hExkefABsq1_1MFs3dM6gANdJgXZ0r.Ah4y0gFULUjW2iI6gk6zMXGhwSCkxmEXRh.1 CXOR9brdPZm8AnG9ahnDIzK.miyJz3LKNfdeKv_ZuocQ.qq0xfkm9KNudY9fQplp_iATPidbrnZH JjBHxfaHmhPneEKUSrbfFRbjbMGqDvVpEJzG3VPNVIxqpDddDWJyKHLUH2v58.YQpZ.kl1CSE.Be os3n_JXosD3wM8V6I9rmIOhH0CumxOhlGLhf8CAQXA4i4HVB4Rkl7xKmpCp7Hs3rtBFasLNe1cQY uYnKSgsKoQJtd_w5p8ttcxGMq5yLw4sQObP0Bstw4FLcx3ErfsV3zCNI_A.xF861VSvS455lAONo DQVnjQUmJNTYGYMbPUm9vLJsyoJK9vlif8vmYI2eziyHZw4XcCz5rVepth_C8f8ytTiPS.p4ghH_ Wq2zk5vO9gaM4e7RiQ0zw6Kwj5AWDeONGaJ_L533BmZCiMhKflC6TBz.8Nwq55MmMVq0xFho_tjK ceDJ.tM4_u.ZrNhMN4zQAGv_XPzADiK.Z1pxp1BQt2vsci0WhQel88G.yPVB8vj1y1TNhsnDJBO4 S6IevkYXIv8ZRL1.eFzC5I3C8C1hW8kQVEXz_7yIWsxIpfuPLOTJiBOzN3wBYjOmLXRFm9SLbyBf d6sbJlJyJgNmTiEHG4cBiZ0dHzQfeN5KMFxGtBbeHjito9lyZgX2nJMXys0.farB3u8nx1iHXbZq 6zq6LwVy3SQPmGPChG6Qbq5W.r1LLAVmrr9yQFg2BoHB2Ywx_mJq..SF07mYdhGWXeS8L9gylOgN 4CuWcREh9kpOhzZF7i1OCw6KtoHNnEMGS3Il4mgbqUCdzt5hjz2J17KTZDIVKZJEftwH4E6IHYMC cn6j6Kem68NjHi52C4r8sJBbZNfReNHXGnxrU40ax68imRkNTPYluPI6PzTYDSl.xXC8.lg.qSIv as_Ao5g5AaMcE08O1BHSbfld2Y4Gyb0ftRwPqYKvePjJguKoznDE6Y9sa1THaaWefPIBgrbGBILY CCpWKN1mMa7pnp7Rb_dr4FfB7kSW94miQD6XL4xHUfrjs6aqPBqDu_kMRU_Wss_Ovr24WtXf7Cwb 89LQm_gtJ1V_OSAd4sEKEBIQ3akysZBtTQmUnSRW_FJduYXopFKqkyJe9JYJiJJCn9vObsXnAzaZ EeHXHpO8TFn1S9Ba5XemoWcw7UAvxCIuTD0O9ofrXH9QSU4KnWcvuH.dPprdNdHQ6JWlilqJNvGN G7rq2.DDqg_vyCfHwvQOfGMqBesNUq7ZgDYeYw5W5Nanz9k_bt.W9e6JugGEuTlIqo2H01wcyegJ PjzhcvONn_tt.gHJb3AMS3lc0CdtrcXwcIB06AyLbEvwovKg9bxL6n.pXYIjPq0SGzgao4Kn8J5X zZhWlt.SGi9lkf1taYd5FgRBNAWmHuk4Zs3rc_YBRVDh2V7PmOpo1gkwRoxdCu_h5xoH9XCXb3DO 0x98BMlRB.jvcY1LyEI3fq1YoYQ2Vkf7BHmqf3SIkdNd0rwqx74ChXsLxUSi6lWrPJC_P7rTiNdN jVHHC1yPMRgkuV7AyHnImZ7bMnvmC.BPqjIfqb.ssuYc7RTgj__Gb8fGDMnFc94VHvaMuOaKY.P6 Y._n.XkXUON3wqqQSGBV8xEPGZqDIhaG5XQaEBwKz8b5WR.fRAnhx0OMvcNwaSr3.Qk.wRyytTb_ a09.nTdZvEt68vy43lUakEm69k4mW2MfjCp5l03bosNpUsvmuvIyf6L3vi1SRgObtTqAat4HwjBO LuDIUcbAZux5FQdgsbhf4WIIabiL.OgpYCQbhL4sGgAf12e3XmT7UrP7d1QwEBQlqaykrMWGBbGe 4HehYKWQjV8kxn_RZhTkyigbW0GibYD0lypTt8s8x6yJzhypTn8lHigx65jOS6u5Pp9gsACoeEVT PdCyBNtUHYHMy3dS4Tb_D3HyHxKfunu89vEtNuRE8eXfsjnPUsiolF8tW08M- X-Sonic-MF: X-Sonic-ID: 1efa2e4c-8b3b-4834-af09-d8e7be927857 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 23:28:52 +0000 Received: by hermes--production-gq1-799bb7c8cf-wncxc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8cba7a8418349235ec2d87935350c7c3; Sat, 27 Jul 2024 23:28:51 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Files not deleted via update procedure: rescue/gbde usr/include/machine/fiq.h usr/lib/include/machine/fiq.h usr/share/man/man4/CAM.4.gz Date: Sat, 27 Jul 2024 16:28:40 -0700 References: <79733ECA-6700-467D-BA4D-CB33540D2F62@yahoo.com> To: Current FreeBSD In-Reply-To: <79733ECA-6700-467D-BA4D-CB33540D2F62@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.65 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.35)[0.351]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4WWgml2Thqz4Lcy On Jul 27, 2024, at 16:07, Mark Millard wrote: > The following old files were in the historically incrementally > updated directory tree but not in the installation to an empty > directory tree (checked via diff -rq): >=20 > /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde > /usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h > /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/include/machine/fiq.h > /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz That was an armv7 context. For comparison/contrast, aarch64 had: /usr/obj/DESTDIRs/main-CA76-poud/rescue/gbde = /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/cddl/usr.sbin/dtr= ace/amd64/kinst/ = /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/lib/libc/ssp/h_ra= w.debug /usr/obj/DESTDIRs/main-CA76-poud/usr/share/examples/IPv6/USAGE /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/recvmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/sendmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/CAM.4.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/geom_map.4.gz = /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/cddl/usr.sbin/dtrace/amd64/kins= t/ /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/lib/libc/ssp/h_raw =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jul 28 08:32:48 2024 X-Original-To: freebsd-current@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 4WWvrg2RmVz5Rl6n for ; Sun, 28 Jul 2024 08:33:07 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWvrd0v49z45JD for ; Sun, 28 Jul 2024 08:33:04 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.de header.s=s31663417 header.b=X4iPg6Eq; dmarc=pass (policy=quarantine) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.17.21 as permitted sender) smtp.mailfrom=garyj@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1722155582; x=1722760382; i=garyj@gmx.de; bh=B/wAn2nzB2Uv42dv7pdVXvuNIC6vR8UBEMV/KButJ1c=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:In-Reply-To: References:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=X4iPg6Eq/C8SSejLLT7c1diafgwyg3x93dgQfM5uZoOxUpFjPln8kSRED1Wcwtk5 FsqQRkUL/Tm80BPd9TMk2Quj0IzYbnunm0Lf3PxPDa4z53OvI9W6ZYwhtS7hrtDz1 im4pnxjUe9cEsFIiUvG5gFdIExtJnESOZXGDRle9LUZ8sCmlv0llTBfEyjASkpJpF FvfyGKYULL/wkiaHixIV0jRg+E5OivCvh3+TaXPeMvUJ5PPV5tFxNEF6UKkUXUaut ThnbJroMY8Pcd4SyAhZQKt3R6PyZGnD4hq6UlFAFdeY30eOWVRWn9uAbIsucdKdZL fymHq/KObZ+PkVLy8Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.2.58.134]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MD9T7-1sPV0h0cZF-000j1z for ; Sun, 28 Jul 2024 10:33:02 +0200 Date: Sun, 28 Jul 2024 08:32:48 +0000 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: <20240728103248.4266cd7e@ernst.home> In-Reply-To: References: <20240727170122.675f6bfe@ernst.home> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.20.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ZSD/xAskHm36mWQOB+uXH4mtWgjFFEoW1LJVHX3818t5+VL4sb6 3yeHcuypOtY6FyeDFl/MDWrgriDsbDH5R/Cc8en+3bAyaGGM4JmPiDXnjVVkQEXK9w7A7y9 ybIel5U7vCuVad2vZDURUv4Lk+StNyb9FnXr44TrMWF26wAxzopbRBYSKIBEdl5A7UP/yHg moDlBxkkUf1TZP4yZ9blA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:KiSJgZovAXM=;UJ7PE5G/FBBcL1mvBydHNh8un7T hI64oixZrusUlfo6FRB+Ns4g2CZO5z5+qO205nCrgcHYFsqae0uC0gmR5IEkGCSmzfwfKJEk4 e+3q52/7F7B+5LqgmnyLYC0RCTW5jZgSx+QfFK+HEwWbsYZnOC6b4MoJ9gLo+rjP7+hTkaiYr NvTnkNJyBV+U2B98YaweIl7etqWOnx7VBfam0nfaLZbpxMSYaNyQX2+UYDE6NNL14kBTmZl6W qWC0C9pJHcBthj3Zb+Z8o832jio21rukCCfsoombYJPlx82hZU2liWeXBM+35y82cDCKHjeVO m02IuHzbJ3Q4kXFCbnCc1V1z2PER940tCVMUwaqfM/Z4p42dKcFRnTwr6CLpjuqV9QayIjFaN cXa3Y7II/fjcTENXpcVid6uOW75b+Gc7Sqnl3ELrvyg+hhJ0aUXEWoWQw8JbOJQqgFnuhQwib +pLtBV6g5q0y5kDlO+Sl1Y6LKQlKtD5NEepQp7ACo6kNWvnY36fgWeHBkBCVFDJ4772NAy72V Ef7cqOmOhg6VaS6MAsJa8xWZDPCac+Z5S3aVK0XuGJdIfNCIYwnzjM9gwZ+xZnP+ixIzSChAM 8aZl3hOGtwXDzinO3LLP1FokbPyZ7gvy+xvVzk8uMc4T6p7eesyTwhRxREtqtjhoRXK+S9Hrk hXg6CAWt8Oy29r1/XFskPZuRe+pf/uOtF7bpodm90Db8hJ715kr6Q8Ng+E15JVjnd7fn65vvy 1Nrbm8qXkqaDjH59W4pHwPqrUemxrj2CXZADy9QuOYBqIis6TBLdZU4++9IePCu0Apu5tPLb7 dnvOWHOoTpfolriQVBkMGk6w== X-Spamd-Bar: / X-Spamd-Result: default: False [-0.60 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.998]; NEURAL_HAM_MEDIUM(-0.78)[-0.776]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,quarantine]; NEURAL_SPAM_SHORT(0.28)[0.282]; R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417]; R_SPF_ALLOW(-0.20)[+a:mout.gmx.net]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.21:from]; RWL_MAILSPIKE_GOOD(-0.10)[212.227.17.21:from]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[gmx.de]; FREEMAIL_ENVFROM(0.00)[gmx.de]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmx.de:+]; FREEMAIL_REPLYTO(0.00)[gmx.de]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; HAS_REPLYTO(0.00)[garyj@gmx.de] X-Rspamd-Queue-Id: 4WWvrd0v49z45JD On Sat, 27 Jul 2024 19:31:37 +0100 void wrote: > On Sat, Jul 27, 2024 at 03:01:22PM +0000, Gary Jennejohn wrote: > > >filemon is not a device, it's an option. So you can't have "device > >filemon" in your kernel config file. > > > >I compile it with makeoptions MODULES_OVERRIDE=3D"filemon ..." in my > >kernel config file. > > What's the actual line in your kernel config file please? > makeoptions MODULES_OVERRIDE=3D"cpuctl filemon aesni vesa amdsmn amdte= mp" These are the only modules under /usr/src which I use, so I limit building modules using MODULES_OVERRIDE. > >I also load it from /boot/loader.conf using filemon_load=3D"YES" > > Why do you do both? (I presume both as you're saying you 'also load') > Because filemon.ko has to be loaded. But you're right, device filemon works in my kernel config file. I added device filemon (and removed it from MODULES_OVERRIDE) and my kernel compiled successfully. I removed filemon_load=3D"YES" from /boot/loader.conf and booted the new kernel. kldstat -v showed that filemon was in the kernel. So I guess I misunderstood what optional means in /sys/conf/files:dev/filemon/filemon.c optional filemon =2D- Gary Jennejohn From nobody Sun Jul 28 12:57:40 2024 X-Original-To: freebsd-current@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 4WX1k14SLTz5S7lM; Sun, 28 Jul 2024 12:57:45 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com [103.168.172.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WX1k03V1gz4S0g; Sun, 28 Jul 2024 12:57:44 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=TYVoeyGI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="GlU+p3c/"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.146 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id DDAFE138019C; Sun, 28 Jul 2024 08:57:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 28 Jul 2024 08:57:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1722171462; x=1722257862; bh=1uP9zxPi0Xf9dqNkOfgfE1EDW5mCei1k +c4e0LMAokg=; b=TYVoeyGI+ouuKWtJYKUdxHhE83NjwPRjG7RvMTZjiPAuqXQG rnA8pnrPl3RvhKLG7d+IJdgWkf7fM61MY2IJSx+24bQvPnuRa6J4OnxlFIKMyyKE lp/rYXy5Mw0xgCeppZdn9TxA0Iv8E/bAlIBnUhojwK8oETR36usvIRd/g025CKG8 uIIhNtWB4I2etSIu6k1zsMfQss2jbO+iVTOClx6oYJvNPDKIbPuuXwr6dQnjsWtE mSnYS/4uaqLnGb7pxpCpfcGCuzmpxXWPKF/KJWWt84skWP4QyXekJyC94RRkhoFq LW5hi34e46vHxXnwt5WBNlFKdaLV/qOjZNd67A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1722171462; x=1722257862; bh=1uP9zxPi0Xf9dqNkOfgfE1EDW5mCei1k+c4 e0LMAokg=; b=GlU+p3c/VPhmkwfo4NIE7usSFyA6bbDMv4MoQXGg3UCJojxzbVu sccIOR/3d3mR8K2xfmlGk2EuDuvVFiqntg26J4sw0DRK0w030cP/1t/XnZppESm7 9+3jJiqx7EaMt0jwfzPST6UtPcti13msaa6BLKfiBIyPWpGyImozX9m2OSSTgosc +HYQw4pdq+ImFFC/V5A4wwI57IYAl38Dmgj1di0d9GGq+Ft5dD3skSvnvD3aV5BK Q84449bm5cAe4Vg/oM51cI3LLPSkCf7vXICb3flaSpIKjqd9HcsxMtpC1iktXT0e 7UMampr7MONcV+j7q7FjdgWzD+Obtt6P4sA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjedtgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepueekjefhleduiedttefhffejieeugfehtdefleevgfduieeuvedviedujefhtd elnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 28 Jul 2024 08:57:41 -0400 (EDT) Date: Sun, 28 Jul 2024 13:57:40 +0100 From: void To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: rebuilding with zfs-on-root on arm64 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.51 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.911]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.146:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WX1k03V1gz4S0g Hi, What/where are the full instructions for installing new kernel and world in a rpi4/arm64 zfs context? I'm looking for instructions that would account for u-boot, zfs and zfs encryption. -- From nobody Sun Jul 28 13:03:00 2024 X-Original-To: freebsd-current@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 4WX1r873CHz5S8Kr for ; Sun, 28 Jul 2024 13:03:04 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh7-smtp.messagingengine.com (fhigh7-smtp.messagingengine.com [103.168.172.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WX1r824fLz4TKl for ; Sun, 28 Jul 2024 13:03:04 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=pvTf9tcY; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=md5CQUKe; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.158 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id B09B9114014E for ; Sun, 28 Jul 2024 09:03:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 28 Jul 2024 09:03:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1722171782; x=1722258182; bh=9mr7v/XhkK 6GWS4AjsCiQnkt27naSq9smdM/ntDp+o0=; b=pvTf9tcYZJT4FAq4pt7WATBUkv f33DuJNkuayWW9HLPlSHFgzlPmCn/zr3VDhMV7AkwrqX9k7a3WcRz+X2RoaS5RV0 XudbrnZCjbFzvodCbXmoU2yIqYwqDJKx1K7FGZoaoJd36M8FnzeEE75xD2ZDdz50 lqYe1LZ1W15+2NpHFekdaVupzwMDMEtylPAaXnB8RW4mwrdaj27sT1m9iEO+96JT Rs1NSxPKvO/HPAn37usuKdFm1W/Qew15kD30sOPvkiLDLX3RV5ns3gFp5MH6WZlV +olPTq9zOHrm/frR/5T/M7SPUPGSWO0PTfShmHr+KWoqRKkiyVbt0X/EkZdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1722171782; x=1722258182; bh=9mr7v/XhkK6GWS4AjsCiQnkt27na Sq9smdM/ntDp+o0=; b=md5CQUKejfX7PJ+Eh6H+eKFXjP3xH8H0VuV8XWIQpJbv W3Wh7w3tgWPz7wQ1VvzVwRP/DQJwbxW3Bz+CzA8+yWp4JMQwYmcX+xAycnVoen3P mgTwCdtI1JwS68/9EzNu5RM10G/XQ7lY32nqrGxCkzYe71z0MWI6gOhfgmTeLD5a z5sHyuAXn3jN/xdXz8YDJ1QZWHomCRcphvKUqH4yFRq8dcQIepXMHdb6+2xBg/P9 H9w2d/i6fqcxC+CZ8g3v7cudoqdOTTKa+ZHulEjQtDDM0zIV+zQchArBtvhFAS5b IvUey0ufkbjna8/loz/f01UxeDENFPDbVRdtUbwQbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjedtgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutdehhe fgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 28 Jul 2024 09:03:02 -0400 (EDT) Date: Sun, 28 Jul 2024 14:03:00 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: filemon Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.77 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.972]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.158:from]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.158:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WX1r824fLz4TKl How would I go about remedying the issue that usage/examples are not present in manpages for either the device line in kernel config or filemon.ko ? --