From nobody Fri Nov 21 03:34:28 2025 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 4dCLQs6BHcz6GQMZ; Fri, 21 Nov 2025 03:33:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCLQr2LjDz3TFH; Fri, 21 Nov 2025 03:33:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AL3YT4J068575 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 20 Nov 2025 19:34:30 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AL3YSDO068574; Thu, 20 Nov 2025 19:34:28 -0800 (PST) (envelope-from fbsd) Date: Thu, 20 Nov 2025 19:34:28 -0800 From: bob prohaska To: Warner Losh Cc: "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> 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-Spamd-Bar: / X-Spamd-Result: default: False [0.95 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.67)[0.669]; NEURAL_HAM_SHORT(-0.62)[-0.621]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4dCLQr2LjDz3TFH On Sun, Nov 16, 2025 at 10:51:01AM -0700, Warner Losh wrote: > Maybe try main with the following patch. Adrian noticed the TLS mismatch. I > don't think it will matter, but TLS thread model stuff always gives me a > big headache. If the following fails to apply, just copy the > JEMALLOC_TLS_MODEL line from i386 to arm. The default changed elsewhere, > but this wasn't updated here. > > Warner > > diff --git > a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > index 34c86271ab2e..bd6850ebd95f 100644 > --- a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > +++ b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > @@ -26,10 +26,11 @@ > #undef LG_SIZEOF_LONG > #undef LG_SIZEOF_INTMAX_T > > +#define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > + > #ifdef __i386__ > # define LG_VADDR 32 > # define LG_SIZEOF_PTR 2 > -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > #endif > #ifdef __ia64__ > # define LG_VADDR 64 > @@ -38,7 +39,6 @@ > #ifdef __sparc64__ > # define LG_VADDR 64 > # define LG_SIZEOF_PTR 3 > -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > #endif > #ifdef __amd64__ > #ifdef _USE_LG_VADDR_WIDE > @@ -47,7 +47,6 @@ > # define LG_VADDR 48 > #endif > # define LG_SIZEOF_PTR 3 > -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > #endif > #ifdef __arm__ > # define LG_VADDR 32 > @@ -69,11 +68,9 @@ > #ifdef __powerpc64__ > # define LG_VADDR 64 > # define LG_SIZEOF_PTR 3 > -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > #elif defined(__powerpc__) > # define LG_VADDR 32 > # define LG_SIZEOF_PTR 2 > -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) > #endif > #ifdef __riscv > # define LG_VADDR 48 > > > Is it still advisable to apply this patch? I'm guessing it'll get committed on its own in due course. Its present lack seems harmless. One of the Pi2's has now completed two complete cycles of self-hosting, with no problems of any kind. No silent hangs, no assertion failures. The double-cleandir rebuild also worked with no difficulty. It even seems to boot a little faster 8-) More seriously, is the path forward even hinted at yet? It seems jemalloc is getting considerable attention but I'm not reading reports of 'Eureka!'. Am I right in thinking git will preserve the reversion when pulling other updates? Does anything special need to be done if an updated jemalloc is committed to -current? Many thanks to all who've helped! bob prohaska