From nobody Mon Dec 22 03:21:42 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 4dZNj43yYNz6M47C for ; Mon, 22 Dec 2025 03:21:44 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4dZNj329ttz3Z5J for ; Mon, 22 Dec 2025 03:21:43 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 97387 invoked from network); 22 Dec 2025 03:21:42 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 22 Dec 2025 03:21:42 -0000 Date: Sun, 21 Dec 2025 19:21:42 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2025-12-15 to 2025-12-21 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 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; NEURAL_HAM_SHORT(-0.61)[-0.611]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4dZNj329ttz3Z5J Hi all, I'm happy to announce FreeBSD git weekly for 2025-12-15 -- 2025-12-21: https://freebsd-git-weekly.tarsnap.net/2025-12-15.html It's a list of the 134 commits in that week, split into categories. Highlighted commits: - aq(4): Add man page - librt/mq_getfd_np.3: Initial manual page - usr.bin: Remove intrinsic utilities "Highlighted" commits are selected automatically if a commit modifies UPDATING, or if the commit message contains a "Relnotes:" line. If you think that another commit should be highlighted, let me know and I'm happy to make it so. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Mon Dec 22 03:25:00 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 4dZNmz2npYz6M4cc for ; Mon, 22 Dec 2025 03:25:07 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZNmz2GRWz3bS9; Mon, 22 Dec 2025 03:25:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766373907; 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=QK3QDMKL/29gaMwzVuI4l12DVbu5Ye+3Cs5nqIo66dk=; b=iwiuNcMPquz1zyz9DdA6p2JXR4SgZ7jHiqAQkjxIKrrbMIfDNwY2shidSxrJNAvCjhhARf zKEVETbn94tNUVI5Oy0R6aF+rzEuG7hOhCtCdmDSdA04HVIp9KMSZHOjMDYXxCFNww9VTc qSKaiEn38UKf0FkqiuTVg+vveml1lc89dMmyE2y6CxarcdeRCTSow6x85KJZdZ7KbJ06Ub 4Np+x5izVBZBcUeyZfIH9VOY0XmFpN1dO957FqG44ZhAJgQwA/epAYsMW51k4Zgs4Iu/yu rmHOQwr/Kv6tUIGwFjOPWd2pa42iy6n4IK3TGPnXJn87SSZjziviG0fvlzz5eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766373907; 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=QK3QDMKL/29gaMwzVuI4l12DVbu5Ye+3Cs5nqIo66dk=; b=tkw75copnLD88YHIWXU6yodhrVPf2KTrp2/lJDyD1R2JqU4t4RdBFotNJJKjgPRzop7Z5m ucQfICzFxutKlZZ29uqXnUacXa/3czt8HABuW4o06YFXq+XsEnCCnWtd3QoqVYoQInwFUt R3YH5O3cv/o3DYYXNguPrGQkt13TLBhLxdkKCAwbgPyDzJzlVupnYM0imgYC+x2YWA1lxq 4XEzRYTHsZOlWsx7q6ZWRshf0aeeykLZF1Plj9qWgRBf7fKtDQyXZ8zgWTx3+EQNCDZET+ PiYpO8DAVH3+i/ngWDdYjNDOOYEQX6j1rfnS/PpHCjaWe3sffRIdFYNHrrZZYg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766373907; a=rsa-sha256; cv=none; b=nWwOd3J1ifCfd4uMEVWNC+z6lwB9rhLrTsu6B7ggCfQmsRY2exQe1FahegXV+Umr4myuys P0JsnH9Vn909W+zCn9qmradiOICRoaJ6BySjrx6DP4g2qpMbVUlhK5j3pD852iT3JNgAaJ jKwIGx1q+TXLJbMMMvtbwwUvOToq5ZcXh44cnOYaEEMhyfim8vDR8x4Sms+H9Lw9iTnJJv out2puyApZL+qxP3mveNMWAMTxzxuyitbVubMNXyZMeMLK6eez5uMmffNiAbHZ9ciAcfqc IkmkcQPzmpIbG4s2y0FJGW1/cUgftGoGPkqsdkrGMPar9xA55RYNTRvtOHl86A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4dZNmy2vrfzqC5; Mon, 22 Dec 2025 03:25:06 +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.10\)) Subject: Re: FYI: Prime X670-P WiFI built in Ethernet detected and basically operational on main [so: 16] From: Zhenlei Huang In-Reply-To: <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70@yahoo.com> Date: Mon, 22 Dec 2025 11:25:00 +0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <97EAF012-BB2A-422C-9F2E-A428E88F3826@FreeBSD.org> References: <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70.ref@yahoo.com> <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3696.120.41.1.10) > On Dec 22, 2025, at 7:37 AM, Mark Millard wrote: >=20 > After my kernel update (pkgbase style) today I noticed that the = built-in > ethernet was detected. After the overall update, trying it for some = basic > operation looks to be working. (My context is normally limited to = basic > operation.) Up to this point I'd been using a USB3 dongle for Ethernet > for this system. >=20 > Extracted from "dmesg -a" output: >=20 > Autoloading module: if_rge > rge0: port 0xe000-0xe0ff mem = 0xdf400000-0xdf40ffff,0xdf410000-0xdf413fff at device 0.0 on pci8 > rge0: Ethernet address: REDACTED > rge0: no link .... > rge0: link state changed to DOWN > rge0: link state changed to UP > Starting Network: lo0 rge0. > rge0: flags=3D1008843 = metric 0 mtu 1500 > options=3D9b > ether REDACTED > inet REDACTED netmask 0xffffff00 broadcast REDACTED > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=3D29 > . . . > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20 The if_rge(4) was committed in main recently [1]. 1. 4bf8ce037dc8 if_rge: initial import of if_rge driver from OpenBSD=20 Best regards, Zhenlei From nobody Mon Dec 22 04:42:56 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 4dZQW05xyrz6MC3C for ; Mon, 22 Dec 2025 04:43:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 4dZQW040byz3kwj for ; Mon, 22 Dec 2025 04:43:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-4eda77e2358so29140121cf.1 for ; Sun, 21 Dec 2025 20:43:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766378587; x=1766983387; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uDvwXhjCkOWt+y1YLEtKiJOmifjoO1NLOP50f/f1X9c=; b=Umt+ejhRkBI+Mzl28Btw40ksLE5/bVL+zLPbDIpWlvZryj86PKvl2IQ2pSCgDFwg85 5NGTG+Rhh5WdChuHKBaYGMr4i5tdaA7jsd9R05LdJb94Rlwh1t7Ijfubs4UWUI7XPWn7 OdjQJZWTfuviIpSqnnUbbSLFbnwZJ77nmsW1B2TctdfemWSW4cApe5dUX93WkjJ/FVZ5 mPo4bKjgnWQ4fUiVP2NMoOK3SALWllqRa2KiE6UoaCikOkAQQhoXLBckIKAFktnvI+rv xJAAqIY+tfXkwR+J+VOwEbuHPIlLQGROTDNOS6BKHH7L1XudPRdRP1tt8s/w40FEUqGr moPA== X-Gm-Message-State: AOJu0YyjVgekK0krGS5vEFsrqbnqex0aP8rp0ZXtPnPeTE2T6NVHv0AB plWjjJiEnsKZrer2g5w62/jGGwvNxVGEYSuTTtnJvXXbrKf/mmU7m8+Va8tf1yi3xnMYz/ZluRw c9NjE9FVERiQx6FCf+CJvbBTQaif+rVyPM+dz X-Gm-Gg: AY/fxX5k0p10MYg5OZNj9awwhbEdycy35u4rjucSjWzZbDGufAJbDr5+zh2O3C5mg98 PrQ8gEFL2gMClU38sd7ghENPR23N6nL+X5wFHQqeBP1Dvtej5Df64qOyC7AFmAyA8KPlr1mEbBh L/LtgYCZNwfGVzTf9aZnqs6e+RBDlXH++lUMUDTGVDgDdiuQtr8PK0Ta6Q5t+kZyfwb4+gSLzoN VSvdCh0BulGS8gViIi9srMgeMgfGqMbEY/DlyQrMa71vMMK6J63ZcOMOR2lbKVohuPCMdB8aTSC zjDMnbRc2nPxY6CFLfzRm4qurNLdRzs2EjAlGUieHlzitCZNCQAgnu03/J7uHeo/27is488= X-Google-Smtp-Source: AGHT+IGIOFfJI7zFbcd3Wy4+3DB7eYa0puym6Y+vu8hfyxJSrTqCrkhT5gT/avg6BMeyIlL+tKOxPiJCg1GfDeLEj6E= X-Received: by 2002:ac8:5ccf:0:b0:4ed:bb39:9a67 with SMTP id d75a77b69052e-4f4abd9c6aemr158889121cf.60.1766378587488; Sun, 21 Dec 2025 20:43:07 -0800 (PST) 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: <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70.ref@yahoo.com> <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70@yahoo.com> In-Reply-To: <24C46BFA-DAD6-4C79-AAE9-19193D7C1D70@yahoo.com> From: Adrian Chadd Date: Sun, 21 Dec 2025 20:42:56 -0800 X-Gm-Features: AQt7F2rIazGLMasG1QQ5leDsVYnyiXx9iB8zjv_4Lj6-bklyuODWgAvvaywkY5A Message-ID: Subject: Re: FYI: Prime X670-P WiFI built in Ethernet detected and basically operational on main [so: 16] To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dZQW040byz3kwj On Sun, 21 Dec 2025 at 15:38, Mark Millard wrote: > > After my kernel update (pkgbase style) today I noticed that the built-in > ethernet was detected. After the overall update, trying it for some basic > operation looks to be working. (My context is normally limited to basic > operation.) Up to this point I'd been using a USB3 dongle for Ethernet > for this system. > > Extracted from "dmesg -a" output: > > Autoloading module: if_rge > rge0: port 0xe000-0xe0ff mem 0xdf400000-0xdf40ffff,0xdf410000-0xdf413fff at device 0.0 on pci8 > rge0: Ethernet address: REDACTED > rge0: no link .... > rge0: link state changed to DOWN > rge0: link state changed to UP > Starting Network: lo0 rge0. > rge0: flags=1008843 metric 0 mtu 1500 > options=9b > ether REDACTED > inet REDACTED netmask 0xffffff00 broadcast REDACTED > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > . . . Yay! > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto Yup as you reported in the follow-up email; that's not for if_rge but a realtek PHY for an earlier device (your USB dongle.) I'm glad it works! Please do let me know if you experience any hiccups. My goal is to make sure this is as bulletproof as we can make it and that i share any fixes with the OpenBSD driver maintainer (Kevin Lo.) -adrian From nobody Mon Dec 22 09:00:17 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 4dZXCn0tr8z6Kf5d; Mon, 22 Dec 2025 09:00:21 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZXCn0CFLz47r7; Mon, 22 Dec 2025 09:00:21 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766394021; 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=ttwMHC4i9u/sCRM1/0ECN9mqPW4hbi+A/N/yr57kCkA=; b=oYs6FE6JTe0OBHl5ivTeXUkS1ICE1dpFBNElRu5OfprNGTKJW+vuMiLnvJgkbsQKqAjlNR 0Y7a7soagp6KkrsBIHmoWQ5ivzz/pip1ejx+3W8uJMTp+27cZ7BSd3zcxk6F7qsoBlZ1M0 ZsgndppPsWSloQP+ETR/4WolTTUjns+SO9NegOnVJNusOP8uDqM9kQww2QuD7sY4UYh66P x4gT8ItD8gLsIwSbWeWPDHu7Tow8bEpZ7IqVaAnoJqYtkhHsHlvwg0emN/HkLiHUTER4uL O2UR9XseZJOtoLt9hykRPKHH7X5NZRjlRJNv8TDodxfgHkyACdHCLVotLAxILQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766394021; 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=ttwMHC4i9u/sCRM1/0ECN9mqPW4hbi+A/N/yr57kCkA=; b=YPNVFdIyOh5OBompSqWJimgW27CfVfJBqagFW2mEGKfYZ/T0NzEqp2KLz6BWT8SSLi2+Vn pgLgJ5qoN7mV7o6dxtOepDUS+m3ZS68CVwoIOnF4NqK/c3ymx5dhiJuJMJssDFFBCS1E0N NWA9Qix8YanaBL75HhrLeMfxE6GDlw6q5hJuZFNZS7KB6TvNiCOLFkKnomGx+7pZ707nlS /GgA2NEcGadt9QN+GeXkTWh4iDpJMEAi0PIaNxJ80jGgTvjlIpfHB3/uvpXiIEWkqQ+n6l 9v8I2d3fVEEOAVKZhx/o0Z3esKIO3p27qZirUHYT+GEed3q7S/GmOyWTIiidGw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766394021; a=rsa-sha256; cv=none; b=FaCEGK6ofJE1OqowYbNBQB/Wd4kB0OF+kKQ8SNLdUtgfG9IubLlfA6vIMtDtehUFgdwLYR lqeZSHjnxF1fjQ6cBa0VbEfo3gUb43NcfwNvO/6dx+IDCmHcOMtf5V2gc+pFleNVfRwSD1 P+MdsHlQbT7U8bjpzFxtVdE/FghX/fT7g4PuLVbw71vh11Y3JrPhUferBHrisYGpFUOCt/ FSda3THqPNAad4SKY8myykd87JJF3+9P3sShCw+ngI4t0o9rzklZXa1gmZxt/ZxgHVtBtg 5At1J5xqSD/g0hEz34BVm5CXK4/mivaNrqD6tvEJs3h2nc8cb4h55W6iri7tEg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4dZXCm45QGz10ct; Mon, 22 Dec 2025 09:00:20 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 22 Dec 2025 01:00:17 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: December 2025 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 December 2025 stabilization week started with FreeBSD/main at main-n282678-88b04633c29e, which was tagged as main-stabweek-2025-Dec. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. The tag main-stabweek-2025-Dec has been published at Gleb Smirnoff's github repo. To connect this repo as an additional remote you need to run: git remote add glebius https://github.com/glebius/FreeBSD Once remote is configured, to checkout the tag run: git fetch glebius --tags git checkout main-stabweek-2025-Dec If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout 88b04633c29e Developers are encouraged to avoid pushing new features to FreeBSD/main during the stabilization week, 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 Dec 22 16:58:13 2025 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 4dZkqX41S3z6LTLD for ; Mon, 22 Dec 2025 16:58:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 4dZkqW5tmQz3fRG for ; Mon, 22 Dec 2025 16:58:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=fQmAdfhe; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102a) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-34c565b888dso4652263a91.0 for ; Mon, 22 Dec 2025 08:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1766422704; x=1767027504; 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=0iOZgLrIpRV7nEFZ6G7m6XorCQ/2vpOIy7C2mkOx08A=; b=fQmAdfhedKGdQ0bIoYAIrCWMj6Cm4f4JjWXA8INXRXXbneAP22LQeOCGxdet2OE0Qv YJIk8oofU4e7FHqfaaz6mGFz+ox72pu4TJtWgoikBWCHRpjGyRtOjYbkmmabv3t6A97e IELRvk8epO12ZnhID/waI9ZpSMEgk5HcCPLjbFybFHkPD09+SfWRGRz9yyqPDWQ4k3AZ bSGLLdSSHUYLDxOncBiPXJu4ErJg8Vtq5h7KfZEpORRE22MQrHzatXjSuqY3A05fE/1e 80W88TmZv/zhDnldJepgjTEVmg/0UVAcOO7HncJm/JlmU1qsbtU8L3PXmYUQ9lIeOVrp m79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766422704; x=1767027504; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0iOZgLrIpRV7nEFZ6G7m6XorCQ/2vpOIy7C2mkOx08A=; b=PVjRO0CuqlbyCpU2xBV9vZJYm6m8pZ7tnI3ztzx5FfqqcneF97yZfUCwdRFJ8B7sMc ZGdl3g6C6cugEiQkIinCF7o+7+xGUaxbwD8l7NS7SJ1uv8xwdWYtNWXE2cisHPDD+RVJ MHWzOmE01i6JjM8MRjZsaCqtafwn8lIFclzTwPKpO9DlS/ooii0nEAI4P/6NX4bdhu7O r+nzulnMAEHFjTpXET/+bciGO7VZ+S/HWiqeMZ4HtYSj5fErqohh9BzYp1t30PV6puZN MbR40+spj+QK5EnfA03HjjpB/AIHAv6P1U1yTxHiiq0H1R3jHl46BKYulyCrWRKBJzTr FIjw== X-Gm-Message-State: AOJu0YzpTtkZ36QjuIoipmXu3HYZKEmLVEMlrO9mYx70ehheBoNDBa8y TyQ4wzQNr62N+ngi4sPzuFYzveZY0LLvbO+G7RSc9B0ncP3/Khwl07WDbr6fCyKbrjSJ8zwVnCK mQVzEPQKuVxAtUDW1xIalU1sL54aIeUcuja/Y4m+iPSuUFJuL9XM22cA= X-Gm-Gg: AY/fxX50DHSoRt7E5/RbwMSrTROuu00T0lCK+OOtTmN/JTSEN+OJdvnhC1XAiEt9HFc FAiSr/kzr/caqUfYyOz2LnGgvIS8TaIe8Y6pIpDRi8gFdGxERql+fZ9NxNN6HyRdp2TMv3Fwgsw ZrYMrMY98Cb6woa9jFJtyKCMnnLt7grszFECYLMbdgux5Cqb1n9uJKBZVzN9MQiWTD0Rdq/yfR0 VUUNul/jedOf2BTnekMWbtXCUI+8ziDfzAjT4P3kP0bbJQEdLYCfo/wvcbtmozVr54H0RU= X-Google-Smtp-Source: AGHT+IF0Ixu8O5d8XsBJg5X+JvRvFbLNbl3BEXRvSEf9Q1qVf5TbPXhCJaGEM1OPnblTz/rWFStWChr5xMp5qjsPKwg= X-Received: by 2002:a17:90b:53c7:b0:34a:adf1:6781 with SMTP id 98e67ed59e1d1-34e92143b39mr9501561a91.9.1766422704320; Mon, 22 Dec 2025 08:58:24 -0800 (PST) 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: <198170948d34f4dc169e94934da82161@Leidinger.net> <89a92e0a926239e2c192dc0ff9c80d6e@Leidinger.net> In-Reply-To: <89a92e0a926239e2c192dc0ff9c80d6e@Leidinger.net> From: Warner Losh Date: Mon, 22 Dec 2025 09:58:13 -0700 X-Gm-Features: AQt7F2p1nnF6jzOxIod-rFSW22i7ahL-J7py8yhGkI76keM-fM2nOGnJZy9Dhgc Message-ID: Subject: Re: Changes in cam/nvme causes issues? To: Alexander Leidinger Cc: Current Content-Type: multipart/alternative; boundary="000000000000d0827c06468d5538" X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::102a:server fail]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4dZkqW5tmQz3fRG --000000000000d0827c06468d5538 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 21, 2025 at 8:37=E2=80=AFAM Alexander Leidinger wrote: > Am 2025-12-14 14:05, schrieb Warner Losh: > > Let's do one issue at a time. There's too much missing info. Top posting > since there's not a lot of context to this request > > > The disk died now completely, so the CRC errors are out of reach now. > > > First, let's start with pciconf -l of the nvme drive. I have a strong > idea, but need some data. > > > While already provided privately with some other data, here for the publi= c > so that people are aware that currently there is an issue with such drive= s: > nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 vendor=3D0x144d > device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801 > Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V > Yea, so far this is the only report I've received, and there's not enough data in it to reproduce it with any of the dozen NVMe drives that I have, or to spot a difference with what I know I check in the code. So if it's compiled into the kernel with cam also compiled into the kernel, I know it works. Warner > Bye, > Alexander. > > > Also, the disk report needs full logs with and without the settings that > have uncorrectable in them. I'd expect that a shorter timeout would lead = to > different behavior, but maybe that error syndrome isn't one I've seen. It > would also be helpful to know which of the times changes the behavior... > > Warner > > On Sun, Dec 14, 2025, 5:06=E2=80=AFAM Alexander Leidinger > wrote: > > Hi Warner, > > I try to update a 15-current (as of 2025-11-27-110715) to a recent 16 > (as of 2025-12-13-132815). It fails to import a pool due to a missing > nvme. I also have a broken HD in this system... to be on the safe side I > mention it. > > This is from 15-current: > ---snip--- > NAME STATE READ WRITE CKSUM > rpool DEGRADED 0 0 0 > mirror-0 DEGRADED 0 0 0 > diskid/DISK-WD-WCC4N4KLEZT7p3 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1DF9DA2p3 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R0NTp3 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1PYJ3F8p3 OFFLINE 0 0 0 > logs > diskid/DISK-493504058890547p1 ONLINE 0 0 0 > cache > diskid/DISK-493504058890547p2 ONLINE 0 0 0 > > NAME STATE READ WRITE CKSUM > space DEGRADED 0 0 0 > raidz2-0 DEGRADED 0 0 0 > diskid/DISK-WD-WCC4N4KLEZT7p4 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1DF9DA2p4 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R0NTp4 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R2TPp4 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1PYJ3F8p4 OFFLINE 0 0 0 > logs > diskid/DISK-S649NL0T819360Vp2 ONLINE 0 0 0 > cache > diskid/DISK-S649NL0T819360Vp3 ONLINE 0 0 0 > ---snip--- > > The offline marked partitions are on the same HD (the broken one). The > DISK-S649NL0T819360V device use as log and cache in the second pool > causes the issue on 16-current. > > On 16-current I get "uncorrectable parity/CRC error" messages on boot > from the broken disk. I used this to get rid of those errors: > ---snip--- > # grep kern.cam /tmp/be_mount.MhLw/boot/loader.conf > kern.cam.tur_timeout=3D"60" > kern.cam.inquiry_timeout=3D"60" > kern.cam.modesense_timeout=3D"60" > ---snip--- > > But the second pool ("space") fails to get imported. When I import it > via "zpool import -m space" it shows me that the log and cache devices > (different partitions on the same hardware) are not available. > This is the device in question as seen from 15-current: > ---snip--- > nda0: > nda0: Serial Number S649NL0T819360V > [1] nda0: nvme version 1.4 > nda0: 953869MB (1953525168 512 byte sectors) > [1] GEOM: new disk nda0 > ... > [1] pass6 at nvme0 bus 0 scbus6 target 0 lun 1 > pass6: > pass6: Serial Number S649NL0T819360V > [1] pass6: nvme version 1.4 > ---snip--- > > In case you need some info from the 15- or 16-current BE, which info do > you need? > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --000000000000d0827c06468d5538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Dec 21,= 2025 at 8:37=E2=80=AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2025-12-14 14:05, schrieb Wa= rner Losh:

Let's do one issue at=C2=A0a time. There's too mu= ch missing info. Top posting since there's=C2=A0 not a lot of context t= o this request=C2=A0
=C2=A0
The disk died now completely, so the CRC errors are out o= f reach now.
=C2=A0
First, let's start with pciconf -l of the nvme drive.= I have a strong idea, but need some data.
=C2=A0
While already provided privately with some other data, he= re for the public so that people are aware that currently there is an issue= with such drives:
nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 = vendor=3D0x144d device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801
Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V
<= /div>

Yea, so far this is the only re= port I've received, and there's not enough data in it to reproduce = it with any of the dozen NVMe drives that I have, or to spot a difference w= ith what I know I check in the code. So if it's compiled into the kerne= l with cam also compiled into the kernel, I know it works.

Warner=C2=A0
=C2=A0
=
Bye,
Alexander.
=C2=A0
Also, the disk report needs full logs with and without th= e settings that have uncorrectable in them. I'd expect that a shorter t= imeout would lead to different behavior, but maybe that error syndrome isn&= #39;t one I've seen. It would also be helpful to know which of the time= s changes the behavior...
=C2=A0
Warner

On Sun, Dec 14, 2025, 5:06=E2=80=AFAM Alexander Leidinger = <Alexander@leidinger.net> wrote:
Hi Warner,

I try to update a 15-current = (as of 2025-11-27-110715) to a recent 16
(as of 2025-12-13-132815). It = fails to import a pool due to a missing
nvme. I also have a broken HD i= n this system... to be on the safe side I
mention it.

This is fr= om 15-current:
---snip---
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NAME=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATE=C2=A0 =C2=A0 =C2=A0READ WRITE CKSUM=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rpool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D= EGRADED=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mirror-0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEGRADED= =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-WD-WCC4N4KLEZT7p3=C2= =A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 = =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-WD-W= CC4N1DF9DA2p3=C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00= =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0di= skid/DISK-WD-WX52D625R0NTp3=C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 = =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0diskid/DISK-WD-WCC4N1PYJ3F8p3=C2=A0 OFFLINE=C2=A0 =C2=A0 =C2= =A0 0=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0logs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-4935= 04058890547p1=C2=A0 =C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 = =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cache
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-493504058890547p2=C2= =A0 =C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 = =C2=A0 =C2=A00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NAME=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0STATE=C2=A0 =C2=A0 =C2=A0READ WRITE CKSUM
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0space=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DEGRADED=C2= =A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0raidz2-0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEGRADED=C2=A0 =C2= =A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-WD-WCC4N4KLEZT7p4=C2=A0 ONLINE= =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-WD-WCC4N1DF9DA2= p4=C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2= =A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-= WD-WX52D625R0NTp4=C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2= =A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0diskid/DISK-WD-WX52D625R2TPp4=C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00= =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0diskid/DISK-WD-WCC4N1PYJ3F8p4=C2=A0 OFFLINE=C2=A0 =C2= =A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0logs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DI= SK-S649NL0T819360Vp2=C2=A0 =C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 = =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ca= che
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diskid/DISK-S649NL0T819360V= p3=C2=A0 =C2=A0 ONLINE=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A00=C2= =A0 =C2=A0 =C2=A00
---snip---

The offline marked partitions are o= n the same HD (the broken one). The
DISK-S649NL0T819360V device use as = log and cache in the second pool
causes the issue on 16-current.
On 16-current I get "uncorrectable parity/CRC error" messages on= boot
from the broken disk. I used this to get rid of those errors:
= ---snip---
# grep kern.cam /tmp/be_mount.MhLw/boot/loader.conf
kern.c= am.tur_timeout=3D"60"
kern.cam.inquiry_timeout=3D"60"= ;
kern.cam.modesense_timeout=3D"60"
---snip---

But t= he second pool ("space") fails to get imported. When I import it =
via "zpool import -m space" it shows me that the log and cach= e devices
(different partitions on the same hardware) are not available= .
This is the device in question as seen from 15-current:
---snip---<= br>nda0: <Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V>
nda0: Seri= al Number S649NL0T819360V
[1] nda0: nvme version 1.4
nda0: 953869MB (= 1953525168 512 byte sectors)
[1] GEOM: new disk nda0
...
[1] pass6= at nvme0 bus 0 scbus6 target 0 lun 1
pass6: <Samsung SSD 980 1TB 2B4= QFXO7 S649NL0T819360V>
pass6: Serial Number S649NL0T819360V
[1] pa= ss6: nvme version 1.4
---snip---

In case you need some info from = the 15- or 16-current BE, which info do
you need?

Bye,
Alexan= der.

--
http://www.Leidinger.net Alexander@Leidinger= .net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org=C2=A0 =C2= =A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F31830F9F2772BF


--
http://= www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:= //www.FreeBSD.org =C2=A0 =C2=A0netchild@FreeBSD.org =C2=A0: PGP 0x8F31830F9F2772BF
--000000000000d0827c06468d5538-- From nobody Mon Dec 22 19:23:13 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 4dZp373hwCz6LRrM for ; Mon, 22 Dec 2025 19:23:47 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dZp362N0dz3rdV for ; Mon, 22 Dec 2025 19:23:46 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="E6W9/Hb/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 5871F240632; Mon, 22 Dec 2025 20:23:43 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id A9CE0240370; Mon, 22 Dec 2025 20:23:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1766431421; 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=MvIvD41pbxw+BwF8aTwhVN5FjMbebqIOKHZ6gsCqnCo=; b=E6W9/Hb/whgdabS6X4NAev0vsXTcrwNjR06iyPCGUQmrhW+gdMgDw3IEQGI+TqweyZ5Ha5 WP27Hd6dJ86ULxlsGbheoWU5M2jXUaW6jzrXGpH4SIHB2OqP27rVvT0hS5JoX98+AX/lr6 /F+vt6hkwp3LcfrTkYgZk78hV74x1x9wFywSDGa5Rqdq7lGGjFhUYSZ6C3q8KPu1AvEPwm GEPkq7A5Njw2Lk6tC0GR707hTfpcUDA4Tw5LBCoPHQMUO2K0gnS0YK8ioFkRTe8IwsvdZ/ FBkXleCMBtF5x/GQxVlIu205R0sWwN+GmvqiRdPlgbUzXhxJyaODMVmUH2udmA== Received: from thor.sb211.local (dynamic-2a02-3100-2405-3c02-021b-21ff-fe4e-8f4d.310.pool.telefonica.de [IPv6:2a02:3100:2405:3c02:21b:21ff:fe4e:8f4d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 675C4240350; Mon, 22 Dec 2025 20:23:41 +0100 (CET) Date: Mon, 22 Dec 2025 20:23:13 +0100 From: A FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: CURRENT: havock: elf_load_section: truncated ELF file Message-ID: <20251222201622.0993320f@thor.sb211.local> In-Reply-To: References: <20251220141124.1606aa7c@thor.sb211.local> <20251220233127.2ad04793@thor.sb211.local> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd16.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: multipart/signed; boundary="Sig_/eGRkODnR8Vk/K6ZF0S1.Edh"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 131793 X-Rspamd-UID: fdc69d X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.68 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.978]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; DMARC_NA(0.00)[walstatt-de.de]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dZp362N0dz3rdV --Sig_/eGRkODnR8Vk/K6ZF0S1.Edh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tage des Herren Sat, 20 Dec 2025 23:11:37 -0700 Warner Losh schrieb: > On Sat, Dec 20, 2025 at 3:31=E2=80=AFPM A FreeBSD User > wrote: >=20 > > Am Tage des Herren Sat, 20 Dec 2025 08:10:59 -0700 > > Warner Losh schrieb: > > =20 > > > On Sat, Dec 20, 2025 at 6:12=E2=80=AFAM A FreeBSD User > > > wrote: > > > =20 > > > > Hello, > > > > > > > > recently a small server running recent CURRENT with a UFS basesd sy= stem > > > > SSD (NVMe) and a data > > > > graveyard based on RAID level 5 with ZFS (attached to a Fujitsu HBA > > > > controler) gets corrupted > > > > because of "loosing" a driver - this time the system reported TWO = =20 > > drives a =20 > > > > removed froma RAID > > > > level 5 - which is like a death sentence. > > > > > > > > I guess this is a fallout of the recently changed timie parameters = to =20 > > the =20 > > > > CAM infrastructure > > > > (I can't find any notes on this in man cam, so I feel lost). > > > > =20 > > > > > > Unlikely, but you can set this in the boot loader: > > > kern.cam.tur_timeout=3D60 > > > kern.cam.inquiry_timeout=3D60 > > > kern.cam.modesense_timeout=3D60 =20 > > > > I'll check, thanks. Are these OIDs documented somewhere to be at hand j= ust > > in case? I searched > > the recent cam manpage ... > > =20 >=20 > scsi.4: > SYSCTL VARIABLES > The following variables are available as both sysctl(8) variables and > loader(8) tunables: >=20 > kern.cam.cam_srch_hi > Search above LUN 7 for SCSI3 and greater devices. >=20 > kern.cam.tur_timeout > Timeout, in ms, for the initial TESTUNITREADY command we send to > the > devices during their initial probing. Defaults to 1s. FreeBSD = 15 > and earlier set this to 60s. >=20 > kern.cam.inquiry_timeout > Timeout, in ms, for the initial INQUIRY command we send to the > devices during their initial probing. Defaults to 1s. FreeBSD = 15 > and earlier set this to 60s. >=20 > kern.cam.reportluns_timeout > Timeout, in ms, for the initial REPORTLUNS command we send to the > devices during their initial probing. Defaults to 50s. >=20 > kern.cam.modesense_timeout > Timeout, in ms, for the initial MODESENSE command we send to the > devices during their initial probing. Defaults to 1s. FreeBSD = 15 > and earlier set this to 60s. Oh, I see, thank you for the hint. oh >=20 >=20 > > > > > > and see if that works. You should see new errors on boot if his is t= he > > > issue. Can you share a dmesg? > > > > > > I kinda doubt they'd cause the issues that you've had. If disks are g= one, > > > then there'd be different errors to what you are seeing, I'd think. > > > > > > To recover, your best bet is to use a USB stick from one of the relea= se =20 > > or =20 > > > snapshots. =20 > > > > In earlier times, when "make installkernel and/or make installworld > > crashed midair, some > > binaries in the installed tree were corrupted and since I run CURRENT > > which has a tough pace > > at the moment, the USB image booting should be close to the CURRENT made > > via "make world" ... > > I assume. I did so and had some problems with the new pkg concept ... > > (working offline, is a > > problem with the install-blob.txz ...) > > =20 >=20 > Yuck. Sorry that was a source of trouble for you. >=20 >=20 > > > > > > Warner > > > > > > =20 > > > > A very desastrous side effect of this crash was the inability to re= boot > > > > the box (CURRENT pre- > > > > 16.0-CURRENT #11 master-n282659-7f39d05b67ae: Sat Dec 20 09:35:32 C= ET > > > > 2025amd64, the runtime > > > > system was from 16th or 17th of December). > > > > After several tenth of minutes I had to hadr reboot the box - with = =20 > > obvious =20 > > > > data loss on the > > > > system SSD. And here my problems start to turn into a mess. > > > > > > > > After the first initial reboot I performed a fsck -fy, rebootet and > > > > whitnessed that > > > > jails didn't come up anymore and SSHD didn't work. So I installed = =20 > > prior to =20 > > > > the crash already > > > > compiled CURRENT from /usr/src which is "master-n282659-7f39d05b67a= e" =20 > > (as =20 > > > > the sibling box which > > > > is runnig great by the way, but different CPU and smaller RAID, but= =20 > > also =20 > > > > system SSD based on > > > > UFS filesystem, same HBA. So CURRENT seem to operate in general on = =20 > > similar =20 > > > > hardware. > > > > > > > > After the second reboot with the old kernel the box in question wen= t =20 > > into =20 > > > > debugger, rebooting > > > > in single user mode and performing fsck -fy revealed a lot of repai= rs =20 > > on =20 > > > > the first partitions, > > > > /, /var, /usr. After a reboot I realized that most services now are= =20 > > broken =20 > > > > - jails do not > > > > start, sshd doesn't start and the whole system is going into multiu= ser, > > > > but seems to have > > > > serious problems. > > > > > > > > uname -a remains empty > > > > cd /usr/src; make buildworld returns immediately empty, no further = =20 > > action =20 > > > > service ldconfig start also returns complete empty on console > > > > > > > > Several onboard/base tools simply return nothing. > > > > > > > > trying "/resucue/sh" (install date indicates 20th of December, so i= t is > > > > the latest ) seems to > > > > give me the first indication of something has terribly gone wrong o= r =20 > > even =20 > > > > /rescue/vi (to edit > > > > loader to change to boot.old): > > > > > > > > elf_load_section: truncated ELF file > > > > Abort trap > > > > > > > > Checking /boot/kernel, /lib, /usr/lib, /bin or /sbin seems to be in= takt > > > > (as far as I can > > > > check, all timestamps are 20th Dec 2025, 9:48 UTC). > > > > > > > > Well, since this is not the first time I ran into some problems usi= ng > > > > CURRENT, the outage due > > > > to two lost ZFS drives after the recent chenges seems worthy to mak= e =20 > > some =20 > > > > note here. > > > > =20 > > > > > > Can you provide error messages at boot for this? You talk about fsck = and > > > about ZFS, so I'm a little confused as to your setup. =20 > > > > No need to be confused: the CURRENT crashed/froze after two of five HDD > > were reported as > > "removed" from a RAIDZ pool. The box hung forever. > > > > The OS resides on a SSD with UFS. After > 30 min I had to switch off/on > > the box physically. > > So the UFS filesystem had a bump (journalling didn't fix it). ZFS "heal= ed" > > after reboot and > > checking the HDD. UFS SSD didn't ... > > > > > > I spent a while now to bring back everything. Boot device is now ZFS, t= oo. > > And, therefore, > > obvious slower but somehow save. > > > > The only issue I have now is a crash after a reboot. While rebooting and > > killing jails, the > > box drops into kernel debugger ... > > > > Somehow I need to copy the picture I made from the box, since the machi= ne > > isn't connected to > > the net at the moment ... > > =20 >=20 >=20 >=20 >=20 > > > > > > Warner > > > > > > =20 > > > > The other question would be how to fix: one strategy would be to bo= ot =20 > > from =20 > > > > an official image > > > > from flash drive and try to perform a "make installkernel =20 > > installworld". =20 > > > > Maybe there is > > > > another way idicativ to that what I described above ... > > > > =20 > > > > > > > > > > > > =20 > > > > Thanks in advance, > > > > > > > > oh > > > > > > > > > > > > -- > > > > > > > > A FreeBSD user > > > > =20 > > > > > > > > -- > > > > A FreeBSD user > > =20 --=20 A FreeBSD user --Sig_/eGRkODnR8Vk/K6ZF0S1.Edh Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaUmavAAKCRCxzvs8Oqok r/lsAQDzrlvtIMdoJ7whnswXENwgnDiZLk4tPpelzuUQJFsoYQEA4fvnbZjnJQsN m5oU4L0VKVYpc4xrrP0uDU2tSS6BRgE= =Z+rr -----END PGP SIGNATURE----- --Sig_/eGRkODnR8Vk/K6ZF0S1.Edh-- From nobody Mon Dec 22 20:19:45 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 4dZqHn00fxz6LXkc for ; Mon, 22 Dec 2025 20:19:49 +0000 (UTC) (envelope-from lausts@acm.org) Received: from 013.lax.mailroute.net (013.lax.mailroute.net [199.89.1.16]) (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 "mailroute.net", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZqHm0bHFz3xw9 for ; Mon, 22 Dec 2025 20:19:48 +0000 (UTC) (envelope-from lausts@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=acm.org header.s=mr01 header.b="k JHMbBu"; dmarc=pass (policy=reject) header.from=acm.org; spf=pass (mx1.freebsd.org: domain of lausts@acm.org designates 199.89.1.16 as permitted sender) smtp.mailfrom=lausts@acm.org Received: from localhost (localhost [127.0.0.1]) by 013.lax.mailroute.net (Postfix) with ESMTP id 4dZqHk3Yl6zmLB4j for ; Mon, 22 Dec 2025 20:19:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:subject :subject:from:from:content-language:user-agent:mime-version:date :date:message-id:received:received; s=mr01; t=1766434785; x= 1769026786; bh=aab7w5AufXc/0uWEYzN9LDz74xQ20UXFRqSwxUVN3y0=; b=k JHMbBuoBdt9yR5xusBFaq/Vd6MG/TzhKcl5MXOJQiB+R4FLypk24cn6ahgSqDblC yUcNRkuLJBwKOMlnjPOHnGjDrRjIUVOdtNsdIZ1MawHQFtpz98AUkfrGiJJyTR6C 41ekUh+d8CoH7eqebtphkQLVhFi7NcwiVl9zYN8amSJzkhi/9AwdCl1Jo8HYraDY uOvWuqO3ck2TynbJKLmq2ktEpz8asr0nGgoIKhzSdumWpBjkgerLe/HTQ94mrakh n1aFRjncKdKrhoYc7zFGx1lLr6HMLPYo8s+yC+r6xhzZ7Nxx7+CRLWDvJQGYiKEU M9otQ1ZxHaZqzL/UEWZyw== X-Virus-Scanned: by MailRoute Received: from 013.lax.mailroute.net ([127.0.0.1]) by localhost (013.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id yVjSKJNJ2YsN for ; Mon, 22 Dec 2025 20:19:45 +0000 (UTC) Received: from [192.168.1.100] (unknown [174.101.219.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lausts@acm.org) by 013.lax.mailroute.net (Postfix) with ESMTPSA id 4dZqHj4TfkzmLB4N for ; Mon, 22 Dec 2025 20:19:45 +0000 (UTC) Message-ID: Date: Mon, 22 Dec 2025 15:19:45 -0500 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 Content-Language: en-US To: Current FreeBSD From: Thomas Laus Subject: FreeBSD 16.0-CURRENT cf1eaaf41 Won't Install Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.09 / 15.00]; DWL_DNSWL_MED(-2.00)[acm.org:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[acm.org,reject]; R_DKIM_ALLOW(-0.20)[acm.org:s=mr01]; R_SPF_ALLOW(-0.20)[+ip4:199.89.0.0/21]; RCVD_IN_DNSWL_LOW(-0.10)[199.89.1.16:from]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:40676, ipnet:199.89.1.0/24, country:US]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RECEIVED_HELO_LOCALHOST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[acm.org:+] X-Rspamd-Queue-Id: 4dZqHm0bHFz3xw9 I have been building CURRENT every two weeks for years using a fast PC and using NFS to install it on the others in my lab. This is the first one that was built and installed successfully on the build machine but won't install on any of the others via NFS. FreeBSD 16.0-CURRENT (GENERIC-NODEBUG) #10 cf1eaaf41: Mon Dec 22 08:59:58 EST 2025 root@hamshack:/usr/src # make installworld make: warning: /usr/obj/usr/src: Permission denied make[1]: warning: /usr/src/: Permission denied make[1]: /usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at zfs on Mon Dec 22 05:59:05 EST 2025 sh: environment corrupt; missing value for 107 sh: environment corrupt; missing value for 107 sh: environment corrupt; missing value for 107 sh: environment corrupt; missing value for 107....... sh: environment corrupt; missing value for 107 -------------------------------------------------------------- sh: environment corrupt; missing value for 107 sh: environment corrupt; missing value for 107 >>> Install check world started on Mon Dec 22 15:12:45 EST 2025 sh: environment corrupt; missing value for 107 -------------------------------------------------------------- mkdir -p /tmp/install.jiTD9Kd8hh progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test time true uname wc tzsetup makewhatis ; do if progpath=`env PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH ("/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin")." >&2; exit 1; fi; done); if [ -z "" ] ; then libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | grep -Ev '\[.*]' | while read line; do set -- $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs /tmp/install.jiTD9Kd8hh sh: environment corrupt; missing value for 107 cp: =>: No such file or directory cp: =>: No such file or directory cp: =>: No such file or directory *** Error code 1 Stop. make[1]: stopped making "installworld" in /usr/src *** Error code 1 Stop. make: stopped making "installworld" in /usr/src root@hamshack:/usr/src # ============================================================================= I tried installing base.txz from the last snapshot to see if anything on my existing system was missing but received this same result. What tool or file on this PC needs to be found and re-installed if it's not in base.txz? -- Public Key: GnuPG KeyID = BD072E375C2B03E3 From nobody Mon Dec 22 21:33:52 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 4dZrxQ3VM7z6Lfnd; Mon, 22 Dec 2025 21:34:02 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4dZrxP5tD5z3CfZ; Mon, 22 Dec 2025 21:34:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id E86E0D7891; Mon, 22 Dec 2025 21:33:52 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 5BMLXq6J003058; Mon, 22 Dec 2025 21:33:52 GMT (envelope-from phk) Message-Id: <202512222133.5BMLXq6J003058@critter.freebsd.dk> To: Gleb Smirnoff cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: December 2025 stabilization week In-reply-to: From: "Poul-Henning Kamp" 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-ID: <3056.1766439232.1@critter.freebsd.dk> Date: Mon, 22 Dec 2025 21:33:52 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dZrxP5tD5z3CfZ Gleb Smirnoff writes: My thinkpad T14s is now on: main-n282679-cf1eaaf41cef-dirty Nothing to report (yet :-) Happy Solstice! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Dec 23 02:54:09 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 4db0340wj3z6M8vQ for ; Tue, 23 Dec 2025 02:54:24 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 "mx1.riseup.net", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4db0323Khwz3xhC for ; Tue, 23 Dec 2025 02:54:22 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=hhYuAuMl; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews04-sea.riseup.net (fews04-sea-pn.riseup.net [10.0.1.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4db0305d3kzDqLj for ; Tue, 23 Dec 2025 02:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riseup.net; s=squak; t=1766458460; bh=8yKGANJ8qDG+aEtkhr0TxlItm+90H+oIjngoafm8ae0=; h=Date:From:To:Subject:From; b=hhYuAuMlfr396QiVTmzRcnzgm/NtvxmY4lnWyZzkApFikt8OFzct//m/d9xnFAOAU ZkL/Jdc7duqqzI0gW/a2V0OOmvzcgMtYqJ3G9j3z0Tep8/xQ8+1B0vnp5KH7Rl85Z7 oKfIVyZMTH3HjO+FLibVqTS39N9Tql2Mdth1MSoY= X-Riseup-User-ID: 49353F37F8F5EBC7DFF957D5A672B2D0857D8AA16C2839F9E8F90FD6B58DCB1B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews04-sea.riseup.net (Postfix) with ESMTPSA id 4db02n40XPz5vgt for ; Tue, 23 Dec 2025 02:54:09 +0000 (UTC) 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 Date: Tue, 23 Dec 2025 02:54:09 +0000 From: Alastair Hogge To: freebsd-current@freebsd.org Subject: pkgbase and customised builds via ${SRC}/release/release.sh Message-ID: <20fb908c0954e62977dffdcd4a883678@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_SPF_ALLOW(-0.20)[+a:mx1.riseup.net]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[riseup.net:+]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_HELO_LOCALHOST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim] X-Rspamd-Queue-Id: 4db0323Khwz3xhC Hello, For years, I have been using one host to build all customised USB images, and tarballs for all other hosts at home. This is reached via custom make, and src.conf files, which are codified in a custom release.conf. My custom release.conf redefines load_chroot_env() to setup the environment with ${SRC}, ${PORTS}, and pkg related files. On 16-CURRENT (2-3 weeks behind) I am able to use ${SRC}/release/release.sh sans customisation, however, when I start to introduce customisations, the build never succeeds. At the moment, the build fails at: make[5]: stopped making "create-kernel-packages" in /usr/src make[5]: stopped making "create-world-packages" in /usr/src make[5]: stopped making "create-world-packages" in /usr/src make[4]: stopped making "real-packages" in /usr/src make[5]: stopped making "create-kernel-packages" in /usr/src make[4]: stopped making "real-packages" in /usr/src make[4]: stopped making "real-packages" in /usr/src make[3]: stopped making "real-packages" in /usr/src make[2]: stopped making "packages" in /usr/src make[2]: stopped making "packages" in /usr/src make[1]: stopped making "packages" in /usr/src make[1]: stopped making "packages" in /usr/src make: stopped making "release" in /usr/src/release make: stopped making "release" in /usr/src/release pkg: Unable to open plist file: /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist I have no debug enabled options, and am not interested in debug builds. In the past, when I needed debug features, I would edit the kernel config, and src.conf files, and start the release build process from there; I do not know how to parametrise debug build options. What is the method for using release.sh to custom build a pkgbase, that also supports tarballs, and install images? -- To good health, and happy holidays Alastair From nobody Tue Dec 23 04:22:09 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 4db20h6XSDz6MHWQ for ; Tue, 23 Dec 2025 04:22:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.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 4db20f5SbLz47Mq for ; Tue, 23 Dec 2025 04:22:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CzSiUEvW; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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=1766463742; bh=GBlHpRW4khpkikpE0VPZPSK5SI0bo4510THR5vSooXo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=CzSiUEvWxjCxjg1ywk68LmCxNbAsd1KzpHFf5qAQgobE0+MmuGA+Pe19xkBoxIuqvlF3KIrTXhseGS0RETMtDu+qhZy0MXH7eE0IpP2STWAj2HsVBiITQhMQacEiU+80CFN8tMWq5fI0j/ICbxctfQgotT/5iQ9e6nQlzYX/KgALBrTS9/B5mESp2GglUp0i2Cq1xkwwD5n6u1aNNaeJfX0VTYQSNONzTeS9CXYnsF1wVgwJDgXgFmye7LKLfAF7EbrZi4N1cgBB7zc7hj06Oi5W9xr+iSX4+etNmTSDDP7V1grXK+Xr9eEliSQkAwv5yJbG2yh84u0PCl7GZkjsfg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766463742; bh=4WwI5cNpDNq3tHMuTXC2BFsbcttf8vpCqg8OMVZ0Oav=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=emPQy6srMreyhw1F6NhPFhie0dU5acOMv/5rFxGfJd22ltwmNcbAu5TAHIn40mI/09MIzb5DwkzP3XHD5mLSshOfGLV3Ms+LggcOGS0l2/eamZsMcE3URWQStl49hQXaWt0rxkG9F6KGLclrj5pmC0urjcsdjdUnOYc1DcDSUDNiNgJ6G6AGjRe3FxZlb1LaS74d66112kV2ihxz9Gccle0YUxsEovjJ5ASj/K0KaRsSLcOg37frQJ22ZyOnaWZ2dVibaSTEZJx4Hh7/0a9qNXkuSWBE1uUmgPdQF2V2dLZwk+w77G2tOwL8HeK6ORmczchsZpnRXenawoG29s8oqA== X-YMail-OSG: MTXpp80VM1kZOVM7NSz0Z4hO2YpgMjkV6czco1VYf947L0_f9UB5L.v_w4JpkDr 51b45tWq.eAOM4lEsVGNRWRIEiCgdOSklJ0xnXgTwbzJidLa78Lj3x6WIwLMsLFyp_yoes.iz8Wh w2CSnbRl8gjEZ1k6PJsA9tjUx2cmqoItu0CqpfJJSYQcxdqmNKthp6RaFV1Kuhoj3JemLQjV.Ez9 AwUxD_sGHQj4CptOyXfwmUyPgZSUuR0iSkPSr3Ih0eO9ZJX802.wQVVYZBaLmJPIGrkIPuN4J_3h 1N6o_eNPgTYAknlfDvt1Q8cdDFmp5OihKO_55XO0A7qghsbJ5BbUOvJhov2w4b.J9uwfaVeDFP60 6hFNDAqf9atzfPe7JGSCIkFD0kd6bOCyFZjfZ9NeFW2Mc9T1OCUSQOpC0nVgwRmW9iXgl1eUAfpE wAbp58jwlOqVjDPCQIqoBRxW4kNWelh.MBaIFe_CI4DQdwKNeupVYY.KBIPAzE2GpbbBrt2PCsBR bieAMLyfZ4_Qvj6hxmntE1c4BpsuUnummaXUQVS.BAEgy.eo3Dm8yjR0NX.Ksl5kg.LKybh8Mg3g BagAhxIUcJuntYaRgb44EPwUk.GhZrB7NUGotgPYfjhfrFGgP3qc91yKdEytz4U4xg65409V3X5G 9u5jBwKC4UsxxbJ3hoPragmuiiOJcBJli5_u9vD.sxBg.kxoT3ksxYGJiO5Trl5uK5lfYRpwx50Q hgKCfDy9BhqD7MlTHZgId4uMiFsacCk8J3E1ph7rPz2Fnu4ZAtGaH.6PlxnEDxnwRB.BQrT_reja 0qYSvS399HntYXjXxvZgNV8f09sfgTtZ.og_bIxKppMhMbGb0DQuEIQNQT3iIVhEoWYc0MXyfF9N 6qEBieX1bqzy3MW.XCvvoU1bHPzMT5vpwsAdINWhP.EGw2Gfst4Io6HPng7fr2.jpQIKPSKRbO6f BNajQeLpQ7hpoZQNwr313hgbXndJmWZLYY7f7xkkmwaaRz0PkGoBJUSa6V1vQkT7cOha5EdjAkY4 Ei2r2FJWAFlYsON9C8Q8AzSM1EoDxThHzE.ez5j.zAwRq9VwULkU1u1QIQvQLEVCg4nWcr522U62 Da_Lhil5NT1M33C72xs1rzBMg1KR3_PKKJpRtpmQOcH5kj8pS_wYmJLmGD80gSF9oKtcF1afZDDB uGRvRFDkBA.Hpq9zA3ixZxoJ789w0Eeh13MqkST9bffNm33XmVJDA77XrQBEfVQoMz2YMBPpMN.o BQkToCX7VTlci62eQJE.i.dh95xuQ_MtVYLZ90ouWyW74i5NFy8USY3n8Q0b0nBWmONpsG6mscKe FDvpLZ4Yfk0aRaX7BAr4KKqspFufeOzm1PFUBIWx5.FIXApuM69Ngh4WETaix83e5BkTHIpqFRgI g1vRtH1VkiqWlud4bgljpC36QaGavawGOCqJTy9Z2cXBMKXuPzeVfRx.HPyZ.MHA43GawnA8f5Vd EZAhc0muy4OnWi4fgjpxcjVxoL_wwywGKDR8dSIqqGC27OxSUMKOauiSE_00yUlFCafMnaw01BBL a4JZRLpkDszSWywCQRyd_3D1mdFEqLD4zAM.uoW0xt7KW78Etgt0wwpkHwuL1QQHf6IjSwarejAY 4LlGhxDUrWUz1sHxvUahRhepss16BXbWLbUML1B6i4L_vN2EACJOZFtfcrP8ssQSQELGY6wMbaUK 878gYN__9PSJjeY_y3AzPeVWzElKbeBjPvRG5knvypGyye1XnOg6Dz5Y8G3PO6MDtbJilMNF81te 5KwlLeOYuB8vAqQeJZZbNBLjAH_5AATOE33Y_twHw77eMNkvowRMiaGpbfV3RLjPd33JfpuUbyct ZrI73zQ4ITXRDdXFNv2h2yIA5beJtLYYsHqLkne05spyKKVX4QzG8k2kkPkOnqBI0_8P26CtW35z N7mfNZtnwIMJfwKukDxBoRsCApUaHm07rACkfeunsAuq5jgLoU2Le3xBNwfzWuBtBvZx.NICHbj0 uPeMXvIpxciQjcGgkzyKNUdKwhm.p.bR29KdcYiiZhMeVvVSkdGkr2J1h2o0pN3AAbDJUTyz0tJn ta_jbV7U_7rsuQ6Te2HGlj93.dsnAzKt2bDH3R5_KKBpnd60sBrU3oDvOcZ5dtpLfwK2j3jYcSR8 SMAh7Xi_OA6cgY9uCrhhTAHvNGs3nWsZYyr_pcUMhzKB4bagdDLQ.NecOai9hpW89D72BJ7EaUrG Dz6_s9YQHk.1hbTO2E71YjlON6qOzWKLYJwk8SZKHRQ2vjimBa4wWWrJsj053sWIRxeWL7jF_Ig7 KtqPRoA-- X-Sonic-MF: X-Sonic-ID: df0c9261-7cd7-4ec3-9f6b-2858b2292584 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 04:22:22 +0000 Received: by hermes--production-gq1-54bf57fc64-hpmbd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9efb39ea815ae74487ec4263eb11c43d; Tue, 23 Dec 2025 04:22:20 +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 \(3826.700.81\)) Subject: RE: pkgbase and customised builds via ${SRC}/release/release.sh Message-Id: Date: Mon, 22 Dec 2025 20:22:09 -0800 To: agh@riseup.net, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.98)[-0.983]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; 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.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from] X-Rspamd-Queue-Id: 4db20f5SbLz47Mq Alastair Hogge wrote on Date: Tue, 23 Dec 2025 02:54:09 UTC : My notes here are limited in their coverage. I've not done the type of thing you are trying to do. > For years, I have been using one host to build all customised USB > images, and tarballs for all other hosts at home. This is reached via > custom make, and src.conf files, which are codified in a custom > release.conf. My custom release.conf redefines load_chroot_env() to > setup the environment with ${SRC}, ${PORTS}, and pkg related files. > > On 16-CURRENT (2-3 weeks behind) I am able to use > ${SRC}/release/release.sh sans customisation, however, when I start to > introduce customisations, the build never succeeds. At the moment, the > build fails at: > > make[5]: stopped making "create-kernel-packages" in /usr/src > make[5]: stopped making "create-world-packages" in /usr/src > make[5]: stopped making "create-world-packages" in /usr/src > make[4]: stopped making "real-packages" in /usr/src > make[5]: stopped making "create-kernel-packages" in /usr/src > make[4]: stopped making "real-packages" in /usr/src > make[4]: stopped making "real-packages" in /usr/src > make[3]: stopped making "real-packages" in /usr/src > make[2]: stopped making "packages" in /usr/src > make[2]: stopped making "packages" in /usr/src > make[1]: stopped making "packages" in /usr/src > make[1]: stopped making "packages" in /usr/src > make: stopped making "release" in /usr/src/release > make: stopped making "release" in /usr/src/release > pkg: Unable to open plist file: > /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist > > I have no debug enabled options, and am not interested in debug builds. pkgbase has been including debug symbol information even for non-debug builds. But they go in separate .pkg files that do not have to be installed. The bias seems to be to allow somewhat readable backtraces for failures without having to rebuild, just having chosen to have the information present by installing it. (I do not know if dist tarballs now do similarly for non-debug builds.) Just having debug symbol information for backtrace or the like to use need not be considered a debug-build: no enabling of adding internal checking for problems, for example. > In the past, when I needed debug features, I would edit the kernel > config, and src.conf files, and start the release build process from > there; I do not know how to parametrise debug build options. Of course, you may not want even backtrace information. > What is the method for using release.sh to custom build a pkgbase, that > also supports tarballs, and install images? pkgbase and dist tarballs are mutually exclusive ways of doing an install. pkgbase does not have to be involved at all for 15.* , for example. (pkgbase has its own way of dealing with doing updates as well.) Related to such, root/release/Makefile reports: # Variables affecting the build process: . . . # NODISTSETS: if set, do not include dist sets or MANIFEST # NOPKGBASE: if set, include dist tarballs rather than pkgbase packages in # disc1 and dvd1 installation media and build VM/cloud images using # make installkernel installworld. . . . As stands, the above indicates that to get dist tarballs you turn off the generation of pkgbase files from the buildworld results: it does one or the other way, but not both in one run, for disc1 and dvd1. pkgbase generation does not have to be involved at all for those. (You were not explicit about dist sets or their MANIFEST but I listed the line for that as well.) I'm not sure if you might only want dist tarballs and not need pkgbase at all. pkgbase does not have to be involved at all until 16.0-STABLE . === Mark Millard marklmi at yahoo.com From nobody Tue Dec 23 09:31:43 2025 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 4db8vl40qkz6L2yB for ; Tue, 23 Dec 2025 09:33:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E7" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4db8vl04Vnz3fnt for ; Tue, 23 Dec 2025 09:33:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1766482364; 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=wlMo8pqmU185QhCA/AwORucrk74SzhuKeCNsoyvB5N4=; b=nzIY0GNtmMBrpQWt5pgmw/rSy83241vfMZBhCzApd8lP5cQ1ttkRnuENdF05PX6zAsV1nx rp12qqGBh52tgCE0jwAhKYmH9EV6E8wIafP/71A/DpLZHz5LLr1k6H3A7NHDdbl9Tmw7SO iGpB9bWq21uxv1XGooIfEuiRmNVYZYVP3H7fmp7slSaS39aapSZNSQ9Hc3ggmr6rQVrd6t VHhHw/QUbejZs1FMlM///cUNo0yFReX6Bt1Wg11z9CEChFgbNFtw7m46YAwhLMHPLpzN62 AzZLT4IXSdp3/cYVqQct4nKrFy7icW2DnB/r3nMrTc9bMV5DEbVViJWLn4Z1Ng== Date: Tue, 23 Dec 2025 10:31:43 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current Subject: Re: Changes in cam/nvme causes issues? In-Reply-To: References: <198170948d34f4dc169e94934da82161@Leidinger.net> <89a92e0a926239e2c192dc0ff9c80d6e@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_c58046925ce793454f8ac90d7ad4be2e"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4db8vl04Vnz3fnt This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_c58046925ce793454f8ac90d7ad4be2e Content-Type: multipart/alternative; boundary="=_62b8689b2f5b3983b81d241231879e94" --=_62b8689b2f5b3983b81d241231879e94 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-12-22 17:58, schrieb Warner Losh: > On Sun, Dec 21, 2025 at 8:37 AM Alexander Leidinger > wrote: > > Am 2025-12-14 14:05, schrieb Warner Losh: > > Let's do one issue at a time. There's too much missing info. Top > posting since there's not a lot of context to this request > > The disk died now completely, so the CRC errors are out of reach now. > > First, let's start with pciconf -l of the nvme drive. I have a strong > idea, but need some data. > > While already provided privately with some other data, here for the > public so that people are aware that currently there is an issue with > such drives: > nvme0@pci0:5:0:0: class=0x010802 rev=0x00 hdr=0x00 vendor=0x144d > device=0xa809 subvendor=0x144d subdevice=0xa801 > Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V Yea, so far this is the only report I've received, and there's not enough data in it to reproduce it with any of the dozen NVMe drives that I have, or to spot a difference with what I know I check in the code. So if it's compiled into the kernel with cam also compiled into the kernel, I know it works. CAM is in the kerne, nvme is loaded as a module (from 15-current): ---snip--- # kldstat | egrep '(nvm|cam)' 2 1 0xffffffff811e3000 20db8 nvme.ko ---snip--- I will do a clean rebuild with the most recent 16-current and provide a full dmesg if this still doesn't work. Bye, Alexander. > Warner > > Bye, > Alexander. > > Also, the disk report needs full logs with and without the settings > that have uncorrectable in them. I'd expect that a shorter timeout > would lead to different behavior, but maybe that error syndrome isn't > one I've seen. It would also be helpful to know which of the times > changes the behavior... > > Warner > > On Sun, Dec 14, 2025, 5:06 AM Alexander Leidinger > wrote: Hi Warner, > > I try to update a 15-current (as of 2025-11-27-110715) to a recent 16 > (as of 2025-12-13-132815). It fails to import a pool due to a missing > nvme. I also have a broken HD in this system... to be on the safe side > I > mention it. > > This is from 15-current: > ---snip--- > NAME STATE READ WRITE CKSUM > rpool DEGRADED 0 0 0 > mirror-0 DEGRADED 0 0 0 > diskid/DISK-WD-WCC4N4KLEZT7p3 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1DF9DA2p3 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R0NTp3 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1PYJ3F8p3 OFFLINE 0 0 0 > logs > diskid/DISK-493504058890547p1 ONLINE 0 0 0 > cache > diskid/DISK-493504058890547p2 ONLINE 0 0 0 > > NAME STATE READ WRITE CKSUM > space DEGRADED 0 0 0 > raidz2-0 DEGRADED 0 0 0 > diskid/DISK-WD-WCC4N4KLEZT7p4 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1DF9DA2p4 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R0NTp4 ONLINE 0 0 0 > diskid/DISK-WD-WX52D625R2TPp4 ONLINE 0 0 0 > diskid/DISK-WD-WCC4N1PYJ3F8p4 OFFLINE 0 0 0 > logs > diskid/DISK-S649NL0T819360Vp2 ONLINE 0 0 0 > cache > diskid/DISK-S649NL0T819360Vp3 ONLINE 0 0 0 > ---snip--- > > The offline marked partitions are on the same HD (the broken one). The > DISK-S649NL0T819360V device use as log and cache in the second pool > causes the issue on 16-current. > > On 16-current I get "uncorrectable parity/CRC error" messages on boot > from the broken disk. I used this to get rid of those errors: > ---snip--- > # grep kern.cam /tmp/be_mount.MhLw/boot/loader.conf > kern.cam.tur_timeout="60" > kern.cam.inquiry_timeout="60" > kern.cam.modesense_timeout="60" > ---snip--- > > But the second pool ("space") fails to get imported. When I import it > via "zpool import -m space" it shows me that the log and cache devices > (different partitions on the same hardware) are not available. > This is the device in question as seen from 15-current: > ---snip--- > nda0: > nda0: Serial Number S649NL0T819360V > [1] nda0: nvme version 1.4 > nda0: 953869MB (1953525168 512 byte sectors) > [1] GEOM: new disk nda0 > ... > [1] pass6 at nvme0 bus 0 scbus6 target 0 lun 1 > pass6: > pass6: Serial Number S649NL0T819360V > [1] pass6: nvme version 1.4 > ---snip--- > > In case you need some info from the 15- or 16-current BE, which info do > you need? > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP > 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP > 0x8F31830F9F2772BF -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_62b8689b2f5b3983b81d241231879e94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2025-12-22 17:58, schrieb Warner Losh:

 

On Sun, Dec 21, 2025 at 8:37=E2=80= =AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2025-12-14 14:05, schrieb = Warner Losh:

Let's do one issue at a time. There's too much missi= ng info. Top posting since there's  not a lot of context to this reque= st 
 
The disk died now completely, so the CRC errors are out o= f reach now.
 
First, let's start with pciconf -l of the nvme drive. I h= ave a strong idea, but need some data.
 
While already provided privately with some other data, he= re for the public so that people are aware that currently there is an issue= with such drives:
nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 = vendor=3D0x144d device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801
Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V
 
Yea, so far this is the only report I've received, and there's not eno= ugh data in it to reproduce it with any of the dozen NVMe drives that I hav= e, or to spot a difference with what I know I check in the code. So if it's= compiled into the kernel with cam also compiled into the kernel, I know it= works.
 
CAM is in the kerne, nvme is loaded as a module (from 15-current):
---snip---
# kldstat | egrep '(nvm|cam)'
 2    1 0xffffffff81= 1e3000    20db8 nvme.ko
---snip---
 
I will do a clean rebuild with the most recent 16-current and provide = a full dmesg if this still doesn't work.
 
Bye,
Alexander.
 
Warner 
 
 
Bye,
Alexander.
 
Also, the disk report needs full logs with and without th= e settings that have uncorrectable in them. I'd expect that a shorter timeo= ut would lead to different behavior, but maybe that error syndrome isn't on= e I've seen. It would also be helpful to know which of the times changes th= e behavior...
 
Warner

On Sun, Dec 14, 2025, 5:06=E2=80=AFAM Alexander Leidinger = <Alexander= @leidinger.net> wrote:
Hi Warner,

I try to update a 15-current= (as of 2025-11-27-110715) to a recent 16
(as of 2025-12-13-132815). = It fails to import a pool due to a missing
nvme. I also have a broken= HD in this system... to be on the safe side I
mention it.

This is from 15-current:
---snip---
        =  NAME                  &n= bsp;            STATE     READ= WRITE CKSUM
         rpool    &nbs= p;                     &n= bsp;   DEGRADED     0     0   =  0
           mirror-0   = ;                     &nb= sp;DEGRADED     0     0     0<= br />             diskid/DISK-WD-WCC4N4K= LEZT7p3  ONLINE       0     0 =    0
             diskid= /DISK-WD-WCC4N1DF9DA2p3  ONLINE       0  &nbs= p;  0     0
          &nb= sp;  diskid/DISK-WD-WX52D625R0NTp3  ONLINE      &n= bsp;0     0     0
      &= nbsp;      diskid/DISK-WD-WCC4N1PYJ3F8p3  OFFLINE =     0     0     0
  &nbs= p;      logs
           d= iskid/DISK-493504058890547p1    ONLINE       = 0     0     0
       = ;  cache
           diskid/DISK-493= 504058890547p2    ONLINE       0   =  0     0

         = NAME                    &= nbsp;          STATE     READ WRITE= CKSUM
         space      &nb= sp;                     &= nbsp; DEGRADED     0     0     = ;0
           raidz2-0    &nbs= p;                    DEG= RADED     0     0     0
&= nbsp;            diskid/DISK-WD-WCC4N4KLEZT7p= 4  ONLINE       0     0   = ;  0
             diskid/DISK-= WD-WCC4N1DF9DA2p4  ONLINE       0    &nb= sp;0     0
            &n= bsp;diskid/DISK-WD-WX52D625R0NTp4  ONLINE       0&= nbsp;    0     0
        =      diskid/DISK-WD-WX52D625R2TPp4  ONLINE   =    0     0     0
   = ;          diskid/DISK-WD-WCC4N1PYJ3F8p4  OFF= LINE      0     0     0
&= nbsp;        logs
        &nbs= p;  diskid/DISK-S649NL0T819360Vp2    ONLINE    &nb= sp;  0     0     0
    &n= bsp;    cache
           diski= d/DISK-S649NL0T819360Vp3    ONLINE       0&nb= sp;    0     0
---snip---

The offl= ine marked partitions are on the same HD (the broken one). The
DISK-S= 649NL0T819360V device use as log and cache in the second pool
causes = the issue on 16-current.

On 16-current I get "uncorrectable pari= ty/CRC error" messages on boot
from the broken disk. I used this to g= et rid of those errors:
---snip---
# grep kern.cam /tmp/be_mount.= MhLw/boot/loader.conf
kern.cam.tur_timeout=3D"60"
kern.cam.inquir= y_timeout=3D"60"
kern.cam.modesense_timeout=3D"60"
---snip---

But the second pool ("space") fails to get imported. When I import = it
via "zpool import -m space" it shows me that the log and cache dev= ices
(different partitions on the same hardware) are not available.This is the device in question as seen from 15-current:
---snip---=
nda0: <Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V>
nda0:= Serial Number S649NL0T819360V
[1] nda0: nvme version 1.4
nda0: 9= 53869MB (1953525168 512 byte sectors)
[1] GEOM: new disk nda0
...=
[1] pass6 at nvme0 bus 0 scbus6 target 0 lun 1
pass6: <Samsun= g SSD 980 1TB 2B4QFXO7 S649NL0T819360V>
pass6: Serial Number S649NL= 0T819360V
[1] pass6: nvme version 1.4
---snip---

In ca= se you need some info from the 15- or 16-current BE, which info do
yo= u need?

Bye,
Alexander.

--
http://= www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
= http://www.FreeBSD.org    netchild@FreeBSD.org  : = PGP 0x8F31830F9F2772BF


--


--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:/= /www.FreeBSD.org    n= etchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
--=_62b8689b2f5b3983b81d241231879e94-- --=_c58046925ce793454f8ac90d7ad4be2e Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIyBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmlKYY4ACgkQEg2wmwP4 2IZ8BA/4npcxTpdRYZJ5/A0+vcT7jZvrg37cCg9EJaBb09v7AqUiaaPwC+7FjY6q Ji4E2xBZyhXf1xC9wbDrDc2jki5xNUD14O5BISyCanARH5u2g7GP6s1blxAX1SzK OmDG11tOMZIPrV7TycyNHh6pquaznRUxb5xbU9mc4OlGoO40OL+EiX5lUVzYDbCw MjjfZb5MYI0QmACsxdNsdLMoftSej7KUm0vJJfF5Bs0LspLwj0uzpnqmw+dNhV9D ROgM0co3MHnzHg3Kju0xeaXevKQ9JSioHzMFe92fg0KR6R3V9XzU69kf8mfx0t3l fHxPY0K88KeRGDR+QoutysZrb1ssN4AkCrskvCpyG5W3aRleUwIAZPjNn48K71AR tIPvchXnnArGhMhEMR4ZMnPRqaFJsGYoY75HzVeJxC2v5IE1XhV34/kZh9pmqyc/ lZQGoWkLHY+W/HJwa8aQUv6uPeTkmFIbm+1KZo3RGudLSPausWW0qT4lnK2dMznk S9JDvxn3Za26FtUbmW7Es0Sq1NzznEzX+ZieNwB5oQ2Gm10LriFTg3GVHy1f5gzc t4Rf6N5wfw2ucOu9EuAfMyVT3YqeNZy+BVWmNUt6mqpJrbboHU+91fX2X7hKVGMy WJVV4sfKjF5YEPorPV8ZU2TessssGFjfUhZwPLleJu0cKKPbEw== =ohgH -----END PGP SIGNATURE----- --=_c58046925ce793454f8ac90d7ad4be2e-- From nobody Tue Dec 23 09:50:57 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 4db9J01KJsz6L4cM for ; Tue, 23 Dec 2025 09:51:12 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 "mx1.riseup.net", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4db9Hy6zw2z3hj1 for ; Tue, 23 Dec 2025 09:51:10 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; none Received: from fews04-sea.riseup.net (fews04-sea-pn.riseup.net [10.0.1.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4db9Hj6442zDqP6; Tue, 23 Dec 2025 09:50:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riseup.net; s=squak; t=1766483468; bh=nDCB5nqFiMXynm9WZnkTD0qcvbf2Wdr9YahMLrDrQWY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NH6n0s0na17R5ls5+Tl9f5lQqSX3+heIRJirqoZjYSCoL5aZySYu+B1hp6bC1oM+d vd+iAVyeAw1QTMegWrCcBCFr2OsgIXzuc+KIqm9caee7uEInSk/y2cY1JAEVPhcU6G Yqd1YythK/hOwaQ+855A1ZkmUqbM/xN1vo4nGfMk= X-Riseup-User-ID: E4387E5DF0BAD20F7385789F91E6DA6CBB6819CBCB2CB58A480C39E56C4723BC Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews04-sea.riseup.net (Postfix) with ESMTPSA id 4db9Hj3zcPz5whT; Tue, 23 Dec 2025 09:50:57 +0000 (UTC) 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 Date: Tue, 23 Dec 2025 09:50:57 +0000 From: Alastair Hogge To: Mark Millard Cc: FreeBSD Current Subject: Re: pkgbase and customised builds via ${SRC}/release/release.sh In-Reply-To: References: Message-ID: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4db9Hy6zw2z3hj1 On 2025-12-23 12:22, Mark Millard wrote: > Alastair Hogge wrote on > Date: Tue, 23 Dec 2025 02:54:09 UTC : > > My notes here are limited in their coverage. I've > not done the type of thing you are trying to do. > >> For years, I have been using one host to build all customised USB >> images, and tarballs for all other hosts at home. This is reached via >> custom make, and src.conf files, which are codified in a custom >> release.conf. My custom release.conf redefines load_chroot_env() to >> setup the environment with ${SRC}, ${PORTS}, and pkg related files. >> >> On 16-CURRENT (2-3 weeks behind) I am able to use >> ${SRC}/release/release.sh sans customisation, however, when I start to >> introduce customisations, the build never succeeds. At the moment, the >> build fails at: >> >> make[5]: stopped making "create-kernel-packages" in /usr/src >> make[5]: stopped making "create-world-packages" in /usr/src >> make[5]: stopped making "create-world-packages" in /usr/src >> make[4]: stopped making "real-packages" in /usr/src >> make[5]: stopped making "create-kernel-packages" in /usr/src >> make[4]: stopped making "real-packages" in /usr/src >> make[4]: stopped making "real-packages" in /usr/src >> make[3]: stopped making "real-packages" in /usr/src >> make[2]: stopped making "packages" in /usr/src >> make[2]: stopped making "packages" in /usr/src >> make[1]: stopped making "packages" in /usr/src >> make[1]: stopped making "packages" in /usr/src >> make: stopped making "release" in /usr/src/release >> make: stopped making "release" in /usr/src/release >> pkg: Unable to open plist file: >> /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist >> >> I have no debug enabled options, and am not interested in debug builds. > > pkgbase has been including debug symbol information > even for non-debug builds. But they go in separate > .pkg files that do not have to be installed. The > bias seems to be to allow somewhat readable backtraces > for failures without having to rebuild, just having > chosen to have the information present by installing > it. I am all for it, right now I think I need a way to disable it. > (I do not know if dist tarballs now do similarly for > non-debug builds.) > > Just having debug symbol information for backtrace > or the like to use need not be considered a > debug-build: no enabling of adding internal checking > for problems, for example. > >> In the past, when I needed debug features, I would edit the kernel >> config, and src.conf files, and start the release build process from >> there; I do not know how to parametrise debug build options. > > Of course, you may not want even backtrace information. > >> What is the method for using release.sh to custom build a pkgbase, that >> also supports tarballs, and install images? > > pkgbase and dist tarballs are mutually exclusive ways > of doing an install. pkgbase does not have to be > involved at all for 15.* , for example. (pkgbase has > its own way of dealing with doing updates as well.) > > Related to such, root/release/Makefile reports: > > # Variables affecting the build process: > . . . > # NODISTSETS: if set, do not include dist sets or MANIFEST > # NOPKGBASE: if set, include dist tarballs rather than pkgbase packages in > # disc1 and dvd1 installation media and build VM/cloud images using > # make installkernel installworld. > . . . Whether it is a generic, or custom build, using ${NOPKGBASE} always results in a pkg failure: -------------------------------------------------------------- >>> Install kernel(s) GENERIC completed in 6 seconds, ncpu: 64, make -j32 -------------------------------------------------------------- [...] --- disc1 --- env INSTALL_AS_USER=yes ASSUME_ALWAYS_YES=yes pkg -o METALOG=METALOG -o ABI= -r disc1 -o REPOS_DIR=/usr/src/release/pkg_repos install -f pkg Installing pkg-2.5.0... Extracting pkg-2.5.0: .......... done pkg: Unknown OS '' in ABI string pkg: Cannot parse configuration file! *** [disc1] Error code 1 make: stopped making "release" in /usr/src/release Or, FreeBSD-base repository update completed. 269 packages processed All repositories are up to date. pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION as: 1600000 /usr/libexec/flua: /usr/src/release/scripts/pkgbase-stage.lua:47: assertion failed! stack traceback: ▸ [C]: in function 'assert' ▸ /usr/src/release/scripts/pkgbase-stage.lua:47: in upvalue 'select_packages' ▸ /usr/src/release/scripts/pkgbase-stage.lua:101: in local 'main' ▸ /usr/src/release/scripts/pkgbase-stage.lua:107: in main chunk ▸ [C]: in ? *** [disc1] Error code 1 make: stopped making "release" in /usr/src/release --- bootonly --- --- installconfig_subdir_share --- --- installconfig_subdir_share/timedef --- make[4]: stopped making "installconfig" in /usr/src/share make[3]: stopped making "installconfig" in /usr/src make[2]: stopped making "distribution" in /usr/src make[1]: stopped making "installworld installkernel distribution" in /usr/src *** [bootonly] Error code 2 make: stopped making "release" in /usr/src/release make: 2 errors make: stopped making "release" in /usr/src/release > As stands, the above indicates that to get dist > tarballs you turn off the generation of pkgbase > files from the buildworld results: it does one > or the other way, but not both in one run, for > disc1 and dvd1. pkgbase generation does not have > to be involved at all for those. > > (You were not explicit about dist sets or their > MANIFEST but I listed the line for that as well.) > > I'm not sure if you might only want dist tarballs > and not need pkgbase at all. pkgbase does not > have to be involved at all until 16.0-STABLE . I want to move to pkgbase over dists, however, it seems I can not manage either yet. From nobody Tue Dec 23 10:38:50 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 4dbBMz5pRtz6L8F4 for ; Tue, 23 Dec 2025 10:39:43 +0000 (UTC) (envelope-from ivy@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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbBMz570rz3nhX for ; Tue, 23 Dec 2025 10:39:43 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766486383; 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=6p3JSQEtxqmYhdjlSXOej8sV+Ikk1NqnWWuGGp2vA58=; b=IGiYc82fFQ3mB18LFyTIWpxtCRcVMH5cpNJAZwlcVDh91q4NuncHg6bU6evt4vLqKxcbxb v0m5AdakuGRd1h28T1aog+U9y5TzJcDEufOAxTcO+d8VRQb+A4nCPGRaoIyYLOgpkwDqcE 0QupIn11RJYgU/PvYVRP0ZtIjx9tFevLhvB59FLhfrV9AfOvQ2I8PRTeKI6bu9H2P9K7wv m0fnnqdJlSVPbIgTImVWYt2V2Lc6pzocMVCCEWTnh3gsBRhJE/EeVwW3x92wt8uSov4N6H qznS+Vt2o0N/RCkOfUU5/7O0NogQWDhd8RH+G6x2S7KrStFmdWnznI2v+prkrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766486383; 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=6p3JSQEtxqmYhdjlSXOej8sV+Ikk1NqnWWuGGp2vA58=; b=N5esVwP++86QrAXNS/KegzGvJCRKaFJ6OpW3JUxbmFGlpsVKeql5kjeF51rENjrIn6w4J3 YnEvaTWML2nEEhCOH53+3mBTfV4nrH+BIj/91eC4954nimqQJ+1xaRi1K3GpJBg9JAdO0i IVsHc57twM9G3J2Hr96scAHwghPLYyDHXAMI08WW6qyIIp4sSdUCJOb+Xlwcfliz+AnhDb nMCa0djw0i0jqOo81PD7oOuF3CCfhgl2i9btUdc4MLrb7D8/wHP5XkJZhKUqdh12GAFfGE nT6YA2TUmguA58D6K3V1B9fdM6zrZbMnCfUhCQ9TD8IqlaYNWIEJsIrwGns/gw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766486383; a=rsa-sha256; cv=none; b=fSsC1N+NEZ+5m2OYi9LWHfqKC9pzO9GaSIsZCu8NSS8IMgoqSGovrd1IUd7yHjRd0uKiA9 wTI7VsuilsxjCOdqExVUumXslcfNBzp3q+CB6rRd7le9fqJifhmXEHdmF2GOl/n7QREfqy YUgFQqPRs0rtHhEY6JXDT90wnmRK4utdt8IwJJwetjPzBqVyCaIUghS45slNIQhWGpcveQ PCis+XmgkkalUWwVIfkYu4/Big4NHUqAywL3VRBmHEL/ivyrVaR4/Rvb0EZ+sDKeNsE6km ZDtGrBc/yhKlfrQpZ+FSkriDWla8/F8ePKTNG3Hsu8XHSt5vXfRGAiZbwRYNcw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dbBMz2M1XzJgB for ; Tue, 23 Dec 2025 10:39:43 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Tue, 23 Dec 2025 10:38:50 +0000 From: Lexi Winter To: freebsd-current@freebsd.org Subject: Re: pkgbase and customised builds via ${SRC}/release/release.sh Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20fb908c0954e62977dffdcd4a883678@riseup.net> 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/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GYL7cdsEQoWniSJ/" Content-Disposition: inline In-Reply-To: <20fb908c0954e62977dffdcd4a883678@riseup.net> --GYL7cdsEQoWniSJ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alastair Hogge wrote in <20fb908c0954e62977dffdcd4a883678@riseup.net>: > pkg: Unable to open plist file: > /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist >[...]=20 > What is the method for using release.sh to custom build a pkgbase, that > also supports tarballs, and install images? as far as i'm aware, we don't support building a pkgbase release with a kernel other than GENERIC. even if the build succeeded, you wouldn't be able to install using the resulting media since bsdinstall only knows how to install GENERIC. my suggestion for now would be to build the release media with GENERIC, then put the custom kernels in your base repository and install them after booting with GENERIC. this is definitely something we want to fix in the future, it just wasn't critical enough to make the 15.0 release. i have a couple of other release things i want to fix first, then i'll see about fixing this, since i also want custom kernels on install media. --GYL7cdsEQoWniSJ/ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaUpxNQAKCRD1nT63mIK/ YIkoAQD7jvPhrse6ln85Gz96xdT7FszAtCpZgxDjqONqdWhw2QD/Wq9FPm8ikcVF 8VYjlnCqmAZ4uzPe4sa4D2L3Pls8kgw= =qUDY -----END PGP SIGNATURE----- --GYL7cdsEQoWniSJ/-- From nobody Tue Dec 23 14:18:24 2025 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 4dbHG62BTBz6LVDh for ; Tue, 23 Dec 2025 14:19:58 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E7" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbHG438Dpz4Kdq for ; Tue, 23 Dec 2025 14:19:56 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=nd4Nx4U1; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1766499554; 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=MCsLRHhaM7zYUhKy60shdgQGJI+t/NE/sobuQp+u3B8=; b=nd4Nx4U1gHQWE6+ncUlLaoUM9FlJKzOpv1KNC0IO1JHDpuDgi9vvzu8Hg+cAkxzzXU0FHr cCFwV4ADD6YLbk2siszRHQu0Qx6v5SFTcdngXp4db6tjpgLLN7uXnyCM6pBS0buztY1ZhH nCUe7vt+ZbUoyTQfAs6MD3kIzhO2IOK0i0RNUMW+3XQ8cTAOYl/r3hCGtL+OQYTwoCfchL 2i4cpqNsIc45RUm6cQt/xM+8afWKAS3kyd6eDH2dJeOrbzT/jCjCITYUAxTUgfEdB5WtyT f8f4z9nREb4QZ5YHe4KcHxRjG9GQeYkKlwBxyyBYyxQ9AguwXfudN7qjzs0edQ== Date: Tue, 23 Dec 2025 15:18:24 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current Subject: Re: Changes in cam/nvme causes issues? In-Reply-To: References: <198170948d34f4dc169e94934da82161@Leidinger.net> <89a92e0a926239e2c192dc0ff9c80d6e@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_5b8398f92dd80349ad073fab75fdfec1"; micalg=pgp-sha256 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ONCE_RECEIVED(0.10)[]; NEURAL_SPAM_SHORT(0.02)[0.021]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; BLOCKLISTDE_FAIL(0.00)[89.238.82.207:server fail]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~] X-Rspamd-Queue-Id: 4dbHG438Dpz4Kdq This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_5b8398f92dd80349ad073fab75fdfec1 Content-Type: multipart/alternative; boundary="=_a1d23432334b461710ca90b104d8b2e2" --=_a1d23432334b461710ca90b104d8b2e2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-12-23 10:31, schrieb Alexander Leidinger: > Am 2025-12-22 17:58, schrieb Warner Losh: > > On Sun, Dec 21, 2025 at 8:37 AM Alexander Leidinger > wrote: > > Am 2025-12-14 14:05, schrieb Warner Losh: > > Let's do one issue at a time. There's too much missing info. Top > posting since there's not a lot of context to this request > > The disk died now completely, so the CRC errors are out of reach now. > > First, let's start with pciconf -l of the nvme drive. I have a strong > idea, but need some data. > > While already provided privately with some other data, here for the > public so that people are aware that currently there is an issue with > such drives: > nvme0@pci0:5:0:0: class=0x010802 rev=0x00 hdr=0x00 vendor=0x144d > device=0xa809 subvendor=0x144d subdevice=0xa801 > Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V Yea, so far this is the only report I've received, and there's not enough data in it to reproduce it with any of the dozen NVMe drives that I have, or to spot a difference with what I know I check in the code. So if it's compiled into the kernel with cam also compiled into the kernel, I know it works. CAM is in the kerne, nvme is loaded as a module (from 15-current): ---snip--- # kldstat | egrep '(nvm|cam)' 2 1 0xffffffff811e3000 20db8 nvme.ko ---snip--- I will do a clean rebuild with the most recent 16-current and provide a full dmesg if this still doesn't work. As a module it fails: [1] link_elf_obj: symbol nvme_handle_aen_desc undefined [1] KLD file nvme.ko - could not finalize loading Bye, Alexander. > F -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_a1d23432334b461710ca90b104d8b2e2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2025-12-23 10:31, schrieb Alexander Leidinger:

Am 2025-12-22 17:58, schrieb Warner Losh:

 

On Sun, Dec 21, 2025 at 8:37=E2= =80=AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2025-12-14 14:05, schrie= b Warner Losh:

Let's do one issue at a time. There's too much missi= ng info. Top posting since there's  not a lot of context to this reque= st 
 
The disk died now completely, so the CRC errors are out o= f reach now.
 
First, let's start with pciconf -l of the nvme drive. I h= ave a strong idea, but need some data.
 
While already provided privately with some other data, he= re for the public so that people are aware that currently there is an issue= with such drives:
nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 = vendor=3D0x144d device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801
Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V
 
Yea, so far this is the only report I've received, and there's not eno= ugh data in it to reproduce it with any of the dozen NVMe drives that I hav= e, or to spot a difference with what I know I check in the code. So if it's= compiled into the kernel with cam also compiled into the kernel, I know it= works.
 
CAM is in the kerne, nvme is loaded as a module (from 15-current):
---snip---
# kldstat | egrep '(nvm|cam)'
 2    1 0xffffffff81= 1e3000    20db8 nvme.ko
---snip---
 
I will do a clean rebuild with the most recent 16-current and provide = a full dmesg if this still doesn't work.
 
As a module it fails:
[1] link_elf_obj: symbol nvme_handle_aen_desc undefined
[1] KLD f= ile nvme.ko - could not finalize loading
 
Bye,
Alexander.
F


--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:/= /www.FreeBSD.org    n= etchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
--=_a1d23432334b461710ca90b104d8b2e2-- --=_5b8398f92dd80349ad073fab75fdfec1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmlKpMAACgkQEg2wmwP4 2IYaGw/9Ecuti7E8hQwbANj4zuLKfTcxH5L79nocGFG2Ui7o8MaZWLM40TMK2zCv yPRo3dmChGEu23gO+nezHH6cy3QBsfbI5J1BoQ9UnVqR9JPzCBXeHRQXfdxc2hf2 q3zQ3JTHccVwhdFxkfagJ5EH2M/7JrectWwff0jfanKxMLOPlP7je6QY4degz0z4 wuBVmj/g2Yl+pn74ZZxtzY+gygiXWdOPPgPe+NWdXHSSUaaUsnbkLPkqI1DIrktf 5xgjm4krIXa2BBXl9wUPWlXkU3To0q/X6PSJR/4KRohwaUU7Ru6bLUVVLA7hW2Ou YW0hDa+5tYYwzIvt4TVd3+Tq5xRvkYEK4QqMbrV6qA7B6XShfNQMucQ4/egN5t8O OK0k0NRv0+iRr3c2BYwyDhLQAExfnNEtDIydX/mAsQP32aNpzZ2esP8U9dhfDHnd LrO+2ZRT9u0wpZwnnp7BNiANabW2D0Wz1kTlniC+w0iH69w3GidNqsGuST57AZiL cYkekj81HUQEZI40ROy85IcZCjjcl2e6D8Az+LRFOD75Wld91Y/zto8m5b4I8bvO sl1XeTAYORAcmREgm6oEb85nkjwxsMEAIJz947JLp5f5EV5Q8QgdFXZp7NGt7n47 N6MpgJS0XSBDdk1zdw1PpkW9EKU4RV+jN+PBg84RJznJKXhQLnc= =WsmL -----END PGP SIGNATURE----- --=_5b8398f92dd80349ad073fab75fdfec1-- From nobody Tue Dec 23 16:04:00 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 4dbKZW3xVpz6LfXP for ; Tue, 23 Dec 2025 16:04:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4dbKZV6Kxmz3Kgr for ; Tue, 23 Dec 2025 16:04:18 +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=1766505854; bh=kIXE3V1WKTnh1A2+m/m00hpdckLFkZEJL57G1zkxu1w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CqOEmjNRXDYP5O5WKu3uojEdugrNU52Jdgr11HkcjJdSIrIubA5CKG+V+bZ9sQ/Ce3cSwHdqG1rbUS/6awM9fDDHuGsxwH1fEJhFQjCrfNGHF/jOoUzahirgOfbTQlQCTI3JPZCc+GzVjLsqe1IuTtBd7OXbQ0GpFy0CGa/8LDc4bWxFW4+x7F2soZsNR0Ofb1bsM++Hue5hU+2sR4tnCBkizQ/Gsl8My+QMGCN0NtEwE4oLitPghNj/PLDzMJE23Zgv4tDDOD1xtEqFvgXvEJEduEPqnyAgV1mi/mFfGuM+18B2OOdg7hJe6FTSze/gx+gR++bfy6+LQQV6fYCIVw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766505854; bh=5VGPyZljefi4Ov/9bll3TAbz3ek/wLtH+d0duThMilS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Nx3TqL0WwRr88SxJFTk3/a/NcmSnR/9GndVc+oiXo6DEYxqId6dUCro6q8soItURR3DgOlee/QR/Quomc8q5v5QvNm0TpLaKSAvDmrYn5A+0XJpZTIwiq24rG8i9Om/ufkLXZVxA7pfO7OiKI8R23OZ1rWLzutr4LPRWpJjpHQtnOYdE1Xz0Q8np861qR0dJGkowtFifxArR83CUjYFGwkgCak7/P1U4PU1nH1tCgoJ5ry5MpbsHfUqIvkvYQqFD2PIUe/qROD9H5feCQvFvqnwAyn+cqhxxWzbrQuAVgZAcqd0yqONl3pjgVVUvEOEUXALQL67S4qlgUgBk+4iECw== X-YMail-OSG: WHpJh5wVM1ndW5XkQWqEvD_7bb5sKLJSUgGYGVqe7YBQkiIXiD8meZl2y9odVhN NnMM3Kzh3QJwJsdAvwhQFGsS8ZqByQbi3e6HC3JdGO3oIWffMIxE2ImvE7J6HZph0OJB6F7CByyC .Q3YQVzsIn3vwQXVpFupURF.bWDCV1jv4elURWd75cergE_CKVA6ihrFzWxy.Gb6Sb_Fj4gXDBWb i6dBtXEfgESXom_RaccrhMZR3t6fJBT875BR3qFVqWoZ88mng22.KUW4Ewjr3.2xkFt3w_5bQYm7 Yrb0tH.2CIpU5ERMemiK6CxLISppiDRMbqDdBLN_eMhwHZ72ZpL_yWXBfgD3El6k60fBCXcgBeW7 8crmsCMz.XMW2p0GyHyTjiBg9Q6CZmr0C3FRwVPYkOiVeCI_RNJ4mevcLhMmrWFW6ETfseKHm6Dg ckaaWgk6X8B3ncff5QcIN_GKb4v52TGXeydyY7j9SKZnrCIbnPMQ1O4x3eisvPEgPux7Q.8cQ.x5 IJngxjU27Ia3kNu0eyvry1viNG5RCwx44Gby8ffA5SkOWQZFJPqtGUr5Xdu7YixrRnduoVlx7Xrn VEODPzrutQjr6pHig3g.HxFpIhs_Jx0rSshzPQZRZhYF5FvjOXu0B35w1MFnelmjyBATf2EapErC e.lN2TKZ1td1Ph2dev0GPvHpbrzE0xPuIFJqLkXSTwmwpiF7WS2N3UCasL8HiHmJR8a7xJa9NCOh SdhHv5CLpLQfrEU59D7te0hH887_5uSh8PdH5HKAdQLw49iaJ7OhHVd.OSlTii.a3qhNu_EOhwFJ Dt4p0LFmHdI5S2bnCL_DZhV.szlo1v3u30JHwIi9RJj0EOoKAgGmBwl4aPryrpBLi.bqfiEBHCW5 8_JRAs0anA.sEz_RbqlsYWRV3hM8RMDGLDrM0JHzAQCAbrryA.bRG3sZgdhGSMWzc8JCJhpqJFK0 pUyW1CckWx15nJSURbYvjsJQ5j_W_ZxoEBy7WFbBSAb758Hl4qmaIdT41geiXvRVAHr6bfoX39iU hWygW6piKCrXuT5ODQbHMWoHhrtEswIuauerF42DRl4PVnpzH2IQ2EHUrxPKYAyIl.cX6cBVap3q 6YOqkdfqOb8hOD7x44ekJfYv.oCDfxzm2aXygQ0EWJ6nseKxrVpqdU3W0KxDlZ5_Yv6YBSJbwO4j cJVZp9BpNEZGJc37.VkwsZLJfVB87rpw1pt91OVg1xOHEuU4vznGh2yAGdWaQLqT_tTg2NLCB6tX TxI4oWi43WaQOgFJNXPk.vFfSdR29FoAVE.dcmcwrloLbPQTkyBYp7UK08QgW6XnKEN67uQR1WXz DbI08cK5PnB3yGqgfhbTk17d6z5b_PjDkboaLJZk3HTXiZbUUxJ5Dea2BJWMAGkQIThm36.3LVOR u491N3_Y5db0TXLbZ8PttD2nLX8sANZavqnhNa_62Aj34InItGc2H6U79f0GO8MjQZQl.AZOrB1. oFqN3rAqENxc12rFE0AREjB02OemwMGissi.V1JtSM_jfXFIBrXGJFCJrW0fawcxQtT1gj.as8_u 7E02ENAEIvNK1vDKW4bxFc.yOBvk0r.AxI5nwOHLzqJqyWjPyaCmwrFtPfgsUY9h8RZ9htwlLFD8 TiiQRaOaiUZnomuvMt.bdXAAS1aOE.E6395BnSGOSTCyS46HwBdugBplJrrsfs9A0GLJilbW.O0n AkHjjD0j5EXiRbDUQ3Fh3npBmnYeCuzRAnGcJ9G4hZH0vxHzb4DLLR6M1iXw29taYecM0cFqE4As CKgf2qn9kG2sCGIPMAhhVX2QdzgZ3negfLoE6OYsyy1XUyiAjrtiLmtzWMVnVrUQ2LDN.Tt66owi gho8abf4xvJd4i5hE_oVs9whp4N2u2bPHqSta0Qu7iCeZUAsxliSFKtAnOqecQW7eqEh2_N9lNSI hHNL50p3EQUiOqeFWuHyENRkKxelQSahXgrE10RB0nSmojRvXiQFdhzcM7lLnowYmUawbL0OMFkN prJ538Pyus9pHxr0lxPhxHcSGN6Fx4rS9569sSy83V4FNRrngVdS5Slt4OsaN_4g4PTMSWpjgBgB .5kuCOtU3tkJAukJBk_xA8Yr2o_slzJYgXujqvJw.M4.JR85e3u9XbcWPsz4xKWpTueZj00RdNGO zcL0uTEEDA11n2DXm2RUM1U0ewDer4nCX3QtteNS7EXzfdC14WE4nsN7jXzs1QR5_9faDnR_NWDo z82qgrB49GR4WVq1SGbzk2A9nbUsu8pwpqqBL8OjgAW34cTzCSb53eLYSDkXU3F7.ys1zFG2NyrE yGw-- X-Sonic-MF: X-Sonic-ID: 1252b83e-55ec-4093-a7b4-1de3378dd4ff Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 16:04:14 +0000 Received: by hermes--production-gq1-54bf57fc64-fqp47 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d34683351e8680442c76bf957eede111; Tue, 23 Dec 2025 16:04:11 +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 \(3826.700.81\)) Subject: Re: pkgbase and customised builds via ${SRC}/release/release.sh From: Mark Millard In-Reply-To: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> Date: Tue, 23 Dec 2025 08:04:00 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> To: Alastair Hogge X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbKZV6Kxmz3Kgr On Dec 23, 2025, at 01:50, Alastair Hogge wrote: > On 2025-12-23 12:22, Mark Millard wrote: >> Alastair Hogge wrote on >> Date: Tue, 23 Dec 2025 02:54:09 UTC : >>=20 >> My notes here are limited in their coverage. I've >> not done the type of thing you are trying to do. >>=20 >>> For years, I have been using one host to build all customised USB >>> images, and tarballs for all other hosts at home. This is reached = via >>> custom make, and src.conf files, which are codified in a custom >>> release.conf. My custom release.conf redefines load_chroot_env() to >>> setup the environment with ${SRC}, ${PORTS}, and pkg related files. >>>=20 >>> On 16-CURRENT (2-3 weeks behind) I am able to use >>> ${SRC}/release/release.sh sans customisation, however, when I start = to >>> introduce customisations, the build never succeeds. At the moment, = the >>> build fails at: >>>=20 >>> make[5]: stopped making "create-kernel-packages" in /usr/src >>> make[5]: stopped making "create-world-packages" in /usr/src >>> make[5]: stopped making "create-world-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[5]: stopped making "create-kernel-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[3]: stopped making "real-packages" in /usr/src >>> make[2]: stopped making "packages" in /usr/src >>> make[2]: stopped making "packages" in /usr/src >>> make[1]: stopped making "packages" in /usr/src >>> make[1]: stopped making "packages" in /usr/src >>> make: stopped making "release" in /usr/src/release >>> make: stopped making "release" in /usr/src/release >>> pkg: Unable to open plist file: >>> = /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist >>>=20 >>> I have no debug enabled options, and am not interested in debug = builds. >>=20 >> pkgbase has been including debug symbol information >> even for non-debug builds. But they go in separate >> .pkg files that do not have to be installed. The >> bias seems to be to allow somewhat readable backtraces >> for failures without having to rebuild, just having >> chosen to have the information present by installing >> it. >=20 > I am all for it, right now I think I need a way to disable it. My guess is that pkgbase does not allow avoiding the debug symbol .pkg files' production/inclusion. The choice is likely at installation time only for if the debug symbols are installed. >> (I do not know if dist tarballs now do similarly for >> non-debug builds.) >>=20 >> Just having debug symbol information for backtrace >> or the like to use need not be considered a >> debug-build: no enabling of adding internal checking >> for problems, for example. >>=20 >>> In the past, when I needed debug features, I would edit the kernel >>> config, and src.conf files, and start the release build process from >>> there; I do not know how to parametrise debug build options. >>=20 >> Of course, you may not want even backtrace information. >>=20 >>> What is the method for using release.sh to custom build a pkgbase, = that >>> also supports tarballs, and install images? >>=20 >> pkgbase and dist tarballs are mutually exclusive ways >> of doing an install. pkgbase does not have to be >> involved at all for 15.* , for example. (pkgbase has >> its own way of dealing with doing updates as well.) >>=20 >> Related to such, root/release/Makefile reports: >>=20 >> # Variables affecting the build process: >> . . . >> # NODISTSETS: if set, do not include dist sets or MANIFEST >> # NOPKGBASE: if set, include dist tarballs rather than pkgbase = packages in >> # disc1 and dvd1 installation media and build VM/cloud = images using >> # make installkernel installworld. >> . . . >=20 > Whether it is a generic, or custom build, using ${NOPKGBASE} always > results in a pkg failure: > -------------------------------------------------------------- >>>> Install kernel(s) GENERIC completed in 6 seconds, ncpu: 64, make = -j32 > -------------------------------------------------------------- > [...] > --- disc1 --- > env INSTALL_AS_USER=3Dyes ASSUME_ALWAYS_YES=3Dyes pkg -o = METALOG=3DMETALOG -o > ABI=3D -r disc1 -o REPOS_DIR=3D/usr/src/release/pkg_repos install -f = pkg Its having set ABI empty . . . > Installing pkg-2.5.0... > Extracting pkg-2.5.0: .......... done > pkg: Unknown OS '' in ABI string the above complaint about would not be surprising at this point. ABI strings look like: FreeBSD:16:amd64 FreeBSD:15:aarch64 The FreeBSD part is the OS part of it. The 16 vs. 15 is the version part of it. The amd64 vs. aarch64 part is the architecture part of it. Not that I know why ABI is set empty as shown above. > pkg: Cannot parse configuration file! > *** [disc1] Error code 1 >=20 > make: stopped making "release" in /usr/src/release >=20 > Or, >=20 > FreeBSD-base repository update completed. 269 packages processed > All repositories are up to date. > pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION = as: > 1600000 That suggests that you are using main [so: 16]. In case that is true . . . I'll note that official pkgbase builds for main have a non-debug kernel prebuilt with its own /pkg file, that can be installed and ends up named: /boot/kernel.GENERIC-NODEBUG/ (This is the first type of official non-debug build of the kernel for main that I know of.) By contrast, for main [so: 16] /boot/kernel/ is the debug version of the kernel. (Those names are specific to main.) There are also for main what can be installed that end up as: /boot/kernel.GENERIC-MMCCAM/ /boot/kernel.MINIMAL/ However the official pkgbase build of main's world is a debug build that does validation activity. There is no pre-made non-debug alternate for that for main. In general, you can build and install your own kernels under your own names and have such booted instead of the official ones. Reusing official names with non-official content could lead to confusions when getting help --or at least require remembering to document the context explicitly. I'll also note that /usr/src/ and /usr/src/sys/ (if installed via pkgbase) do not contain git repositories. The two have separate .pkg files in pkgbase. The /usr/src/ and /usr/src/sys/ combination for main or a stable/* need not be an exact match to a single git commit hash's content last I knew: the two parts were generated at distinct times and commits can occur between. > /usr/libexec/flua: /usr/src/release/scripts/pkgbase-stage.lua:47: > assertion failed! That line is: assert(components["kernel"]) > stack traceback: > =E2=96=B8 [C]: in function 'assert' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:47: in = upvalue > 'select_packages' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:101: in = local 'main' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:107: in = main chunk > =E2=96=B8 [C]: in ? > *** [disc1] Error code 1 >=20 > make: stopped making "release" in /usr/src/release > --- bootonly --- > --- installconfig_subdir_share --- > --- installconfig_subdir_share/timedef --- >=20 > make[4]: stopped making "installconfig" in /usr/src/share >=20 > make[3]: stopped making "installconfig" in /usr/src >=20 > make[2]: stopped making "distribution" in /usr/src >=20 > make[1]: stopped making "installworld installkernel distribution" in > /usr/src > *** [bootonly] Error code 2 >=20 > make: stopped making "release" in /usr/src/release > make: 2 errors >=20 > make: stopped making "release" in /usr/src/release >=20 >> As stands, the above indicates that to get dist >> tarballs you turn off the generation of pkgbase >> files from the buildworld results: it does one >> or the other way, but not both in one run, for >> disc1 and dvd1. pkgbase generation does not have >> to be involved at all for those. >>=20 >> (You were not explicit about dist sets or their >> MANIFEST but I listed the line for that as well.) >>=20 >> I'm not sure if you might only want dist tarballs >> and not need pkgbase at all. pkgbase does not >> have to be involved at all until 16.0-STABLE . >=20 > I want to move to pkgbase over dists, however, it seems I can not = manage > either yet. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 23 16:34:51 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 4dbLGD1y4Gz6Lhkb for ; Tue, 23 Dec 2025 16:35:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.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 4dbLGC3CxVz3QTV for ; Tue, 23 Dec 2025 16:35:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rbdrxQzZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1766507708; bh=LZiRhv/8fgDRgQcM08IyC4iEyT1m6lImjo+JWmmf8p4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rbdrxQzZenbTB0sm1EhgBbg22JMbNBsK2vb+HVUvKD79a8gh1pGvhsa1qxja9uv7GMlaC2Azwfe9vaKhKrrU7aQnetxPq6puoEqtJSGi1Qv7rLSseuM3PyDJYDLZ7476FNStWXkFugLiMNGVuBRjO1o1YPMsHeQowB25mo09IvRnxZVr5vN0Qzudi4tMmAgD5hPHPH59CVPC1niwLP8FQoAgyoF3WtpDTioEI8hZDpxzJHt3G8Uzv0L1BloOhk9F47jnZKqs4+zcYBOiJw5AE25qFmlu1mcJZMJR+JMbCD2yrHv2KrXZtXzoVv4xgPRtwlEEsEErXf/fS2hlrTL4Og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766507708; bh=zqKrRw3F5/uyD115eqVlCIVu1M66cx6KV/LfdvFQzRX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=X7iYtGMTTvGmnKsPZTvpK+qSg5ZOdS4f182+WkwwijLEt/mtUQ9GuUr6JNyfOJyrrICUCV5Ua0hREE1OvIG1ozRDZRjt+aY3JT4NmcJP3nU1PjoMGt2uJ9BLO91YnbwJnQ8d/Bct2hjbX34Kb7W1xwwrzqUT9NIU78jnih2dfUoNx6WuxCJurg0wBGd50D0zoTDxK3sjwj/dkE9AWTV/wGwsoQi8u90iwGwK8PCPo7TP/OhaeCC6PagkHFyz4qvuVziflnuIM6CNabOuaHOtoX3zaZxzGZkyQ4rTdqR8U1+YIKJfcjewVKBlyRXyCY34DJlDt/Sk7ic52QE9E5CHWw== X-YMail-OSG: 97XcLh8VM1ngx2sUUKJc8c50RYL1OTaAijqy5ph4j82cnfk9JuD4iKYNKid1Xyd 94jv62JRvPutePZHWxoELla87GwkuKV.TeyADbQi4Qkmcm4r0Va6fqRp2L21RKqBNtJOUS3v8Kot pjk8UcNVd.3VT8FFlDrsx13Bta2o3jN664ssJJKB31nVxvzZ3WjPDBW0be441xF6D614FC7hgS5b upSgm2sLu8Ca7tdX_sTyakw.fquWGDXAQZLwBI5CKLpZ.fb1EZgPsp9Uo1owU63brndpS0XR3AML eWBMH6znTdbdz_5uez_jSEctPcbqsxlraavWX1ofH_29_9N75poWp1KlctPZ2UlaGiX8OSEcek7m 7tAtpvDydcVaUnITpuDNRg7FJf2QLZz7PRFvh4StkiV1qkkkYExXB1e12ogYMnbkU0VAfS3ENG5c VssoGkvCNiyMjQky7J2P9UfwqJrKGVBrXg62WR0LVgMpOysnBGDrmKoNeKEVOHECNU8AJp9orJ99 2OOZ_YORQFN0AtP71bgOAthg.hgJT8xB158luq1aQCoqkOzp2NgzOcdusb00h6HPTjJ0wsJuXI8e EMpGuEAs7pqjIhWAijpc2wfteWwi9HnMNt8dYTuOFQ4LXC..sd5h6iKtXaS9BSEeMsfuJLmbG4Ib Z7v779Xc_8D5pNqqPgaHaJEuH7J3wisrW_mt13zpIUfHHysIpqzeLVS8oJNmjyXqbJpORlJdGSft xw5E5zrFFF.gtkhaQ6m5MrSXLHtyEClIzRN1gnsaVcrQT6IoeR3Gva4kbUiHnGWTjWSSNJnAcHh_ dRGSiJ3z15s7Al2sb9REx1JKxkIgKauNoQWgcX9V8aGPeaZT2aw4AzBqRKEUYax30yqR1F1U2oEv HiskYA7k9nkk1c7yBt.GdTUydm5uPKGHMeo7gdBuuq41a7t9tNZzLqrCTTggEOQ99mOv2YaHxfxI 9v.67.cdMAqz5yUlN.Ki4RCH229iHI0CesrVjl11ASuj3AjWhqMJJbzu11Lff8wboQx2AKnb9I9d 9n4tO8NYvPi7vhARoQ8qcW0y9NN9QN1X27fRILAW9TppwTecC2gDq_UOEtuoLVZeU2WrzHKZrnG2 WpQOmXBqTQ2p57K9VBZ6MvuW9nupIjxAcms4XO1_GYK0MOJfUt7R4xy.a1mvxZKQj_bup2OyK.bQ w8JhcJm1iWoQCY0rCuOZMSEIHAVa1JDnWAOK_aIcOgCxTCTj6ri89wKWHXZezXAS1dcXypI39ipu o1zXgTeCTyTqFrwbpMKcO9D3y7xAHwQmPOwdb7F8J9JcwOKZ6tHqkjSEKW2rNVDhf.UZGKmO17oj dacMsg3Yt_pbx6P1Ta0Sl9JP1VTtglFLVH9xu7YKYyW.69Ka3h_OUMICfuPF4e5C5bvlObeY74P2 XLkDX2dUKzHZVedRRPQRszW9glCt72aRyfxYCOXvLHsqfb89n1vguz04Tq9Vhdt5nFcjwr_7ZMHq iIs6Q.UAy2fTs4W9Cm2ELbutDd4sSFpKoBz88rpxl.q9nxNN57JVtnFn4YM9p_ZKhpoSQUmf6sxi GQM3IFPl2H7ogVWX84uca5dkNDCql8yip5Jmc1CQqKq1YYO7TGJ8PGKJO9XFoZhFiOf.f_tUOpXK oaeKPZsOkERqt2yrd4mHAyYRELjCARmt6zlSOGvycnMWWvWnFLCHdb33YzmzV2dG_bMkXQH1ohR4 Jo5tQ5u6BhwRNB.TVNrg94NYYS5fK45t9nW_oRNlCz9KhoON..j2QUkZwJcJJvIc2J3siMqwCMGB .n56YxCuF4NDXi5H2iVXEkkX_IcRM2iBa7f9FO_.qrOUieysxZwlGAVFnJKvcdpocR0E4PGkWdPc n9j4zOWZRBr9IUUDcXoEOaJwn.pKDjbox80Tzkz9MGozry_f797aLFRgyYinnxHRsWxdxCEga.8j rnlH16LnkSXuvQpkgtbnHRDS_pJ9M4CXMk2Xbn9th7KDtwxLl.jvQwUoxkuzgJjx2Qc9ZVxqkKdf L7xQ6VAqKwyzwWvcMv8JCNVc62JF.PnWNvnmDmCgy_cXFiRJrsJ1IA4mYdhAyvWU9MTQjZWHeQ25 rjmo4zvfUtEVvMxqGaJ_k7tGvlxUnSxAha8GP0gB_2vTrNCOet0om1e6FMF8GZxRenYGd3J6ivPQ H9d4hRAqBXwQNipk0fcxrwUOPN475pqC1PG7taO8aWh4RX0G1HQ4G5oTQuxki1YGtDSzQnjaNqzE u05Msnb.zY1yF4_mDuS9M1areHpJAvlWecGaa.rJu6qKVezgQeBmKGcF6kNaF77u3qf0vnb5JZT5 4kw-- X-Sonic-MF: X-Sonic-ID: 49600287-2093-4ba8-bdc9-7dcee51b430b Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 16:35:08 +0000 Received: by hermes--production-gq1-54bf57fc64-7shwr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 194a14d90870ea8c907547baa3727546; Tue, 23 Dec 2025 16:35:02 +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 \(3826.700.81\)) Subject: Re: pkgbase and customised builds via ${SRC}/release/release.sh From: Mark Millard In-Reply-To: Date: Tue, 23 Dec 2025 08:34:51 -0800 Cc: FreeBSD Current , Lexi Winter Content-Transfer-Encoding: quoted-printable Message-Id: References: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> To: Alastair Hogge X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.98 / 15.00]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.99)[-0.988]; 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]; RCPT_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; 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]; BLOCKLISTDE_FAIL(0.00)[98.137.65.82:server fail]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from] X-Rspamd-Queue-Id: 4dbLGC3CxVz3QTV On Dec 23, 2025, at 08:04, Mark Millard wrote: > On Dec 23, 2025, at 01:50, Alastair Hogge wrote: >=20 >> On 2025-12-23 12:22, Mark Millard wrote: >>> Alastair Hogge wrote on >>> Date: Tue, 23 Dec 2025 02:54:09 UTC : >>>=20 >>> My notes here are limited in their coverage. I've >>> not done the type of thing you are trying to do. >>>=20 >>>> For years, I have been using one host to build all customised USB >>>> images, and tarballs for all other hosts at home. This is reached = via >>>> custom make, and src.conf files, which are codified in a custom >>>> release.conf. My custom release.conf redefines load_chroot_env() to >>>> setup the environment with ${SRC}, ${PORTS}, and pkg related files. >>>>=20 >>>> On 16-CURRENT (2-3 weeks behind) I am able to use >>>> ${SRC}/release/release.sh sans customisation, however, when I start = to >>>> introduce customisations, the build never succeeds. At the moment, = the >>>> build fails at: >>>>=20 >>>> make[5]: stopped making "create-kernel-packages" in /usr/src >>>> make[5]: stopped making "create-world-packages" in /usr/src >>>> make[5]: stopped making "create-world-packages" in /usr/src >>>> make[4]: stopped making "real-packages" in /usr/src >>>> make[5]: stopped making "create-kernel-packages" in /usr/src >>>> make[4]: stopped making "real-packages" in /usr/src >>>> make[4]: stopped making "real-packages" in /usr/src >>>> make[3]: stopped making "real-packages" in /usr/src >>>> make[2]: stopped making "packages" in /usr/src >>>> make[2]: stopped making "packages" in /usr/src >>>> make[1]: stopped making "packages" in /usr/src >>>> make[1]: stopped making "packages" in /usr/src >>>> make: stopped making "release" in /usr/src/release >>>> make: stopped making "release" in /usr/src/release >>>> pkg: Unable to open plist file: >>>> = /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist >>>>=20 >>>> I have no debug enabled options, and am not interested in debug = builds. >>>=20 >>> pkgbase has been including debug symbol information >>> even for non-debug builds. But they go in separate >>> .pkg files that do not have to be installed. The >>> bias seems to be to allow somewhat readable backtraces >>> for failures without having to rebuild, just having >>> chosen to have the information present by installing >>> it. >>=20 >> I am all for it, right now I think I need a way to disable it. >=20 > My guess is that pkgbase does not allow avoiding the > debug symbol .pkg files' production/inclusion. The > choice is likely at installation time only for if the > debug symbols are installed. >=20 >>> (I do not know if dist tarballs now do similarly for >>> non-debug builds.) >>>=20 >>> Just having debug symbol information for backtrace >>> or the like to use need not be considered a >>> debug-build: no enabling of adding internal checking >>> for problems, for example. >>>=20 >>>> In the past, when I needed debug features, I would edit the kernel >>>> config, and src.conf files, and start the release build process = from >>>> there; I do not know how to parametrise debug build options. >>>=20 >>> Of course, you may not want even backtrace information. >>>=20 >>>> What is the method for using release.sh to custom build a pkgbase, = that >>>> also supports tarballs, and install images? >>>=20 >>> pkgbase and dist tarballs are mutually exclusive ways >>> of doing an install. pkgbase does not have to be >>> involved at all for 15.* , for example. (pkgbase has >>> its own way of dealing with doing updates as well.) >>>=20 >>> Related to such, root/release/Makefile reports: >>>=20 >>> # Variables affecting the build process: >>> . . . >>> # NODISTSETS: if set, do not include dist sets or MANIFEST >>> # NOPKGBASE: if set, include dist tarballs rather than pkgbase = packages in >>> # disc1 and dvd1 installation media and build VM/cloud = images using >>> # make installkernel installworld. >>> . . . >>=20 >> Whether it is a generic, or custom build, using ${NOPKGBASE} always >> results in a pkg failure: >> -------------------------------------------------------------- >>>>> Install kernel(s) GENERIC completed in 6 seconds, ncpu: 64, make = -j32 >> -------------------------------------------------------------- >> [...] >> --- disc1 --- >> env INSTALL_AS_USER=3Dyes ASSUME_ALWAYS_YES=3Dyes pkg -o = METALOG=3DMETALOG -o >> ABI=3D -r disc1 -o REPOS_DIR=3D/usr/src/release/pkg_repos install -f = pkg >=20 > Its having set ABI empty . . . >=20 >> Installing pkg-2.5.0... >> Extracting pkg-2.5.0: .......... done >> pkg: Unknown OS '' in ABI string >=20 > the above complaint about would not be surprising at this > point. >=20 > ABI strings look like: >=20 > FreeBSD:16:amd64 > FreeBSD:15:aarch64 >=20 > The FreeBSD part is the OS part of it. > The 16 vs. 15 is the version part of it. > The amd64 vs. aarch64 part is the architecture part of it. >=20 > Not that I know why ABI is set empty as shown > above. >=20 >> pkg: Cannot parse configuration file! >> *** [disc1] Error code 1 >>=20 >> make: stopped making "release" in /usr/src/release >>=20 >> Or, >>=20 >> FreeBSD-base repository update completed. 269 packages processed >> All repositories are up to date. >> pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION = as: >> 1600000 >=20 > That suggests that you are using main [so: 16]. > In case that is true . . . >=20 > I'll note that official pkgbase builds for main > have a non-debug kernel prebuilt with its own > /pkg file, that can be installed and ends up > named: .pkg (not /pkg). > /boot/kernel.GENERIC-NODEBUG/ >=20 > (This is the first type of official non-debug > build of the kernel for main that I know of.) My wording is likely confusing for not making an explicit distinction between pkgbase in general and the subset of that the release procedures deal with releasing. I was not trying to claim that attempting a release build of main would provide more than /boot/kernel/ (GENERIC), even if the pkgbase activity internally produced a GENERIC-NODEBUG as well. I'm not even sure that a release build of main is something that the release procedures are currently intended to be able to do. > By contrast, for main [so: 16] >=20 > /boot/kernel/ >=20 > is the debug version of the kernel. (Those names > are specific to main.) There are also for main > what can be installed that end up as: >=20 > /boot/kernel.GENERIC-MMCCAM/ > /boot/kernel.MINIMAL/ >=20 > However the official pkgbase build of main's world > is a debug build that does validation activity. > There is no pre-made non-debug alternate for that > for main. The above might mean that you want more world tailoring of main if you are building main. > In general, you can build and install your own > kernels under your own names and have such booted > instead of the official ones. Reusing official > names with non-official content could lead to > confusions when getting help --or at least > require remembering to document the context > explicitly. >=20 > I'll also note that /usr/src/ and /usr/src/sys/ > (if installed via pkgbase) do not contain git > repositories. The two have separate .pkg files > in pkgbase. The /usr/src/ and /usr/src/sys/ > combination for main or a stable/* need not be > an exact match to a single git commit hash's > content last I knew: the two parts were generated > at distinct times and commits can occur between. >=20 >> /usr/libexec/flua: /usr/src/release/scripts/pkgbase-stage.lua:47: >> assertion failed! >=20 > That line is: assert(components["kernel"]) >=20 >> stack traceback: >> =E2=96=B8 [C]: in function 'assert' >> =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:47: in = upvalue >> 'select_packages' >> =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:101: in = local 'main' >> =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:107: in = main chunk >> =E2=96=B8 [C]: in ? >> *** [disc1] Error code 1 >>=20 >> make: stopped making "release" in /usr/src/release >> --- bootonly --- >> --- installconfig_subdir_share --- >> --- installconfig_subdir_share/timedef --- >>=20 >> make[4]: stopped making "installconfig" in /usr/src/share >>=20 >> make[3]: stopped making "installconfig" in /usr/src >>=20 >> make[2]: stopped making "distribution" in /usr/src >>=20 >> make[1]: stopped making "installworld installkernel distribution" in >> /usr/src >> *** [bootonly] Error code 2 >>=20 >> make: stopped making "release" in /usr/src/release >> make: 2 errors >>=20 >> make: stopped making "release" in /usr/src/release >>=20 >>> As stands, the above indicates that to get dist >>> tarballs you turn off the generation of pkgbase >>> files from the buildworld results: it does one >>> or the other way, but not both in one run, for >>> disc1 and dvd1. pkgbase generation does not have >>> to be involved at all for those. >>>=20 >>> (You were not explicit about dist sets or their >>> MANIFEST but I listed the line for that as well.) >>>=20 >>> I'm not sure if you might only want dist tarballs >>> and not need pkgbase at all. pkgbase does not >>> have to be involved at all until 16.0-STABLE . >>=20 >> I want to move to pkgbase over dists, however, it seems I can not = manage >> either yet. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 23 17:49:13 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 4dbMvx3tSmz6Lntl for ; Tue, 23 Dec 2025 17:49:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4dbMvw6wcvz3Y2g for ; Tue, 23 Dec 2025 17:49:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BzZxjGc1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766512165; bh=5P/7P8k837BafDku3h2C6wclsLNrZTH7oSHwlZdvxxQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=BzZxjGc1czS5QJEYAvFWvSmaF8XLOQ6z+CbgqvyjsIAnhWcdjP5KGRpy621SofxYYo6q3C+GeazHcPccGHRbzFHzE4AhtRcE3ZZkkZ2wQ7ss9qSdUtJD9VerSDHpw8y2T9ymzMyBiUfg6yNcoeDvOY5ouLyFrA6HyRHB0qjHTMjBjLm/nu/DFB5y4D6QE6LGf1JCCkh40X4PRDaqKRY5u3j/1Ue4HFFNOoxuiAegL2/vjJCDzygzgxYNKUW8JTUMKhihedw7petEuqCaiCV0HfvpG6KHjbeZELt/iaza2aKSuQTT01T5kSn+AR+vQNmDVC+SN9OARdXQPWwcO/kXvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766512165; bh=hopfckZ8eTGXxfZABxRgPsAuD2Kzy7JbfOqsGUyjubw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rEJyEW0sByztZOezEMIvOl31PhRRqTQ4Sl7esCSry7AJYPK8S3sYLBdetIlZvGUzcOA3ZwJfvG+dY8X26vu8Qj8ieOwmrZZs2zDzdvwKskrRNi9yosq3XzLEtV1jVZ5b8WeHtN3208NtCKfRKaxcWEQ0ZIKDY2gD/cQaIkSzovHqFrApMgM5vn3t0tqjmWRDWQZsRvL5NPxmm6TXqvh9aC1gynuvuROkzv+QtpmXyNo0ExUORdIyNhhMKYB1KdFr6K1YR3CcrtYbsFhi9sGA/ICqDTc191O43D8HI/D8AWC0CkRFfVKz+UZVUWYNHs4z4fAhStX6ozY4K/2p/+ciWg== X-YMail-OSG: zaZu43YVM1lGqt5BLRD9M_oYGgJX10juzCKyySyO83NqcWPS.FO9Iyzk894Iut2 FHmMyxZPVUf_G717rleWvWlwCkDc3VSiGjNnH3XH4Ix94Q6.jVjwNVZ.rqDwnXFyHa2nbdK2wsMe xm9a5CdcI4jVJDnzDbbv.24CeU88A80QMy3CjZml2PHHXroPl9kEaEssYiqm9RN06fQZgn4roSUV 2AzL022vBv3lgUVBXt3Sys.Vdar7ngqT02qS5JgSX_NeAVVZrH9Yq76NI8M9YTBJcFMIvFhdXIgQ ebcORTY1byisJ37PBo0Van3bG55.rET6mBTZbkcw5IsLC8t_YpvxYiDdAYMmvFio9J8gUk6hMBsg pvxcROGaZxPivldPPF7ya6PlkS71Q1uhpJd0rtbbuDvUZavVVI4CrKjKnjtnBmRORdjqL7IqQ13u JmzYP3yLsl_MqJGWaAgiIAMpEI1jxMw.y6vInbz8wEPRnlpuSPrRg.IvLGePJkgrpN.CEYL.9kYM viUDKDbfxHcseR4vGJuwXqdgWJKZASX26WGKhD_5uUFsXl9ZU3uADa_UwIaNslF3etApoW762GBU uJtwBRjmLDNgN.TbxLBDmEBPY0JYsYfxHe9slYm7kAGxTV9PURlWup4ic1_fwhM5TOa07TkAM6Ru b7Q3t1pt27lk0WflSAhkA.7ta3_Rmm_uXFOhlLYX1ArksxdZQK_qB3lghiK.2vuKW_I0bVpcXuxU gcsI8qGAoBBcUlJa0WSt0MNGpxNHbSFEONsQuzr8jjps.i9rZWeIbxC5TNvka1kPzScIJusr9otB vTG9Oqc1h1zDIvhDPEmltPA04Ot_JWvDrjckFv1zVwB_TgDFCshROcnBN3YLzwyF5mTpqRduehOX zXtbbHZ_X0uJz1NTN425kix0TmMH7f2CKvuiG5tMnvGU4lESs69wnzWsgyAofJdpXOeOwUj5fpBD AZp6ntLA25KpnKjgvMrFUS0ro4RnVSSkYzu4pgyhTvwTYJ0w25doiq3OOnvjVq.dWNUAh_NsQJN8 nGoNtmtDxGJVVe0tiKUjFZ4T5yKQvCE53cXjJ91rZvgtuGqZZPiLOmbb5vAb2giJzPl47_tJb.M3 ded_fN7JprOxwb5PjjWPlUPzV2o6rZC735kLQ4OJZJ6jvKh6WoACr7KSYs4XteAfR8iW.N6MNWxu IDKBgRuXeEcMSUAxCZOdLPflyljD8_W9vPA4JEjEzXjgnvzfaK1KMyT14Vf2HymrR25tdJLBSz8G x3VACb9OblZjSG_dlR6Eb0yNkJ.IX6cOyhflNEC04nldR8_iNAZZqoqN.OnWtnfWYDNedGfjG8Zt 97A_Q6ls4N9FAEtYpZh1_yg9FAl8y2mGVAeXs5VKimCC_ircauqdC0YegkSsTRDTmtUVsMCA90y2 3.2ARVkJaZ8HSpSzhLUqrfBCN3ylRwglhS6nAOgXeCFACLwvYILjexDLI2SCjT6ooTuyIe9meTme PQR5VB7Wz8Drgz34LRTrKnjPLzz2nI1yV87TRdJt3j5goO.4umclLa5FFTPC_Ybh0.sCNTYN72_3 3RVMq0VOj1XDx55CGzIWFpmFsLshGD3oYyRse6kA6DElL3spkP.KxFvHV4eK1HUIarHzCVB8lm.4 Pc.1RJQrr6_onROdT9x3WmzIei4MWN1I9uf7HbVwMdphycvcMHsoVOjjH5dasgbTSc6zkH.cledF NXjPqMN0mFKCKn3_5YOy5F3R6ZhK.3.156DyHAz4uq16.OADHiuFHIXi9E6i6a0hkG1Y5V6hORGp C3fSF5ctz458GHufiAkkXP4KlwCrw5pYkgaBCHZjh_kkl5FDOORZEYHHEc5oSR_dtxXSWfsgeyn7 9uAhB39dvX9ay4m.dQZiEFJK54d8ArWgubTFJ8rmWYLqydBRmWFD3vOFvfgx6jNdR4_KZvtQuSaW GyvCaMDn2UKIvaCn7nj6ibqGKLSzL7DWvsymqZJ6TSMp2T2lr8ygB1CbcJGTsg4kJA5LPCv3pfbS zGiZ36vcS6VuTAcJj0Io1zALZzCDVaSdLSVZZLKT40xa1d5oIzmryUL7Ta3_S4QhNLK2X0MC2Jsh Jd.rwGMide38H49mClwD7Q378uPktvlMQphwwl7wyd6Bk3vPTHyjOyzKBoaDlGHKMNgOYgsP5Mx1 Po1E9kuXr0f0zZikE2vTPcw3APW4JOARPmqOqR3SkiEBSK9Q.Ke.NN6hsELMi.o1doXaQHJQFoQX zuvHKHDoBE_PgQ3aq_GoTQUhLlNS3jsDn_Ofyqr97FYs1yOX_kT.J1uUNcIVBBonFcfexitWMwMy akjF0lcE- X-Sonic-MF: X-Sonic-ID: 1f3c73b4-aa5d-473a-9da2-02fe38b5bcfd Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 17:49:25 +0000 Received: by hermes--production-gq1-54bf57fc64-v95fx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b0e71bd2f4d0fddd7df5ca2480895e63; Tue, 23 Dec 2025 17:49:23 +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 \(3826.700.81\)) Subject: panic On aarch64 main: "usbconfig -d ugen0.11 set_config 1" panicked (data abort) on Windows Dev Kit 2023; kgdb backtrace included Message-Id: <6306A627-8052-4ADA-ADED-8CF68AC837D1@yahoo.com> Date: Tue, 23 Dec 2025 09:49:13 -0800 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <6306A627-8052-4ADA-ADED-8CF68AC837D1.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_SHORT(-0.98)[-0.978]; 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.65.30:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from] X-Rspamd-Queue-Id: 4dbMvw6wcvz3Y2g # uname -apKU FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282662-117306dc606b GENERIC-NODEBUG arm64 aarch64 1600007 1600007 That is from an official pkgbase distribution, not a personal build. Prior to "usbconfig -d ugen0.11 set_config 1": # usbconfig -l -d ugen0.11 ugen0.11: = at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DON (72mA) For reference for the panic: #8 0xffff0000005293e0 in vpanic (fmt=3D, ap=3D...) at /usr/src/sys/kern/kern_shutdown.c:962 buf =3D "vm_fault failed: 0xffff00000074c5dc error 1", '\000' = other_cpus =3D {__bits =3D {127, 0 }} td =3D 0xffff0000eb228640 newpanic =3D bootopt =3D #9 0xffff0000005291d0 in panic ( fmt=3D0x12 ) at /usr/src/sys/kern/kern_shutdown.c:887 ap =3D {__stack =3D 0xffff00010cfec1a0, __gr_top =3D = 0xffff00010cfec150,=20 __vr_top =3D 0xffffa00080cf7700, __gr_offs =3D -56, __vr_offs =3D= 0} #10 0xffff00000095ea5c in data_abort (td=3D,=20 frame=3D0xffff00010cfec270, esr=3D2516582404, far=3D,=20= lower=3D) at /usr/src/sys/arm64/arm64/trap.c:410 sig =3D 11 ucode =3D 1 pcb =3D 0xffff00010cfecb20 map =3D ftype =3D error =3D handled =3D #11 No locals. #12 0xffff00000074c5dc in in6m_disconnect_locked ( inmh=3Dinmh@entry=3D0xffff00010cfec498, = inm=3Dinm@entry=3D0xffffa00087100b00) at /usr/src/sys/netinet6/in6_mcast.c:604 curelm =3D 0x0 ifp =3D 0xffffa000870f9c00 ifma =3D 0xffffa000872cc500 ll_ifma =3D ifa =3D ifa6 =3D imm =3D imm_tmp =3D #13 0xffff00000074d840 in in6_leavegroup_locked (inm=3D0xffffa00087100b00,= =20 imf=3D, imf@entry=3D0xffff00010cfec4c0) at /usr/src/sys/netinet6/in6_mcast.c:1404 inmh =3D {slh_first =3D 0x0} error =3D timf =3D ifp =3D 0xffffa000870f9c00 #14 0xffff000000752550 in in6_pcbpurgeif0 (pcbinfo=3D,=20 ifp=3Difp@entry=3D0xffffa000870f9c00) at = /usr/src/sys/netinet6/in6_pcb.c:857 inpi =3D {ipi =3D 0xffff0000435dad38, inp =3D 0xffffa00087a8bc40,=20= match =3D 0xffff000000752590 , ctx =3D 0x0, = hash =3D -1,=20 lock =3D INPLOOKUP_RLOCKPCB} im6o =3D 0xffffa00087470260 imf =3D inm =3D 0xffffa000870f9c00 inp =3D #15 0xffff00000074a348 in _in6_ifdetach = (ifp=3Difp@entry=3D0xffffa000870f9c00,=20 purgeulp=3D, purgeulp@entry=3D1) at /usr/src/sys/netinet6/in6_ifattach.c:877 ifa =3D next =3D #16 0xffff00000074a88c in in6_ifdeparture (arg=3D,=20 ifp=3D0xffffa000870f9c00) at /usr/src/sys/netinet6/in6_ifattach.c:918 ext =3D 0xffffa000870f4340 #17 0xffff0000006834bc in if_detach_internal ( ifp=3Difp@entry=3D0xffffa000870f9c00, vmove=3Dfalse) at /usr/src/sys/net/if.c:1122 _ep =3D _t =3D 0xffffa00080cf7700 _el =3D 0xffffa00080376a80 shutdown =3D ifa =3D #18 0xffff000000682c54 in if_detach (ifp=3D0xffffa000870f9c00) at /usr/src/sys/net/if.c:1029 saved_vnet =3D 0x0 found =3D #19 0xffff0000006913e0 in ether_ifdetach = (ifp=3Difp@entry=3D0xffffa000870f9c00) at /usr/src/sys/net/if_ethersubr.c:1045 sdl =3D #20 0xffff00000033caec in uether_ifdetach = (ue=3Due@entry=3D0xffffa0008785b000) at /usr/src/sys/dev/usb/net/usb_ethernet.c:315 ifp =3D 0xffffa000870f9c00 #21 0xffff00000033579c in ure_detach (dev=3D) at /usr/src/sys/dev/usb/net/if_ure.c:591 ue =3D 0xffffa0008785b000 sc =3D 0xffffa0008785b000 #22 0xffff000000569bb0 in DEVICE_DETACH (dev=3D0xffffa00087534d00) at ./device_if.h:234 _m =3D 0x0 rc =3D _desc =3D _cep =3D _ce =3D #23 device_detach (dev=3Ddev@entry=3D0xffffa00087534d00) at /usr/src/sys/kern/subr_bus.c:2709 error =3D #24 0xffff000000569744 in device_delete_child (dev=3D0xffffa0008786e500,=20= child=3Dchild@entry=3D0xffffa00087534d00) at = /usr/src/sys/kern/subr_bus.c:1550 error =3D grandchild =3D #25 0xffff0000003175e8 in usb_detach_device_sub = (udev=3D0xffffa00087847000,=20 ppdev=3D, ppnpinfo=3D, flag=3D) at /usr/src/sys/dev/usb/usb_device.c:1253 dev =3D 0xffffa00087534d00 err =3D pnpinfo =3D #26 usb_detach_device (udev=3Dudev@entry=3D0xffffa00087847000,=20 iface_index=3D, flag=3D) at /usr/src/sys/dev/usb/usb_device.c:1315 i =3D 0 '\000' iface =3D #27 0xffff000000316538 in usb_unconfigure = (udev=3Dudev@entry=3D0xffffa00087847000,=20 flag=3D0 '\000', flag@entry=3D144 '\220') at /usr/src/sys/dev/usb/usb_device.c:623 do_unlock =3D #28 0xffff0000003161f4 in usbd_set_config_index ( udev=3Dudev@entry=3D0xffffa00087847000, index=3D1 '\001') at /usr/src/sys/dev/usb/usb_device.c:686 ds =3D {wStatus =3D "\000"} cdp =3D 0xffff000000e79000 err =3D selfpowered =3D power =3D max_power =3D do_unlock =3D #29 0xffff0000003205f4 in uhub_explore_handle_re_enumerate ( child=3Dchild@entry=3D0xffffa00087847000) at = /usr/src/sys/dev/usb/usb_hub.c:479 err =3D do_unlock =3D #30 0xffff0000003212c4 in uhub_explore_sub (sc=3D0xffffa0008767b000,=20 up=3D0xffffa0008786e49c) at /usr/src/sys/dev/usb/usb_hub.c:527 bus =3D 0x0 err =3D USB_ERR_NORMAL_COMPLETION child =3D 0xffffa00087847000 refcount =3D #31 uhub_explore (udev=3D0xffffa00087658000) at /usr/src/sys/dev/usb/usb_hub.c:1107 hub =3D 0xffffa0008786e400 sc =3D 0xffffa0008767b000 x =3D retval =3D USB_ERR_NORMAL_COMPLETION up =3D 0xffffa0008786e49c portno =3D 2 '\002' err =3D do_unlock =3D #32 0xffff00000032130c in uhub_explore_sub (sc=3D0xffffa00087473580,=20 up=3D0xffffa00087448a9c) at /usr/src/sys/dev/usb/usb_hub.c:547 bus =3D err =3D USB_ERR_NORMAL_COMPLETION child =3D 0xffffa00087658000 refcount =3D #33 uhub_explore (udev=3D0xffffa00087440000) at /usr/src/sys/dev/usb/usb_hub.c:1107 hub =3D 0xffffa00087448a00 sc =3D 0xffffa00087473580 x =3D retval =3D USB_ERR_NORMAL_COMPLETION up =3D 0xffffa00087448a9c portno =3D 2 '\002' err =3D do_unlock =3D #34 0xffff00000032130c in uhub_explore_sub (sc=3D0xffffa00080d88b00,=20 up=3D0xffffa00080da9bcc) at /usr/src/sys/dev/usb/usb_hub.c:547 bus =3D err =3D USB_ERR_NORMAL_COMPLETION child =3D 0xffffa00087440000 refcount =3D #35 uhub_explore (udev=3D0xffffa00080de4000) at /usr/src/sys/dev/usb/usb_hub.c:1107 hub =3D 0xffffa00080da9b00 sc =3D 0xffffa00080d88b00 x =3D retval =3D USB_ERR_NORMAL_COMPLETION up =3D 0xffffa00080da9bcc portno =3D 5 '\005' err =3D do_unlock =3D #36 0xffff00000030c65c in usb_bus_explore (pm=3D) at /usr/src/sys/dev/usb/controller/usb_controller.c:409 udev =3D 0xffffa00080de4000 bus =3D 0xffff00010ef84428 #37 0xffff000000326434 in usb_process (arg=3Darg@entry=3D0xffff00010ef8453= 8) at /usr/src/sys/dev/usb/usb_process.c:160 up =3D 0xffff00010ef84538 td =3D pm =3D 0xffff00010ef845e8 #38 0xffff0000004cc260 in fork_exit (callout=3D0xffff000000326320 = ,=20 arg=3D0xffff00010ef84538, frame=3D0xffff00010cfeca00) at /usr/src/sys/kern/kern_fork.c:1155 td =3D 0xffff0000eb228640 p =3D 0xffffa000824acaa0 dtd =3D #39 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 23 18:00:40 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 4dbN8r0NNxz6K5s5; Tue, 23 Dec 2025 18:00:44 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbN8q4LM1z3bg6; Tue, 23 Dec 2025 18:00:43 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766512843; 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=IIy0DMAomBZaNS3hZmtOVPKZ6HoFbpSoOMDp+Uy3YwQ=; b=J9Kz32ibP9jEPVE/wwolzAxvJd4Kq+sjUu81bpwwph8zLWWljTvS4ozLpjHcyD60bi3zpI J3FUfreQCY+PXC8tYpgz5tJ8Hk0B94NR48vB4ykEegW3GKbr9KdvXe0qG1LjzrFMYZBd4l wYOaU/Tv9tLt4ag8IdFtPFWgBTzTqhHgPevXlrGBQzZxKfESHkJ9+k83436r6vwQ3KsuIi p0xTI1n7Gaq/I4WuM14xa6x+/KTxSUZxnyoj1XglJLxQqiw+jaY9xSLRVif3GQw5rrUSSe NeVSvmzHIjW0P6uWP1IMIYWMf9hxyyItfWe0cDVQWolDOJ7mJQYj1SFvjQENHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766512843; 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=IIy0DMAomBZaNS3hZmtOVPKZ6HoFbpSoOMDp+Uy3YwQ=; b=isizawCuSKYgMjlF7uVxPZE5KFjrR7xrgNXxes8RTVst/cDDMBgzUqnTFM0zqWfFlLOQ7b ar79ggedPBtHtHcHp5mNN6EhZi7AzFbI5re9x8lC5MqIsPbGTnalZK9NP4xBnoPF7UGgIm O1b7vit7BfoFvw/MzcfmZh1zH9vtrcJ5i98kJIqUpuvAYbOIobALIJFhDUWZpwPHqRDPnY +IuETSrHhgHyCug9Wq7F2Xh4BDq4dwQI74pj2BsGDzV7Yi5IaaYLsnZaPqr1GUd3ZfeRMy vsPj1q2c/ezzBwmWaFG9ThIooV+hAcAZVp+Tls2qoqkc46yeqCm2mOP8ZIEAww== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766512843; a=rsa-sha256; cv=none; b=IDnp6p+WwGiwZjQdeU0ldvPN4cl9UaiiauWq68KUX3pJLv74xN8xF+FrE04wo0yUCWwhEg qtBTOBPcjwIyDJvrjwG7jtxmMJHao1ErsM90arGqD6FROpqcB5qX3eYaWnumqNOI/8o1QM mwEAtCABZCUT5OsobtPULAo+DGuZaNi9RSh7Xh+yd/cbK9uLhGnGUCBfJrZvqSaKdo58CK rGMl/BQKRkhvbo8/lq5dUpGBHjqn2Jp/zczUtcHn8gbKRu2IOHqNAo/rhlNUfhBeg253OT 8m4/pFwoy96+h3MO2k+gEBTZYU54J0Bf9OxPhujaDgcTQNrSDa61YOkKcn+WKA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4dbN8q15mZzkhB; Tue, 23 Dec 2025 18:00:43 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 23 Dec 2025 10:00:40 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: December 2025 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FWzt+dbNZo7fc1fv" Content-Disposition: inline In-Reply-To: --FWzt+dbNZo7fc1fv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 22, 2025 at 01:00:17AM -0800, Gleb Smirnoff wrote: T> This is an automated email to inform you that the December 2025 stabiliz= ation week T> started with FreeBSD/main at main-n282678-88b04633c29e, which was tagged= as T> main-stabweek-2025-Dec. Due to lack of human and computational resources at Netflix during the holiday period, we are unable to make our regular A/B testing in a timely manner. My personal desktop, laptop and home router upgrade experience went smooth, as well as several other people updated their machines smoothly. We are aware of two regressions worth mentioning, both already fixed after the stabweek tag: - The standalone command(1) as a script is needed Bug: 291879 Cherry-pick: 745c6c0431d01b4fc3247f4eac08a2181d71e008 - nvme.ko and nvd.ko fail to load Cherry-pick: 1aea5b0ba76a30cc9753fbc860c0f35a980b756b With that said let's declare the stabweek as done. Happy holidays! --=20 Gleb Smirnoff --FWzt+dbNZo7fc1fv Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQT+rgtjiRzq3LbQ3Nn+/1jAXQXMIgUCaUrYvwAKCRD+/1jAXQXM IqCbAQCY/t0w5s3HxAd4iiMbkCjjV1BySjILuZWJikfIhmwLoQD9HX3763I7qqn9 ihJU705OgFgoFk9eYeX6BFih92R6BAw= =HJu4 -----END PGP SIGNATURE----- --FWzt+dbNZo7fc1fv-- From nobody Tue Dec 23 18:07:02 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 4dbNJB07mjz6K6Hk; Tue, 23 Dec 2025 18:07:06 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbNJ96FKcz3fNt; Tue, 23 Dec 2025 18:07:05 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766513225; 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=yfafjcM0+HIHS1BSH5JUXk0vysp2tazT9bAUuIzxPw8=; b=xcd1cCWMGAagoto15uEnR12tlJDJE0/3vJGaMYxHf2BE2CFN3gaK8P7f/x4H8y++/1ixsE L/EuNQdXQ408KenmuSGAJqQqkAUjy+GynhTcjFi3j7LPsBJNQrfi75s/tQVOwZcGMk8JqW iBBkGps00titNghore0n4kpiKa9GiBUjgvdjtd3pz50OK5nns2VtMQZBhPdj/Ob9Uu7Znn m47pVbEcOrnzobJFkvOHCCfJVpv4Dgnx6DWDp+aD2lAETFjxc7oDOJmg1YEX9RK3URSlyU l/HBSFiBSLRrU1Vb5ol/y3h+Kl0BxroENM1sVdbSzlTSvJo4aNEJ0umky0hYlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766513225; 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=yfafjcM0+HIHS1BSH5JUXk0vysp2tazT9bAUuIzxPw8=; b=J0LeFErWAk+pTZuALtIvcYk6qPTXCWsMmPER9xOwJHLsEyHxBfjySrYmNGMg0BGnDkyXt1 HhhUCmUOM05aXcaTzzm83DoKqeOgV8JhVz8iVaAuJdwsPdyTtpAv9nryEKUD3NSyWbT7/M hr1NgPMmM/XACv9WYC5gv4ZtsBj6PgtiD9yQ8IXIDuBpz4GfdKGtnLjXaWNEXWELPyVdCv 8CVkJroiKosw0wZyrO2+3N4X1lZIfbbAWfXXRnuXHtx7ghIZcLXEyXaYqAOItPEbGTihJM q40aTGGBEM6tQbAsCJv9JASD0nPPksXZ08xXxX0hIK62+CkoMLP0OH6EojrUqg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766513225; a=rsa-sha256; cv=none; b=XLCJ66d98z+9XlHdB/xRlsE+OFNCzNZlSLRgVhCKg0QkZJWKH09jSCg0SXxLsleYkurbwB k8Dv8zheiIcaGqwL+UUB3s5+9GVrSOHHa18+UuIOd9yymvDQ45cmoQoTaN8e8wOVSq6JGJ Puf0rz/qVFXAaSPSsTzWMEpFMPy4DmVVAV9YNn6jT6TCzqo8eoQHM7xtNRoS2ehQXMNI+9 nAXxUPKRb3XmmpyWZDNJ9pgb9vjD6G6SaELsObqQdAUd3TeGo9bZB+n0bnpR9MCEamZvui mOzm9rB+rRNdkamayVcnZ3IGobv+A61gamtZf7E5SZMzr6mVEH1c8jb0fUf/yA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4dbNJ92fK3zkhC; Tue, 23 Dec 2025 18:07:05 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 23 Dec 2025 10:07:02 -0800 From: Gleb Smirnoff To: Mark Millard Cc: freebsd-arm , FreeBSD Current Subject: Re: panic On aarch64 main: "usbconfig -d ugen0.11 set_config 1" panicked (data abort) on Windows Dev Kit 2023; kgdb backtrace included Message-ID: References: <6306A627-8052-4ADA-ADED-8CF68AC837D1.ref@yahoo.com> <6306A627-8052-4ADA-ADED-8CF68AC837D1@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: <6306A627-8052-4ADA-ADED-8CF68AC837D1@yahoo.com> Mark, On Tue, Dec 23, 2025 at 09:49:13AM -0800, Mark Millard wrote: M> # uname -apKU M> FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT main-n282662-117306dc606b GENERIC-NODEBUG arm64 aarch64 1600007 1600007 Very likely this is fixed by 77939d64f23da4b0b599fad6edd967ffd1d17217. And was broken by 0d469d23715d690b863787ebfa51529e1f6a9092. Please update and re-check. -- Gleb Smirnoff From nobody Tue Dec 23 19:06:53 2025 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 4dbPdc0khpz6KBJW for ; Tue, 23 Dec 2025 19:07:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 4dbPdb3rb6z3pFr for ; Tue, 23 Dec 2025 19:07:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-7baf61be569so5684736b3a.3 for ; Tue, 23 Dec 2025 11:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1766516828; x=1767121628; 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=mTP19pfxq4nNARMjyGwBKfZ5nZ75gyc5gswX9BMFSmI=; b=2zd/EUWsySDPUtlQlLs0TfPlVeGhLva89VfFFFnDBXZ6aCO8vOTPNf3yYtXr1w/Aln dFOms91wevDTi+P4UpvbO+8np0lPl/6tCnI9BicKjEYwdKYYsvNtuqe36ly/x15e0iVP VtsAMQUReoei1yOJNo4xKfE1TFPHFFPVr1GWelrVXoaVDW2TDyoDJNGW5jFbDW0YjXxg HC1xiIBOYdgEZwiUZ1bZe9WvyubES+hR8mNskwGtGGqt35aqbh7SQmBO2tO+N0pFI5OK Nl6VbnVVuanNSF+aESroqbUTNxKlCbL+izvDF9RAqeMlaAE7YGRZO0r8eqCapYtJDWRp RIOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766516828; x=1767121628; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mTP19pfxq4nNARMjyGwBKfZ5nZ75gyc5gswX9BMFSmI=; b=vc0enu4yEbMndGhkqIGpzw70TRnEafEaqeWraSZaN6d6ANUy65jonyD3HCxoFFZf3q cJ0H/LTn4kB/o4OyZYfb5SSN6vmXwIAb7cc1R763bufcl/AdWEwQlVE/+YPjqVsUxUI8 7RdmYpE8/m632BFmiR1gvRlDg0mEcBgclerRNS0Pfzntxlth/XMKjLY3vP1EmJWQIc4d EZSIKPotFCXyE01SGvZTocwAorIyCCfSdPSOwCvFLAo++z1MhbG0uk+UAdkWZ6IGOuHa gCnrUHleuoEqQXqieUZn6A2rgJ0JhY0SWm9sIjzveGOvPr7Q+Y8pFJpx9q2kSXpJApY3 eXaQ== X-Gm-Message-State: AOJu0YzsiunDSWcQUECr6Ajqi4qkFwZGqxeoZb9xstgih/KRDva+cJQ9 8PqTzoM9RAeAhwrYVh0TBadJO712f5EQIiuGEKfpIQOu2jxdJRUc/jHowu1eWQOD+4B1RtGnOOe BGuB8WKARqUg/ud8ePQd4/kiFqyy9hZA/RwgaHopgHg== X-Gm-Gg: AY/fxX6c+ZsDx+2F6CB8L8sv4u/d6rcsvgvkzXvlZvvcfiiFXl4jXkkYfr2AewkVc2P K1O/CJy+L89tLGf0gcbLr+aQ4MeRFUHLUwAwcAMbYmWLl48EJmRv4UciO3r4MywI6wXx/c8Osc/ kUQNZRXmZbUftKin8EmmlYGn6kOZA8GWsPK557wz9Cmu7IzDRrt9RHAXtMmdNKlOygvc2JMR3kQ 5vpFSPXrIMWpJs5iB8H9a2UQpJIFfu0fGYDEIycWIF7R7T4jsjZ7U0Tz6EFl/o/0lfAD0kj X-Google-Smtp-Source: AGHT+IH4hGFkXlmujh4paAZV4TqFilXUYE0kV3Hefy13pIMsB2MWqJpEuXyiM5qC/ZSL8B+zzJrvwog/hyIBy0wM13Y= X-Received: by 2002:a05:6a20:5491:b0:371:7f31:17f with SMTP id adf61e73a8af0-376ab8cb3b1mr14529289637.77.1766516824668; Tue, 23 Dec 2025 11:07:04 -0800 (PST) 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: <198170948d34f4dc169e94934da82161@Leidinger.net> <89a92e0a926239e2c192dc0ff9c80d6e@Leidinger.net> In-Reply-To: From: Warner Losh Date: Tue, 23 Dec 2025 12:06:53 -0700 X-Gm-Features: AQt7F2rDf5mkWVxf7d6_X4kKsKyoKht5MIKeljg9-JLdE8g6KPEc_dWUqtiT0zE Message-ID: Subject: Re: Changes in cam/nvme causes issues? To: Alexander Leidinger Cc: Current Content-Type: multipart/alternative; boundary="000000000000d30abd0646a33f97" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbPdb3rb6z3pFr --000000000000d30abd0646a33f97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 23, 2025 at 7:19=E2=80=AFAM Alexander Leidinger wrote: > Am 2025-12-23 10:31, schrieb Alexander Leidinger: > > Am 2025-12-22 17:58, schrieb Warner Losh: > > > > On Sun, Dec 21, 2025 at 8:37=E2=80=AFAM Alexander Leidinger < > Alexander@leidinger.net> wrote: > > Am 2025-12-14 14:05, schrieb Warner Losh: > > Let's do one issue at a time. There's too much missing info. Top posting > since there's not a lot of context to this request > > > The disk died now completely, so the CRC errors are out of reach now. > > > First, let's start with pciconf -l of the nvme drive. I have a strong > idea, but need some data. > > > While already provided privately with some other data, here for the publi= c > so that people are aware that currently there is an issue with such drive= s: > nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 vendor=3D0x144d > device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801 > Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V > > > Yea, so far this is the only report I've received, and there's not enough > data in it to reproduce it with any of the dozen NVMe drives that I have, > or to spot a difference with what I know I check in the code. So if it's > compiled into the kernel with cam also compiled into the kernel, I know i= t > works. > > > CAM is in the kerne, nvme is loaded as a module (from 15-current): > ---snip--- > # kldstat | egrep '(nvm|cam)' > 2 1 0xffffffff811e3000 20db8 nvme.ko > ---snip--- > > I will do a clean rebuild with the most recent 16-current and provide a > full dmesg if this still doesn't work. > > > As a module it fails: > [1] link_elf_obj: symbol nvme_handle_aen_desc undefined > [1] KLD file nvme.ko - could not finalize loading > The kld problem has been fixed. Warner > Bye, > Alexander. > > F > > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --000000000000d30abd0646a33f97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 23,= 2025 at 7:19=E2=80=AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2025-12-23 10:31, schrieb Al= exander Leidinger:

Am 2025-12-22 17:58, schrieb = Warner Losh:

=C2=A0

On Sun, Dec 21, 2025 at 8:37=E2=80=AFAM Alexander Leidinge= r <Alexander@leidinger.net> wrote:

Am 20= 25-12-14 14:05, schrieb Warner Losh:

Let's do one issue at=C2=A0a time. There's too mu= ch missing info. Top posting since there's=C2=A0 not a lot of context t= o this request=C2=A0
=C2=A0
The disk died now completely, so the CRC errors are out o= f reach now.
=C2=A0
First, let's start with pciconf -l of the nvme drive.= I have a strong idea, but need some data.
=C2=A0
While already provided privately with some other data, he= re for the public so that people are aware that currently there is an issue= with such drives:
nvme0@pci0:5:0:0: class=3D0x010802 rev=3D0x00 hdr=3D0x00 = vendor=3D0x144d device=3D0xa809 subvendor=3D0x144d subdevice=3D0xa801
Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V
=C2=A0
Yea, so far this is the only report I've received, and there's= not enough data in it to reproduce it with any of the dozen NVMe drives th= at I have, or to spot a difference with what I know I check in the code. So= if it's compiled into the kernel with cam also compiled into the kerne= l, I know it works.
=C2=A0
CAM is in the kerne, nvme is loaded as a module (from 15-current):
---snip---
# kldstat | egrep '(nvm|cam)'
=C2=A02 =C2=A0 =C2=A01 0xffff= ffff811e3000 =C2=A0 =C2=A020db8 nvme.ko
---snip---
=C2=A0
I will do a clean rebuild with the most recent 16-current and provide = a full dmesg if this still doesn't work.
=C2=A0
As a module it fails:
[1] link_elf_obj: symbol nvme_handle_aen_desc undefined
[1] KLD fil= e nvme.ko - could not finalize loading
<= /blockquote>

The kld problem has been fixed.
<= br>
Warner
=C2=A0
Bye,
Alexander.
F


--
http://= www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:= //www.FreeBSD.org =C2=A0 =C2=A0netchild@FreeBSD.org =C2=A0: PGP 0x8F31830F9F2772BF
--000000000000d30abd0646a33f97-- From nobody Tue Dec 23 19:42:21 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 4dbQQS6qdrz6KF9S for ; Tue, 23 Dec 2025 19:42:40 +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 4dbQQS0bmrz3w9R for ; Tue, 23 Dec 2025 19:42:39 +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=1766518956; bh=9it+eBKtrpps6K9bZg2YIz8Kw0MzhuEzovdjfif/C0c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uXEeYyQLaFAxo1xaJKF3DuwwcZtlFj85R7I0UrCBOB0zkiGUJLtq/L/haeYrb67va0ivWtR6tHR0QT2Ikox26Q1wmkm29z6P9nDrijehTNGy+Nrzg5YqoCCL6d3Oh9khH5P/YKZDPfnCbGjA1stcDlfeGj+qT+fpPS2oDY6v6ofQnG72WLPuBqdtpaFmENtCtPTUQuq3AN97GiC+J7BYl/x/2dmBCcVBz9FWaoXAx7EVW17WbtCObI7h606Hzbq3F6m5uhSL5gkiKiqzkLVeEBKUiCP9KmZIcJbWusQlMJ+PDkXAbNu95U1elXyLc39wqeLntwa8vD1KsstebRfJ6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766518956; bh=f+w7ihT2//aswtiACko21LklvYD4VKsVU/nNWRqCYAl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=o/00hhEhaMbG1lRMXjN4Pzfn5KVNCFa1dCI/WVQBnHwcF5ks4NCo4mAFP27zGxnMgZDPexql2Ev2AmPhqFiSXnCffN7TiGOISAb16T9YkXHFVQitMqpC01pv0zs8Zk1L5xbXp+2AnyS7awyLXBVZdJoH+qVOm4bCEtq6VkSFnnHdiIpF/X2xc/f6wHEEK4RkU+j33N0y2dPFB4xHD2uVG7ES77Y6A7PumcVRSbXfsv9Nitlgvw0gSgjWv0bgPxfJBk4dTw1H48tHbD7fF4SoKWZsIB540U3/KmGVVS54to749QgYs7QNSmwCXjUYL9ll8qsLYqRwJNSvVJkEtypiNg== X-YMail-OSG: 6L2tzlEVM1mJyzeaWxEDtrjE7jJIAvtj7OeK2i3jxf_FjpcSZm6cEzIoePi4K6v PNDjEU5Cr6CjqLoqyzVvxBqxP2FiSl6tdUeUTmx4Kv7_ceBTIUIVn14lfW67bIatw2cIFz0oX1Qz YP95.8RniHyMGbdLnEjce14LgEFn6ltT4cWBWqvlH_ITMZrR5qJ9TM7bwWSW9QnqEIY70nUKXqgL qdKJSNLImq7FQ7dXkwUq25ceGj8RtGccYAV9gAduyedCVCeMjAf1_tVLwiqZ_tG7IfACLp7J2RvL RXSF_DCgEIQdpJlLw8ArYfXFlvma9kiLWMxyIwgFAg5FuAEE7zgSnsfitbnlOmQJwV4mXwQhZQR7 .48FGLglCvpSy2yizS7Fs82nLEFuRTpRtgTU3EbHOFbl1cKs4Nc8x.IUDR_MzIHX7yC7LGqqowUh lNVpl.P_I.YW.6wGOaDwHVQW.ofKFPvm2naZ905v31WfDl56vrS86BftYadWun5b_OsEAy1oEC0L bb_zbJY6iWyoUJkmDinrv3zvQpBUEvlKmwpSUFW0NV_g.dUKndl35I15lf2phiqv9MCvU_QIO120 ZqT7Rbo3detRk_oqLjaj2_opa3inMmYwBRmleT08SmtP5u2L8t_OwHMtIX0s98nAmlbV039sf0YF W.4NPGxh0MJ67pdqvAqmGz5qR0fVzwRkrV5vCGfL4XBMcimAB_yx1OmePVjd2ppAv6ZYw0qiBago 2Xc2TWGOp.zndRzAJ8P2OJzSYrAaVC971f.GK1Q9VWYbU4BrAumrpkkXSr4KLBNvnJ9l_tU2PEJK NY3y4B6dfTLhRU_eBnPb7hwf08N55f8t.Jakn4LC3i7vWTm0vQgv5rCmA75753HyqL1Jz70AUaDz avCzgF.0XILaUOBwgMdMt5gVXDy_X0bGXUivs_2hoOyV58PjQ3bMdjMGEznjM7qEltzPn2l.L7Fy AptwdMeKG4H2neyex3vOg5580qPF9P9WsIr0vlLKmCn2vIkAIYurYhZ_C86uL0MKKZ0LiQEI3XWE wH7hh_nnrTUKIYDGxx3dTVnOleF8dLVBIULoFEd86b4X6PZ4dJiWOQYrhol5rO2GCRZqI0.pOO5k EYh.f1HF37eNe9V345h46JVkKt1OkJVVRSUbGZ.5iVbGVKcm4lllVMpxjkwSWCC8xAv0gABohfiK ZPcwQqvc7ouQFgQO1NS43rATK9eteYwXrUKIAetTf.1VD44YROFnrkgxZJcJsn6VTbALwuuCQIsg bdoIDdQwRqb3vdVzBNxGhkvX7Tlzbrdso5D_PGp29bQx3eV9kjfIQDcb98kgRVky1.xgcAIPvZkS sRZk2cvBBpE3Z_H4QbYb0twvKZo3k0VoLeeVvA85TY.JuIj9mg6tnz8cG4uM7Zudk0NhCsPjWZMr 3j9WuHWp9Gw.a.HQ8JaWGhMORUvLK8Tdn1p9OhaFj7RwiNaKJh.rfNa07j5zcPO1GYgoWWc3vexI lg2.2X7RUsWpJlCMnK6aUnLzc5Oo6Vn3HPVCJYepGk_49yoQfqULzRxKxMJVFEVdlfmc71mqbYvF h2GGlhwc.moKdrg5BK5C1Z8Le3bRH7HBSF1EDr5_yoO1is4YSyjOGsUInKObJlw61lQD.KrCuSFf sFLNVfGJpkdA2mWadghN3WC4J9aWEgnz4xAtigKKD578yyBQHV80TwiA3vLbN6JMW2RJqJ.BHr_S p2jN7ho8XM1qNaoD7zoHz4Ilgdy_RN4LdGD2.J3HS2Q5CDB0LDS91k7W2Cldq6xaMUjldNnFsE2J 3cKdoQPDvzz0PU40LBj368ps9LhIC1c3qYBdKHRAKeE7vJnxhQWM0Eldyi0J_QxPaXWSoIQJUdoq cOVxEq3HRTNjwDt4StHcA97HcMvQRKZHdbNiJGaCgaxupDnl3funYe8ekLP3tU5r8gb9z3pM94vX 0jFXt9zXoCPragIit3OROeb3QkehAApaZTZhOsLTZEEd01tiM85h.qGndjJWGkEgqyfwmeusWmDy jCYHdHHOhUN8NBYw8dtxkpFGWAFJKDqEtl8pO6N676etjLt82lfOr_TFwfWmov5YaRwBv5huohgy OcFbDJBbzl_jIQ0.pwdsd_vyfywxoZjHfqzF1WQqoR46Rm5a5xTPNqeLveg_vlPW6L2fElf.Gjj8 ibxaoqDp8.2xeQdfZMYJ24SGurN_KGx_WPuTIqbea82AGe6uD5QZEi1itwtaHcwnwKC8xNYkVMen 81Oe3rYZrQwGCTVgRHVbiWRRr1vAxzv.ykhUaEipUSx_zovphsxmou8RfllYyapQmmzv8iUOhNcj 9gYZU5bHghG_mYS.cQ03silg- X-Sonic-MF: X-Sonic-ID: 11b99cdf-883b-4e27-b868-1ccaa358ac0e Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 19:42:36 +0000 Received: by hermes--production-gq1-54bf57fc64-6fh6p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7265cbeb5fd0f60f6a68f391253e00d0; Tue, 23 Dec 2025 19:42:32 +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 \(3826.700.81\)) Subject: Re: panic On aarch64 main: "usbconfig -d ugen0.11 set_config 1" panicked (data abort) on Windows Dev Kit 2023; kgdb backtrace included From: Mark Millard In-Reply-To: Date: Tue, 23 Dec 2025 11:42:21 -0800 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <447DC0E8-452F-4E12-A034-8C5360F850B4@yahoo.com> References: <6306A627-8052-4ADA-ADED-8CF68AC837D1.ref@yahoo.com> <6306A627-8052-4ADA-ADED-8CF68AC837D1@yahoo.com> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbQQS0bmrz3w9R On Dec 23, 2025, at 10:07, Gleb Smirnoff wrote: > On Tue, Dec 23, 2025 at 09:49:13AM -0800, Mark Millard wrote: > M> # uname -apKU > M> FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282662-117306dc606b GENERIC-NODEBUG arm64 aarch64 1600007 1600007 >=20 > Very likely this is fixed by 77939d64f23da4b0b599fad6edd967ffd1d17217. > And was broken by 0d469d23715d690b863787ebfa51529e1f6a9092. >=20 > Please update and re-check. The more recent official pkgbase kernel is: # uname -apKU FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282692-44f656641c23 GENERIC-NODEBUG arm64 aarch64 1600007 1600007 and is now installed. It did not panic for: usbconfig -d ugen0.11 set_config 0 (It has a quirk set that made 1 the default, unlike the kernel the system was previously using.) Note: I did not update the world, just the kernels available. I wanted to be able to potentially revert to using the to the copies that I'd made of the older kernels. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 24 00:01:12 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 4dbX8n00hDz6L70t; Wed, 24 Dec 2025 00:01:13 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbX8m4Kfkz3TfV; Wed, 24 Dec 2025 00:01:12 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766534472; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=E3A6uLCZiTW//HsOmq37tkbTxHTTbeDpdMwScJ25CEI=; b=WWRVheQOITXSn+MofYLTMNtqGv3X65kc9Q4U2f2a/csQPT7/dGF+KPUB7pji01xOEojrUT VBalNlfisqBpKESAmhDxIYIzbLuj4+UJpt9m5JmMHBOM6RmiLmV2gjXt5rnLcRoQRQhSJt fWK+pjUjplvQDmNZMeoZjdwZ4GTzIR5f4pUv/YDC1edheuQvJxlH3FcsUKcxWEjW8+g6tv lxOoKwtRSSDFl60IV0Xl30FpgAGxmh7Hsdtm1qSiUEiSEvy4q00hIGwHhOe80bI0QGmA5o mWYB+JB6Cxjz7GqBWDnzO0Ho3DgTS6E9KHN4dvOY8O734DPaikLKyRXI0dLANQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766534472; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=E3A6uLCZiTW//HsOmq37tkbTxHTTbeDpdMwScJ25CEI=; b=Vgrquh9/w/fq1arMeIwjZVxM4WqNhiEenSznY9uGs46ISYQtxuejIlr6zhHLQ2X5Ql81zY SYSVK8nrE7DRe4B1difRgz4I0hFNR6koTd/y/zL+3+14gKkjZdMMezL+WcBPbh3+7CfbSP KQW3DqWOyoSWpaqY7ns+WJ4G0geAY9nBwJ48PaBPVy4laColgqxV+1PhigQ0RCpEhxaSt9 JOam+xy5YBdBVU2KB9B36RQjMvKYDarNMaIMtsHWub0uypuSZAOelXxqdIJQ9PA7PHBsXp uimKX7kDyAWTaHDi4WSDQmOLzxH4XtgXUX2cPCg2fDSFbOFeoJ2w+xGfrTe0EQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766534472; a=rsa-sha256; cv=none; b=xCcuinbNujserZaBlzTJz181EDMX4euKCm6TvUx5HODv/sV1yyzybM2UAYLT+JhfCvtQbe /+nUwros2X8OYJMZSFgoFlc0YjPYDc+Tx8WhqRVcE/rq9ggTJrw4vmOIKcsyBwWElr2LRy uWa7GnQWtdFp+mug7kR9pJNJbcE3Ffzf1uSrjbtTEyGv/Or4UWiQ/0suQmnm9Maq1ZQUDt ceNWRo+Hbm0qWLnp2p4y3Edr/iFxHc6yLOtRYy6HcvqC+VucrsjAMVl+nBsFDFOtl62etP krA0vextoZsQe0La2vfVGMom5Ee+Gbl6UpgJWaZRpBMpvJYxsWt+yuIOmUcpow== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1472) id 3AF8567B0; Wed, 24 Dec 2025 00:01:12 +0000 (-00) To: freebsd-status-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2025Q4 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org Message-Id: <20251224000112.3AF8567B0@freefall.freebsd.org> Date: Wed, 24 Dec 2025 00:01:12 +0000 (-00) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is December, 31st 2025 for work done since the last round of quarterly reports: October 2025 - December 2025. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2025-10-2025-12/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2025-10-2025-12/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2025Q4 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Wed Dec 24 12:43:47 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 4dbs4n0Lxwz6KwCd for ; Wed, 24 Dec 2025 12:43:53 +0000 (UTC) (envelope-from lausts@acm.org) Received: from 011.lax.mailroute.net (011.lax.mailroute.net [199.89.1.14]) (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 "mailroute.net", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbs4l5Pqlz3bQ8 for ; Wed, 24 Dec 2025 12:43:51 +0000 (UTC) (envelope-from lausts@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=acm.org header.s=mr01 header.b=rMmjWSnU; dmarc=pass (policy=reject) header.from=acm.org; spf=pass (mx1.freebsd.org: domain of lausts@acm.org designates 199.89.1.14 as permitted sender) smtp.mailfrom=lausts@acm.org Received: from localhost (localhost [127.0.0.1]) by 011.lax.mailroute.net (Postfix) with ESMTP id 4dbs4j5p2yz1XSVtg; Wed, 24 Dec 2025 12:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1766580229; x=1769172230; bh=DULPrLUlKez4DiOMyxn+haLx tvfVwasCtt6FxwbmEyc=; b=rMmjWSnUuICYsMhS1JZFUJipPZWZ6P6owBRIoS2z 0HpqXlbWk3WGbZGpP2RRpyeurVlbIMubjG98psacSPWMUFjp6nTVZr/H/5lIrkMW wm3uNJj45dFnJ9VELvzvs6k8/MlB6blqhXDOIxOfA5oNUn1VMU7UYkqsodibR4Ha VNtsULkJOO6zXjLk+PIUf6eXYqUwkHjD5gJ+rXbkTVdqiRDfIYL5EkGIlyPa1KuH xuhCJHTD5QaWU3dx/L1m0Y9utL1AHrsfaGG6wwpC0Hx5potkwPcL8hPo6q6pyNsj mH+p/Z+W0GtRsHkFcghEoNBjpTjuQQZVzbf5HnGcUniADw== X-Virus-Scanned: by MailRoute Received: from 011.lax.mailroute.net ([127.0.0.1]) by localhost (011.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id A2a-ftvraEXi; Wed, 24 Dec 2025 12:43:49 +0000 (UTC) Received: from [192.168.1.100] (unknown [174.101.219.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lausts@acm.org) by 011.lax.mailroute.net (Postfix) with ESMTPSA id 4dbs4h3jzdz1XScBh; Wed, 24 Dec 2025 12:43:48 +0000 (UTC) Message-ID: <2ad21304-ce1a-4908-863b-5f62aee8bb08@acm.org> Date: Wed, 24 Dec 2025 07:43:47 -0500 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 Subject: Re: FreeBSD 16.0-CURRENT cf1eaaf41 Won't Install To: David Wolfskill References: Content-Language: en-US Cc: Current FreeBSD From: Thomas Laus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.09 / 15.00]; DWL_DNSWL_MED(-2.00)[acm.org:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[acm.org,reject]; R_DKIM_ALLOW(-0.20)[acm.org:s=mr01]; R_SPF_ALLOW(-0.20)[+ip4:199.89.0.0/21]; RCVD_IN_DNSWL_LOW(-0.10)[199.89.1.14:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; DKIM_TRACE(0.00)[acm.org:+] X-Rspamd-Queue-Id: 4dbs4l5Pqlz3bQ8 On 12/23/25 06:30, David Wolfskill wrote: > > I suggest checking the contents of /etc/make.conf, /etc/src.conf, and > /etc/src-env.conf, comparing the versions on the "builder" vs. the > corresponding files on the "client" machines. > > Mis-matches can cause this sort of thing, from my experience. > All of those files were blank. I ended up installing a fresh CURRENT snapshot on a spare hard drive. I was able to correctly perform an update successfully using NFS. Thanks for pointing me in the right direction. Since I used the original NFS version, the packets sent are UDP vs. TCP like on later versions. It's possible I could have had corruption or missed a file during my previous update. Tom -- Public Key: GnuPG KeyID = BD072E375C2B03E3 From nobody Thu Dec 25 16:09:15 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 4dcYbX0bD1z6LZ2K for ; Thu, 25 Dec 2025 16:09:28 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4dcYbV6wVQz3knZ for ; Thu, 25 Dec 2025 16:09:26 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=eHHheaPB; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 3DFE22404AA for ; Thu, 25 Dec 2025 17:09:18 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id AC025240276 for ; Thu, 25 Dec 2025 17:09:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1766678956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=7bISU3bRsjSSft10JM6ARykSYnsdw41sBkfyy0lncyU=; b=eHHheaPBz58BwnhcYUDFHgYoPc8jxR9QIrGRoiQl7B3fCZmADwn1JfJG3bxmAmNfseH6YT b26CiNLPYPeZfvK28ukQm5oU6kS90DB2QyQuB0fESlB7wFIekbSU3+yR9U0nbDBvVprcdR ye+22mKtqDTdvkr7LrLL+mtHylwDabQ6OYUroirQtV+Oa9rJ5QoHSP+2NpQIDEJj++ZJpp Y5RmzmxmQP0TPvsGHzuzSk4hHGBlsJYvqyL/imEEUzS9NRMXD4mVp1cX37jP2R+Xcn5cOb hj8ZqAx1dqg5Ni7Q1uYxjmhgELJgTOHSaEPsYOr/8PcGPJuwfHOH+7nXmXXkxw== Received: from hermann (dynamic-2a02-3100-2d21-4f06-b77b-4b9b-dce8-1249.310.pool.telefonica.de [IPv6:2a02:3100:2d21:4f06:b77b:4b9b:dce8:1249]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 6020A240023 for ; Thu, 25 Dec 2025 17:09:16 +0100 (CET) Date: Thu, 25 Dec 2025 17:09:15 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: CURRENT: kernel panic in IPFW while stopping jails Message-ID: <20251225170828.7aef61df@hermann> 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: 7bit X-Rspamd-UID: ec0f35 X-Rspamd-UID: f23de9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.932]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dcYbV6wVQz3knZ Hello, on recent CURRENT ipfw (in my case compiled into kernel) either restarting "ipfw" via "service ipfw restart" or restarting jails using also ipfw on a host also using ipfw (jail-hoster also ipfw compiled into kernel) causes a fatal kernel crash. This issue is present since last week an wreak havok to several boxes with OS installed on UFS/FFS SSDs. In one case I have only pictures/screenshots made via smartphone - while crashing, kernel debugger input pops up on console, but I'm able to typein something within the first seconds and this is mostly "reboot" but gets stuck with "re" in most cases. "bt" freezes system immediately. At least I can reproduce this misbehaviour on all recent CURRENT were IPFW is compiled into kernel. Anybody else havong this trouble? Kind regards, Oliver Merry Christmas to everyone. -- A FreeBSD user From nobody Thu Dec 25 16:43:42 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 4dcZMB6zhzz6LbsV for ; Thu, 25 Dec 2025 16:43:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4dcZMB3Hpbz3nbG for ; Thu, 25 Dec 2025 16:43:50 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 5BPGhgKa064673; Thu, 25 Dec 2025 16:43:42 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 5BPGhgsq064672; Thu, 25 Dec 2025 08:43:42 -0800 (PST) (envelope-from david) Date: Thu, 25 Dec 2025 08:43:42 -0800 From: David Wolfskill To: FreeBSD User Cc: FreeBSD CURRENT Subject: Re: CURRENT: kernel panic in IPFW while stopping jails Message-ID: Mail-Followup-To: David Wolfskill , FreeBSD User , FreeBSD CURRENT References: <20251225170828.7aef61df@hermann> 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/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cwr02Wnka5Mbj9r0" Content-Disposition: inline In-Reply-To: <20251225170828.7aef61df@hermann> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dcZMB3Hpbz3nbG --cwr02Wnka5Mbj9r0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 25, 2025 at 05:09:15PM +0100, FreeBSD User wrote: > Hello, >=20 > on recent CURRENT ipfw (in my case compiled into kernel) either restarting > "ipfw" via "service ipfw restart" or restarting jails using also ipfw on = a host > also using ipfw (jail-hoster also ipfw compiled into kernel) causes a fat= al > kernel crash. > ... > At least I can reproduce this misbehaviour on all recent CURRENT were IPF= W is > compiled into kernel. Anybody else havong this trouble? >=20 > Kind regards, >=20 > Oliver While I have some machines where I track stable/14 (for now), stable/15, and head -- daily -- and the laptops use a kernel with ipfw compiled in, I have not encountered issues with head since 17 December (main-n282567-7a83fedc116d -> main-n282596-405188aeac54). The most recent build was: FreeBSD 16.0-CURRENT #7 main-n282707-4f184fd35d81: Thu Dec 25 12:56:01 UTC = 2025 root@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/= CANARY amd64 1600007 1600007 That said, those machines don't run jails. They do use UFS file systems on SSDs, though. Peace, david --=20 David H. Wolfskill david@catwhisker.org See https://www.catwhisker.org/~david/publickey.gpg for my public key. --cwr02Wnka5Mbj9r0 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQRCec5RsK7Enudh3yGB9MJ9AwUELQUCaU1pvl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NDI3 OUNFNTFCMEFFQzQ5RUU3NjFERjIxODFGNEMyN0QwMzA1MDQyRAAKCRCB9MJ9AwUE LU3EAQDJXEnxIveUG/DWYUqKoHaa2QAT7Ig0Wumd8/zZ28bOZAEAnOwVbig/MXlc 4Pu5IJUG3urtSgj6tnAcakenl2FZuwI= =ETdb -----END PGP SIGNATURE----- --cwr02Wnka5Mbj9r0-- From nobody Thu Dec 25 17:30:45 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 4dcbPN30Dvz6LgNw for ; Thu, 25 Dec 2025 17:30:48 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4dcbPM6V4wz3sDx for ; Thu, 25 Dec 2025 17:30:47 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmlive5.colo2.realworks.nl [10.2.52.25]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4dcbPK43nRzb3; Thu, 25 Dec 2025 18:30:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1766683845; 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; bh=2y5WSFomewjGsdT8gwNhLa25OLBXgY7t5KDCrsc8MkI=; b=ZpaF/T3kw6rZoh72VeMqeSyeQK/dCkB6yOg56LTLN4fIa/NYl2R2dToR0IgoZ/kuj2vdvs URILFpK81Zpp1Ur3YusgN1HMaCVNzVmsc8MxElrbodzOVb8qDf3SzVUXlBDDP9JxnBHM0T PRcV4Q+mEXDFpkF0rl1Ipsqiaa4FDurewI7aOSa+sPl56byy+vNq0m0UJT3NT4u1bywGBY 469xCNhzeX7OnnpnAbg46eOb/B7sj7P34EvWI1lVGa5f5E77KntDGzWbGs93k2vJH9HP8J jMomOJR+4kbJvGauqed1HYSxFPFzl/0c112AmkDrk9RX1GrRXMEc/s54V5zRnw== Received: from crmlive5.colo2.realworks.nl (localhost [127.0.0.1]) by crmlive5.colo2.realworks.nl (Postfix) with ESMTP id 45316123890; Thu, 25 Dec 2025 18:30:45 +0100 (CET) Date: Thu, 25 Dec 2025 18:30:45 +0100 (CET) From: Ronald Klop To: FreeBSD User Cc: FreeBSD CURRENT Message-ID: <902742484.3865.1766683845222@localhost> In-Reply-To: <20251225170828.7aef61df@hermann> Subject: Re: CURRENT: kernel panic in IPFW while stopping jails 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="----=_Part_3864_824756654.1766683845219" X-Mailer: Realworks (777.87) X-Originating-Host: from (localhost [127.0.0.1]) by crmlive5 [10.2.52.25] with HTTP; Thu, 25 Dec 2025 18:30:45 +0100 Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dcbPM6V4wz3sDx ------=_Part_3864_824756654.1766683845219 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Do you use bpf or tap in your ipfw rules? A panic with that was mentioned on the 20th. And fixed in the mean time of I remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854 Regards,Ronald Van: FreeBSD User Datum: 25 december 2025 17:09 Aan: FreeBSD CURRENT Onderwerp: CURRENT: kernel panic in IPFW while stopping jails > > > Hello, > > on recent CURRENT ipfw (in my case compiled into kernel) either restarting > "ipfw" via "service ipfw restart" or restarting jails using also ipfw on a host > also using ipfw (jail-hoster also ipfw compiled into kernel) causes a fatal > kernel crash. > > This issue is present since last week an wreak havok to several boxes with OS > installed on UFS/FFS SSDs. In one case I have only pictures/screenshots made > via smartphone - while crashing, kernel debugger input pops up on console, but > I'm able to typein something within the first seconds and this is mostly > "reboot" but gets stuck with "re" in most cases. "bt" freezes system > immediately. > > At least I can reproduce this misbehaviour on all recent CURRENT were IPFW is > compiled into kernel. Anybody else havong this trouble? > > Kind regards, > > Oliver > > Merry Christmas to everyone. > > -- > > A FreeBSD user > > > > > ------=_Part_3864_824756654.1766683845219 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Do you use bpf or tap in your ipfw rules?

A panic with that was mentioned on the 20th. And fixed in the mean time of I remember correctly. 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854

Regards,
Ronald

Van: FreeBSD User <freebsd@walstatt-de.de>
Datum: 25 december 2025 17:09
Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
Onderwerp: CURRENT: kernel panic in IPFW while stopping jails

Hello,

on recent CURRENT ipfw (in my case compiled into kernel) either restarting
"ipfw" via "service ipfw restart" or restarting jails using also ipfw on a host
also using ipfw (jail-hoster also ipfw compiled into kernel) causes a fatal
kernel crash.

This issue is present since last week an wreak havok to several boxes with OS
installed on UFS/FFS SSDs. In one case I have only pictures/screenshots made
via smartphone - while crashing, kernel debugger input pops up on console, but
I'm able to typein something within the first seconds and this is mostly
"reboot" but gets stuck with "re" in most cases. "bt" freezes system
immediately.

At least I can reproduce this misbehaviour on all recent CURRENT were IPFW is
compiled into kernel. Anybody else havong this trouble?

Kind regards,

Oliver

Merry Christmas to everyone.

-- 

A FreeBSD user




------=_Part_3864_824756654.1766683845219-- From nobody Thu Dec 25 18:08:36 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 4dccF64fM4z6Ljph for ; Thu, 25 Dec 2025 18:08:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dccF60KTpz3xdZ for ; Thu, 25 Dec 2025 18:08:41 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 04B672407F9; Thu, 25 Dec 2025 19:08:40 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 3F6992402A6; Thu, 25 Dec 2025 19:08:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1766686118; 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=kOVyjg5OfFfq+Ggyj1NxPHLNUV0IZ+OHHQ+vES/iVWc=; b=VEyjk8qVDkoKLXMePSip7nLUuQH/f9ZIVyZGAiiFz0pUyUfd9tNGls1ELytl9yUqRdUh9m 02JwA7YK+mu7jbJi1lYP4a2JMW6SppWToq4NJgDD9hx1pGs3iixVu+YTBModHFdmbJnUbw J6WFeNnQ13ghL+265jEdNk/KJnYixghNIVvYNKWkobzq+MVomxB4xGS9SnRv0+8GGmsdER uCAF/x66ZAb0ABz6k1Lv+TG/PCV85LDYc74DCUqju1MW+u2C6mU5Wp74p2WUZBWUEljLDQ Rb1/WrWpkYqheBz3Aotpy85+eCp0dXQrQluNbSvNlg6xkQoAxfDCt+fUHa8zdA== Received: from hermann (dynamic-2a02-3100-2d21-4f06-65cb-f1f4-3757-9958.310.pool.telefonica.de [IPv6:2a02:3100:2d21:4f06:65cb:f1f4:3757:9958]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id E9AAB240276; Thu, 25 Dec 2025 19:08:37 +0100 (CET) Date: Thu, 25 Dec 2025 19:08:36 +0100 From: FreeBSD User To: Ronald Klop Cc: FreeBSD CURRENT , David Wolfskill Subject: Re: CURRENT: kernel panic in IPFW while stopping jails Message-ID: <20251225190836.6769e6d6@hermann> In-Reply-To: <902742484.3865.1766683845222@localhost> References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> 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: 7bit X-Rspamd-UID: dc2eb6 X-Rspamd-UID: f65b76 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dccF60KTpz3xdZ On Thu, 25 Dec 2025 18:30:45 +0100 (CET) Ronald Klop wrote: > Do you use bpf or tap in your ipfw rules? > A panic with that was mentioned on the 20th. And fixed in the mean time of I > remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854 > Regards,Ronald Indeed, all boxes in question do have a tap0 at least defined -but in only one case used. Kind regards, oh > > Van: FreeBSD User > Datum: 25 december 2025 17:09 > Aan: FreeBSD CURRENT > Onderwerp: CURRENT: kernel panic in IPFW while stopping jails > > > > > > > Hello, > > > > on recent CURRENT ipfw (in my case compiled into kernel) either restarting > > "ipfw" via "service ipfw restart" or restarting jails using also ipfw on a > > host also using ipfw (jail-hoster also ipfw compiled into kernel) causes a > > fatal kernel crash. > > > > This issue is present since last week an wreak havok to several boxes with > > OS installed on UFS/FFS SSDs. In one case I have only pictures/screenshots > > made via smartphone - while crashing, kernel debugger input pops up on > > console, but I'm able to typein something within the first seconds and this > > is mostly "reboot" but gets stuck with "re" in most cases. "bt" freezes > > system immediately. > > > > At least I can reproduce this misbehaviour on all recent CURRENT were IPFW > > is compiled into kernel. Anybody else havong this trouble? > > > > Kind regards, > > > > Oliver > > > > Merry Christmas to everyone. > > > > -- > > > > A FreeBSD user > > > > > > > > > > From nobody Thu Dec 25 18:30:42 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 4dcckl23DDz6Lklb for ; Thu, 25 Dec 2025 18:30:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 4dcckk6B7Gz41Vk for ; Thu, 25 Dec 2025 18:30:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8b5ed9e7500so470800485a.0 for ; Thu, 25 Dec 2025 10:30:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766687454; x=1767292254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j46OP3HUq1Z9bwUMQoGyjh9U/8xsQGLuTbPkDTWMPkA=; b=nnxY8grfBu1Ika6X2jgcSmSKCgIw8vnByb+uRmZBm+nGLpKGeBiLaHY8oKXoi+PDzp /vfRtZZFFD3CcZQ5rOv8sR/JQdxJQ38I4MVDJc7UrWJ2YX8tyxfGpAPUFnhEK7gYBpY+ ibnnJZ4nNJO5XzjxBW2pHrK5vpeGVuTSF+lTHQXzRFFZnShAADeFWEl3/0rwZT0RZnNU Iz2+hg56lz6Sx5V6tdXa6NwOtB868/A2tM7vJ+gZnO/CaatNEPYj6f8PQF6jHP1mh+WU RkSmCfiEOWOY5UNL2WNWt1mkfttHMyhikjCCIFrdYPe1YSjhwJP58B2sOavgThcA/iPz NbrA== X-Forwarded-Encrypted: i=1; AJvYcCWa0fEyTgh41Ok+DKm195ktM4kmsdcrMr2zdQrFF6Hy2qsD0Imv28UPGg6FKeJdGXnjmHQNq4SchstBR3FCrug=@freebsd.org X-Gm-Message-State: AOJu0YwAqIEN25pLZW4M3Y8VMxbFSQX3h8+j5oeoBGE21mPKV7xZEDt8 WqcdO1HTerqsUhBLWzSdpRQ8GjPazmk1lwg93P66VqYO6MvvsPU46Y6OVJFgHy4wU7wgrGO7gXs fa68Mx2bV3uTQSOhLMPBDNTFet9kxEIfAGA== X-Gm-Gg: AY/fxX5MEvb89n4+bya59YINFtYRyYshYXQJrotCIj5wzINw1QIrHsAgXSKkpozWVCu nIScFO6UblNAAQqAtk5y2oCaKXPtpJgh/CHLTRadwnjXwd+QCTgx3e1r27UFjCY9gr+DP4SHMNH dJuPTCBM9R/NYNCVx7U45MaHpUKEzkUCe6mOU+q4iY8vVwXmf42A5FAeKmUjpLyj/uU3I6q4pRq fPxk6AdXEiSoUP3ZV/dBpR7wPQE/IoW8Rp7eQhQL7MfztL6pptLgX4RjcDZG+sYwQTD99MygyIG 5AeAVq7hCXGBL/KRdvAm0qqEfIqi8wu0nP97V5miy0kTUxbfcmtIfhw+lLtv X-Google-Smtp-Source: AGHT+IHitDdSf0bQlY8iN2a5ho9lTY8nrouThN5B0g5q9HLcjOaDL3/jrSa/aVbmA5HaMTVqE2X5sKZcs+qUjkD2U7s= X-Received: by 2002:a05:620a:469e:b0:8a3:90c:55fb with SMTP id af79cd13be357-8c08fbdf0c8mr3294418385a.20.1766687453593; Thu, 25 Dec 2025 10:30:53 -0800 (PST) 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: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> In-Reply-To: <20251225190836.6769e6d6@hermann> From: Adrian Chadd Date: Thu, 25 Dec 2025 10:30:42 -0800 X-Gm-Features: AQt7F2r1EQKpLxxYWJP9uQitS8bgVZYGJZLkFi6p2r1ezEKgqhzTz72n0zgj284 Message-ID: Subject: Re: CURRENT: kernel panic in IPFW while stopping jails To: FreeBSD User Cc: Ronald Klop , FreeBSD CURRENT , David Wolfskill Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dcckk6B7Gz41Vk On Thu, 25 Dec 2025 at 10:09, FreeBSD User wrote: > > On Thu, 25 Dec 2025 18:30:45 +0100 (CET) > Ronald Klop wrote: > > > Do you use bpf or tap in your ipfw rules? > > A panic with that was mentioned on the 20th. And fixed in the mean time of I > > remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854 > > Regards,Ronald > > Indeed, all boxes in question do have a tap0 at least defined -but in only one > case used. glebius@ did a bunch of bpf cleanup/refactoring in preparation for other work and there was some fallout. If you update to today's -HEAD and it's still broken then please file a bug and poke him about it so he can address it! -adrian From nobody Fri Dec 26 09:06:46 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 4dd0BZ6TtKz6LG1C for ; Fri, 26 Dec 2025 09:07:50 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E7" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dd0BZ3QtCz3HWj; Fri, 26 Dec 2025 09:07:50 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([IPv6:2620:137:e001:0:e470:b235:9d07:3fa6]) (authenticated bits=0) by prime.gushi.org (8.18.1/8.18.1) with ESMTPSA id 5BQ96wfE064827 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Dec 2025 09:06:58 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 5BQ96wfE064827 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1766740020; bh=u7RiIrcoh1jq3pUS4JC+1c4HNFPekThtHF39+4hc5iQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20CURRENT:=20kernel=20panic=20in=20IPFW=20while=20 stopping=20jails|From:=20"Dan=20Mahoney=20(ports)"=20|In-Reply-To:=20|Date:=20Fri,=2026=20Dec=202025=2001:0 6:46=20-0800|Cc:=20FreeBSD=20User=20,=0D=0 A=20Ronald=20Klop=20,=0D=0A=20FreeBSD=20CURR ENT=20,=0D=0A=20David=20Wolfskill=20< david@catwhisker.org>|References:=20<20251225170828.7aef61df@herma nn>=0D=0A=20<902742484.3865.1766683845222@localhost>=20<2025122519 0836.6769e6d6@hermann>=0D=0A=20|To:=20Adrian=20Chadd=20; b=JMhYy0S38DjA2k7bOAnY17aW/y+K0X6rLWNbvF4gpoIkPAjeVCB6qUvJ4FkNoDL6S mtfXE6MIq+rSM4sVIl910E1C+Ilz1AXxEVNx6O61+WGQUcieINrxfonPYpiuy86Xqa 8dCtxhXTapJCeiJZJUL/0cM7wUiQlfJHl1FVr03MHOWsioIdi+XeEyoyjrxiv4aDE1 CNoxIoOyS5CNc+N7DzkIqan8/CCfkbdY/S20HjhccywZUxmLCJIokLfjXS37uJrvDU pqu7X1X+SxrT8fFCT2fJ6dIT4xhSQ0I+vuNKLMygGWdJyRQbPqoBhK96AD1QrDE3x9 zDSmXKFviMsAQ== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2620:137:e001:0:e470:b235:9d07:3fa6] claimed to be smtpclient.apple 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 \(3864.300.41.1.7\)) Subject: Re: CURRENT: kernel panic in IPFW while stopping jails From: "Dan Mahoney (ports)" In-Reply-To: Date: Fri, 26 Dec 2025 01:06:46 -0800 Cc: FreeBSD User , Ronald Klop , FreeBSD CURRENT , David Wolfskill Content-Transfer-Encoding: quoted-printable Message-Id: <0F907415-3277-4EA9-9D8E-C8D0905EC6AA@gushi.org> References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> To: Adrian Chadd X-Mailer: Apple Mail (2.3864.300.41.1.7) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dd0BZ3QtCz3HWj > On Dec 25, 2025, at 10:30=E2=80=AFAM, Adrian Chadd = wrote: >=20 > On Thu, 25 Dec 2025 at 10:09, FreeBSD User = wrote: >>=20 >> On Thu, 25 Dec 2025 18:30:45 +0100 (CET) >> Ronald Klop wrote: >>=20 >>> Do you use bpf or tap in your ipfw rules? >>> A panic with that was mentioned on the 20th. And fixed in the mean = time of I >>> remember correctly. = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291854 >>> Regards,Ronald >>=20 >> Indeed, all boxes in question do have a tap0 at least defined -but in = only one >> case used. >=20 > glebius@ did a bunch of bpf cleanup/refactoring in preparation for = other work > and there was some fallout. >=20 > If you update to today's -HEAD and it's still broken then please file = a bug and > poke him about it so he can address it! I'm still hitting the panic with a slightly older world, but a current = kernel (so it dies before I can install new world). I'll try rebuilding = again, but my last "git pull" didn't look like it touched anything ipfw = related. If the fix is to disable ipfw entirely until the new world is installed = that's also an option (it's a VM, I can snapshot it), but I'd like to = hear if others are hitting this. Sometimes the vm gets to the point of = bootup and even lets me ssh in, but still panics shortly after. I can = get the panic data if need be, but it would need to be captured from the = virtual console (so would be an image, there's no easy copy/paste). I do *not* have a tap0 defined. My entire ruleset is below (and because = it's all tables based, I don't need to edit out private netblocks, yay. I have already poked glebius, but you know, biggest holiday of the year = and all...I'm offering a datapoint for others. I don't start any jails = on this machine by default, but it is my poudriere machine. -Dan 00100 79965 31249091 allow tcp from any to any established 00200 0 0 allow ip from any to any via lo0 00300 0 0 allow ip from any to any via lo1 00400 0 0 deny ip from any to 127.0.0.0/8 in 00500 0 0 deny ip from any to ::/64 in 00600 2 80 deny ip from table(bogons) to me in // unexpected = sources 00700 0 0 deny ip from table(blocked) to me in // emergency = (non-persistent) blocklist 00800 0 0 allow udp from me to any 33434-33600 // traceroute = in 00900 0 0 allow udp from any to me 33434-33600 // traceroute = out 01000 6517 488290 allow icmp from any to any icmptypes 0,3,8,11,13,14 = // safe ICMPv4 01100 0 0 allow ipv6-icmp from :: to fe80::/10 // ICMPv6 DAD 01200 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 // = ICMPv6 NDP 01300 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 // = ICMPv6 NDP 01400 0 0 allow ipv6-icmp from any to any icmp6types = 1,2,3,128,129,135,136 // safe ICMPv6 01500 0 0 check-state :default // permit stateful traffic 01600 961 57660 allow tcp from table(nrpe_clients) to me 5666 in = setup // NRPE agent requests 01700 2587 150268 allow tcp from any to me 80,443 in setup // HTTP(s) = requests 01800 121 7260 allow tcp from table(ssh_clients) to me 22 in setup = // inbound SSH 01900 1 60 allow tcp from me to table(syslog_collectors) 1999 = out setup // syslog-ng TCP outbound 02000 5026 381976 allow ip from me to table(ntp_servers) 123 = keep-state :default // NTP outbound 02100 20 9644 allow udp from me to table(krb5_servers) 88 out = keep-state :default // Kerberos outbound 02200 0 0 allow udp from me to table(krb5_servers) 464 out = keep-state :default // kpasswd outbound 02300 0 0 allow tcp from me to table(krb5_servers) 464 out = keep-state :default // kpasswd outbound 02400 574 49195 allow ip from me to any 53 keep-state :default // = DNS outbound 02500 4 240 allow tcp from me to any out setup // default = outbound 02600 0 0 deny ip from any to 224.0.0.0/4 // drop multicast 02700 8743 423405 reset log ip from any to any 65535 0 0 count ip from any to any not // orphaned dynamic = states counter 65535 0 0 allow ip from any to any r= From nobody Fri Dec 26 09:14:09 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 4dd0Kw3jzvz6LGgQ for ; Fri, 26 Dec 2025 09:14:12 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 4dd0Kv6kFDz3Jj1 for ; Fri, 26 Dec 2025 09:14:11 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XExIQBmj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47d3ffb0f44so8745475e9.3 for ; Fri, 26 Dec 2025 01:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766740451; x=1767345251; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:cc:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vSlgPKu+din+kW6rgT5+4MK/XQ0e7L74aKG2iywZCUw=; b=XExIQBmj1tARay07MdwYQtliRhbuKAdUktUpDgaP3X9XaVdAtg/VlZZcsG54Lww1c6 ncRH0wFHTige210LETj8P9JOPUS3OjAbfPERIEGNkbQQHyC6nUNXE5gHZrhmAYqG6oBt a0lpSZlKFmyk1p9Jza0RzZ74cYjT66ta9czdxB6L5BRB5YiUicMl6sce0DYAPUykX5Ys pGdKuqomO5ppCYndMSuTPRcXh9wJclGXye2qEDF4ChAteBRgjKa2vHtWUiCVyewWW5xr +2HP7wX/SQDuovcZ+cO3nXjpRitOETqo/fIGVp1bFmyuS/ehwxdkPJ8EIwbJMCTL6/UA c9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766740451; x=1767345251; h=content-transfer-encoding:in-reply-to:autocrypt:cc:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vSlgPKu+din+kW6rgT5+4MK/XQ0e7L74aKG2iywZCUw=; b=o/4V8uWxhEANOxrK/F2cIln40sAnb7Hn8ZJg8aSi889Kj6x9922R0ccUzsH3ATZi3I JAxxyNBtJHQDSTQ4kuBr2MaTCqUN74NuMTpA1jxY6H3INBFMG7Glo8tK45TSNDKcrEuu KvfmpVO9ZXOyCI+RU1/yi54DofmgfvGkCNfABQdhP5JafvXruBSzBE07K8AYOXFf6MR/ vcxBdNW8pC4rRuIkI90Uyf1t71oPb6vV70aLdeEj5lZIRNKkqWBq000u4kW5Djw7+/bn vHLkJS+sHJTIM/bcgd9e1TQhXcrPs/JnJz5rlYVjNgCSJdl7hIqg0kSyi2XR590RuxFW PO8Q== X-Gm-Message-State: AOJu0YwAZXz8qfRdvn2o2NcCevl79US+qOWgDXe2jSc6c2fwQzSe1dDL i7YsYySRocMz7rrwi3iChYsZmCYZrhIT7rg5tQDultcpPMX/g8nq66gV3e7QcQ== X-Gm-Gg: AY/fxX5YtQ+YQRGnVVl7RS25ajCjmQwqOqCpUC+wXdUCym7Xs3hilcRgnR/vZbpil7E MJjuaCqPE6mxI2MVfgpXqThHeGQcE3Y/6/b8CC8Af1DiSosNL4nnTaECcLlcYep+6/R84I1Arsi AyfmdfmFiHoBcLzEG/6IawqTgjRX9w8XpikdeoRfU3Id17FvOjq/qQQK8RbPec9u5/USgkLbJnm 1s1i43m0ID9Hdg4X2HfObH2BEE84wPe2WHgysxW7x3uI6aaY5DB8Y+MOkXdmEj/ogLrrRPZIcZd 3hNoFZxyUhfwm+XlNZFxUtskHpMayx9rrY+dzDt1AaH9V/Rc0NNQIpqpU3iu7EdWwV2zh1A0UTk kkNaUfOiC8evD91S+yV974tUYiGgBP7te+pljfAIOY3SVWmG8lovO37OaSP5djiYHv3EYVXZpGz fBFx/xFeu5duDhjo+0HwQBbg5YeQk4lnp33+qHSXMwobs4Nw== X-Google-Smtp-Source: AGHT+IFMjFgIa2mtAJcXAfl3Y1ps9mCKJnLds7gF0ggbgzLXoKJbk4R2wYmzTjXrqlw5zfT1uVXzyA== X-Received: by 2002:a05:600c:3b0d:b0:477:569c:34e9 with SMTP id 5b1f17b1804b1-47d20021316mr235300365e9.23.1766740450507; Fri, 26 Dec 2025 01:14:10 -0800 (PST) Received: from [192.168.1.4] (host-2-100-171-17.as13285.net. [2.100.171.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d193d4e91sm371647625e9.13.2025.12.26.01.14.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Dec 2025 01:14:09 -0800 (PST) Message-ID: <31ff927f-1193-48d5-bf7c-6a78b6283cb7@gmail.com> Date: Fri, 26 Dec 2025 09:14:09 +0000 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 Subject: pkg-unregister(8) (was: changing from pkgbase to regularbase) To: freebsd-pkgbase@freebsd.org References: From: Graham Perrin Content-Language: en-GB X-Priority: 5 (Lowest) Cc: freebsd-current@freebsd.org Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; HAS_X_PRIO_FIVE(0.00)[5]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::331:server fail,2.100.171.17:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from] X-Rspamd-Queue-Id: 4dd0Kv6kFDz3Jj1 On 19/11/2025 14:17, void wrote to freebsd-current: > A newly installed system was installed with pkgbase … > … to properly un-pkgbase things? With pkg 2.5.0 you can: pkg unregister --force --glob 'FreeBSD-*' A careless example, after using VirtualBox to take a snapshot of a guest (force is not generally recommended): root@maximal:~ # freebsd-update fetch freebsd-update is incompatible with the use of packaged base. Please see https://wiki.freebsd.org/PkgBase for more information. root@maximal:~ # pkg unregister --force --quiet --yes --glob 'FreeBSD-*' root@maximal:~ # freebsd-update fetch freebsd-update: Cannot upgrade from a version that is not a release (including alpha, beta and release candidates) using freebsd-update. Instead, FreeBSD can be directly upgraded by source or upgraded to a RELEASE/RELENG version prior to running freebsd-update. Currently running: 16.0-CURRENT root@maximal:~ # pkg -v 2.5.0 root@maximal:~ # env IGNORE_OSVERSION=yes pkg bootstrap -f The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+https://pkg.freebsd.org/FreeBSD:16:amd64/latest, please wait... Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done Installing pkg-2.5.1... package pkg is already installed, forced install Extracting pkg-2.5.1: 100% root@maximal:~ # Additional information: at and around . From nobody Fri Dec 26 09:32:41 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 4dd0m96wVSz6LJ42 for ; Fri, 26 Dec 2025 09:33:29 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4dd0m86N0Hz3PGs for ; Fri, 26 Dec 2025 09:33:28 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="n1q3/t7h"; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 827AD24021D; Fri, 26 Dec 2025 10:33:17 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id AF228240278; Fri, 26 Dec 2025 10:33:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1766741595; 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=2aR0jVPxIXFLEPOeyiGItfsuUQrWv9Phw9EWnJ+BWTo=; b=n1q3/t7hJ+1AnoNi8BsZuTKEsObm2SGhuYoMPlll06J10UslxQIHuDRjUCCbchRcG6CvrD H4YBlQPr0aRNxvYpK7IGYS/xGr+R1+mTmL+C8peA1gy19v7shfuh4jnPsYqgle3Mo+8fpY z6upAriLSGP4Wl0SMVLjmUAFfxDkl1JA1QhRHe/sRKk7C65K6a/XB77bBL+uJ9E5w1kFMl YAStfencBc5SpnL/Uu3jSMrCdMf2I2GnkkHZmemyuZYFGaQg6XfcEKQPmCGKEnFkvkjUkV Z0sadMd8CUcisUq3UJKPfgaPzwYwFpLudBLE3km1AnXaGt55yiaNsRR+sBi5vw== Received: from thor.sb211.local (dynamic-2a02-3100-2c9f-a902-021b-21ff-fe4e-8f4d.310.pool.telefonica.de [IPv6:2a02:3100:2c9f:a902:21b:21ff:fe4e:8f4d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 6632C240277; Fri, 26 Dec 2025 10:33:15 +0100 (CET) Date: Fri, 26 Dec 2025 10:32:41 +0100 From: A FreeBSD User To: Ronald Klop Cc: FreeBSD CURRENT , David Wolfskill Subject: Re: CURRENT: kernel panic in IPFW while stopping jails Message-ID: <20251226103308.72204662@thor.sb211.local> In-Reply-To: <20251225190836.6769e6d6@hermann> References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd16.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: multipart/signed; boundary="Sig_/KwcYlRax9cVebrVo25JGeaA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 4d929e X-Rspamd-UID: adb91c X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.48 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; DMARC_NA(0.00)[walstatt-de.de]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dd0m86N0Hz3PGs --Sig_/KwcYlRax9cVebrVo25JGeaA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Thu, 25 Dec 2025 19:08:36 +0100 FreeBSD User schrieb: > On Thu, 25 Dec 2025 18:30:45 +0100 (CET) > Ronald Klop wrote: >=20 > > Do you use bpf or tap in your ipfw rules? > > A panic with that was mentioned on the 20th. And fixed in the mean time= of I > > remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D291854 > > Regards,Ronald =20 >=20 > Indeed, all boxes in question do have a tap0 at least defined -but in onl= y one > case used. >=20 > Kind regards, >=20 > oh >=20 >=20 > >=20 > > Van: FreeBSD User > > Datum: 25 december 2025 17:09 > > Aan: FreeBSD CURRENT > > Onderwerp: CURRENT: kernel panic in IPFW while stopping jails > > =20 > > >=20 > > >=20 > > > Hello, > > >=20 > > > on recent CURRENT ipfw (in my case compiled into kernel) either resta= rting > > > "ipfw" via "service ipfw restart" or restarting jails using also ipfw= on a > > > host also using ipfw (jail-hoster also ipfw compiled into kernel) cau= ses a > > > fatal kernel crash. > > >=20 > > > This issue is present since last week an wreak havok to several boxes= with > > > OS installed on UFS/FFS SSDs. In one case I have only pictures/screen= shots > > > made via smartphone - while crashing, kernel debugger input pops up on > > > console, but I'm able to typein something within the first seconds an= d this > > > is mostly "reboot" but gets stuck with "re" in most cases. "bt" freez= es > > > system immediately. > > >=20 > > > At least I can reproduce this misbehaviour on all recent CURRENT were= IPFW > > > is compiled into kernel. Anybody else havong this trouble? > > >=20 > > > Kind regards, > > >=20 > > > Oliver > > >=20 > > > Merry Christmas to everyone. > > >=20 > > > --=20 > > >=20 > > > A FreeBSD user > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 >=20 >=20 tap0 disabled/deleted. Same issue on every box. --=20 A FreeBSD user --Sig_/KwcYlRax9cVebrVo25JGeaA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaU5WVAAKCRCxzvs8Oqok r1/gAQDKyz1sb2rqE70z8/oQ1WCRXeJlAkpai99oQncMhPTZ4wEAlTUu7PKxgRuY UFS3AasFgKWcIhYYHxUQ3ZeNHPlJPgI= =Z1aa -----END PGP SIGNATURE----- --Sig_/KwcYlRax9cVebrVo25JGeaA-- From nobody Sun Dec 28 06:03:06 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 4df80x355lz6MVYt for ; Sun, 28 Dec 2025 06:03:29 +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 4df80w3syyz3GYj for ; Sun, 28 Dec 2025 06:03:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QkS+WOej; 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=1766901800; bh=Ylnl2wKHRPENA9xrIFiwg+GTUkUyQMhsgqNIix7Qp1s=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=QkS+WOejuwxmZLQ0LAeXKe/Od1PZn+BDYN+8txvWNFjuXBIjtPuRwZ7Ggvr4R98xpbBAHIYUc0txmyxmftkFkfIOLRa24exDROo0HUNd4TE6gIKenNTYVaOxyqM0moYNdp8gyMp/xDKElB1TUBv5NvN250lWGp21xd9u1N/WZ8Mlruu1JeZGbjO9dzZ5qL/6YCVm6pjbSZogfI3cVYJyFycZbqCGQC9nK2qJ0vleu6wngqk2PJR1FGo2O0iwBkiP5MvKXO/OSgIi0MKn3JxfhHWJbpjEMni9WyFqtA+Zq+iIus+UiNo4I//mSKxQlccvgunoMHIx7jRNALEHXTQkTA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766901800; bh=btMTnQomPJ/tjAJwOcXrsdSFghg8wHLXLvW0tZbk6ix=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Opl1ZfW4Kd07lOMb+vZf2i9RwnepjxU8oNe5g/D1aIfv9plIMx+Cl63wj7w0fWoOvJcU+mopvHNHDaREz09ghXGJhr2+UoRaF7PUk+U0obn3CJsbrQ7P3zo9WuzRiasNMf1mtG9wfIVK/7txUI92aB3h1XmLL4yzRasquDQrVMOrDiySWKwrxkSi1mAjtwsjVf3XpEZpCbJgeHMdNqpkq30bkX1tGwhiSkCScf9sVpdT7yI7qpAH8X1HebFfw/uuIQiBDImB4cwW4Ty43gtNMa9jO3Bm56cI2WZX3s7dyQAVDwbHPAWp1IHLcoGvs/pwZKtbwbA0FIcTaGVpW/fLVA== X-YMail-OSG: X9ic3S4VM1mQyONs0pkTFR7IxScNNiLprA35Cly_P.NzuOyWVnvP6s3U.4bfaTN 75_ZCzZk0I39m3Av4l4h_YKmGPSKxpFJHFLREClPLqgCbWB.96hu3Qnu85VC3rglHeHc1EWob_FD FGNC6sQznOn6hB6LGJxuICpxQoyEDd27MmP2vEM20sqCYi_q4ok6vg3nWXXq1FsQDgDG7EutUPLg Sr7.5U.UdOwQCrL2PCa7YqzyV0u6_uov6uajmMhVy44.dYTubsUeV5DNBie_LW6MYczVUrr4yk9B L1Ob0WM7RAkBRNmj0yrUUM7kjNEkhyLGGfvySuoxxyF2Rj4C67QMZgpTg7PoQr5gNsI1ytZ4afsl udiCuzpejkZWuGneE_vtIVYVXg6QvpG4DU18U1xK9et1qOe54bRC9l3dqFTcvaTY9K.P2zBBOYTC wW25Ph8AzyQgJrcAEVz3Fd..TYDehQ1HEhIVXG0bJswa7jll9W4WaZ7SNbBmgD0EMsa23YuTysPj MJwAJvQwf61RiHIQmbMSu5ALMSLTuWVoEm3rLSPeQPkQPSJZPsbGy29jTi9O8FV2sR0gZfj9QkdF EV1yNqF2m8pYT5V0SD8w4xdK4PxQXG5h.mwrilOrjmqrAX9u4n07MCpE2lrH0mXd5v8w.KOXvMzd TM8m.M_ukRjdaw2yYvBzvsOXjrkpSZsRsAgJVvYXZCXqAvBVB3zsXmX7irtU3fDaAJWdbbxi2DVD QJMH2T.yGNNROD1gyuGgOudUm4VUEfb7r9p.7f5EiIjuPfwDl3lZAvMDVBc1WfID9ODcNGXhbQYT Ck2rATTW.Jc.QfhyHnvPwp9GCey34jkSoSC0Ghq_YBgIX01JX7VSIifmzP6NYGy_q8zJvDhQbG7t oeIUFnNSoJ05waxdTisNQKHWBy2eZV2rY5FdQDFDBodzvl1B8BTbxLofEYKUY2N9t3bgModPxhG7 IXA75Mud8zOBg0Pg_lcG_jsQmOqgRsx.VhfCfhEQaPIMM.OQ4claFgFLYmZPbNkFzPL65aX7rt_D 7rIOsYPc29trhQ6aaWRZvTK1.mYpPghk101OS0UVAcuT2X3t4CDx1TmYfYocjJzkVVOdawqvUUJM cih6gWHp0edl76RRLzNwziG_AyASkx514KJGXqJQWUePGK4PJ4MhEwUYnNEbFm.P3RICAFWkCvIe WXHhfUnO8WuabMUQvCwkW9yDI0mvOBLsD56SyR8YLR4k1I1psNup3VuUVKANZkZPxtB_RdApS8Rz R_tt5jkI3Zo0PmO.m5nmfTotEhdzwULIp1C96WHr01eFTqXZN2VMCUe0h9e8qm1BwSGwksMtTzUX jHE8QxcbH7Cv2s4w0KD2FZbdanulvyDnTb1q0DFTNDEHQL9jksSgJFfBNKP449cOAonZ1gW8dw0N tzy_24fRFEGXIKpfhfPbWP0oN77fopBnkwe5hbbh6GUvwsQ93PXxxxpHdAhlRxoP5vhnNFcxN_da Uf06.u6ePDtBUUeaWdEs0JV8SXv16Rhi7jacQlVMG1ux3yDM9M_FITNxvr0ePrOOmpXk1v4q4P7j GpOe5XQ0B0N_13U9z2t73di7nTmuICZDl50sTq.QpGVj8VFvKdqoBZ7oKXecZ1v8F4ofYE2NTODi W4tTLzUGP25bxSiPfLCZ9dbBMaAb.73fcI2fWS5vsqUu8Va8ap5uzvjrytKKf2DXaKQ5nZLcFxwf 5T2mmmsQRQTJklBDXxgft811wlmdODdI0rnWCPOGvA8GDq6s2F27xV6qP.h21mSvnq91FZ0ToHWG 8DzZ3C0n_4wkb7QJYoQC2EgAmt81dvjcIjvgmAJW9wUE.fnh1zV50Q.wz0.EODIz.NE2T52ShOvX rQMslYqzAFTE_GGqV9JPVcJyMk5da4XwYviRQpn_XLzm6ukGvzApauWSG_ztAvWjVdvjz0gXSqbw wyTD6WrHKDQuVJMmuOMKrxgdw91EC9F8H5tdUj_Np3GdHWXIENt1dYCT6Q6t3k6wr3sfKw.CtcZl OnOB92sHyrX3rXnM3Ym.IR8BMxW5RBYWnNGVWsb2czx77q9_xiS9GiRsjy9H53EbkUR0iVcKNH4g Hi9J5b1sGwn3IaOuU1714vkIg7UIBvFPSrv0MzR3yaWj91OBf5gs15cOGqEi1.LoZte.AP9b1ccT LRz8zqxtbtMjYEO8ocUXIv_2xt9ywo8TN0QROUI1MwIBYLPxKOQT4Fv55S_EYNMBrEkQCSAFpM2M FwABrja8IxqfsYUbythG4l0IH6V5Lm3j.mjvdtVWk.kRTm.Ixz6u8eepu_hcSsAua1kx8ZIhuTO3 cTg-- X-Sonic-MF: X-Sonic-ID: 20d9a400-36d7-443e-89bf-5a0616ac18be Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 06:03:20 +0000 Received: by hermes--production-gq1-54bf57fc64-8j6k2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 20dccb50694ad17af4a8c5f9edecc308; Sun, 28 Dec 2025 06:03:17 +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 \(3826.700.81\)) Subject: armv7 main's gpart: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) Message-Id: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> Date: Sat, 27 Dec 2025 22:03:06 -0800 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.97)[-0.965]; 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)[]; TO_DN_ALL(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]; FROM_HAS_DN(0.00)[]; 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)[]; DKIM_TRACE(0.00)[yahoo.com:+]; 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)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4df80w3syyz3GYj Context: # uname -apKU FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 That is an official pkgbase distribution that I installed, not a personal build. pkgbase for main has world being a debug build, no matter which of the kernels one choses to boot. For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel but might not be exact for the world: /usr/src/sys/ and /usr/src/ (without sys/) are from different times, last I knew anyway. Changes can happen between. During boot, the time on the Orange Pi Plus 2ed is bad so: # ls -lodT /gpart.core=20 -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 /gpart.core Also, for pkgbase, a source file distributed can be newer for its time stamp than the program distributed that was based on the source file. Such happens below. Core was generated by `gpart show'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 warning: Source file is more recent than executable. 2715 if (*cp =3D=3D '\0') (gdb) bt #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0x20130635 "%s", flen=3Dflen@entry=3D2= , flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 (gdb) list 2710 for (;;) { 2711 if (len =3D=3D 0) 2712 break; 2713=09 2714 if (cp) { 2715 if (*cp =3D=3D '\0') 2716 break; 2717 if ((flags & XFF_UNESCAPE) && (*cp =3D=3D '\\' || = *cp =3D=3D '%')) { 2718 cp +=3D 1; 2719 len -=3D 1; (gdb) up #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, (gdb) list 2977=09 2978 return rc; 2979 } 2980 } 2981=09 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, 2983 xfp->xf_width[XF_WIDTH_MAX], 2984 need_enc, xfp->xf_enc); 2985 if (cols < 0) 2986 goto bail; (gdb) list 3498=09 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? = XF_ENC_UTF8 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? = XF_ENC_WIDE 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; 3502=09 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); 3504=09 3505 if ((flags & XFF_TRIM_WS) && = xo_style_is_encoding(xop)) 3506 rc =3D xo_trim_ws(xbp, rc); 3507=09 (gdb) up #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); (gdb) list 3812 { 3813 if (encode_only) 3814 flags |=3D XFF_NO_OUTPUT; 3815=09 3816 if (vlen =3D=3D 0) 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); 3818 else if (!encode_only) 3819 xo_data_append_content(xop, value, vlen, flags); 3820 } 3821=09 (gdb) up #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); (gdb) list 4368=09 4369 save.xhs_offset =3D xbp->xb_curp - xbp->xb_bufp; 4370 save.xhs_columns =3D xop->xo_columns; 4371 save.xhs_anchor_columns =3D xop->xo_anchor_columns; 4372=09 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); 4374=09 4375 if (flags & XFF_HUMANIZE) 4376 xo_format_humanize(xop, xbp, &save, flags); 4377 break; (gdb) up #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 6372 xo_format_value(xop, content, clen, NULL, 0, (gdb) list 6367 flags &=3D ~XFF_WS; /* Prevent later handling of = this flag */ 6368 } 6369 } 6370=09 6371 if (ftype =3D=3D 'V') 6372 xo_format_value(xop, content, clen, NULL, 0, 6373 xfip->xfi_format, xfip->xfi_flen, 6374 xfip->xfi_encoding, xfip->xfi_elen, = flags); 6375 else if (ftype =3D=3D '[') 6376 xo_anchor_start(xop, xfip, content, clen); (gdb) up #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); (gdb) list 6546 /* Retain the info */ 6547 xo_retain_add(fmt, fields, max_fields); 6548 } 6549 } 6550=09 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); 6552 } 6553=09 6554 /* 6555 * Rebuild a format string in a gettext-friendly format. This = function (gdb) up #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 6622 rc =3D xo_do_emit(xop, 0, fmt); (gdb) list 6617 { 6618 xo_handle_t *xop =3D xo_default(NULL); 6619 ssize_t rc; 6620=09 6621 va_start(xop->xo_vap, fmt); 6622 rc =3D xo_do_emit(xop, 0, fmt); 6623 va_end(xop->xo_vap); 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); 6625=09 6626 return rc; (gdb) up #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 warning: Source file is more recent than executable. 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", (gdb) list 649 } 650 wname =3D wmax; 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; 652 secsz =3D pp->lg_sectorsize; 653 xo_open_instance("part"); 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", 655 wblocks, (intmax_t)first, wblocks, = (intmax_t)(last - first + 1), 656 wname, gp->lg_name, 657 scheme, pp->lg_mediasize, 658 s ? " [CORRUPT]": ""); (gdb) up #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 793 gpart_show_geom(gp, element, = show_providers); (gdb) list 788 else 789 errx(EXIT_FAILURE, "No such = geom: %s.", name); 790 } 791 } else { 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { 793 gpart_show_geom(gp, element, = show_providers); 794 } 795 } 796 xo_close_list(name); 797 geom_deletetree(&mesh); (gdb) up #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 warning: Source file is more recent than executable. 497 cmd->gc_func(req, flags); (gdb) list 492 buf[0] =3D '\0'; 493 if (cmd->gc_func !=3D NULL) { 494 unsigned flags; 495=09 496 flags =3D set_flags(cmd); 497 cmd->gc_func(req, flags); 498 errstr =3D req->error; 499 } else { 500 gctl_add_param(req, "output", sizeof(buf), buf, 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); (gdb) up #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 861 run_command(argc, argv); (gdb) list 856 show_tree(); 857 return (0); 858 } 859=09 860 get_class(&argc, &argv); 861 run_command(argc, argv); 862 /* NOTREACHED */ 863=09 864 exit(EXIT_FAILURE); 865 } For reference: # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c = /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c = /sbin/gpart -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 = /usr/src/contrib/libxo/libxo/libxo.c -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 = /usr/src/lib/geom/part/geom_part.c -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 = /usr/src/sbin/geom/core/geom.c That explains the "warning: Source file is more recent than executable" messages. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 07:35:07 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 4dfB365Yy1z6LMt8 for ; Sun, 28 Dec 2025 07:35:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4dfB352CrRz3NNg for ; Sun, 28 Dec 2025 07:35:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=N6iiULD5; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.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=1766907321; bh=XHWULwDSGtMZECAnWclsNmVLYl7L+9g50HczLPfLU/A=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=N6iiULD5jVrxvZ2FX8FvtaWZ7yFyUr40vUVBex9blXgh78k3i04Mp4e6CHHotr05WKcmnN0EPkyOsv7FoXvvJvXtWfrM9/RZ1o4kauyFDeTgjA6kyIopv2GAR59e8EZN0qKzQdtr28ZmWRQ7R2kK2JUeHP0KjbDBf1fDm/1s95JWHd+JzZZHDmDEKB3sPcSlJxZ1qN/u/+JJHMFRDZZ1ov0Wdm1Qj9Kq9fgqGc8mi2dvXSU8f66h3xFUguEc3R97Qha+a1fUuEGF5+8WHWkzhlitc/TL5zcO7hrzQfdiHuJ026uq2nfuUSUPqCSbaYRIAq+8mUWs1fcLbiRTegIVCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766907321; bh=bopZUAxzeD+XILDNGFdjwtOEBqgPON3mxVNW+/WbwLK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=N7CLdcRz6zlcuSNoLdwMGchepUc1pTU16taGy9TxO5esULBL4I2bJgtTWBtd2hvF+V0hdAxpHXl0ay4ikZ8GMSFUTUAdBY5XvdLOXp+Z+xat4D/e1d2mHaYrVp/daE7JoWF7ZSaU1BGWHSix/FFcWpqxq1i3GUo2mftkzToUw7qx5boOrC69sXrIGgf8BilGl6CtKzYCHCvDs1K4exjiwIlqYauEE3gXbpI2glQeqUUz03I4YFUbmtjzzJnNcISooIVwqRKaFNRMS7COVqYUS+TiPEdwujSTuDTmaHzJbxVY/Fl95EgK3tocQmVT41gaYCiluhGxO73GMuOTsZwfDQ== X-YMail-OSG: AqQlqlMVM1kt8Ye4cXw.JA7MuRQHGp5yedRrLlImIVEYO.BTQNBqwtVQIroNTHA aTOuP5CpLMtE.re9F1hrmsoocqpQUyFll54_dhLBCdEYg.Zbxuk4_MaHYu6DZl3BdHn6OHT1ka41 djOh_buEoJP02REvOYf8XWRFuBZKICCcyeS1Ugwh7SCqMbDfXuj7Ey3WSyKww3pYr6NnedyyABiT 18ZXFh4.xGTejZMRvjsWP3AJioyOzKDYRYQKFlqZED0q1KRJAzB8kpZTGlBmParRYe58l_Q4V3Fj LyxIwCb5daBTjoz6k5w3HMlSQOo90TbSZpQvap6vr1jHKyAO53BW3LHHbLa.HNxCTCA22efWls.9 L0k.Z0odhmSbd_8DoZbKcwhrdORI7I0ckKndMg21WlW6CBQg9M0pqblNblFmepcBhlzA56jJ0gJ2 O7_F3fyHnGmptpy1M0DA4cdJDqzFRrx9N66h49JPUsSyla0aulDRveprsPiJF91e50qPPH9XVg4q wTMrN3Mb5LchWedDYWXNOquuAXwcMbEZqMm2n9HF3wsFUyy2v9s47Z_pdokR66EA4MF0R4nvVBt9 WF9eqpPTAuGpfaDllGTMN38Een1taGyy9NBBjGJ1HWdRjsO3.dHWf2MmVWu9bOkZ5bFLRai5ClR. O0ErbBz9NIo0_nWX_2ev0tD1t9HbEZhdwVjC.Zh4w_MjhDXCU83aVoSOfI3cwd7J4DDc1lsgGZuT LmBwNGkfk9z1f4n2JfSuo1CeUCKHa7vIYKW7hlCG9mIF9nbmRRoGOjgRxpKLjx0K2EJTUOIHLESP z_ronKG2LEQO9Qk6RqJdpR4sYhwIiXerriNO4knnf8_AiwxcthGyjxwSGNxER_2qz3MtZyYwxIuI XsL7RZFW4F.PMMUIzI848rf5Vy9vJkrKfJukjxeXX8QHVNrosDD_ln4YLLIlUxYX_aFdGn.Qdb6K FbURpMfA8CBHLfvodXyMLJlL7heuHq4jjeQbG02OCyNXbmJx5TiGJpAJ0SGlKOZRJaUnzNMEzaLC VeiSlMWrHrLT1KIWiSn1xGgX8UO23TiJ_A_LYIFfdfTjHUN2G7L44oQs5rwa9WCx5FPx45d7t5eu _kXvTttWq0eucdzm6v9wamBvapiUP3aHN9vRAHGmBNKeMJPVRoptScRVINVmko9H7Y6kCBwzo77Y g5TN_MBgncEAnESPPJ5VzDlO0nFSq_yUwuWZsNS5S8049ItN7halllcEUJE5k2DIjxxqas0a5AId gsy.HTRu6W1DGfKItgShcpqFpSqANRQ23b1HL_VwKvAzhe66Hpf1QmpHfVoC63UEyljDV7tKFhzy ZmjYaNe61dtWW855h7fDo.510G5VWL7wBRxeQHOKPAxe7otajh1dcM1a8a.VBLOmCQEBgh5285wm 8IsDomCMQiQIsq4qgwXX9IF27KgjAnDwRyiDmuDX6r4o.rvKufJJ4EaKveNq3YuJhyNUws8zlPM5 t8ROdRe9ecq9f5rxSGwPEzCq1kQxUte7nS0RUUcgDoGyQxxLBDz3ROeKobjjajdTrhKRbDj6jRY3 JXhK_RLmY.z.VtfMmqjarLr0ketkX1Z.PLPVAaxTIJZ0hdvIrfg2cVoYfKgcIua4a7dn7juNRhnJ WE5xIQKTy2I.zFHw6qgl9n9QWhLrWrIeKk7T.4VUiuNzXHrMQKAf1r_dC1DBP6ZrDMpFfPEQpEEg 0jL6AbRd0WjYNrUMOSiLpDnABUWd7n1AcnrDuqcDdYUNCXuDx4olh5EHbEhz3J.e5DKrE86Wydkt dwDJU5odMJt4OWCGqhVDC1U3SOyMjFHOxtv6aPHFWPt4n.MYBkvmNt.bpxv1Iwea0NnR_sdUI_z4 6d8sqO8n4anozJPhUrjWm6.7ATGeZfWOomhh0rdMbkX0pQvTYESAQrXDLwsHMs_FrtJIeIhlsWkj rCzd.oykEB5Ya0KFq7UDjaFmL2b.ZZL0KFzg8IH6RJ9QBaGSWxBEG9RdPI65XKsCGux0_gr3pLKn Mz70ImIjIs.OU7As2zDTwyyNRKvkwfJNyTRb1z0syFwNIHb8B1tbXa0K_DIskUR_ENpFtQqdQRpi zreCZnPpua5mixR.lxa64JuigrL9B1zel6vmViiNm9souuC_pXpSPfeEqCh2Qy6QADyw1m8rhtD2 _o3xhS7JGvvmtONvDHWR8R6ONXLAjlxTzfwZqP1DQa9AsYPO8yl9sdRBg1FAyRUAPY65G2x4PFox M9cLoDO37yJ4cOOYwurgLVK2T7xNyhUJV9wdLHS8AlXyM9goSQXmdwi1lZd6IzrlH0gl5Ojcr77o - X-Sonic-MF: X-Sonic-ID: ec335489-261e-4225-b51e-a24cc40a1435 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 07:35:21 +0000 Received: by hermes--production-gq1-54bf57fc64-mhfh2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fe037256e1c9c9444e3fb1aeb1233404; Sun, 28 Dec 2025 07:35:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) Date: Sat, 27 Dec 2025 23:35:07 -0800 References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> To: freebsd-arm , FreeBSD Current , "js@freebsd.org" In-Reply-To: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> Message-Id: <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.98)[-0.981]; 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]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[98.137.68.82:server fail]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4dfB352CrRz3NNg On Dec 27, 2025, at 22:03, Mark Millard wrote: > Context: >=20 > # uname -apKU > FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >=20 > That is an official pkgbase distribution that I installed, not > a personal build. pkgbase for main has world being a debug > build, no matter which of the kernels one choses to boot. > For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel > but might not be exact for the world: /usr/src/sys/ and > /usr/src/ (without sys/) are from different times, last I > knew anyway. Changes can happen between. >=20 > During boot, the time on the Orange Pi Plus 2ed is bad so: >=20 > # ls -lodT /gpart.core=20 > -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 = /gpart.core >=20 > Also, for pkgbase, a source file distributed can be newer > for its time stamp than the program distributed that was > based on the source file. Such happens below. >=20 >=20 >=20 > Core was generated by `gpart show'. > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 > need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >=20 > warning: Source file is more recent than executable. > 2715 if (*cp =3D=3D '\0') > (gdb) bt > #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 > need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 > #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 > #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0x20130635 "%s", flen=3Dflen@entry=3D2= , flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 > #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 > #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 > flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 > #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) > at /usr/src/contrib/libxo/libxo/libxo.c:6372 > #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") > at /usr/src/contrib/libxo/libxo/libxo.c:6551 > #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 > #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 > #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) = at /usr/src/lib/geom/part/geom_part.c:793 > #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 > #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 > (gdb) list > 2710 for (;;) { > 2711 if (len =3D=3D 0) > 2712 break; > 2713=20 > 2714 if (cp) { > 2715 if (*cp =3D=3D '\0') > 2716 break; > 2717 if ((flags & XFF_UNESCAPE) && (*cp =3D=3D '\\' || *cp =3D=3D = '%')) { > 2718 cp +=3D 1; > 2719 len -=3D 1; > (gdb) up > #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 > 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, > (gdb) list > 2977=20 > 2978 return rc; > 2979 } > 2980 } > 2981=20 > 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, > 2983 xfp->xf_width[XF_WIDTH_MAX], > 2984 need_enc, xfp->xf_enc); > 2985 if (cols < 0) > 2986 goto bail; > (gdb) list > 3498=20 > 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? XF_ENC_UTF8 > 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? XF_ENC_WIDE > 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; > 3502=20 > 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); > 3504=20 > 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) > 3506 rc =3D xo_trim_ws(xbp, rc); > 3507=20 > (gdb) up > #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 > 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); > (gdb) list > 3812 { > 3813 if (encode_only) > 3814 flags |=3D XFF_NO_OUTPUT; > 3815=20 > 3816 if (vlen =3D=3D 0) > 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); > 3818 else if (!encode_only) > 3819 xo_data_append_content(xop, value, vlen, flags); > 3820 } > 3821=20 > (gdb) up > #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 > flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 > 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); > (gdb) list > 4368=20 > 4369 save.xhs_offset =3D xbp->xb_curp - xbp->xb_bufp; > 4370 save.xhs_columns =3D xop->xo_columns; > 4371 save.xhs_anchor_columns =3D xop->xo_anchor_columns; > 4372=20 > 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); > 4374=20 > 4375 if (flags & XFF_HUMANIZE) > 4376 xo_format_humanize(xop, xbp, &save, flags); > 4377 break; > (gdb) up > #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) > at /usr/src/contrib/libxo/libxo/libxo.c:6372 > 6372 xo_format_value(xop, content, clen, NULL, 0, > (gdb) list > 6367 flags &=3D ~XFF_WS; /* Prevent later handling of this flag */ > 6368 } > 6369 } > 6370=20 > 6371 if (ftype =3D=3D 'V') > 6372 xo_format_value(xop, content, clen, NULL, 0, > 6373 xfip->xfi_format, xfip->xfi_flen, > 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); > 6375 else if (ftype =3D=3D '[') > 6376 xo_anchor_start(xop, xfip, content, clen); > (gdb) up > #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") > at /usr/src/contrib/libxo/libxo/libxo.c:6551 > 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); > (gdb) list > 6546 /* Retain the info */ > 6547 xo_retain_add(fmt, fields, max_fields); > 6548 } > 6549 } > 6550=20 > 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); > 6552 } > 6553=20 > 6554 /* > 6555 * Rebuild a format string in a gettext-friendly format. This = function > (gdb) up > #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 > 6622 rc =3D xo_do_emit(xop, 0, fmt); > (gdb) list > 6617 { > 6618 xo_handle_t *xop =3D xo_default(NULL); > 6619 ssize_t rc; > 6620=20 > 6621 va_start(xop->xo_vap, fmt); > 6622 rc =3D xo_do_emit(xop, 0, fmt); > 6623 va_end(xop->xo_vap); > 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); > 6625=20 > 6626 return rc; > (gdb) up > #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 > warning: Source file is more recent than executable. > 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", > (gdb) list > 649 } > 650 wname =3D wmax; > 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; > 652 secsz =3D pp->lg_sectorsize; > 653 xo_open_instance("part"); > 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", > 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), > 656 wname, gp->lg_name, > 657 scheme, pp->lg_mediasize, > 658 s ? " [CORRUPT]": ""); > (gdb) up > #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) = at /usr/src/lib/geom/part/geom_part.c:793 > 793 gpart_show_geom(gp, element, show_providers); > (gdb) list > 788 else > 789 errx(EXIT_FAILURE, "No such geom: %s.", name); > 790 } > 791 } else { > 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { > 793 gpart_show_geom(gp, element, show_providers); > 794 } > 795 } > 796 xo_close_list(name); > 797 geom_deletetree(&mesh); > (gdb) up > #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 > warning: Source file is more recent than executable. > 497 cmd->gc_func(req, flags); > (gdb) list > 492 buf[0] =3D '\0'; > 493 if (cmd->gc_func !=3D NULL) { > 494 unsigned flags; > 495=20 > 496 flags =3D set_flags(cmd); > 497 cmd->gc_func(req, flags); > 498 errstr =3D req->error; > 499 } else { > 500 gctl_add_param(req, "output", sizeof(buf), buf, > 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); > (gdb) up > #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 > 861 run_command(argc, argv); > (gdb) list > 856 show_tree(); > 857 return (0); > 858 } > 859=20 > 860 get_class(&argc, &argv); > 861 run_command(argc, argv); > 862 /* NOTREACHED */ > 863=20 > 864 exit(EXIT_FAILURE); > 865 } >=20 >=20 > For reference: >=20 > # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c = /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c = /sbin/gpart > -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart > -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 = /usr/src/contrib/libxo/libxo/libxo.c > -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 = /usr/src/lib/geom/part/geom_part.c > -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 = /usr/src/sbin/geom/core/geom.c >=20 > That explains the "warning: Source file is more recent than = executable" > messages. Additional context notes: ) On the Cortex-A7 SUT the above is repeatable at the shell prompt when logged in: just try "gpart show", including via gdb use. "/rescue/gpart show" also core dumps. ) In a armv7 chroot on a aarch64 system (the Windows Dev Kit 2023), the "gpart show" works just fine. But the vintages could well be a little different. (Tracing to git commits for pkgbase is problematical.) I'll note: Johan S=C3=B6llvander Date: Thu, 18 Dec 2025 15:23:29 UTC=20 The branch main has been updated by js: URL: = https://cgit.FreeBSD.org/src/commit/?id=3D4f809ffec69cd6ede3e7be9a5bc876b2= e5931028 commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 Author: Johan S=C3=B6llvander AuthorDate: 2025-12-18 15:06:09 +0000 Commit: Johan S=C3=B6llvander CommitDate: 2025-12-18 15:22:59 +0000 gpart: add libxo support for "show" subcommand + man page updates Added libxo support to `gpart show`, also updated the man pages for geom and gpart to show where you can expect libxo formatted output. PR: 290629 MFC after: 1 week Sponsored by: ConnectWise Reviewed by: asomers, mckusick, phil Approved by: asomers (mentor) Differential Revision: https://reviews.freebsd.org/D53950 --- . . . Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 07:55:02 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 4dfBV01xSVz6LPFc for ; Sun, 28 Dec 2025 07:55:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.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 4dfBTy0nfjz3RDQ for ; Sun, 28 Dec 2025 07:55:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=f2LBCHq5; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1766908514; bh=kIDcpziUyubd9Za7ko4zibgBjeZbQda4hGXYPdVYfoA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=f2LBCHq50Fz0RoD3B9/MUDGt/i8TbiAinTBLuVHTQIoktErRVM3m5e+denhtmSxQ5I259/S/jsjzKg3OJ/6wpjp6mXgC0OIRpVOKsG6hpFN0AqI/2CkvMW2vn3iNcw0mAGbQz11X9hFFos64DcnagLOPuWGCMuhRYKchnvdqeQVnkEJaqaM8nCQoTUdfzT6Gg+fXvraZhVrP6w+gkccAeQvz1kgIfBaHGY6Og6BY1xbT47LM2zp7Cn+s+tZj65i7GTr90vfqMGmqZv1KsOJ2tW5VOPMjDIBC4g7ncbzGSX0WytbRrK/cYaJ9sVKvKVm8DZPS9CuQL286EMyFj9yBcw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766908514; bh=IGb3EJHufXnQ3EuoGORLKOCU6efm2tC4+NJ2uPkXC5g=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BCAPaiuf1k+QG2riA+koSiHfcji1MHmzSOXy2l/Qcp09r6iz7IDyOZELt7sP8HUdxL9pXiFtPjcjcUfjdbRj8B6RlhHr0VnPpDUxyuUdNjK/jBcSeEzMzYPq50RHxFWMdCIdTW8DDhrINMcVOc29YoPM5KnH8J6GDYY703PjENWhUgZeem7+9cZCbO+9JBQl7nbnwaMSMb1IKEPu/FAchnvAVxiDmObaFPWM1FzaGTFMUscDIOpAUiY2H9894y+g1PTjw/l2lXWjg7r7+QBFvv2lql3FITiQlv0RAmdfuw/tI8aO4LgayU6K8HZEZC4qKsWjEgXpt+14RGCtaeORAw== X-YMail-OSG: Kp44sHcVM1khLlxaJhEe8nYTRCvzpSFNj26aUc09twMl78OTLv8iCOB3MFVPSTH KkulliNSm1IydifkbjlSSo7qshd40w6iKm.9vufnL.mcLR8NSCP8WHYG1IEk1DoPxQM2xDQhYa_F EPVWKlQJZ3vsDToRMTZ.7NpgJ4Vmp9apFyyShdPQOayGHVqLZP6brIp9fa8Very0LH7Br9PtfUEn JjCFCdFo2exOv2w5CHXdGE2brM_HdgU34ygukWb7qU_HG7jvQNpm7_Lmbuh_qn4VXa27z_47XZSQ qRx8DCabziba8yvePGP0Htt_JuXEvoOOJtMiXeog6SoCzw5PvoXOfEO6he_ztQe6NA6QWyr9.Y3o Z2ykYoEzSqWuoU2dfXFU5wTgI7O0dJ.eMiKjfkWtWg65Qt75L1h7jvZod2Jhujk1P82hXgAVQKqw pbZfw064RLi.nNXTOPFy.AxC8O1LzNqjRRCI2Tx1.qCkRwzckLEtBMEZTNTBEQ8D_uXoCBf.UpgT Rk.eORqkIt_LiFIduK7mJyrhje54N3g5wZx7G6H7eIg2V2GbmaxI.DiRxGXKVYAdumM14GlSBN05 mO2NfRhHs25OQIrko15dhP3ys5tuy2Ut3VwYnyYVLYRKxFSE5eJQpCndAR0EoZ5f7001lBtZv2h5 mGCnl92JMf_4IXbKQEIiPFe9IFyShIGVkNiMH.Qyua3vpzDtsST6D6u7EjfTSAcqkYb0OkGvu311 CQm711r5MF1T4RK8psoTVgzPqAWo15Nz3Dr.riGYQoOkZHf1MEbGpwy.YRpJqrmf65SPT57irvxX lVyb5h2swx4mE6Ch7p2jX0FVtpoqc_wcuzHhx_Zqm6K4KuElzAwsa.nMyqHSJBdg_PGwofPJKExp WPr9Ip96nnCEJMeiDOToQxSw6g_JBb9a0snQh.hUXuJntQjWSOFV5c3u4tnpgPLiqnFDIQuJnexu 0GRL21V_qr5MoNqnNWS2M96KFLULp4cJwJON4opFDbGLbsl.yxOpkh09HOqLhMi_L4N1g67KxRhu ftLyPHst812AZB83jvKQwk.WBmqAdpS9kTSOi6Y2w7V3qImqgpcsvpnAbxxhSqsCyvVmpnIQwDK1 MkcIgOM5Cj22wbNNcWwhikMMQ7n6NiXvFQxCuJMkGfD_JDEhWi.tCZdo7pEB6gEfQJ7GHh6AFhiS X1UKALe0WWyMqJDuiyPn6gIPMn_NIwpdLo8GKHd0NyGxMj_0PFWdQqpA52a5hd2e4g3Nrh7xAXIt dKvjVbRHcCYnO2bZHPt4rbMzPVTZW3teHcaiLPt4dvuSP.JgfLTTHiUMDjYygEBqUHd_PDToFsIk 04PZnNvmm16UmgiWxiK6yvBw7IbFLq0MOTekaPF678SBNHk92gY0mDSuLNdo1hKXlAHfa0o9BVrN .xAPGaYCP0h8vURhcijefpJBwV8rmK.dhDO0QPzFSbPbTGXgZohofH1Hz2m8dh_T5qKrOGvnFskQ rugPUpO8GvuCsh1F0NUgIKBWSMkF46eY8V6pqj7jhRRnazZKYYGvH8LPfcLR1dHM9wUM_T_C.38j FwmKh9sRG7jXVkuYWOCkDPWeOYO7rvMh1tEMVmQPHL0jnqdjVvxigJkhS1YUjyUa_NDAk0SF1uW2 s7NcWh.Zq1P0qv0cQlAhly39M9EWytl.E0ApUsvfou3CbK3AxjNhAFd6qWv9o4Df_zyrQ3nQ7geZ 4MMePM_wnidDRi2RfTHjloiSEDJ_STXUUuo3Jn2HWRq02L7NX8TxehOaLmOaPyo1wnPQ90jSWETJ .5Ok3PMDopHioH3BCH0XGV8PGqXfhh2a5_JkGABe6Q_sZbe37m9drwsbswt0iUKm_u0nvWh0pkJe aZnENcDJOa0l3a_S9xJBTXwuTkwkB2xvXzNc3YSu0TuX2CX9MS6MT3A.WcLYqCNG0UMaD79njxTN cIVUusRD0sm9cccck5hotySPGU__eg1quf7v1fdnUTt956BVRYaH52KyQo6ehj3pM78uHqIwUdUs FTCZbk3oKvQtiBM_9zRgaZjQ346kiltlrd59zc.XNBMX9tjnSoP8CfzD3BgbQU9xqAbr8dyEMcrD gxdkvPo8HCPbolhhTYHkPjCKrtvkFEJCKpEHvJOdHtNe.H9I7PYxHJrYoMW91YsEIqggrOiCHl6c phQXwlKguLfUX7FURGvvwDctZqSe4LbB1qufbJEAV42Qertfic0tZL39BjsnrmR6OIJDHwmpjHhl zjBIYeOaGCm_vZ3c70Mk1WQ5ffekAoGixlMDZCT80roucjwKxYCL5fseF6sXpZ9BeeBpy5dKRuF0 9XkgxKMn5 X-Sonic-MF: X-Sonic-ID: 7b8e04a0-b0d4-4e23-b465-f13e594efb7c Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 07:55:14 +0000 Received: by hermes--production-gq1-54bf57fc64-jfb2x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5686beb2aa72c6b7be95e93ed6ed995c; Sun, 28 Dec 2025 07:55:12 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) From: Mark Millard In-Reply-To: <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> Date: Sat, 27 Dec 2025 23:55:02 -0800 Cc: "js@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> To: freebsd-arm , FreeBSD Current , Konstantin Belousov X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_SHORT(-0.97)[-0.968]; 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]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; 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]; BLOCKLISTDE_FAIL(0.00)[98.137.65.204:server fail]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from] X-Rspamd-Queue-Id: 4dfBTy0nfjz3RDQ [Turns out: works on aarch64 kernel's armv7 support, fails on the armv7 native kernel, exact same world files on the exact same media.] On Dec 27, 2025, at 23:35, Mark Millard wrote: > On Dec 27, 2025, at 22:03, Mark Millard wrote: >=20 >> Context: >>=20 >> # uname -apKU >> FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >>=20 >> That is an official pkgbase distribution that I installed, not >> a personal build. pkgbase for main has world being a debug >> build, no matter which of the kernels one choses to boot. >> For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel >> but might not be exact for the world: /usr/src/sys/ and >> /usr/src/ (without sys/) are from different times, last I >> knew anyway. Changes can happen between. >>=20 >> During boot, the time on the Orange Pi Plus 2ed is bad so: >>=20 >> # ls -lodT /gpart.core=20 >> -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 = /gpart.core >>=20 >> Also, for pkgbase, a source file distributed can be newer >> for its time stamp than the program distributed that was >> based on the source file. Such happens below. >>=20 >>=20 >>=20 >> Core was generated by `gpart show'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> Address not mapped to object. >> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >>=20 >> warning: Source file is more recent than executable. >> 2715 if (*cp =3D=3D '\0') >> (gdb) bt >> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150,= flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >> #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0x20130635 "%s", flen=3Dflen@entry=3D2= , flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 >> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) = at /usr/src/lib/geom/part/geom_part.c:793 >> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >> (gdb) list >> 2710 for (;;) { >> 2711 if (len =3D=3D 0) >> 2712 break; >> 2713=20 >> 2714 if (cp) { >> 2715 if (*cp =3D=3D '\0') >> 2716 break; >> 2717 if ((flags & XFF_UNESCAPE) && (*cp =3D=3D '\\' || *cp =3D=3D = '%')) { >> 2718 cp +=3D 1; >> 2719 len -=3D 1; >> (gdb) up >> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150,= flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >> (gdb) list >> 2977=20 >> 2978 return rc; >> 2979 } >> 2980 } >> 2981=20 >> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >> 2983 xfp->xf_width[XF_WIDTH_MAX], >> 2984 need_enc, xfp->xf_enc); >> 2985 if (cols < 0) >> 2986 goto bail; >> (gdb) list >> 3498=20 >> 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? XF_ENC_UTF8 >> 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? XF_ENC_WIDE >> 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; >> 3502=20 >> 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); >> 3504=20 >> 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) >> 3506 rc =3D xo_trim_ws(xbp, rc); >> 3507=20 >> (gdb) up >> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >> (gdb) list >> 3812 { >> 3813 if (encode_only) >> 3814 flags |=3D XFF_NO_OUTPUT; >> 3815=20 >> 3816 if (vlen =3D=3D 0) >> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >> 3818 else if (!encode_only) >> 3819 xo_data_append_content(xop, value, vlen, flags); >> 3820 } >> 3821=20 >> (gdb) up >> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >> (gdb) list >> 4368=20 >> 4369 save.xhs_offset =3D xbp->xb_curp - xbp->xb_bufp; >> 4370 save.xhs_columns =3D xop->xo_columns; >> 4371 save.xhs_anchor_columns =3D xop->xo_anchor_columns; >> 4372=20 >> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >> 4374=20 >> 4375 if (flags & XFF_HUMANIZE) >> 4376 xo_format_humanize(xop, xbp, &save, flags); >> 4377 break; >> (gdb) up >> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >> 6372 xo_format_value(xop, content, clen, NULL, 0, >> (gdb) list >> 6367 flags &=3D ~XFF_WS; /* Prevent later handling of this flag */ >> 6368 } >> 6369 } >> 6370=20 >> 6371 if (ftype =3D=3D 'V') >> 6372 xo_format_value(xop, content, clen, NULL, 0, >> 6373 xfip->xfi_format, xfip->xfi_flen, >> 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); >> 6375 else if (ftype =3D=3D '[') >> 6376 xo_anchor_start(xop, xfip, content, clen); >> (gdb) up >> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >> (gdb) list >> 6546 /* Retain the info */ >> 6547 xo_retain_add(fmt, fields, max_fields); >> 6548 } >> 6549 } >> 6550=20 >> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >> 6552 } >> 6553=20 >> 6554 /* >> 6555 * Rebuild a format string in a gettext-friendly format. This = function >> (gdb) up >> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >> 6622 rc =3D xo_do_emit(xop, 0, fmt); >> (gdb) list >> 6617 { >> 6618 xo_handle_t *xop =3D xo_default(NULL); >> 6619 ssize_t rc; >> 6620=20 >> 6621 va_start(xop->xo_vap, fmt); >> 6622 rc =3D xo_do_emit(xop, 0, fmt); >> 6623 va_end(xop->xo_vap); >> 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); >> 6625=20 >> 6626 return rc; >> (gdb) up >> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >> warning: Source file is more recent than executable. >> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >> (gdb) list >> 649 } >> 650 wname =3D wmax; >> 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; >> 652 secsz =3D pp->lg_sectorsize; >> 653 xo_open_instance("part"); >> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >> 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), >> 656 wname, gp->lg_name, >> 657 scheme, pp->lg_mediasize, >> 658 s ? " [CORRUPT]": ""); >> (gdb) up >> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) = at /usr/src/lib/geom/part/geom_part.c:793 >> 793 gpart_show_geom(gp, element, show_providers); >> (gdb) list >> 788 else >> 789 errx(EXIT_FAILURE, "No such geom: %s.", name); >> 790 } >> 791 } else { >> 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { >> 793 gpart_show_geom(gp, element, show_providers); >> 794 } >> 795 } >> 796 xo_close_list(name); >> 797 geom_deletetree(&mesh); >> (gdb) up >> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >> warning: Source file is more recent than executable. >> 497 cmd->gc_func(req, flags); >> (gdb) list >> 492 buf[0] =3D '\0'; >> 493 if (cmd->gc_func !=3D NULL) { >> 494 unsigned flags; >> 495=20 >> 496 flags =3D set_flags(cmd); >> 497 cmd->gc_func(req, flags); >> 498 errstr =3D req->error; >> 499 } else { >> 500 gctl_add_param(req, "output", sizeof(buf), buf, >> 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); >> (gdb) up >> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >> 861 run_command(argc, argv); >> (gdb) list >> 856 show_tree(); >> 857 return (0); >> 858 } >> 859=20 >> 860 get_class(&argc, &argv); >> 861 run_command(argc, argv); >> 862 /* NOTREACHED */ >> 863=20 >> 864 exit(EXIT_FAILURE); >> 865 } >>=20 >>=20 >> For reference: >>=20 >> # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c = /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c = /sbin/gpart >> -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart >> -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 = /usr/src/contrib/libxo/libxo/libxo.c >> -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 = /usr/src/lib/geom/part/geom_part.c >> -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 = /usr/src/sbin/geom/core/geom.c >>=20 >> That explains the "warning: Source file is more recent than = executable" >> messages. >=20 > Additional context notes: >=20 > ) On the Cortex-A7 SUT the above is repeatable at the > shell prompt when logged in: just try "gpart show", > including via gdb use. "/rescue/gpart show" also > core dumps. >=20 > ) In a armv7 chroot on a aarch64 system (the Windows > Dev Kit 2023), the "gpart show" works just fine. >=20 > But the vintages could well be a little different. > (Tracing to git commits for pkgbase is problematical.) >=20 >=20 > I'll note: >=20 > Johan S=C3=B6llvander > Date: Thu, 18 Dec 2025 15:23:29 UTC=20 > The branch main has been updated by js: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D4f809ffec69cd6ede3e7be9a5bc876b2= e5931028 >=20 > commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 > Author: Johan S=C3=B6llvander > AuthorDate: 2025-12-18 15:06:09 +0000 > Commit: Johan S=C3=B6llvander > CommitDate: 2025-12-18 15:22:59 +0000 >=20 > gpart: add libxo support for "show" subcommand + man page updates >=20 > Added libxo support to `gpart show`, also updated the man > pages for geom and gpart to show where you can expect > libxo formatted output. >=20 > PR: 290629 > MFC after: 1 week > Sponsored by: ConnectWise > Reviewed by: asomers, mckusick, phil > Approved by: asomers (mentor) > Differential Revision: https://reviews.freebsd.org/D53950 > --- > . . . >=20 >=20 > Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone > would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. I shut down the OPi+2e and mounted the boot media on the Windows Dev Kit 2023 and then did a chroot into that boot media and tried "gpart show": "gpart show" worked just fine. What matters is which kernel it runs on for the exact same world files on the exact same media. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 08:23:12 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 4dfC6X5l9rz6LRKH for ; Sun, 28 Dec 2025 08:23:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4dfC6V2Qylz3V0B for ; Sun, 28 Dec 2025 08:23:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="BPg/uHQm"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.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=1766910206; bh=d6kkl2MwgtiFp8QAHXHOMXLC5V1hG6Pv6t1d8EfUg6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BPg/uHQmfs1cgabQyoTnI47/jRU5xfOI+d/XAnStIMg/ff7drzPbniK/cAFTGTjfyY0gVjT7eceyWdareaW4Xf1/ElaLlFdHuWna+0sNXkifMFN9WWecf9zmgbTjBQxHg3Ijr7K+kVtSBq2vnkgex2gsBLOyA/D4fSacbRdP9QJ0q9IyMdEAfRg2D+dHfguv2NXiukhcbjuH3+HMx6v4JkACh+cQfHffe7Z4XxNjKF54c/CkQDpQ17XKTdafJWEZ8hLIMxa7rioWKn8RRhGWDdG4RO5NI6/wE88+f7eLxQzng6pwyC8+rBUzINjbYsN9Yph9pmiQYbX2r+jumtL/+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766910206; bh=r7cldOjLHWv2/Qlz92yqceiSBzg4KeToKsVqfsFtNi3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KweZI7hmyFpHWaA2Jm6PxpPGneLwP4IB9jQc72TxMAyM/oYCL5o+MFIRUD31ixfYvqSueUU6/0DyUQSjx/h5Yo2mrP1jAfLXdWXfoI0HcCuigqhkIwjsygV+5YgQscbuMpobAtcvjrKQCBii/J7XdME0URa+3cyzlpfx7yhJqd0CkKVK4A5tmqxi9Y2eGZuwzaE0ulQpZv8+BtM21vdRiIsSBpvNLMX8zk04JQHmPtWv++t02bRONp8/e1dVgQWybWxoVI49QDgJVp8LAUV6ancvCIvwDTWqqCqL9pdhrA4h5FwUNQun9z/xWW7bPYBm6HMbnS03WdVnrmSPCw5lkQ== X-YMail-OSG: FXvbr6wVM1lqosKf8qYOvxVeeyfSwBhll9NxOacUN4mRICGtQQvNXlmPhr4U7aJ QgmeAW1i35HhIVsXph07DXhA.hBblzUQ5nYm.wniFSqoQTCxAuAJ21B_uI5quBBEhl1j4yolBwVT hXT4nXZqwwFuXwi0DR4P5KaUFs0y85zLlLSep.nEa0rtA8DCTXGFIt71CqkNp1eVi.goNexT2qS2 a_b7x2KnesAdC6ALAGf35HATgd9H3q3ozafScJbRQaMf4xD0AIkAM7h37sM1tI.KMyCfeWYL9trJ GY3hSqqasVjcJP4YdOwxRxRQgE0xw1G5HurC52q0b4jwZkO20kA6TiAyl.iLPM5otor6vjzDbgGi w5ZCr.oL3h6skiKgjxj5g09aNI4iUzr.oVvrLUaCSiUFDeaarR2b_PQDfvT3eGOzsueT8zjY8az9 Y5Xsw3Ucj0AfPdFyTvMTGYSyygSymaQK.FL_sTj5Iv4A4IDggF52X2HEf4ssjvKHIXW3qxv.lU8K 0Obg27hO.EIJ9Gc.D.lugTM28ekilB0bxA_.vJ7Y3ywSRROOaqldvXkJLC8zlhzctmrHQ234voY5 bE73YR2nxkJicQAgrsVIDbf9fyglu8xN8uZq13AwtNfIJ5fReouxn3nm8iqJd7DQ2r8zcjOwWlSN bwwlmvEO8x.yc41nxJNMlNu3xi.VzSiCX45aGIClmTwXgtPvSH8Vj.GH.d2MARrNu6cAfnYlLe2I PhTf0ZLtPrQP2bJn0oQx9GUKLwd962NlCb1CDxVLM7zqjXH2DgPa3Zg5s3xriKuOJRuXqp.QRwVl P49Z3onfrb077FwagQlvCnvdfXdg_AEhSTq_sAjwehF.6RoVmEmsK4ROjjXWOuY4XGWdniklkVNx Yo_tf0Gw9R5wwZUt0Dx5taP86Jioka5sAcPTPf3qF3bcJwK11sUXMquQrNknjzec0PObhIH1raXG .hDECezTnRtNnk0NonPb8xwosNU2cbXkYBsjxAS..GKQCZHtaxUWeq_N_yGJNAxJ9QvOd9i2kHkX F5CASupG_z1YpYObX4y77RaB_B1C2lJH3UPqc_0MHp66b.me7R1YXjOiES0lW8hEOx2wcSaBS0tv s22j_JDgQT5onuNiQAXjweKp4ntJND.I_RfBA8FF23_zCi7kz81XC2VasJr1n.pqWvj8xTDOV79A Yw8HmySmz.zpcHixRhQamYkkI2ovqLzED4FwuSApjV_2DeCFwRX01TAvTZPlAkpy3KUZxVY9NPsY hw866ocyeTkN1qHGvHaocthxAEH3On_qyhn27T3g1AJfjJbgErtyxTEYD14oiA5Onx1nE._baroQ sw2S3p1hMUL..YZOWefM8HcIm.KV1FR4CL6he7zA3SJMxo9mbmukATbtgYIOKmSD5L3b3ivQe5_7 qrhVafL37E_GuaFSnzbGXjxFA.EX7PpFqFCUmjKn5PIu2.dAF7QN89ZPIzbiXSwWmfP7.J9HDbo0 ouNsfWGxDrUWhk3DK5XAmAM3Z1wIGZ469i6v0Q8blCu3I895QoFwCBUUel4NPqLUqScVr47.kVKF qitETNcKucyPIXHlSQdCXt9Q4D.nlnDZMrabbVWbI9kUuIkNLAUr1kvFKf1kCij_AsXsshLxEmvV EBmZVE9V8HznkBmO6Riqmb.Aok2TCBfe95u_T1lRlDqQWAwZi0DvwrgB0_1lLwk_qfowQHzNy.Wd 7L.RC9HRHOPmhPjFfo2CiSspfk.lT8nemTI5rB3b8cqhMMF_r8lpZcwDNy2hP5Jx3LwVELxf94jF rl4H0fE.8d2hi9VzzBSQ_CvSDsA5O9LQLh5z5iGkva.5fsvBauFHOinjZpzz8IpD9L5WiNfKNawn LtY_5XFMa_KxxORYXwzFsAk51nCSk3VCh2ulZbq.GPzsNKTKABKbvecSeMFv_6vO7Zbm4KKNVVJg pXggcg5R2llAJK41wYWTJF2AkGkcChUkHEfcsIqX7IMXprAyQQRNyxjLU9GVegI4UR9lPRW3D0RJ 2ViC5MTiyUEpSprJ7B2wfO9zZut73BY.gfDWm69j9MsPv0ieYF75VJm3q0JATbmI1XaEPy_MDyf1 Pp24PTumYdYu9oV32fOzdoxbFwkTCFmYN4NCacwQbixvB8AM0f0WnPl9ezuQHYddRN2WQgNA4S.l o6kC2OFPJUHEYU7kDPL5SnKLvsRAtNEjR9lKjGqpUWRW3wOW.RJV2dcAWGmRER2YMzhNuyVwZdlj 15sAsP7eTMRBpy86lg7e35X4FNho7piXHz_whXp8QhOhajUuqMJ5pAe19auDyAwFc1t15A82MoDm uS18YFIgv X-Sonic-MF: X-Sonic-ID: d9ace80a-1e43-4957-b107-8cd2d2db9f39 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 08:23:26 +0000 Received: by hermes--production-gq1-54bf57fc64-trzjk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 351d25ed9a16f1850e3f2a8f6a30f6ad; Sun, 28 Dec 2025 08:23:23 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) From: Mark Millard In-Reply-To: <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> Date: Sun, 28 Dec 2025 00:23:12 -0800 Cc: Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> To: freebsd-arm , FreeBSD Current , "js@freebsd.org" X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.89)[-0.885]; 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)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; 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)[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.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from] X-Rspamd-Queue-Id: 4dfC6V2Qylz3V0B On Dec 27, 2025, at 23:55, Mark Millard wrote: > [Turns out: works on aarch64 kernel's armv7 support, fails > on the armv7 native kernel, exact same world files on the > exact same media.] I got that wrong: a large part of the output occurs before a segmentation fault on the Windows Dev Kit 2023. But it has a very different backtrace and the output before that has numerical garbage values showing. >=20 > On Dec 27, 2025, at 23:35, Mark Millard wrote: >=20 >> On Dec 27, 2025, at 22:03, Mark Millard wrote: >>=20 >>> Context: >>>=20 >>> # uname -apKU >>> FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >>>=20 >>> That is an official pkgbase distribution that I installed, not >>> a personal build. pkgbase for main has world being a debug >>> build, no matter which of the kernels one choses to boot. >>> For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel >>> but might not be exact for the world: /usr/src/sys/ and >>> /usr/src/ (without sys/) are from different times, last I >>> knew anyway. Changes can happen between. >>>=20 >>> During boot, the time on the Orange Pi Plus 2ed is bad so: >>>=20 >>> # ls -lodT /gpart.core=20 >>> -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 = /gpart.core >>>=20 >>> Also, for pkgbase, a source file distributed can be newer >>> for its time stamp than the program distributed that was >>> based on the source file. Such happens below. >>>=20 >>>=20 >>>=20 >>> Core was generated by `gpart show'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> Address not mapped to object. >>> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >>> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>=20 >>> warning: Source file is more recent than executable. >>> 2715 if (*cp =3D=3D '\0') >>> (gdb) bt >>> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >>> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >>> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, = xbp=3D0x2009b150, flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >>> #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120,= xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0x20130635 "%s", flen=3Dflen@entry=3D= 2, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 >>> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >>> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >>> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >>> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at /usr/src/lib/geom/part/geom_part.c:793 >>> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >>> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >>> (gdb) list >>> 2710 for (;;) { >>> 2711 if (len =3D=3D 0) >>> 2712 break; >>> 2713=20 >>> 2714 if (cp) { >>> 2715 if (*cp =3D=3D '\0') >>> 2716 break; >>> 2717 if ((flags & XFF_UNESCAPE) && (*cp =3D=3D '\\' || *cp =3D=3D = '%')) { >>> 2718 cp +=3D 1; >>> 2719 len -=3D 1; >>> (gdb) up >>> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, = xbp=3D0x2009b150, flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >>> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >>> (gdb) list >>> 2977=20 >>> 2978 return rc; >>> 2979 } >>> 2980 } >>> 2981=20 >>> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >>> 2983 xfp->xf_width[XF_WIDTH_MAX], >>> 2984 need_enc, xfp->xf_enc); >>> 2985 if (cols < 0) >>> 2986 goto bail; >>> (gdb) list >>> 3498=20 >>> 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? XF_ENC_UTF8 >>> 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? XF_ENC_WIDE >>> 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; >>> 3502=20 >>> 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); >>> 3504=20 >>> 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) >>> 3506 rc =3D xo_trim_ws(xbp, rc); >>> 3507=20 >>> (gdb) up >>> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>> (gdb) list >>> 3812 { >>> 3813 if (encode_only) >>> 3814 flags |=3D XFF_NO_OUTPUT; >>> 3815=20 >>> 3816 if (vlen =3D=3D 0) >>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>> 3818 else if (!encode_only) >>> 3819 xo_data_append_content(xop, value, vlen, flags); >>> 3820 } >>> 3821=20 >>> (gdb) up >>> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >>> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>> (gdb) list >>> 4368=20 >>> 4369 save.xhs_offset =3D xbp->xb_curp - xbp->xb_bufp; >>> 4370 save.xhs_columns =3D xop->xo_columns; >>> 4371 save.xhs_anchor_columns =3D xop->xo_anchor_columns; >>> 4372=20 >>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>> 4374=20 >>> 4375 if (flags & XFF_HUMANIZE) >>> 4376 xo_format_humanize(xop, xbp, &save, flags); >>> 4377 break; >>> (gdb) up >>> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>> (gdb) list >>> 6367 flags &=3D ~XFF_WS; /* Prevent later handling of this flag */ >>> 6368 } >>> 6369 } >>> 6370=20 >>> 6371 if (ftype =3D=3D 'V') >>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>> 6373 xfip->xfi_format, xfip->xfi_flen, >>> 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); >>> 6375 else if (ftype =3D=3D '[') >>> 6376 xo_anchor_start(xop, xfip, content, clen); >>> (gdb) up >>> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>> (gdb) list >>> 6546 /* Retain the info */ >>> 6547 xo_retain_add(fmt, fields, max_fields); >>> 6548 } >>> 6549 } >>> 6550=20 >>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>> 6552 } >>> 6553=20 >>> 6554 /* >>> 6555 * Rebuild a format string in a gettext-friendly format. This = function >>> (gdb) up >>> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>> 6622 rc =3D xo_do_emit(xop, 0, fmt); >>> (gdb) list >>> 6617 { >>> 6618 xo_handle_t *xop =3D xo_default(NULL); >>> 6619 ssize_t rc; >>> 6620=20 >>> 6621 va_start(xop->xo_vap, fmt); >>> 6622 rc =3D xo_do_emit(xop, 0, fmt); >>> 6623 va_end(xop->xo_vap); >>> 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); >>> 6625=20 >>> 6626 return rc; >>> (gdb) up >>> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >>> warning: Source file is more recent than executable. >>> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >>> (gdb) list >>> 649 } >>> 650 wname =3D wmax; >>> 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; >>> 652 secsz =3D pp->lg_sectorsize; >>> 653 xo_open_instance("part"); >>> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >>> 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), >>> 656 wname, gp->lg_name, >>> 657 scheme, pp->lg_mediasize, >>> 658 s ? " [CORRUPT]": ""); >>> (gdb) up >>> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at /usr/src/lib/geom/part/geom_part.c:793 >>> 793 gpart_show_geom(gp, element, show_providers); >>> (gdb) list >>> 788 else >>> 789 errx(EXIT_FAILURE, "No such geom: %s.", name); >>> 790 } >>> 791 } else { >>> 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { >>> 793 gpart_show_geom(gp, element, show_providers); >>> 794 } >>> 795 } >>> 796 xo_close_list(name); >>> 797 geom_deletetree(&mesh); >>> (gdb) up >>> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >>> warning: Source file is more recent than executable. >>> 497 cmd->gc_func(req, flags); >>> (gdb) list >>> 492 buf[0] =3D '\0'; >>> 493 if (cmd->gc_func !=3D NULL) { >>> 494 unsigned flags; >>> 495=20 >>> 496 flags =3D set_flags(cmd); >>> 497 cmd->gc_func(req, flags); >>> 498 errstr =3D req->error; >>> 499 } else { >>> 500 gctl_add_param(req, "output", sizeof(buf), buf, >>> 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); >>> (gdb) up >>> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >>> 861 run_command(argc, argv); >>> (gdb) list >>> 856 show_tree(); >>> 857 return (0); >>> 858 } >>> 859=20 >>> 860 get_class(&argc, &argv); >>> 861 run_command(argc, argv); >>> 862 /* NOTREACHED */ >>> 863=20 >>> 864 exit(EXIT_FAILURE); >>> 865 } >>>=20 >>>=20 >>> For reference: >>>=20 >>> # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c = /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c = /sbin/gpart >>> -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart >>> -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 = /usr/src/contrib/libxo/libxo/libxo.c >>> -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 = /usr/src/lib/geom/part/geom_part.c >>> -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 = /usr/src/sbin/geom/core/geom.c >>>=20 >>> That explains the "warning: Source file is more recent than = executable" >>> messages. >>=20 >> Additional context notes: >>=20 >> ) On the Cortex-A7 SUT the above is repeatable at the >> shell prompt when logged in: just try "gpart show", >> including via gdb use. "/rescue/gpart show" also >> core dumps. >>=20 >> ) In a armv7 chroot on a aarch64 system (the Windows >> Dev Kit 2023), the "gpart show" works just fine. >>=20 >> But the vintages could well be a little different. >> (Tracing to git commits for pkgbase is problematical.) >>=20 >>=20 >> I'll note: >>=20 >> Johan S=C3=B6llvander >> Date: Thu, 18 Dec 2025 15:23:29 UTC=20 >> The branch main has been updated by js: >>=20 >> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D4f809ffec69cd6ede3e7be9a5bc876b2= e5931028 >>=20 >> commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >> Author: Johan S=C3=B6llvander >> AuthorDate: 2025-12-18 15:06:09 +0000 >> Commit: Johan S=C3=B6llvander >> CommitDate: 2025-12-18 15:22:59 +0000 >>=20 >> gpart: add libxo support for "show" subcommand + man page updates >>=20 >> Added libxo support to `gpart show`, also updated the man >> pages for geom and gpart to show where you can expect >> libxo formatted output. >>=20 >> PR: 290629 >> MFC after: 1 week >> Sponsored by: ConnectWise >> Reviewed by: asomers, mckusick, phil >> Approved by: asomers (mentor) >> Differential Revision: https://reviews.freebsd.org/D53950 >> --- >> . . . >>=20 >>=20 >> Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone >> would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. >=20 >=20 > I shut down the OPi+2e and mounted the boot media > on the Windows Dev Kit 2023 and then did a chroot > into that boot media and tried "gpart show": >=20 > "gpart show" worked just fine. >=20 > What matters is which kernel it runs on for the > exact same world files on the exact same media. >=20 I got that wrong: a large part of the output occurs before a segmentation fault on the Windows Dev Kit 2023. But it has a very different backtrace. Also, note all the "517M" that make no sense --and the "0" and "2" junk as well: # gpart show=20 =3D> 34 1000215149 nda0 GPT (2)(null) 34 2014 - free - (2) 2048 532480 1 efi (517M) 534528 32768 2 ms-reserved (517M) 567296 997287936 3 ms-basic-data (517M) 997855232 2359296 4 ms-recovery (517M) 1000214528 655 - free - (2) =3D> 34 2930277101 da0 GPT (0)(null) 34 32734 - free - (0) 32768 501760 1 efi (517M) 534528 20971520 2 freebsd-swap (517M) 21506048 29360128 3 freebsd-swap (517M) 50866176 33554432 4 freebsd-swap (517M) 84420608 67108864 5 freebsd-swap (517M) 151529472 96468992 6 freebsd-swap (517M) 247998464 268435456 7 freebsd-swap (517M) 516433920 7340032 8 freebsd-swap (517M) 523773952 13096960 - free - (0) 536870912 2357198848 9 freebsd-ufs (517M) 2894069760 36207375 - free - (0) =3D> 40 1953525088 da1 GPT (0)(null) 40 532480 1 efi (517M) 532520 2008 - free - (0) 534528 3563520 2 freebsd-swap (517M) 4098048 6504448 - free - (0) 10602496 1740636160 4 freebsd-ufs (517M) 1751238656 7546880 3 freebsd-swap (517M) 1758785536 194739592 - free - (0) Segmentation fault (core dumped) As for gdb's backtrace: Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x200c5ef0 in delete_config (gp=3D0x2053e224) at = /usr/src/lib/libgeom/geom_xml2tree.c:502 warning: Source file is more recent than executable. 502 LIST_REMOVE(cf, lg_config); (gdb) bt #0 0x200c5ef0 in delete_config (gp=3D0x2053e224) at = /usr/src/lib/libgeom/geom_xml2tree.c:502 #1 geom_deletetree (gmp=3Dgmp@entry=3D0xffffcb48) at = /usr/src/lib/libgeom/geom_xml2tree.c:524 #2 0x204d2064 in gpart_show (req=3D, fl=3D) at /usr/src/lib/geom/part/geom_part.c:797 #3 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 #4 0x00022308 in main (argc=3D1, argv=3D0xffffdc70) at = /usr/src/sbin/geom/core/geom.c:861 (I need to get some sleep.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 09:28:51 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 4dfDZ16yP1z6LVtk for ; Sun, 28 Dec 2025 09:28:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward500d.mail.yandex.net (forward500d.mail.yandex.net [178.154.239.208]) (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 4dfDYz661pz3bCx for ; Sun, 28 Dec 2025 09:28:55 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=HVzXvJwZ; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 178.154.239.208 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru Received: from mail-nwsmtp-mxback-production-main-82.klg.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-82.klg.yp-c.yandex.net [IPv6:2a02:6b8:c43:a2b:0:640:585f:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id 4A87080612; Sun, 28 Dec 2025 12:28:53 +0300 (MSK) Received: from mail.yandex.ru (2a02:6b8:c43:4901:0:640:35d8:0 [2a02:6b8:c43:4901:0:640:35d8:0]) by mail-nwsmtp-mxback-production-main-82.klg.yp-c.yandex.net (mxback/Yandex) with HTTPS id TScCfg1smGk0-u5zjXEN1; Sun, 28 Dec 2025 12:28:52 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1766914132; bh=Px1JFDUdSEycftreStgnIrQAaIq9JrQ495xj6TZ7bTY=; h=Message-Id:References:Date:Cc:Subject:In-Reply-To:To:From; b=HVzXvJwZF6K4pJcf4bp3df8gzWESTOaUwv3+phpE+SCVcE9GIZXl0nRB0RgelgwFG qcvSW0bDKDVPs9QK4E+1aFqkJOyyNitRtvbNtP9lywWRjgqZ7ZRuT4eZ+fwfgbEj7m /rmuZwn8AtVBYfmBMRCpVgyd9a3Wokn8RSPZmu48= Received: by mail-sendbernar-production-main-69.klg.yp-c.yandex.net (sendbernar/Yandex) with HTTPS id 636bbd152db75e65dacb6607979126e1; Sun, 28 Dec 2025 12:28:51 +0300 From: Andrey V. Elsukov To: FreeBSD User , Ronald Klop Cc: FreeBSD CURRENT , David Wolfskill In-Reply-To: <20251225190836.6769e6d6@hermann> References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> Subject: Re: CURRENT: kernel panic in IPFW while stopping jails 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-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 28 Dec 2025 12:28:51 +0300 Message-Id: <26521766914006@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=utf-8 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.63 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.97)[0.967]; NEURAL_HAM_SHORT(-0.90)[-0.901]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:178.154.239.208/28]; MIME_HTML_ONLY(0.20)[]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a02:6b8:c43:4901:0:640:35d8:0:received]; FREEMAIL_FROM(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:~]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+] X-Rspamd-Queue-Id: 4dfDYz661pz3bCx

On Thu, 25 Dec 2025 18:30:45 +0100 (CET)
Ronald Klop <ronald-lists@klop.ws> wrote:
 

 Do you use bpf or tap in your ipfw rules?
 A panic with that was mentioned on the 20th. And fixed in the mean time of I
 remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854
 Regards,Ronald


Indeed, all boxes in question do have a tap0 at least defined -but in only one
case used.

Hi,
 
I don't think it is related to tap0.
If it is related to recent BPF changes in ipfw, you can try to remove "log" opcode
from your rules.
 
-- 
WBR, Andrey V. Elsukov
 
From nobody Sun Dec 28 11:01:59 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 4dfGcW2BYXz6LcNb; Sun, 28 Dec 2025 11:01:15 +0000 (UTC) (envelope-from js@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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dfGcW1hc1z3k0D; Sun, 28 Dec 2025 11:01:15 +0000 (UTC) (envelope-from js@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766919675; 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=RHmb6O0dewEFPAQJ/yJFYSd4sPTiBPrjW6Zdncp4jKM=; b=ZeeNKd/evHfdkrJPYpxziyOGQjHl7+nMPildQwYLPpeXRl0HwYRyTxE3gDqYSGPqPKMNAn 8QtXxdPOPfdwh7FdRFmowDclTPTcJNa2JaHSiqnmhQ+gjHbZoXXGv403idKfsQ9NcMdKvN 2V/wO//ng7T7mInf4EzIAPad59jcbt7lQZKDnpt8775dsIgLSTOz3xuTrbONhzcLRfKclU XsTZbpwhqwC1vejoIzJbDT0bzNErL6Mp5IBTom6D9ceLzk6ee0QiApi6nRxb5wRd/CvMVB o6w/6O4Ne5fMHJO8SE7sjZcycSIMdZ9bWXjF89/fbGBIlRmOeRHR4Hz5c8lnpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766919675; 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=RHmb6O0dewEFPAQJ/yJFYSd4sPTiBPrjW6Zdncp4jKM=; b=CykkxCF3T1XWw1PqXOQrpj4z9TPLeLbH91aBsY2FaS6HUJ6on7wv5j62FduKHLUFaWrlxO 2v26i6Gm4A/8vh7ZWquV2Ci3UtiwNXka23Tvu39V4JePUWKGIENikBvMp8zF3P7quvNdzZ vGNfMxxHV8897tcJg+MVX4Z51Xr+V62nrDO/2usTMnWxWHCbz+n5TnElXxu+fbBdgTsHS1 aEJC9PNn+2sMmHS383k0dGZZ/F9zZbrnfkwbPIQuAjex8VbdjKb22F0I0V/xvq8ssgC83+ oyqAjBWJfc3XUyzd/mAs5WtV8M0Nf1sgGCu/IFKAkrfmK7a7XAxiCDmYkytBTQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766919675; a=rsa-sha256; cv=none; b=G8QKe+Two0AcQZLgYZ4be/h7bTjtnWVrUKh81U46pBmttrFb6ie4deXmqxH75J2lTJPgIP 18ATTEOJoPO2kv3FC+S+7Q6fcQ+wM1SSIhTzG6DxtuhXJgvdbIae93jkDyq880aDG3bxGx eECxXj0KTK0ooAd8mJ+VbipvvUj7QxsUbiMzzRf/xHUE3g6hzzPkafx1y1QnNJMmMkPGTC fim/PYhO08VYSzluOKOrnu98SycyMz1wQzvxpHvvB4maUIXBMVw3S3vHw2RcFXGbAj20GO tRe8i92NxgaU59kSnue5dQ/b1C6zjt1fBXNc2sdfknQclzK2827fPqVRZvQjzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.227] (h-212-85-90-245.A980.priv.bahnhof.se [212.85.90.245]) (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) (Authenticated sender: js/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dfGcV4BjQz1Dw8; Sun, 28 Dec 2025 11:01:14 +0000 (UTC) (envelope-from js@FreeBSD.org) Message-ID: Date: Sun, 28 Dec 2025 12:01:59 +0100 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 From: "js@freebsd.org" Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) To: Mark Millard References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> Content-Language: en-US, sv-SE Cc: freebsd-arm , FreeBSD Current In-Reply-To: <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'll take a look at it and try to setup a reproducer, unfortunately my time is a bit limited during the holidays so I can't promise any quick fixes right now. Could you share the output of gpart --libxo:JP show with me? If possible. On 12/28/25 09:23, Mark Millard wrote: > On Dec 27, 2025, at 23:55, Mark Millard wrote: > >> [Turns out: works on aarch64 kernel's armv7 support, fails >> on the armv7 native kernel, exact same world files on the >> exact same media.] > > I got that wrong: a large part of the output occurs before a > segmentation fault on the Windows Dev Kit 2023. But it has a > very different backtrace and the output before that has numerical > garbage values showing. > >> >> On Dec 27, 2025, at 23:35, Mark Millard wrote: >> >>> On Dec 27, 2025, at 22:03, Mark Millard wrote: >>> >>>> Context: >>>> >>>> # uname -apKU >>>> FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >>>> >>>> That is an official pkgbase distribution that I installed, not >>>> a personal build. pkgbase for main has world being a debug >>>> build, no matter which of the kernels one choses to boot. >>>> For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel >>>> but might not be exact for the world: /usr/src/sys/ and >>>> /usr/src/ (without sys/) are from different times, last I >>>> knew anyway. Changes can happen between. >>>> >>>> During boot, the time on the Orange Pi Plus 2ed is bad so: >>>> >>>> # ls -lodT /gpart.core >>>> -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 /gpart.core >>>> >>>> Also, for pkgbase, a source file distributed can be newer >>>> for its time stamp than the program distributed that was >>>> based on the source file. Such happens below. >>>> >>>> >>>> >>>> Core was generated by `gpart show'. >>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>> Address not mapped to object. >>>> #0 xo_format_string_direct (xop=xop@entry=0x2009b120, xbp=xbp@entry=0x2009b150, flags=flags@entry=4096, wcp=0x0, cp=0x6e480000 , len=-1, max=-1, >>>> need_enc=3, have_enc=2) at /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>> >>>> warning: Source file is more recent than executable. >>>> 2715 if (*cp == '\0') >>>> (gdb) bt >>>> #0 xo_format_string_direct (xop=xop@entry=0x2009b120, xbp=xbp@entry=0x2009b150, flags=flags@entry=4096, wcp=0x0, cp=0x6e480000 , len=-1, max=-1, >>>> need_enc=3, have_enc=2) at /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>> #1 0x20150908 in xo_format_string (xop=0x2009b120, xbp=0x2009b150, flags=4096, xfp=0xbfbfd280) at /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>> #2 xo_do_format_field (xop=, xop@entry=0x2009b120, xbp=0x2009b150, fmt=fmt@entry=0x20130635 "%s", flen=flen@entry=2, flags=4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 >>>> #3 0x2014c69c in xo_simple_field (xop=0x2009b120, encode_only=0, value=0x0, vlen=0, fmt=0x20130635 "%s", flen=2, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>> #4 xo_format_value (xop=, xop@entry=0x2009b120, name=, name@entry=0x204bf931 "state}\n", nlen=, nlen@entry=5, value=0x0, vlen=0, fmt=0x20130635 "%s", >>>> flen=2, encoding=0x0, elen=0, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>> #5 0x20148710 in xo_do_emit_fields (xop=, xop@entry=0x2009b120, fields=, fields@entry=0xbfbfd7e8, max_fields=max_fields@entry=17, fmt=) >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>> #6 0x201476a0 in xo_do_emit (xop=xop@entry=0x2009b120, flags=, fmt=fmt@entry=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>> #7 0x20147840 in xo_emit (fmt=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>> #8 0x204d1fd4 in gpart_show_geom (gp=gp@entry=0x20089168, element=element@entry=0x204bfe51 "type", show_providers=show_providers@entry=0) at /usr/src/lib/geom/part/geom_part.c:654 >>>> #9 0x204d1048 in gpart_show (req=0x20089000, fl=) at /usr/src/lib/geom/part/geom_part.c:793 >>>> #10 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 >>>> #11 0x00022308 in main (argc=1, argv=0xbfbfed90) at /usr/src/sbin/geom/core/geom.c:861 >>>> (gdb) list >>>> 2710 for (;;) { >>>> 2711 if (len == 0) >>>> 2712 break; >>>> 2713 >>>> 2714 if (cp) { >>>> 2715 if (*cp == '\0') >>>> 2716 break; >>>> 2717 if ((flags & XFF_UNESCAPE) && (*cp == '\\' || *cp == '%')) { >>>> 2718 cp += 1; >>>> 2719 len -= 1; >>>> (gdb) up >>>> #1 0x20150908 in xo_format_string (xop=0x2009b120, xbp=0x2009b150, flags=4096, xfp=0xbfbfd280) at /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>> 2982 cols = xo_format_string_direct(xop, xbp, flags, wcp, cp, len, >>>> (gdb) list >>>> 2977 >>>> 2978 return rc; >>>> 2979 } >>>> 2980 } >>>> 2981 >>>> 2982 cols = xo_format_string_direct(xop, xbp, flags, wcp, cp, len, >>>> 2983 xfp->xf_width[XF_WIDTH_MAX], >>>> 2984 need_enc, xfp->xf_enc); >>>> 2985 if (cols < 0) >>>> 2986 goto bail; >>>> (gdb) list >>>> 3498 >>>> 3499 xf.xf_enc = (xf.xf_fc == 'm') ? XF_ENC_UTF8 >>>> 3500 : (xf.xf_lflag || (xf.xf_fc == 'S')) ? XF_ENC_WIDE >>>> 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; >>>> 3502 >>>> 3503 rc = xo_format_string(xop, xbp, flags, &xf); >>>> 3504 >>>> 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) >>>> 3506 rc = xo_trim_ws(xbp, rc); >>>> 3507 >>>> (gdb) up >>>> #3 0x2014c69c in xo_simple_field (xop=0x2009b120, encode_only=0, value=0x0, vlen=0, fmt=0x20130635 "%s", flen=2, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>> (gdb) list >>>> 3812 { >>>> 3813 if (encode_only) >>>> 3814 flags |= XFF_NO_OUTPUT; >>>> 3815 >>>> 3816 if (vlen == 0) >>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>> 3818 else if (!encode_only) >>>> 3819 xo_data_append_content(xop, value, vlen, flags); >>>> 3820 } >>>> 3821 >>>> (gdb) up >>>> #4 xo_format_value (xop=, xop@entry=0x2009b120, name=, name@entry=0x204bf931 "state}\n", nlen=, nlen@entry=5, value=0x0, vlen=0, fmt=0x20130635 "%s", >>>> flen=2, encoding=0x0, elen=0, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>> (gdb) list >>>> 4368 >>>> 4369 save.xhs_offset = xbp->xb_curp - xbp->xb_bufp; >>>> 4370 save.xhs_columns = xop->xo_columns; >>>> 4371 save.xhs_anchor_columns = xop->xo_anchor_columns; >>>> 4372 >>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>> 4374 >>>> 4375 if (flags & XFF_HUMANIZE) >>>> 4376 xo_format_humanize(xop, xbp, &save, flags); >>>> 4377 break; >>>> (gdb) up >>>> #5 0x20148710 in xo_do_emit_fields (xop=, xop@entry=0x2009b120, fields=, fields@entry=0xbfbfd7e8, max_fields=max_fields@entry=17, fmt=) >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>> (gdb) list >>>> 6367 flags &= ~XFF_WS; /* Prevent later handling of this flag */ >>>> 6368 } >>>> 6369 } >>>> 6370 >>>> 6371 if (ftype == 'V') >>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>> 6373 xfip->xfi_format, xfip->xfi_flen, >>>> 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); >>>> 6375 else if (ftype == '[') >>>> 6376 xo_anchor_start(xop, xfip, content, clen); >>>> (gdb) up >>>> #6 0x201476a0 in xo_do_emit (xop=xop@entry=0x2009b120, flags=, fmt=fmt@entry=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>> (gdb) list >>>> 6546 /* Retain the info */ >>>> 6547 xo_retain_add(fmt, fields, max_fields); >>>> 6548 } >>>> 6549 } >>>> 6550 >>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>> 6552 } >>>> 6553 >>>> 6554 /* >>>> 6555 * Rebuild a format string in a gettext-friendly format. This function >>>> (gdb) up >>>> #7 0x20147840 in xo_emit (fmt=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>> 6622 rc = xo_do_emit(xop, 0, fmt); >>>> (gdb) list >>>> 6617 { >>>> 6618 xo_handle_t *xop = xo_default(NULL); >>>> 6619 ssize_t rc; >>>> 6620 >>>> 6621 va_start(xop->xo_vap, fmt); >>>> 6622 rc = xo_do_emit(xop, 0, fmt); >>>> 6623 va_end(xop->xo_vap); >>>> 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); >>>> 6625 >>>> 6626 return rc; >>>> (gdb) up >>>> #8 0x204d1fd4 in gpart_show_geom (gp=gp@entry=0x20089168, element=element@entry=0x204bfe51 "type", show_providers=show_providers@entry=0) at /usr/src/lib/geom/part/geom_part.c:654 >>>> warning: Source file is more recent than executable. >>>> 654 xo_emit("=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", >>>> (gdb) list >>>> 649 } >>>> 650 wname = wmax; >>>> 651 pp = LIST_FIRST(&gp->lg_consumer)->lg_provider; >>>> 652 secsz = pp->lg_sectorsize; >>>> 653 xo_open_instance("part"); >>>> 654 xo_emit("=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", >>>> 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), >>>> 656 wname, gp->lg_name, >>>> 657 scheme, pp->lg_mediasize, >>>> 658 s ? " [CORRUPT]": ""); >>>> (gdb) up >>>> #9 0x204d1048 in gpart_show (req=0x20089000, fl=) at /usr/src/lib/geom/part/geom_part.c:793 >>>> 793 gpart_show_geom(gp, element, show_providers);would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. >>>> (gdb) list >>>> 788 else >>>> 789 errx(EXIT_FAILURE, "No such geom: %s.", name); >>>> 790 } >>>> 791 } else { >>>> 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { >>>> 793 gpart_show_geom(gp, element, show_providers); >>>> 794 } >>>> 795 } >>>> 796 xo_close_list(name); >>>> 797 geom_deletetree(&mesh); >>>> (gdb) up >>>> #10 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 >>>> warning: Source file is more recent than executable. >>>> 497 cmd->gc_func(req, flags); >>>> (gdb) list >>>> 492 buf[0] = '\0'; >>>> 493 if (cmd->gc_func != NULL) { >>>> 494 unsigned flags; >>>> 495 >>>> 496 flags = set_flags(cmd); >>>> 497 cmd->gc_func(req, flags); >>>> 498 errstr = req->error; >>>> 499 } else { >>>> 500 gctl_add_param(req, "output", sizeof(buf), buf, >>>> 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); >>>> (gdb) up >>>> #11 0x00022308 in main (argc=1, argv=0xbfbfed90) at /usr/src/sbin/geom/core/geom.c:861 >>>> 861 run_command(argc, argv); >>>> (gdb) list >>>> 856 show_tree(); >>>> 857 return (0); >>>> 858 } >>>> 859 >>>> 860 get_class(&argc, &argv); >>>> 861 run_command(argc, argv); >>>> 862 /* NOTREACHED */ >>>> 863 >>>> 864 exit(EXIT_FAILURE); >>>> 865 } >>>> >>>> >>>> For reference: >>>> >>>> # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c /sbin/gpart >>>> -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart >>>> -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 /usr/src/contrib/libxo/libxo/libxo.c >>>> -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 /usr/src/lib/geom/part/geom_part.c >>>> -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 /usr/src/sbin/geom/core/geom.c >>>> >>>> That explains the "warning: Source file is more recent than executable" >>>> messages. >>> >>> Additional context notes: >>> >>> ) On the Cortex-A7 SUT the above is repeatable at the >>> shell prompt when logged in: just try "gpart show", >>> including via gdb use. "/rescue/gpart show" also >>> core dumps. >>> >>> ) In a armv7 chroot on a aarch64 system (the Windows >>> Dev Kit 2023), the "gpart show" works just fine. >>> >>> But the vintages could well be a little different. >>> (Tracing to git commits for pkgbase is problematical.) >>> >>> >>> I'll note: >>> >>> Johan Söllvander >>> Date: Thu, 18 Dec 2025 15:23:29 UTC >>> The branch main has been updated by js: >>> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >>> >>> commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >>> Author: Johan Söllvander >>> AuthorDate: 2025-12-18 15:06:09 +0000 >>> Commit: Johan Söllvander >>> CommitDate: 2025-12-18 15:22:59 +0000 >>> >>> gpart: add libxo support for "show" subcommand + man page updates >>> >>> Added libxo support to `gpart show`, also updated the man >>> pages for geom and gpart to show where you can expect >>> libxo formatted output. >>> >>> PR: 290629 >>> MFC after: 1 week >>> Sponsored by: ConnectWise >>> Reviewed by: asomers, mckusick, phil >>> Approved by: asomers (mentor) >>> Differential Revision: https://reviews.freebsd.org/D53950 >>> --- >>> . . . >>> >>> >>> Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone >>> would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. >> >> >> I shut down the OPi+2e and mounted the boot media >> on the Windows Dev Kit 2023 and then did a chroot >> into that boot media and tried "gpart show": >> >> "gpart show" worked just fine. >> >> What matters is which kernel it runs on for the >> exact same world files on the exact same media. >> > > I got that wrong: a large part of the output occurs before > a segmentation fault on the Windows Dev Kit 2023. But it has a > very different backtrace. Also, note all the "517M" that make no > sense --and the "0" and "2" junk as well: > > # gpart show > => 34 1000215149 nda0 GPT (2)(null) > 34 2014 - free - (2) > 2048 532480 1 efi (517M) > 534528 32768 2 ms-reserved (517M) > 567296 997287936 3 ms-basic-data (517M) > 997855232 2359296 4 ms-recovery (517M) > 1000214528 655 - free - (2) > > => 34 2930277101 da0 GPT (0)(null) > 34 32734 - free - (0) > 32768 501760 1 efi (517M) > 534528 20971520 2 freebsd-swap (517M) > 21506048 29360128 3 freebsd-swap (517M) > 50866176 33554432 4 freebsd-swap (517M) > 84420608 67108864 5 freebsd-swap (517M) > 151529472 96468992 6 freebsd-swap (517M) > 247998464 268435456 7 freebsd-swap (517M) > 516433920 7340032 8 freebsd-swap (517M) > 523773952 13096960 - free - (0) > 536870912 2357198848 9 freebsd-ufs (517M) > 2894069760 36207375 - free - (0) > > => 40 1953525088 da1 GPT (0)(null) > 40 532480 1 efi (517M) > 532520 2008 - free - (0) > 534528 3563520 2 freebsd-swap (517M) > 4098048 6504448 - free - (0) > 10602496 1740636160 4 freebsd-ufs (517M) > 1751238656 7546880 3 freebsd-swap (517M) > 1758785536 194739592 - free - (0) > > Segmentation fault (core dumped) > > As for gdb's backtrace: > > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 0x200c5ef0 in delete_config (gp=0x2053e224) at /usr/src/lib/libgeom/geom_xml2tree.c:502 > > warning: Source file is more recent than executable. > 502 LIST_REMOVE(cf, lg_config); > (gdb) bt > #0 0x200c5ef0 in delete_config (gp=0x2053e224) at /usr/src/lib/libgeom/geom_xml2tree.c:502 > #1 geom_deletetree (gmp=gmp@entry=0xffffcb48) at /usr/src/lib/libgeom/geom_xml2tree.c:524 > #2 0x204d2064 in gpart_show (req=, fl=) at /usr/src/lib/geom/part/geom_part.c:797 > #3 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 > #4 0x00022308 in main (argc=1, argv=0xffffdc70) at /usr/src/sbin/geom/core/geom.c:861 > > > (I need to get some sleep.) > > > === > Mark Millard > marklmi at yahoo.com > From nobody Sun Dec 28 11:36:05 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 4dfHNn60Z4z6LfrK for ; Sun, 28 Dec 2025 11:36:09 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 "mx1.riseup.net", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dfHNm4sqTz3p25 for ; Sun, 28 Dec 2025 11:36:08 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b="q44bbX/h"; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews04-sea.riseup.net (fews04-sea-pn.riseup.net [10.0.1.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4dfHNk5sdFzDq9p; Sun, 28 Dec 2025 11:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riseup.net; s=squak; t=1766921767; bh=cxtE/DC+0APSHNhm+znuFHElBv8CQ6brRxCJsQCIr9Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q44bbX/h+UaZbHY1L/orKsxWnJlzhvatiQJBPi2RZ5IKAkJ9VY6FuqBZX2p/GRR/P rwbXwlTA0KvlNELYQSCzdVskZEnpoxkgod8uXpE13qkoEscOSLnNHVl6uwUgEhdOdb qOcgwPxi8ayjhyUYofDIdhw4aKK1FjD6PUbSB/3I= X-Riseup-User-ID: 35A01C610718552CDC4FCDE596BFE83574190FF31540287C5535B3AEA7F32297 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews04-sea.riseup.net (Postfix) with ESMTPSA id 4dfHNk0d0vz5w8p; Sun, 28 Dec 2025 11:36:05 +0000 (UTC) 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 Date: Sun, 28 Dec 2025 11:36:05 +0000 From: Alastair Hogge To: A FreeBSD User Cc: Ronald Klop , FreeBSD CURRENT , David Wolfskill Subject: Re: CURRENT: kernel panic in IPFW while stopping jails In-Reply-To: <20251226103308.72204662@thor.sb211.local> References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> <20251226103308.72204662@thor.sb211.local> Message-ID: <291e26bfbe2b51835f7672db3a2e3593@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.963]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_SPF_ALLOW(-0.20)[+a:mx1.riseup.net]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[198.252.153.129:from]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[riseup.net:+] X-Rspamd-Queue-Id: 4dfHNm4sqTz3p25 On 2025-12-26 17:32, A FreeBSD User wrote: > Am Tage des Herren Thu, 25 Dec 2025 19:08:36 +0100 > FreeBSD User schrieb: > >> On Thu, 25 Dec 2025 18:30:45 +0100 (CET) >> Ronald Klop wrote: >> >> > Do you use bpf or tap in your ipfw rules? >> > A panic with that was mentioned on the 20th. And fixed in the mean time of I >> > remember correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291854 >> > Regards,Ronald >> >> Indeed, all boxes in question do have a tap0 at least defined -but in only one >> case used. >> >> Kind regards, >> >> oh >> >> >> > >> > Van: FreeBSD User >> > Datum: 25 december 2025 17:09 >> > Aan: FreeBSD CURRENT >> > Onderwerp: CURRENT: kernel panic in IPFW while stopping jails >> > >> > > >> > > >> > > Hello, >> > > >> > > on recent CURRENT ipfw (in my case compiled into kernel) either restarting >> > > "ipfw" via "service ipfw restart" or restarting jails using also ipfw on a >> > > host also using ipfw (jail-hoster also ipfw compiled into kernel) causes a >> > > fatal kernel crash. >> > > >> > > This issue is present since last week an wreak havok to several boxes with >> > > OS installed on UFS/FFS SSDs. In one case I have only pictures/screenshots >> > > made via smartphone - while crashing, kernel debugger input pops up on >> > > console, but I'm able to typein something within the first seconds and this >> > > is mostly "reboot" but gets stuck with "re" in most cases. "bt" freezes >> > > system immediately. >> > > >> > > At least I can reproduce this misbehaviour on all recent CURRENT were IPFW >> > > is compiled into kernel. Anybody else havong this trouble? >> > > >> > > Kind regards, >> > > >> > > Oliver >> > > >> > > Merry Christmas to everyone. >> > > >> > > -- >> > > >> > > A FreeBSD user >> > > >> > > >> > > >> > > >> > > >> >> > > tap0 disabled/deleted. Same issue on every box. $ git bisect log git bisect start # status: waiting for both good and bad commits # bad: [086bedb11a853801e82234b8a1a64f0df52d9e52] tools.build: also add sys/_visible.h to SYSINCS git bisect bad 086bedb11a853801e82234b8a1a64f0df52d9e52 # status: waiting for good commit(s), bad commit known # good: [44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9] tcp: improve credential handling in syncache git bisect good 44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9 # good: [b0c7eaf83d21bbc333e247ab9e136965b3ca54ed] bhyve/slirp: Drop privileges before entering capability mode git bisect good b0c7eaf83d21bbc333e247ab9e136965b3ca54ed # good: [6a75e3951506c12b42428a47710d07cadcdd723e] ofed/libibverbs: remove strdupa() hack from config.h git bisect good 6a75e3951506c12b42428a47710d07cadcdd723e # bad: [1fad49baf390cb52f238e6c352d0bc0893c008c3] sdhci: Try to complete the last transaction if dumping git bisect bad 1fad49baf390cb52f238e6c352d0bc0893c008c3 # good: [9d9974457ce8c6cf9023884ab457d4712dcc237f] bhyvectl: fix build without BHYVE_SNAPSHOT git bisect good 9d9974457ce8c6cf9023884ab457d4712dcc237f # bad: [52395203f9ac40d321ed55d93e9887300261d3bf] MFV: Import blocklist 2025-12-15 (8a4b011) git bisect bad 52395203f9ac40d321ed55d93e9887300261d3bf # good: [c112ad75605ccdfcb8bbce2f57b0e7a077f057f8] options: describe WITH_IPFILTER_IPFS git bisect good c112ad75605ccdfcb8bbce2f57b0e7a077f057f8 # good: [8774a990ee4094f16d596d4b78e0f3239e5d0c88] bpf: modularize ifnet(9) part of bpf git bisect good 8774a990ee4094f16d596d4b78e0f3239e5d0c88 # bad: [1615eff94cda8619561b73186ec8098cc8b14c5c] usb: don't create ifnet(9) for usbus devices git bisect bad 1615eff94cda8619561b73186ec8098cc8b14c5c # good: [ddf4f9eda9c295082f17e7f26963666b72c97bb9] ipfw: create "ipfw0" and "ipfwlog0" bpf tapping points without ifnet(9) git bisect good ddf4f9eda9c295082f17e7f26963666b72c97bb9 # bad: [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw: create a bpf tap point for every log rule git bisect bad 3daae1ac1d82ecdcd855101bab5206e914b12350 # good: [1c5021f5251b231b614ad9cd175bcb4250495c12] ifconfig: print warning and return success on ipfw0, ipfwlog0 cloning git bisect good 1c5021f5251b231b614ad9cd175bcb4250495c12 # first bad commit: [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw: create a bpf tap point for every log rule https://codeberg.org/FreeBSD/freebsd-src/commit/3daae1ac1d82ecdcd855101bab5206e914b12350 ipfw: create a bpf tap point for every log rule Dynamically allocate bpf tap points for every rule that has "log". The name is "ipfw%u", where %u is substituted to the rule number. The default catch all "ipfw0" tap still exists for compatibility and it will catch packets in case if there are no bpf listeners on a per-rule tap. Reviewed by: ae Differential Revision: https://reviews.freebsd.org/D53877 From nobody Sun Dec 28 12:33:33 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 4dfJhG34kTz6LkRw for ; Sun, 28 Dec 2025 12:34:38 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E7" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dfJhF6lTNz3wcv for ; Sun, 28 Dec 2025 12:34:37 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([IPv6:2001:500:6b:200:c000:0:0:71f]) (authenticated bits=0) by prime.gushi.org (8.18.1/8.18.1) with ESMTPSA id 5BSCXkQJ070610 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Dec 2025 12:33:47 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 5BSCXkQJ070610 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1766925228; bh=9nRNuxsz54yACroCANg70sQC/nqH7hC1WF70d4Zae+g=; h=From:Subject:Date:In-Reply-To:Cc:To:References; z=From:=20"Dan=20Mahoney=20(ports)"=20|Subject:= 20Re:=20CURRENT:=20kernel=20panic=20in=20IPFW=20while=20stopping=2 0jails|Date:=20Sun,=2028=20Dec=202025=2004:33:33=20-0800|In-Reply- To:=20<291e26bfbe2b51835f7672db3a2e3593@riseup.net>|Cc:=20A=20Free BSD=20User=20,=0D=0A=20Ronald=20Klop=20,=0D=0A=20FreeBSD=20CURRENT=20,=0D=0A=20David=20Wolfskill=20|T o:=20Alastair=20Hogge=20|References:=20<2025122517 0828.7aef61df@hermann>=0D=0A=20<902742484.3865.1766683845222@local host>=20<20251225190836.6769e6d6@hermann>=0D=0A=20<20251226103308. 72204662@thor.sb211.local>=0D=0A=20<291e26bfbe2b51835f7672db3a2e35 93@riseup.net>; b=I8vrhbz/Hc642BbZTK3q4euDnk2tL6terRiY78MhToMwG86VjQpq/+smkpVMPEYl4 UxBgrciHi4sluWehtov+x3sQLvOIgFuryQGwG4zijF4EcL9U5eCgcF1vD4bQlIUn2q ZYdsoAliMGwVlmBHzn9F0WsynLnJDHdS9KYneQv6r9EAZVbn5vkpQOWWNzfYnpdcQ4 GVkJ4grC3TJTmAlq8VjkXqIfMESuj+9IHkD4i6zKLe2iij2shCRW7AYPh1eLEygw5p LaUEVMqdWRa314yRBGlGGrE9bKmPYBGs/9WPfm35qcIZOpKZiUz1VIDGZ7JrvYdd/+ tBlmYBWYgAJMw== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2001:500:6b:200:c000:0:0:71f] claimed to be smtpclient.apple From: "Dan Mahoney (ports)" Message-Id: <8E7598CD-640D-4E15-8576-2A4DE38A4C13@gushi.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E4599F8-0D63-4CF7-B601-AEEBB1F7037A" 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 \(3864.300.41.1.7\)) Subject: Re: CURRENT: kernel panic in IPFW while stopping jails Date: Sun, 28 Dec 2025 04:33:33 -0800 In-Reply-To: <291e26bfbe2b51835f7672db3a2e3593@riseup.net> Cc: A FreeBSD User , Ronald Klop , FreeBSD CURRENT , David Wolfskill To: Alastair Hogge References: <20251225170828.7aef61df@hermann> <902742484.3865.1766683845222@localhost> <20251225190836.6769e6d6@hermann> <20251226103308.72204662@thor.sb211.local> <291e26bfbe2b51835f7672db3a2e3593@riseup.net> X-Mailer: Apple Mail (2.3864.300.41.1.7) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dfJhF6lTNz3wcv --Apple-Mail=_5E4599F8-0D63-4CF7-B601-AEEBB1F7037A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 28, 2025, at 3:36=E2=80=AFAM, Alastair Hogge = wrote: ...sending from the right account this time... (Mail clients break = becausse they only see the list-address in the To: header so don't use = the right role). Removing my final "log" rule fixes this for me, yes. (That probably = should be sufficient for anyone else to reproduce, I posted earlier in = thread, but my final rule (before the automatic ones at 65535) is "reset = log ip from any to any"). My panic output looks like this (there might be slight character misses = because this is text copy/pasted from a screenshot (so the console zero = font gets grabbed as =C3=98) I don't have good knowledge of how to drive = the kernel debugger. Feel free to email me privately on-list if you can = tell me a command=20 I didn't want to reopen the other bug, but it might belong there. -Dan=20 panic: Assertion tap !=3D NULL failed at = /usr/src/sys/netpfil/ipfw/ip_fw_bpf.c:127 cpuid =3D 9 tie =3D 1766922462 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+@x2b/frame = =C3=98xfffffe0123=C3=98a35c=C3=98 vpanic() at vpanic+0x136/frame =C3=98xfffffe01230a36f0 panic() at panic+0x43/frame =C3=98xfffffe01230a3750 ipfw_bpf_tap() at ipfw_bpf_tap+@x104/frame =C3=98xfffffe01230a3760 ipfw_chk() at ipfw_chk+@x1e37/frame =C3=98xfffffe01230a3990 ipfw_check_packet() at ipfw_check_packet+@xf6/frame 0xfffffe01230a3a80 pfil_mbuf_in() at pfil_mbuf_in+@x58/frame @xfffffe01230a3ab0 ip input ) at ip_input+@x3f9/frame Bxfffffe01230a3b10 netisr_dispatch_src() at netisr_dispatch_src+@xb4/frame = =C3=98xfffffe=C3=98123=C3=98a3b7=C3=98 ether_demux() at ether_demux+0x16a/frame =C3=98xfffffe01230a3ba=C3=98 ether_nh_input() at ether_nh_input+@x3ce/frame =C3=98xfffffe01230a3bf0 _src+0xb4/frame netisr_dispatch_src() at netisr_dispatch_src+=C3=98xb4/frame = =C3=98xfffffe0123=C3=98a3c50 ether_input () at ether_input+@xd5/frame @xfffffe01230a3cb0 tcp_lro_flush_all() at top_lro_flush_all+@xdc/frame =C3=98xfffffe01230a3d0= 0 iflib_rxeof() at iflib_rxeof+@xbef/frame =C3=98xfffffe01230a3e00 _task_in_rx() at _task _fn_rx+@x7a/frame =C3=98xfffffe01230a3e40 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x18e/frame = =C3=98xfffffe01230a3ec0 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+@xd3/frame = @xfffffe01230a3ef0 _1oop+@xd3/frame fork_exit() at fork_exit+0x82/frame =C3=98xfffffe01230a3f30 fork_trampoline() at fork_trampoline+@xe/frame Bxfffffe01230a3f30 But I don't actually get a kernel dump. lb> bt Tracing pid 8 tid 100032 td Bxfffff80004725000 kdb_enter() at kdb_enter+=C3=98x33/frame =C3=98xfffffe=C3=98123=C3=98a36f0= panic() at panic+0x43/frame =C3=98xfffffe01230a3750 ipfw_bpf_tap() at ipfw_bpf_tap+@x184/frame =C3=98xfffffe=C3=98123=C3=98a37= 60 ipfw_chk() at ipfw_chk+@x1e37/frame =C3=98xfffffe01230a3990 ipfw_check_packet() at ipfw_check_packet+=C3=98xf6/frame = =C3=98xfffffe=C3=98123=C3=98a3a8=C3=98 pfil_mbuf _in() at pfil_mbuf_in+@x58/frame BxfffffeB1230a3ab0 ip_input() at ip_input+@x3f9/frame =C3=98xfffffe01230a3b10 netisr_dispatch_src() at netisr_dispatch_src+@xb4/frame = =C3=98xfffffe01230a3b70 ether_demux() at ether_de=D0=BCux+@x16a/frame Bxfffffe01230a3ba=C3=B8 ether_nh_input() at ether_nh_input+=C3=98x3ce/frame Bxfffffe01230a3bf8 netisr_dispatch_src() at netisr _dispatch_src+@xb4/fra=D0=BCe =C3=98xfffffe0123=C3=98a3c5=C3=98 ether_input() at ether_input+0xd5/frame Bxfffffe0123=C3=98a3cb=C3=98 top_lro_flush_alll) at top_lro_flush_all+@xdc/frame @xfffffe01230a3dB0 iflib_rxeof() at iflib_rxeof+@xbef/frame =C3=98xfffffe01230a3eB8 _task_fn_rx() at _task_fn_rx+@x7a/frame =C3=98xfffffe0123=C3=98a3e40 gtaskqueue_run_locked() at gtaskqueue_run_locked+@x18e/frame = =C3=98xfffffe01230a3ec=C3=98 gtaskqueue_thread_loop() at gtaskqueue_thread _1oop+=C3=98xd3/frame =C3=98xfffffe0123=C3=98a3efE fork_exit() at fork_exit+0x82/fra=D0=BCe =C3=98xfffffe0123=C3=98a3f30 fork_trampoline() at fork_trampoline+@xe/frame Bxfffffe0123=C3=98a3f30 >=20 > On 2025-12-26 17:32, A FreeBSD User wrote: >> Am Tage des Herren Thu, 25 Dec 2025 19:08:36 +0100 >> FreeBSD User schrieb: >>=20 >>> On Thu, 25 Dec 2025 18:30:45 +0100 (CET) >>> Ronald Klop wrote: >>>=20 >>>> Do you use bpf or tap in your ipfw rules? >>>> A panic with that was mentioned on the 20th. And fixed in the mean = time of I >>>> remember correctly. = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291854 >>>> Regards,Ronald =20 >>>=20 >>> Indeed, all boxes in question do have a tap0 at least defined -but = in only one >>> case used. >>>=20 >>> Kind regards, >>>=20 >>> oh >>>=20 >>>=20 >>>>=20 >>>> Van: FreeBSD User >>>> Datum: 25 december 2025 17:09 >>>> Aan: FreeBSD CURRENT >>>> Onderwerp: CURRENT: kernel panic in IPFW while stopping jails >>>>=20 >>>>>=20 >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> on recent CURRENT ipfw (in my case compiled into kernel) either = restarting >>>>> "ipfw" via "service ipfw restart" or restarting jails using also = ipfw on a >>>>> host also using ipfw (jail-hoster also ipfw compiled into kernel) = causes a >>>>> fatal kernel crash. >>>>>=20 >>>>> This issue is present since last week an wreak havok to several = boxes with >>>>> OS installed on UFS/FFS SSDs. In one case I have only = pictures/screenshots >>>>> made via smartphone - while crashing, kernel debugger input pops = up on >>>>> console, but I'm able to typein something within the first seconds = and this >>>>> is mostly "reboot" but gets stuck with "re" in most cases. "bt" = freezes >>>>> system immediately. >>>>>=20 >>>>> At least I can reproduce this misbehaviour on all recent CURRENT = were IPFW >>>>> is compiled into kernel. Anybody else havong this trouble? >>>>>=20 >>>>> Kind regards, >>>>>=20 >>>>> Oliver >>>>>=20 >>>>> Merry Christmas to everyone. >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> A FreeBSD user >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>=20 >> tap0 disabled/deleted. Same issue on every box. >=20 > $ git bisect log > git bisect start > # status: waiting for both good and bad commits > # bad: [086bedb11a853801e82234b8a1a64f0df52d9e52] tools.build: also = add > sys/_visible.h to SYSINCS > git bisect bad 086bedb11a853801e82234b8a1a64f0df52d9e52 > # status: waiting for good commit(s), bad commit known > # good: [44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9] tcp: improve > credential handling in syncache > git bisect good 44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9 > # good: [b0c7eaf83d21bbc333e247ab9e136965b3ca54ed] bhyve/slirp: Drop > privileges before entering capability mode > git bisect good b0c7eaf83d21bbc333e247ab9e136965b3ca54ed > # good: [6a75e3951506c12b42428a47710d07cadcdd723e] ofed/libibverbs: > remove strdupa() hack from config.h > git bisect good 6a75e3951506c12b42428a47710d07cadcdd723e > # bad: [1fad49baf390cb52f238e6c352d0bc0893c008c3] sdhci: Try to = complete > the last transaction if dumping > git bisect bad 1fad49baf390cb52f238e6c352d0bc0893c008c3 > # good: [9d9974457ce8c6cf9023884ab457d4712dcc237f] bhyvectl: fix build > without BHYVE_SNAPSHOT > git bisect good 9d9974457ce8c6cf9023884ab457d4712dcc237f > # bad: [52395203f9ac40d321ed55d93e9887300261d3bf] MFV: Import = blocklist > 2025-12-15 (8a4b011) > git bisect bad 52395203f9ac40d321ed55d93e9887300261d3bf > # good: [c112ad75605ccdfcb8bbce2f57b0e7a077f057f8] options: describe > WITH_IPFILTER_IPFS > git bisect good c112ad75605ccdfcb8bbce2f57b0e7a077f057f8 > # good: [8774a990ee4094f16d596d4b78e0f3239e5d0c88] bpf: modularize > ifnet(9) part of bpf > git bisect good 8774a990ee4094f16d596d4b78e0f3239e5d0c88 > # bad: [1615eff94cda8619561b73186ec8098cc8b14c5c] usb: don't create > ifnet(9) for usbus devices > git bisect bad 1615eff94cda8619561b73186ec8098cc8b14c5c > # good: [ddf4f9eda9c295082f17e7f26963666b72c97bb9] ipfw: create = "ipfw0" > and "ipfwlog0" bpf tapping points without ifnet(9) > git bisect good ddf4f9eda9c295082f17e7f26963666b72c97bb9 > # bad: [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw: create a bpf = tap > point for every log rule > git bisect bad 3daae1ac1d82ecdcd855101bab5206e914b12350 > # good: [1c5021f5251b231b614ad9cd175bcb4250495c12] ifconfig: print > warning and return success on ipfw0, ipfwlog0 cloning > git bisect good 1c5021f5251b231b614ad9cd175bcb4250495c12 > # first bad commit: [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw: > create a bpf tap point for every log rule >=20 > = https://codeberg.org/FreeBSD/freebsd-src/commit/3daae1ac1d82ecdcd855101bab= 5206e914b12350 > ipfw: create a bpf tap point for every log rule >=20 > Dynamically allocate bpf tap points for every rule that has "log". > The name is "ipfw%u", where %u is substituted to the rule number. > The default catch all "ipfw0" tap still exists for compatibility > and it will catch packets in case if there are no bpf listeners > on a per-rule tap. >=20 > Reviewed by: ae > Differential Revision: https://reviews.freebsd.org/D53877 --Apple-Mail=_5E4599F8-0D63-4CF7-B601-AEEBB1F7037A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 28, 2025, at 3:36=E2=80=AFAM, Alastair Hogge = <agh@riseup.net> = wrote:

...sending from the right = account this time... (Mail clients break becausse they only see the = list-address in the To: header so don't use the right = role).

Removing my final "log" rule fixes = this for me, yes.  (That probably should be sufficient for anyone = else to reproduce, I posted earlier in thread, but my final rule (before = the automatic ones at 65535) is "reset log ip from any to = any").

My panic output looks like this (there = might be slight character misses because this is text copy/pasted from a = screenshot (so the console zero font gets grabbed as =C3=98) I don't = have good knowledge of how to drive the kernel debugger. Feel free to = email me privately on-list if you can tell me a = command 

I didn't want to reopen the other = bug, but it might belong = there.

-Dan 

panic: Assertion tap !=3D NULL failed = at /usr/src/sys/netpfil/ipfw/ip_fw_bpf.c:127

cpuid =3D 9

tie =3D 1766922462

KDB: stack backtrace:

db_trace_self_wrapper() at = db_trace_self_wrapper+@x2b/frame =C3=98xfffffe0123=C3=98a35c=C3=98

vpanic() at vpanic+0x136/frame = =C3=98xfffffe01230a36f0

panic() at = panic+0x43/frame =C3=98xfffffe01230a3750

ipfw_bpf_tap() at = ipfw_bpf_tap+@x104/frame =C3=98xfffffe01230a3760

ipfw_chk() at ipfw_chk+@x1e37/frame = =C3=98xfffffe01230a3990

ipfw_check_packet() at ipfw_check_packet+@xf6/frame

0xfffffe01230a3a80

pfil_mbuf_in() at = pfil_mbuf_in+@x58/frame @xfffffe01230a3ab0

ip input ) at ip_input+@x3f9/frame = Bxfffffe01230a3b10

netisr_dispatch_src() at netisr_dispatch_src+@xb4/frame = =C3=98xfffffe=C3=98123=C3=98a3b7=C3=98

ether_demux() at = ether_demux+0x16a/frame =C3=98xfffffe01230a3ba=C3=98

ether_nh_input() at = ether_nh_input+@x3ce/frame =C3=98xfffffe01230a3bf0

_src+0xb4/frame

netisr_dispatch_src() at = netisr_dispatch_src+=C3=98xb4/frame =C3=98xfffffe0123=C3=98a3c50

ether_input () at = ether_input+@xd5/frame @xfffffe01230a3cb0

tcp_lro_flush_all() at = top_lro_flush_all+@xdc/frame =C3=98xfffffe01230a3d00

iflib_rxeof() at = iflib_rxeof+@xbef/frame =C3=98xfffffe01230a3e00

_task_in_rx() at _task

_fn_rx+@x7a/frame = =C3=98xfffffe01230a3e40

gtaskqueue_run_locked() at gtaskqueue_run_locked+0x18e/frame = =C3=98xfffffe01230a3ec0

gtaskqueue_thread_loop() at gtaskqueue_thread_loop+@xd3/frame = @xfffffe01230a3ef0

_1oop+@xd3/frame

fork_exit() = at fork_exit+0x82/frame =C3=98xfffffe01230a3f30

fork_trampoline() at = fork_trampoline+@xe/frame = Bxfffffe01230a3f30


But I don't actually get = a kernel dump.

lb> bt

Tracing pid 8 tid 100032 td = Bxfffff80004725000

kdb_enter() = at kdb_enter+=C3=98x33/frame =C3=98xfffffe=C3=98123=C3=98a36f0

panic() at panic+0x43/frame = =C3=98xfffffe01230a3750

ipfw_bpf_tap() at ipfw_bpf_tap+@x184/frame = =C3=98xfffffe=C3=98123=C3=98a3760

ipfw_chk() at ipfw_chk+@x1e37/frame = =C3=98xfffffe01230a3990

ipfw_check_packet() at ipfw_check_packet+=C3=98xf6/frame = =C3=98xfffffe=C3=98123=C3=98a3a8=C3=98

pfil_mbuf

_in() at pfil_mbuf_in+@x58/frame = BxfffffeB1230a3ab0

ip_input() = at ip_input+@x3f9/frame =C3=98xfffffe01230a3b10

netisr_dispatch_src() at = netisr_dispatch_src+@xb4/frame =C3=98xfffffe01230a3b70

ether_demux() at = ether_de=D0=BCux+@x16a/frame Bxfffffe01230a3ba=C3=B8

ether_nh_input() at = ether_nh_input+=C3=98x3ce/frame Bxfffffe01230a3bf8

netisr_dispatch_src() at netisr

_dispatch_src+@xb4/fra=D0=BCe = =C3=98xfffffe0123=C3=98a3c5=C3=98

ether_input() at = ether_input+0xd5/frame Bxfffffe0123=C3=98a3cb=C3=98

top_lro_flush_alll) at

top_lro_flush_all+@xdc/frame = @xfffffe01230a3dB0

iflib_rxeof() at iflib_rxeof+@xbef/frame = =C3=98xfffffe01230a3eB8

_task_fn_rx() at _task_fn_rx+@x7a/frame = =C3=98xfffffe0123=C3=98a3e40

gtaskqueue_run_locked() at gtaskqueue_run_locked+@x18e/frame = =C3=98xfffffe01230a3ec=C3=98

gtaskqueue_thread_loop() at gtaskqueue_thread

_1oop+=C3=98xd3/frame = =C3=98xfffffe0123=C3=98a3efE

fork_exit() = at fork_exit+0x82/fra=D0=BCe =C3=98xfffffe0123=C3=98a3f30

fork_trampoline() at = fork_trampoline+@xe/frame Bxfffffe0123=C3=98a3f30





On = 2025-12-26 17:32, A FreeBSD User wrote:
Am = Tage des Herren Thu, 25 Dec 2025 19:08:36 +0100
FreeBSD User = <freebsd@walstatt-de.de> schrieb:

On Thu, 25 Dec 2025 18:30:45 +0100 (CET)
Ronald Klop = <ronald-lists@klop.ws> wrote:

Do = you use bpf or tap in your ipfw rules?
A panic with that was = mentioned on the 20th. And fixed in the mean time of I
remember = correctly. = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291854
Regards,Rona= ld  

Indeed, all boxes in question do have a = tap0 at least defined -but in only one
case used.

Kind = regards,

oh



Van: FreeBSD = User <freebsd@walstatt-de.de>
Datum: 25 december 2025 = 17:09
Aan: FreeBSD CURRENT = <freebsd-current@freebsd.org>
Onderwerp: CURRENT: kernel panic = in IPFW while stopping jails



Hello,

on recent CURRENT ipfw (in my case = compiled into kernel) either restarting
"ipfw" via "service ipfw = restart" or restarting jails using also ipfw on a
host also using = ipfw (jail-hoster also ipfw compiled into kernel) causes a
fatal = kernel crash.

This issue is present since last week an wreak = havok to several boxes with
OS installed on UFS/FFS SSDs. In one case = I have only pictures/screenshots
made via smartphone - while = crashing, kernel debugger input pops up on
console, but I'm able to = typein something within the first seconds and this
is mostly "reboot" = but gets stuck with "re" in most cases. "bt" freezes
system = immediately.

At least I can reproduce this misbehaviour on all = recent CURRENT were IPFW
is compiled into kernel. Anybody else havong = this trouble?

Kind regards,

Oliver

Merry Christmas = to everyone.

-- 

A FreeBSD = user








tap0 disabled/deleted. Same issue on every box.

$ git bisect log
git bisect start
# status: waiting for both good and bad = commits
# bad: = [086bedb11a853801e82234b8a1a64f0df52d9e52] tools.build: also = add
sys/_visible.h to SYSINCS
git bisect bad = 086bedb11a853801e82234b8a1a64f0df52d9e52
# status: waiting for good commit(s), bad = commit known
# good: = [44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9] tcp: improve
credential handling in syncache
git bisect good = 44cb1e857f048d2326bdc1a032ccd2c04d2bcdc9
# good: = [b0c7eaf83d21bbc333e247ab9e136965b3ca54ed] bhyve/slirp: Drop
privileges before entering capability = mode
git bisect good = b0c7eaf83d21bbc333e247ab9e136965b3ca54ed
# good: = [6a75e3951506c12b42428a47710d07cadcdd723e] ofed/libibverbs:
remove strdupa() hack from = config.h
git bisect good = 6a75e3951506c12b42428a47710d07cadcdd723e
# bad: = [1fad49baf390cb52f238e6c352d0bc0893c008c3] sdhci: Try to = complete
the last transaction if dumping
git bisect bad = 1fad49baf390cb52f238e6c352d0bc0893c008c3
# good: = [9d9974457ce8c6cf9023884ab457d4712dcc237f] bhyvectl: fix build
without BHYVE_SNAPSHOT
git bisect good = 9d9974457ce8c6cf9023884ab457d4712dcc237f
# bad: = [52395203f9ac40d321ed55d93e9887300261d3bf] MFV: Import = blocklist
2025-12-15 (8a4b011)
git bisect bad = 52395203f9ac40d321ed55d93e9887300261d3bf
# good: = [c112ad75605ccdfcb8bbce2f57b0e7a077f057f8] options: describe
WITH_IPFILTER_IPFS
git bisect good = c112ad75605ccdfcb8bbce2f57b0e7a077f057f8
# good: = [8774a990ee4094f16d596d4b78e0f3239e5d0c88] bpf: modularize
ifnet(9) part of bpf
git bisect good = 8774a990ee4094f16d596d4b78e0f3239e5d0c88
# bad: = [1615eff94cda8619561b73186ec8098cc8b14c5c] usb: don't create
ifnet(9) for usbus devices
git bisect bad = 1615eff94cda8619561b73186ec8098cc8b14c5c
# good: = [ddf4f9eda9c295082f17e7f26963666b72c97bb9] ipfw: create = "ipfw0"
and "ipfwlog0" bpf tapping points without = ifnet(9)
git bisect good = ddf4f9eda9c295082f17e7f26963666b72c97bb9
# bad: = [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw: create a bpf = tap
point for every log rule
git bisect bad = 3daae1ac1d82ecdcd855101bab5206e914b12350
# good: = [1c5021f5251b231b614ad9cd175bcb4250495c12] ifconfig: print
warning and return success on ipfw0, = ipfwlog0 cloning
git bisect good = 1c5021f5251b231b614ad9cd175bcb4250495c12
# first bad commit: = [3daae1ac1d82ecdcd855101bab5206e914b12350] ipfw:
create a bpf tap point for every log = rule

https://codeberg.org/FreeBSD/freebsd-src/commit/3daae1ac1d82ecdcd855= 101bab5206e914b12350
ipfw: create a bpf tap point for every log = rule

Dynamically allocate bpf tap points for = every rule that has "log".
The name is "ipfw%u", where %u is = substituted to the rule number.
The default catch all "ipfw0" tap still = exists for compatibility
and it will catch packets in case if there = are no bpf listeners
on a per-rule tap.

Reviewed by: = = ae
Differential Revision: = https://reviews.freebsd.org/D53877

<= /body>= --Apple-Mail=_5E4599F8-0D63-4CF7-B601-AEEBB1F7037A-- From nobody Sun Dec 28 16:06:11 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 4dfPNl3k9Cz6Lyw0 for ; Sun, 28 Dec 2025 16:06:31 +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 4dfPNj2BSQz3Lby for ; Sun, 28 Dec 2025 16:06:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AKguDBuJ; 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=1766937985; bh=EicLZEA/Xj6wqUC7MEi436E0SOevhR3qkNhrKw38T8I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AKguDBuJRhF7Rzv84US+1rIHQl887fgtLLp6Rt7+T2hloyGz1WbwEj50dzfuvJiMkktKE2URl/TAi601th3j1U5H0B44FZPWRBCWllV0KZGKx5/H4LktWbeg/e+RrunoKFBZPPxMdUqTV0VcTjnqB3wDRKum72FT4bwEDopfksacLwUh957J0ye1ZvxAjR8ZTZuuXLI/y7V58SIwOcOOpzySwFxKUKDpa9iG3bNZsb+x7pWD+o8pXH1rgqW+KuZXiuDW5CFsGbU9msBMc4jZ9dFvGNT5d5Hpdntq7yVq1A7rE4CJt9OkQev7V6yLiPUlxCbGDyk6b3mZS42orT2plA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766937985; bh=gZMR5IfNi4udwwn+FaplGNsBS2k0cALZQcYid4yezw9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Eb+8GGNheFnqBixuKUbFXy5R8GkrbCVEqpDPhMUtyy277uvQkzi63vxWuQY2i1/6PdHSk7hWOoct34/dDXFQKcpCGRmv+0ON21vVN+PKTdPolmtzB9dTUb1W6Nu3+urwJwOXkISjvgGO/V02SD5wt6JpowNoC2NeB/1zkH/8mRH2qv9yLuspLMecgapmOpZvv1YPQKzJHwFOinO0bzZJ9sAKsyk16qd2yc3mF3XY+68jSFZ6jYRadRdJKFoI0rcOpIWLb8Y7xmpPEm4pqQZduNQ/jwSpD2JDo157ao8t/D845HA9RdGyYr1puKL0i9hEH5a/anJwM2qnmsG1lbBoYw== X-YMail-OSG: sJSJQogVM1lZ.Muv7DKyWNkxHgeG.Qg6Nt9CneGXtoRpqe9ZD2DLoScSk8EIHKN BggDlrteDzt7ExEG.quhxWHJ6UyCmRBHzEhHCERltPo3mHCVj7zIJMggo06511yQ0z3v2zJWL7iQ 5Jhn_UCjYDXNJbrh75.CLb9vNFVucbTqyiZGb40fNBjKCRPvNBix4p4FN.wcfKDfbmUZ1yWKoC6. mcfTmykJDRfi_lpxHFiu8ayGSTkg9qiFxyjxCyrUEtj_uh8uw7ydFFGO8cZ0NAUxYBpwZGJBlPej IMkeUbRjFf0o8BvOrOfOFc1kRRCZDWKq9S7tFpEDF1o2CiJHoJmTGGf636pmRt1B2ZvYx6W1iRuc _pV12HeWzaK8yc6gnEKoDirY0A0JoAA_Q50F1.L4rBXcPDbRb5QlzzXqv8YBu0gmnRKnnjg9VMQi kYSiClgejgcrh2_weyK8CLeCZMwPi1gZ8U19BYPhfzsNOEkh7xL7k9m3ehiTASqipFXVkH1VIF70 PCouuZUpw0yuhdZH.CTZbhLlbdriI2j18sMosrRzKbNfTgguI_XpIlmRdBb4CjX7G.G507MdRhbb rFNEckZlas9_P6yeYEzNk9b235opFyCvSDL1yEQbDoSUrMSWCgKkYFfjG8pg6wWQ5PN2NpdX1NZr 7mNL.adXtdapvceVeIYm5v0J9wAaMucm3YpoYbc6aLM9oeIX5rlPpwSZMsmu.RDLhGKHp28BCLgM TByglwUP3mM5FE54VISxWCfmM0xxc5kO2m0M8NfskGrboMeNHuBbkEkSSbN6PV3TUSwQ4q8ebXRT kWXJ7NNBTkW2iE8CPngVfvI.FyLYTb.uDxAw9JR1jdvHYU9at7vk3vA1xdoXFrUcrwwT6V7QpFax swcL3xOcpl1mK65BjBYsjxwU0JpvIy3tjOo1bRmHajVASKB70lOrpVVr_J7WXniqxdvjcV1l9Khh Ou.mZ_oe3f0aGQB4Rlk3YK7v3h.V2nDCUaEGhdQAB8Aav4p0E_xSMBkYUroQSQ0aD5OXBmK5A0db v.3kAO.ZZQMmJryYIwTy_xrmPOL9DmftR_GZQNkuM1PviqY5Pw9eMfaz9HxH2a6wWx3BWjPK646N mhs0NRa8W4.SGyYW3Wav4PRByjcs8a6TtaN66_dBL._8xyp875tJY95ee3DwLF0_GuKL4Nh1smd8 2YdVEaO26lMTSBl6kI5Egxrnwh89CFZQu3hjwFOJyaeSEmq05snGLTMgn9WtpGdkDAh4.xpIaL1n m0PSc_d9UgV7MnAAJT_CEqOXrU5eXmaOHb4dJgFvQMLTn9R2FhbRNgIkVDVYVVwndyk2NoNyNkr8 HzsgyL1CzDnmiB9Yn8ghE6gnLE6tkT9QS6RoUqkwK_Fr68UFDIbdMPe22lsSjpt3EEsq7K47bWAa 1f3NdW2SDsl7jdmuqMlYum3QElegp662adqfTS3FwmiLTMioe2scNLeSIVw7JX_0x__p5IhdQk_6 jlRIcwFpxSpdCy863WRAwHkvjAnguTnBfKQhUmDdU5FbM.jBKyXUewU.uk.nYEh2KSM6JGV8_Sac ZgbWnRTxnbTjZcjLSnpPTsMs30T6B74hImlp89LGlsv3bGcAvEo2jUSkkhRxOQI5xz8RJ.Z_gDj0 M1fOiRTGxUJzbrvGGWsh6DtGu9856i1D1kWsMqfvwiCD4d2R9lWhmg6poox2TAs5C_eOuEeviVhp v9xnks.YpZz08x6CEF5VKXFelJ3GOpVnas0Sfob8v2XL74XvMEHcif0WSE3q8WKPetP1PSllCHnr BV42jcLvoRqtxH3zdJq3qHSz3UgFWsuWbDwXJdswYGIamopKMngxKaSKtwOsNE.rziIzXjaDDE0e 4ItoTB7_SarRaSXIZ..4PaBrZpj3mWSBQ2sL8KZkzFlDI8koHFbOD9vzwqgYNnIJ9MMqAO48Kr9r XShPwFue67G5vNoSD2GECRAwnwI0KnpSEmQIcrg7OzeXsEJPYanmaMeIDa53Cdkc6SLnMnN_zh6C 2k0JI4.TP2gXsn..e7BUfFF1xPD2b8RbPPTMi.phQc.KxumO4SswqaNr.jdEhrmTBA67VEsL37Oh HTfrVFzzNbDvt9oxbCvYzWTCsJperXU4JGqLhwWLnLMqlrV3PZSV4CZKKFTOTzy4RRHA64Cyu.xw 2ECeR3xN6wLiLi6eA57Dl4XDEiQaTyUQsJU0YunSYvy5J3uxxRQS1rSnKhIusiLqqY2kg5bGVOol IEJEg61xEmKswCuAk2DjuAoybzTJnHcfU9Ht5F2Gteg5YVHxjIbyPM9NYU_AIHHS0Ewm8ZjUFSCH H5cCd_4lnquwp6lg- X-Sonic-MF: X-Sonic-ID: 731c1b30-2ace-4f74-92eb-dd4406714ed2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 16:06:25 +0000 Received: by hermes--production-gq1-54bf57fc64-s8ptv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 82dfc0869d5fb4ea74df1b703e825e47; Sun, 28 Dec 2025 16:06:22 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) From: Mark Millard In-Reply-To: <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> Date: Sun, 28 Dec 2025 08:06:11 -0800 Cc: "js@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> To: freebsd-arm , FreeBSD Current , Konstantin Belousov X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.97)[-0.970]; 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)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; 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: 4dfPNj2BSQz3Lby [minherit(0x2051e000,1100,INHERIT_ZERO) =3D 0 (0x0) might be involoved?] On Dec 28, 2025, at 00:23, Mark Millard wrote: > On Dec 27, 2025, at 23:55, Mark Millard wrote: >=20 >> [Turns out: works on aarch64 kernel's armv7 support, fails >> on the armv7 native kernel, exact same world files on the >> exact same media.] >=20 > I got that wrong: a large part of the output occurs before a > segmentation fault on the Windows Dev Kit 2023. But it has a > very different backtrace and the output before that has numerical > garbage values showing. >=20 >>=20 >> On Dec 27, 2025, at 23:35, Mark Millard wrote: >>=20 >>> On Dec 27, 2025, at 22:03, Mark Millard wrote: >>>=20 >>>> Context: >>>>=20 >>>> # uname -apKU >>>> FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >>>>=20 >>>> That is an official pkgbase distribution that I installed, not >>>> a personal build. pkgbase for main has world being a debug >>>> build, no matter which of the kernels one choses to boot. >>>> For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel >>>> but might not be exact for the world: /usr/src/sys/ and >>>> /usr/src/ (without sys/) are from different times, last I >>>> knew anyway. Changes can happen between. >>>>=20 >>>> During boot, the time on the Orange Pi Plus 2ed is bad so: >>>>=20 >>>> # ls -lodT /gpart.core=20 >>>> -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 = /gpart.core >>>>=20 >>>> Also, for pkgbase, a source file distributed can be newer >>>> for its time stamp than the program distributed that was >>>> based on the source file. Such happens below. >>>>=20 >>>>=20 >>>>=20 >>>> Core was generated by `gpart show'. >>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>> Address not mapped to object. >>>> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >>>> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>>=20 >>>> warning: Source file is more recent than executable. >>>> 2715 if (*cp =3D=3D '\0') >>>> (gdb) bt >>>> #0 xo_format_string_direct (xop=3Dxop@entry=3D0x2009b120, = xbp=3Dxbp@entry=3D0x2009b150, flags=3Dflags@entry=3D4096, wcp=3D0x0, = cp=3D0x6e480000 , = len=3D-1, max=3D-1,=20 >>>> need_enc=3D3, have_enc=3D2) at = /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, = xbp=3D0x2009b150, flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>> #2 xo_do_format_field (xop=3D, = xop@entry=3D0x2009b120, xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0x20130635 = "%s", flen=3Dflen@entry=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3503 >>>> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0,= value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, = flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >>>> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >>>> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at /usr/src/lib/geom/part/geom_part.c:793 >>>> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >>>> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >>>> (gdb) list >>>> 2710 for (;;) { >>>> 2711 if (len =3D=3D 0) >>>> 2712 break; >>>> 2713=20 >>>> 2714 if (cp) { >>>> 2715 if (*cp =3D=3D '\0') >>>> 2716 break; >>>> 2717 if ((flags & XFF_UNESCAPE) && (*cp =3D=3D '\\' || *cp =3D=3D = '%')) { >>>> 2718 cp +=3D 1; >>>> 2719 len -=3D 1; >>>> (gdb) up >>>> #1 0x20150908 in xo_format_string (xop=3D0x2009b120, = xbp=3D0x2009b150, flags=3D4096, xfp=3D0xbfbfd280) at = /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >>>> (gdb) list >>>> 2977=20 >>>> 2978 return rc; >>>> 2979 } >>>> 2980 } >>>> 2981=20 >>>> 2982 cols =3D xo_format_string_direct(xop, xbp, flags, wcp, cp, = len, >>>> 2983 xfp->xf_width[XF_WIDTH_MAX], >>>> 2984 need_enc, xfp->xf_enc); >>>> 2985 if (cols < 0) >>>> 2986 goto bail; >>>> (gdb) list >>>> 3498=20 >>>> 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? XF_ENC_UTF8 >>>> 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? XF_ENC_WIDE >>>> 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; >>>> 3502=20 >>>> 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); >>>> 3504=20 >>>> 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) >>>> 3506 rc =3D xo_trim_ws(xbp, rc); >>>> 3507=20 >>>> (gdb) up >>>> #3 0x2014c69c in xo_simple_field (xop=3D0x2009b120, encode_only=3D0,= value=3D0x0, vlen=3D0, fmt=3D0x20130635 "%s", flen=3D2, = flags=3D) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>> (gdb) list >>>> 3812 { >>>> 3813 if (encode_only) >>>> 3814 flags |=3D XFF_NO_OUTPUT; >>>> 3815=20 >>>> 3816 if (vlen =3D=3D 0) >>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>> 3818 else if (!encode_only) >>>> 3819 xo_data_append_content(xop, value, vlen, flags); >>>> 3820 } >>>> 3821=20 >>>> (gdb) up >>>> #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3D, name@entry=3D0x204bf931 "state}\n", = nlen=3D, nlen@entry=3D5, value=3D0x0, vlen=3D0, = fmt=3D0x20130635 "%s",=20 >>>> flen=3D2, encoding=3D0x0, elen=3D0, flags=3D) at = /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>> (gdb) list >>>> 4368=20 >>>> 4369 save.xhs_offset =3D xbp->xb_curp - xbp->xb_bufp; >>>> 4370 save.xhs_columns =3D xop->xo_columns; >>>> 4371 save.xhs_anchor_columns =3D xop->xo_anchor_columns; >>>> 4372=20 >>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>> 4374=20 >>>> 4375 if (flags & XFF_HUMANIZE) >>>> 4376 xo_format_humanize(xop, xbp, &save, flags); >>>> 4377 break; >>>> (gdb) up >>>> #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd7e8, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>> (gdb) list >>>> 6367 flags &=3D ~XFF_WS; /* Prevent later handling of this flag */ >>>> 6368 } >>>> 6369 } >>>> 6370=20 >>>> 6371 if (ftype =3D=3D 'V') >>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>> 6373 xfip->xfi_format, xfip->xfi_flen, >>>> 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); >>>> 6375 else if (ftype =3D=3D '[') >>>> 6376 xo_anchor_start(xop, xfip, content, clen); >>>> (gdb) up >>>> #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>> (gdb) list >>>> 6546 /* Retain the info */ >>>> 6547 xo_retain_add(fmt, fields, max_fields); >>>> 6548 } >>>> 6549 } >>>> 6550=20 >>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>> 6552 } >>>> 6553=20 >>>> 6554 /* >>>> 6555 * Rebuild a format string in a gettext-friendly format. This = function >>>> (gdb) up >>>> #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>> 6622 rc =3D xo_do_emit(xop, 0, fmt); >>>> (gdb) list >>>> 6617 { >>>> 6618 xo_handle_t *xop =3D xo_default(NULL); >>>> 6619 ssize_t rc; >>>> 6620=20 >>>> 6621 va_start(xop->xo_vap, fmt); >>>> 6622 rc =3D xo_do_emit(xop, 0, fmt); >>>> 6623 va_end(xop->xo_vap); >>>> 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); >>>> 6625=20 >>>> 6626 return rc; >>>> (gdb) up >>>> #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 >>>> warning: Source file is more recent than executable. >>>> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >>>> (gdb) list >>>> 649 } >>>> 650 wname =3D wmax; >>>> 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; >>>> 652 secsz =3D pp->lg_sectorsize; >>>> 653 xo_open_instance("part"); >>>> 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} = {:scheme} ({h:size/%ld}){t:state}\n", >>>> 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + = 1), >>>> 656 wname, gp->lg_name, >>>> 657 scheme, pp->lg_mediasize, >>>> 658 s ? " [CORRUPT]": ""); >>>> (gdb) up >>>> #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at /usr/src/lib/geom/part/geom_part.c:793 >>>> 793 gpart_show_geom(gp, element, show_providers); >>>> (gdb) list >>>> 788 else >>>> 789 errx(EXIT_FAILURE, "No such geom: %s.", name); >>>> 790 } >>>> 791 } else { >>>> 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { >>>> 793 gpart_show_geom(gp, element, show_providers); >>>> 794 } >>>> 795 } >>>> 796 xo_close_list(name); >>>> 797 geom_deletetree(&mesh); >>>> (gdb) up >>>> #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 >>>> warning: Source file is more recent than executable. >>>> 497 cmd->gc_func(req, flags); >>>> (gdb) list >>>> 492 buf[0] =3D '\0'; >>>> 493 if (cmd->gc_func !=3D NULL) { >>>> 494 unsigned flags; >>>> 495=20 >>>> 496 flags =3D set_flags(cmd); >>>> 497 cmd->gc_func(req, flags); >>>> 498 errstr =3D req->error; >>>> 499 } else { >>>> 500 gctl_add_param(req, "output", sizeof(buf), buf, >>>> 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); >>>> (gdb) up >>>> #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed90) at = /usr/src/sbin/geom/core/geom.c:861 >>>> 861 run_command(argc, argv); >>>> (gdb) list >>>> 856 show_tree(); >>>> 857 return (0); >>>> 858 } >>>> 859=20 >>>> 860 get_class(&argc, &argv); >>>> 861 run_command(argc, argv); >>>> 862 /* NOTREACHED */ >>>> 863=20 >>>> 864 exit(EXIT_FAILURE); >>>> 865 } >>>>=20 >>>>=20 >>>> For reference: >>>>=20 >>>> # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c = /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c = /sbin/gpart >>>> -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart >>>> -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 = /usr/src/contrib/libxo/libxo/libxo.c >>>> -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 = /usr/src/lib/geom/part/geom_part.c >>>> -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 = /usr/src/sbin/geom/core/geom.c >>>>=20 >>>> That explains the "warning: Source file is more recent than = executable" >>>> messages. >>>=20 >>> Additional context notes: >>>=20 >>> ) On the Cortex-A7 SUT the above is repeatable at the >>> shell prompt when logged in: just try "gpart show", >>> including via gdb use. "/rescue/gpart show" also >>> core dumps. >>>=20 >>> ) In a armv7 chroot on a aarch64 system (the Windows >>> Dev Kit 2023), the "gpart show" works just fine. >>>=20 >>> But the vintages could well be a little different. >>> (Tracing to git commits for pkgbase is problematical.) >>>=20 >>>=20 >>> I'll note: >>>=20 >>> Johan S=C3=B6llvander >>> Date: Thu, 18 Dec 2025 15:23:29 UTC=20 >>> The branch main has been updated by js: >>>=20 >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D4f809ffec69cd6ede3e7be9a5bc876b2= e5931028 >>>=20 >>> commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >>> Author: Johan S=C3=B6llvander >>> AuthorDate: 2025-12-18 15:06:09 +0000 >>> Commit: Johan S=C3=B6llvander >>> CommitDate: 2025-12-18 15:22:59 +0000 >>>=20 >>> gpart: add libxo support for "show" subcommand + man page updates >>>=20 >>> Added libxo support to `gpart show`, also updated the man >>> pages for geom and gpart to show where you can expect >>> libxo formatted output. >>>=20 >>> PR: 290629 >>> MFC after: 1 week >>> Sponsored by: ConnectWise >>> Reviewed by: asomers, mckusick, phil >>> Approved by: asomers (mentor) >>> Differential Revision: https://reviews.freebsd.org/D53950 >>> --- >>> . . . >>>=20 >>>=20 >>> Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone >>> would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. >>=20 >>=20 >> I shut down the OPi+2e and mounted the boot media >> on the Windows Dev Kit 2023 and then did a chroot >> into that boot media and tried "gpart show": >>=20 >> "gpart show" worked just fine. >>=20 >> What matters is which kernel it runs on for the >> exact same world files on the exact same media. >>=20 >=20 > I got that wrong: a large part of the output occurs before > a segmentation fault on the Windows Dev Kit 2023. But it has a > very different backtrace. Also, note all the "517M" that make no > sense --and the "0" and "2" junk as well: >=20 > # gpart show=20 > =3D> 34 1000215149 nda0 GPT (2)(null) > 34 2014 - free - (2) > 2048 532480 1 efi (517M) > 534528 32768 2 ms-reserved (517M) > 567296 997287936 3 ms-basic-data (517M) > 997855232 2359296 4 ms-recovery (517M) > 1000214528 655 - free - (2) >=20 > =3D> 34 2930277101 da0 GPT (0)(null) > 34 32734 - free - (0) > 32768 501760 1 efi (517M) > 534528 20971520 2 freebsd-swap (517M) > 21506048 29360128 3 freebsd-swap (517M) > 50866176 33554432 4 freebsd-swap (517M) > 84420608 67108864 5 freebsd-swap (517M) > 151529472 96468992 6 freebsd-swap (517M) > 247998464 268435456 7 freebsd-swap (517M) > 516433920 7340032 8 freebsd-swap (517M) > 523773952 13096960 - free - (0) > 536870912 2357198848 9 freebsd-ufs (517M) > 2894069760 36207375 - free - (0) >=20 > =3D> 40 1953525088 da1 GPT (0)(null) > 40 532480 1 efi (517M) > 532520 2008 - free - (0) > 534528 3563520 2 freebsd-swap (517M) > 4098048 6504448 - free - (0) > 10602496 1740636160 4 freebsd-ufs (517M) > 1751238656 7546880 3 freebsd-swap (517M) > 1758785536 194739592 - free - (0) >=20 > Segmentation fault (core dumped) >=20 > As for gdb's backtrace: >=20 > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 0x200c5ef0 in delete_config (gp=3D0x2053e224) at = /usr/src/lib/libgeom/geom_xml2tree.c:502 >=20 > warning: Source file is more recent than executable. > 502 LIST_REMOVE(cf, lg_config); > (gdb) bt > #0 0x200c5ef0 in delete_config (gp=3D0x2053e224) at = /usr/src/lib/libgeom/geom_xml2tree.c:502 > #1 geom_deletetree (gmp=3Dgmp@entry=3D0xffffcb48) at = /usr/src/lib/libgeom/geom_xml2tree.c:524 > #2 0x204d2064 in gpart_show (req=3D, fl=3D) at /usr/src/lib/geom/part/geom_part.c:797 > #3 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 > #4 0x00022308 in main (argc=3D1, argv=3D0xffffdc70) at = /usr/src/sbin/geom/core/geom.c:861 >=20 >=20 > (I need to get some sleep.) Back to the Cortex-A7 context (armv7 without aatch64) for that same media . . . The tail of a truss output from a run looks like (note the "minherit(0x2051e000,1100,INHERIT_ZERO)"?): . . . modfind("g_part") =3D 190 (0xbe) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 537432064 (0x20089000) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 537452544 (0x2008e000) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 537456640 (0x2008f000) = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542076928 (0x204f7000) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542089216 (0x204fa000) = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542109696 (0x204ff000) = mmap(0x0,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542121984 (0x20502000) __sysctl("sysctl.name2oid = kern.geom.confxml",2,0xbfbfdbb8,0xbfbfdbb0,0x200b4716,17) =3D 0 (0x0) __sysctl("kern.geom.confxml",3,0x0,0xbfbfdbb4,0x0,0) =3D 0 (0x0) = mmap(0x0,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542150656 (0x20509000) __sysctl("kern.geom.confxml",3,0x20509180,0xbfbfdbb4,0x0,0) =3D 0 (0x0) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542175232 (0x2050f000) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542195712 (0x20514000) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542216192 (0x20519000) mmap(0x0,1100,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D = 542236672 (0x2051e000) minherit(0x2051e000,1100,INHERIT_ZERO) =3D 0 (0x0) getrandom("\M-,\M-;\M^P\^Rl\^VHP\M->'\M-v"...,40,0) =3D 40 (0x28) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542240768 (0x2051f000) = mmap(0x0,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542261248 (0x20524000) = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542289920 (0x2052b000) = mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542302208 (0x2052e000) = mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-= 1,0x0) =3D 542322688 (0x20533000) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 542334976 (0x20536000) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 542339072 (0x20537000) = mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1= ,0x0) =3D 542343168 (0x20538000) SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D5 addr=3D0x6e480000 process killed, signal =3D 11 (core dumped) Given recent work on anonymous zeroed pages, I note for minherit: QUOTE INHERIT_ZERO This option causes the address space in question to = be mapped as new anonymous pages, which would be initial- ized to all zero bytes, in the child process. END QUOTE Not that I've any specific evidence of it being an issue. I'll note that trying the official debug kernel did not report anything special and got the same behavior. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 16:48:15 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 4dfQKL1djrz6M364 for ; Sun, 28 Dec 2025 16:48:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4dfQKK3H9fz3R0p for ; Sun, 28 Dec 2025 16:48:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=q3Wn9s1a; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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=1766940509; bh=S/nEyE3OcTCKM5CL3sKcVTxO0PNbeYX2FMaZcftBbbQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=q3Wn9s1aRVUNxvF0qok9EjtSfBbi4zHZyvPq6oo8DgvLe5yzdb63P9Fg0mc+vWt9l8g8pBH+rLX7RSgqkZWf4ugxxOst+VaJuH3ZjTxbjpldF1X0SvYiFXy9I50qQybiWF5BdHjuwwZ5dImrtFCAyz1N3MJm02tLx0sIua2vP0BqUFWuDKkDcXVglt2XQNGCSWjIiQfo4JfgRlkBLEZBt9cx8FCF3/8yKKnT2M3YhdzR0ezvv2jpvLTa4NvvnThHZIx8ED17iFY/zpLlZ9OYx9HEluR0Ypzc97wa+dAuDJZlm/qVqvHC1kgVmP5anC/+gqAhjSmCtk2PrevgkxVd4A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766940509; bh=oyvSYP6mb6N6y24BY/B11vl3nOSpU5Kw3e6zvihR4ba=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qBSpxivdNcZ+wAj1iJpPyH3IL75EaxZ0SvZ0SpXQJwnKgy85wtTExGe3iqNOZ+HPr6cujKLWKHDPBFjQDyGtbLzz5uFttyy1M0mC0v3DFcUHmURKe9QAdvmSu/eXab/U+EEGGWMDS+rH1SnRU55RVC57NHFQuIZazOWd46l9julVu57xyK0U2AaOHvMe8HsOnxnLjZz18XvdAKrQLlReE3ZUV2gZAbKlc3e2kCgvvgcwRXGPSCJyOPCgu/Qz3GwzdrSpyJePKk73kx4aqJEQZxko6Bz0x0+mXdrtBxnvhQIOK/ISa9CYaoB4phwVjBDBPBbH0gf4V+za9BwcghdidQ== X-YMail-OSG: xiDX4REVM1lLpjyxld66uMJjyfnOW0Otpii2vYprg7wwHRw3kwXyhcDnn8tacGp QA9jVkaVdvhgDRJamCo_iPe5sI_6UwVMqEDOKiuywVnfeVBFDWggotRkdimZIihvZgOTchcScGQZ .yjddyCyb4AoMzYx_1h_EyDkoCGq7UEFKwLnnp9aOCek1Jo1dh95Hwl8NCvgL4cYXdKTv_F5k10. wGXl7MaTZ7TnFRoRMXHDnslJW05pgAc8KVkm89gjRNEouhEnAxOJJ7eUME8G8z4cp5N55ZKw2HJ2 geVTKYYjK6oqScBN49Y7srL7gTyIn0ot9a4uCHW4DYTbKZglIzMrEbUBs5sMY62v7OkD8s7YjYd. hB9Mj_uAL8Au11ZXU.uyDSJNhnhKIHSOy4ArIE5UAkP1rToos_MZeaghsy3xYvfwZnDtuytiG9nv USkjJTnlQN3Tv.bkTl4GXCd5nkn21rGcCgIwHR2C8cdr3pdoxwvB7T9IzEkow.s9nnMFjW58SdmB LOM2bbvahByXC0BnArQr2anw5kI22ZJ527GNLA29Xc5QfY5uz1NG5LTKRMgdJzltGW7vzABBC0oI o8qWtCKfax94xEu0dL5rnRyBjpBSe82y_WPeEYOqr4uu7ywYmIhQXCY6V.xB2ffts7LxM736Nygr lJyOFjgobPN1.CmUWLeJ.92Gh7eVmHP9bwsLD83b7uN8wNL2ax6KQW0LZyD5Rwidlz1VXNBFPOkv EzLboJd0_32G_v1O6UXGWQx5XWFxuNgZZFijZtZhENH2z_FT2vgZS8W_f83AXojZGja9v9bRdzpB akdRBGSPDBLagwX3BULXQXxHXY5AqM0b4iU3PgXtP0EQ7c.w0f6pFco9XNb8arLZFaWeJmaCae8m avzL2CJwtUTq42FnLwfz_u7sriFNtuc.83IbtIRkJ5OllqaVSTE9DV1BCqo9S7LIrmf5nzmWMh9S uTfeafTGpPnB0WxoUzY5j8rWFISRcA3ityZvmPqohiKsUvQF1UZsHgkxfy_LhbZ7bJl1QiooHa.q 9mY9itzKoamY81uoncyNuzjRZAKOB_wXOsa5yNT6QZQ_J9fbXr95iDN2_r4ve0VaQohNSewoUr4q xZvPZZh4KMTK04gWnUJOyNg1eY9Nk2vt94yfkLUuDBsrje3AgkLktSTfxUb3FWfn6sgYnAHzKRE5 7Sc1R_eUTVupcCc6oRtG_p1Jr9beRTgrVux.TWMxbQWpVkjHxVr0GA0zQouiRMOfQsgA2HtO4L7H C1sqaUvPFgXb80xcXetcUBqXbZ1SX3.CuYNyvLJao2dLFfHaPa1V1b8oQX0CoiaVPRl.oxZhr_xU IHHAvtqztrQp6OUtkYIsCBvqPtpx9iDXW4TQKrmo3SN2p63M_qvkLXv9LPFZMr6VSezc9S.7GwI8 bJWLEAwlPWKgQm_pvfzoh9jXUi_dIh7qbZx61YvTt1FiNrkfrjQfBOy.GJhs7pnJmGs2qUZkHvwH dLwfruxdyt8AyGJjAyQw_f6eOG.ntGazL08UwPw1f4RY.3Q9nGom6yNjO0xxeKqNsPwpHLAHXrOP 88LNfrV2rCGlLoQiH_cQmCGIhH0Or6iP_KR7Yi3zxWtw3HGStbNa27O4gfmm_gPzzyYGq2nRXKPQ SGHL02RhTUnkkeW3_SMadunEdRchxlrYmJlC6WzH3XaCO8x8Hv_59muMZUFR3W_tCcaRiHLCft8E NqpHSZ4ZJugesF0XLKzzsR8slgRyzYE59I0EEUWH9PLfXVFJV4JtLzzR0jRfmCSJzIpeHTJ1PGVA Inu85_A5ggygRDNKMRBTpUMf9HYQ1k2EHnueGE5CHum25gRwb4Wb6YNb0zEDM37U3wXcwqPIekgE GZC5UPYhv8WqbiZuRvnLicS748YVXNlBhmlXhj1qKeGnJKmwnLKokq1hLqcTHbIVEAcPKZt2dLJT QDbz4NxGfnwMNqMxnB8f_iXQbPkWo7WefiEseRgHoVHE8hAZhyKLQs1D0mNaQB62FnSBTqG0Uji2 beheSqlIw0LxbcdVrdngiBQ5lx32Fo3LZEba6rvnVZyi8VbScnWF6Np2nm8TE9YFljdGq32_dwnf sWuxDda26Zp.r8KCSurzm7iwVWn5AMtB00pT1rt4SkCmUiqylETlwMZSz4MvZi5yX1Emt.Ojr7se 32b_J0LnEpvZ2cLbq73athoZVCj4sqMQTsDvNPTMQESckRQvyClvwS723bsb6Q9UJocYvAzj7AHG lvyp3K2ygiE7Aelh61oCmiRBVKSkn0a5mXgSj61DIgL.jRNxqy0w6ACP.9_hsdtmzZU.1EG4oAyx jj3w- X-Sonic-MF: X-Sonic-ID: 08779a99-dfd4-4a47-9fb9-cbdbb4bf1a98 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 16:48:29 +0000 Received: by hermes--production-gq1-54bf57fc64-lg4js (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 251ed51ed7ed0d1eb811133cd93f9844; Sun, 28 Dec 2025 16:48:25 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) Message-Id: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> Date: Sun, 28 Dec 2025 08:48:15 -0800 To: js@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <1B16024B-5AEC-4F75-BAC5-C6936208082F.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.99)[-0.992]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; 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)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from] X-Rspamd-Queue-Id: 4dfQKK3H9fz3R0p js@freebsd.org wrote on Date: Sun, 28 Dec 2025 11:01:59 UTC : > I'll take a look at it and try to setup a reproducer, unfortunately my=20= > time is a bit limited during the holidays so I can't promise any quick=20= > fixes right now. >=20 > Could you share the output of >=20 > gpart --libxo:JP show >=20 > with me? If possible. On the Orange Pi Plus 2e (Cortex-A7, not aarch64, just armv7): # gpart --libxo:JP show Segmentation fault (core dumped) I'll note that the 0x6e480000 in r0 that is shown later below is the same failing address reported in my original list submittal about the issue. For reference: (gdb) bt #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd1f8) at = /usr/src/contrib/libxo/libxo/libxo.c:2966 #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3817 #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, = elen=3D0,=20 flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd768, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at = /usr/src/sbin/geom/core/geom.c:861 (gdb) list 41 /* So that the N bit is set. */ 42 cmp r3, #0 43 b .Ldo_2 44 =20 45 .Loop: 46 ldr r2, [r0] 47 add r0, r0, #4 48 ands r3, r2, #0x000000ff 49 it ne 50 addne r1, r1, #1 #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd1f8) at = /usr/src/contrib/libxo/libxo/libxo.c:2966 warning: Source file is more recent than executable. 2966 len =3D strlen(cp); (gdb) list 2961 && xfp->xf_width[XF_WIDTH_MIN] < 0 2962 && xfp->xf_width[XF_WIDTH_SIZE] < 0 2963 && xfp->xf_width[XF_WIDTH_MAX] < 0 2964 && !(XOIF_ISSET(xop, XOIF_ANCHOR) 2965 || XOF_ISSET(xop, XOF_COLUMNS))) { 2966 len =3D strlen(cp); 2967 xo_buf_escape(xop, xbp, cp, len, flags); 2968 =20 2969 /* 2970 * Our caller expects xb_curp left untouched, so we have (gdb) up #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); (gdb) list 3498 =20 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? = XF_ENC_UTF8 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? = XF_ENC_WIDE 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; 3502 =20 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); 3504 =20 3505 if ((flags & XFF_TRIM_WS) && = xo_style_is_encoding(xop)) 3506 rc =3D xo_trim_ws(xbp, rc); 3507 =20 (gdb) up #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3817 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); (gdb) list 3812 { 3813 if (encode_only) 3814 flags |=3D XFF_NO_OUTPUT; 3815 =20 3816 if (vlen =3D=3D 0) 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); 3818 else if (!encode_only) 3819 xo_data_append_content(xop, value, vlen, flags); 3820 } 3821 =20 (gdb) up #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, = elen=3D0,=20 flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 4535 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); (gdb) list 4530 } 4531 =20 4532 if (quote) 4533 xo_data_append(xop, "\"", 1); 4534 =20 4535 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); 4536 =20 4537 if (quote) 4538 xo_data_append(xop, "\"", 1); 4539 break; (gdb) up #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd768, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 6372 xo_format_value(xop, content, clen, NULL, 0, (gdb) list 6367 flags &=3D ~XFF_WS; /* Prevent later handling of = this flag */ 6368 } 6369 } 6370 =20 6371 if (ftype =3D=3D 'V') 6372 xo_format_value(xop, content, clen, NULL, 0, 6373 xfip->xfi_format, xfip->xfi_flen, 6374 xfip->xfi_encoding, xfip->xfi_elen, = flags); 6375 else if (ftype =3D=3D '[') 6376 xo_anchor_start(xop, xfip, content, clen); (gdb) up #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); (gdb) list 6546 /* Retain the info */ 6547 xo_retain_add(fmt, fields, max_fields); 6548 } 6549 } 6550 =20 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); 6552 } 6553 =20 6554 /* 6555 * Rebuild a format string in a gettext-friendly format. This = function . . . (gdb) up #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 6622 rc =3D xo_do_emit(xop, 0, fmt); (gdb) list 6617 { 6618 xo_handle_t *xop =3D xo_default(NULL); 6619 ssize_t rc; 6620 =20 6621 va_start(xop->xo_vap, fmt); 6622 rc =3D xo_do_emit(xop, 0, fmt); 6623 va_end(xop->xo_vap); 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); 6625 =20 6626 return rc; (gdb) up #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 warning: Source file is more recent than executable. 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", (gdb) list 649 } 650 wname =3D wmax; 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; 652 secsz =3D pp->lg_sectorsize; 653 xo_open_instance("part"); 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", 655 wblocks, (intmax_t)first, wblocks, = (intmax_t)(last - first + 1), 656 wname, gp->lg_name, 657 scheme, pp->lg_mediasize, 658 s ? " [CORRUPT]": ""); (gdb) up #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 793 gpart_show_geom(gp, element, = show_providers); (gdb) list 788 else 789 errx(EXIT_FAILURE, "No such = geom: %s.", name); 790 } 791 } else { 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { 793 gpart_show_geom(gp, element, = show_providers); 794 } 795 } 796 xo_close_list(name); 797 geom_deletetree(&mesh); (gdb) up #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 warning: Source file is more recent than executable. 497 cmd->gc_func(req, flags); (gdb) list 492 buf[0] =3D '\0'; 493 if (cmd->gc_func !=3D NULL) { 494 unsigned flags; 495 =20 496 flags =3D set_flags(cmd); 497 cmd->gc_func(req, flags); 498 errstr =3D req->error; 499 } else { 500 gctl_add_param(req, "output", sizeof(buf), buf, 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); (gdb) up #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at = /usr/src/sbin/geom/core/geom.c:861 861 run_command(argc, argv); (gdb) list 856 show_tree(); 857 return (0); 858 } 859 =20 860 get_class(&argc, &argv); 861 run_command(argc, argv); 862 /* NOTREACHED */ 863 =20 864 exit(EXIT_FAILURE); 865 } (gdb) frame 0 #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 46 ldr r2, [r0] (gdb) info registers r0 0x6e480000 1850212352 r1 0x0 0 r2 0x80 128 r3 0x0 0 r4 0xffffffff 4294967295 r5 0x6e480000 1850212352 r6 0x0 0 r7 0x2 2 r8 0x2009b120 537506080 r9 0x1000 4096 r10 0xbfbfd269 3217019497 r11 0xbfbfd258 3217019480 r12 0x201777b0 538408880 sp 0xbfbfd190 0xbfbfd190 lr 0x20151020 538251296 pc 0x202f58c4 0x202f58c4 cpsr 0x60000010 1610612752 fpscr 0x2000000 33554432 tpidruro 0x2009b010 0x2009b010 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 16:54:40 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 4dfQSm10wyz6M3dM for ; Sun, 28 Dec 2025 16:55:04 +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 4dfQSl2WVlz3SZ7 for ; Sun, 28 Dec 2025 16:55:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Cw1Po7Gy; 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=1766940895; bh=IqWloroBhGRVKql5GXN4HlO82phXcprZLYzd30oQ3YY=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Cw1Po7GyLLb/3DF49MlrbZgviz5Tg+6QSr+Xwpvkxu9Xmq32JNyZYf3JpDbN8nhDJBxcmJXMZIv5klMC8igYCxhvudhOu9x5ZY+/aBXIjDiKj6I/nNBWPrfREQpIlGkmmoYUWjI6v+hSsE+LxF/bphPiN6rin/F0ScyLfAgsJPjaRPpyXcUEPXHpHpQtsBaayw/DeM8ye/td/L5My1fhNM6hYZpwkwB69a+26SwJ12SMCPPyl2+olJ32rfxU1hEBOiQTM3XUO9YO8CkMFBuD6kT2M+4u3BGL+Mm9EfRKgETJNZtnd8wUD3oCii9oygggVYo9OGeQHLAslG5Zq4riew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766940895; bh=khJ6B3rJ8SmsOkfuxH0fMZMnob5cRxxDww/WUoxogTQ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=r2OyfQq+R+vCHstIbSccNimZJpff0fAltJ2RLZI73gB0mrXmVuRccvQtor71YefzRM0Nf6vPvqv9u+YrNv3vTUQBJYRchX9UiyQzAZ3qQh1DY+AFmEhNa6T4FJQW+ViPUdrd06LFxV656v0miS2FsuP1dXZawFLEpJYeorTAVQ8ph8z8L2GmtcfOpCl/vcpkyKwBQdDqG+x0RDhASUomO1D2kTj1B5upkdNsqpjvCOivuWu56cAXhMoYzP1FZrywMmOj15T6bq3+s6CKv+ZAG38GYApvo7tIYoSRnJUUHMF4D7UNm8LRjn+BeIKUEK9floMIPl1eOagRarxbSyCstA== X-YMail-OSG: qXBNke4VM1mby0xhTACuXQwlLUsAPoJAnaqgQSk6NLlvDY2VCELbl9CEBji0iyK 09yfbBg_RgpSk._rBBZh4ATYoySk.pYb_zlnI3_pk.FUYcohAtO7FoH5dCybTiCvbm6TExHjl1c1 EVN9Xw0u9jUzWJFyD6vBD.Ly8O5jT05WDDbgdjbtQ4J6KrdLxjEnV_0dq15ArSpvLSm60LjW_8iZ ho6KB4Kh2JbkhqcNm5ZCBsv4AKGYs2vGb23c.QVU46yq1IwSV1L5Ld4WMqbvzm95gw30jecyjXpV gcAjYOVkdlcwp8DJ0j7gQnU7Mo0jaPbBbME9H63fyWXZnX15VWwuwYCyCcq4G5n7XA4fzJDfrRFg s0M984Ew38D7MYwE3OV2Q6eqOut6ZbVzmLpj2cmliDpAIRBffWuBOD4judyCEVRk.rtdsEQTt9SA Dry9n.nY5DepDiOesC.lJkt15gwbed9_6_LnHq7AfYwXCPdufP8.xTo8beOBHkjz29aC5_whN2pN FGGVzzLgVoDnstQJne8UHQ_9wvsHU.AwFB9zDNntlYnCFJPyghYk47S7UUDuuLx.P4yxp5DPWwD3 uEwGVQfv9EJ1hs5ltrLsvvd8_8zwx_f11UfWaAW5KSnfWSkJItMcLNBb7k8Bsw2ELzwutitM13r_ e8af0w.g56YN0Lnp71opA0ZdtnYVInnAdpmemA_2oK1DSejH7q87UFRW4Gm2t9wWFwLyBo1TUJaN khdsArtH_ViZ8fAYkbxS5lyP4xaeVoZdtfgdo0BEK4c.yYnaL7XD389VCeEMxEenf7aWaV6rBjDW fHoMlFiOo1quatxrYPZpyvXdwnSPSEgs5jwNrEEcKO7hvOVKu76AovksArxj7HT3ciNPOmG4MQRW u2HfXQ3_teGqzXyzcI37.OvVgPbgxnGPNq9zsXl.JS12OCN7gQlNiO2iMjig5BjGZXMo1DCwlbNa d5wKdnuNAgcwADSE7mUBvswqQnqyZd1zvQvUAflcXXfkq.PodehR4d2pxqng9_j9bCiX18sZhM6E fS2nSpSkasGisn9iVqnoeRGo872HfntWkzc4ci.5Baz_7EtBRwV9fktZXMSJpxGCHkhuAG4bi2Ok 5RYpersVpkL0kqcMtmgVP7IGaA2NRRUiVGd4dKW0yRJQTQidTty14H5CcrXZh_6IO60olB6nMmV0 JdMamRZJxUW_jbwtkCwtYS1vLALiGYJBPdYy7cZlgxchW.ssNUEPFaM4TuHWUUWjTTsFm3zqpux5 LdsXPBzYHgAVZ9wgyNOsdI30lCyaQ3mX6JFX.fgNb4mo0F2kCbGsG2DEEXoJSVzC4y3_8ucM9GpS GylF1GDTpT8aS20mJLP8n4hj7_5tZfhkh7BsJhLNBM0IwMiZug3oA5yRZ4xTbULLDM8kfcDs0Mid ZRY_VL5nbLsf9Hj3HWDsfdryOeHO2CbXN3bksWsDVdkEiZGWrx.W2w.uD319is4NBOS_P8EJieel DBmzc79XF0mbJc2HmRMg_RMW4Sf7s1CyRfq7XPV1u_lk6uvtu5K5P3Vi0GP31PHQuRf0wltx_z9l DO94c65gjN7kzJC8aaObrihQm6FSC8oGOzLuoGI9Wvn9L5utOtOtzTTz_rF.YNyn5pXhRZfYYwBX JtSK38rrZoUQ4AGsonImPjkcAKxu58usL5zBXmJn7aj.jSvQ_4Xin5PuW9VoPWBFWG8l6OIrnWRB 83SIY88J0LB41KmCcGKxIq7lfacl6qswAVlyVbVgeWMVSBqfxaeIlcoVS3Dtm9C_psPd.IVAaZ8n LwYAi6fZXOKdprKPmwQZqnZSk05RS2ZtEyX128mPvHqpxgfEcQ7l3xJ0fnjUudvOhPmbq461wpgU svggoSRQj9fWFLf9nkMeJ_LsvC_a18qj0KCBzRQ4pNnXlGnbe38llOIjK_S1zf3.H9lM_lp9oY8k sdTGA31d5UWmK8ha6omtqaok_dHU5eRRrRSyKarMgNKVtHpPg7rMbGQ_rYMXzVPXC22POtcgSRUa hy86uZdD37D.ZGG9_s8fYoGM42VZbbbTZw_nTLEL9ioFUE42Z4s1cA1dYIZlhdQ2EYNoHh5aGyUZ Rh4_wBuIQpmJiws49AbA7HfBqb8PI4RrMSlM7QqFULclZgAQjrkvlfGWzIv.0YDLkW1yOve9.rtL yNuM6cqhFlR0ga_94TWg21Z2ZALHKH3xqtPxklqgCH4BoRvkSxPe8EVRX0.ah_FJCKw1eYdIQJrO 8ghctibGvpOx0zazh1Jmz6g_iXReAHa8gnhH0h4uQzE0ZJzNxSAdcZ0pz6f5wvBAi8cHQv6G4F7X MEj0- X-Sonic-MF: X-Sonic-ID: 123343d7-e558-474f-9fb6-f54f8491b598 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 16:54:55 +0000 Received: by hermes--production-gq1-54bf57fc64-4glv7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f081369db19d664e6203ef5ee276ca2; Sun, 28 Dec 2025 16:54: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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) Date: Sun, 28 Dec 2025 08:54:40 -0800 References: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> To: js@freebsd.org, FreeBSD Current , freebsd-arm In-Reply-To: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; 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)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(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: 4dfQSl2WVlz3SZ7 [Resend including freebsd-arm.] On Dec 28, 2025, at 08:48, Mark Millard wrote: js@freebsd.org wrote on Date: Sun, 28 Dec 2025 11:01:59 UTC : > I'll take a look at it and try to setup a reproducer, unfortunately my=20= > time is a bit limited during the holidays so I can't promise any quick=20= > fixes right now. >=20 > Could you share the output of >=20 > gpart --libxo:JP show >=20 > with me? If possible. On the Orange Pi Plus 2e (Cortex-A7, not aarch64, just armv7): # gpart --libxo:JP show Segmentation fault (core dumped) I'll note that the 0x6e480000 in r0 that is shown later below is the same failing address reported in my original list submittal about the issue. For reference: (gdb) bt #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd1f8) at = /usr/src/contrib/libxo/libxo/libxo.c:2966 #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3817 #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, = elen=3D0,=20 flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd768, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at = /usr/src/sbin/geom/core/geom.c:861 (gdb) list 41 /* So that the N bit is set. */ 42 cmp r3, #0 43 b .Ldo_2 44 =20 45 .Loop: 46 ldr r2, [r0] 47 add r0, r0, #4 48 ands r3, r2, #0x000000ff 49 it ne 50 addne r1, r1, #1 #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd1f8) at = /usr/src/contrib/libxo/libxo/libxo.c:2966 warning: Source file is more recent than executable. 2966 len =3D strlen(cp); (gdb) list 2961 && xfp->xf_width[XF_WIDTH_MIN] < 0 2962 && xfp->xf_width[XF_WIDTH_SIZE] < 0 2963 && xfp->xf_width[XF_WIDTH_MAX] < 0 2964 && !(XOIF_ISSET(xop, XOIF_ANCHOR) 2965 || XOF_ISSET(xop, XOF_COLUMNS))) { 2966 len =3D strlen(cp); 2967 xo_buf_escape(xop, xbp, cp, len, flags); 2968 =20 2969 /* 2970 * Our caller expects xb_curp left untouched, so we have (gdb) up #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); (gdb) list 3498 =20 3499 xf.xf_enc =3D (xf.xf_fc =3D=3D 'm') ? = XF_ENC_UTF8 3500 : (xf.xf_lflag || (xf.xf_fc =3D=3D 'S')) ? = XF_ENC_WIDE 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; 3502 =20 3503 rc =3D xo_format_string(xop, xbp, flags, &xf); 3504 =20 3505 if ((flags & XFF_TRIM_WS) && = xo_style_is_encoding(xop)) 3506 rc =3D xo_trim_ws(xbp, rc); 3507 =20 (gdb) up #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3817 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); (gdb) list 3812 { 3813 if (encode_only) 3814 flags |=3D XFF_NO_OUTPUT; 3815 =20 3816 if (vlen =3D=3D 0) 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); 3818 else if (!encode_only) 3819 xo_data_append_content(xop, value, vlen, flags); 3820 } 3821 =20 (gdb) up #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, = elen=3D0,=20 flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 4535 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); (gdb) list 4530 } 4531 =20 4532 if (quote) 4533 xo_data_append(xop, "\"", 1); 4534 =20 4535 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, = flags); 4536 =20 4537 if (quote) 4538 xo_data_append(xop, "\"", 1); 4539 break; (gdb) up #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd768, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) at /usr/src/contrib/libxo/libxo/libxo.c:6372 6372 xo_format_value(xop, content, clen, NULL, 0, (gdb) list 6367 flags &=3D ~XFF_WS; /* Prevent later handling of = this flag */ 6368 } 6369 } 6370 =20 6371 if (ftype =3D=3D 'V') 6372 xo_format_value(xop, content, clen, NULL, 0, 6373 xfip->xfi_format, xfip->xfi_flen, 6374 xfip->xfi_encoding, xfip->xfi_elen, = flags); 6375 else if (ftype =3D=3D '[') 6376 xo_anchor_start(xop, xfip, content, clen); (gdb) up #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6551 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); (gdb) list 6546 /* Retain the info */ 6547 xo_retain_add(fmt, fields, max_fields); 6548 } 6549 } 6550 =20 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); 6552 } 6553 =20 6554 /* 6555 * Rebuild a format string in a gettext-friendly format. This = function . . . (gdb) up #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 6622 rc =3D xo_do_emit(xop, 0, fmt); (gdb) list 6617 { 6618 xo_handle_t *xop =3D xo_default(NULL); 6619 ssize_t rc; 6620 =20 6621 va_start(xop->xo_vap, fmt); 6622 rc =3D xo_do_emit(xop, 0, fmt); 6623 va_end(xop->xo_vap); 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); 6625 =20 6626 return rc; (gdb) up #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 warning: Source file is more recent than executable. 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", (gdb) list 649 } 650 wname =3D wmax; 651 pp =3D LIST_FIRST(&gp->lg_consumer)->lg_provider; 652 secsz =3D pp->lg_sectorsize; 653 xo_open_instance("part"); 654 xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} = {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", 655 wblocks, (intmax_t)first, wblocks, = (intmax_t)(last - first + 1), 656 wname, gp->lg_name, 657 scheme, pp->lg_mediasize, 658 s ? " [CORRUPT]": ""); (gdb) up #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) at = /usr/src/lib/geom/part/geom_part.c:793 793 gpart_show_geom(gp, element, = show_providers); (gdb) list 788 else 789 errx(EXIT_FAILURE, "No such = geom: %s.", name); 790 } 791 } else { 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { 793 gpart_show_geom(gp, element, = show_providers); 794 } 795 } 796 xo_close_list(name); 797 geom_deletetree(&mesh); (gdb) up #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 warning: Source file is more recent than executable. 497 cmd->gc_func(req, flags); (gdb) list 492 buf[0] =3D '\0'; 493 if (cmd->gc_func !=3D NULL) { 494 unsigned flags; 495 =20 496 flags =3D set_flags(cmd); 497 cmd->gc_func(req, flags); 498 errstr =3D req->error; 499 } else { 500 gctl_add_param(req, "output", sizeof(buf), buf, 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); (gdb) up #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at = /usr/src/sbin/geom/core/geom.c:861 861 run_command(argc, argv); (gdb) list 856 show_tree(); 857 return (0); 858 } 859 =20 860 get_class(&argc, &argv); 861 run_command(argc, argv); 862 /* NOTREACHED */ 863 =20 864 exit(EXIT_FAILURE); 865 } (gdb) frame 0 #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 46 ldr r2, [r0] (gdb) info registers r0 0x6e480000 1850212352 r1 0x0 0 r2 0x80 128 r3 0x0 0 r4 0xffffffff 4294967295 r5 0x6e480000 1850212352 r6 0x0 0 r7 0x2 2 r8 0x2009b120 537506080 r9 0x1000 4096 r10 0xbfbfd269 3217019497 r11 0xbfbfd258 3217019480 r12 0x201777b0 538408880 sp 0xbfbfd190 0xbfbfd190 lr 0x20151020 538251296 pc 0x202f58c4 0x202f58c4 cpsr 0x60000010 1610612752 fpscr 0x2000000 33554432 tpidruro 0x2009b010 0x2009b010 =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 17:44:54 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 4dfRYQ4zmnz6M6ss; Sun, 28 Dec 2025 17:44:10 +0000 (UTC) (envelope-from js@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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dfRYQ41zGz3cDH; Sun, 28 Dec 2025 17:44:10 +0000 (UTC) (envelope-from js@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766943850; 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=ldLsFafh5aQmhNCcMQZq44d13NL7YGK20hOCHrecsq0=; b=V7HzuXx4XFSeOr3cDjxRyEmjIzN6wD2PQNKjT9yrSx34UkZzcmDHw80CejubfvAfwxNm2L Yw2vN3lWlaQkMpfF0aC2Lo8/otxdJI/1gec92++Hy/mhfI94XMKolb7dHIRwHDEw1FEA6t +Coj0ryebAU0jdnTxERcPnKH7c7vbvA48wA6cjQyyC7P29rpL70fYhTCFoQTaBGW+R1xfl kocNuuGKsZ2b2mQtoZF9rPecApoA1AeYo29p2AvBu/KaZvKMWDG9ZdATg2VfzTSA3Bc445 p/ZbK/ZOKFC2+5gnfznE2H2Nmr8OtgH1OQnxtKP5TxA/OIr9nJpvtgHilyneLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766943850; 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=ldLsFafh5aQmhNCcMQZq44d13NL7YGK20hOCHrecsq0=; b=gXnx5+n6FJWoatgrQRBKqFoKIdZAKhbXnqzNa0IsmogFb0R42zI3NceySheC3QnMiCzsDG DLAVEG+7Xx9Tv+ALSZ5GexUn6feLePmWdlfezratAqGrf5V2yOsD1FMcAGoXVra8gE2OXS y+6XJN6KZ/vb677XYZBUAtvVX1Hrrgh2/3RlgoaNYDVeJbN0Y9lYxHXw4lLI+TV9BC9EaD aVphpPLGGoKM9c2kmP+dwoxTUOiwnahkRbrEu2rpY8Mew15ZVYeLpCIs7bnwI9boGunWfh gmFmkX/57QQO1O+7CivTD1/FCemBEHFUv06+kFlV6Erax4eVjK0VBW3G2/bQ6A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766943850; a=rsa-sha256; cv=none; b=sNAN5GJpqm8j1KW886hWJ7NKaBJvg/94PClJMFTnFZqSQsmT03TRBe7JgyC2hE8T+iKiJ9 dOqWZrsDtUxSZ8dthwPLdlqVqqDy/uw4PYrUTNib/28bMlaYWMV3O8WxZiE+FrexNJSDJJ d6lfptiihTtVvNxGm7W9eMg6QOqRxwkcIPI7pxjenh4xPt/Uo9PsJf1f+XN6deSg/sUhaA N1MYHE73eULnZsmSGgspvH1mrtlHd7uRLla4kca/TaFG17nFeLuJd2jXrwQZTRtvTHvOmG Hgs1OKRyLwLgvwxq4/zasJakAMEDgwDyG73zvdUuAOw5OUZchar3QVUPbPyLxQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.227] (h-212-85-90-245.A980.priv.bahnhof.se [212.85.90.245]) (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) (Authenticated sender: js/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dfRYP6lN2z1Nln; Sun, 28 Dec 2025 17:44:09 +0000 (UTC) (envelope-from js@FreeBSD.org) Message-ID: <2a58208c-1f84-4c6d-8c01-b9df50d4c5d3@FreeBSD.org> Date: Sun, 28 Dec 2025 18:44:54 +0100 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 From: "js@freebsd.org" Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) To: freebsd-arm , FreeBSD Current References: <73B5AB7B-E546-431C-AAF8-C20DB5616CD5@yahoo.com> <16109C94-D82C-4873-BC21-41B420A850EE@yahoo.com> <6C850038-7550-4954-A319-0F1484C31766@yahoo.com> <29DCA955-4FEB-4EB4-8AEC-01312C932456@yahoo.com> Content-Language: en-US, sv-SE Cc: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Can someone with a FreeBSD 15 or 16 -CURRENT armv7 machine test if they're also getting segfaults when running gpart show? Or better yet, if someone has a test machine to lend me. On 12/28/25 17:06, Mark Millard wrote: > [minherit(0x2051e000,1100,INHERIT_ZERO) = 0 (0x0) > might be involoved?] > > On Dec 28, 2025, at 00:23, Mark Millard wrote: > >> On Dec 27, 2025, at 23:55, Mark Millard wrote: >> >>> [Turns out: works on aarch64 kernel's armv7 support, fails >>> on the armv7 native kernel, exact same world files on the >>> exact same media.] >> >> I got that wrong: a large part of the output occurs before a >> segmentation fault on the Windows Dev Kit 2023. But it has a >> very different backtrace and the output before that has numerical >> garbage values showing. >> >>> >>> On Dec 27, 2025, at 23:35, Mark Millard wrote: >>> >>>> On Dec 27, 2025, at 22:03, Mark Millard wrote: >>>> >>>>> Context: >>>>> >>>>> # uname -apKU >>>>> FreeBSD OPiP2E-RPi2v1p1 16.0-CURRENT FreeBSD 16.0-CURRENT main-n282732-939ac0c8fde2 GENERIC-NODEBUG arm armv7 1600007 1600007 >>>>> >>>>> That is an official pkgbase distribution that I installed, not >>>>> a personal build. pkgbase for main has world being a debug >>>>> build, no matter which of the kernels one choses to boot. >>>>> For pkgbase, 939ac0c8fde2 would be correct(?) for the kernel >>>>> but might not be exact for the world: /usr/src/sys/ and >>>>> /usr/src/ (without sys/) are from different times, last I >>>>> knew anyway. Changes can happen between. >>>>> >>>>> During boot, the time on the Orange Pi Plus 2ed is bad so: >>>>> >>>>> # ls -lodT /gpart.core >>>>> -rw------- 1 root wheel nodump 3174400 Jan 1 00:01:01 2010 /gpart.core >>>>> >>>>> Also, for pkgbase, a source file distributed can be newer >>>>> for its time stamp than the program distributed that was >>>>> based on the source file. Such happens below. >>>>> >>>>> >>>>> >>>>> Core was generated by `gpart show'. >>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>> Address not mapped to object. >>>>> #0 xo_format_string_direct (xop=xop@entry=0x2009b120, xbp=xbp@entry=0x2009b150, flags=flags@entry=4096, wcp=0x0, cp=0x6e480000 , len=-1, max=-1, >>>>> need_enc=3, have_enc=2) at /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>>> >>>>> warning: Source file is more recent than executable. >>>>> 2715 if (*cp == '\0') >>>>> (gdb) bt >>>>> #0 xo_format_string_direct (xop=xop@entry=0x2009b120, xbp=xbp@entry=0x2009b150, flags=flags@entry=4096, wcp=0x0, cp=0x6e480000 , len=-1, max=-1, >>>>> need_enc=3, have_enc=2) at /usr/src/contrib/libxo/libxo/libxo.c:2715 >>>>> #1 0x20150908 in xo_format_string (xop=0x2009b120, xbp=0x2009b150, flags=4096, xfp=0xbfbfd280) at /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>>> #2 xo_do_format_field (xop=, xop@entry=0x2009b120, xbp=0x2009b150, fmt=fmt@entry=0x20130635 "%s", flen=flen@entry=2, flags=4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 >>>>> #3 0x2014c69c in xo_simple_field (xop=0x2009b120, encode_only=0, value=0x0, vlen=0, fmt=0x20130635 "%s", flen=2, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>>> #4 xo_format_value (xop=, xop@entry=0x2009b120, name=, name@entry=0x204bf931 "state}\n", nlen=, nlen@entry=5, value=0x0, vlen=0, fmt=0x20130635 "%s", >>>>> flen=2, encoding=0x0, elen=0, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>>> #5 0x20148710 in xo_do_emit_fields (xop=, xop@entry=0x2009b120, fields=, fields@entry=0xbfbfd7e8, max_fields=max_fields@entry=17, fmt=) >>>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>>> #6 0x201476a0 in xo_do_emit (xop=xop@entry=0x2009b120, flags=, fmt=fmt@entry=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>>> #7 0x20147840 in xo_emit (fmt=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>>> #8 0x204d1fd4 in gpart_show_geom (gp=gp@entry=0x20089168, element=element@entry=0x204bfe51 "type", show_providers=show_providers@entry=0) at /usr/src/lib/geom/part/geom_part.c:654 >>>>> #9 0x204d1048 in gpart_show (req=0x20089000, fl=) at /usr/src/lib/geom/part/geom_part.c:793 >>>>> #10 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 >>>>> #11 0x00022308 in main (argc=1, argv=0xbfbfed90) at /usr/src/sbin/geom/core/geom.c:861 >>>>> (gdb) list >>>>> 2710 for (;;) { >>>>> 2711 if (len == 0) >>>>> 2712 break; >>>>> 2713 >>>>> 2714 if (cp) { >>>>> 2715 if (*cp == '\0') >>>>> 2716 break; >>>>> 2717 if ((flags & XFF_UNESCAPE) && (*cp == '\\' || *cp == '%')) { >>>>> 2718 cp += 1; >>>>> 2719 len -= 1; >>>>> (gdb) up >>>>> #1 0x20150908 in xo_format_string (xop=0x2009b120, xbp=0x2009b150, flags=4096, xfp=0xbfbfd280) at /usr/src/contrib/libxo/libxo/libxo.c:2982 >>>>> 2982 cols = xo_format_string_direct(xop, xbp, flags, wcp, cp, len, >>>>> (gdb) list >>>>> 2977 >>>>> 2978 return rc; >>>>> 2979 } >>>>> 2980 } >>>>> 2981 >>>>> 2982 cols = xo_format_string_direct(xop, xbp, flags, wcp, cp, len, >>>>> 2983 xfp->xf_width[XF_WIDTH_MAX], >>>>> 2984 need_enc, xfp->xf_enc); >>>>> 2985 if (cols < 0) >>>>> 2986 goto bail; >>>>> (gdb) list >>>>> 3498 >>>>> 3499 xf.xf_enc = (xf.xf_fc == 'm') ? XF_ENC_UTF8 >>>>> 3500 : (xf.xf_lflag || (xf.xf_fc == 'S')) ? XF_ENC_WIDE >>>>> 3501 : xf.xf_hflag ? XF_ENC_LOCALE : XF_ENC_UTF8; >>>>> 3502 >>>>> 3503 rc = xo_format_string(xop, xbp, flags, &xf); >>>>> 3504 >>>>> 3505 if ((flags & XFF_TRIM_WS) && xo_style_is_encoding(xop)) >>>>> 3506 rc = xo_trim_ws(xbp, rc); >>>>> 3507 >>>>> (gdb) up >>>>> #3 0x2014c69c in xo_simple_field (xop=0x2009b120, encode_only=0, value=0x0, vlen=0, fmt=0x20130635 "%s", flen=2, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:3817 >>>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>>> (gdb) list >>>>> 3812 { >>>>> 3813 if (encode_only) >>>>> 3814 flags |= XFF_NO_OUTPUT; >>>>> 3815 >>>>> 3816 if (vlen == 0) >>>>> 3817 xo_do_format_field(xop, NULL, fmt, flen, flags); >>>>> 3818 else if (!encode_only) >>>>> 3819 xo_data_append_content(xop, value, vlen, flags); >>>>> 3820 } >>>>> 3821 >>>>> (gdb) up >>>>> #4 xo_format_value (xop=, xop@entry=0x2009b120, name=, name@entry=0x204bf931 "state}\n", nlen=, nlen@entry=5, value=0x0, vlen=0, fmt=0x20130635 "%s", >>>>> flen=2, encoding=0x0, elen=0, flags=) at /usr/src/contrib/libxo/libxo/libxo.c:4373 >>>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>>> (gdb) list >>>>> 4368 >>>>> 4369 save.xhs_offset = xbp->xb_curp - xbp->xb_bufp; >>>>> 4370 save.xhs_columns = xop->xo_columns; >>>>> 4371 save.xhs_anchor_columns = xop->xo_anchor_columns; >>>>> 4372 >>>>> 4373 xo_simple_field(xop, FALSE, value, vlen, fmt, flen, flags); >>>>> 4374 >>>>> 4375 if (flags & XFF_HUMANIZE) >>>>> 4376 xo_format_humanize(xop, xbp, &save, flags); >>>>> 4377 break; >>>>> (gdb) up >>>>> #5 0x20148710 in xo_do_emit_fields (xop=, xop@entry=0x2009b120, fields=, fields@entry=0xbfbfd7e8, max_fields=max_fields@entry=17, fmt=) >>>>> at /usr/src/contrib/libxo/libxo/libxo.c:6372 >>>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>>> (gdb) list >>>>> 6367 flags &= ~XFF_WS; /* Prevent later handling of this flag */ >>>>> 6368 } >>>>> 6369 } >>>>> 6370 >>>>> 6371 if (ftype == 'V') >>>>> 6372 xo_format_value(xop, content, clen, NULL, 0, >>>>> 6373 xfip->xfi_format, xfip->xfi_flen, >>>>> 6374 xfip->xfi_encoding, xfip->xfi_elen, flags); >>>>> 6375 else if (ftype == '[') >>>>> 6376 xo_anchor_start(xop, xfip, content, clen); >>>>> (gdb) up >>>>> #6 0x201476a0 in xo_do_emit (xop=xop@entry=0x2009b120, flags=, fmt=fmt@entry=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") >>>>> at /usr/src/contrib/libxo/libxo/libxo.c:6551 >>>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>>> (gdb) list >>>>> 6546 /* Retain the info */ >>>>> 6547 xo_retain_add(fmt, fields, max_fields); >>>>> 6548 } >>>>> 6549 } >>>>> 6550 >>>>> 6551 return xo_do_emit_fields(xop, fields, max_fields, fmt); >>>>> 6552 } >>>>> 6553 >>>>> 6554 /* >>>>> 6555 * Rebuild a format string in a gettext-friendly format. This function >>>>> (gdb) up >>>>> #7 0x20147840 in xo_emit (fmt=0x204bf8e3 "=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/src/contrib/libxo/libxo/libxo.c:6622 >>>>> 6622 rc = xo_do_emit(xop, 0, fmt); >>>>> (gdb) list >>>>> 6617 { >>>>> 6618 xo_handle_t *xop = xo_default(NULL); >>>>> 6619 ssize_t rc; >>>>> 6620 >>>>> 6621 va_start(xop->xo_vap, fmt); >>>>> 6622 rc = xo_do_emit(xop, 0, fmt); >>>>> 6623 va_end(xop->xo_vap); >>>>> 6624 bzero(&xop->xo_vap, sizeof(xop->xo_vap)); >>>>> 6625 >>>>> 6626 return rc; >>>>> (gdb) up >>>>> #8 0x204d1fd4 in gpart_show_geom (gp=gp@entry=0x20089168, element=element@entry=0x204bfe51 "type", show_providers=show_providers@entry=0) at /usr/src/lib/geom/part/geom_part.c:654 >>>>> warning: Source file is more recent than executable. >>>>> 654 xo_emit("=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", >>>>> (gdb) list >>>>> 649 } >>>>> 650 wname = wmax; >>>>> 651 pp = LIST_FIRST(&gp->lg_consumer)->lg_provider; >>>>> 652 secsz = pp->lg_sectorsize; >>>>> 653 xo_open_instance("part"); >>>>> 654 xo_emit("=>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n", >>>>> 655 wblocks, (intmax_t)first, wblocks, (intmax_t)(last - first + 1), >>>>> 656 wname, gp->lg_name, >>>>> 657 scheme, pp->lg_mediasize, >>>>> 658 s ? " [CORRUPT]": ""); >>>>> (gdb) up >>>>> #9 0x204d1048 in gpart_show (req=0x20089000, fl=) at /usr/src/lib/geom/part/geom_part.c:793 >>>>> 793 gpart_show_geom(gp, element, show_providers); >>>>> (gdb) list >>>>> 788 else >>>>> 789 errx(EXIT_FAILURE, "No such geom: %s.", name); >>>>> 790 } >>>>> 791 } else { >>>>> 792 LIST_FOREACH(gp, &classp->lg_geom, lg_geom) { >>>>> 793 gpart_show_geom(gp, element, show_providers); >>>>> 794 } >>>>> 795 } >>>>> 796 xo_close_list(name); >>>>> 797 geom_deletetree(&mesh); >>>>> (gdb) up >>>>> #10 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 >>>>> warning: Source file is more recent than executable. >>>>> 497 cmd->gc_func(req, flags); >>>>> (gdb) list >>>>> 492 buf[0] = '\0'; >>>>> 493 if (cmd->gc_func != NULL) { >>>>> 494 unsigned flags; >>>>> 495 >>>>> 496 flags = set_flags(cmd); >>>>> 497 cmd->gc_func(req, flags); >>>>> 498 errstr = req->error; >>>>> 499 } else { >>>>> 500 gctl_add_param(req, "output", sizeof(buf), buf, >>>>> 501 GCTL_PARAM_WR | GCTL_PARAM_ASCII); >>>>> (gdb) up >>>>> #11 0x00022308 in main (argc=1, argv=0xbfbfed90) at /usr/src/sbin/geom/core/geom.c:861 >>>>> 861 run_command(argc, argv); >>>>> (gdb) list >>>>> 856 show_tree(); >>>>> 857 return (0); >>>>> 858 } >>>>> 859 >>>>> 860 get_class(&argc, &argv); >>>>> 861 run_command(argc, argv); >>>>> 862 /* NOTREACHED */ >>>>> 863 >>>>> 864 exit(EXIT_FAILURE); >>>>> 865 } >>>>> >>>>> >>>>> For reference: >>>>> >>>>> # ls -lodT /usr/src/contrib/libxo/libxo/libxo.c /usr/src/lib/geom/part/geom_part.c /usr/src/sbin/geom/core/geom.c /sbin/gpart >>>>> -r-xr-xr-x 17 root wheel - 30720 Dec 18 07:22:59 2025 /sbin/gpart >>>>> -rw-r--r-- 1 root wheel - 211505 Dec 24 08:29:29 2025 /usr/src/contrib/libxo/libxo/libxo.c >>>>> -rw-r--r-- 1 root wheel - 35380 Dec 24 08:29:29 2025 /usr/src/lib/geom/part/geom_part.c >>>>> -rw-r--r-- 1 root wheel - 36298 Dec 24 08:29:29 2025 /usr/src/sbin/geom/core/geom.c >>>>> >>>>> That explains the "warning: Source file is more recent than executable" >>>>> messages. >>>> >>>> Additional context notes: >>>> >>>> ) On the Cortex-A7 SUT the above is repeatable at the >>>> shell prompt when logged in: just try "gpart show", >>>> including via gdb use. "/rescue/gpart show" also >>>> core dumps. >>>> >>>> ) In a armv7 chroot on a aarch64 system (the Windows >>>> Dev Kit 2023), the "gpart show" works just fine. >>>> >>>> But the vintages could well be a little different. >>>> (Tracing to git commits for pkgbase is problematical.) >>>> >>>> >>>> I'll note: >>>> >>>> Johan Söllvander >>>> Date: Thu, 18 Dec 2025 15:23:29 UTC >>>> The branch main has been updated by js: >>>> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >>>> >>>> commit 4f809ffec69cd6ede3e7be9a5bc876b2e5931028 >>>> Author: Johan Söllvander >>>> AuthorDate: 2025-12-18 15:06:09 +0000 >>>> Commit: Johan Söllvander >>>> CommitDate: 2025-12-18 15:22:59 +0000 >>>> >>>> gpart: add libxo support for "show" subcommand + man page updates >>>> >>>> Added libxo support to `gpart show`, also updated the man >>>> pages for geom and gpart to show where you can expect >>>> libxo formatted output. >>>> >>>> PR: 290629 >>>> MFC after: 1 week >>>> Sponsored by: ConnectWise >>>> Reviewed by: asomers, mckusick, phil >>>> Approved by: asomers (mentor) >>>> Differential Revision: https://reviews.freebsd.org/D53950 >>>> --- >>>> . . . >>>> >>>> >>>> Note: Dec 18 07:22:59 2025 /sbin/gpart for my time zone >>>> would be 2025-12-18 15:22:59 +0000 (the CommitDate) UTC. >>> >>> >>> I shut down the OPi+2e and mounted the boot media >>> on the Windows Dev Kit 2023 and then did a chroot >>> into that boot media and tried "gpart show": >>> >>> "gpart show" worked just fine. >>> >>> What matters is which kernel it runs on for the >>> exact same world files on the exact same media. >>> >> >> I got that wrong: a large part of the output occurs before >> a segmentation fault on the Windows Dev Kit 2023. But it has a >> very different backtrace. Also, note all the "517M" that make no >> sense --and the "0" and "2" junk as well: >> >> # gpart show >> => 34 1000215149 nda0 GPT (2)(null) >> 34 2014 - free - (2) >> 2048 532480 1 efi (517M) >> 534528 32768 2 ms-reserved (517M) >> 567296 997287936 3 ms-basic-data (517M) >> 997855232 2359296 4 ms-recovery (517M) >> 1000214528 655 - free - (2) >> >> => 34 2930277101 da0 GPT (0)(null) >> 34 32734 - free - (0) >> 32768 501760 1 efi (517M) >> 534528 20971520 2 freebsd-swap (517M) >> 21506048 29360128 3 freebsd-swap (517M) >> 50866176 33554432 4 freebsd-swap (517M) >> 84420608 67108864 5 freebsd-swap (517M) >> 151529472 96468992 6 freebsd-swap (517M) >> 247998464 268435456 7 freebsd-swap (517M) >> 516433920 7340032 8 freebsd-swap (517M) >> 523773952 13096960 - free - (0) >> 536870912 2357198848 9 freebsd-ufs (517M) >> 2894069760 36207375 - free - (0) >> >> => 40 1953525088 da1 GPT (0)(null) >> 40 532480 1 efi (517M) >> 532520 2008 - free - (0) >> 534528 3563520 2 freebsd-swap (517M) >> 4098048 6504448 - free - (0) >> 10602496 1740636160 4 freebsd-ufs (517M) >> 1751238656 7546880 3 freebsd-swap (517M) >> 1758785536 194739592 - free - (0) >> >> Segmentation fault (core dumped) >> >> As for gdb's backtrace: >> >> Program terminated with signal SIGSEGV, Segmentation fault. >> Address not mapped to object. >> #0 0x200c5ef0 in delete_config (gp=0x2053e224) at /usr/src/lib/libgeom/geom_xml2tree.c:502 >> >> warning: Source file is more recent than executable. >> 502 LIST_REMOVE(cf, lg_config); >> (gdb) bt >> #0 0x200c5ef0 in delete_config (gp=0x2053e224) at /usr/src/lib/libgeom/geom_xml2tree.c:502 >> #1 geom_deletetree (gmp=gmp@entry=0xffffcb48) at /usr/src/lib/libgeom/geom_xml2tree.c:524 >> #2 0x204d2064 in gpart_show (req=, fl=) at /usr/src/lib/geom/part/geom_part.c:797 >> #3 0x000230dc in run_command (argc=0, argv=) at /usr/src/sbin/geom/core/geom.c:497 >> #4 0x00022308 in main (argc=1, argv=0xffffdc70) at /usr/src/sbin/geom/core/geom.c:861 >> >> >> (I need to get some sleep.) > > Back to the Cortex-A7 context (armv7 without aatch64) > for that same media . . . > > The tail of a truss output from a run looks like > (note the "minherit(0x2051e000,1100,INHERIT_ZERO)"?): > > . . . > modfind("g_part") = 190 (0xbe) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 537432064 (0x20089000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 537452544 (0x2008e000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 537456640 (0x2008f000) > mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542076928 (0x204f7000) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542089216 (0x204fa000) > mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542109696 (0x204ff000) > mmap(0x0,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542121984 (0x20502000) > __sysctl("sysctl.name2oid kern.geom.confxml",2,0xbfbfdbb8,0xbfbfdbb0,0x200b4716,17) = 0 (0x0) > __sysctl("kern.geom.confxml",3,0x0,0xbfbfdbb4,0x0,0) = 0 (0x0) > mmap(0x0,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542150656 (0x20509000) > __sysctl("kern.geom.confxml",3,0x20509180,0xbfbfdbb4,0x0,0) = 0 (0x0) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542175232 (0x2050f000) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542195712 (0x20514000) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542216192 (0x20519000) > mmap(0x0,1100,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 542236672 (0x2051e000) > minherit(0x2051e000,1100,INHERIT_ZERO) = 0 (0x0) > getrandom("\M-,\M-;\M^P\^Rl\^VHP\M->'\M-v"...,40,0) = 40 (0x28) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542240768 (0x2051f000) > mmap(0x0,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542261248 (0x20524000) > mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542289920 (0x2052b000) > mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542302208 (0x2052e000) > mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542322688 (0x20533000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542334976 (0x20536000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542339072 (0x20537000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 542343168 (0x20538000) > SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=5 addr=0x6e480000 > process killed, signal = 11 (core dumped) > > > Given recent work on anonymous zeroed pages, I note for > minherit: > > QUOTE > INHERIT_ZERO This option causes the address space in question to be > mapped as new anonymous pages, which would be initial- > ized to all zero bytes, in the child process. > END QUOTE > > Not that I've any specific evidence of it being an issue. > > I'll note that trying the official debug kernel did not report > anything special and got the same behavior. > > > === > Mark Millard > marklmi at yahoo.com > From nobody Sun Dec 28 18:32:36 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 4dfSdj0qyTz6M9Nh for ; Sun, 28 Dec 2025 18:32:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4dfSdh2Pz9z3kT4 for ; Sun, 28 Dec 2025 18:32:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sbqieLTl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1766946768; bh=gEx+ysoMfGSkdp8FNgmeah4bEIEVqE4AsO6Y1Cb6zm8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=sbqieLTlgtsbn4NrAsNSdqkHE7OlF537AbnGCJNNtb2u2qJVCJnyQOtRRho3yg6CvAG6p9RLJEDap0+69a6/UvSrw/OjU4aK9l2739SAz+8eU52JUPcj+NakwGhJnsaDPAS0EkXDezRLh+L+U3M5ANWYo7DegFprDqQzy0dLBBMSfSFeY7+qr6ckDS2hPmbsleGeD4HSdn4Y6qpFlg72n/Te9szX0VJdXUTVcKxMsCTJXEALnPcntMaAhVdRfiHBEWrKNgqmyjE2+IeHBjryHef167MAWjXpZp9XHq7d91UhJOt/L5TrETAEkHlaSHUgSzyPaeZi2J/W5QwM3/h8GA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766946768; bh=5agc83PM6DPgMQ0CXATYbtJr1eNN5bu6QZiq4fA5Par=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GHnWeDDq7eZ9nWX3qaz4d3zvWqdXH1VtrlwjvesObFAkh85AuR960bD9BXg1+Bta0Qxd35PHZyNH9cv1z33hSV9CaPh8ENoQvBQtconGD1+r4TJl5LQFGZdRvOkacSEpEI86EwLUa7TVs384mQ0qwqji8jke7GQrVdjU3Z6Aof3vNDPsqw7DG7axJ2DxrXw71a2k3KuhLVP2IP/imrhFkYoEX7P1vRFKpw0qScyzgOBIVQj4u5nSJsLZHh4NdZkWtes7xOuutNdae2N7uMn/HF8fNaXgDIVZh6nVKo8TjE3zL78QMbom9LTK25bRh7SYHWhc7deoLCxSFAIxhM3Csw== X-YMail-OSG: ssckIbMVM1nbw2w.pHI9zDZP2UIX_iJ7UHckHqteBKDnUwuzeiXFmh30iMMuERs nnTPfsuBNuxKrnQro7kyTtWYuTkS.Wt95A.K.W.l4m_ZAUV4dCTDsvyCM4AL3YAlNr42DdtWRh9J HrKREReU8NYkABcha5auyYaarhTj8iLfXaJud86vuS58zyMJLNMMMkrKNoFZLlNFqZJBDPSp4kde 4V3HcBFvVKF_hpYagAxEeYSWY5W3kXfRaDH7U3s6dnguRHISYI8xGuqKfMrRDJu34yT_gmEzBMVO llBH7mM_ECKd2ZyicHnG3ImHV_CWqzdZhNrZMice_Fop_H_.Dwg2t0goaNAU3dciorUTy1AbQnEc umqJxwmM1NkjE5.pKxbtiSR3Wk2n.axytyoVt4RpTiEqfBD1NPSkqASQWkQP0O.KKJ56Qgo2mLnr uHMd9hkImCBrxEKrqlRUNpaQpLzdrQu1wmWm5io6SJCSfN7OhYss2J6iY6nz.y33nvNz7Wnjayb5 QigO_hUrF1UJG8BbXQn1pc8bntskgvljgK7i9CdvwlSb6gfMedDIxXjxMjWUkYcEKyfiovrFq4Bu bIE1MtoOxp8nJMxk.FdsQffTC8Qg47n9qTfpHQrY_vp7wd_40Pbt_AasCTg0.QY3.P33RUcjOZs3 dKFBAedVDpHzhxffvwf2Sjm5TgXrihrWJnGCWT.qFINM3t.MtVPczeXu15OVTlJpOzfCOK1Qu0B1 Io8tLmpUr6tFZ95WbtL_jlnKn_Gcp8uwjpLEQeetr.lyrWAXmGsc103AeWiQQfuU9gVEfNxadNky hhwVjXW9VJHAJKzxAQJtFoMQ5Hrbkz2yNqtxcRUssJA1VTHPWlBG6MaL4RWewQScCh0CtdSnrkr8 5L9WiVeQzfSsX5Tf5uqX.MzEHwEkRHyBeZp94Lt.aJc9r6WQG0hIAATQYwKwlW77x3EZXhS0xVLD YQVaQWed0LAH1_OsTZdJ_yQ_XBdmIdtaK4YHhDTQMAfMrYXVVM1wsMhuHxsjTX_VxoxUFrgxcjj8 AOYhz3RFyybHDoFYLKY8lgtfCnH.eD8anCN8aF0G8ar9YaTf3ApmuaCiJ9r6wafTVBoPvaVpAEcl oglbd7ZPEcFnwQuuAteq00Lc_7KWiIEySwGuS35q5SI66AgSeRdkdL9E7_pYQ4lfbjfZEcG5s_JT JXDrs3b7Geachb_2JGCRorWUDx2r.pd40h7A5Yo8doAHJL7yGv035G_4_3cOUTRvcgnMCe5c4o3e gbLNs.jjbCJHliLC_jCLPHXm4JQTfBoY2BwMRkzdr0DtkAwPCU3BzqmwCYUHVy.cxPY7uS9xBoly t63VTjpFplbVjrkfOeXjuUmLqtrO3PFpmv74hGDnMdPn30vPqVPBTmanedF0nN7RdTW_uT2KKFuq LigNf_q5Susn8l0oepF_Rm9GkVTp9J6pDR4utPMrTiQhWd2zjfK2qX.SmqRoJ98.z_FlHM.YMn.I v9FvN4KIl_D0RkpbpFuigCnvm6HzSikgR0OVY_5hLgsGsuaDuF9T2qfM9OQ5S8TpbwHoV_3cX0zn UlNzetLKa9.uviTujHE00yjfbLa1LCVtGFDyxH2QlndokAO4j_sfd.g11szPGMYSBltHcUCl01uq XWl7fx.2fRJB3IIfUW2UAuOI.Ge9lFa3vw_sQ.mbR6jEe_ONLWcO3luQ9zkXZ5D.ksHLqmPg9pEd Yz_UFwaXZ5uzwbkWWbcxewoTgKDRNobMuhgP3Iz9n6JzWTXY_1bSldgyJyeRnuEKGfeE85Y5Jqzd Ou86CGuM06vEtD6S7KjjTZe.xccQPRVovfpHuwIjJ0wjJ9W1t1Bs1Zx425NtelE2Liv.ai7XxK1. hUTagvIAbfzXj4Tsid9pDRge9o8vC14zKG.jzSdE7seu86v_I_HeCzTb75jEUDTujJ3Kn5qWiMvS yev6na6SQqvDCA3PYK07JREd5XSbdHFWSkchuYnjXMSHSHtgnbse9dld3ohqAuMe3zbBupKLarqN rzgxVVFtbOm8XC6Y4t1NXQTPfyzth1Gfj1zeP_R3hnuq61VxUrKth_SdbiptZc_cOrPZ5fBK0b62 ATwCccVGu2oUrq89Gylk6Bu_fQJjt8v6XSOn2eOHibFm_m4FT.cniNLcywiaMB1x0uPVgXSzFU5m qhXXPgYGLhSVGuesupYnFWcSA78N5KyMvBhz8evsI6AMCl5hPcANaZset9DCMHYtKZZ5A6ZDY2Xj k.aF9VnPzZvPYpZwvKe_QGPUsoCVe X-Sonic-MF: X-Sonic-ID: 3d431b14-dd3f-4a6c-b1ac-1b4acd9c4193 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 18:32:48 +0000 Received: by hermes--production-gq1-54bf57fc64-spflw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5188bbcd3259a6994e2099761c12185b; Sun, 28 Dec 2025 18:32:47 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) Date: Sun, 28 Dec 2025 10:32:36 -0800 References: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> To: js@freebsd.org, FreeBSD Current , freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.936]; 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)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Rspamd-Queue-Id: 4dfSdh2Pz9z3kT4 On Dec 28, 2025, at 08:54, Mark Millard wrote: > [Resend including freebsd-arm.] >=20 > On Dec 28, 2025, at 08:48, Mark Millard wrote: >=20 > js@freebsd.org wrote on > Date: Sun, 28 Dec 2025 11:01:59 UTC : >=20 >> I'll take a look at it and try to setup a reproducer, unfortunately = my=20 >> time is a bit limited during the holidays so I can't promise any = quick=20 >> fixes right now. >>=20 >> Could you share the output of >>=20 >> gpart --libxo:JP show >>=20 >> with me? If possible. >=20 > On the Orange Pi Plus 2e (Cortex-A7, not aarch64, > just armv7): >=20 > # gpart --libxo:JP show > Segmentation fault (core dumped) >=20 > I'll note that the 0x6e480000 in r0 that is shown > later below is the same failing address reported > in my original list submittal about the issue. >=20 >=20 > For reference: >=20 > (gdb) bt > #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 > #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150, = flags=3D4096, xfp=3D0xbfbfd1f8) at = /usr/src/contrib/libxo/libxo/libxo.c:2966 > #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D, flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 > #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at = /usr/src/contrib/libxo/libxo/libxo.c:3817 > #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, = name=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, = value=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, = elen=3D0,=20 > flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 > #5 0x20148710 in xo_do_emit_fields (xop=3D, = xop@entry=3D0x2009b120, fields=3D, = fields@entry=3D0xbfbfd768, max_fields=3Dmax_fields@entry=3D17, = fmt=3D) > at /usr/src/contrib/libxo/libxo/libxo.c:6372 > #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, = flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") > at /usr/src/contrib/libxo/libxo/libxo.c:6551 > #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} = {t:sectors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") = at /usr/src/contrib/libxo/libxo/libxo.c:6622 > #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, = element=3Delement@entry=3D0x204bfe51 "type", = show_providers=3Dshow_providers@entry=3D0) at = /usr/src/lib/geom/part/geom_part.c:654 > #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) = at /usr/src/lib/geom/part/geom_part.c:793 > #10 0x000230dc in run_command (argc=3D0, argv=3D) at = /usr/src/sbin/geom/core/geom.c:497 > #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at = /usr/src/sbin/geom/core/geom.c:861 > (gdb) list > . . . >=20 I'll note that the details are different, but I get failures in an armv7 chroot on aarch64 that supports armv7 code. So that is another type of environment that might be of use based on pkgbase distribution materials. Your --libxo:JP command in that context gets some output before also getting a segmentation fault: # gpart --libxo:JP show { "__version": "1",=20 "PART": [ { "start": 34, "sectors": 1000215149, "name": "nda0", "scheme": "GPT", "size": 2, "state": "(null)", "partitions": [ { "start": 34, "sectors": 2014, "free": true, "size": 2 }, { "start": 2048, "sectors": 532480, "index": 1, "name": "nda0p1", "type": "efi", "label": "EFI system partition", "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", "size": 541854500 }, { "start": 534528, "sectors": 32768, "index": 2, "name": "nda0p2", "type": "ms-reserved", "label": "Microsoft reserved partition", "rawtype": "e3c9e316-0b5c-4db8-817d-f92df00215ae", "size": 541854500 }, { "start": 567296, "sectors": 997287936, "index": 3, "name": "nda0p3", "type": "ms-basic-data", "label": "Basic data partition", "rawtype": "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7", "size": 541854500 }, { "start": 997855232, "sectors": 2359296, "index": 4, "name": "nda0p4", "type": "ms-recovery", "label": "(null)", "rawtype": "de94bba4-06d1-4d40-a16a-bfd50179d6ac", "size": 541854500 }, { "start": 1000214528, "sectors": 655, "free": true, "size": 2 } ] }, { "start": 34, "sectors": 2930277101, "name": "da0", "scheme": "GPT", "size": 0, "state": "(null)", "partitions": [ { "start": 34, "sectors": 32734, "free": true, "size": 0 }, { "start": 32768, "sectors": 501760, "index": 1, "name": "da0p1", "type": "efi", "label": "PBaseEFI", "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", "size": 541854500 }, { "start": 534528, "sectors": 20971520, "index": 2, "name": "da0p2", "type": "freebsd-swap", "label": "PBaseSwp10", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 21506048, "sectors": 29360128, "index": 3, "name": "da0p3", "type": "freebsd-swap", "label": "PBaseSwp14", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 50866176, "sectors": 33554432, "index": 4, "name": "da0p4", "type": "freebsd-swap", "label": "PBaseSwp16", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, "type": "freebsd-swap", "label": "PBaseSwp32", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 151529472, "sectors": 96468992, "index": 6, "name": "da0p6", "type": "freebsd-swap", "label": "PBaseSwp46", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 247998464, "sectors": 268435456, "index": 7, "name": "da0p7", "type": "freebsd-swap", "label": "PBaseSwp128", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 516433920, "sectors": 7340032, "index": 8, "name": "da0p8", "type": "freebsd-swap", "label": "PBaseSwp3p5", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 523773952, "sectors": 13096960, "free": true, "size": 0 }, { "start": 536870912, "sectors": 2357198848, "index": 9, "name": "da0p9", "type": "freebsd-ufs", "label": "PBaseUFS", "rawtype": "516e7cb6-6ecf-11d6-8ff8-00022d09712b", "size": 541854500 }, { "start": 2894069760, "sectors": 36207375, "free": true, "size": 0 } ] }Segmentation fault (core dumped) # gpart show =3D> 34 1000215149 nda0 GPT (2)(null) 34 2014 - free - (2) 2048 532480 1 efi (517M) 534528 32768 2 ms-reserved (517M) 567296 997287936 3 ms-basic-data (517M) 997855232 2359296 4 ms-recovery (517M) 1000214528 655 - free - (2) =3D> 34 2930277101 da0 GPT (0)(null) 34 32734 - free - (0) 32768 501760 1 efi (517M) 534528 20971520 2 freebsd-swap (517M) 21506048 29360128 3 freebsd-swap (517M) 50866176 33554432 4 freebsd-swap (517M) 84420608 67108864 5 freebsd-swap (517M) 151529472 96468992 6 freebsd-swap (517M) 247998464 268435456 7 freebsd-swap (517M) 516433920 7340032 8 freebsd-swap (517M) 523773952 13096960 - free - (0) 536870912 2357198848 9 freebsd-ufs (517M) 2894069760 36207375 - free - (0) Segmentation fault (core dumped) =46rom an aarch64 context instead pf the armv7 chroot: # gpart show you have mail =3D> 34 1000215149 nda0 GPT (477G) 34 2014 - free - (1007K) 2048 532480 1 efi (260M) 534528 32768 2 ms-reserved (16M) 567296 997287936 3 ms-basic-data (476G) 997855232 2359296 4 ms-recovery (1G) 1000214528 655 - free - (328K) =3D> 34 2930277101 da0 GPT (1T) 34 32734 - free - (16M) 32768 501760 1 efi (245M) 534528 20971520 2 freebsd-swap (10G) 21506048 29360128 3 freebsd-swap (14G) 50866176 33554432 4 freebsd-swap (16G) 84420608 67108864 5 freebsd-swap (32G) 151529472 96468992 6 freebsd-swap (46G) 247998464 268435456 7 freebsd-swap (128G) 516433920 7340032 8 freebsd-swap (4G) 523773952 13096960 - free - (6G) 536870912 2357198848 9 freebsd-ufs (1T) 2894069760 36207375 - free - (17G) Here is a "diff -u" of the libxo:JP outputs: # diff -u gpart_show_armv7_failure_libxo_jp.txt = gpart_show_aarch64_good_libxo_jp.txt --- gpart_show_armv7_failure_libxo_jp.txt 2025-12-28 = 10:27:57.985558000 -0800 +++ gpart_show_aarch64_good_libxo_jp.txt 2025-12-28 = 10:28:41.456968000 -0800 @@ -7,14 +7,14 @@ "sectors": 1000215149, "name": "nda0", "scheme": "GPT", - "size": 2, - "state": "(null)", + "size": 512110190592, + "state": "", "partitions": [ { "start": 34, "sectors": 2014, "free": true, - "size": 2 + "size": 1031168 }, { "start": 2048, @@ -24,7 +24,7 @@ "type": "efi", "label": "EFI system partition", "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", - "size": 541854500 + "size": 272629760 }, { "start": 534528, @@ -34,7 +34,7 @@ "type": "ms-reserved", "label": "Microsoft reserved partition", "rawtype": "e3c9e316-0b5c-4db8-817d-f92df00215ae", - "size": 541854500 + "size": 16777216 }, { "start": 567296, @@ -44,7 +44,7 @@ "type": "ms-basic-data", "label": "Basic data partition", "rawtype": "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7", - "size": 541854500 + "size": 510611423232 }, { "start": 997855232, @@ -54,13 +54,13 @@ "type": "ms-recovery", "label": "(null)", "rawtype": "de94bba4-06d1-4d40-a16a-bfd50179d6ac", - "size": 541854500 + "size": 1207959552 }, { "start": 1000214528, "sectors": 655, "free": true, - "size": 2 + "size": 335360 } ] }, @@ -69,14 +69,14 @@ "sectors": 2930277101, "name": "da0", "scheme": "GPT", - "size": 0, - "state": "(null)", + "size": 1500301910016, + "state": "", "partitions": [ { "start": 34, "sectors": 32734, "free": true, - "size": 0 + "size": 16759808 }, { "start": 32768, @@ -86,7 +86,7 @@ "type": "efi", "label": "PBaseEFI", "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", - "size": 541854500 + "size": 256901120 }, { "start": 534528, @@ -96,7 +96,7 @@ "type": "freebsd-swap", "label": "PBaseSwp10", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 10737418240 }, { "start": 21506048, @@ -106,7 +106,7 @@ "type": "freebsd-swap", "label": "PBaseSwp14", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 15032385536 }, { "start": 50866176, @@ -116,12 +116,17 @@ "type": "freebsd-swap", "label": "PBaseSwp16", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 17179869184 }, + { + "start": 84420608, + "sectors": 67108864, - "size": 541854500 + "size": 34359738368 }, { "start": 151529472, @@ -131,7 +136,7 @@ "type": "freebsd-swap", "label": "PBaseSwp46", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 49392123904 }, { "start": 247998464, @@ -141,7 +146,7 @@ "type": "freebsd-swap", "label": "PBaseSwp128", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 137438953472 }, { "start": 516433920, @@ -151,13 +156,13 @@ "type": "freebsd-swap", "label": "PBaseSwp3p5", "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 3758096384 }, { "start": 523773952, "sectors": 13096960, "free": true, - "size": 0 + "size": 6705643520 }, { "start": 536870912, @@ -167,13 +172,16 @@ "type": "freebsd-ufs", "label": "PBaseUFS", "rawtype": "516e7cb6-6ecf-11d6-8ff8-00022d09712b", - "size": 541854500 + "size": 1206885810176 }, { "start": 2894069760, "sectors": 36207375, "free": true, - "size": 0 + "size": 18538176000 } ] - }Segmentation fault (core dumped) + } + ] +} + =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 19:16:20 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 4dfTc24x0Bz6MDQK for ; Sun, 28 Dec 2025 19:16:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 4dfTc22fBzz3pDR for ; Sun, 28 Dec 2025 19:16:34 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-64b9cb94ff5so10025109a12.2 for ; Sun, 28 Dec 2025 11:16:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766949393; x=1767554193; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+ysEYxJd/zIFtLNou4ofqIuPSGmb6nP8RBKLPoE46BY=; b=Z+6VLHhc//eYmhz61KRABjcFJpW2xPWdKp5/PWdy3RhB1koKLUvV5aVt0O/0Fppf0g 5wB1PmFO6Lc06AhEC0FuzKbiXKDMlRoL+JntTzya0Qugkb0kVxVMwmOXFvjKa8VoL3RT FGTD3tWOro+afuc9ddcXub7ypnn2etyyqdfjPrcS2B0Lv2X/zRBTB4h94l0JNr9mkfLd AImdVMAAlEsfDq+fPMsfKk2RnRFWPCnxIeJmbHXHNPD9mZdEDKUyjFlVrGMPEG0Vj8nh EfMTQgxFZD2qSL8u1p07JGAGU2c6jL0GxGX1Wi2uTuTlb+7LIxr6dQnHM/IaBxgT5/DG Kx2g== X-Forwarded-Encrypted: i=1; AJvYcCXYCBRRB9MAQ9z/3cNBkkl0dzIFUl4wpNm/MdFW/jIicDGPIdpZYEd3ryNhuNBifx8Zn3xC8s+Coyi3InNEE+0=@freebsd.org X-Gm-Message-State: AOJu0Ywzcj5AlMvqKEbmsxW1yM5ssOsKefWjEc96ZAXgNmGuON707Xzx zXzBgr5d7XXDFSKUH7T3kc11Naxm+RePRWUSuzomctO18ACC4CeYo04MMZqgn02m0x/i4XDB1OQ eV3F6Z31I+e4QCPu9vVeTbrLzR1sD+qg= X-Gm-Gg: AY/fxX7hpxEWxpPDbfZpIgX5CU3zmT0BMH2oOGgu2xJwIUnRwtpUU+Fakw9yIV+fWNt uIkaVIUqy73gG9C1sFhY62OUGzGO0N4stcndOYuZAyRhyHVnMMN0Bb78xs01MyJEljZX+o12lq7 ApWZIyVmtykYkuT0Ks6A7NyaxLTYBtUeAIL6PYhQdhTZQO9Q0IbYMn7yk0RnQqk8UBZGzoLz1Us 6x9Yy5n5+LS0OpMGznmMdUMtgtGW2nUMjnUSZoWXf7JuwJQO+rxv/Nwq47zrYeukIm2Ypt9OJ+6 qEnWXg== X-Google-Smtp-Source: AGHT+IFBF4zhvK+jYS+CGoeg4qPr2YBHRrCZQfo3jfdKrvym6K7ZLXNrrh8QZTAuT55k4qksfZSowQjg0gQkOc9NqCs= X-Received: by 2002:a05:6402:354b:b0:64b:7795:a6e3 with SMTP id 4fb4d7f45d1cf-64b8eeea6b7mr25509071a12.32.1766949392362; Sun, 28 Dec 2025 11:16:32 -0800 (PST) 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: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> In-Reply-To: From: Alan Somers Date: Sun, 28 Dec 2025 12:16:20 -0700 X-Gm-Features: AQt7F2r5uwHuh_nl0TqekSU_A19NDuThzd12239_0HFiyrVe212dORD7B2HorLQ Message-ID: Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) To: Mark Millard Cc: js@freebsd.org, FreeBSD Current , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dfTc22fBzz3pDR The output of "kern.geom.confxml" would also be useful. Also, I suggest that we move this discussion into Bugzilla. On Sun, Dec 28, 2025 at 11:33=E2=80=AFAM Mark Millard w= rote: > > On Dec 28, 2025, at 08:54, Mark Millard wrote: > > > [Resend including freebsd-arm.] > > > > On Dec 28, 2025, at 08:48, Mark Millard wrote: > > > > js@freebsd.org wrote on > > Date: Sun, 28 Dec 2025 11:01:59 UTC : > > > >> I'll take a look at it and try to setup a reproducer, unfortunately my > >> time is a bit limited during the holidays so I can't promise any quick > >> fixes right now. > >> > >> Could you share the output of > >> > >> gpart --libxo:JP show > >> > >> with me? If possible. > > > > On the Orange Pi Plus 2e (Cortex-A7, not aarch64, > > just armv7): > > > > # gpart --libxo:JP show > > Segmentation fault (core dumped) > > > > I'll note that the 0x6e480000 in r0 that is shown > > later below is the same failing address reported > > in my original list submittal about the issue. > > > > > > For reference: > > > > (gdb) bt > > #0 strlen () at /usr/src/lib/libc/arm/string/strlen.S:46 > > #1 0x20151020 in xo_format_string (xop=3D0x2009b120, xbp=3D0x2009b150,= flags=3D4096, xfp=3D0xbfbfd1f8) at /usr/src/contrib/libxo/libxo/libxo.c:29= 66 > > #2 xo_do_format_field (xop=3D, xop@entry=3D0x2009b120, = xbp=3D0x2009b150, fmt=3Dfmt@entry=3D0xbfbfd268 "%s", flen=3D= , flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:3503 > > #3 0x2014d0a8 in xo_simple_field (xop=3D0x2009b120, encode_only=3D0, v= alue=3D0x0, vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, flags=3D4096) at /us= r/src/contrib/libxo/libxo/libxo.c:3817 > > #4 xo_format_value (xop=3D, xop@entry=3D0x2009b120, nam= e=3Dname@entry=3D0x204bf931 "state}\n", nlen=3Dnlen@entry=3D5, value=3D0x0,= vlen=3D0, fmt=3D0xbfbfd268 "%s", flen=3D2, encoding=3D0x0, elen=3D0, > > flags=3D4096) at /usr/src/contrib/libxo/libxo/libxo.c:4535 > > #5 0x20148710 in xo_do_emit_fields (xop=3D, xop@entry= =3D0x2009b120, fields=3D, fields@entry=3D0xbfbfd768, max_fie= lds=3Dmax_fields@entry=3D17, fmt=3D) > > at /usr/src/contrib/libxo/libxo/libxo.c:6372 > > #6 0x201476a0 in xo_do_emit (xop=3Dxop@entry=3D0x2009b120, flags=3D, fmt=3Dfmt@entry=3D0x204bf8e3 "=3D>{t:start/%*jd} {t:sectors/= %*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") > > at /usr/src/contrib/libxo/libxo/libxo.c:6551 > > #7 0x20147840 in xo_emit (fmt=3D0x204bf8e3 "=3D>{t:start/%*jd} {t:sec= tors/%*jd} {t:name/%*s} {:scheme} ({h:size/%ld}){t:state}\n") at /usr/sr= c/contrib/libxo/libxo/libxo.c:6622 > > #8 0x204d1fd4 in gpart_show_geom (gp=3Dgp@entry=3D0x20089168, element= =3Delement@entry=3D0x204bfe51 "type", show_providers=3Dshow_providers@entry= =3D0) at /usr/src/lib/geom/part/geom_part.c:654 > > #9 0x204d1048 in gpart_show (req=3D0x20089000, fl=3D) a= t /usr/src/lib/geom/part/geom_part.c:793 > > #10 0x000230dc in run_command (argc=3D0, argv=3D) at /us= r/src/sbin/geom/core/geom.c:497 > > #11 0x00022308 in main (argc=3D1, argv=3D0xbfbfed10) at /usr/src/sbin/g= eom/core/geom.c:861 > > (gdb) list > > . . . > > > > I'll note that the details are different, but I get failures > in an armv7 chroot on aarch64 that supports armv7 code. So > that is another type of environment that might be of use based > on pkgbase distribution materials. > > Your --libxo:JP command in that context gets some output > before also getting a segmentation fault: > > # gpart --libxo:JP show > { > "__version": "1", > "PART": [ > { > "start": 34, > "sectors": 1000215149, > "name": "nda0", > "scheme": "GPT", > "size": 2, > "state": "(null)", > "partitions": [ > { > "start": 34, > "sectors": 2014, > "free": true, > "size": 2 > }, > { > "start": 2048, > "sectors": 532480, > "index": 1, > "name": "nda0p1", > "type": "efi", > "label": "EFI system partition", > "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", > "size": 541854500 > }, > { > "start": 534528, > "sectors": 32768, > "index": 2, > "name": "nda0p2", > "type": "ms-reserved", > "label": "Microsoft reserved partition", > "rawtype": "e3c9e316-0b5c-4db8-817d-f92df00215ae", > "size": 541854500 > }, > { > "start": 567296, > "sectors": 997287936, > "index": 3, > "name": "nda0p3", > "type": "ms-basic-data", > "label": "Basic data partition", > "rawtype": "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7", > "size": 541854500 > }, > { > "start": 997855232, > "sectors": 2359296, > "index": 4, > "name": "nda0p4", > "type": "ms-recovery", > "label": "(null)", > "rawtype": "de94bba4-06d1-4d40-a16a-bfd50179d6ac", > "size": 541854500 > }, > { > "start": 1000214528, > "sectors": 655, > "free": true, > "size": 2 > } > ] > }, > { > "start": 34, > "sectors": 2930277101, > "name": "da0", > "scheme": "GPT", > "size": 0, > "state": "(null)", > "partitions": [ > { > "start": 34, > "sectors": 32734, > "free": true, > "size": 0 > }, > { > "start": 32768, > "sectors": 501760, > "index": 1, > "name": "da0p1", > "type": "efi", > "label": "PBaseEFI", > "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", > "size": 541854500 > }, > { > "start": 534528, > "sectors": 20971520, > "index": 2, > "name": "da0p2", > "type": "freebsd-swap", > "label": "PBaseSwp10", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 21506048, > "sectors": 29360128, > "index": 3, > "name": "da0p3", > "type": "freebsd-swap", > "label": "PBaseSwp14", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 50866176, > "sectors": 33554432, > "index": 4, > "name": "da0p4", > "type": "freebsd-swap", > "label": "PBaseSwp16", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > "type": "freebsd-swap", > "label": "PBaseSwp32", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 151529472, > "sectors": 96468992, > "index": 6, > "name": "da0p6", > "type": "freebsd-swap", > "label": "PBaseSwp46", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 247998464, > "sectors": 268435456, > "index": 7, > "name": "da0p7", > "type": "freebsd-swap", > "label": "PBaseSwp128", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 516433920, > "sectors": 7340032, > "index": 8, > "name": "da0p8", > "type": "freebsd-swap", > "label": "PBaseSwp3p5", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 523773952, > "sectors": 13096960, > "free": true, > "size": 0 > }, > { > "start": 536870912, > "sectors": 2357198848, > "index": 9, > "name": "da0p9", > "type": "freebsd-ufs", > "label": "PBaseUFS", > "rawtype": "516e7cb6-6ecf-11d6-8ff8-00022d09712b", > "size": 541854500 > }, > { > "start": 2894069760, > "sectors": 36207375, > "free": true, > "size": 0 > } > ] > }Segmentation fault (core dumped) > > # gpart show > =3D> 34 1000215149 nda0 GPT (2)(null) > 34 2014 - free - (2) > 2048 532480 1 efi (517M) > 534528 32768 2 ms-reserved (517M) > 567296 997287936 3 ms-basic-data (517M) > 997855232 2359296 4 ms-recovery (517M) > 1000214528 655 - free - (2) > > =3D> 34 2930277101 da0 GPT (0)(null) > 34 32734 - free - (0) > 32768 501760 1 efi (517M) > 534528 20971520 2 freebsd-swap (517M) > 21506048 29360128 3 freebsd-swap (517M) > 50866176 33554432 4 freebsd-swap (517M) > 84420608 67108864 5 freebsd-swap (517M) > 151529472 96468992 6 freebsd-swap (517M) > 247998464 268435456 7 freebsd-swap (517M) > 516433920 7340032 8 freebsd-swap (517M) > 523773952 13096960 - free - (0) > 536870912 2357198848 9 freebsd-ufs (517M) > 2894069760 36207375 - free - (0) > > Segmentation fault (core dumped) > > From an aarch64 context instead pf the armv7 chroot: > > # gpart show > you have mail > =3D> 34 1000215149 nda0 GPT (477G) > 34 2014 - free - (1007K) > 2048 532480 1 efi (260M) > 534528 32768 2 ms-reserved (16M) > 567296 997287936 3 ms-basic-data (476G) > 997855232 2359296 4 ms-recovery (1G) > 1000214528 655 - free - (328K) > > =3D> 34 2930277101 da0 GPT (1T) > 34 32734 - free - (16M) > 32768 501760 1 efi (245M) > 534528 20971520 2 freebsd-swap (10G) > 21506048 29360128 3 freebsd-swap (14G) > 50866176 33554432 4 freebsd-swap (16G) > 84420608 67108864 5 freebsd-swap (32G) > 151529472 96468992 6 freebsd-swap (46G) > 247998464 268435456 7 freebsd-swap (128G) > 516433920 7340032 8 freebsd-swap (4G) > 523773952 13096960 - free - (6G) > 536870912 2357198848 9 freebsd-ufs (1T) > 2894069760 36207375 - free - (17G) > > Here is a "diff -u" of the libxo:JP outputs: > > # diff -u gpart_show_armv7_failure_libxo_jp.txt gpart_show_aarch64_good_l= ibxo_jp.txt > --- gpart_show_armv7_failure_libxo_jp.txt 2025-12-28 10:27:57.98555= 8000 -0800 > +++ gpart_show_aarch64_good_libxo_jp.txt 2025-12-28 10:28:41.45696= 8000 -0800 > @@ -7,14 +7,14 @@ > "sectors": 1000215149, > "name": "nda0", > "scheme": "GPT", > - "size": 2, > - "state": "(null)", > + "size": 512110190592, > + "state": "", > "partitions": [ > { > "start": 34, > "sectors": 2014, > "free": true, > - "size": 2 > + "size": 1031168 > }, > { > "start": 2048, > @@ -24,7 +24,7 @@ > "type": "efi", > "label": "EFI system partition", > "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", > - "size": 541854500 > + "size": 272629760 > }, > { > "start": 534528, > @@ -34,7 +34,7 @@ > "type": "ms-reserved", > "label": "Microsoft reserved partition", > "rawtype": "e3c9e316-0b5c-4db8-817d-f92df00215ae", > - "size": 541854500 > + "size": 16777216 > }, > { > "start": 567296, > @@ -44,7 +44,7 @@ > "type": "ms-basic-data", > "label": "Basic data partition", > "rawtype": "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7", > - "size": 541854500 > + "size": 510611423232 > }, > { > "start": 997855232, > @@ -54,13 +54,13 @@ > "type": "ms-recovery", > "label": "(null)", > "rawtype": "de94bba4-06d1-4d40-a16a-bfd50179d6ac", > - "size": 541854500 > + "size": 1207959552 > }, > { > "start": 1000214528, > "sectors": 655, > "free": true, > - "size": 2 > + "size": 335360 > } > ] > }, > @@ -69,14 +69,14 @@ > "sectors": 2930277101, > "name": "da0", > "scheme": "GPT", > - "size": 0, > - "state": "(null)", > + "size": 1500301910016, > + "state": "", > "partitions": [ > { > "start": 34, > "sectors": 32734, > "free": true, > - "size": 0 > + "size": 16759808 > }, > { > "start": 32768, > @@ -86,7 +86,7 @@ > "type": "efi", > "label": "PBaseEFI", > "rawtype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b", > - "size": 541854500 > + "size": 256901120 > }, > { > "start": 534528, > @@ -96,7 +96,7 @@ > "type": "freebsd-swap", > "label": "PBaseSwp10", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 10737418240 > }, > { > "start": 21506048, > @@ -106,7 +106,7 @@ > "type": "freebsd-swap", > "label": "PBaseSwp14", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 15032385536 > }, > { > "start": 50866176, > @@ -116,12 +116,17 @@ > "type": "freebsd-swap", > "label": "PBaseSwp16", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 17179869184 > }, > + { > + "start": 84420608, > + "sectors": 67108864, > - "size": 541854500 > + "size": 34359738368 > }, > { > "start": 151529472, > @@ -131,7 +136,7 @@ > "type": "freebsd-swap", > "label": "PBaseSwp46", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 49392123904 > }, > { > "start": 247998464, > @@ -141,7 +146,7 @@ > "type": "freebsd-swap", > "label": "PBaseSwp128", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 137438953472 > }, > { > "start": 516433920, > @@ -151,13 +156,13 @@ > "type": "freebsd-swap", > "label": "PBaseSwp3p5", > "rawtype": "516e7cb5-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 3758096384 > }, > { > "start": 523773952, > "sectors": 13096960, > "free": true, > - "size": 0 > + "size": 6705643520 > }, > { > "start": 536870912, > @@ -167,13 +172,16 @@ > "type": "freebsd-ufs", > "label": "PBaseUFS", > "rawtype": "516e7cb6-6ecf-11d6-8ff8-00022d09712b", > - "size": 541854500 > + "size": 1206885810176 > }, > { > "start": 2894069760, > "sectors": 36207375, > "free": true, > - "size": 0 > + "size": 18538176000 > } > ] > - }Segmentation fault (core dumped) > + } > + ] > +} > + > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > From nobody Sun Dec 28 21:23:08 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 4dfXQW17Vsz6MNr9 for ; Sun, 28 Dec 2025 21:23:31 +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 4dfXQV3cpWz3Bmf for ; Sun, 28 Dec 2025 21:23:30 +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=1766957002; bh=RL92I7O1P3G1NvBmfvTTkAkWkEySGVAk8ptclQna9C8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KiRIeVPrjAYEoarH1q+l6oHGgw5C+FPklU3XTWQYgpmW5ZwLyoNMYXAgx3O8M8yPOSBJrrGmAnd/vA+qLvDnZYmG9S35+O8dKR6VA3ydtoy+1PyPqL2yzwrUFeYp/Mgd/c4uz96v0Y54jH3KVg95Xjj5/foecaI7/4XUKTW9E5hFP9CFvqoI4m6i+jraVWmWAQI2G2iU+6itTKSI2eFk+CxonDkLtSFEFCYE0uZteDXJt1sHGGg8LVzHuCuGfrSommTxu4j+aOOdPMmwlJn7OXO2uVaPwwSsCc9g6+aPcZ1XJUqtTu7EpAEvYNL/clGiDsvRYR7FwC8YlIpchMmtTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766957002; bh=t5jjl9HWjVX3Ot+fQLBRsoLy+NztE+4MlCwNUWH2AXT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N/yx1CXO21uZqp+tFV3b26zhnSYChv6K6uisxfwtCkJfUnrU7BbiDvTHVE246tkQRbU+dmnwdncqG992YvrTOKKNLOagnohmMmpxjUA7Ba7lLtQSfKApp3LLi6aiIIBcwzETyTleUznTyoo4NzAWOTzEuRmBjy9UO9JrNxhYoydZptDSG65yqJtEAXV/GNjzkaWXZ9O3xjppdhn2E8F/o5YWP3XyrvY5e99+w4e9jeijXUvppd7n48Tsd9wstC0i7zWHPBxndMcBXb0vo3wFd913brDE5x3jSQEPhssmVRsfBJe1k3t3Yh+engH/4czFM5nVuYI/PLtLLMagc88Bsw== X-YMail-OSG: fdxzU9UVM1k_I.MnLD1m6mBFnnJ2fJpLkBLwnbAwP1QAZzGTUJoN8WCIyImqwz3 DL0iBPbI6QvKBsDfLQ2lEtj2kgvDqY_3tLpaAl1Z2wRkfeFnJSkH86A5WrHIqiUHbHHSLasPnfAR Zth3pV3teP6jIMMNga7o2Z0wz_kC5xYKsjGgHT.5AbzfALz8hU7Rv7J.fn2XViNZJ6qbPn8g2kc8 7B4tebpBJZXOZ.U8wpR6klJJUr7BrQBruS1Hva1xAfSwrVMMVXcLpmkwSuQJsmNF4cRSK8NjPON1 xl1G08dO5WKJBvchFCQMfamsTHxGW2oGo0FwREzH5u1sKzdvBhw_9Z3UzYSLTVID1GgZ8xHLG4Lg vwDn.S_qQcAGDvOURYmf9X8aiHWMCV6m6lPcx.CPIC2LBu1ez9tljnmaIMB5DAIQti6yb6xK.GL3 WpoLIN7AFt37K2pq5lkjmsTAO3ieOvSrYjovh3pKM9YfkxofVG4uU8BxzQsTlPlMqqc76ZQ7.bmA _kBwKe7mNmZu.K_8W6c1eHK9cMDJsDmf_wa0duqyliy0tpxULILRP8yQb9LrqtfJ5_NYDsVbBkAw 2BS4gjEMN3zANLetQkTGs7YTruo.oFUFCDFEqNJFnlJSh24bYnGKgwrDysDxo2rpKJNoFik7CRgx ltqVs4Vj2cHXVoYt5Hctw3Mfbac3PPvCm8xgTfoH21alkbociFeHEXAksjul0Kr0iFBXkLnCJpZa gPpe_MAW3eK2hMyuGXRGnjeYKTUb15MxPCeVveOXq8cjquX7lgxpWXimR2n60wxpFvewcD.itip8 ojK3dgL_InR5RromR.7GsGnRsGuddW2C6QKx6NGKP9V.6DWXG819XHOie8zQpgVxzjQao4bduWvI _DlNihjVkqzWUMOqO2RkLG7fUHKYtljBBbb8lMqCZPSSRnrhquQB17Bs_PFvUgTzLzmv3O__GJJp aiNB1DlwxJDmrvcSBhuXZiAcQRXu1kOOJJozhINdPic7zkYrzCdtAlK5nPNu5WQ65KO3S9QyXUVx 0rOxprZBr_6v4fIwSSSfZD5eQKwiUwvOf_mJ94c1HdTE3N5MSl06SLMb4RCi7YE0PjptaYarWtJg PjMtZQfmHK5PlXhpHq.YZhIOvA0bLu8Lku8wbIRpDfxpBqqFLO5K_zPp5zDW93MGYCY.U9pc6k5i e9ZFXIR5n49LnPj14LnMyEYhCvh..Z_YEfFeSvrCY64oysJC09jCeaPptTguxZSRcgKmCbJIVTlD 51UadZfHFdp_w8IOc.MwRI6c3lmwCx7ZLGHXc_8tLwsq.TQHU37qM8Z0ypBjfOkIMLPIiXEbU0DT 5SxG56SLX.mqKFDZdMMLQXGt7xwTNzuC5hjj57T2ThfKcJTMRAohgpES_wpi9B9XyZW3U8aTixbi hMWCZe.Cs3CR2W0GQxO0wwTMcuYP3h1sYAcOajpovE6208pDDp8xLaUmgYKAedQbZaUG9xlB7w0V BNxSUJyDnqhBS1oONGn5fD0t07Z0V1wdL9dBuR5HCh_m892tOn4qbHA_JawWWIMfU2WyAIGFCsL_ 4IgHXFXvg4AdzCrBwbU88frM8DnLDP7N8wdIpFaEzbdSp1hObCRgLYyl4M6twkgxE.cODJLuSd6y zBe6OQiwf4n5ABhrGX.6vAYfidThAL3eT1zc8OWdvEXOhi.Y6YaOcoMKM0g4oi1taW.sC.O9hxZL 97JucRLT5_nAjr0WVqeDXpLHtkl.0RQl.KNL76_zmJD.hRHhQ7VX6b1pqRUeBJJZLzXrOXsUr2.7 qLPwUcdpDMLhLFISBcsi3Om1w5.1VVuSWn.5tUapnk3.n8loHbwu5ItFDaANXRwHNgwR1Z7ofmao cAwRUK2VQZwcr9dgUUKQw96va6B805.B6zAbuEYdKC4n6o0fs5D4xy85tgeO4A2EWZvJlw1jyG6Y sKvJyDHGcW6xW2if8AZE6kHgCOF5Rl7_EMkAGX92EyoU1As95wlTL5mpyFFnzLs76KcbvozsL6wU 4u0iYWTsym0qU3BNjJFzfYO2_iCaTCmIW_MLyWeof.zPWYN4MkqrSy_lYramtnJpV5ooQsFxyYPG .Dq0A6FI95kjotSFZFz4XLkjKfkUQ6j1D3CYJmjs.ZgymI6Ir6AzoFdopEUlY4KvTwNXsgPak2lw cth60euQYl1kA6p_4VxGb.A00cBDrA7eu7mfFJTY7JnMZOrQO9Q_xTOzNZE2ftIsyJBYySLySTyI 7YEHOtJWjvXgGNQJthSRMW127ryaD6Rh2Hq12bgqBpb3ZW7Z_mCF0ax3Mzxj1xb4AeJGLpIGcdg_ R4dVB8X0- X-Sonic-MF: X-Sonic-ID: 45727c13-168e-4ce1-b38e-32203ff0d2fd Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 21:23:22 +0000 Received: by hermes--production-gq1-54bf57fc64-hpmbd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7ab55f53414d8bc71e0475560574aa06; Sun, 28 Dec 2025 21:23: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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) From: Mark Millard In-Reply-To: Date: Sun, 28 Dec 2025 13:23:08 -0800 Cc: js@freebsd.org, FreeBSD Current , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <2DDE6192-97E6-45A0-A119-6E25D9995C78@yahoo.com> References: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> To: Alan Somers X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dfXQV3cpWz3Bmf On Dec 28, 2025, at 11:16, Alan Somers wrote: > The output of "kern.geom.confxml" would also be useful. Also, I > suggest that we move this discussion into Bugzilla. > . . . I've submitted to bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292008 It has attachments for "sysctl kern.geom.confxml" output for both the native armv7/Cortex-A7 environment and an example for the armv7 chroot on aarch64 environment, among other things. === Mark Millard marklmi at yahoo.com From nobody Sun Dec 28 22:54:10 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 4dfZRZ44snz6MTdH for ; Sun, 28 Dec 2025 22:54:34 +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 4dfZRY5LWCz3KBR for ; Sun, 28 Dec 2025 22:54:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NauLVPHB; 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=1766962465; bh=/hxlaa5vOk8ZHf3jM1qIEK84oQT2AVBnZK5ISvNmSKc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NauLVPHBS/2Zkv4+JH6GSDcbzLLxs8LoxgHNGB18M1AUp/xclh3DEnxO0zw9NNZR6heD5BEeEwNSA9AFIy/98SRtU2MIQMptksnWyfjECpE4P/QZx0SmEFvqCBTebf/vv4hL5tYNPZrYNtcwjfW9JKoM08q27zqV3OdLCCqujTnKTrXbKC6L8h6qvznNNz6vB1zFHghtT7iZOYNDYKMCNFRKhwHjFCXibgPZA73cqU+h/5JOc+qbafP685ayRG10k6TDO4/btcxtolhWVFctm9heK1/+ps0vlRMJABS7VH/7++VF5nr+tfwCiLOqJFIGivlWDukBSEIKHJLNQqiZgA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766962465; bh=9DnDF2mAS6/4AOOqYo6Tpi+7b7SJGz6Cpf5DmflADdu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=J37dQLLnZp+8Jpcvbhr+Q4ywJd6agyvq2I13rOkWwI9p9JY+6izHj/JaJ7RXajkNDvddoHqhgBvEfABWtreEt2ilwoomU1MAUiFPTOnqSStBS5GJpSQHiXAkm4YXLIOGyQLDM4o26mLMQgTV2L2qdwXTb8LV1LYGqtaZC6G+i2gt7KH22xcnNAGV+PYxtpqlEoPlW0hRDyuVDVbRlarnK5qozllUBUG66UUS/1WAIJobKLtgVu3JuW6BApbLCI1vUvG4O6Yvx3ZAE977yLn2jGMYsFy1xImGJ6Fu4Q/OkcrrHfUfMuP2yVUi7EiPjp2/v4eyq5A2E7QaK4Z4QfINtw== X-YMail-OSG: nCnt9OMVM1lU0xY6Hg1dx4EwEIR3Nrafah0G4AdfpMELbDrruiYQIgh75txRdFS AId08r.UhYX4ueVvX4ujlVRqOxIr.dB4NaM2hW4s359scH2bHXVo6q2ct515tVx3yO23p5n9ErYI pGRq6.a.e6l9C3jSCniY65tnNYsvppBA_lWqXQ1t9BdQ5Xe7e_vqlqO4JfLsCzzVAtSEYstg8F0m 6Sj9.uCqXSzfXRrlemVXyVspiNOyghYxB2kyn67HF6pEyuXiodRDwICyBxV1IVi.Ay_IKHVVR66j PmUmlUiLh7kgKZFZ1Xnib9RTgIA0bORTafRhd1i7HLHxkrgAvDQb8i_wTYRyANZomMko7C.zPPV8 W4Ol.YDUc3GxKmoMcTjTRAt84AzF8ZXEvQ8HihQ9_VD.7JZMYX3mxIVPVVRhGEySFS0HLTs_rNlQ FzQDyuj6gy97ZDLssu4os7lUu4wF.1Frnl4XM4vT.VDmOMDYRHlr8aIgCUKx8TQ19krsajGJ_EEC eLvKK3ZwjFiKpyaQBZFI47OJQ4r92L6JbW4npp57OZh1hBqUI4GzfzhmMX69HbTg1uBgIyha3Zcv FbJve0NHCqav.R5NgF4ckkxt1NFkQ7BndgzHmigAaKjn0FFWiXVcTmYeMk6VjNwchbZ2HQrpCaFg a4OE5lRt2u2gCGBRBlXx_DIePSACmD1UQTPq_IQzxJKefnVqcM9GWorwmJ99Z3kVrs6xjMmdNceU X7n.Dt17galRqoaOxpNxoyeOWF4B2Gs1D1PyiNtPvRcztuhOuat91r5UcWkoRSCIWZNcgdcTnzxy 5KEHhNtpXzI64q_c1lDx861luzDkmisWAXrYDL7DXbGXs50qNJ8XLjaMefBYRxCjgtEUin0OEqVg xgKoJ7GtAyGP4BXJVq6yFG2hFejImDgTTIsd78cfr9eWlRGLtUfwBX2pOkRfrmgwHqFsjW4Vi2Rs _E3aE5mA0SyMLC1mScUhzXq_AtyUyyrgG7ttx97_5bSOXg3gbNWD8IM9a3RvkpBESDU57fUVhN6_ o_KSTUNak3qCHrt1GqA5IEHB8N00eLHpqVwoSOhF0p5.etT1RVVahDfRrDf6yChYGIXlX1fu.sgo tbquD.vdUAJrWcVC7wv6mzJ4KfxonWNrUC1tzEFxU4rOVO3bALy.P1WYlS4cQkHFwlJSAopHee.i SCPW2iOtJGq9QHl4JAhauAPNr0wu4RwOPHTFUHmyEGDC13ee4GuOvut.ItZCl1u0cxVassI0BQZI 5YtBlxOM7whsFftdIUvdgxp3xFYitfo3kPw6PyWfrFNIGLiiIVtAFC1soHXothgHz80hT_nFJPTl Rfywn1xy3I1iDQT82w6hLr08OaIIp.BMzDcsvkJxdc647ufu9PYKF0zQxw89RTWCcoChSxUD.Gax VnO1CP2OLozd3lav_jP7rQs8E6R4buqO7xV_I5nkPoEaxkObV7IZFriX8QNK2UU3Yd0siyazCfB3 St0BenATl58qoyhLe_c1OAjgbAKlqonyOhQ00_YGcVGq540Lu2rOFrfge_S363we8tTm4yd1dhei 2cj2N2UwyeZ3AOoOdWmVDSDNtX4VHqEVE9MZtYXM.hzbt9RYpnSESbL_vOQgwXpWBdyOLZB9_SCU qbaIpJLiEyDJ2Iv9515B5ctc2_kcg8puuc.vZTjgMifIoQmUiBQxY.54864NXE3QOmpH_VYDQFyg n6Mr5piaqXplj7LoMocRGr3kL3WZkS55ZbFqGMRKjOiS8w7pxaLApPaFnIpzf7LuAOg1XEvaUt3_ GknMCivJe1v1UZkS9lS.ZY4baOs9MRZDJ.q5nxaGrloT1sngmHRAvdYexsAAshrgvvcQ7RmsHC4y g7XGyHzMDxakCTXCJsaX.WI_UdLF.D0EYMpBRjD1lBLRADULS9VDgFg9lKYAPjpwWHcbd9K9fbtS rdQLK_P.KSocR_53wXRIswCz2WvUrR7N4DR7MBK7vgrNNktbOLYxtJQU6qGDJ1oJf7HYIy7wzg3E EmMNzhIbqAgsEKxeTVR4BQ7bHSgKIiAX7f_UQzjnlkOI9.uttXvVunGQerLGL8q6IehzUM5lT.cD VMFXV2OlnQ4HczzCpq3dTnYm14iDX3pvFqjWK1HYjQvRUhspCyygxaoMJaTHQ192Iy1RBB8K0dN0 ajyRIHVzpjdILmNnk7MJhP0jYNYIjTIty5sSiaoGLGj8ri8hck3Acanx7GPnPdJMzUcZVD4eaXiv rLYq_DD2PxM4PAshWm8Tizt66OFzqUeguKDj7fdO26AKe8A7qt1X9UIb_8dF5aEl2jmCWshAD2y5 cKCJC2w-- X-Sonic-MF: X-Sonic-ID: 02a38d3d-0de2-48a5-ba8c-db463964da2f Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Dec 2025 22:54:25 +0000 Received: by hermes--production-gq1-54bf57fc64-fqp47 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c3511808342bdf21b9c4fa617f766f5b; Sun, 28 Dec 2025 22:54:21 +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 \(3826.700.81\)) Subject: Re: armv7 main's gpart [show]: signal 11 core dump during boot, before login; xo_format_string_direct; official pkgbase distribution (kernel and world) From: Mark Millard In-Reply-To: <2DDE6192-97E6-45A0-A119-6E25D9995C78@yahoo.com> Date: Sun, 28 Dec 2025 14:54:10 -0800 Cc: Alan Somers , FreeBSD Current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <29D0FAE4-7E72-420C-9E18-808DEAD16F72@yahoo.com> References: <1B16024B-5AEC-4F75-BAC5-C6936208082F@yahoo.com> <2DDE6192-97E6-45A0-A119-6E25D9995C78@yahoo.com> To: js@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.54 / 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.46)[0.456]; 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)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.66.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4dfZRY5LWCz3KBR I've found a problem: use of %ld notation which is not an invariant match to off_t and the like across FreeBSD platforms: off_t is 64 bits across FreeBSD platoforms but long is not (and so %ld is not): + xo_emit("=3D>{t:start/%*jd} {t:sectors/%*jd} {t:name/%*s} {:scheme} = ({h:size/%ld}){t:state}\n", . . . + xo_emit(" {t:start/%*jd} {t:sectors/%*jd} {P:/%*s} {ne:free}- free - = ({h:size/%ld})\n", . . .=20 + xo_emit(" ({h:size/%ld})\n", pp->lg_mediasize); . . . + xo_emit(" {t:start/%*jd} {t:sectors/%*jd} {P:/%*s} {ne:free}- free - = ({h:size/%ld})\n", %ld is for long but: . . . Architecture long void * long double time_t aarch64 8 8 16 8 aarch64c 8 16 16 8 amd64 8 8 16 8 armv7 4 4 8 8 i386 4 4 12 4 . . . The code would be broken in this way for i386 as well. =3D=3D=3D Mark Millard marklmi at yahoo.com