From nobody Mon Feb 17 14:47:27 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 4YxQVn0j04z5nk5H for ; Mon, 17 Feb 2025 14:47:45 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (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 4YxQVk5bk7z47hl for ; Mon, 17 Feb 2025 14:47:42 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=MxcRLTOL; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::112c) smtp.mailfrom=tomek@cedro.info Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-6f972c031efso45328487b3.1 for ; Mon, 17 Feb 2025 06:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1739803661; x=1740408461; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=iZ7dcdr5KRC512qdkHSCv2eNyo/UHohZd8Rkjojl61Y=; b=MxcRLTOL8wzhZi5kRSPogAYO+1dHF7XoyB7xXIQuPCVQA/gyx3tNxlaDlXG+yhId6J awQ2B0IuUTP6ezns9oG+lmFujRohmfd4qlxD8Pjk820jJACyP3QWk4hTdp9CI4h2Tpuh ggSVnB6n1hTmr9WlABffVIxnS+CfiDqmZegZKu6pFMKbXTDXifVEFkVV868OTJjr6Go7 FewtvEv1B17Zu/don4QPcKRvCx8mE2IznXuzgqZU3/hNZBq0BBLiF0FIMn360yz1dFMt ymTRQRk8imzWRHj7XJhXZJDep89Slx02V6DDKodf7HLAkVhZCdWX5IBIqb5z+4JCaVXm r/PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739803661; x=1740408461; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iZ7dcdr5KRC512qdkHSCv2eNyo/UHohZd8Rkjojl61Y=; b=kZPvhYzE05PprHY+HILUxoeMNHkabA47q76tESDC9o4n9lTqGQBcWu9M6y4YfQn9Kv oMmGJN9YqhKl+LDK8578SV4QimtkG2doqCvfzl18vyng7ugUhlVvmbssWDpSKuGY6WVE wYVTAypfYiJKclrxjtNah3qzb6TPCK6BxloSPghb3YsSkgNWMNKIWfRmGf9D2tn2lCCO Wty5Ig2iPlRLUkOJColv6cjmx4wYheGyrZgSz9kkSJAQRlr+aJTRZqLyM/HyN0pgQSm3 OKoejBwjNUd0dx0qFMgVNSZnvWqidHena7z/Eevs2jx/7/pcrh4jsjf/h8V9ZqqBselq KDTA== X-Forwarded-Encrypted: i=1; AJvYcCW4Mv8RB0lvDRNpC4BfVR8FgyN8dwVqQ7wZDJMidlmEaldKjkdb4ezTlSaVn6nT5gdvcxW0wTov8XnJAu3urXw=@freebsd.org X-Gm-Message-State: AOJu0Yz/bLjJ8rLnwO3OVH6ahHDGZ5FX5WLBuUumqm9938IqE3cS+jfz jtB7xd1+79Ghkg/YTdhYLJCifCzSAr+UVmPdZTdcf11pG6q2s8wm04MxENCH5w== X-Gm-Gg: ASbGncuogJ1+8tSYgO0wJ2n3ceFJIog/SWt7RG9PRmkInAzB6VcWiWck75AKWo3cypk kCaAMC/eudXc1e6ZsplWmHU5/f3eXPkgJy80x/KCMsx8HqL2477H5ELTzjvhluRS/e7prNdwC82 EaIVcEZiEuTfTUqNsZSVDfMwV6CrHYrBQSF1/J5aiG4NUgNJKylUq1s2OJ9lZjd69QIxsgBlP2D L6afF5glD2Ln/uV7w+BUMEMKYNr4qFo9wBTVns4TuD8cPBHPftWn7klsPTd12kUQy0gWzBKHx3Q s49xL+SM0xcDJlVII78GYqUS9TCImrTteepwqjPOSIMvjSl9PdWV X-Google-Smtp-Source: AGHT+IG0bKr1hAZwx7qba3VMBPIp7bdR/MSoolCfEH842CveLjyZEgNaEKJzt/+wnHRwsvNO3sIrWg== X-Received: by 2002:a05:690c:6f03:b0:6fb:5d74:959d with SMTP id 00721157ae682-6fb5d74a0f8mr63017137b3.1.1739803660863; Mon, 17 Feb 2025 06:47:40 -0800 (PST) Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com. [209.85.128.177]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6fb3609fa86sm21100407b3.60.2025.02.17.06.47.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2025 06:47:40 -0800 (PST) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-6f768e9be1aso44055647b3.0; Mon, 17 Feb 2025 06:47:40 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVjbNG6x//uJx4vK3LD6AhWALJM65Gzj3qMoDF/rLDdpJx/WQEF8PKy6M06YkLjmvcYvsvTXC5nuA==@freebsd.org, AJvYcCXydCveY6/iMnaq9HlMe9ifE87yeTo1jfoKUrePdI0HnToiSYwbONBSIlENwEUI2L+Yvc07GIdbAbvYdeVG4xE3Ug==@freebsd.org, AJvYcCXzVvUGYkMe6lxE/jGGuLWB0GzLYlKup7gBxlSUKbq7n2fehONNDKHeCJPFpxDhJ9PTe30fnSD3EGbJseQixuc=@freebsd.org X-Received: by 2002:a05:6902:10cb:b0:e5b:33c2:5a03 with SMTP id 3f1490d57ef6-e5daa4a56fdmr14360004276.9.1739803659634; Mon, 17 Feb 2025 06:47:39 -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 From: Tomek CEDRO Date: Mon, 17 Feb 2025 15:47:27 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZltebXDvb3Uq9_xZ6i-18SgCcA8enslud0fLRfNZ9Hc1EZjwzr9wIAD1wQ Message-ID: Subject: real world hardware testing ci To: freebsd-questions , freebsd-hackers , FreeBSD Current , freebsd-security Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112c:from,209.85.128.177:received]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; 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)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[cedro.info]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4YxQVk5bk7z47hl X-Spamd-Bar: --- Hello world :-) Sorry for cross posting but I just need short quick info :-) I am writing a paper and designing distributed real world hardware build and runtime verification for NuttX RTOS, kinda in-house what you have CI automation to complement build only CI. There are over 15 different supported architectures on 340 different boards and around 1500 different existing configurations at this point so changing one thing may impact others. Recently it turned out not only changing one place impacts others in build but also runtime validation needs better tools as qemu did not reveal real world hardware problems (i.e. registers alignment). I am using FreeBSD as the build host. Did setup laptop and rpi-0-2W as the test node workers for the prototype. For the paper I am searching for references and current state of the art in similar solutions. I know FreeBSD is CI tested on VM/QEmu. But question is do we have this kind of real world hardware testing in place? :-) Also hints / references on how to setup one-time-use Jails per build and runtime process that would execute untrusted code and scripts are welcome. I know Ports prohibits connectivity after fetch phase.. unfortunately in NuttX some components are fetched during build right now and we are searching for some solutions :-P Any hints appreciated :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Tue Feb 18 08:38:30 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 4YxtGT2FdQz5pFTs for ; Tue, 18 Feb 2025 08:38:41 +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 4YxtGR4BYPz3jrQ for ; Tue, 18 Feb 2025 08:38:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk 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 CFE2289287 for ; Tue, 18 Feb 2025 08:38:30 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 51I8cUSF020035; Tue, 18 Feb 2025 08:38:30 GMT (envelope-from phk) Message-Id: <202502180838.51I8cUSF020035@critter.freebsd.dk> To: current@freebsd.org Subject: Two issues with 571df2c64a3c1a From: Poul-Henning Kamp 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: <20033.1739867910.1@critter.freebsd.dk> Date: Tue, 18 Feb 2025 08:38:30 +0000 X-Spamd-Result: default: False [-2.67 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.67)[-0.669]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[phk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4YxtGR4BYPz3jrQ X-Spamd-Bar: -- I'm running -current on my primary laptop (T14sG2Intel), which cramps my style when it comes to getting to the bottom of these two issues. 1. Panic when TB3 dock is unplugged. uhub0: detached ugen1.1: <(0x1b73) XHCI root HUB> at usbus1 (disconnected) Fatal trap 9: general protection fault [...] calltrap --- trap 0x9 device_printf() usb_detach_device()+0xd3 usb_unconfigure()+0x83 [...] This used to work just fine. I'll try to get better diagnostics when I can reboot at leisure. 2. Program does not do what it (probably) should My simulation of the Rational R1000 computer reproducibly fails in "impossible" ways when I run it on my laptop, but works fine everywhere else, including 14.2 in a VM. I have not seen this failure prior to updating world+kernel, but that may merely be accidental. -- 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 Feb 18 11:31: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 4Yxy6Y1W95z5nS9T for ; Tue, 18 Feb 2025 11:32:05 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-10626.protonmail.ch (mail-10626.protonmail.ch [79.135.106.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yxy6X0VNnz46mP for ; Tue, 18 Feb 2025 11:32:04 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=ufrh1j1D; dmarc=none; spf=pass (mx1.freebsd.org: domain of sgharms@stevengharms.com designates 79.135.106.26 as permitted sender) smtp.mailfrom=sgharms@stevengharms.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1739878321; x=1740137521; bh=JAsOkObu5Sv8Jt2O47uP2UZZ85bQwSkqSASB9L/f5W4=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=ufrh1j1Dn+ippmnxbtaB+dExO5CqMfqL1DfqHGrW8ndAkMG2eDe/vjEUz+Hzv+Usq mLGVHkyfzj+KBr879a1eik09p6TpUNGCi04quT0oqKz2TwC4EPWncR0P2lH2eVfjMK MzLcLzsEXotzKeQMHqlL+l2+bKjM5ccHT46y6/OM= Date: Tue, 18 Feb 2025 11:31:56 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: Quieter startup + working experience by overriding VT_CONSWINDOW (and consequences) Message-ID: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: 9453bacf4a3304c829659515b2f0c3aaa72f4a7d List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_w9oqYMJP9qnwLwCH4CI0ioXR650EvPIZpD8sQ" X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RBL_SENDERSCORE_REPUT_9(-1.00)[79.135.106.26:from]; NEURAL_HAM_SHORT(-0.98)[-0.979]; R_DKIM_ALLOW(-0.20)[stevengharms.com:s=protonmail]; R_SPF_ALLOW(-0.20)[+ip4:79.135.106.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; RWL_MAILSPIKE_GOOD(-0.10)[79.135.106.26:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[stevengharms.com]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[79.135.106.26:from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4Yxy6X0VNnz46mP X-Spamd-Bar: --- --b1=_w9oqYMJP9qnwLwCH4CI0ioXR650EvPIZpD8sQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R3JlZXRpbmdzLAoKQXMgcGVyIHByZXZpb3VzIHRocmVhZCwgSSBhbSBzdGlsbCBpbnRlcmVzdGVk IGluIGEgcXVpZXRlciBmYnNkIGV4cGVyaWVuY2U6IGlkZWFsbHkgbm8ga2VybmVsIC8gcmMgb3V0 cHV0IG9uIHN0YXJ0dXAgYW5kIG5vIGNvbnNvbGUgbWVzc2FnZXMgb24gZGVmYXVsdCBUVFkgYWZ0 ZXIgbG9naW4uCgpBcyBJIHdhcyB0cnlpbmcgdG8gc2VlIGlmIEkgY291bGQgZXh0ZW5kIGJvb3Rf bXV0ZSwgSSBjYW1lIGFjcm9zcyBhbm90aGVyIGFwcHJvYWNoOgoKLSBzZXQgdGhlIGRlZmF1bHQg Y29uc29sZSB0byBub3QtemVybyAoZS5nLiA0KQoKLSBCdXQgdGhlbiB0aGUgZGVmYXVsdCBsb2dp biBwcm9tcHQgd2FzIGFsc28gdHR5djQuIFNvIEkuLi4uCi0gQWRkZWQgYSBrZXJuZWwgb3B0aW9u IHdoZXJlYnkgdG8gc3BlY2lmeSB3aGljaCBWVCB0aGUgc3RhcnRpbmcgb25lIChpbnN0ZWFkIG9m IGZvbGxvd2luZyB0byBlLmcuIDQpLgoKLSAoc3VwcG9ydGluZyBjb2RlIHRvIG1ha2UgYWxsIHRo YXQgd29yaykKLSBQYWlyIHdpdGggdGhlIHN0YXR1cyBxdW8gYm9vdF9tdXRlLCB5b3UgZ2V0IGEg cmVtYXJrYWJseSBxdWlldCBib290IHVwLiBMb2dvLCBibGFjayBzY3JlZW4gKGFzIHlvdXIgZ2V0 dHkgc2Vzc2lvbiB3YWl0cyksIHByb21wdC4KCk1lYSBDdWxwYTogSSdtIHdhYWFhYXl5eSBvdXQg b2YgbXkgZGVwdGggb24gdGhlIGtlcm5lbCBoYWNraW5nIHBpZWNlIChqdXN0IGVub3VnaCBDIHRv IGJlIGRhbmdlcm91cykuIENvbnNpZGVyIHRoZXNlIHNrZXRjaGVzLiBodHRwczovL2dpdGh1Yi5j b20vZnJlZWJzZC9mcmVlYnNkLXNyYy9wdWxsLzE2MDAKClRoZSBzdWdnZXN0aW9uIHNlcGFyYXRl cyAiV2hpY2ggVlQgZ2V0cyB0aGUgY29uc29sZSIgYW5kICJXaGljaCBWVCBpcyB0aGUgc3RhcnRp bmcgVlQuIiBUaGVzZSB0d28gcm9sZXMgYXJlIGNvbmZsYXRlZCBhbmQgbXkgc2tldGNoIHVud2lu ZHMgdGhhdC4gSGVyZWJ5IG9uZSBnZXRzOgoKLSBhIG5pY2UgcXVpZXQgYm9vdCB1cAotIGEgZGVm YXVsdCBsb2dpbiBzY3JlZW4gd2hvc2Ugdmkgc2Vzc2lvbiBpc24ndCBpbnRlcnJ1cHRlZCAoYnkg ZGVmYXVsdCkgd2l0aCBub2lzZSBmcm9tIHlvdXIgd2lmaWNhcmQgKGlmIHlvdSdyZSBvbiBsYXB0 b3AgZmJzZCkgLS0gZnJpZ2h0ZW5pbmcvYW5ub3lpbmcgdG8gc29tZQoKLSBhIGRlZGljYXRlZCBs aXZlIHNpbmsgZm9yIGNvbnNvbGUgbWVzc2FnZXMgKHZlcnN1cyBhIGxvZyBmaWxlIG9yIHZlcnN1 cyB5b3VyIHZpIHNlc3Npb24pIGNsb3NlciB0byBhIHJlYWwgc2VyaWFsIGNvbnNvbGUgb3IgT1NY J3MgY29uc29sZS5hcHAKCklzIHRoaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdnMgZXh0ZW5kaW5nIGJv b3RfbXV0ZSdzIHJ1bj8gT3IgaWYgdGhpcyBpcyB3cm9uZy1oZWFkZWQgSSdsbCBnbyBiYWNrIHRv IHByZXZpb3VzIHBhdGhzIG9mIGlucXVpcnkuCgpTdGV2ZW4KCi0tLQoKUHVibGljIEtleTogMjJC RTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERQoKTWVzc2FnZXMgZnJvbSB0aGlz IGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJlc3Qtc2VjdXJlZCBhbmQgbW9zdCByZWxpYWJs ZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaGVhbHRoLCB3ZWFsdGgsIG9yIHJlcXVpcmlu ZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5IHRvIHRoaXMgYWRkcmVzcy4KClNlbnQgd2l0 aCBbUHJvdG9uIE1haWxdKGh0dHBzOi8vcHJvdG9uLm1lL21haWwvaG9tZSkgc2VjdXJlIGVtYWls Lg== --b1=_w9oqYMJP9qnwLwCH4CI0ioXR650EvPIZpD8sQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5HcmVldGluZ3MsPGJyPjxicj5BcyBwZXIgcHJldmlvdXMgdGhyZWFkLCBJIGFtIHN0aWxs IGludGVyZXN0ZWQgaW4gYSBxdWlldGVyIGZic2QgZXhwZXJpZW5jZTogaWRlYWxseSBubyBrZXJu ZWwgLyByYyBvdXRwdXQgb24gc3RhcnR1cCBhbmQgbm8gY29uc29sZSBtZXNzYWdlcyBvbiBkZWZh dWx0IFRUWSBhZnRlciBsb2dpbi4mbmJzcDs8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5BcyBJIHdhcyB0cnlpbmcg dG8gc2VlIGlmIEkgY291bGQgZXh0ZW5kIGJvb3RfbXV0ZSwgSSBjYW1lIGFjcm9zcyBhbm90aGVy IGFwcHJvYWNoOjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PG9sIGRhdGEtZWRpdGluZy1p bmZvPSJ7JnF1b3Q7b3JkZXJlZFN0eWxlVHlwZSZxdW90OzoxLCZxdW90O3Vub3JkZXJlZFN0eWxl VHlwZSZxdW90OzoxfSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyIgZGF0YS1saXN0Y2hhaW49Il9fTGlzdF9DaGFpbl85NDkiPjxsaSBzdHlsZT0ibGlzdC1zdHls ZS10eXBlOiAmcXVvdDsxLiAmcXVvdDs7Ij48c3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+c2V0IHRoZSBkZWZhdWx0IGNvbnNvbGUgdG8gbm90LXplcm8g KGUuZy4gNCk8L3NwYW4+PGJyPjwvc3Bhbj48L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBl OiAmcXVvdDsyLiAmcXVvdDs7Ij5CdXQgdGhlbiB0aGUgZGVmYXVsdCBsb2dpbiBwcm9tcHQgd2Fz IGFsc28gdHR5djQuIFNvIEkuLi4uPC9saT48bGkgc3R5bGU9Imxpc3Qtc3R5bGUtdHlwZTogJnF1 b3Q7My4gJnF1b3Q7OyI+PHNwYW4gc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5BZGRlZCBhIGtlcm5lbCBvcHRpb24gd2hlcmVieSB0byBz cGVjaWZ5IHdoaWNoIFZUIHRoZSBzdGFydGluZyBvbmUgKGluc3RlYWQgb2YgZm9sbG93aW5nIHRv IGUuZy4gNCkuPC9zcGFuPjxicj48L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiAmcXVv dDs0LiAmcXVvdDs7Ij48c3BhbiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPihzdXBwb3J0aW5nIGNvZGUgdG8gbWFrZSBhbGwgdGhhdCB3 b3JrKTwvc3Bhbj48L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiAmcXVvdDs1LiAmcXVv dDs7Ij48c3BhbiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij5QYWlyIHdpdGggdGhlIHN0YXR1cyBxdW8gYm9vdF9tdXRlLCB5b3UgZ2V0IGEgcmVtYXJrYWJs eSBxdWlldCBib290IHVwLiBMb2dvLCBibGFjayBzY3JlZW4gKGFzIHlvdXIgZ2V0dHkgc2Vzc2lv biB3YWl0cyksIHByb21wdC48L3NwYW4+PGJyPjwvc3Bhbj48L2xpPjwvb2w+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5N ZWEgQ3VscGE6IEknbSB3YWFhYWF5eXkgb3V0IG9mIG15IGRlcHRoIG9uIHRoZSBrZXJuZWwgaGFj a2luZyBwaWVjZSAoanVzdCBlbm91Z2ggQyB0byBiZSBkYW5nZXJvdXMpLiBDb25zaWRlciB0aGVz ZSBza2V0Y2hlcy4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9InNjcm9sbGJhci13aWR0aDp0aGlu O3RleHQtZGVjb3JhdGlvbjpub25lIj48YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVy IG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVl YnNkLXNyYy9wdWxsLzE2MDAiIHN0eWxlPSJzY3JvbGxiYXItd2lkdGg6IHRoaW47IGNvbG9yOiBi bHVlOyI+aHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1zcmMvcHVsbC8xNjAwPC9h Pjwvc3Bhbj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5UaGUgc3VnZ2VzdGlvbiBzZXBhcmF0ZXMgIldoaWNoIFZU IGdldHMgdGhlIGNvbnNvbGUiIGFuZCAiV2hpY2ggVlQgaXMgdGhlIHN0YXJ0aW5nIFZULiIgVGhl c2UgdHdvIHJvbGVzIGFyZSBjb25mbGF0ZWQgYW5kIG15IHNrZXRjaCB1bndpbmRzIHRoYXQuIEhl cmVieSBvbmUgZ2V0czo8L3NwYW4+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48dWwgZGF0YS1l ZGl0aW5nLWluZm89InsmcXVvdDtvcmRlcmVkU3R5bGVUeXBlJnF1b3Q7OjEsJnF1b3Q7dW5vcmRl cmVkU3R5bGVUeXBlJnF1b3Q7OjF9IiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7Ij48bGkgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyBsaXN0LXN0eWxlLXR5cGU6IGRpc2M7Ij48c3Bhbj48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+YSBuaWNlIHF1aWV0IGJvb3QgdXA8L3Nw YW4+PC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6IGRpc2M7Ij48c3BhbiBz dHlsZT0iZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiPjxmb250IGZhY2U9IkFyaWFsLCBzYW5zLXNlcmlmIj5hIGRlZmF1bHQg bG9naW4gc2NyZWVuIHdob3NlIHZpIHNlc3Npb24gaXNuJ3QgaW50ZXJydXB0ZWQgKGJ5IGRlZmF1 bHQpIHdpdGggbm9pc2UgZnJvbSB5b3VyIHdpZmljYXJkIChpZiB5b3UncmUgb24gbGFwdG9wIGZi c2QpIC0tIGZyaWdodGVuaW5nL2Fubm95aW5nIHRvIHNvbWU8L2ZvbnQ+PC9zcGFuPjxicj48L2xp PjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiBkaXNjOyI+PHNwYW4gc3R5bGU9ImRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij48Zm9udCBmYWNlPSJBcmlhbCwgc2Fucy1zZXJpZiI+YSBkZWRpY2F0ZWQgbGl2ZSBzaW5rIGZv ciBjb25zb2xlIG1lc3NhZ2VzICh2ZXJzdXMgYSBsb2cgZmlsZSBvciB2ZXJzdXMgeW91ciB2aSBz ZXNzaW9uKSBjbG9zZXIgdG8gYSByZWFsIHNlcmlhbCBjb25zb2xlIG9yIE9TWCdzIGNvbnNvbGUu YXBwPC9mb250Pjwvc3Bhbj48L2xpPjwvdWw+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxmb250IGZhY2U9IkFyaWFsLCBzYW5z LXNlcmlmIj48YnI+PC9mb250PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48Zm9udCBmYWNlPSJBcmlhbCwg c2Fucy1zZXJpZiI+SXMgdGhpcyBhIGJldHRlciBhcHByb2FjaCB2cyBleHRlbmRpbmcgYm9vdF9t dXRlJ3MgcnVuPyBPciBpZiB0aGlzIGlzIHdyb25nLWhlYWRlZCBJJ2xsIGdvIGJhY2sgdG8gcHJl dmlvdXMgcGF0aHMgb2YgaW5xdWlyeS48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxmb250IGZhY2U9IkFy aWFsLCBzYW5zLXNlcmlmIj48YnI+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDAp OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48Zm9udCBmYWNlPSJBcmlh bCwgc2Fucy1zZXJpZiI+U3RldmVuPC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48ZGl2Pjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PC9zcGFuPjxmb250IGZhY2U9IkFy aWFsLCBzYW5zLXNlcmlmIj48L2ZvbnQ+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+DQo8ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayIgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQogICAgPGRpdiBjbGFzcz0icHJv dG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciI+DQogICAgICAgIDxkaXY+LS0tPGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5QdWJsaWMgS2V5OiA8YSByZWw9Im5vcmVmZXJyZXIgbm9m b2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iMjJCRTM5RTJGQTY4RDhCQThE QzRCNDNBNTVBMTZEOENFMkIwMzZERSIgaHJlZj0iaHR0cHM6Ly8yMkJFMzlFMkZBNjhEOEJBOERD NEI0M0E1NUExNkQ4Q0UyQjAzNkRFIj48c3Bhbj4yMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUEx NkQ4Q0UyQjAzNkRFPC9zcGFuPjwvYT48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC1mYW1pbHk6IEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij48YnI+ PC9kaXY+PGRpdj5NZXNzYWdlcyBmcm9tIHRoaXMgYWNjb3VudCBhcmUgY29uc2lkZXJlZCB0aGUg YmVzdC1zZWN1cmVkIGFuZCBtb3N0IHJlbGlhYmxlLiBTZW5kIGluZm9ybWF0aW9uIHJlZ2FyZGlu ZyBoZWFsdGgsIHdlYWx0aCwgb3IgcmVxdWlyaW5nIGhpZ2hlciBzdGFuZGFyZHMgb2Ygc2VjdXJp dHkgdG8gdGhpcyBhZGRyZXNzLjxicj48L2Rpdj4NCiAgICA8L2Rpdj4NCiAgICA8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48 L2Rpdj4NCiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90b24i Pg0KICAgICAgICBTZW50IHdpdGggPGEgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVy IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly9wcm90b24ubWUvbWFpbC9ob21lIj5Qcm90 b24gTWFpbDwvYT4gc2VjdXJlIGVtYWlsLg0KICAgIDwvZGl2Pg0KPC9kaXY+DQo= --b1=_w9oqYMJP9qnwLwCH4CI0ioXR650EvPIZpD8sQ-- From nobody Tue Feb 18 11:47:18 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 4YxySR3f3Bz5nTZM for ; Tue, 18 Feb 2025 11:47:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-ztdg06021701.me.com (mr85p00im-ztdg06021701.me.com [17.58.23.196]) (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 4YxySQ6nxYz3Bt5 for ; Tue, 18 Feb 2025 11:47:34 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; bh=teqBLssvVSjSt1w+qSO3ByiWtzjoId+O65a4vvbG6kw=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To:x-icloud-hme; b=J4lJODlZZwZNbu7o0QrzoZagYln6HQuvk8dzissvc/emxZ76uNSzKfnF2cYvFVSrB 05OYq8qesMN+Yu1wRIdY/m47rdlHft+LQo9fazuVCovlQg5vq8LgapBLGuAdzUfoKz ZELtGzA6r1dCgsqnGtZDose104Q1tv8uxbjm04qLy0msBcFZzIZ7K5W7sgJDfFNroq 9BjsHcES65IKKZTasoqGaXiOzLrMXLsR6vrlLvkd2UEteEbhCM5caZ5CXQwL4coLBi NaAtALK/b8fRUstSgts0BFD80iCd23OMhNndFWox1KuedtbMrV/QkxLd5L/JznNXA5 o0BITG/qLtm1A== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06021701.me.com (Postfix) with ESMTPSA id D91472633385; Tue, 18 Feb 2025 11:47:31 +0000 (UTC) From: Toomas Soome Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_464AC729-5D09-44A4-A521-98650C0FC5BC" 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.400.131.1.6\)) Subject: Re: Quieter startup + working experience by overriding VT_CONSWINDOW (and consequences) Date: Tue, 18 Feb 2025 13:47:18 +0200 In-Reply-To: Cc: "freebsd-current@freebsd.org" To: "Steven Harms (High-Security Mail)" References: X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Proofpoint-ORIG-GUID: YhJdg-cj8fQpjFl5sOJ_kC4nibMLAvKU X-Proofpoint-GUID: YhJdg-cj8fQpjFl5sOJ_kC4nibMLAvKU X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-02-18_04,2025-02-18_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 clxscore=1011 bulkscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2502180092 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Rspamd-Queue-Id: 4YxySQ6nxYz3Bt5 X-Spamd-Bar: ---- --Apple-Mail=_464AC729-5D09-44A4-A521-98650C0FC5BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18. Feb 2025, at 13:31, Steven Harms (High-Security Mail) = wrote: >=20 > Greetings, >=20 > As per previous thread, I am still interested in a quieter fbsd = experience: ideally no kernel / rc output on startup and no console = messages on default TTY after login.=20 >=20 > As I was trying to see if I could extend boot_mute, I came across = another approach: >=20 > set the default console to not-zero (e.g. 4) > But then the default login prompt was also ttyv4. So I.... > Added a kernel option whereby to specify which VT the starting one = (instead of following to e.g. 4). > (supporting code to make all that work) > Pair with the status quo boot_mute, you get a remarkably quiet boot = up. Logo, black screen (as your getty session waits), prompt. >=20 > Mea Culpa: I'm waaaaayyy out of my depth on the kernel hacking piece = (just enough C to be dangerous). Consider these sketches. = https://github.com/freebsd/freebsd-src/pull/1600 >=20 > The suggestion separates "Which VT gets the console" and "Which VT is = the starting VT." These two roles are conflated and my sketch unwinds = that. Hereby one gets: >=20 > a nice quiet boot up > a default login screen whose vi session isn't interrupted (by default) = with noise from your wificard (if you're on laptop fbsd) -- = frightening/annoying to some > a dedicated live sink for console messages (versus a log file or = versus your vi session) closer to a real serial console or OSX's = console.app >=20 > Is this a better approach vs extending boot_mute's run? Or if this is = wrong-headed I'll go back to previous paths of inquiry. >=20 > Steven I personally like the approach to enable console log with boot -v, = otherwise use your syslog kern.* once userland is there and internal = message buffer for startup time before userland appears. This makes it = possible to have quick check (-v) and for normal startup, we still have = the information or in case of crash, we can check the message buffer=E2=80= =A6=20 rgds, toomas= --Apple-Mail=_464AC729-5D09-44A4-A521-98650C0FC5BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18. Feb 2025, at 13:31, Steven Harms = (High-Security Mail) <sgharms@stevengharms.com> wrote:

Greetings,

As per previous = thread, I am still interested in a quieter fbsd experience: ideally no = kernel / rc output on startup and no console messages on default TTY = after login. 

As I = was trying to see if I could extend boot_mute, I came across another = approach:

  1. set the = default console to not-zero (e.g. 4)
  2. But then the default login = prompt was also ttyv4. So I....
  3. Added a kernel option whereby to specify which VT the starting = one (instead of following to e.g. 4).
  4. (supporting code to make all that = work)
  5. Pair with the status quo = boot_mute, you get a remarkably quiet boot up. Logo, black screen (as = your getty session waits), prompt.

Mea Culpa: I'm waaaaayyy out of = my depth on the kernel hacking piece (just enough C to be dangerous). = Consider these sketches. https://github.com/freebsd/freebsd-src/pull/1600

The suggestion separates "Which = VT gets the console" and "Which VT is the starting VT." These two roles = are conflated and my sketch unwinds that. Hereby one = gets:

  • a = nice quiet boot up
  • a default login = screen whose vi session isn't interrupted (by default) with noise from = your wificard (if you're on laptop fbsd) -- frightening/annoying to = some
  • a dedicated live sink for = console messages (versus a log file or versus your vi session) closer to = a real serial console or OSX's console.app

Is this a better approach vs = extending boot_mute's run? Or if this is wrong-headed I'll go back to = previous paths of inquiry.

Steven

I = personally like the approach to enable console log with boot -v, = otherwise use your syslog kern.* once userland is there and internal = message buffer for  startup time before userland appears. This = makes it possible to have quick check (-v) and for normal startup, we = still have the information or in case of crash, we can check the message = buffer=E2=80=A6 

rgds,
toomas
= --Apple-Mail=_464AC729-5D09-44A4-A521-98650C0FC5BC-- From nobody Tue Feb 18 21:56:18 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 4YyCz35DhYz5pDpp for ; Tue, 18 Feb 2025 21:56:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 4YyCz30tBfz3Lfp for ; Tue, 18 Feb 2025 21:56: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=C7WoSZOx; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102f) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2fc0026eb79so11326965a91.0 for ; Tue, 18 Feb 2025 13:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1739915790; x=1740520590; 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=thCdEoKtZhAW4LLvk3sHvMlt5rZ2snxe7zo4SUCwY9g=; b=C7WoSZOxZJRkGGSwRRObV2n2woWPHk7RmzATnPN9woS0y0VttKIs3/bpS2phuEuNLm moV/yeZ9UFByAGzbINGrowwNPNnipOPOMpGVtAqja9lfApK2Jdfl5HoY5+Xhe3T5y7qx 6SQiTGnloE1Tq04na/IWDmzjvW0uKrmP+LRQA4MDZ3FKOXRJU+cK7EYDgPde94oz7vlf olkQ24pF/YqT9eG11SvgdIDFc5Oo1w7GggDIIQGVU/3AbrBIas7I5itS3ohm2smB/jq3 Jn3TWLt5aS5l0d9S7OM4ozb9dgp9OfGR1O6RwgK7cD0jgveC94jdPGj94U7BCffd025L itbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739915790; x=1740520590; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=thCdEoKtZhAW4LLvk3sHvMlt5rZ2snxe7zo4SUCwY9g=; b=CpGgYY5qam9txmaHbg9kUsw1ARo5YeECVUFs6HONgDqv2BMzB4kntecIUgpvK8YjWO tLsbI3E1rZn+XymySWZA/82D+0/2yd4OJVfja94Ks5N1Pn3MqbZt/w8E7SdCKp7cre0l iDS0u8V53UVC506LVxYEwodhoIfUOg6qHbJQjfnd1xSMhq6uUYv1pX+PsMazKTL/T0Z0 tNGi8MlM+qSaN4vTCtAwJbjfg9VX/WGluA1FtG+K/Hriv3UbMEHzEA/++dIy3wVB3an6 uaMBiMQzZF/OWsmGnWdBHkq7vHPYhid41+mTPjp/iSGgbi3WLkR05wRf9gOt73ew71Qm Ddnw== X-Forwarded-Encrypted: i=1; AJvYcCXIEIDzFEtwmp8Nt05XV0WkTAQqQzAZAMSW73FqOrC+A8VN2Cv4SbJ11auh4mhk6zuBP2v8uAgNBBuXGHjr0MA=@freebsd.org X-Gm-Message-State: AOJu0YzRUwbp12cCqfVI+Spetb6S5vlPbxFjxVFn88F8jdCrCeuJgXrC pybWiVTRRCteWOnt62vCeFnvIp28fCOu88CPZEyt2zU6N8NlkkjsS3fdTR1aG/MOc/0GqrFWPa4 jYnJvvlpWu/HzorkRRw+8MKXCoyVJD4L2ExSznQ== X-Gm-Gg: ASbGncvTHbziLZyLhzZ6Suf9MH8LJdIz7MRfU94TwO2AqUZknfUQmaWkPf+ie1LkeLG Lf4AHLK2OpvcBzJV+nJbphQBagNjEa3maum0aFycUNn1iuBeFOn1SrlCqIz/T8bzY8RQ71JB/ X-Google-Smtp-Source: AGHT+IGQLgiFqLOJ94PBSSmj1OZ8acPo33PbU0qPxQla1eOOW/+Fjj9k0dwUIqX4ZhKSWN4o30LfyPGGBq5OcvKSiwI= X-Received: by 2002:a17:90b:1a88:b0:2fc:b40:339a with SMTP id 98e67ed59e1d1-2fcb5a14827mr1793619a91.10.1739915789988; Tue, 18 Feb 2025 13:56:29 -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: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> In-Reply-To: <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> From: Warner Losh Date: Tue, 18 Feb 2025 14:56:18 -0700 X-Gm-Features: AWEUYZluCUk5qgMKCO8pBec6oeKjoYOoWtZyCCqE48DEcR_GaTSh2fIC6qa4cXI Message-ID: Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? To: Mark Millard Cc: freebsd-arm , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000009a13f4062e71b6a2" X-Spamd-Result: default: False [-1.89 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.891]; 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]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102f:from]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4YyCz30tBfz3Lfp X-Spamd-Bar: - --0000000000009a13f4062e71b6a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard w= rote: > [This seems likely to not be limited to main [so: 15 as stands]. > But I'm using main as the example for the issue.] > > In: > > # man 5 device.hints > DEVICE.HINTS(5) FreeBSD File Formats Manual > DEVICE.HINTS(5) > > NAME > device.hints =E2=80=93 device resource hints > > . . . > > FILES > /boot/device.hints Device resource hints > file. > /sys/ARCH/conf/GENERIC.hints Sample resource hints fo= r > the > GENERIC kernel. > /sys/ARCH/conf/NOTES Notes on the kernel > configuration file and > device > resource hints. > . . . > > > > For reference: > > # find -s / -name GENERIC.hints -print > /usr/src/sys/amd64/conf/GENERIC.hints > /usr/src/sys/i386/conf/GENERIC.hints > /usr/src/sys/powerpc/conf/GENERIC.hints > > > Multiple points: > > ) It seems that aarch64 (arm64?) and armv7 (arm?) have no > such GENERIC.hints file. The same goes for riscv64 > (riscv?). > > The intent for powerpc64 , powerpc64le , and powerpcspe > may have the same issue. > > > ) At least for how the local systems were installed, there > is no such place predefined as /sys/ , not even as a > symbolic link. "man 7 hier" does not list such. > > So it seems /sys -> /usr/src/sys is intended. (But > /usr/src/ need not have been populated, leaving a > lack of any GENERIC.hints in such a case.) > > Best to not to depend on /sys in the notation shown? > > > ) The /ARCH/ reference is unclear vs. MACHINE, > MACHINE_CPUARCH, and MACHINE_ARCH. The example paths > existing for GENERIC.hints do not help because they > all allow MACHINE =3D=3D MACHINE_CPUARCH , > MACHINE =3D=3D MACHINE_ARCH , and > MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the > NOTE paths: > Like all things kernel, it's MACHINE. > > # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more > /usr/src/sys/amd64/conf/NOTES > /usr/src/sys/arm/conf/NOTES > /usr/src/sys/arm64/conf/NOTES > /usr/src/sys/conf/NOTES > /usr/src/sys/i386/conf/NOTES > /usr/src/sys/powerpc/conf/NOTES > /usr/src/sys/riscv/conf/NOTES > /usr/src/sys/x86/conf/NOTES > > None of of the MACHINE* are right: x86 is not one of > any of the 3. Otherwise /arm64/conf/NOTES would suggest > MACHINE as the only possibility if /ARCH/ was uniform > for relative to the 3 MACHINE* possibilities. So?: > > /usr/src/sys/arm64/conf/GENERIC.hints > /usr/src/sys/arm/conf/GENERIC.hints > /usr/src/sys/riscv/conf/GENERIC.hints > > with no aarch64 , armv7 , powerpc64* , powerpcspe , or > riscv64 examples? > We store these in /dev/null these days :). I'll create empty ones for this. Warner > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --0000000000009a13f4062e71b6a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 15,= 2025 at 10:04=E2=80=AFAM Mark Millard <marklmi@yahoo.com> wrote:
[This seems likely to not be limited to main [so: 15 = as stands].
But I'm using main as the example for the issue.]

In:

# man 5 device.hints
DEVICE.HINTS(5)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD File Format= s Manual=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DEVICE.HINTS(5)

NAME
=C2=A0 =C2=A0 =C2=A0device.hints =E2=80=93 device resource hints

. . .

FILES
=C2=A0 =C2=A0 =C2=A0/boot/device.hints=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 Device resource hin= ts file.
=C2=A0 =C2=A0 =C2=A0/sys/ARCH/conf/GENERIC.hints=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sample resource hints for the
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0GENERIC kernel.
=C2=A0 =C2=A0 =C2=A0/sys/ARCH/conf/NOTES=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notes on the kernel
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration file and device
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0resource hints.
. . .



For reference:

# find -s / -name GENERIC.hints -print
/usr/src/sys/amd64/conf/GENERIC.hints
/usr/src/sys/i386/conf/GENERIC.hints
/usr/src/sys/powerpc/conf/GENERIC.hints


Multiple points:

) It seems that aarch64 (arm64?) and armv7 (arm?) have no
=C2=A0 such GENERIC.hints file. The same goes for riscv64
=C2=A0 (riscv?).

=C2=A0 The intent for powerpc64 , powerpc64le , and powerpcspe
=C2=A0 may have the same issue.


) At least for how the local systems were installed, there
=C2=A0 is no such place predefined as /sys/ , not=C2=A0 =C2=A0even as a
=C2=A0 symbolic link. "man 7 hier" does not list such.

=C2=A0 So it seems /sys -> /usr/src/sys is intended. (But
=C2=A0 /usr/src/ need not have been populated, leaving a
=C2=A0 lack of any GENERIC.hints in such a case.)

=C2=A0 Best to not to depend on /sys in the notation shown?


) The /ARCH/ reference is unclear vs. MACHINE,
=C2=A0 MACHINE_CPUARCH, and MACHINE_ARCH. The example paths
=C2=A0 existing for GENERIC.hints do not help because they
=C2=A0 all allow MACHINE =3D=3D MACHINE_CPUARCH ,
=C2=A0 MACHINE =3D=3D MACHINE_ARCH , and
=C2=A0 MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the
=C2=A0 NOTE paths:

Like all things kern= el, it's MACHINE.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--0000000000009a13f4062e71b6a2-- From nobody Tue Feb 18 22:01:44 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 4YyD5L52z7z5pFTq for ; Tue, 18 Feb 2025 22:01:58 +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 4YyD5K011Kz3QYp for ; Tue, 18 Feb 2025 22:01:57 +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=jxzhp1wN; 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-2fbfc9ff0b9so9159513a91.2 for ; Tue, 18 Feb 2025 14:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1739916115; x=1740520915; 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=FRSBeN7SWd/8CeFfFq7eFa8ISOmEsHVNLrNQrSjGPjs=; b=jxzhp1wNhosvfqkM0Ljcb9RLGju943HRvwPFdGzKrNTl+hK8yQlLGYo0WJFZJtax6S 3zZ/O3E3dQLBMpAv7nu9dXb6iynndDcYuhUitPzteSWaw42r8FrTBAQdTGT9NK1pBV+b nwr3xLdkOEMcCCPIGFoh3gvjTMsFuw1gG/o0E0POEncUO8mVeeIuaEP/2br4gU7dOH2j x8UIXtktQA3CDtpGmOywvOtBA7Jy6VOdjrBf7GtetwLsbAmCo5bF097u15apzr1QET2t QxjPe8vxjpO4mBkIaD27RHkkB8BqGVTRPK2RxX5GPScisdThS81Z/DMOt+yOC2lDcd4t aVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739916115; x=1740520915; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FRSBeN7SWd/8CeFfFq7eFa8ISOmEsHVNLrNQrSjGPjs=; b=pl2/tZtF9EPbWKTauxvNohzrcUvpsju1pXDTXXNfZ/q2V9/YnjDiszpfuXpTuCJGue xWVGNlAPDNOhf7SEit78TCs2D2J/xx9vlGNt24BnJ4r+v24M9bEtXNX+P0UZTuOQiAWf 0NXeCLLWSKkJ9I//K3AM8BO4SrvPfHXjmThs7FY5VsI+E5lzSXgHSVnSTU9uYKcgTj/A 6DsedRmWuomPGewK/Vqi8uTetROb6XACjVedvE0B97eQCjFoWYtjqTnlOtmhrKrOQUDz Mbn3ZAyNMNmtFYnxQvS8FPMRFe2tgihsylAVD9T6ROJ8MoOn5OXsyVJ8gs239KySE5NE ubQA== X-Forwarded-Encrypted: i=1; AJvYcCXLkMpB9H5SVr/pv+ClqS17JKslYLy9YirgAic/QsREsAWc6QtyQnFRrrt0i3F4MuYxhiDX7kdMddibQddPGcU=@freebsd.org X-Gm-Message-State: AOJu0Yxes4uYlTxXZ0VyV9DJ1c99tp6l66vZr0N8uyF8fGfVJHSa2sE7 B46iWnseXaA0Hmo4NJH+cCqbZXQhSVP3OaeOJeO18c2yrCcjfrs+GdPQPs1Fp8UDJv0k6B/zUTk jDYJmhnMlHpr1t6mPvb+xWr8IlrJ/C1c4ntP1j4cOMrtdCPdSKj3oCQ== X-Gm-Gg: ASbGncu23wGFAzX6nzAWwsuo0gmwJyULUKBCQksD16LHlGUTDcQoM8PyO+mZqCWg+eF czCiRq2Pgy2S5GvOQd/ZJJRcJrdHoiIlEdBDDO83QNn2vt2rQlFWaTn5DMj5889p9Ifc8qK6l X-Google-Smtp-Source: AGHT+IGFnMWWZ0ZiXdOySRN7+/XfswWt5zNQQetHZUwtfeyV+WxU7E2EyhOWD023Pl5HRES9sWRje5KBNyENDEwV6qo= X-Received: by 2002:a17:90b:1e09:b0:2ee:d186:fe48 with SMTP id 98e67ed59e1d1-2fc410453b3mr22958361a91.28.1739916115631; Tue, 18 Feb 2025 14:01:55 -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: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> In-Reply-To: From: Warner Losh Date: Tue, 18 Feb 2025 15:01:44 -0700 X-Gm-Features: AWEUYZk6tCtC2_9AKoiJy35Q5It_QnaAMdDQfYxS6GjugrqQKdd1i85470uIWfg Message-ID: Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? To: Mark Millard Cc: freebsd-arm , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000002fcf4062e71ca96" X-Spamd-Result: default: False [-1.88 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.885]; 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]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4YyD5K011Kz3QYp X-Spamd-Bar: - --00000000000002fcf4062e71ca96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh wrote: > > > On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard = wrote: > >> [This seems likely to not be limited to main [so: 15 as stands]. >> But I'm using main as the example for the issue.] >> >> In: >> >> # man 5 device.hints >> DEVICE.HINTS(5) FreeBSD File Formats Manual >> DEVICE.HINTS(5) >> >> NAME >> device.hints =E2=80=93 device resource hints >> >> . . . >> >> FILES >> /boot/device.hints Device resource hints >> file. >> /sys/ARCH/conf/GENERIC.hints Sample resource hints >> for the >> GENERIC kernel. >> /sys/ARCH/conf/NOTES Notes on the kernel >> configuration file and >> device >> resource hints. >> . . . >> >> >> >> For reference: >> >> # find -s / -name GENERIC.hints -print >> /usr/src/sys/amd64/conf/GENERIC.hints >> /usr/src/sys/i386/conf/GENERIC.hints >> /usr/src/sys/powerpc/conf/GENERIC.hints >> >> >> Multiple points: >> >> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no >> such GENERIC.hints file. The same goes for riscv64 >> (riscv?). >> >> The intent for powerpc64 , powerpc64le , and powerpcspe >> may have the same issue. >> >> >> ) At least for how the local systems were installed, there >> is no such place predefined as /sys/ , not even as a >> symbolic link. "man 7 hier" does not list such. >> >> So it seems /sys -> /usr/src/sys is intended. (But >> /usr/src/ need not have been populated, leaving a >> lack of any GENERIC.hints in such a case.) >> >> Best to not to depend on /sys in the notation shown? >> >> >> ) The /ARCH/ reference is unclear vs. MACHINE, >> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths >> existing for GENERIC.hints do not help because they >> all allow MACHINE =3D=3D MACHINE_CPUARCH , >> MACHINE =3D=3D MACHINE_ARCH , and >> MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the >> NOTE paths: >> > > Like all things kernel, it's MACHINE. > >> >> # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more >> /usr/src/sys/amd64/conf/NOTES >> /usr/src/sys/arm/conf/NOTES >> /usr/src/sys/arm64/conf/NOTES >> /usr/src/sys/conf/NOTES >> /usr/src/sys/i386/conf/NOTES >> /usr/src/sys/powerpc/conf/NOTES >> /usr/src/sys/riscv/conf/NOTES >> /usr/src/sys/x86/conf/NOTES >> >> None of of the MACHINE* are right: x86 is not one of >> any of the 3. Otherwise /arm64/conf/NOTES would suggest >> MACHINE as the only possibility if /ARCH/ was uniform >> for relative to the 3 MACHINE* possibilities. So?: >> >> /usr/src/sys/arm64/conf/GENERIC.hints >> /usr/src/sys/arm/conf/GENERIC.hints >> /usr/src/sys/riscv/conf/GENERIC.hints >> >> with no aarch64 , armv7 , powerpc64* , powerpcspe , or >> riscv64 examples? >> > > We store these in /dev/null these days :). > > I'll create empty ones for this. > https://reviews.freebsd.org/D49052 Just to expand a little: These platforms don't have legacy devices they need to hard-wire in various ways, unlike the other platforms. However, people use them to do device instance wiring, so I've created the empty ones. Warner > Warner > > >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> >> >> --00000000000002fcf4062e71ca96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 18,= 2025 at 2:56=E2=80=AFPM Warner Losh <= imp@bsdimp.com> wrote:


On Sat, Feb 15, 2025 at= 10:04=E2=80=AFAM Mark Millard <marklmi@yahoo.com> wrote:
[This seems likely to not be limited to ma= in [so: 15 as stands].
But I'm using main as the example for the issue.]

In:

# man 5 device.hints
DEVICE.HINTS(5)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD File Format= s Manual=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DEVICE.HINTS(5)

NAME
=C2=A0 =C2=A0 =C2=A0device.hints =E2=80=93 device resource hints

. . .

FILES
=C2=A0 =C2=A0 =C2=A0/boot/device.hints=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 Device resource hin= ts file.
=C2=A0 =C2=A0 =C2=A0/sys/ARCH/conf/GENERIC.hints=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sample resource hints for the
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0GENERIC kernel.
=C2=A0 =C2=A0 =C2=A0/sys/ARCH/conf/NOTES=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notes on the kernel
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration file and device
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0resource hints.
. . .



For reference:

# find -s / -name GENERIC.hints -print
/usr/src/sys/amd64/conf/GENERIC.hints
/usr/src/sys/i386/conf/GENERIC.hints
/usr/src/sys/powerpc/conf/GENERIC.hints


Multiple points:

) It seems that aarch64 (arm64?) and armv7 (arm?) have no
=C2=A0 such GENERIC.hints file. The same goes for riscv64
=C2=A0 (riscv?).

=C2=A0 The intent for powerpc64 , powerpc64le , and powerpcspe
=C2=A0 may have the same issue.


) At least for how the local systems were installed, there
=C2=A0 is no such place predefined as /sys/ , not=C2=A0 =C2=A0even as a
=C2=A0 symbolic link. "man 7 hier" does not list such.

=C2=A0 So it seems /sys -> /usr/src/sys is intended. (But
=C2=A0 /usr/src/ need not have been populated, leaving a
=C2=A0 lack of any GENERIC.hints in such a case.)

=C2=A0 Best to not to depend on /sys in the notation shown?


) The /ARCH/ reference is unclear vs. MACHINE,
=C2=A0 MACHINE_CPUARCH, and MACHINE_ARCH. The example paths
=C2=A0 existing for GENERIC.hints do not help because they
=C2=A0 all allow MACHINE =3D=3D MACHINE_CPUARCH ,
=C2=A0 MACHINE =3D=3D MACHINE_ARCH , and
=C2=A0 MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the
=C2=A0 NOTE paths:

Like all things kern= el, it's MACHINE.
https://reviews.freebsd.org/D49= 052

Just to expand a little: These platforms d= on't have legacy devices
they need to hard-wire in various wa= ys, unlike the other platforms.
However, people use them to do de= vice instance wiring, so I've created
the empty ones.

Warner
=C2=A0
Warn= er
=C2=A0
=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--00000000000002fcf4062e71ca96-- From nobody Tue Feb 18 23:57:14 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 4YyGfg0Y15z5pN63 for ; Tue, 18 Feb 2025 23:57:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.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 4YyGff3sZCz3ThV for ; Tue, 18 Feb 2025 23:57: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=1739923047; bh=cqdHIMql8W1qerhnHiIp4oV3cP0URUlD3MkcakAnxEY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jVtQ10C1P9Z75tCZw2oWJoCEcv+gCr9yiM64mBcHzBgDn2JhBLangt01wAFZydiMl5Q6TaqsV9pyx7FDPCU3YjHiWBXng4Ig8gCC0JPQEnQJql8/72lj+HQwOOwAYtRHpRWETxys7xWw9Pn+0H2T1vaHVvhlqhJ0oZNzuAYqMM0WeZ5nb2EdBKwtAREVt5dbVvDcfPGp2s7ZwxcMHAd95yN7gV3nLYVUUp2W9Yujel1A/h90AmIowqxMB2olPlxEkrsbY77hfa1fzMbXEyo1kv6c5/pgRYprNj9iUijl8bOC/trWtKTkzFr4ZlttMKWRoF7ZkYGI1h+Wf6yPpHTnYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739923047; bh=E7b56wTV4FV+7pCJt8KvJMdQ+xQNEBlFqtLPcB+bc8w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=a+wR9pVer/XGcrAADpEkSJWE0+RM23/cBsX1Oc6maEhVJb3irfQAXVv730QPn12O9wJ1H9P0FabxKV7RKQGk7WZcj6xire9t7reZX84bJh0M6sYSewCy6w8ehTfrMapsnvS62RXsv7ELKY0AFQhT7J1bjOj9lIZElt9qOsc2uS9OrnVS5r7Fn8wKZYBp9RZISzFcw0f2G8Wyu5Oxpq3DGcewx4O5tDhYd4TltPqpNo4E9ki0W1l41tsI5tdXPxqonoDu7vb4cXuYBF1TESWJRXNie6qia9s3rSf5vtq9Yb6xM3QdAOstt/zbVDSI2C8sddtL/2U46D+z5pY0RvQrfw== X-YMail-OSG: cjtc4h4VM1mZaI4IRMlaWzR.cy0Jhb3_1XUosmdGtHtkZnYtEDvv425sb4avDwQ ew6JL2o5iVWfQG.N.bwEQ8Rk_wAmimWSz8UxBnzzEg.1ODnVJfnX0GkzeJ2Q4VeF08ZtQyT9gRNd RyEU1_3IpBNj7lKF6dWj2k14rKNS9dRCzvU3PuqBy7phkDYGsmfc06Dmx.SFORsshQM0gT9RZa3D MIj0v9CgpXAufm6UUMAUFPFIvpc6VhTjZRMbInNAycuG55jUEOXBEXJ7Uu5.hXY0CciBU_6LhXuS r3cPvf5h_BYiGhbRkmBspGYu8O1g8x2m8rHDus5ONYXxVcGMyvLRIe63pXfBiDOTzS03TztIhTq4 DGFGdb3BjLT.r5b4Xj9y1yen6w7_flnj3Vlg5Zd3I5ebcOcy3f5xJxVxotyUdXvGnUwkU7jcdiGQ 4EastZyJmcEdCwLjJuIcwyCog.kzT8FTJtrBgtRqcW5Lk7bXKHvEZySpwbWa.N84kNoztPc0GURM u9DZGPiOnMuY2KH.w20FPPPHobgZyXSHpS_18yAPKVZqhgyHbqx_GD.RyJUuOEdCnvEQmQiGkJSg wz0Q6LMWgkZ_1tSzNKr5QVGkC8vNZ3Q8xbuGWRV8ZIrHm1Wqn4KYgr5mqtqbV6D6pbOUNCiKXtRY aT6btuFPCDXsXQXEuun9BTpbrJOblpKu4DlB4ZzJ5gvT2XS3cvRW_05LzDx0MeOMjXdspM5QwRl2 oWSraC1LAVJVXTC5nMaw99JBod48aZLxSRk7y4H7bwLLUT5yH2TAcxgBTs9A78JsdUMZR9p.VuhJ CjrVuUGVVIazrO9tsTqZ9M0V7DOlqZh.xJp._.e0RmeMfo.Gc5ju_7wNcHKwIbT.9JLmNeQzNjOw FkQEb9Q8wzSP3X7tS0PnrZBHX6cTE.o0oF45rxLfs1Q50GshtCryFdauMyIs9Kj00gwq14wkGtDX lZN78RlZWN7ZVF4xxOzYV8r.Z4WTFpHLGzwCGKzVTIAkO8GX6_xuEtRgGIaZJnYJxuaFIbVJJXbY PjNmjnAtLdzsI.udgHFesYLIOIPw4m9utwGCmmWyA0_d4lE21Xw1ATNwYkc4xDgku_XY00sa7IMk MYMG_d.RLNajkwtxEgsRPDoIA6GsgANRwdJr.YkAi0_s_dMoeXHKw3TPqkuNVlMzZbe29UXH7wDu s2xHsMkevFBfALou8w.XR8ib.95NFLuqKWoYcFKzXJ_yyIFxfh.WjV0CLAYUJz.WZXo_rJeo2oEy XFjoqZMtlQL.AkA3K.sDrPjw9SFaPxXkWX6GgMv7Ghtg2Fu4o28BWdhlUC7iWRKuxpC8XGkwssnH 7blnvrg2V5PcJGSEvFKwYNFMhlZVA.5QsJeqIe96STBv.EFvdRFci6O8Xo1z4mjmnStdAcEptE3X PGaY6Kb1IicoN2h5MsdqDe56brNuqCUjLd1Q_sJyKnq5bNa_ZY8tue._5uC3HzxLj3AK2kQLPO2m _z0oNEB6KOLssPxwf59XHkmdXVIc33FKSlRDWbkVclINoW0PJ1b3m3UKPH7t64Y0aEHkJ9BApa8q v8OdLI3CuoYtnTXPZnCGQNnK4QqYY8xsZimQHgUzr7apZbfEentZCs3nS6F3xe8zbimyQZmniDWD 4jTAoFg7W6abGL6o4tsr2lNB4PoAPhmugelMJEF.JgAyooZcPWXlVg9RjwqvZOMlHSo.wV04tw6H Va7QG0kuBqp7Go7Us3N7bLszTLKwq9Cw2eHtMZHj6XFglt93O0Q060xAxcQnvXeGY_G1njtNTlco cM_J5qEYJ89Qvl61cLGHtRQgGF70u2iCFMSFMqPmsq3zJrhu9yzYdhsNymjV6iRzql2GLRL9SPJu TpTeUlgSbs8aQp45PS45uQQmRJTGr1Q6TrwCFdyMZ6HAhwDewOOXlEE0L7GqWA.h_90JYI0I9mEA U8BDz_IRvuj4q6jvGawanDbFlMFdSv0_2KQOPiUXp4bN_7M98yqw_4oMf1ZCl1srUOY92PGGmZgq Ue_nbcfRbxPfIAkLT5ia4X7FvjgfSDj8ksMh6kU5gyfjch40Cz0cH3Ma_IXvLAGzc0cbSnyXn5k9 rNFWM2rhfIF.5eD1PSCKTbiYYfX.XpF_N70a4sJs1MiZ2DQmM37KuwaWy3qtsiqGea.11OjeFNtR GXehcie5WcnjslAX9E8wn_hypjzsU1mKfiWL9rqw_XdrOt9dEeQOpm.Py4k8CUtbfo71lMnKBzR6 W3zMvK4zWA_b80dSHy7AQpLatLVLF.hzTHFVKew8EDH0ZpDK1vMJhmdPmhVPniTErptX9VoWxWb7 6qS0- X-Sonic-MF: X-Sonic-ID: 2088fcc8-c69b-4bee-a636-b634a7287381 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Feb 2025 23:57:27 +0000 Received: by hermes--production-gq1-5dd4b47f46-9j75b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 31921bde9e8836832ab35cbdaecf000d; Tue, 18 Feb 2025 23:57:25 +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.400.131.1.6\)) Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? From: Mark Millard In-Reply-To: Date: Tue, 18 Feb 2025 15:57:14 -0800 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4YyGff3sZCz3ThV X-Spamd-Bar: ---- On Feb 18, 2025, at 14:01, Warner Losh wrote: >=20 > On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh = wrote: >>=20 >> On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard = wrote: >>> [This seems likely to not be limited to main [so: 15 as stands]. >>> But I'm using main as the example for the issue.] >>>=20 >>> In: >>>=20 >>> # man 5 device.hints >>> DEVICE.HINTS(5) FreeBSD File Formats Manual = DEVICE.HINTS(5) >>>=20 >>> NAME >>> device.hints =E2=80=93 device resource hints >>>=20 >>> . . . >>>=20 >>> FILES >>> /boot/device.hints Device resource = hints file. >>> /sys/ARCH/conf/GENERIC.hints Sample resource = hints for the >>> GENERIC kernel. >>> /sys/ARCH/conf/NOTES Notes on the kernel >>> configuration file = and device >>> resource hints. >>> . . . >>>=20 >>>=20 >>>=20 >>> For reference: >>>=20 >>> # find -s / -name GENERIC.hints -print >>> /usr/src/sys/amd64/conf/GENERIC.hints >>> /usr/src/sys/i386/conf/GENERIC.hints >>> /usr/src/sys/powerpc/conf/GENERIC.hints >>>=20 >>>=20 >>> Multiple points: >>>=20 >>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no >>> such GENERIC.hints file. The same goes for riscv64 >>> (riscv?). >>>=20 >>> The intent for powerpc64 , powerpc64le , and powerpcspe >>> may have the same issue. >>>=20 >>>=20 >>> ) At least for how the local systems were installed, there >>> is no such place predefined as /sys/ , not even as a >>> symbolic link. "man 7 hier" does not list such. >>>=20 >>> So it seems /sys -> /usr/src/sys is intended. (But >>> /usr/src/ need not have been populated, leaving a >>> lack of any GENERIC.hints in such a case.) >>>=20 >>> Best to not to depend on /sys in the notation shown? >>>=20 >>>=20 >>> ) The /ARCH/ reference is unclear vs. MACHINE, >>> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths >>> existing for GENERIC.hints do not help because they >>> all allow MACHINE =3D=3D MACHINE_CPUARCH , >>> MACHINE =3D=3D MACHINE_ARCH , and >>> MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the >>> NOTE paths: >>=20 >> Like all things kernel, it's MACHINE. >>=20 >>> # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more >>> /usr/src/sys/amd64/conf/NOTES >>> /usr/src/sys/arm/conf/NOTES >>> /usr/src/sys/arm64/conf/NOTES >>> /usr/src/sys/conf/NOTES >>> /usr/src/sys/i386/conf/NOTES >>> /usr/src/sys/powerpc/conf/NOTES >>> /usr/src/sys/riscv/conf/NOTES >>> /usr/src/sys/x86/conf/NOTES >>>=20 >>> None of of the MACHINE* are right: x86 is not one of >>> any of the 3. Otherwise /arm64/conf/NOTES would suggest >>> MACHINE as the only possibility if /ARCH/ was uniform >>> for relative to the 3 MACHINE* possibilities. So?: >>>=20 >>> /usr/src/sys/arm64/conf/GENERIC.hints >>> /usr/src/sys/arm/conf/GENERIC.hints >>> /usr/src/sys/riscv/conf/GENERIC.hints >>>=20 >>> with no aarch64 , armv7 , powerpc64* , powerpcspe , or >>> riscv64 examples? >>=20 >> We store these in /dev/null these days :). >>=20 >> I'll create empty ones for this. >=20 > https://reviews.freebsd.org/D49052 Thanks. > Just to expand a little: These platforms don't have legacy devices > they need to hard-wire in various ways, unlike the other platforms. > However, people use them to do device instance wiring, so I've created > the empty ones. An example can also be disabling something that needs to be avoided for some unusual reason, such as avoiding virtio_gpu under parallels on aarch64 macOS. (I've not tested doing that yet.) =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 19 00:04: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 4YyGpV6HL4z5pNLY for ; Wed, 19 Feb 2025 00:04:18 +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 4YyGpV2KqKz3ZVY for ; Wed, 19 Feb 2025 00:04:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2fbf77b2b64so11448404a91.2 for ; Tue, 18 Feb 2025 16:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1739923456; x=1740528256; 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=/ZzceWk0iID3BCJAakMf3N4ITDWrClnL4y6Dzr0jrc8=; b=onkKdiUFq+h5SbhvhgX1mvIowi+zMmC9Xpl6ZRr4mu3fiLydfv/fnQEIwVNH3cYbet zjXy0VPlPQQ816180TCubf311sKkR3VE2YCxK7ykcSFIxmu60p4G3z5oxTNMNGvYJNNb +791HqotOvhW6+/eua3diaNHkaWimAOxRAb+LZA22uNiycDJdXCJAKjO3dr4/8ReLAG1 UIM4ynNuqW7UHOFlqebVItk84VxL/0+7uzBj9i9Ncca+C07cAnNuI9HWlBTPSUFlbdfk N5K6gkvGGefnWu0Lrsh7s1Bkv1B52ClJQfeLU8c74HF2C1umDGtB1WAqAnUbXyFhMpHw 9qww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739923456; x=1740528256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/ZzceWk0iID3BCJAakMf3N4ITDWrClnL4y6Dzr0jrc8=; b=oSLmkQErrh910YSQc/bB00lj+EkJAEyCtBw6Vpvb4rFDJ/ea7IvuW15H6UAbfYNe+z YhE8Lzvi1/NbxUbxzXFUiHvZQRE6HeIcqOjN7lP9Z2H3PUB12Vuf2eSD0w06vlQvyyBT I/1w7vbiAIsbM0KGPtduqDbU6oN0zACIn/Qu1p2q0jljr8zcCNk5d7c+6Si0xIP3R6R6 trqHzcaOvA0WHjYnk2jc4Fovfdd0FEGTtINbooORjCdHF6JjzPp9tEPsSTZgB9HKHa1p IiI/MYbyxRBsPY29NcOTaa7B5ihYyabqWKRfpRc2VmiRfNVqdi2NCVDZwADoJQ9cLt88 KXdg== X-Forwarded-Encrypted: i=1; AJvYcCU8I1qG2iW2oC/PQ3ufA74zPvnoMXS8CqkT/OTmYhVlLsOURx8f2h3GgZB17p2nhrHgana+yiDRNwQGhC83MeM=@freebsd.org X-Gm-Message-State: AOJu0YyXl5B3fP+2vci4Oj+GsEoHUC6iRbGuOOMmeFU/bQN3ohqJwPk4 vSY++/6YD17vX8X2ACU3mD4wrgIxhc1pDfpSnPcN5HBlLM0Fa8Jrr4mcJ+4F1U7uBdpc+NvZLcO vUlOJtWFhdZ4Q9+/jv9jta9D2oFIkhWR0FLBfWQ== X-Gm-Gg: ASbGncuQnK+CSF/fEBl9T7ZW+GKZh6MEhxzDGXs3h4ReYTs+TUEbHGGgBR23t733wAf au1gZDsq7vCeUeaIQMH3Ee2vpy5+7GnG+LuDA8VhSi8eJxpq3yiTRQh971GReDRbGxX7zmX+p X-Google-Smtp-Source: AGHT+IGmOHtNhuzzepnoM3NVUtu057Vx6Ghslxkq0pMFSuqt+W6E2R8Jo5OP6ZtexaiPJwOtUolkVbdKpsjFvfZ3qPo= X-Received: by 2002:a17:90b:4e85:b0:2ee:c9b6:c267 with SMTP id 98e67ed59e1d1-2fcb5a14805mr2250009a91.9.1739923456189; Tue, 18 Feb 2025 16:04:16 -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: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> In-Reply-To: From: Warner Losh Date: Tue, 18 Feb 2025 17:04:05 -0700 X-Gm-Features: AWEUYZlpDAmHUcpsgB-hX8UQOEvgMG4qT2s6O_2pZIj-zL-1JDnwboP-noSs3uU Message-ID: Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? To: Mark Millard Cc: freebsd-arm , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000008b02b5062e737fae" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4YyGpV2KqKz3ZVY X-Spamd-Bar: ---- --0000000000008b02b5062e737fae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2025 at 4:57=E2=80=AFPM Mark Millard wr= ote: > On Feb 18, 2025, at 14:01, Warner Losh wrote: > > > > On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh wr= ote: > >> > >> On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard > wrote: > >>> [This seems likely to not be limited to main [so: 15 as stands]. > >>> But I'm using main as the example for the issue.] > >>> > >>> In: > >>> > >>> # man 5 device.hints > >>> DEVICE.HINTS(5) FreeBSD File Formats Manual > DEVICE.HINTS(5) > >>> > >>> NAME > >>> device.hints =E2=80=93 device resource hints > >>> > >>> . . . > >>> > >>> FILES > >>> /boot/device.hints Device resource hint= s > file. > >>> /sys/ARCH/conf/GENERIC.hints Sample resource hint= s > for the > >>> GENERIC kernel. > >>> /sys/ARCH/conf/NOTES Notes on the kernel > >>> configuration file > and device > >>> resource hints. > >>> . . . > >>> > >>> > >>> > >>> For reference: > >>> > >>> # find -s / -name GENERIC.hints -print > >>> /usr/src/sys/amd64/conf/GENERIC.hints > >>> /usr/src/sys/i386/conf/GENERIC.hints > >>> /usr/src/sys/powerpc/conf/GENERIC.hints > >>> > >>> > >>> Multiple points: > >>> > >>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no > >>> such GENERIC.hints file. The same goes for riscv64 > >>> (riscv?). > >>> > >>> The intent for powerpc64 , powerpc64le , and powerpcspe > >>> may have the same issue. > >>> > >>> > >>> ) At least for how the local systems were installed, there > >>> is no such place predefined as /sys/ , not even as a > >>> symbolic link. "man 7 hier" does not list such. > >>> > >>> So it seems /sys -> /usr/src/sys is intended. (But > >>> /usr/src/ need not have been populated, leaving a > >>> lack of any GENERIC.hints in such a case.) > >>> > >>> Best to not to depend on /sys in the notation shown? > >>> > >>> > >>> ) The /ARCH/ reference is unclear vs. MACHINE, > >>> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths > >>> existing for GENERIC.hints do not help because they > >>> all allow MACHINE =3D=3D MACHINE_CPUARCH , > >>> MACHINE =3D=3D MACHINE_ARCH , and > >>> MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the > >>> NOTE paths: > >> > >> Like all things kernel, it's MACHINE. > >> > >>> # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more > >>> /usr/src/sys/amd64/conf/NOTES > >>> /usr/src/sys/arm/conf/NOTES > >>> /usr/src/sys/arm64/conf/NOTES > >>> /usr/src/sys/conf/NOTES > >>> /usr/src/sys/i386/conf/NOTES > >>> /usr/src/sys/powerpc/conf/NOTES > >>> /usr/src/sys/riscv/conf/NOTES > >>> /usr/src/sys/x86/conf/NOTES > >>> > >>> None of of the MACHINE* are right: x86 is not one of > >>> any of the 3. Otherwise /arm64/conf/NOTES would suggest > >>> MACHINE as the only possibility if /ARCH/ was uniform > >>> for relative to the 3 MACHINE* possibilities. So?: > >>> > >>> /usr/src/sys/arm64/conf/GENERIC.hints > >>> /usr/src/sys/arm/conf/GENERIC.hints > >>> /usr/src/sys/riscv/conf/GENERIC.hints > >>> > >>> with no aarch64 , armv7 , powerpc64* , powerpcspe , or > >>> riscv64 examples? > >> > >> We store these in /dev/null these days :). > >> > >> I'll create empty ones for this. > > > > https://reviews.freebsd.org/D49052 > > Thanks. > > > Just to expand a little: These platforms don't have legacy devices > > they need to hard-wire in various ways, unlike the other platforms. > > However, people use them to do device instance wiring, so I've created > > the empty ones. > > An example can also be disabling something that needs to be avoided > for some unusual reason, such as avoiding virtio_gpu under parallels > on aarch64 macOS. (I've not tested doing that yet.) > I'm open to commenting out such things. Warner --0000000000008b02b5062e737fae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 18,= 2025 at 4:57=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wrote:
On Feb 18, 2025, at 14:01, Warner Losh <imp@bsdimp.com> wrote:
>
> On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote:
>>
>> On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard <marklmi@yahoo.com> w= rote:
>>> [This seems likely to not be limited to main [so: 15 as stands= ].
>>> But I'm using main as the example for the issue.]
>>>
>>> In:
>>>
>>> # man 5 device.hints
>>> DEVICE.HINTS(5)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBS= D File Formats Manual=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DEVICE.HINTS(5)
>>>
>>> NAME
>>>=C2=A0 =C2=A0 =C2=A0 device.hints =E2=80=93 device resource hin= ts
>>>
>>> . . .
>>>
>>> FILES
>>>=C2=A0 =C2=A0 =C2=A0 /boot/device.hints=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 Device r= esource hints file.
>>>=C2=A0 =C2=A0 =C2=A0 /sys/ARCH/conf/GENERIC.hints=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sample resource hints for the
>>>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GENERIC kernel.
>>>=C2=A0 =C2=A0 =C2=A0 /sys/ARCH/conf/NOTES=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notes on the= kernel
>>>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration file and device
>>>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resource hints.
>>> . . .
>>>
>>>
>>>
>>> For reference:
>>>
>>> # find -s / -name GENERIC.hints -print
>>> /usr/src/sys/amd64/conf/GENERIC.hints
>>> /usr/src/sys/i386/conf/GENERIC.hints
>>> /usr/src/sys/powerpc/conf/GENERIC.hints
>>>
>>>
>>> Multiple points:
>>>
>>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no
>>>=C2=A0 =C2=A0such GENERIC.hints file. The same goes for riscv64=
>>>=C2=A0 =C2=A0(riscv?).
>>>
>>>=C2=A0 =C2=A0The intent for powerpc64 , powerpc64le , and power= pcspe
>>>=C2=A0 =C2=A0may have the same issue.
>>>
>>>
>>> ) At least for how the local systems were installed, there
>>>=C2=A0 =C2=A0is no such place predefined as /sys/ , not=C2=A0 = =C2=A0even as a
>>>=C2=A0 =C2=A0symbolic link. "man 7 hier" does not lis= t such.
>>>
>>>=C2=A0 =C2=A0So it seems /sys -> /usr/src/sys is intended. (= But
>>>=C2=A0 =C2=A0/usr/src/ need not have been populated, leaving a<= br> >>>=C2=A0 =C2=A0lack of any GENERIC.hints in such a case.)
>>>
>>>=C2=A0 =C2=A0Best to not to depend on /sys in the notation show= n?
>>>
>>>
>>> ) The /ARCH/ reference is unclear vs. MACHINE,
>>>=C2=A0 =C2=A0MACHINE_CPUARCH, and MACHINE_ARCH. The example pat= hs
>>>=C2=A0 =C2=A0existing for GENERIC.hints do not help because the= y
>>>=C2=A0 =C2=A0all allow MACHINE =3D=3D MACHINE_CPUARCH ,
>>>=C2=A0 =C2=A0MACHINE =3D=3D MACHINE_ARCH , and
>>>=C2=A0 =C2=A0MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, base= d on the
>>>=C2=A0 =C2=A0NOTE paths:
>>
>> Like all things kernel, it's MACHINE.
>>
>>>=C2=A0 =C2=A0# find -s /usr/src/ -name NOTES -print | grep /con= f/NOTES | more
>>>=C2=A0 =C2=A0/usr/src/sys/amd64/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/arm/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/arm64/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/i386/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/powerpc/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/riscv/conf/NOTES
>>>=C2=A0 =C2=A0/usr/src/sys/x86/conf/NOTES
>>>
>>>=C2=A0 =C2=A0None of of the MACHINE* are right: x86 is not one = of
>>>=C2=A0 =C2=A0any of the 3. Otherwise /arm64/conf/NOTES would su= ggest
>>>=C2=A0 =C2=A0MACHINE as the only possibility if /ARCH/ was unif= orm
>>>=C2=A0 =C2=A0for relative to the 3 MACHINE* possibilities. So?:=
>>>
>>>=C2=A0 =C2=A0/usr/src/sys/arm64/conf/GENERIC.hints
>>>=C2=A0 =C2=A0/usr/src/sys/arm/conf/GENERIC.hints
>>>=C2=A0 =C2=A0/usr/src/sys/riscv/conf/GENERIC.hints
>>>
>>>=C2=A0 =C2=A0with no aarch64 , armv7 , powerpc64* , powerpcspe = , or
>>>=C2=A0 =C2=A0riscv64 examples?
>>
>> We store these in /dev/null these days :).
>>
>> I'll create empty ones for this.
>
>=C2=A0 https://reviews.freebsd.org/D49052

Thanks.

> Just to expand a little: These platforms don't have legacy devices=
> they need to hard-wire in various ways, unlike the other platforms. > However, people use them to do device instance wiring, so I've cre= ated
> the empty ones.

An example can also be disabling something that needs to be avoided
for some unusual reason, such as avoiding virtio_gpu under parallels
on aarch64 macOS. (I've not tested doing that yet.)

I'm open to commenting out such things.

=
Warner=C2=A0
--0000000000008b02b5062e737fae-- From nobody Wed Feb 19 04:13: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 4YyNKt6ZGcz5nj3F for ; Wed, 19 Feb 2025 04:13:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YyNKt3B1Gz47Mw for ; Wed, 19 Feb 2025 04:13:22 +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=1739938399; bh=D43hUJzskcm6wUNPeP2XKb99J6MI0MWozQsWS3OJqwY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QxZmhcrmDtid9YbhQ/itkhTd5Smy2JP5tqGdQ1Uzr/DRC/V7tILpTv+8IufG2CiyddGvsvLmw5B0i8ApVrloIZtYURYkgXUhY7fnLJ2A9eQrUWdbVlxWZp2qKGGXP0PuhdhBmEodLi15xBOe2ir7sL3WwkUnfJ09N2z3zTcyOWyZlmI7YfA4TaysrKiI1hB5RgnnQcLVQNQKD4pSRJLdqFl+J4GW/yw3EA16qRU6phJuI0VOONxumS8xZdHkUN6LkSlakxG6ctohS1irzUFmX34IhSbaWhRUJdANp1A7atmYtjvIYmkMpw9HT9NzACy4XSVcUBjm+MsKZhawgoKJNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739938399; bh=PKPbaRtc9EsiHKxRN/FFnLqGQ1zhd+DemM35ErvYTb3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ks6Tk/VpsrNckg1IeA+CmKStXoDJy3WxmYXvgAIkRvSVaVWzoi21HcVhDx5CnkC5vM0Of89T2o5GR5wvkmDBm6ZqSZg1HDo/chj7K/n7tsgUtNWSS/Z0dT7FCvV/VSQZQJLYurazR5xbYLfPs693QZimMwhMwlnLcLu/m2Sbs+dkN9V7rLq7QEIWlTuQyUNWkDSebvGT/ajdAug7xpyUjZ15bMUs/lLcVrhyuXE0V3XrgiTf2bvtBKLVwwRWonsdh8Y3VcVZTQ/OZf3gY3xH9dYCycKLJnJHnily/eaUuf+pJbHRCG+Foy/o0vrBGIpCsvfEfzws6ahZbhAhEN5W7A== X-YMail-OSG: l_Tm5r0VM1kdBNGeaeT4erJTdTOgxH0aKEbRRRdcuCr2ukTO3srQ6X4y3MXlb44 YuENIfYsYeiMUtAIlljb.OhLXzJda8p4U9h1Qb9j.SysOMUJ03EYhYmX5zD_xqL4CRJgE14ypolq oPfjo3SiBPca.9hpvUiRzq0FHnVzTrJiDfdPWE_3yoSqZ1UpR24PBJzbepIwl55swhy46fpcaHND nnzwsZ8vSRpX.KNi7MpZlX4ZM6wJauvc8vj1IRRSsPgcD57eoCU9iMRyqcHvqcsuFvIKjju7LNZO mrrIjpvW5ZbaNYWh2Qr7h6QRUdW7GhXwkMAUWr9FWOfCNOrV0n3qiQ5QYow3XRUxoqRyacwH7bQX .lp9ys_244k_NqKYg9rlevsSJBki9eg_gF5qpcyvMx_6zzXDJ5Ou8W1YciyK7gn3MMicazwzJ4Ji tDea0fmkN3_fM1Q1s3APeswNhof9tNhMpKp7SvJM0BI6yxdxqfEkjjurMFzUvN7gVn37sSMprIDa 1qT2jTFV1Ohy5y.EggIGfASQf1hQkaJxaq0gk.CO0zbd0JG1v_hVWUA1.zNnjaj6ld.QdsxSy54H s5ng3wYsLhVWNuupKfzX.zV.ywhNnHtehPyfXpwjpuooIpJwk23WzK4JLQneuMFkNzzXmBDvmGf5 Kzm9vI6Sn2iikudT4gcd511Ieyc3MeM2Pqy2Mom2GyzYP6IEpLQwb_6Dx7f6W02h_6NAtXoOoPV. Cr.IUP0o.vUVjIa8meaA7pXOh4IMOO5YkdMQcwDZfCPPsefzffE.l2053TgjHdAwdMRwJXxzV3L4 32VJXvC2RpRh3oWzB.IpYHHbgfbYhVqbqkNaXxBq7CEPBIOZvubiLSyckWX9Zb5JCQY6STsx08Pn J_vgykGr.b4mh.bByx2yeXRnGFotrDF7JkAgD4SKNJV_1vYwlOk8_KYtxoECvyd8lnXpTh6sneAS .3nssbGbqRXZx5sNN_rwCrYrh0PlILLt4qMDAM74Vsv5uKHGVlRfgXpkRbHzAy13hS9QjKBgEFTx JLYiHNINZRwEmMTlNjdxXe1s6LvJXAOqgOVcLG9YDEqoevQhEj1h8I4VYbyuMENq_7m8BgCRNCSc f.uk3jsUQNpp78rmtWEH23BbO4f8GhzFj0YqG.A6c974G.l5E7BQ2.g3QS_FiLEhSfXFzP0F0Akn FmEokqYaaEw1GNtoNblsZUkhVJToCzwQB5UvMglvR8nWAQV8FQMfcMrNsD1Va2.uMPvYTDT9iD4P 405eDPsKVIObCqMMewgJNxagwUIyYR9X8bhtcDqchUTagESimJs_VMrF1uz4p4h4FmhtY3Kl3dwl B1vVb8FYNtc8RbWtihgA.iwzYucjC1KtVsqZdAAjQUsL1dTvGIUn4zR7p8AEBuIn0h2wXp4Qyboj eNR4YjFUmTlmJm6vCYjTmQvw6bVpk.fmEd4nwtkA8qVLPoz1nHN5hcsd5njURNHHIyJRYDZT2yDW 6uqzK6vSkeNM2x089FzftxgmRqgC9ctn43TRGkl8VMBrlNOseexuWhytFmjIKGg6OtzGnPBD.Z98 NFgKnWJOakVX7PsYU1rtwXnQ3kyplhr2C8Y5P9bpRfUu67eNX9w2Pcve5vmRC2nVQmiFSMnGdmPu siFsILG4S6B23sCJBB.EhgY6LLJP7F9qQnFWSkzsmqZKnY0k38ju7fRXBiCsiWZ_7qWsn2C8K4jo 9BvmpQVFvgUC.faSaKtjeVs.iq9ZpTnw5NAOAo1lNiuQ3d48Cp4mM1DnAclasFJwiyFVlEehJ2Vs SIME3OuWGCxjpBOLKcgrpKHni1K63zVBAlPTGEPbm_EK9CaJ.5QeY_2V5ZoKM2AlE2dYcK6HbhCq XANaKsMRG1O4wHipC12Z.ihnbdagsizM5ANp9j1J9VdVj.B9twk95U.8R3DpKlpkzZVYD3ccfm8T pMOIec3_BXiGtr0_Ff9zps.J5vA8h7gQtQRtU9oL3i5yItvCwbDRMm_0yNDBWO1FF0ccO4XzmySY RvkBclrQkXxtk14m_OKh5.bevQyx1v5y9lQXJjqaFbYIO2Gjzgv8pkQOhshtpFlGKRaI2jFCNTuL kyVMo1HK2RECds8Yjn.fyGdKb4wDbbd8F9ptHvKV_dosi6vIVODBN4uLipqVR1vY3tk2vpo5WXol crUeWfcIEyHBlddyP9LkI1DR7NoyhkFNaoaVIsdkEaI9s1MsgY3p9hR5jJnOjHxKXWCOLHvAyKvx 7Ul6qnH8_ZF1kY1g_1KkIzCkLIiphdLx.m45Lfu3X5FoHhnHS2Q5fGQ8vu8oVQ93YhoqYvVUzGr5 K3Hw5 X-Sonic-MF: X-Sonic-ID: 1b1727a7-0887-4ac6-ab3d-bfb497ce8434 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Feb 2025 04:13:19 +0000 Received: by hermes--production-gq1-5dd4b47f46-dvwsq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c10ab92819725e4baf9698b75286e7d0; Wed, 19 Feb 2025 04:13:16 +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.400.131.1.6\)) Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? From: Mark Millard In-Reply-To: Date: Tue, 18 Feb 2025 20:13:05 -0800 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4YyNKt3B1Gz47Mw X-Spamd-Bar: ---- On Feb 18, 2025, at 16:04, Warner Losh wrote: > On Tue, Feb 18, 2025 at 4:57=E2=80=AFPM Mark Millard = wrote: >> On Feb 18, 2025, at 14:01, Warner Losh wrote: >> >=20 >> > On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh = wrote: >> >>=20 >> >> On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard = wrote: >> >>> [This seems likely to not be limited to main [so: 15 as stands]. >> >>> But I'm using main as the example for the issue.] >> >>>=20 >> >>> In: >> >>>=20 >> >>> # man 5 device.hints >> >>> DEVICE.HINTS(5) FreeBSD File Formats Manual = DEVICE.HINTS(5) >> >>>=20 >> >>> NAME >> >>> device.hints =E2=80=93 device resource hints >> >>>=20 >> >>> . . . >> >>>=20 >> >>> FILES >> >>> /boot/device.hints Device resource = hints file. >> >>> /sys/ARCH/conf/GENERIC.hints Sample resource = hints for the >> >>> GENERIC kernel. >> >>> /sys/ARCH/conf/NOTES Notes on the = kernel >> >>> configuration = file and device >> >>> resource hints. >> >>> . . . >> >>>=20 >> >>>=20 >> >>>=20 >> >>> For reference: >> >>>=20 >> >>> # find -s / -name GENERIC.hints -print >> >>> /usr/src/sys/amd64/conf/GENERIC.hints >> >>> /usr/src/sys/i386/conf/GENERIC.hints >> >>> /usr/src/sys/powerpc/conf/GENERIC.hints >> >>>=20 >> >>>=20 >> >>> Multiple points: >> >>>=20 >> >>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no >> >>> such GENERIC.hints file. The same goes for riscv64 >> >>> (riscv?). >> >>>=20 >> >>> The intent for powerpc64 , powerpc64le , and powerpcspe >> >>> may have the same issue. >> >>>=20 >> >>>=20 >> >>> ) At least for how the local systems were installed, there >> >>> is no such place predefined as /sys/ , not even as a >> >>> symbolic link. "man 7 hier" does not list such. >> >>>=20 >> >>> So it seems /sys -> /usr/src/sys is intended. (But >> >>> /usr/src/ need not have been populated, leaving a >> >>> lack of any GENERIC.hints in such a case.) >> >>>=20 >> >>> Best to not to depend on /sys in the notation shown? >> >>>=20 >> >>>=20 >> >>> ) The /ARCH/ reference is unclear vs. MACHINE, >> >>> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths >> >>> existing for GENERIC.hints do not help because they >> >>> all allow MACHINE =3D=3D MACHINE_CPUARCH , >> >>> MACHINE =3D=3D MACHINE_ARCH , and >> >>> MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the >> >>> NOTE paths: >> >>=20 >> >> Like all things kernel, it's MACHINE. >> >>=20 >> >>> # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | = more >> >>> /usr/src/sys/amd64/conf/NOTES >> >>> /usr/src/sys/arm/conf/NOTES >> >>> /usr/src/sys/arm64/conf/NOTES >> >>> /usr/src/sys/conf/NOTES >> >>> /usr/src/sys/i386/conf/NOTES >> >>> /usr/src/sys/powerpc/conf/NOTES >> >>> /usr/src/sys/riscv/conf/NOTES >> >>> /usr/src/sys/x86/conf/NOTES >> >>>=20 >> >>> None of of the MACHINE* are right: x86 is not one of >> >>> any of the 3. Otherwise /arm64/conf/NOTES would suggest >> >>> MACHINE as the only possibility if /ARCH/ was uniform >> >>> for relative to the 3 MACHINE* possibilities. So?: >> >>>=20 >> >>> /usr/src/sys/arm64/conf/GENERIC.hints >> >>> /usr/src/sys/arm/conf/GENERIC.hints >> >>> /usr/src/sys/riscv/conf/GENERIC.hints >> >>>=20 >> >>> with no aarch64 , armv7 , powerpc64* , powerpcspe , or >> >>> riscv64 examples? >> >>=20 >> >> We store these in /dev/null these days :). >> >>=20 >> >> I'll create empty ones for this. >> >=20 >> > https://reviews.freebsd.org/D49052 >>=20 >> Thanks. >>=20 >> > Just to expand a little: These platforms don't have legacy devices >> > they need to hard-wire in various ways, unlike the other platforms. >> > However, people use them to do device instance wiring, so I've = created >> > the empty ones. >>=20 >> An example can also be disabling something that needs to be avoided >> for some unusual reason, such as avoiding virtio_gpu under parallels >> on aarch64 macOS. (I've not tested doing that yet.) >=20 > I'm open to commenting out such things. So I reenabled having virtio_gpu in my kernel builds, rebuilt, and then installed the update. I then created: # more /boot/device.hints=20 # This is for virtio_gpu --for avoiding its use under Parallels: # dmesg -a | grep -i "virtio.*gpu" # virtio_pci1: mem = 0x10000000-0x17ffffff,0x18008000-0x18008fff,0x18000000-0x18003fff at = device 10.0 on pci0 hint.virtio_pci.1.disabled=3D"1" On reboot virtio_gpu was not substituted for efifb . Strings on the kernel.CA76-NODBG/kernel showed virtio_gpu was again present and kernel.CA76-NODBG.old/kernel showed no such text. In other words: it all worked just fine. I do not know if some variation of this would make a good commented-out example in /usr/src/sys/arm64/conf/GENERIC.hints or not. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 19 17:05: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 4YyjSh5Z5cz5pcRV for ; Wed, 19 Feb 2025 17:05:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YyjSh2KXPz3htj for ; Wed, 19 Feb 2025 17:05:24 +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=1739984723; bh=QSLsq8mT6lzPJWSrjr46zRvRkfyxBRy+QD1Axtf0CEY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hofZaRrrI9zsoDz+0noUM+MWEMmUfRECInBlUm63G9XTexmvp8Uz6xavVQXIRqAxEOiqC6Gwhaz8TGo8sePNo525fV36/KiNqztfhcjRS2Slv6v/AzbauHqq8Gz6zeB+Av9UsxAQu76VKnJj6KGoU4/ZH81uBoC5IQBCGsPsArMCWeD2eUkR+YyKDo1X96+EvSVcFAc29iRvUc92fuKkTpr5u1Rv0qsxDf0shw/j5QT1IVbsxdKRM7LzPjx+rysq9W+FhoTrsFWWLDeF29Kh+GsBDR+zw1Ayw6znQZf+9o6D1wko2eyp1s/fgHyWk+HpKWHhpx1tKDMmbd170aSIRQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739984723; bh=6Tkq0jSN2Uv/CKHfGqXBv+uG8GIgM3sgvybWcERh0qh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=imzzYqAGmwsrd14+ZntTtIx0IjrEUsJ04xT8Yxo+QpWITWMeIfO+sqW8A4OKqeEXBF4sN4OkQY6LK/bKNwkZlJRZqL5hDyv/SBAHXkClonNQHWCfgBDM3/TDz5Q5tGbELCRyGaLQaTOwXgpmf7+akqooWpRd1exQmaM3KUjH4XZ9o30mD8i4/qmMTjsBA8JLILSGMVrGDm0MXaqSrqmivgzplpKh3xlbXzzeu0DkZflfWSjW6788hJ6o7PPbi15VyvhADGxqNAUH/oBIgaRYe7yPgIsgdnFhASSnu6ewWc7W5fjozTZB/rwEUU+Mlovm21ILwj8fsotTf2QIx0Vi3Q== X-YMail-OSG: Ao8WRlwVM1nvFPaCDHuO47lTMobL6IFIJi2mldD2OGypvxh9k8MI8mRLUfiuy5c By1QgZsTGknrH3_MulRYhZ9C0FuuGJzcOiGUhYSgQH2IYrflDCEbvlZQZY36PB649I89h3FQqNTv g_HUvzmeGnuYSw9gw7T02IPuhaOOMg1upAbn5H1YiT4B5jB4yBETGr2ZQI8N20PUMzf1xNY8mFRg opd3jWLP0kbZN6tNEAVDlbS8zJ850tzHgsfy7fViHIgXEeFddonKjmPik0xM_aYV9_3Hh10zClsC FiN42aeGqxIzYP0Fe4pJAXZwWecOZCN.Nq2St0ULAk3P5Y95X433H37qSsuYsH5tdQi50tTCJ8y3 SlQh1XusirtUDiWZhKTJfpDo2HvBvb7jEug04VMOgayDYApi9eJnDiK.99fRqB4YMdQhVrNWRL.q prcSuKU1IBkArCXYkINY7Uz.Yv4gh.DAS.cPPZXDopzUPKZKV8Lbnxzb31JKHkq5llVeJDBwlxGr Df6NUj.XeCPl9PvZ8r_KryXaY2fhb8hyWxN.r4XYDG_8QsqZFDS.b.D6OrT0b9ezESoDz3fcGgUX 0GETPzpMl105pJen9qowXl_8I_G6A_BWhqDp.wbVWHPmtzK_c_4k1Y70l4cjfbBIPXoYig2siOYy QOBBQYA_nDnoBAcWNbBWhWRNr24M_OcNTvnqyzsA0fkoeSqVjJqJpDXMTMI0SFTXAjAjQ07CVpvf KE6FLMwS8wNE6srKaMI2jbxqkXKpb_65xiZ3JPEwJfkT4mnwLZ8xtglVinDRxIhKiG0FacA9nQV1 Ca5Rxcvsnuf_UKXxs9UPwC6Tf4UHho0IludH.eVdwwQVm_.GJh5hd6jpommzhIC94aZgEzv6D2rA jUU.9Xr2w5X3R.I5QCzgexooktlABL9gpOy9XdBcEVXhT3IURH95b4YKZnxTj.f3Y42Qpde79yoU VrJh.j8ZvP.0ryVM4vWB_XbHWnQDDQtYCinHn8MyX9VvXPiNAaPd2oqMVnYnW23_Ydq7yHTYWhB3 JHLuEQVZdV1O3x5CEKJFt7w0xZCe46UAStvj8oBEgpfdfQIadMe.fu_FTKwPOI0UcjodxkV6kw4n Sr5oT4zvvXFafMnWR_mf491uToV7z1jwnsHaqWZ5a0pYmuOf6MENjBRml0Uri7QslE16477skMND jX1zDYPO05Ow7YMPurI4MhznwQjF81Y0Act9blSIDTuMIPlPjPCJMpJJgZ0BfydadyyLsj9LeQTo KrZgP1WQToBIPWSBAC63TTLOc2f89sMTJAviNraIv_LuabEnS0tI07CKP_Glcr4TIrRT9JBJyoxs vFbMtB7arpYIUSmrkIOWAd0N6X2ETX4T6kaqaFF3Rw1A0r5WWgfUDQeopKsI3rACOtEApK_uSBRk aq33SxceJ2IEGG59sLYivA_Ns97v49PKJt2ZKmpiqtOOCbLRac2UD7XJZG2657vxsV2N6tdjy31a ELSd1FaD.pVslPtrFcWtjB0wOwh97_2GtROF0CTj.eBV6MGom4WmpQ3P94.f_Rl3B1fR3_7oPSA_ xy5mXbfbv.nKoMeXr1lpBLK3Oz1lCeAiTt08rKLQLWhpKp8ZPvUkjllYr2TFvcrV27DG6WLhNXVE EBQxxwW7_BoBep1X66wuDszxGSMrwMeArcoGhlxv18yVEWMSJF4wVQ0QYIj0u0XOYZs8BUZwaN9Q JVQ.e2RJ08KQB5L7HvmNzyhcglUdsTaHhM2EXNHdfMenvZWIxq1OCj3YCch6DC.ye0HqjzylYMYR QB5j5G62vX3v03qVtgiDkiB2Ackwdfc5vtSNQ.JeUURk6w0bj8cfRC2TkO1b3S7vILkR45s8L55b GOHliT4eez2tNfaB9bbpEQGYbDrRC3GXLlNd1wpS72LUXqHfBZh30mWcK1i.156pthia_A5c6dRt QclAyjUClErsQtTwSVHxxDaGMTKxJ3I3gYFzqbk3U3Iymwntanvj4RgaHVkB.DxxgKqVlTbXvYNC 1UEv__iHVRu_IW5fGtIdgAXTpwA_5l0SuEhQACEQ1MHi0tKGOmcxAtsoxD64qzqgieCGq0v4duMB E1oIYeYHDdPDrL07TqTIZEdhmriLVVlMvpwo87IpfaZvzywYqLHlsX1VFjvnyy52.z5J60rNAHKc yF3t11VMVAgez.9ahDU1ZsYlyNxpaMrt4WA.rhaMSast1ZVKX5aPuI2aWoarzkAwBDUXfQQr6ZAw AJ7_fbrxXSQH8jEzZ1GnutK8OE2.VSK9IYYazD4iT7NrsgvhqD92OcZknNQU.rfFmQUgU7HGgKxa r6L2tNrhAxxiEYCFu X-Sonic-MF: X-Sonic-ID: c274e576-99b4-45b0-96e5-b95b3ce76512 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Feb 2025 17:05:23 +0000 Received: by hermes--production-gq1-5dd4b47f46-pfhh2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f145458b591bf6372b419f15049224a; Wed, 19 Feb 2025 17:05:18 +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.400.131.1.6\)) Subject: [Retitled!] some under-VM detections for non-amd64 may be broken From: Mark Millard In-Reply-To: Date: Wed, 19 Feb 2025 09:05:07 -0800 Cc: Jason Bacon Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4YyjSh2KXPz3htj X-Spamd-Bar: ---- On Feb 19, 2025, at 05:24, Jason Bacon wrote: >=20 > On 2/18/25 20:13, Mark Millard wrote: >> Something I possibly should have done --but did not do was to set: >> kern.hz=3D100 >=20 > I stopped doing this under VirtualBox a few years ago, because it was = causing clock skew. Apparently an assumption of 1000 was hard-coded = into the FreeBSD kernel at a couple places. Not sure if this has been = fixed. If anyone is using an aarch64 VM, it may not be obvious if FreeBSD is "aware" of running in a VM. For Parallels, the detection of the VM for an amd64(/i386) VM does not work for an aarch64 Parallels VM. Folks using aarch64 VMs (or other non-amd64/i386 VMs) may want to check on the status of (using my Parallels context as an example): # kenv smbios.system.product Parallels ARM Virtual Machine # sysctl kern.vm_guest kern.vm_guest: none # sysctl kern.hz kern.hz: 1000 The "none" and "1000" indicate a lack of FreeBSD having any status indicating it is running in a VM. In this case, the detection would be via smbios.system.product content. Other VM contexts might also have distinct names for ARM (or other) contexts compared to the historical amd64/i386 ones. sys/dev/smbios/smbios_subr.c has: static const struct { const char *vm_pname; int vm_guest; } vm_pnames[] =3D { { "VMware Virtual Platform", VM_GUEST_VMWARE }, { "Virtual Machine", VM_GUEST_VM }, /* Microsoft = VirtualPC */ { "QEMU Virtual Machine", VM_GUEST_VM }, { "VirtualBox", VM_GUEST_VBOX }, { "Parallels Virtual Platform", VM_GUEST_PARALLELS }, { "KVM", VM_GUEST_KVM }, }; None of those names are explicit about aarch64 or ARM or the like but Parallels' naming is explicit vs. amd64/i386. Parallels might not be the only context to make such a distinction. Some detections are not via this smbios.system.product text matching. So kern.vm_guest and kern.hz may indicate having the under-VM status recording set up, even if there is no text match for smbios.system.product . Going the other way for Jason's note: It may not be obvious if kern.hz is already set to 100, even if you do not want it set that way. Another example might be if new VM contexts should be added, such as UTM for macOS. What do kenv smbios.system.product , sysctl kern.vm_guest , and sysctl kern.hz report for UTM on: ) amd64 macOS ) aarch64 macOS ) . . . ? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 19 17:42:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YykHh4xzXz5nQcy; Wed, 19 Feb 2025 17:42:40 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YykHh4Jrdz3nq9; Wed, 19 Feb 2025 17:42:40 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739986960; 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=cjl1tauh42rnrGBu6vP+ZELwUpxiA2GENY7FXGfSVcI=; b=c3/SjLmtAVigUy0mmkKCwWWBXfu6E4izVatZ011Kfh7x5e4gvihLH2ba4v7oAkrg1U7WS4 cb1GPt2ly6YwJdVmlyMBKs+NDzwjxSwIu4Gatu5hdM8gdGNcYgvUjQFdeZ17PEgjmGx0By 8EY7i2RUaAxIdxgFiRkaVhC/jwUo8AtKg7PaHr7CKdKoStbm8wWfhOD/TdLB351PgQSwLW 9if8bjhjHLtpPlP4X4ZWwt5Y7zgqykQBHYy2IJZri4ggA6OpPTP6Whz/KCJyR5zY1VhMSs 7M9W0ReskOj4/+gUpG+MayZbrsxNDZxMRuXrZQ55hOHGLCqn1G+HCN4JsYPsVg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1739986960; a=rsa-sha256; cv=none; b=o4ePriu8TuvVlrlRwxM+H8PFtahtHaqC5PoxFJeuty58wDQbwCCCpjqKDjUHrJC1ueKNs/ FO0P+czBl4qTfkf4wcui6TxxM/P0jUMAVBjDKSjAhgdNDgr/MWWqghUxnkd8EDPptb0K3C bQRN9YHFhHm9jyaD4iXwqJAyVTKI2+wH+/PgBfkiGQwEF1MZio3mIDejEUcL15FJw3FJC6 NaIeyCSR/LvTrmkMsGk9wtV+ZMZ/0QU9H7p2rnnWFD5CDGqIBG+mrllq43wi5HJVnY5qDL xNgU2xpHeysJ37PU3BwPMJpi5kIMaFQYACL1b5qsxnAusAWb2ZPBwtcl5/YYIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739986960; 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=cjl1tauh42rnrGBu6vP+ZELwUpxiA2GENY7FXGfSVcI=; b=bTfh2oJ61mGKc8Qf+cVZDxEq2rxBaGOn/rkjby0KrOS9uXib3qNCuKtrAlvOnGlI2O9NOT 3rKZt8BHYazweKnqLd8/IV1VllNbPnJ2sYcfeqg6AsIu6/JSsxjBgpYX4UmGH6K1StYhqn YGvfEEkWL5uoV69oIQqi3QMxCi8bPpUPqxciQlcTIKXrBPfiPOzXg7O70jwOAyaKEtZxF9 FzsxHg9O3AoRKt16IBrkbQfXpu4BxINUnfkPDcxQ6SlvHDbXfE763dNBlhWIDKjgH0WUSo eobltZDdbQpr9hY7dIYcDGOMixftIF+eHjF/mS56US4ZXVcExeMnWtArw+xIuw== Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YykHh3KB2zBt9; Wed, 19 Feb 2025 17:42:40 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-471f88518c8so239801cf.0; Wed, 19 Feb 2025 09:42:40 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXt2D++ydadKRO6Iel2iYbcbnyJibBY5H+SrFJFCCvMji57UVH7q9x/+26lm8xx1xsceYgc8Q8fpGMj9F1ixok=@freebsd.org X-Gm-Message-State: AOJu0YwpggRcX0cIykd3ArpldPE9B4x8Mq1mXrJgfLqdSpacazRbHsvK uEdeiPd3D7tFBa12dD/x06Tsa67iMWlh814CPz3Ncj/+Sl4Q0GKqgxsxiooMqXy2eMVHHUXTg/1 C4U4A4i8wfpM9/lD25GaGoHDNjm8= X-Google-Smtp-Source: AGHT+IEeXFYeQRvSzVPJxkGFHu64jApwrT2pG+LnJSge/H2f0Tu2yn0wYJ5Te2xeU2OhMjRC1ITL8q56SIllTvvmA+k= X-Received: by 2002:a05:6214:ace:b0:6d8:9d28:ff07 with SMTP id 6a1803df08f44-6e6975bd7abmr60516666d6.45.1739986959974; Wed, 19 Feb 2025 09:42:39 -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: In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 19 Feb 2025 18:42:28 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZlv4SJj1Zar5aK1S8TB7mV5QdiAAxFosdR-POih8Xpbicffy6MTBEkarQ8 Message-ID: Subject: Re: [Retitled!] some under-VM detections for non-amd64 may be broken To: Mark Millard Cc: freebsd-arm , FreeBSD Current , Jason Bacon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2025 at 6:05=E2=80=AFPM Mark Millard wr= ote: > > Another example might be if new VM contexts should be added, > such as UTM for macOS. What do kenv smbios.system.product , > sysctl kern.vm_guest , and sysctl kern.hz report for UTM on: > > ) amd64 macOS > ) aarch64 macOS > ) . . . ? > Hi, UTM on Apple M3 running aarch64 FreeBSD VM (main branch): olivier@vm:~ $ kenv smbios.system.product QEMU Virtual Machine olivier@vm:~ $ sysctl kern.vm_guest kern.vm_guest: generic olivier@vm:~ $ sysctl kern.hz kern.hz: 100 UTM on Apple Intel running amd64 FreeBSD 14.2 VM: root@freebsd:~ # kenv smbios.system.product Standard PC (Q35 + ICH9, 2009) root@freebsd:~ # sysctl kern.vm_guest kern.vm_guest: generic root@freebsd:~ # sysctl kern.hz kern.hz: 100 UTM on Apple Intel running aarch64 FreeBSD 14.2 VM: root@freebsd:~ # kenv smbios.system.product QEMU Virtual Machine root@freebsd:~ # sysctl kern.vm_guest kern.vm_guest: generic root@freebsd:~ # sysctl kern.hz kern.hz: 100 Regards, Olivier From nobody Wed Feb 19 19:23: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 4YymWx4bg7z5nY4d for ; Wed, 19 Feb 2025 19:23:25 +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 4YymWx1xGvz41YM for ; Wed, 19 Feb 2025 19:23:25 +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=1739993003; bh=7WvTYKcQj8MHQqM16hf9lGASRVAE7gaWPsG09MQoibQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mk+CnSQMzoxiz9PjR5BAheGSotZLX92S72TVUHC0Yc/qFG3sUF2h7eH0grmY4mvru0JeN18Nyk+/XDgagawsK29TQVWt6j1X+uBrFGF8usQ0+wHM4M96uf1e6AKFMQia6Mx2e5Ao3TV4kekj/hCagVE0TMv/N+j5riaTVpJ10f42bhpEmVLkllnAAWlcVKvxVfSMovbyoAo+Gl3I8xaqOGHXJaFjvyNwOfhyD1PGQUCeM7aoJSUEXhCcXpJhRyken8dHRVnjZWZ+4pQwizwAYKq+JRwGgboll5gfypDIkFwUv9zSX9752AOG4MX7+kAVhmUl3qzRtc93jN/HLceAsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739993003; bh=RfYACLw3WJwA7VvcnKRj14QMG+U1GRTU+yOfcfHJA8Y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=I4ITUVgG2iV5Yy+vSPnipD0dguE+JJv+U/bdKvFqYdtvNZSAQe6aJW4QWeNrTMRHt8+hJs5BUQffe2r26/ESH8/dbA6/PbBAGEQJCZF/MvvAuLz6Xa1JLJgWqeuhtRFniRXMnYbqHM2sB8IWQxK4wppESUGzI17mwtMYwTlzZWz+VrO2MaRPvuCFC9C3K7O3cZ7UrbLdfg6chJZa9dbMj60XDWsAeYc/4IlxQg0oeiZOB5MKnhwEdmmNOKTRfIHAaqiPqj5chQSdpsxjVHSPMXk+ohg4An2PJ6vBgHwfUkaiUIuswI5XUJkF+gGV2TdruThHXBtIipZmAB/MdiQEFg== X-YMail-OSG: NewGsY4VM1lSMtH8Gdbku2kM1sm.LOmTWMBz.HNgCOeiBhx65afjpU_azY74.P2 P1mKcjYH7h3RHjfaThoCfkFaAI4B8H4kpYwzhV2mYuEmNuozVb6sofhAqCedQMcCAP9zvuJx5kNN Ixgc_qWGxFZF0VFAsywXCGERLOK0ooixwDVEps6L1QfOkrrOV8IurLv0atdIfrsKupLGGCrCtf4k K7oVfRO8iW1AkXqY8zJTnhQVXSIk_1fsQeCKes5i5RHtemlOtQ9ZhnUOfO4HDNPCx1cscchb_AGb aA959wVvMkn2cjwidzSeLBBRl7evFtC929QA5iY3O6NNVBmsLxKrTetcZVyN2QgOcGOGD0exp7x1 28ua8EYqG2e9Z.VDfqI0.rSr2Ik_ZUO_diRVvfieCAfQgZKc9nOQoJqCbynIGGPRz61lus8dtytu oFiZqmR4tti20lfZrJdwHVqcfnNreGk2b1t2pL2hQQof5gIgAdAii1Mf.V9XliLBudeHi6kEi.Nj ZaZxw2u2JLZrTmeLl7wnyRfIgEG53AESnxDuFS.Lu89aGGbwFRv1XzL8I0_3N.S5MM4utblsyEBx KSuqDiCkZL.qDUMDQmOJR6jMDVfXorEmZysQTs8mMuZD81r9pTPXmwVnVhWr7.wAWW6UKvV2ngaw 2kRBfAlptiNEmeZIdJ2huhI0BAmppg0cA51U3qqzHVYZzJi2rNSqdFfoJDOHTv.I9fFW40bAAfO7 bJb6vbcTTFyY3w9ALA0wltst1_xojuPcuglCq1La3Ju0OmVvVgbl8GFepIo17_72OSvqJ5p0QuyD n74_tYFfY.8idmgz6ho7tSXf8t0WmzT2ijLTKLSDKRab0BPPnjm8.5ncbLazkTpNFqUdYpJ1Tq90 glIGZ53qxam_gMjtEO0aj32vIkcyHAxiQsHKPu7qQGyOoF3JFAJynpRtE.IaAdRxdbHqvVCv_gwk 3btOQd1xkaiaVBlCuj6fuzXfbgrdem.IPgpFyzLJK8tjUQPnxAmJgVCZ1sP2vjqmd8T.OpbsVWSb DAQXstL3vtYsp0MLMHczmy7OfI_GhGR_Lh4N9wHkYVEkxmHEMcLcIlcS2fxqqAiWWo1l6BO4WTcm xQ.sL3jWOUyl4IazGGHwYiiyOqnFSJma1UDehDUmlbOn1.esM.TZOGCqL7aK7nOyVxny8bl9nxld aEtWlZhKNMnukxjbCjNNIcvAeOQZGxkj7BSoZFcFNJHuqGjMa3VbiB71f2gAa1QaHOyDfsMUstOF Z_3ERjHR2gJ6DN7pAsFMN_EL8nCZpEJA8QErf6fV6mh6mNjOH45pM1bi7_Ir.7ByUJygpaZPgLli suUDolitvs9ZXmNO02IMq.4JPz2YaFFitGWs2Kg9Kq3bLt5yaWoGkNqLl5.JYty4T3yJc4mOrumj .DUa8pNEiee9ZMQj40V_Qoz5BEXCfzztOq3vVkZzm4LUnvCPwApQQDkWyGkIrV1gaCBgKIBYlOvd YIJNMT0a7NEMgrGXTY0pBOQtAGoku0htYlqfx2TkrCPLHCtGEN5_D_wV84I94IZO1QYY.sv9ihBy vBm5_VoSoswZZma60Q3CChJHwA.n1qG8USASoolzhiX2DIJ3TqnacD5e2KJhvV.PrO0Z1tkuTscR 0qTVpDQb4HsmLcMAsc4T3P.v43UntaJU7rqF1EtHNnwcHpIabZP0LFuK5ZYwEtQLeljmJi4sEUsD 905WHV4J4zWZds6.cKhF_YqfeNqNNdV5fg1.VkLVmASSHdfanzach1coEdjhHNfHhKKZNMq87SBr QFS4ujMUMsBNZz1Y0HJ_3_aCkq7Zw_nbmiggV4hsC_3V7CYsA04Yrn6Gv2jIG1jVQrCn40mQF3WQ CX0W.XI2iu40p5A9gjNlABaspitdfX1omOUYfO3gBtyETvrP.f0df3naXBHAUbeR9pAtyodrntLO xLYvvBK4KY2hI8jerwTGLpNfhHo9M4h6egTBlDmDO7PG24yHqf48J7IkUt7mCdlOo3DNJdEeKDEv LirgDnmyM6R9IISRxLqTYtamG2Ke04GM1fczD6Rrtp8o8i3ZL.7wTR.KZrdnbLxBkfaAyQQU7SUJ IFMoJM5c5_cIYDCbha2K8D4rrPjDSRgetylwgyZhre2pB8M5uuRytPem7zJRunQno7PuLxfE9DuZ yqoA.sXl5x7E7iGqZOkRNHxH68iRzBBG5GpV74KNtI6X4dz300wZoq6MDIrk44CqQr8NclQ3bK1n FszVgyjr1BDVqsdCHfkQxijlR37qSA2f2TVSuz80_f4pkm_jihXqfNJOvYL.5fJ3b5GYQuiPEp5r CQebp X-Sonic-MF: X-Sonic-ID: c16a1cb9-9ff1-45fb-a689-8c30c794b64f Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Feb 2025 19:23:23 +0000 Received: by hermes--production-gq1-5dd4b47f46-zz6g6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c25411db4cfb4573c2e8424f67dd8666; Wed, 19 Feb 2025 19:23:21 +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.400.131.1.6\)) Subject: Re: [Retitled!] some under-VM detections for non-amd64 may be broken From: Mark Millard In-Reply-To: Date: Wed, 19 Feb 2025 11:23:10 -0800 Cc: freebsd-arm , FreeBSD Current , Jason Bacon Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Olivier_Cochard-Labb=C3=A9?= X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4YymWx1xGvz41YM X-Spamd-Bar: ---- On Feb 19, 2025, at 09:42, Olivier Cochard-Labb=C3=A9 = wrote: > On Wed, Feb 19, 2025 at 6:05=E2=80=AFPM Mark Millard = wrote: >>=20 >> Another example might be if new VM contexts should be added, >> such as UTM for macOS. What do kenv smbios.system.product , >> sysctl kern.vm_guest , and sysctl kern.hz report for UTM on: >>=20 >> ) amd64 macOS >> ) aarch64 macOS >> ) . . . ? >>=20 >=20 > Hi, >=20 > UTM on Apple M3 running aarch64 FreeBSD VM (main branch): >=20 > olivier@vm:~ $ kenv smbios.system.product > QEMU Virtual Machine > olivier@vm:~ $ sysctl kern.vm_guest > kern.vm_guest: generic > olivier@vm:~ $ sysctl kern.hz > kern.hz: 100 >=20 > UTM on Apple Intel running amd64 FreeBSD 14.2 VM: >=20 > root@freebsd:~ # kenv smbios.system.product > Standard PC (Q35 + ICH9, 2009) > root@freebsd:~ # sysctl kern.vm_guest > kern.vm_guest: generic > root@freebsd:~ # sysctl kern.hz > kern.hz: 100 Was the above Apple Virtualization instead of QEMU based virtualization? > UTM on Apple Intel running aarch64 FreeBSD 14.2 VM: >=20 > root@freebsd:~ # kenv smbios.system.product > QEMU Virtual Machine > root@freebsd:~ # sysctl kern.vm_guest > kern.vm_guest: generic > root@freebsd:~ # sysctl kern.hz > kern.hz: 100 Cool. Looks like those 3 types of context worked as expected. Does using Apple Virtualization in UTM allow running FreeBSD enough to see what FreeBSD gets for that type of usage context? (I do not expect Apple Virtualization to have text indicating QEMU, but I could be wrong. But not seeing QEMU might be enough to know it is Apple Virtualization?) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 19 22:40: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 4YyrvP1khqz5nntW for ; Wed, 19 Feb 2025 22:40:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 4YyrvN1m9Cz3WM4 for ; Wed, 19 Feb 2025 22:40:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Az4+Mo5g; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-aaf3c3c104fso61771266b.1 for ; Wed, 19 Feb 2025 14:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740004830; x=1740609630; darn=freebsd.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ztjoNmgpmHRaFEWrRetNkYwTjcbcgqNDM6OEgQ1MrGw=; b=Az4+Mo5gaePn34OYL9WyO+T5Z/XAmkurgA+30xRXFbYRmLX7RuDOy6UGQ8bJN0xGV/ yt7IR2zeaAjAoG4n0PdW/PEA5eVahqIsyG6b6mPVpRwl493ZtTpN1QsgIJlajlRM2p7y kj8bC2rOGgoHWhiL+pzOeZo7NNfshto2SnxAAYt3sWIGGoNy7UUMu2w9p//0baC526ji BkRWmdupYPzUEiXRcICBo11rWUPKafNDGrvdsW9Iw6SinDy5YcJiglYXxdWfHzQW9NiH a8H3mMKIXQLN9IXVDjX5I2qZYAcQ2uUKK+XqzHdVgBOUHnpeGFmvWqeui8jwKDZDDjeo wJGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740004830; x=1740609630; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ztjoNmgpmHRaFEWrRetNkYwTjcbcgqNDM6OEgQ1MrGw=; b=aPqbYE2wCmIXiKKhCHWiXRtTdUR6Xg+iN2iHuWr7qBDqBJfWGpE20cKHxK6prmYCE9 hUQ2OvHO6Z2J7KTpyzKao7EAE88BHGIs8HoIikEn9D6k1sDEiKm+yBGyaYHWRixZ0deP 1ifLEqohzskBj4xzTkk7fS5njnQ4LwFJlaz6CN6KuowuyEix9oWbbR5x4ByQDyBDm8G1 WKIy7PfgetjSJMVyfTTVa1YkirtmQfgUkw9J6T5KeAsfCDieRx236Kx7sW75E1D3zrUN c53N8OUZ6xxkHltcOS1QQx1gSW8DJg+wZv+ErTSmffXDsj8oQS6y7AelACWCUOTf/u+Y mLRg== X-Gm-Message-State: AOJu0Yz2r8ayH8qnBAOI1Uxs8+o8NVf73zOHewP3O7IdssGNEjFL7BXz dMYPC2hhjwEsOn4Wvh72FdwiEDL+VKn38hlS+/ODZ7HYpfchduFNR+1F6enu+Pr+0nimPNSLJtH pFBBCFYQredrCL8CQq0sCAlPJvpIg X-Gm-Gg: ASbGncuDcVSMfdrgN8S7U4AAgpmy8h6dl00ChaBenegoSqszZVGyRpZHnam9xO1/cos JK9Ju8TYgSGxZCT7+u0vzNJf+0xg63yUG7/lvOxbVqmP8OKvTU49OzqBD/Yutr2z9TXVtin8ZTf YfRbzAnjMxDMB1rKDQayq6xkRf+V8p1A== X-Google-Smtp-Source: AGHT+IF7YlPknct7i2UFE6pCa0WiHgZMTBBoHKVSIBzMeEPa9HXXOL1dePq99I+ixKAZOSo5BQ9XBCqMc2OOF0UVrgc= X-Received: by 2002:a17:906:9d2:b0:abb:6f30:32c7 with SMTP id a640c23a62f3a-abb709211e5mr1845119366b.10.1740004829969; Wed, 19 Feb 2025 14:40:29 -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 From: Rick Macklem Date: Wed, 19 Feb 2025 14:40:15 -0800 X-Gm-Features: AWEUYZln7Ca2WEZOqf1Z70KcIV9layRFT9vTnykF7lPIQmAeenREREszvg6uoZU Message-ID: Subject: RFC: mount_nfs failure due to dns not running yet To: FreeBSD CURRENT Cc: Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; 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]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from] X-Rspamd-Queue-Id: 4YyrvN1m9Cz3WM4 X-Spamd-Bar: --- Hi, The subject line basically describes the problem glebius@ ran into. When doing an NFS mount in /etc/fstab, it failed since the DNS service was not yet working and, as such, the DNS lookup of the server fqdn failed, causing the mount to fail. Note that this behaviour has existed for decades. He feels this is a bug and that mount_nfs(8) should retry getaddrinfo(3) calls until success, instead of failing the mount when the first attempt fails. The problem with just retrying getaddrinfo(3) is that it could retry forever for simple failures like a typo in the server fqdn. I can see several ways this can be handled and would like feedback from others w.r.t. these alternatives. 1) Simply document this case and encourage use of host names in /etc/hosts for NFS servers along with specifying use of file before dns in nsswitch.conf. Doing this results in the mounts working whether or not DNS is working. 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) until it succeeds. (I feel this would be a POLA violation, given that the current behaviour has existed for decades and for simple cases where the fqdn will never resolve the behaviour would be to hang at the mount attempt during boot unless "bg" is specified for the /etc/fstab entry.) 3) Add a new NFS mount option "retrydns=", which would enable retries of getaddrinfo(3). This would avoid any POLA violation and would allow for a convenient way to document the behaviour in "man mount_nfs". 4) ??? So, what do you think is the preferred change? rick ps: I looked and the return value from getaddrinfo(3) does not appear to be useful to discern the case of "DNS service not running yet". (I think it replies EAI_FAIL for this case.) From nobody Thu Feb 20 00:25: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 4YyvDY12ksz5nvg0 for ; Thu, 20 Feb 2025 00:25:33 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4YyvDX1Bvyz3hpq for ; Thu, 20 Feb 2025 00:25:32 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=M0clCxuh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of drsnx60@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=drsnx60@gmail.com Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2fc33aef343so761030a91.1 for ; Wed, 19 Feb 2025 16:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740011131; x=1740615931; 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=6Bk6H/2jP0x3rMCbmAvFMwpYE5eVbN1r1hQzcnPZ5Mk=; b=M0clCxuhduBmyWCgFxagNihhCUdyVeP4u7EPJY8RItBbtXaLW7Y8sxMXF3lxEChMOH 0XzzfadS062Su6JxjyLILuYV2uyEtbxk1MmW+ImY6t8RRfGFQqxC5WeQfG32tFL8LQEl pbcJE6OuXb54v1Vf9p8K9SARYMX3MBzYG+qtEJWCVS04f1CyqIk8Q0qyeOaYV5HXyLOy 0CJdJg8YvPaC/yY54aWvSTP7vNn4ycLGBphIa/fWNC4SG2l9zK0a09J7LMu83amhhVWv L94MpUY8D3BxGzkqNzbdPdut3Wu7757LQLEmxQbTVDHERXEv9izO1Gu+p474UYBs41tz jyPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740011131; x=1740615931; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6Bk6H/2jP0x3rMCbmAvFMwpYE5eVbN1r1hQzcnPZ5Mk=; b=s6QwFm4mLhREDSrky7Y7bH0XAplS18iv69XMqtNQf1wZfSG0BKtK8LFglOWQGiCGDC XC5f3/LkpLu07GMxllJ8hglz/2KOBi0UZXAH8obutug8FQlnuN7UKM19H/GZhh0V8r/Q O18dPL4yNWE7ATOjEEq8P5HqrhDkv7rBeStZj4twsZRnuGEngEB92HPQJT0W640zF760 7cJLUj1/2C3h5ra2cxYot3BsW4XroFDcDuyVBK6u3HC60jZdUen68p1QyotMNvb9JHka Dm4Y4UeDW1eohYfglYa95joA9JaCY22XN8VLEWKR33XHjeGwwkz3Ze6vJ30Q+GBO9n9X nCXA== X-Gm-Message-State: AOJu0YybIvzRzyBcUYhPcMI3ttoVEqqmP/WeLnEV2lUTQDfIk62GdF+B CezUrYFu4PDE7RuxjdGbcEnh25x8RRlJJsWUfrYpdOFiKQQP2fqDUzdO+b+SuR45InTSxeVNrEX PrE1Z7lg2OmcQNN971LjOaRZNXk4= X-Gm-Gg: ASbGncuWFa7BK8GvPhJ5hEiUN0nlc7nBpo4iOInSHkVDf26OP0wC5f227gZ7UgsyBcR u1d2AlZ7enkk1AowNNRDBiv4+IXXCoLV5cOzxJlJ2Hm9AGZNIanRgZzkRIcWumn3NveKPw1Q= X-Google-Smtp-Source: AGHT+IGsYxWdYgq73u6JdHcb7hcFg5lTZyrz5eWd/HA08yUshxG2Mbk9RF+1eWvso0nMJYdLZczYPVqgTgxqEPFPYYI= X-Received: by 2002:a17:90b:520d:b0:2ee:f687:6adb with SMTP id 98e67ed59e1d1-2fcb59ec21dmr8393721a91.3.1740011130792; Wed, 19 Feb 2025 16:25:30 -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: In-Reply-To: From: Lars Tunkrans Date: Thu, 20 Feb 2025 01:25:20 +0100 X-Gm-Features: AWEUYZmiOSnofvHmL-LsuH6FgqnLks4LE_M9netdeokGiMQvk7BtLKeYNlRVUCE Message-ID: Subject: Re: RFC: mount_nfs failure due to dns not running yet To: Rick Macklem Cc: FreeBSD CURRENT , Gleb Smirnoff Content-Type: multipart/alternative; boundary="0000000000005b3956062e87e9f2" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4YyvDX1Bvyz3hpq X-Spamd-Bar: --- --0000000000005b3956062e87e9f2 Content-Type: text/plain; charset="UTF-8" This situation has existed these past 40 years. You have to put your ipadress : hostname pairs into /etc/hosts if you dont have accsss to a working DNS. This is not a bug. Its the way name resolution works. Den ons 19 feb. 2025 23:40Rick Macklem skrev: > Hi, > > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. > > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. > > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) > > 3) Add a new NFS mount option "retrydns=", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". > > 4) ??? > > So, what do you think is the preferred change? > > rick > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) > > --0000000000005b3956062e87e9f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This situation has existed these past 40 years.=C2=A0 You ha= ve to put your ipadress : hostname pairs into /etc/hosts=C2=A0 if you dont = have accsss to a working DNS.=C2=A0=C2=A0=C2=A0 This is not a bug.=C2=A0 It= s the way name resolution works.


Den ons 19 feb. 2025 23:40Rick Macklem <rick.macklem@gmail.com> skrev:
Hi,

The subject line basically describes the problem glebius@
ran into.=C2=A0 When doing an NFS mount in /etc/fstab, it failed
since the DNS service was not yet working and, as such,
the DNS lookup of the server fqdn failed, causing the mount
to fail. Note that this behaviour has existed for decades.

He feels this is a bug and that mount_nfs(8) should retry
getaddrinfo(3) calls until success, instead of failing the
mount when the first attempt fails.
The problem with just retrying getaddrinfo(3) is that it
could retry forever for simple failures like a typo in the
server fqdn.
I can see several ways this can be handled and would
like feedback from others w.r.t. these alternatives.

1) Simply document this case and encourage use of
=C2=A0 =C2=A0 host names in /etc/hosts for NFS servers along with
=C2=A0 =C2=A0 specifying use of file before dns in nsswitch.conf.
=C2=A0 =C2=A0 =C2=A0Doing this results in the mounts working whether or
=C2=A0 =C2=A0 =C2=A0 not DNS is working.

2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3)
=C2=A0 =C2=A0 =C2=A0until it succeeds. (I feel this would be a POLA violati= on,
=C2=A0 =C2=A0 =C2=A0given that the current behaviour has existed for decade= s
=C2=A0 =C2=A0 =C2=A0and for simple cases where the fqdn will never resolve<= br> =C2=A0 =C2=A0 =C2=A0the behaviour would be to hang at the mount attempt
=C2=A0 =C2=A0 =C2=A0during boot unless "bg" is specified for the = /etc/fstab entry.)

3) Add a new NFS mount option "retrydns=3D<N>", which would= enable
=C2=A0 =C2=A0 retries of getaddrinfo(3). This would avoid any POLA violatio= n and
=C2=A0 =C2=A0 would allow for a convenient way to document the behaviour in=
=C2=A0 =C2=A0 "man mount_nfs".

4) ???

So, what do you think is the preferred change?

rick
ps: I looked and the return value from getaddrinfo(3) does not
=C2=A0 =C2=A0 =C2=A0 appear to be useful to discern the case of "DNS s= ervice not
=C2=A0 =C2=A0 =C2=A0 running yet". (I think it replies EAI_FAIL for th= is case.)

--0000000000005b3956062e87e9f2-- From nobody Thu Feb 20 00:29: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 4YyvKP6RGKz5nvw5 for ; Thu, 20 Feb 2025 00:29:45 +0000 (UTC) (envelope-from dan@3geeks.org) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 4YyvKN6wKZz3jlj for ; Thu, 20 Feb 2025 00:29:44 +0000 (UTC) (envelope-from dan@3geeks.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=3geeks.org header.s=google header.b=j4hx5QbU; dmarc=pass (policy=none) header.from=3geeks.org; spf=pass (mx1.freebsd.org: domain of dan@3geeks.org designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=dan@3geeks.org Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6fba8e84d3cso3093647b3.0 for ; Wed, 19 Feb 2025 16:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=3geeks.org; s=google; t=1740011384; x=1740616184; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=4wSE2k8pbPQAMnrwKDpSLN2yBP0I6vHfLpOFo8bPEh4=; b=j4hx5QbUXAsBuE70OBTqTQ3MwJq/DSGnr2SIYkM/RYDjqIk8nqr9dtif8AnM+9+u8/ LbeMrI8JkuK/DrFIpQdaOa847fb1m39f7zb/ChY32G4UUp4jiE93JJInhK/IUwQwCzSF A8HwlcX9BwTWP/CAsu1PHTGXFuKSOJy7UscfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740011384; x=1740616184; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4wSE2k8pbPQAMnrwKDpSLN2yBP0I6vHfLpOFo8bPEh4=; b=NMAFZUSaE6IVc5d21kO0rpAIZG1TtZsqxSAtczDs1hUnYHQDsSD/LnNg7peh1QabVh cn+pHGQgrANWfWseSVIjUJcOolK0M1pPSkz1A+j4THmZv2/8f6b7JYVNatNYi4thLoDx /yBjpAgqNVAqDUiY59wR5hR8Wq1XE3bNo9PU0OLvOVUnW2v4icRKP1K20QjpobKtqDKE EOuioP2lcKO+kt4h7Nfiy4ZW/BYz0UeItPk/AHc8yjkW/V/BkBIK3d90jCLVTJ/IIdBe BZC7cYs0+k1t8EmFCbhn6aPcDxwddyB1WPO8cRauWcjinQ+R2b0HX4VRyxsPBA3twyqw Iiig== X-Gm-Message-State: AOJu0YzE7FtgGPWGRNthsosbQsUCmgQFdfPf28Y6j6yQksYcR0EHosgw V+G8qYwPJ/Uunnd1I+FTNOI6RI8tGi7jyaJp0Kz9EoUP9ZsduG8C4hpADq0CZpreA55mjVjJS9M O X-Gm-Gg: ASbGnct2kbFx6Sk1v7vl3pYc565rolPjwz2a396scHSWbFafXJZ7xtxMNoS9KknvA/Q 2hXGnQdPKSCedOqz9Rp6EpbqRKW/txsy4QhA4OMlNrH1uk4pVeCYYLQDu63zCvFqELpRGIwgidB BpIwxx8pIyVzwmsufcl2WHAiAtYUDoGOOi+FcpVevSYe2RqCtsCCkSNnuV8Owws4Q3LChcxxcJj 5laF/vZTAMVtTKr7JesUy0dLZip/5sHni2uY5qOE2z+K5QM8Qqy25r0eMfHMoC2kTxXJOEZy6EZ ztBofUUqwBk4tUDd5rqIKA626BjNku3NlDHYnYyugdqrGfWl+RMt3LOvg86O X-Google-Smtp-Source: AGHT+IHZWgkfWYwiSyO0YVUzA/ZdlS4gM8lJTF75kkdV7qisMYcQ2ukf12jUtu6mxT8ibVd2tJ5nQQ== X-Received: by 2002:a05:690c:25c5:b0:6ef:4a1f:36d6 with SMTP id 00721157ae682-6fb5831d609mr181653587b3.23.1740011383750; Wed, 19 Feb 2025 16:29:43 -0800 (PST) Received: from [192.168.21.197] (69-237-9-85.lightspeed.dybhfl.sbcglobal.net. [69.237.9.85]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6fbb72f48f3sm1923717b3.6.2025.02.19.16.29.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 16:29:43 -0800 (PST) Message-ID: <56736af6-e72a-4d91-a56d-cde0f5e32252@3geeks.org> Date: Wed, 19 Feb 2025 19:29:42 -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: RFC: mount_nfs failure due to dns not running yet To: freebsd-current@freebsd.org References: Content-Language: en-US From: Daniel Mayfield In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.66 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.66)[-0.662]; DMARC_POLICY_ALLOW(-0.50)[3geeks.org,none]; R_DKIM_ALLOW(-0.20)[3geeks.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[3geeks.org:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[dan]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from] X-Rspamd-Queue-Id: 4YyvKN6wKZz3jlj X-Spamd-Bar: --- On 2/19/25 5:40 PM, Rick Macklem wrote: > Hi, > > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. > > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. > > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) > > 3) Add a new NFS mount option "retrydns=", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". > > 4) ??? Split the difference?  -1 for "try forever", default to 3, configurable up to insanity?  Also, rather than just DNS, make this in the case of just about any failure except actual administrative failure (mountd refusing the mount, for example). If this gets added, there should either be an exponential backoff with a configurable max (default to 30s), or a configurable static delay (default to 3s? 10s?).   The mount_nfs process should log loudly every time the delay gets triggered. Honestly, this would be handy in any number of crazy situations where you have a need to wait for something else to start.  I've been bitten by the "just fail the mount" behavior before, but I worked around it instead of thinking of changing the behavior. Daniel From nobody Thu Feb 20 03:34:01 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 4Yyy0g4Ndvz5p4Gq for ; Thu, 20 Feb 2025 02:30:27 +0000 (UTC) (envelope-from mohammad@thelightbird.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 4Yyy0f28jtz42Lp for ; Thu, 20 Feb 2025 02:30:26 +0000 (UTC) (envelope-from mohammad@thelightbird.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=thelightbird-com.20230601.gappssmtp.com header.s=20230601 header.b=dkVBGtGW; dmarc=none; spf=fail (mx1.freebsd.org: domain of mohammad@thelightbird.com does not designate 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=mohammad@thelightbird.com Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-546202d633dso481588e87.2 for ; Wed, 19 Feb 2025 18:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thelightbird-com.20230601.gappssmtp.com; s=20230601; t=1740018624; x=1740623424; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=aJfvzf/7Pf+ynFlOUD8LEhR0m8M40ctTCrADDMbcil8=; b=dkVBGtGWnqZMvjzkBm39S/yUY4sE+BS2YIELmyvJ12LzatG/rp39V89krjPbHXqSHw d/lDYaYIihEO03fkHi79vrBB6Cy5hda/d3NA4wXwMxlK3MKJRxESLpyEobyzqF+or74X KmY9xHl1uCmJ4Sazk0wLyLmUkXBjMSzh3gYVSvUXbhDCM/M5SyeD+W1pQ7FnCzo253+Y +Cvnbls8gT8W7x/HKeUeXXl7HaSCm8hDNPQ46r4tDKhB1w3PrwDWrpTibV/ACteAyD1v IWjKz1C+pgtfk2syUW8T2EeVNJ6lHixiRinaA5h5Ad+eC8bfIvpEJoCsCmAZ8NwCmOhh pxMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740018624; x=1740623424; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aJfvzf/7Pf+ynFlOUD8LEhR0m8M40ctTCrADDMbcil8=; b=CsGYueoDdE6RprB2cV7KBxd0y4+bYyqU4EXIDqOXjLiemCZEozcor3d1+BW8TQLLlM TQ8P2+NHdacthTCWUoOLuUxot1Y27aI8C3N+eq9U8ECtZS3xtyQEjhPxLahk1sGGKmOS 6C+UDrqUjaIh1f1VZYiM4jTgfgfFi2Wb2tC/xJYxL6/7yRFWEHYKtQYEbKYORhZdgEI9 EGZrmGQSDkct//jTDC56kzhUbuCOJWt8x7vi1CGLsGikiw8EHzzZl5Yz2+urEro9PI38 pbdkwzHXSJzfG3Z8IyCswu3XTgsbt6iT4qZ+iJNUEMMEQFoSt39hIIxfDDMtd8ofCW5O 7UXQ== X-Gm-Message-State: AOJu0Yyp1gFjfEHrHYU03G4DS0h5mX+UR5qboe8WrbNH3vWb2VJlz82x +pRjs4wWTJvp92XfXxjya/XcHVjkD3KZlx+iOUcarA6HIsdSQ3/r8t/VQmI3Tt9s2MbiN8bhzr1 FDraAy6+KvuZ2JS7sL/1FgsUOlAk2LLN7Yt49dWCeabD3sHmTLg== X-Gm-Gg: ASbGnctZoRUSpaBR8AZRgq/LtXwegyXagnq8xCaKgzu5heHxrXRNr6dQAhBiaB/YOFc 1J/4Q0k+4lWJq8r6Ap+qehzu+paiYvhc18B9rctCJUeMkJU82smk4kQkW+PqIsocT51AtZPE= X-Google-Smtp-Source: AGHT+IEQ51X8mepllm0HBl4beh0sfeGuWzTkFgmMr1A1Bx5KPHTiual3wH2icYlZ0l6vt32nX+7ltHaQ9AhGP9AIxos= X-Received: by 2002:a05:6512:b12:b0:545:e7f:cf3d with SMTP id 2adb3069b0e04-5452fe2e4aemr7873710e87.5.1740018624164; Wed, 19 Feb 2025 18:30: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 From: Mohammad Noureldin Date: Thu, 20 Feb 2025 04:34:01 +0100 X-Gm-Features: AWEUYZklXuQmWtYy4EHUN9hLkgSBySsS5dBmMIrEdkvX5mzx3A3TCJB3uy7o9N8 Message-ID: Subject: Very poor -CURRENT boot performance on AMD To: Freebsd current Content-Type: multipart/alternative; boundary="000000000000ff1163062e89a720" X-Spamd-Result: default: False [-2.30 / 15.00]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[thelightbird-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[thelightbird.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::136:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[thelightbird-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4Yyy0f28jtz42Lp X-Spamd-Bar: -- --000000000000ff1163062e89a720 Content-Type: text/plain; charset="UTF-8" Hi, I've installed -CURRENT using snapshot "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on an HP EliteBook 845 G10 with AMD Ryzen 5 7540U. Both when booting from the install media and when booting from disk after installation I get a very poor boot performance up until the FreeBSD Boot Options Menu. Right after it is all OK. I've recorded what happens during the boot from the installation media in [1]. Does this ring any bells ? Is it a bug that I should report in a PR (Problem Report) ? [1] https://drive.google.com/file/d/1s1a9qTwh-8gWOp0Lyta_Wc0RyUAkXTND/view?usp=sharing -- Thanks - Mohammad Noureldin -- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein --000000000000ff1163062e89a720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I've installed -CURR= ENT using snapshot "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-2= 75409" on an HP EliteBook 845 G10 with=C2=A0AMD Ryzen 5 7540U.

Both when booting from the install media and when booting= from disk after installation I get a very poor boot performance up until= =C2=A0the FreeBSD Boot Options Menu. Right after it is all OK.
I've recorded what happens during the boot from the instal= lation media in [1].

Does this ring any bells ? Is= it a bug that I should report in a PR (Problem Report) ?


--
Thanks
- Mohammad N= oureldin
--
"Life is like riding a bicycle. To keep your balance= you must keep moving"
- Albert Einstein

--000000000000ff1163062e89a720-- From nobody Thu Feb 20 02:47: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 4YyyNX0wYbz5p5FB for ; Thu, 20 Feb 2025 02:47:40 +0000 (UTC) (envelope-from zagazaw2004@gmail.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 4YyyNW5Nzxz44hf for ; Thu, 20 Feb 2025 02:47:39 +0000 (UTC) (envelope-from zagazaw2004@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-72741784350so255626a34.1 for ; Wed, 19 Feb 2025 18:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740019658; x=1740624458; darn=freebsd.org; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:from:to:cc:subject:date:message-id :reply-to; bh=alUbW0Z3q4S6fAOkBoW5HnbW+awyIRwhUyvGWisXtqk=; b=cKdEhXqI0IktLNUHbLL+zokws1TiCUat+jI66wSRI6Zo0TRGSm4k1fYgrtPV2GjKxp 9xIyRTe9LdF+x7k0O5WL2eoexnKNR5LjQCXMtZppWVHLc64Po/+BwFdeRld3LRIXllXI RbvAcjrnHGDg0MDW2dyZN3tTICZh08gAIoh95U5e0AYRXQP3m67z2mG2vGW/3vx8Tbh5 0Fa429hnOgxjGRH7FNH3qPyYIJZa847/yo14vcjwDG5ntvvoeflwPBSH/V3oWSTxvc9A tBUXLLF8rri7fiywuClJRNaW3cGLkFvnBjBggKYPIDOPUymiE3T7+83XRC/SlpwYxjse KZMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740019658; x=1740624458; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=alUbW0Z3q4S6fAOkBoW5HnbW+awyIRwhUyvGWisXtqk=; b=TErEuYSBq3sMBqpucXm0qRzvNuCPoOGaiitL8vpo8qMpid9c8TFLdq6cCEvBuAxieW QrCIENYKk4+LRqZBxfduMdQ2xD6XL2KVZUqnqwe5Iy+P9STvQhtpeFuAO5zQ0ZXtJuqp TcWgSPk9NdQ4MQSboBUqEzKcbnfMytjdUcAl2ATVq/XRWP9kUH7Wo7kgdI5dqyl7Goem 4XIAq2Gh4zJZ2mqohpOJ2SYzBAarxvqR24Jg5ACQ9Z+v3sL76+w8zwG+GHslCkHdGKO8 aq1Nkm/z/4oapJ/x8BiSsumFPbMb3vKaW/qWcswOZ3aMtW1fCPWn5h/XC2d4OLm2ff8I 7EiA== X-Forwarded-Encrypted: i=1; AJvYcCXKgIH6boQeEJsOQH/A9GCKlHTDRjNo/DbqFtR1+A0siw1QAWZlLlAng6z2igkIZHJRUkZbog1uDdcrCNNYGUI=@freebsd.org X-Gm-Message-State: AOJu0YxQpfGKUqRuNYf0FUYlmFtKksVnlr1Te4R10f12wyuJXyrUTr7v GzPW+D4NzfnjuZLvkSG4G+6k3XDLmP4X0/YGWy7ZTgu2zlkLtHVFC58Pvg== X-Gm-Gg: ASbGncuWTb8hJXh3HDhuaoc8nebQS8xnOpaJXP4kSKmJ3h0J5FKZOkPbHqb1j0Aova4 XvdlmPDSDvgPdpVpuCWA8J5dAQKdFItYa9WxKoQdMn3AGKPyDl9uhzUAuO9CrJVx//JxO/RNZQm oiHp/z0uHGsR8ZwoFSMUsjFN0oCck8x6O8fPOYjM+euQMkWAc8/NAXsMG0hWt744VK2kSvy/Xdx Vqb9lYYQIn94cFziLbezzsoMlOMNEiDpX2LJoZihfeg1bRSgNYLXUB2kVTVWoBkvFml1oiSLmxU r1oQigB3rPXzstnOMdOK7Z1HJ88vloNDRflUbqaRip6bnqY63HQtIinaJ2s5k7jOgA== X-Google-Smtp-Source: AGHT+IGbTJ6BXhkJBQ8H+Nl22BX9TJjB5VkTCy53b1zKmUEwNPMBqTHURoIsDJnL4EYOMlneeXI9ng== X-Received: by 2002:a05:6830:6e17:b0:726:fb8c:ef4 with SMTP id 46e09a7af769-72737765bd9mr5386505a34.12.1740019657985; Wed, 19 Feb 2025 18:47:37 -0800 (PST) Received: from MICROBOX (c-76-143-116-34.hsd1.tx.comcast.net. [76.143.116.34]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-727295b7eeesm1962580a34.46.2025.02.19.18.47.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2025 18:47:37 -0800 (PST) From: "Maku Bex" To: "'Mohammad Noureldin'" , "'Freebsd current'" References: In-Reply-To: Subject: RE: Very poor -CURRENT boot performance on AMD Date: Wed, 19 Feb 2025 20:47:36 -0600 Message-ID: <002301db8341$cd1ffc60$675ff520$@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01DB830F.828628A0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHyZgwUFrvx/icPqXT3krFqEGCEx7Mhtwqg X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4YyyNW5Nzxz44hf X-Spamd-Bar: ---- This is a multipart message in MIME format. ------=_NextPart_000_0024_01DB830F.828628A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mohammad, =20 The performance issue(s) have been noted on the UPDATING file. Here is a = snippet:=20 =20 =20 NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW: FreeBSD 15.x has many debugging features turned on, in both the = kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, = malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. (To completely disable malloc debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild world, or to merely disable the most expensive debugging = functionality at runtime, run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) =20 -----BEGIN PGP PUBLIC KEY BLOCK----- =20 mJMEZlPMfxMFK4EEACMEIwQA/hAHZ4KNJLw5eRl6DAOyzkuHQ7PaK2hTYLVIPoxC sCe8lB/hzET5KxMW9GXgFgPaSP7Es+ul6ajyq8pr9DeGnXUAFymi7GoT1kLIqgrn X+rDAwMk9JNEElTmVNvgKWv/G+pSg2rAQ8sIw6smgckA0CaX1JdcNavrHDgKMO4u Duo44Te0BkpPTUlTTYjbBBMTCgBBFiEENyUvu5bQVBXM019e8anbed+sQ8YFAmZT zH8CGwMFCQHnaREFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQ8anbed+s Q8Y5BgIHcX19jz0KP89uTmqvLGZcKsITDJKweAnccCZRS8hvXT8JBwR1LyxsBBKF ++eN2JJasZLo+s6sy7pDMN+9z4Gkdy0CCOj+arfLdvajfzdK4QeKpINfpa2SkQD1 CP98lvfI/luIbetUVW+qNDkzT1jZphYuzgsCaofTGCIQpFk19q22ZcZquJcEZlPM fxIFK4EEACMEIwQANy4VvpnTHneZipCPwzVJnMN82coCudRAiL2i2m3GPA06lRtU njcn9r9Sm26A0sajwc3kQw/ekWrHXpXV0aL076cAUW9GKYDljIHVlr76wgHbLt6q BX5VkA6xS0cq3skbMEI0QpIqIK81Yf0z8wfyF5uqAgNPUpY4nHMV9S856JB2VDQD AQoJiMEEGBMKACYWIQQ3JS+7ltBUFczTX17xqdt536xDxgUCZlPMfwIbDAUJAedp EQAKCRDxqdt536xDxjIuAgjacZCttPWpKGfMbnNWePz6t9rcMUb496tSWfKRActr Rco8lSaDNTVohT/6hLZ5wUX5NFUqTb+kOXJcUGHGbnw2KQIJAQu1m9zEP5XdWmFi SvGg1NHW2kzqAvFsG37flbwrGRu5fmTnS/LZ/oPzOCuwU6F+o1q0E7gLwFwnzD93 riKeabdd =3DiCV+ -----END PGP PUBLIC KEY BLOCK----- =20 From: owner-freebsd-current@FreeBSD.org = On Behalf Of Mohammad Noureldin Sent: Wednesday, February 19, 2025 9:34 PM To: Freebsd current Subject: Very poor -CURRENT boot performance on AMD =20 Hi, =20 I've installed -CURRENT using snapshot = "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on an HP = EliteBook 845 G10 with AMD Ryzen 5 7540U. =20 Both when booting from the install media and when booting from disk = after installation I get a very poor boot performance up until the = FreeBSD Boot Options Menu. Right after it is all OK. =20 I've recorded what happens during the boot from the installation media = in [1]. =20 Does this ring any bells ? Is it a bug that I should report in a PR = (Problem Report) ? =20 [1] = https://drive.google.com/file/d/1s1a9qTwh-8gWOp0Lyta_Wc0RyUAkXTND/view?us= p=3Dsharing =20 --=20 Thanks - Mohammad Noureldin -- "Life is like riding a bicycle. To keep your balance you must keep = moving" - Albert Einstein =20 ------=_NextPart_000_0024_01DB830F.828628A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mohammad,

 

The performance issue(s) have been = noted on the UPDATING file. Here is a snippet:

 

 

NOTE TO = PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW:

=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD 15.x has many debugging features = turned on, in both the kernel

=C2=A0=C2=A0=C2=A0=C2=A0 and userland.=C2=A0 These features = attempt to detect incorrect use of

=C2=A0=C2=A0=C2=A0=C2=A0 system primitives, and encourage loud = failure through extra sanity

=C2=A0=C2=A0=C2=A0=C2=A0 checking and fail stop semantics.=C2=A0 = They also substantially impact

=C2=A0=C2=A0=C2=A0=C2=A0 system performance.=C2=A0 If you want to = do performance measurement,

=C2=A0=C2=A0=C2=A0=C2=A0 benchmarking, and optimization, you'll = want to turn them off.=C2=A0 This

=C2=A0=C2=A0=C2=A0=C2=A0 includes various WITNESS- related kernel = options, INVARIANTS, malloc

=C2=A0=C2=A0=C2=A0=C2=A0 debugging flags in userland, and various = verbose features in the

=C2=A0=C2=A0=C2=A0=C2=A0 = kernel.=C2=A0 Many developers choose to disable these features on = build

=C2=A0=C2=A0=C2=A0=C2=A0 machines to = maximize performance.=C2=A0 (To completely disable = malloc

=C2=A0=C2=A0=C2=A0=C2=A0 debugging, = define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild

=C2=A0=C2=A0=C2=A0=C2=A0 world, or = to merely disable the most expensive debugging = functionality

=C2=A0=C2=A0=C2=A0=C2=A0 at runtime, = run "ln -s 'abort:false,junk:false' = /etc/malloc.conf".)

 

-----BEGIN PGP PUBLIC KEY BLOCK-----

 

mJMEZlPMfxMFK4EEACMEIwQA/hAHZ4KNJLw5eRl6DAOyzkuHQ7PaK2hTYLVIPoxC

sCe8lB/hzET5KxMW9GXgFgPaSP7Es+ul6ajyq8pr9DeGnXUAFymi7GoT1kLIqgrn

X+rDAwMk9JNEElTmVNvgKWv/G+pSg2rAQ8sIw6smgckA0CaX1JdcNavrHDgKMO4u

Duo44Te0BkpPTUlTTYjbBBMTCgBBFiEENyUvu5bQVBXM019e8anbed+sQ8YFAmZT

zH8CGwMFCQHnaREFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQ8anbed+s

Q8Y5BgIHcX19jz0KP89uTmqvLGZcKsITDJKweAnccCZRS8hvXT8JBwR1LyxsBBKF

++eN2JJasZLo+s6sy7pDMN+9z4Gkdy0CCOj+arfLdvajfzdK4QeKpINfpa2SkQD1

CP98lvfI/luIbetUVW+qNDkzT1jZphYuzgsCaofTGCIQpFk19q22ZcZquJcEZlPM

fxIFK4EEACMEIwQANy4VvpnTHneZipCPwzVJnMN82coCudRAiL2i2m3GPA06lRtU

njcn9r9Sm26A0sajwc3kQw/ekWrHXpXV0aL076cAUW9GKYDljIHVlr76wgHbLt6q

BX5VkA6xS0cq3skbMEI0QpIqIK81Yf0z8wfyF5uqAgNPUpY4nHMV9S856JB2VDQD

AQoJiMEEGBMKACYWIQQ3JS+7ltBUFczTX17xqdt536xDxgUCZlPMfwIbDAUJAedp

EQAKCRDxqdt536xDxjIuAgjacZCttPWpKGfMbnNWePz6t9rcMUb496tSWfKRActr

Rco8lSaDNTVohT/6hLZ5wUX5NFUqTb+kOXJcUGHGbnw2KQIJAQu1m9zEP5XdWmFi

SvGg1NHW2kzqAvFsG37flbwrGRu5fmTnS/LZ/oPzOCuwU6F+o1q0E7gLwFwnzD93

riKeabdd

=3DiCV+

-----END PGP = PUBLIC KEY BLOCK-----

 

From: = owner-freebsd-current@FreeBSD.org = <owner-freebsd-current@FreeBSD.org> On Behalf Of Mohammad = Noureldin
Sent: Wednesday, February 19, 2025 9:34 = PM
To: Freebsd current = <freebsd-current@freebsd.org>
Subject: Very poor = -CURRENT boot performance on AMD

 

Hi,

 

I've installed -CURRENT using snapshot = "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on = an HP EliteBook 845 G10 with AMD Ryzen 5 = 7540U.

 

Both when booting from the install media and when = booting from disk after installation I get a very poor boot performance = up until the FreeBSD Boot Options Menu. Right after it is all = OK.

 

I've recorded what happens during the boot from the = installation media in [1].

 

Does this ring any bells ? Is it a bug that I should = report in a PR (Problem Report) ?

 

 

-- =

Thanks
- Mohammad = Noureldin
--
"Life is like riding a bicycle. To keep your = balance you must keep moving"
- Albert = Einstein

 

------=_NextPart_000_0024_01DB830F.828628A0-- From nobody Thu Feb 20 04:11:35 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 4Yz0Fc2fgJz5pBfq for ; Thu, 20 Feb 2025 04:11:48 +0000 (UTC) (envelope-from rupeshpilania@gmail.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 4Yz0Fc0tw4z3HS7 for ; Thu, 20 Feb 2025 04:11:48 +0000 (UTC) (envelope-from rupeshpilania@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-520b7289062so7847e0c.2 for ; Wed, 19 Feb 2025 20:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740024707; x=1740629507; 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=xVSKRoQclCf4Sirp3TT/zYaM4iExJOqbU/UD3mgssgs=; b=eVTCiLYVWtCVwDeiuxhPrvBnJUGJ7o7il6Mbr+C7V06db/jH4SqcjRzNXT+j7x+eDm lCPomyZmIbPR4z9yXk43fO6ry2dC1BqcUb2lX3/PAZU+axN3rsSEUHk0Ox4P4U1RMNOh Bv47p6Lhm8M09J/e3rLbbLARvmdJrT0FexXR3ZGQVPu3hSMz6xpLAO6zNC3nWFeRPkvH SqkLGw3d9hV01K+AfocHgr0L9e2sA4vgjp0PyI38YZG/z6RqODe5z25yHWKhZnlFi16q foBjuQiDxLRrJTHG9Q8ESogNIoJ7tcwxhBbYsSxWsHl07EEB1s63BhQN+zw2ekWHTCAh 1KEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740024707; x=1740629507; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xVSKRoQclCf4Sirp3TT/zYaM4iExJOqbU/UD3mgssgs=; b=ml+9Jo2Om/T1tetucAgSCPVDeFrU/w84myAvte90ZXIvTjWrcsALXPGdmE72i4yrnf 63/Ul64fXEhHh0uBIQZ69IVL0zzZxiuKe0y9gkI6OQ4PKQ6X+uZOePFd9g5Nt9muljqy 1jXFdag3QuztlpiXHwYai4Qe3KKj+iWXeasONGTx9YhNLO4omDs9uXQ87IAK5eNQmpIv eDdzUwGwZZCiBfSkL1AyPRO+KigQLxyLKCiRQUVuAgz3h3BySpZtd9zq5B4VGITErq3I sZfhBLp0+6RdFM5Sn77BAQFKLgHb0hylQbexMdEcI4mYjQjUB6TZOw7k4Svate8NMpo4 PQnQ== X-Gm-Message-State: AOJu0Ywc0roQh6kMfxvNOCfYAqbUpqZmx465lKav+KZW0CxyFvMSYsL4 MDhWZr0bM5NCkItg73uQqsjvEq63PDfzlA6bF4NfikphZ/4BDtdBAzWtlJp75OzdPmhYhneU+q+ dNcDgzw79xcenzyvR2DeC7745V0/px2nF X-Gm-Gg: ASbGncv90vSe/EdLfuYyigdNx3w95SUU3OlBzO6xWe5gQQ6VFlibinx+qopvsst4t+i MV8xZCXZdbtYCT+7NRmaVX/GLYtwAX6Cur0HSSNWzRJO39CQXEKZoLnzYPdaSCf8a7qLauhGfYP FoywC9Y5M8fmNwnNRWNcBXWZAhtYD1MEQ= X-Google-Smtp-Source: AGHT+IEuKR1N40TkLRAC6hq2Xq2XAgiMkeJ1rRjyZvH67nDwG5N24M+c69DiJ0BT+jzMt2pYX3sYWfB4oM3VD3+dBFI= X-Received: by 2002:a05:6102:2acd:b0:4bb:d062:43c with SMTP id ada2fe7eead31-4bd3fa93d36mr3547993137.0.1740024706487; Wed, 19 Feb 2025 20:11:46 -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: In-Reply-To: From: Rupesh Pilania Date: Thu, 20 Feb 2025 09:41:35 +0530 X-Gm-Features: AWEUYZk6mpEGJb72L9H-A00-bTyFMhOpssLAT9cP3X3OgBqdcKh-fOmjeTuTuDg Message-ID: Subject: Re: Very poor -CURRENT boot performance on AMD To: Mohammad Noureldin Cc: Freebsd current Content-Type: multipart/related; boundary="00000000000087fce8062e8b12f4" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Yz0Fc0tw4z3HS7 X-Spamd-Bar: ---- --00000000000087fce8062e8b12f4 Content-Type: multipart/alternative; boundary="00000000000087fce6062e8b12f3" --00000000000087fce6062e8b12f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mohammad, I tried the same build on VMware and it came up very fast. I don't have any AMD Ryzen based hw to confirm the behaviour. IMO you should raise a PR. [image: image.png] Thanks & Regards Rupesh Pilania On Thu, Feb 20, 2025 at 8:00=E2=80=AFAM Mohammad Noureldin < mohammad@thelightbird.com> wrote: > Hi, > > I've installed -CURRENT using snapshot > "FreeBSD-15.0-CURRENT-amd64-20250213-6156da866e7d-275409" on an HP > EliteBook 845 G10 with AMD Ryzen 5 7540U. > > Both when booting from the install media and when booting from disk after > installation I get a very poor boot performance up until the FreeBSD Boot > Options Menu. Right after it is all OK. > > I've recorded what happens during the boot from the installation media in > [1]. > > Does this ring any bells ? Is it a bug that I should report in a PR > (Problem Report) ? > > [1] > https://drive.google.com/file/d/1s1a9qTwh-8gWOp0Lyta_Wc0RyUAkXTND/view?us= p=3Dsharing > > -- > Thanks > - Mohammad Noureldin > -- > "Life is like riding a bicycle. To keep your balance you must keep moving= " > - Albert Einstein > > --=20 Thanks & Regards Rupesh Pilania --00000000000087fce6062e8b12f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Mohammad,

I tried the same buil= d on VMware and it came up very fast. I don't have any AMD Ryzen based = hw to confirm the behaviour.
IMO you should raise a PR.
3D"image.png"

Thanks &=C2=A0Regards
Rupesh = Pilania

On Thu, Feb 20, 2025 at 8:00=E2=80=AFAM = Mohammad Noureldin <mohamma= d@thelightbird.com> wrote:
Hi,

I'= ve installed -CURRENT using snapshot "FreeBSD-15.0-CURRENT-amd64-20250= 213-6156da866e7d-275409" on an HP EliteBook 845 G10 with=C2=A0AMD Ryze= n 5 7540U.

Both when booting from the install medi= a and when booting from disk after installation I get a very poor boot perf= ormance up until=C2=A0the FreeBSD Boot Options Menu. Right after it is all = OK.

I've recorded what happens during the boot= from the installation media in [1].

Does this rin= g any bells ? Is it a bug that I should report in a PR (Problem Report) ?


-- <= /span>
=
Thanks
- Mohammad Nour= eldin
--
"Life is like riding a bicycle. To keep your balance yo= u must keep moving"
- Albert Einstein



--
Thanks & Regards
Rupesh Pilania
--00000000000087fce6062e8b12f3-- --00000000000087fce8062e8b12f4 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_m7ctpfym0 iVBORw0KGgoAAAANSUhEUgAAAsUAAAB5CAYAAADRXFw/AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAFiUAABYlAUlSJPAAABaMSURBVHhe7d0NkuQ2joZh71xg6nQ+pI/Qp/Ke YGfQNmq/hgkSlKi/1PtEKDqThECQUmbRFVnp//nzzz//77f/+vr6sn8AAACA1/nX3/8CAAAAr8Wm GAAAAK/HphgAAACvx6YYAAAAr8emGAAAAK/HphgAAACvx6YYAAAAr8emGAAAAK/3/T/v+PHjx8+G zO+///73o3P88ccffz86f+yz2Bxbc5udu8cfvU5nX5Oz5oV7yV4XqKusYfX13Hod6rlRzNU6HwDu 6B+/KdY3rivfxD79DXTmh8pd8EMNR+u9LlBTXcPK63m0obX2eETexrUFcHe/bIp7b2i4r+yH0dN9 6ryAJxhtiGd4DjbGAO7s++MTX19fPxtM782w9aa25U2zkkfryGqKeSo5TC9PNl4cy8Q8I60cJqsn q8VpvlG/m61ZVWtxMS7Wm+WLcUrP6cVV6Plmy1jVeuJYJstj4nOzaiwzimmNb2L7TB6NbcVEcexV RjWbVTEjniPL7e2jsVr9ZmvNWV2m15fZcg4AnGlqU9xqX/Xm2Gsz1j4aK+uP7bPPTbWtanSu9xuL 6cVnfa320bgje8YaPY96/bO5KrIclbFGMavOMVvO2xNjsrZKHpPl1hiTta+0tb4tMRV+jom5jbXN jNWrIfbNxCrvi1qxrpcPAO7gNt8+YW+U2Zvl6I3Wj0+05weIn6tr01vnN/r0+8ftve6ftEZ3fl08 ZZ19vfQwn3KPAHinR38lm78B65vy0fyH1lPe/PWH1VNqPouvx5n3z934fdG7N3RtsnWq5LmT6uui Mq9KTEVlnQEAx+F7iifZD6t43J3WufcHNz6L3sd6n0S9PqPnj2LvQuvMXhc6H41XlZiqvecDALa7 zaZ4xW9azraq5qPmHevzH7ZHjYf7ivdCSyWmYmWelr354/nV10Vl3ErMmfbU0luX2Xl6bLbhn80H AEf4xx/axTem+CbWeuPK3uh6Rnm0P7459+J6MdU8TvtNJWZGqw6j4/RqNrGmI2teMVa1nupY3h6f V+k4dm4rT2WsmRil/UZjrO+ssVxvHJeNr6rnxDjT6zOj/oqZmtWWmJFsPrF9Zqwsp9E81t+LNVl/ tZ5RflOJAYCjNb994u14gz4H64yt7N7hvgEArMRniv/LfsD6Bg3HYZ2xAhtiAMAR+E3x3+JmjR+6 x2CdAQDAHbEpBgAAwOvx8QkAAAC8HptiAAAAvN73xyd+/Pjxs6Fl5nOf+pnRvZ8Xbf1RVsxZian4 xLFaOZzmWjWvKh3vyHGcj7dnrLhGWa7KWL2YOI6JcZUYU615j1YtZkvNo5hsLFedX3VdVtTsemNa X5Y3q61iRY5VWnNUK+erNF+rhr3jjuZlKjF7jeYOoOb7N8X6ArLHW19Qq16I+mal9eiLvxJT8alj Oc2j+czqsSp0/KfRNYoqa9aLqVyLSozT/qNo/qyeI+bl9HFV5fyza26ds4fWdrXK3HprV6Hz9cPE fFvzt1RyrRwvU507gLHuxyf8xXWVq8ffw96QWm9K+qY1o3deNhb+snXNZ1TW/67X6En3T+s6Hn1t z7LqGniep62L13v0vfiUex3A+dJNcfbGau3xyFRiMlve0LeM07IqD7bR+8aPKPZV45S29+Iq7H4d 3bOVGOR6a3eXdd17jbfef1V6j/tjbXOxL/abUUxsa8VcZU8dlXltiTGxrRVjsnaTtQMYa26KRy82 f+P3N/8svhJTpWO37M3vVuXRubfYOH6YVqzGeFzLzFi9PHfg9fmcfF5ad4zR51GrzWluz+XP30Tn jusdef/Fe7x13bVP7w2tqxKj7SY+v5rWOqMyr0rMEbbOCcBfHvHtE/oG3DLqr+rl8TaL8WMPy+eH aeWrxPTo+VkebfMD16hciztfL63H63yTvdfk7DXz8ezfN12vT53rm197wCrNTfHoRbX3zX9G9YW+ 6o2gl8f69PgUnzqvJ6pci0rMFe5UyxVWzP/ta3iWT11n7h9gn/Q3xb0Xl/XF4wh32hDPOus/GsyZ Y+HzcP/85S5rcNT7KX71hHX2GvXe9Mexfu4bYL/dH5846gdq9sK/yqp5HrVeLZWxzqwHfZ9wvVo/ xJ/gafX23Pka9Gryvidu7iprHWPidcrmr3FZDIA10v95R/aiiy9sE2MrMSOtHE5zrRjLnDUv86lj VcXxttRTrbk6lrfH566aJ9K4rTGVsWKMGdW8go7h+b3trvNqjeNW1GxGca1xRm2zenldlj/GmRhb iXGj+Yz6K0b1tMbYO27l/FGM1r01j+ZwW+cEvNn3pvjr6+tnA/A0lR9MAHBHvH8B9/GIb58AlP0Q af1mBACehA0xcC/8phiPFDfF/FAB8CRsiIH7YVMMAACA1+PjEwAAAHg9NsUAAAB4vcs3xWf8wZSN 4Yc+BwAAAMylnyn2jWnvDw3i5nX2jxJ0DM215Y8bWrm25AEAAMC93HpTbP2xr9Vmztik6hhnjAcA AIBzfG+K/f9opxs+pxu/2GfixnAU0+o3Mcafa7y1aZ/zmNi+SlazmRkz1tmqW9t03DhOrCnrH7XH PCaes8qoZgAAgCt8f6Y4bpBamxXt88PoRqcSo+0mPld2Xq/fVWL20NzZ41U8Z5y7rqHxvqzfaXuM 8efVXHudNQ4AAMCM5h/a+YZFNy+4H9tQ+jFSjdtKa4mHytoBAACu9JivZLt6E6XjZ4/P5ONW/sNF +7NYy+fHFl5H63AzNQMAAJzpEZti20z5Jkofqz0bugodM3t8Z1Znr1bv1wMAAOAtbrMpjhta25T5 Btg3aGzWznH0f2AAAADczT++fcJlm8/WZinGVmKcx1bH+4RNsc7J5tNag9jWizGtPK1zTBan4jmr jGoGAAC4wqXfUwwAAADcwWP+0A4AAAA4CptiAAAAvB6bYgAAALwem2IAAAC8HptiAAAAvF76lWzq iq/Lan1NmIm1jL5OrJpnteyrxrJ6zGxNo7lXVdew15bNq3VOVIkxOpaeY6r1uHh+plLPmbJ6svVQ GlPNM8NzVmpxs+ON5lVVXZ9eWzav1jlRJcboWHqOqdbj4vl7tcZbPcYWcV2uMlqf3vWqXNNsftn8 R/WYSkzFTJ6Zep3GbhnLHDWvVTEjrRyulWvv3Ed69Rgb8+ga1Oz6uO/fFGuQPT664JGsHp2oP/b+ Voy3mSxmtUpur0WPGZW5V6zK4+eZLM+emKhaX8w3q1rPWbJ6dD38sfe3YrzNZDEzKuf5OHrMqMyr YlUeP89kefbERNX6Yr4tbCwfTx87f+71+jgx7q1m1ifGtGhMLzZb/0o9MzX3zOSp5NY8ms/M1qzn zqqMtSpmRsyTGfWvouPEMc+qwcQ6qmN3Pz5x5gRWubrmrTc2ctk1Ha1167wV9wevi19xz693t3v+ SWy+d5hzpYaVdd75ddi6JkfV2xrrSpV6tta8ep52TfZcl1Y9q2vco1JLuin2hdEkumD+WNtc7Iv9 phIz4rXFc6+8CDb2FeNvWb/MVXNo8Xll9WTz7tW/Z26teqzN2/2xtrnYF/tNJWbEa4vn7pl3j+U9 KnfPlrXJXDWHFp9XVk827179M3PT/NnjqNfXY+e1zo3t/jy2R70Ybe/FjVTyVNZ75f3m41dzxnqv YLWuXIOe7DopjenFnSXWE2uaudat81fr1ZP1teqKba2YLTxHrMXz+9HcFPvJkSfz/tZEtc8Pozkr Mcra9Ryl52bn35HXu6LuJ817RnVeZ80/Gyfev/EeNdrnh9GclRhl7XqO0nOz88/mtayo6S5zWq06 ryPnr/dS9litqEVztPLZ2H6YbMysRqPnVnJltuTxPo9t6cVYnx6qd15LPP8oWu+eMSt5ejH+XK9V i/d7TMyj7TpOK6fGeFzUi/Hno5qUnuNinpFq3ApWm4/Vm9cKWf7W+mz+9glPoMmOomO0JjfqvxOv VQ+ztW69qJH1ZceRdIxWXaYSM7L1vCN5Tfbv0fXpGK1rOuo/i9ehh9laU+++sb7sOJKO0arLVGJG tp53lL3zUbo+kfdl/avoOPHYys/dskZ2TjzM1np6tWhuPyLti0e0t2Y9f5SnEjPi88jO9fbKWKti PpnP+26am+IVxdoF9iNTiZnBzfUra8+OI1XynxmzyoqxKvd8JWaG170q3x1k18Las+NIlfxnxuyh 90n2WK2oR3PEfD6utR89dx+jdWyhtfdU43osh14jfax6Y/hc/Yhivx5Pput/p7n4Nc2updP68U+j ddE1Tn9TvHdx/ebSI6rE9FRulk83u2YVd1pXn1+vniPWILN3LDs/HlElpufTXxez61HBPf//NHf2 2K2sw3KtzHc1v35Hz8nXLa5fa9xWG+5Lr6sfR7rT++BqvbXT9d388YkZlYX+5IuhZub55DXxG7BX fyXGPHUNRirXtxJzdzNzePJ8uefh/Pr59e7pxVrfWffCmWNV3K2eq2Xr4W2Vew19tpbp/7wje4Gq 7CK0LlyMHcW0+s1ReVapjDeq2XlcVms1z0glzyhG+7091j8bE2XnmFabifli/0jl/OoYMc6M6jUa 0+o3R+WpqOQa1eM8LqujmmekkmcUo/3eHuufjYmyc0yrzcR8sX+VVt2zY43m4O06lrWNznPVvDFu ZJQn1qFGNUWtXNVYjavkmRmrZ+tY5oiaNcb6/Hk2ViXG9cZyR8WYVp1K81jMKH6vWLeOE2sxrXpW 1NyrQ8W4703x19fXzwYAAADgbU75+AQAAABwZ2yKAQAA8HpsigEAAPB6bIoBAADwemyKAQAA8Hqb v32i9xUZ8SsuzMxXabhRnla/2zKeyea1cqzZ9clqGmmdF9t68zK9uNl6TCXPipjevLbU/Xa2nndZ N722V9dUuVev4HXtreUOa31EDXe6h9C25Rqtuu9xvN711T7Xu6Yrr/um3xS3CnZanB+md07LTJ4Y s1WlRh1ry5iz61OpaQWdR5zTbM2ZSp5VMU5jNBZ1rXWNLEaPI93lGvo847119PzPovMzV83riOt9 RM67udt9OFvP0dfo6etztKPrya6vj2v9fpisntV1Tm+KRwXoJM4wM5bVftbCZmPNrM/qmjKteo66 hqvyHlUf5tl9atdDj7Pu3Sv5XO9odW13nutbZD9TWu72+jurnup9+tb1qbpbPdl1PaLOQz4+Ec3E uniOTr6XpzdWpY4spnKumolvxWrb7NhulDfK+raOXxFzZ89Nb/xRnk+h89K1MTrX2GfiWoxiWv0m xvhzjbc27/N2fexirkj7leaMRnmyemKu2Ncb01Vioko9rbzZWFmOGZrDZGNYey829pleve7KmIpR Hu+3thjbijMa26qp16dacbEty+XtKssTY2Mut3UsU4lxGpvFmFY9sa0VY0b16HkxNuZyR481yhNV 68n6R+2jerI8kcZVz2nReuz8w/7Qzgbyw2wp1mnRPaOxrH1PHUbn1atrNFbMobGttk80mqf3j/Ty WJ8eT+dzHM3ZWJ8fRudfidF2E58rOy/r9zYdM6rUU1HJo21ZTMyjzyPr88O0Ynp0fB/Pn28xO36L 5mjlizW2YrTPD6PzqsSoPXlizFaVsWJba7yYpxdrPK5nlKMn1uM5vN3EttE4WVxlLFWNGanW3VKp ObaNxsniVo1VyaN6uWZzmBij+VtjKIvVQ2meveKcDtsU+0A62BYrJ7+HzscPs3Veq/I81ei6Vq97 Fudrq4f5pHX2Oen87u6JNY/4XHw+b3st+7x1Dc7WWvsr61Few9H1VN8zM35edQ29PYvZW89qT1of b1s1lspiRutj/X6MVON6vE6vZ2++TKz1EV/Jll0k5ZOqxD5FvFj6+Mmq12rU/4nX/On23qN2vh97 rMqD/SrXohIz4u8De/M8kc9373vhqjVcVc8qT1yfVWNVjOrR/l7NRvtHsXvFtZldp9a8b78pXrmo cQGPtGcsm7MebuVa7LV1fn7OaC6j/moenMeuiV8PfTzDzonHFqvyYL/KtajEVOi5W96f7szm05qT t21ds2jvGq6uZ68nr8/esSqOuF5a9xE8fxxnxZjLN8W2wEddvMwRFzVaNa8r1ucuVl2nSp43r/OR 4praNbA2+9evhz7eY9U1XJUnmsm7twZfT8/h/25d5731bFUZd0tt8Zy4XrO21HClI15ve9ZwRT0r PW19Vo4VxdzmbtdrpdZ8e6a/fSJLrovaitmy6NU8Hrfnwt5xXibGzo5XHWs0zoq5t3I4zTUaa1We J4pzyuZTmfvM+nhsdTyNW1mzGeWr5PEYb4/PzUweFWNMK7+q1GN0vFEut6ce16vDVPOYUS5zRoz1 +fMsLra70Vixf2uelXQsG6M1x1XzqqjMvRKjWnOq0rHs/FauUT2xf0sdbtVYozxVmsfO9+eeKz53 WZxp5TEa42JeF2NH40fab483fyUbALzF6I31LHepA+txbefFNWMNsdcj/tAOAM5kP1z9B+xd8AP/ s9zxHgPejt8UA0BD3LBcuRllQ/yZ7nSPPRVriJXYFAMAAOD1+PgEAAAAXo9NMQAAAF6v+fEJ/YxO /HxO/PyO6X2G55M+Czeae6vfeZzFZGuqMZlRTMxtYmw2vmrlOZvWtbdmj7/DvAAAwP00f1OcbRx0 Y+GHaW1QTNaemY0/mtZTmbu3GY2JRvOs5MliWrljrKrM6yqxVjdb8x3mAgAA7m33xyd0U6JmNyJ3 27isqqe1NmY2f5YHf1l1HwIAgHf6ZVNsGwg/9vDzqxu5LF7r8UPNtunR4/2j+rONmBvlGdXhqvWs MppXxurUI6q2+/NW7Aw//6x1AwAAz/W9KdYNxGgToZsWP89pnoosXtu1pjjeyGyerJ5Z1TpHcdU8 dzC7xibG+HPNk7FYPZTmAQAAGNn08QnfsPiGI25Iqnobl1ZuHbNqJs/MRspi/dhidh49WsfKvLNm 1qQa1+PX0ee8Nx8AAHiv3Z8pzsRNT9yw+PPeJk43O/H8GZU8lXrUKK6S58yYo+n6jerR/qNrj9c8 u/4AAODdlm+KfVPkh9PHMxtQzbNnQ9PLM1PPjErdlTEreVaycY4ey+a0er2V54/jHDkmAAB4rsN+ Uzwy2pzEjZnH99r8X81dyWNG9WwVx9lqlCebFwAAAMZ++Z93xM2jP4+bzCjbUMbY2Y1ndaxYdzRT c08rj/FcWb+JMTp+bJvJY3q5Tcw36jcxpiLWFOsZ1RfjTCuP0RgX87oYm8UBAID3av4f7Z6mtWkC AAAAqi77+MQqbIgBAACw16M3xWyIAQAAsMJHfHwCAAAA2INN8clafyAW8ZtvAACAcz3+M8UAAADA Xpdviiu/Od3LxvBDnwMAAADm0k1xZWPqG9itG1k/xz+SEJ/P0Br0MQAAAJ7t1h+fsE2nbV71yDai 2SbVz9PH/hwAAAAw339o9+PHj58NtmGMm0vdRGYbTzWKafWbGOPPNd7atM95TGxfJavZzIzZy+OO mgMAAADavn9T7Bux3uZS+/wwutGrxGi7ic+Vndfrd5WYPTR39hgAAADP1Pz4hG/07F82fQAAAPh0 t/5MsdLfNF+h9dtwc3VdAAAA2O8Rm2L/CEV8rKz9yA2qjpk9BgAAwDPdZlMcN7S22fQNsG889TEA AACwyj++fcJlm8/Wb2NjbCXGeWx1vKdviltrEz19jgAAAE/zvSn++vr62YBjsSkGAAC4n8f8oR0A AABwFDbFAAAAeD02xQAAAHi9788U//vf//uzAQAAAHgbflMMAACAl/vtt/8A9U/sjj4Of/oAAAAA SUVORK5CYII= --00000000000087fce8062e8b12f4-- From nobody Thu Feb 20 04:22: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 4Yz0TP5q48z5pC1Y for ; Thu, 20 Feb 2025 04:22:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz0TP58m0z3M1Z; Thu, 20 Feb 2025 04:22:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740025321; 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: in-reply-to:in-reply-to:references:references; bh=ssd/ULZyfHCty/VS2OWk6kywU7ah9tr+qnxlf37gTaE=; b=wckrfj+UzzOpU++Qzlw7uwqANjcQKGuiOuYTgybNx5pK8g971DtW7wfIalfWxF5hqCrDrK D267pAW5mbaGtN/oYI9JiD43KI3UiNAsMBH0P2+jvEyrQJHRFWMoIif4SV8L953BsVL/S7 B7QvfdOoSKebyRb8H09qh+tjRXxpjX7AlUBAyeuVrdeuhT9dQdHvPgkJBIXkYznIOQcOQI f09HPHVzA0QetA4IUFxcML83QBwdIwnEjJZNi6iCNhq6Fy2aKAQMYY1X0miP8/gIbyojid wJYLQDD3SpsjroKLqzrUdbfbDRKXPMkp9tT/AuuPzxdJzYJn1TxLUQjVeSQ97g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740025321; a=rsa-sha256; cv=none; b=fD8JqCRppkvXTEEHb/HUbxYhVJxBnz1E8B3KYXm+HsELrfj2K7V86UdaIrBYvSA8QFHIw7 25fWn6eXr0+2q6BqWGKq+D5ADk7shqf7DbQLS7rihOqI4c2YHN76E+U+DGe4oeqU2/ejuE q4kN7ENEi4WuGOA/1eYSygKZJ3By3zM6LwCdMNbBHK8E9+dnFFj5ZQuUbci966Uyf7TRpj nQCZWufaFAYqYezBG4HYqsJP65D7emHX6mktcuxf+YnVVvyhpUs/hIz09pHUa60JA7+ACt BkniitZP5jAe7QALkJKbaMfnSt3rvJ/qPCFTL1w1yVHM5vvHj5OraKer3YNmXg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740025321; 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: in-reply-to:in-reply-to:references:references; bh=ssd/ULZyfHCty/VS2OWk6kywU7ah9tr+qnxlf37gTaE=; b=jmdQiAVaGsZ1FObHgzkP6IuHOOy84GlAu/KE8KwJfwMDdAYiAAzs0ExKaIYMpnXUd+Rg8k msEeHCDCjRpzL0n/6dWuGPUXzoblqBQMamxmf83oZ3jUqK82FeUH4LgUyT8j2j12saH9NJ QAZmf505WDCJvxpcITQ5PSvzK00CeUVzcBN9mr05iZTq81CzddGxQpXxcln63abXv0pC4Z N/5t8eFiKStEKxQiqTJG0HTjK/W5Wep8RsX8xvEDyCYsXB+X8G2cGRfcnT0AbuO61QPoZi 6ynoGDpscpTm9pMygyppVtzSpxnK6qi6YOXUtSg0aeuzDP08RhE2A2Q285espw== Received: from freefall.freebsd.org (unknown [IPv6:2600:4040:a6c3:2900:506:2666:153d:532c]) (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: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Yz0TP4MjCzQXH; Thu, 20 Feb 2025 04:22:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <3c7dab54-ac92-4a65-8517-e1636361e33d@FreeBSD.org> Date: Wed, 19 Feb 2025 23:22:00 -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: Very poor -CURRENT boot performance on AMD To: Mohammad Noureldin , Freebsd current References: Content-Language: en-US From: Jung-uk Kim Organization: FreeBSD.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 25. 2. 19., Mohammad Noureldin wrote: > Hi, > > I've installed -CURRENT using snapshot "FreeBSD-15.0-CURRENT- > amd64-20250213-6156da866e7d-275409" on an HP EliteBook 845 G10 with AMD > Ryzen 5 7540U. > > Both when booting from the install media and when booting from disk > after installation I get a very poor boot performance up until the > FreeBSD Boot Options Menu. Right after it is all OK. > > I've recorded what happens during the boot from the installation media > in [1]. > > Does this ring any bells ? Is it a bug that I should report in a PR > (Problem Report) ? > > [1] https://drive.google.com/file/d/1s1a9qTwh-8gWOp0Lyta_Wc0RyUAkXTND/ > view?usp=sharing d/1s1a9qTwh-8gWOp0Lyta_Wc0RyUAkXTND/view?usp=sharing> This happens because UEFI framebuffer access from boot loader is very slow. Once the kernel is loaded and booted, everything is okay because we properly set memory attribute. It's a long standing bug and there's PR254381. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254381 Jung-uk Kim From nobody Thu Feb 20 05:37: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 4Yz28L3mwxz5pH2J for ; Thu, 20 Feb 2025 05:37:22 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-10625.protonmail.ch (mail-10625.protonmail.ch [79.135.106.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz28K1PPPz3rPZ for ; Thu, 20 Feb 2025 05:37:21 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=F+A5IVGx; dmarc=none; spf=pass (mx1.freebsd.org: domain of sgharms@stevengharms.com designates 79.135.106.25 as permitted sender) smtp.mailfrom=sgharms@stevengharms.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1740029837; x=1740289037; bh=/YfTmXrhm/iXWqFR1ByiLRNUUHLm9h+j/7vd7crbRlU=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=F+A5IVGx0WFuFGUsaVxzSiih6SyI8Nrtf/aEvl6v5CQz+dBjcw5QGq9ddvzJX/kNT sW82j5OUDzxLavmyZNvXc54JUv9FstlIV3t7LMRqjAc3Ss0zIdPlbBO/kIo6rxNXFI DXNlw36fEqzy4Dz8q8P6KMQ4J+ItYmeRz3JUxGJ8= Date: Thu, 20 Feb 2025 05:37:13 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: Error messages in 15.0-CURRENT (n275524-8dc0889..) Message-ID: <-lBMvD5Tiv4yF0hnXfnTe5uomckYynoVVg4eIHbmsGnvMpKO7X9SF8zP4BFgJFdcM2AQzHNxCcQ2dXe-IzYJMMzUyauPaBMnPktD9WNJRqI=@stevengharms.com> Feedback-ID: 16996530:user:proton X-Pm-Message-ID: a7bdefe7e397b3bc3e579c78d952890ea55d32ef List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_5pqFwqYEosTMwUsIiu97NbPt2vf1qi58i1yL7mBKgE" X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:79.135.106.0/24]; R_DKIM_ALLOW(-0.20)[stevengharms.com:s=protonmail]; RWL_MAILSPIKE_VERYGOOD(-0.20)[79.135.106.25:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH]; DMARC_NA(0.00)[stevengharms.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4Yz28K1PPPz3rPZ X-Spamd-Bar: --- --b1=_5pqFwqYEosTMwUsIiu97NbPt2vf1qi58i1yL7mBKgE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Rm9sa3MsCgpJIGJ1aWx0IGEgR0VORVJJQyBrZXJuZWwgImhvdCBvZmYgdGhlIHByZXNzZXMiIGFz IG9mIHRoZSBjb21taXRzIGNpdGVkIGFib3ZlLiBJIGFtIHN1cnByaXNlZCB0aGF0IEknbSBzdGls bCBnZXR0aW5nIGVycm9yIG1lc3NhZ2VzIGluIGRtZXNn4oCLIGFib3V0OgoKLSBGaXJtd2FyZSBl cnJvcnMKCi0gaTkxNS9za2xfZG1jX3ZlcjFfMjcuYmluOiBjb3VsZCBub3QgbG9hZCBiaW5hcnkg ZmlybXdhcmUgL2Jvb3QvZmlybXdhcmUvaTkxNS9za2xfZG1jX3ZlcjFfMjcuYmluIGVpdGhlciAo cmVwZWF0cykKLSBkcm1uMDogY291bGQgbm90IGxvYWQgZmlybXdhcmUgaW1hZ2UgJ2k5MTUvc2ts X2RtY192ZXIxXzI3LmJpbicKLSBkcm1uMDogW2RybV0gRmFpbGVkIHRvIGxvYWQgRE1DIGZpcm13 YXJlLi4uRGlzYWJsaW5nIHJ1bnRpbWUgcG93ZXIgbWFuYWdlbWVudAoKLSBXYWl0LCB0aGF0IHNv dW5kcyBsaWtlLi4udXNlZnVsLiBJcyB0aGF0IHNjcmVlbiBibGFua2luZyBhbmQgYmFja2xpZ2h0 IHNodXNoaW5nPwotIEFsc28sIEkgZG9uJ3QgbGlsa2UgZmFsc2UgbmVnYXRpdmVzIGluIGRtZXNn 4oCLCi0gSSBidWlsdCBhcm0tNTE1LWttb2QgZnJvbSBwb3J0ICh3aGljaCB3b3JrZWQpIGFuZCBt YWRlIGFwcHJvcHJpYXRlIGZpbGUgYW5kIGdyb3VwIGVkaXRzLCBidXQgZXZlbiBhZnRlciByZWJv b3QgaXQgZGlkbid0IGFmZmVjdCB0aGVzZSBtZXNzYWdlcwotIFN0YWNrIHRyYWNlIGluIHRoZSBW VDogUmVwbGFjZW1lbnQgYWN0aW9uLiBTaG9ydGx5IGFmdGVyICJWVDogUmVwbGFjaW5nIGRyaXZl ciAiZWZpZmIiIHdpdGggbmV3ICJmYiIiIEkgc2VlIGEgc3RhY2sgdHJhY2UKCi0gZXhjbHVzaXZl IHNsZWVwIG11dGV4IHZ0ZGV2Li4uLiBsb2NrZWQgYXQgL3Vzci9zcmMvc3lzL2Rldi92dC92dF9j b3JlLmM6MzI2MAotIE5vdyB0aGlzIGp1c3QgaGFwcGVuZWQgdG8gYmUgdGhlIGZpbGUgSSB3YXMg aGFja2luZyBzbyBJIHdhcyB3b3JyaWVkIEknZCBpbnRybydkIGEgcmVncmVzc2lvbiA7KSBCdXQg dGhpcyBpcyBhIGdlbmVyaWMga2VybmVsLCBzbyBkb24ndCBsb29rIGF0IG1lIDopCi0gVGhlIHRy YWNlIHVsdGltYXRlbHkgc2hvd3MgZnJhbWVzIGludm9sdmluZyBpOTE1X2RyaXZlcl8ocmVnaXN0 ZXJ8cHJvYmUp4oCLLi4ud2hpY2ggc3VnZ2VzdHMgdGhhdCBtYXliZSB0aGVzZSB0d28gdGhpbmdz IGFyZSByZWxhdGVkLiBMaW5lIDMyNjAgaXMgd2hlcmUgYSBtdXRleCBpcyBzb3VnaHQgYXMgcGFy dCBvZiB0aGUgcmVwbGFjZSByb3V0aW5lLgoKSSB0aGluayBJJ3ZlIHRyb3VibGVzaG90IHRoaXMg cmVhc29uYWJseSwgaXMgdGhlcmUgc29tZSBhbmdsZSBJJ3ZlIG1pc3NlZD8gSSdkIGxpa2UgdG8g aGF2ZSBhIGNsZWFuIGRtZXNnIG9uIG15IEdFTkVSSUMgYmVmb3JlIEkgc3RhcnQgYm9sdGluZyBp biBteSBGcmFua2Vuc3RlaW4gaWRlYXMgaW50byBhIGN1c3RvbSBrZXJuZWwuCgpUaGFua3MhCgpT dGV2ZW4KCi0tLQoKUHVibGljIEtleTogMjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENF MkIwMzZERQoKTWVzc2FnZXMgZnJvbSB0aGlzIGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJl c3Qtc2VjdXJlZCBhbmQgbW9zdCByZWxpYWJsZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcg aGVhbHRoLCB3ZWFsdGgsIG9yIHJlcXVpcmluZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5 IHRvIHRoaXMgYWRkcmVzcy4KClNlbnQgd2l0aCBbUHJvdG9uIE1haWxdKGh0dHBzOi8vcHJvdG9u Lm1lL21haWwvaG9tZSkgc2VjdXJlIGVtYWlsLg== --b1=_5pqFwqYEosTMwUsIiu97NbPt2vf1qi58i1yL7mBKgE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5Gb2xrcyw8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkkgYnVpbHQgYSBHRU5FUklDIGtl cm5lbCAiaG90IG9mZiB0aGUgcHJlc3NlcyIgYXMgb2YgdGhlIGNvbW1pdHMgY2l0ZWQgYWJvdmUu IEkgYW0gc3VycHJpc2VkIHRoYXQgSSdtIHN0aWxsIGdldHRpbmcgZXJyb3IgbWVzc2FnZXMgaW4g PGNvZGU+ZG1lc2c8L2NvZGU+4oCLIGFib3V0OjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXY+PG9s IGRhdGEtZWRpdGluZy1pbmZvPSJ7JnF1b3Q7b3JkZXJlZFN0eWxlVHlwZSZxdW90OzoxLCZxdW90 O3Vub3JkZXJlZFN0eWxlVHlwZSZxdW90OzoxfSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyI+PGxpIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsgbGlzdC1zdHlsZS10eXBlOiAmcXVvdDsxLiAmcXVvdDs7Ij48 c3Bhbj5GaXJtd2FyZSBlcnJvcnM8L3NwYW4+PC9saT48b2wgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBsaXN0LXN0eWxlLXR5cGU6IGxvd2VyLWFscGhhOyI+PGxp IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi PjxzcGFuPmk5MTUvc2tsX2RtY192ZXIxXzI3LmJpbjogY291bGQgbm90IGxvYWQgYmluYXJ5IGZp cm13YXJlIC9ib290L2Zpcm13YXJlL2k5MTUvc2tsX2RtY192ZXIxXzI3LmJpbiBlaXRoZXIgKHJl cGVhdHMpPC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPjxzcGFuPmRybW4wOiBjb3VsZCBub3QgbG9hZCBmaXJtd2Fy ZSBpbWFnZSAnaTkxNS9za2xfZG1jX3ZlcjFfMjcuYmluJzwvc3Bhbj48L2xpPjxsaT48Zm9udCBm YWNlPSJBcmlhbCwgc2Fucy1zZXJpZiI+ZHJtbjA6IFtkcm1dIEZhaWxlZCB0byBsb2FkIERNQyBm aXJtd2FyZS4uLkRpc2FibGluZyBydW50aW1lIHBvd2VyJm5ic3A7bWFuYWdlbWVudDwvZm9udD48 L2xpPjxvbCBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGxpc3Qt c3R5bGUtdHlwZTogbG93ZXItcm9tYW47Ij48bGk+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMtc2Vy aWYiPldhaXQsIHRoYXQgc291bmRzIGxpa2UuLi51c2VmdWwuIElzIHRoYXQgc2NyZWVuIGJsYW5r aW5nIGFuZCBiYWNrbGlnaHQgc2h1c2hpbmc/PC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9IkFy aWFsLCBzYW5zLXNlcmlmIj5BbHNvLCBJIGRvbid0IGxpbGtlIGZhbHNlIG5lZ2F0aXZlcyBpbiA8 Y29kZT5kbWVzZzwvY29kZT7igIs8L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQXJpYWwsIHNh bnMtc2VyaWYiPkkgYnVpbHQmbmJzcDthcm0tNTE1LWttb2QgZnJvbSBwb3J0ICh3aGljaCB3b3Jr ZWQpIGFuZCBtYWRlIGFwcHJvcHJpYXRlIGZpbGUgYW5kIGdyb3VwIGVkaXRzLCBidXQgZXZlbiBh ZnRlciByZWJvb3QgaXQgZGlkbid0IGFmZmVjdCB0aGVzZSBtZXNzYWdlczwvZm9udD48L2xpPjwv b2w+PC9vbD48bGkgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyBsaXN0LXN0eWxlLXR5cGU6ICZxdW90OzIuICZxdW90OzsiPjxzcGFuPlN0YWNr IHRyYWNlIGluIHRoZSBWVDogUmVwbGFjZW1lbnQgYWN0aW9uLiBTaG9ydGx5IGFmdGVyICJWVDog UmVwbGFjaW5nIGRyaXZlciAiZWZpZmIiIHdpdGggbmV3ICJmYiIiIEkgc2VlIGEgc3RhY2sgdHJh Y2U8L3NwYW4+PC9saT48b2wgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBsaXN0LXN0eWxlLXR5cGU6IGxvd2VyLWFscGhhOyI+PGxpIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPmV4Y2x1c2l2ZSBzbGVlcCBt dXRleCB2dGRldi4uLi4gbG9ja2VkIGF0IC91c3Ivc3JjL3N5cy9kZXYvdnQvdnRfY29yZS5jOjMy NjA8L2xpPjxsaSBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij5Ob3cgdGhpcyBqdXN0IGhhcHBlbmVkIHRvIGJlIHRoZSBmaWxlIEkgd2FzIGhh Y2tpbmcgc28gSSB3YXMgd29ycmllZCBJJ2QgaW50cm8nZCBhIHJlZ3Jlc3Npb24gOykgQnV0IHRo aXMgaXMgYSBnZW5lcmljIGtlcm5lbCwgc28gZG9uJ3QgbG9vayBhdCBtZSA6KTwvbGk+PGxpIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPlRo ZSB0cmFjZSB1bHRpbWF0ZWx5IHNob3dzIGZyYW1lcyBpbnZvbHZpbmcgPGNvZGU+aTkxNV9kcml2 ZXJfKHJlZ2lzdGVyfHByb2JlKTwvY29kZT7igIsuLi53aGljaCBzdWdnZXN0cyB0aGF0IG1heWJl IHRoZXNlIHR3byB0aGluZ3MgYXJlIHJlbGF0ZWQuIExpbmUgMzI2MCBpcyB3aGVyZSBhIG11dGV4 IGlzIHNvdWdodCBhcyBwYXJ0IG9mIHRoZSByZXBsYWNlIHJvdXRpbmUuPC9saT48L29sPjwvb2w+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPjxmb250IGZhY2U9IkFyaWFsLCBzYW5zLXNlcmlmIj48YnI+PC9mb250PjwvZGl2Pjwv ZGl2PjxkaXYgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxm b250IGZhY2U9IkFyaWFsLCBzYW5zLXNlcmlmIj5JIHRoaW5rIEkndmUgdHJvdWJsZXNob3QgdGhp cyByZWFzb25hYmx5LCBpcyB0aGVyZSBzb21lIGFuZ2xlIEkndmUgbWlzc2VkPyBJJ2QgbGlrZSB0 byBoYXZlIGEgY2xlYW4gZG1lc2cgb24gbXkgR0VORVJJQyBiZWZvcmUgSSBzdGFydCBib2x0aW5n IGluIG15IEZyYW5rZW5zdGVpbiBpZGVhcyBpbnRvIGEgY3VzdG9tIGtlcm5lbC48L2ZvbnQ+PC9k aXY+PGRpdiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGZv bnQgZmFjZT0iQXJpYWwsIHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGZvbnQgZmFjZT0iQXJpYWws IHNhbnMtc2VyaWYiPlRoYW5rcyE8L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMtc2VyaWYi Pjxicj48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyI+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMtc2VyaWYiPlN0ZXZlbjwvZm9udD48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPjxicj48L2Rpdj4NCjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Js b2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyIj4N CiAgICAgICAgPGRpdj4tLS08YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2Io MCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlB1YmxpYyBL ZXk6IDxhIHRpdGxlPSIyMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUExNkQ4Q0UyQjAzNkRFIiBo cmVmPSJodHRwczovLzIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REUiPjxz cGFuPjIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REU8L3NwYW4+PC9hPjxi cj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiPjxicj48L2Rpdj48ZGl2Pk1lc3NhZ2VzIGZyb20g dGhpcyBhY2NvdW50IGFyZSBjb25zaWRlcmVkIHRoZSBiZXN0LXNlY3VyZWQgYW5kIG1vc3QgcmVs aWFibGUuIFNlbmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGhlYWx0aCwgd2VhbHRoLCBvciByZXF1 aXJpbmcgaGlnaGVyIHN0YW5kYXJkcyBvZiBzZWN1cml0eSB0byB0aGlzIGFkZHJlc3MuPGJyPjwv ZGl2Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9InBy b3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+DQogICAgICAgIFNlbnQgd2l0aCA8YSB0 YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly9wcm90b24ubWUvbWFpbC9ob21lIj5Qcm90b24g TWFpbDwvYT4gc2VjdXJlIGVtYWlsLg0KICAgIDwvZGl2Pg0KPC9kaXY+DQo= --b1=_5pqFwqYEosTMwUsIiu97NbPt2vf1qi58i1yL7mBKgE-- From nobody Thu Feb 20 09:27:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yz7Gh5BsVz5nbZJ for ; Thu, 20 Feb 2025 09:28:12 +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 "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz7Gf3XfFz3G8B for ; Thu, 20 Feb 2025 09:28:10 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=fwpjTPG2; 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=1740043670; 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=64mzcdH4iRKw/BJGzENw6ZchHZ/A5SsUUsDeMbkPGqQ=; b=fwpjTPG263OYuL55Jj0kUrN6faSKs40ekgHVXw6ZORmZYFpDiFnJo1l3QrVFU5rgS5TesX msHvHeljopXUftKpqkq8G0FCBCg46Wb+oXEI+OaD4ZqigtqBa0P8rfO3yA3FYOD+o/CZI+ yUGKx82vqIuxesir0GPq80VEZvgE0lXe+ncVivt7xhEr5l9QOb2cChtigGJiuFsoMmhRiZ 3iqb+Gxg/ZxQwfD0K8zQ612DX9UvvGo2rTYKauVoTk1wJQQ+wz3nyndP89A4wR9zP41EUA zdrJpKtpkJW2ayJGFpx088dRnFJ7vyzG1u2ylGyzs1s4H/cRJN9TqVs2rTq+zA== Date: Thu, 20 Feb 2025 10:27:28 +0100 From: Alexander Leidinger To: Current FreeBSD Subject: crash with head as of 2h ago (in_pcblbgroup_insert) Message-ID: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_861bd1ac6280a0f370578510fcc924c2"; micalg=pgp-sha256 X-Spamd-Result: default: False [-5.36 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.36)[-0.365]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ONCE_RECEIVED(0.10)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Yz7Gf3XfFz3G8B X-Spamd-Bar: ----- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_861bd1ac6280a0f370578510fcc924c2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I get this backtrace: ---snip--- [102] panic: invalid local group size 16 and count 16 [102] cpuid = 17 [102] time = 1740041984 [102] KDB: stack backtrace: [102] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe07453a5b80 [102] vpanic() at vpanic+0x136/frame 0xfffffe07453a5cb0 [102] panic() at panic+0x43/frame 0xfffffe07453a5d10 [102] in_pcblbgroup_insert() at in_pcblbgroup_insert+0xaa/frame 0xfffffe07453a5d30 [102] in_pcblisten() at in_pcblisten+0x92/frame 0xfffffe07453a5d50 [102] tcp_usr_listen() at tcp_usr_listen+0x18a/frame 0xfffffe07453a5db0 [102] solisten() at solisten+0x47/frame 0xfffffe07453a5dd0 [102] kern_listen() at kern_listen+0x3f/frame 0xfffffe07453a5e00 [102] amd64_syscall() at amd64_syscall+0x15b/frame 0xfffffe07453a5f30 [102] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe07453a5f30 ---snip--- This is with head updated at 2025-02-20-080119 CET. The previous world is from 1 month ago (2025-01-22-120655). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_861bd1ac6280a0f370578510fcc924c2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAme29Y8ACgkQEg2wmwP4 2IZVjQ/9EDTELaioGJwzikREDQswO96RyOaftWyV4ZaoX9MXqVojGAjY38At9zEc 4qW2fr6O8Ti3KwIUOTPv8rQXo1XHWPIjgafZSDwIwJVpTJrzREarT/XmyuAbsBqf M80a438qTdTLlK6He1uoxqFtiINvjEIyCRit20bBDk3rpvFxG71qR7IQHjzbbulP utQiF7r8uGC0Nxqep4bEej2KIpgibjkhg7ZxZBXkg2FF4QU1yI6qZJbrYOsJL7AZ 0UGvC/JlP46OJU37Rta5rW7mpAB2K6sTnkYhCN1meGjOVJtTQlDqCHxqZSxGGqmB 9mAu6rs6V55BRO3Au03HroYll1qd4dRSi4N9zXW1B3n9yPMSljWio5hg39zZ09Zz OHkTNFYmqi/H0kknm+1YY4sWBf/EKlhPOK8GKgT8WMaYseTgEQHqMwCQCMGLQ46M 4PzfqJRKMhYlwtrDn7ohCazp/y+YYLSv+lgioGB+Fes6J6n/JRbwEJKBuVs4KOtt 7yEF14xQlEBR40BGKpeRyYLyHZu7rFr7C/urTw++TuC15bH4tz/Bl11wR9yJcOaE ao8S/oQ2LoWODmrgNDtva9vpxMu2OfbYXnqrODTxOAJD4ifFdJ6H7MuIYTlPVpe1 UaDRSkfK6m2lc+eHPOqHfbHEn+u1QplY+ADvcGBuUILnC7/znlA= =J44n -----END PGP SIGNATURE----- --=_861bd1ac6280a0f370578510fcc924c2-- From nobody Thu Feb 20 09:40:54 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 4Yz93h4VVGz5nhwP for ; Thu, 20 Feb 2025 10:48:48 +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 4Yz93f3Y0Yz3pnK for ; Thu, 20 Feb 2025 10:48:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk 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 EEEC089287 for ; Thu, 20 Feb 2025 10:48:37 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 51K9eswS003142; Thu, 20 Feb 2025 09:40:54 GMT (envelope-from phk) Message-Id: <202502200940.51K9eswS003142@critter.freebsd.dk> To: current@freebsd.org Subject: Empty structures have sizeof(1) in C++ now ? From: Poul-Henning Kamp 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: <3140.1740044454.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Feb 2025 09:40:54 +0000 X-Spamd-Result: default: False [-1.75 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.94)[-0.937]; NEURAL_HAM_SHORT(-0.81)[-0.815]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[phk]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4Yz93f3Y0Yz3pnK X-Spamd-Bar: - Is this a bug ? critter phk> cat /tmp/_.c #include struct foo { }; int main(int argc, char **argv) { struct foo bar; printf("%jd %jd\n", sizeof(struct foo), sizeof(bar)); return (0); } critter phk> cc -o /tmp/a.out /tmp/_.c critter phk> /tmp/a.out 0 0 critter phk> c++ -o /tmp/a.out /tmp/_.c c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior= is deprecated [-Wdeprecated] critter phk> /tmp/a.out 1 1 -- = 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 Thu Feb 20 11:03:39 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 4Yz9Nx42zSz5nk6X for ; Thu, 20 Feb 2025 11:03:45 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz9Nx3HNpz3w3j; Thu, 20 Feb 2025 11:03:45 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049425; 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=4fxZRXCaXViuwkr/QxtVFahEx9HJy8f/+BJWUNlaHg0=; b=uba0wHBi8bOyA/AYqPJpAalqDNQRwhF13aMTWPGp9MDt5bPZwjlA2EnWTCVRGzUKJ2EXC4 diEbHVeAfjeb1nm3NGyBM+BBst6aQXhZpqcwOjE9uwtPCxhpQBaeGQeEWaeAEUuS5SoGs+ liuZ3czRBnOK4L/7FhYsmtbUsJi5lujZG3cG/NMGNr5gdjtFPc3zLbD353n0TF8YB3DRhr xTs67SDtOIhpOmO8/CvKbjXVTdKWKrtj1tHxci7Us0Vk91QERwN+m3wsazgZVxIQaLOFlF Z6/buKd7QzEsuP9IGsciBDPtbTOR00DwR6h1+7stRxu7vM+NFBh0kI8vT89LWg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740049425; a=rsa-sha256; cv=none; b=kJCcmQZH9D2o4m54oZxuTpdqfe/Al9otVoIcszh7Hj9oocFdPbHuhC4P26rq+pQ0d5f/aZ 5EhFD9x46/sF/p17e212VaRrJ08h5ubsx5/o5Ta4fUnv5LX6MoKE7mzkAWu+bQJvAzDW7n 5tjwYl/YCnaYTPo8+SJvykV9ZuavpCYvTdmzhDXGef2ldmVCO8CSwjpJkUT2d9+JpQPo/7 H66Ekgmiajt4/E35y7/X3TJGNwh+HrQEi6//Tzq/EYQyWZyDsOy7OMpOWUUdFG4KYnz0Jf APTezrHJ51uyNSfXyIXaj9N8cIXxTosurGZkXACQtTT5HadGN7qH7VsOwZuE+g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049425; 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=4fxZRXCaXViuwkr/QxtVFahEx9HJy8f/+BJWUNlaHg0=; b=JCJVBRMMXGhBGxa3GSkA74NiU9veJ6BZPQGJn4Iuf2qA69HB8tZJ3VEsY74/jv4eA6eQ5l bxkkpCdGB7gQxzp+sXGuI0q2Xa3VsKC3xih8JU5VO5AzY7j0qKsF4sRxrik03wy3NZ5mP+ xdxek92MWz7pknF9KImw7PVnsDTWnBLKBmOZNNLRVQ12xrHqOSeyKv8tqRaIiYaVuUmxWn KKkpuNdpll/cFp/teW9xPH2w/T0u/9Zkg80DgzHKRdJYfTFX95u4MjMSjkKomVjDmlAN31 6/RX/lj6tEW+Hpl1Cl11s7UygJ9s+8GHfb78wahoq0geBnBMv9MFuiz78yaUOw== Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Yz9Nx0Bhlzqdf; Thu, 20 Feb 2025 11:03:44 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id cce14b8d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 20 Feb 2025 11:03:42 +0000 (UTC) Date: Thu, 20 Feb 2025 12:03:39 +0100 From: Michael Gmelin To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: Empty structures have sizeof(1) in C++ now ? Message-ID: <20250220120339.2f1af442.grembo@freebsd.org> In-Reply-To: <202502200940.51K9eswS003142@critter.freebsd.dk> References: <202502200940.51K9eswS003142@critter.freebsd.dk> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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 On Thu, 20 Feb 2025 09:40:54 +0000 Poul-Henning Kamp wrote: > Is this a bug ? > > > critter phk> cat /tmp/_.c > > #include > struct foo { > }; > > int > main(int argc, char **argv) > { > struct foo bar; > printf("%jd %jd\n", sizeof(struct foo), sizeof(bar)); > return (0); > } > critter phk> cc -o /tmp/a.out /tmp/_.c > critter phk> /tmp/a.out > 0 0 > critter phk> c++ -o /tmp/a.out /tmp/_.c > c++: warning: treating 'c' input as 'c++' when in C++ mode, > this behavior is deprecated [-Wdeprecated] critter phk> /tmp/a.out > 1 1 > AFAIK it has always been like that, see https://www.stroustrup.com/bs_faq2.html#sizeof-empty : To ensure that the addresses of two different objects will be different. For the same reason, "new" always returns pointers to distinct objects. -m -- Michael Gmelin From nobody Thu Feb 20 11:03:28 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 4Yz9Nz4Wgpz5njlK for ; Thu, 20 Feb 2025 11:03:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz9Nz1hnCz3vxJ; Thu, 20 Feb 2025 11:03:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049427; 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=yF/D25t/FlzN714fNAU31LdlXyX9sXuntdNBIhSah08=; b=JHX4ayY0dbD9ADeMsBqzrPmVk8pOKwRy/UVihvKvpeDw/oe77do4An7kY2OIvqptNFtDm1 NxZ/l1t3SgHv1nFb6vFyixyf9XtcsI71+Tw9st1YhBW2IdPMI1J55U1zQg9jjUS8si6KL5 8BFTiTdOGfWInWm11cYNKqO8XWcVDt0/i+lpmC6ZY/6SrgMQOcNfVbOYegGAbwkPaqYAPm GRoVvaZMPalKP8KVQXKerHkqkPIXhJOU4eCEyhJNe+yJ7EkHY+SmEixwpdGaFIufd4/2Zk bZQVEDG9zqB6CO0fyodJ/dO/sVclqThtUJx24YkTT8js/QOZYd+NkwHfNljTVw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740049427; a=rsa-sha256; cv=none; b=tgaKOyH2Ns0X1WObYdzxTseJrSbEwxIF/Sw2zVU79EXTZ5l7RpzcBt/Z51fGywyyY1QNe3 U5CKMUbXjm5wS4/mX1dQK83+EtLcsuy38WRHk+q2woSvhb+TKf9x44IKjEx+hh0BLEObMw WFSoX1y3WrPk8MvfpoqwIyOv7Db4WzHR7qCGBgpAmmmHea0j0ZLeJjSGjUGf0doRuByKrI KOLMcSdp1v/ON5Y+T/tOeS+bhyQpS8o/B3uM9Bq+4inE1NEYnv9sGN92WwEL+faUYUUqZn J7EojoDO9X5gdx32hUaPraB20P1y3PeM3pUCw4tBeEt0C8Xm1tYlXBkTLWQy2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049427; 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=yF/D25t/FlzN714fNAU31LdlXyX9sXuntdNBIhSah08=; b=Ar4JieUJS+j711Mhl1mxFhRNm2X/vtcGW0d2YMhFeG9xtOMrS+HSJlL5ikrbc6ZcffhcBB XTX3zISzoSvbup1sgSqzMfedA8S40M7vy9oMd6JzDZPWJ7j+R96s261/91rKLVicAaUmAy aPMQ6eedA5MJBT6DJx7dSIumlG2Tcquln7u3g/p+QcG8b3/cafWsnFlVqqV7gbKHSl8btC mKs38KbIqibmgz+QlVdTktW5K7pGzTAqjkjLuKfi3eVGSUbd2yjenVIckDsy1D89Q0N4VN rY4YP1kPhVERSy8HX/FxiTYdMmmFcetH6PHInKpiztkwGzkxEVetTTbPwLwYoQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Yz9Nz1FdnzqK2; Thu, 20 Feb 2025 11:03:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (unknown [194.168.166.4]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 22608D8; Thu, 20 Feb 2025 11:03:46 +0000 (GMT) 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 \(3776.700.51.11.1\)) Subject: Re: Empty structures have sizeof(1) in C++ now ? From: David Chisnall In-Reply-To: <202502200940.51K9eswS003142@critter.freebsd.dk> Date: Thu, 20 Feb 2025 11:03:28 +0000 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9A5B431C-2405-412A-90FF-DA016E80DF68@FreeBSD.org> References: <202502200940.51K9eswS003142@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3776.700.51.11.1) No, that=E2=80=99s always been the case in C++. It comes from the rule = that two allocations must have unique addresses. If a structure could = have size zero, an array of these structures would have size zero and = the two elements in the array would have the same address. Similarly, = two struct fields could have the same address, which breaks other bits = of the language (pointers to members would compare equal when they = should not). C++20 introduced the no_unique_address attribute. This allows you to = embed a struct in another and, if the child struct has no fields, then = its address is not required to be unique and you are explicitly saying = that you won=E2=80=99t do any of the things where this would be a = problem. =20 This lets you do things like: ```c++ template struct SomeStructThatMayContainAnother { // Normal fields go here [[no_unique_address]] std::conditional_t, struct {}, = Embedded> embeddedStruct; // More fields maybe here }; ``` In this case, `embeddedStruct` will not add any space to the parent = struct if the template parameter is `void`. David > On 20 Feb 2025, at 09:40, Poul-Henning Kamp = wrote: >=20 > Is this a bug ? >=20 >=20 > critter phk> cat /tmp/_.c >=20 > #include > struct foo { > }; >=20 > int > main(int argc, char **argv) > { > struct foo bar; > printf("%jd %jd\n", sizeof(struct foo), sizeof(bar)); > return (0); > } > critter phk> cc -o /tmp/a.out /tmp/_.c > critter phk> /tmp/a.out > 0 0 > critter phk> c++ -o /tmp/a.out /tmp/_.c > c++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] > critter phk> /tmp/a.out > 1 1 >=20 > --=20 > 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. >=20 >=20 From nobody Thu Feb 20 11:08:10 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 4Yz9V42YrRz5nkB6 for ; Thu, 20 Feb 2025 11:08:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yz9V41tfMz40sF; Thu, 20 Feb 2025 11:08:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049692; 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=xtYuWM8kHO4Azypm0oV1m/K8k+rs8m7tCfstlKRhJyM=; b=RgeJ/T5YzmMUxNlN7CD+sHH3KZUSsARQv1SRaDOypGIqByqQqaA0xEqIfzzO5wYBVT8fgj 4OCoVekRJrroK8Ihmjim6S3bfMX6xypQwWAvmI39XS/95KSFtb4g5LZeJ6RaZj3Y01Q09g FNFgw9PMKykdflc11OS8Gc/9Ax1+N/xfnAQA9FzEpqWAo6I8U0cTFrE8RQ96U0TykWfaBi KRVJ/Op96eijgRodlxlH5iAO2QG3B6Ou9Wmsy6EjlcZq+jBhHmCtxqN3wYI8cDVyNnAdXD lr4MsNBEZaAt7F++mo8TEhI0xxFs9CRAciB0QmYS105hZ8B53PeWTO397af/Ag== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740049692; a=rsa-sha256; cv=none; b=raIDz0MVIqizx/O5rJjyfOOqBQOJ5eU4wDLVA5h1slCiI3HM0fvOAQZ+1/M3bLNVpIHkOO UI9zKDxdqnCEvxi6yeuO/JO+0/PTra+HXYWuZr5+LWTDlFTm9s/OOjRXLdDEtkRgdoiH10 Gpt48mv2cEMvXWuyZhanXTGa3ELzviEdQmz/o25othZvEhwIM/AJyGiUrFI261cpCCqDMd 0zn67u5WMfh6EJlkwWr4FBQaszJJIJhGZ/KeruaBURNndK9FPNQj/PA9kCH3UFOutWaEMS zXbIva/0yep0ncOnR88ZMYWi3pgVDXvjg7syOGq0YEvJkMX+p+SYRpSEE43/EQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740049692; 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=xtYuWM8kHO4Azypm0oV1m/K8k+rs8m7tCfstlKRhJyM=; b=vulQQm8CGRAU2wGFz9mZbzgT+325Sc0iVoYQkElNF4KwRr5i2kD+nMTFHrix1yenL6CeHL 2lDuDoJ1fW1akyFUtJB0hGH9KEAaEaeL7fvosylvbPEOLgUcJTJEOO4CiPebzIh4f6dMef CBpbV/ss8/rwJdqUsWtWz0kr5C+iJAcxzqsERyteypmotv9ZGHUo6nxVbTc405L8VSxIkz 5kPTSeQNkVw3xetNcIUJ5muMavtRgNuMCrpiJ0IOKxn1js/yIpyVOVb3b+88/0fcEmFwM0 nhKGpuoYpP2I7BUYCzCOighuS1W8/tsCKtHTzBguzrCthnYg/wN2Hl02mNvEMw== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R10" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Yz9V40Yxvzqdg; Thu, 20 Feb 2025 11:08:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8251F56932; Thu, 20 Feb 2025 12:08:10 +0100 (CET) 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 \(3731.700.6.1.9\)) Subject: Re: Empty structures have sizeof(1) in C++ now ? From: Dimitry Andric In-Reply-To: <9A5B431C-2405-412A-90FF-DA016E80DF68@FreeBSD.org> Date: Thu, 20 Feb 2025 12:08:10 +0100 Cc: current@freebsd.org, David Chisnall Content-Transfer-Encoding: quoted-printable Message-Id: <9AD91F33-8A44-480C-9DAB-766D6C0228B5@FreeBSD.org> References: <202502200940.51K9eswS003142@critter.freebsd.dk> <9A5B431C-2405-412A-90FF-DA016E80DF68@FreeBSD.org> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3731.700.6.1.9) In fact, in C having a struct without members is undefined behavior: > If the struct-declaration-list does not contain any named members, = either directly or via an anonymous structure or anonymous union, the = behavior is undefined. However, gcc allows this as an extension, and clang has apparently = followed that: https://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html -Dimitry > On 20 Feb 2025, at 12:03, David Chisnall wrote: >=20 > No, that=E2=80=99s always been the case in C++. It comes from the = rule that two allocations must have unique addresses. If a structure = could have size zero, an array of these structures would have size zero = and the two elements in the array would have the same address. = Similarly, two struct fields could have the same address, which breaks = other bits of the language (pointers to members would compare equal when = they should not). >=20 > C++20 introduced the no_unique_address attribute. This allows you to = embed a struct in another and, if the child struct has no fields, then = its address is not required to be unique and you are explicitly saying = that you won=E2=80=99t do any of the things where this would be a = problem. =20 >=20 > This lets you do things like: >=20 > ```c++ > template > struct SomeStructThatMayContainAnother > { > // Normal fields go here >=20 > [[no_unique_address]] > std::conditional_t, struct {}, = Embedded> embeddedStruct; >=20 > // More fields maybe here > }; > ``` >=20 > In this case, `embeddedStruct` will not add any space to the parent = struct if the template parameter is `void`. >=20 > David >=20 >> On 20 Feb 2025, at 09:40, Poul-Henning Kamp = wrote: >>=20 >> Is this a bug ? >>=20 >>=20 >> critter phk> cat /tmp/_.c >>=20 >> #include >> struct foo { >> }; >>=20 >> int >> main(int argc, char **argv) >> { >> struct foo bar; >> printf("%jd %jd\n", sizeof(struct foo), sizeof(bar)); >> return (0); >> } >> critter phk> cc -o /tmp/a.out /tmp/_.c >> critter phk> /tmp/a.out >> 0 0 >> critter phk> c++ -o /tmp/a.out /tmp/_.c >> c++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] >> critter phk> /tmp/a.out >> 1 1 >>=20 >> --=20 >> 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. >>=20 >>=20 >=20 >=20 From nobody Thu Feb 20 11:47:26 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 4YzBMQ0nFhz5nmRR for ; Thu, 20 Feb 2025 11:47:30 +0000 (UTC) (envelope-from SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4YzBMN4f8kz3Mty for ; Thu, 20 Feb 2025 11:47:28 +0000 (UTC) (envelope-from SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ni0XE2Hz; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl" Date: Thu, 20 Feb 2025 12:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1740052046; 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=Ir4HQ2mILtaZExaMAXG6QYrsBut807g1FtLdMxxs5I8=; b=ni0XE2Hz7YedMjDAGZhJ6liqOqzFdow8BrhrJn8asaSjue0ecbyhofW2kgPZhjrRxX1JIT 3xtW8Ow/Z+WFxG+RkTGnq0uVU9fcZiBRsHhJL+e25gR2ijwbkiA8lqYNhGaZhMXc4et53r AWTSCz0gdjcAXeV3mIdKhm9gWpbhLvJZn0VIYZwt+wOp2e0Bd18vxivm5Mif8aSavfnlZd SRjuRACgJQwU0iV6cz0gK/NQCPUZGQMRdMqWGyZxhb2/eVhyD9vfYMYtXJvKhFmqUpE4r6 JfIw2LZHSSKPTSiXLpeHCOmnje43OWSyEsmvOdNR50XgxgolzQRaUL8Xyw+7Tg== From: Ronald Klop To: Rick Macklem Cc: FreeBSD CURRENT , Gleb Smirnoff Message-ID: <2082771622.1171.1740052046496@localhost> In-Reply-To: References: Subject: Re: RFC: mount_nfs failure due to dns not running yet 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_1170_2115107581.1740052046373" X-Mailer: Realworks (739.8) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-4.09 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[194.109.157.24:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_FROM(0.00)[x,D=VL=klop.ws=ronald-lists]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=@realworks.nl]; DKIM_TRACE(0.00)[klop.ws:+]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from] X-Rspamd-Queue-Id: 4YzBMN4f8kz3Mty X-Spamd-Bar: ---- ------=_Part_1170_2115107581.1740052046373 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Rick Macklem Datum: woensdag, 19 februari 2025 23:40 Aan: FreeBSD CURRENT CC: Gleb Smirnoff Onderwerp: RFC: mount_nfs failure due to dns not running yet > > Hi, > > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. > > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. > > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) > > 3) Add a new NFS mount option "retrydns=", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". > > 4) ??? > > So, what do you think is the preferred change? > > rick > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) > > > > Add the 'late' option in fstab. So DNS should be up. Assumes the NFS share is not needed during boot of course. @work we use IP addresses for NFS mounts as it is so low level in the infra that we can't assume DNS yet. And our NFS servers don't change IP address often. This has proven to be pretty robust in the past years. Regards, Ronald. ------=_Part_1170_2115107581.1740052046373 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Rick Macklem <rick.macklem@gmail.com>
Datum: woensdag, 19 februari 2025 23:40
Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
CC: Gleb Smirnoff <glebius@glebi.us>
Onderwerp: RFC: mount_nfs failure due to dns not running yet

Hi,

The subject line basically describes the problem glebius@
ran into.  When doing an NFS mount in /etc/fstab, it failed
since the DNS service was not yet working and, as such,
the DNS lookup of the server fqdn failed, causing the mount
to fail. Note that this behaviour has existed for decades.

He feels this is a bug and that mount_nfs(8) should retry
getaddrinfo(3) calls until success, instead of failing the
mount when the first attempt fails.
The problem with just retrying getaddrinfo(3) is that it
could retry forever for simple failures like a typo in the
server fqdn.
I can see several ways this can be handled and would
like feedback from others w.r.t. these alternatives.

1) Simply document this case and encourage use of
    host names in /etc/hosts for NFS servers along with
    specifying use of file before dns in nsswitch.conf.
     Doing this results in the mounts working whether or
      not DNS is working.

2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3)
     until it succeeds. (I feel this would be a POLA violation,
     given that the current behaviour has existed for decades
     and for simple cases where the fqdn will never resolve
     the behaviour would be to hang at the mount attempt
     during boot unless "bg" is specified for the /etc/fstab entry.)

3) Add a new NFS mount option "retrydns=<N>", which would enable
    retries of getaddrinfo(3). This would avoid any POLA violation and
    would allow for a convenient way to document the behaviour in
    "man mount_nfs".

4) ???

So, what do you think is the preferred change?

rick
ps: I looked and the return value from getaddrinfo(3) does not
      appear to be useful to discern the case of "DNS service not
      running yet". (I think it replies EAI_FAIL for this case.)
 


Add the 'late' option in fstab. So DNS should be up. Assumes the NFS share is not needed during boot of course.

@work we use IP addresses for NFS mounts as it is so low level in the infra that we can't assume DNS yet. And our NFS servers don't change IP address often. This has proven to be pretty robust in the past years.

Regards,
Ronald.
  ------=_Part_1170_2115107581.1740052046373-- From nobody Thu Feb 20 14:10:49 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 4YzFYH4sx6z5nx7B for ; Thu, 20 Feb 2025 14:11:15 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4YzFYF1Qdnz3T3b for ; Thu, 20 Feb 2025 14:11:12 +0000 (UTC) (envelope-from janm@transactionware.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of janm@transactionware.com designates 203.14.245.7 as permitted sender) smtp.mailfrom=janm@transactionware.com Received: (qmail 9483 invoked by uid 907); 20 Feb 2025 14:11:04 -0000 Received: from i5E864487.versanet.de (HELO smtpclient.apple) (94.134.68.135) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Fri, 21 Feb 2025 01:11:04 +1100 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.400.131.1.6\)) Subject: Re: RFC: mount_nfs failure due to dns not running yet From: Jan Martin Mikkelsen In-Reply-To: Date: Thu, 20 Feb 2025 15:10:49 +0100 Cc: FreeBSD CURRENT , Gleb Smirnoff Content-Transfer-Encoding: quoted-printable Message-Id: <86DA09CB-C743-498A-BD6D-8A36D247878F@transactionware.com> References: To: Rick Macklem X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spamd-Result: default: False [-1.82 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:203.14.245.0/24]; NEURAL_HAM_SHORT(-0.12)[-0.124]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[transactionware.com]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4YzFYF1Qdnz3T3b X-Spamd-Bar: - Hi, DNS resolvers can fail transiently, as can UDP. At least some retries = seem to make sense. (I don=E2=80=99t use NFS; this is a general comment.) Regards, Jan M. > On 19. Feb 2025, at 23:40, Rick Macklem = wrote: >=20 > Hi, >=20 > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. >=20 > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. >=20 > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. >=20 > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) >=20 > 3) Add a new NFS mount option "retrydns=3D", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". >=20 > 4) ??? >=20 > So, what do you think is the preferred change? >=20 > rick > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) >=20 From nobody Thu Feb 20 17:26:34 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 4YzKts2DGTz5pB8n; Thu, 20 Feb 2025 17:26:45 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YzKts1jzMz3qrl; Thu, 20 Feb 2025 17:26:45 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740072405; 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=VHuPs4rBXf8pe95n0bUKg6rOpw+tVARwCYhm5u9Lwqo=; b=jJbH+cwVpK5VdN7UnjuN3Gk9dNvUWzYnJKxeUjDNGKRRYsTKUYcAC5U0Tq1f0Tjrhuc5CD cxBTpUCXgfTQ2SiWdesn5Bfgo+s4SRzCphhaxmws1z6pCtndgqMXDxVWjierGmhT6fDC8O +P5b2Qpxk5KVdCLeBbdQtTb3pgAebGCFx78rT/UzjlG8efQQ8wG6DvJgxBztM4ZqlXLmLF 8u4nnJV+1vXfWhErrWHXH2UaJKUa4DS6df9tbEbRRMJX4dmz7AwW+HS+nASysW1u1EeXJ0 RpYObwXA/zsp2mf4LhuCLWo0hyDL9pyWG/MoWay58IEarqCijFyXFMVg/CAzYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740072405; a=rsa-sha256; cv=none; b=GmRJ4McyfMB0CfCTCw1EgzAd3Pj1N5vPrzpvUqNMKjJxACYwG6GJMp/qUGJaK+k3u1zUWP fqnMdqMlVfrSWtqbsCmRwpl1jndb1hBcgUofHLO+7BjLzaN9ttGpqYtuVV0pjsw1DjHlMT dtuD+QMpZ4iAidO8hKP4Ssd6uHmqMF1oAzCP9foo7QrYp1SmjW/e4mAq7jcy2F7/+fZcL8 2PZ4LLxk96OgoKVnEc5qUxhDQsXyTjT5WV5X2qZLExygmUt22sUAw4OKoO2jiS4D2la2px grH1Pgni1ohnrQ4LUZ2dD5xkFFAPyLCE6z8hcYrf/8rRCMRVso05dNI5CmSsFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740072405; 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=VHuPs4rBXf8pe95n0bUKg6rOpw+tVARwCYhm5u9Lwqo=; b=O4xHftKcDG+rABVeIdPddOEVbnBLLuAdXZu+F9PfGORUgbw1WJYnc4BYF5X/gj9RKWX1QP I2LlfXQjSUQm3Vx4b3G24GU4FeTPcsLcu6/Wk2+yp0lXHkiRlf0wu72KJGcvaUwzE58rKz wbKJxMvK0/tqPSfbgnY18/TDQncNpVS4DnCMR3u+ujde7w7jyYmYA/+IeVdHEeW1J2T/Ji tnr9HZtEDwDIykLaAY78IJqAPqz9ez07sIWxLAbm0PeExPiFaivMXGFBu/JsIiBRQl3xJb eIyQP4SVyYeStGSu6ZIf5q1pN3YSBU6VCIDuseX28T6CUC3pR94Jg86xGk+3/w== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YzKtr3S69zybF; Thu, 20 Feb 2025 17:26:44 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mark Millard , Olivier =?ISO-8859-1?Q?Cochard=2DLabb=E9?= Cc: freebsd-arm , FreeBSD Current , Jason Bacon Subject: Re: [Retitled!] some under-VM detections for non-amd64 may be broken Date: Thu, 20 Feb 2025 18:26:34 +0100 Message-ID: <4120300.BRNeRiNLvY@ravel> In-Reply-To: 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; boundary="nextPart2367967.mfXeX5GmMH"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2367967.mfXeX5GmMH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Date: Thu, 20 Feb 2025 18:26:34 +0100 Message-ID: <4120300.BRNeRiNLvY@ravel> MIME-Version: 1.0 Hi, I've submitted a change proposal to fix this (and potentially other problems): https://reviews.freebsd.org/D49084 Please feel free to comment/review there. For olivier@: I'd be interested in seeing the full output of (minus serial numbers of course): kenv | grep -F smbios in all the cases you reported just to check that I'm not too far off. If you have some time, could you add these results to the differential revision above? Thanks and regards. -- Olivier Certner --nextPart2367967.mfXeX5GmMH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAme3ZcoACgkQjKEwQJce JicjzQ/9EOcslOHZNahbtKTnWCdMpEDY+GvkrIoo+D/ZirttcRoeGl3EPsOZ2mh2 lpXTsZ0QTpLW127DT4OP2odsrHHK+m1uhNAWOVMiSlvHJ2D6/dAhV+oLR5yUdNnk zhJDFC/DgXksB+5HT8DOOIPaUsjFuc2/P+TBp/x3wzaNxEfod7DtyJiLK4Tlk7hE XTl6GWSgfFnD4aM5GQ4LJmokOh+p7ZRItjPdyt+ote3+QgbXP8gxH5FawCEQHiXH 82NSVsB1fB+yP+uaKH9npwQGnSUHzICwlRLd7uzzTWo41d5/527kiXPkjSgbAvJs 9OwU9Xb73EZ0d56VbizzTUso1p9hDAcjpL6aiFhhiVfFFQ8nyInAoIvPMHcHOBDN BTGb+qww7XUx7BbHn+PKDeG6vw/dNz5BPq0mi6cHA8kw/kVL17ubabgdUmoZQXCL 6HwpriPf9koKp3ijXmQGHfLjrHAYd3iCYfixNVoEUZX4OJ37huts9AKUaFKnRLh6 b5oevO2A2Dbphrf5BU3oyM4otF3LyWIUrZrIwzUkPSw4Pi42Nb0P2ZGPKrSxXPy2 4ktCRwhTmNWUyOkHUGM7/dLgrQ5HWcw0WTI2Z2Jp06G7c/6wGbmkByUkq5Ev/U/Y bpuGvrfD8GcfgGgIw0tbOr2ocJVgq5pTz7jMGIk74M5m15qAPHE= =HEpa -----END PGP SIGNATURE----- --nextPart2367967.mfXeX5GmMH-- From nobody Fri Feb 21 00:28: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 4YzWFJ5Shwz5pdM1 for ; Fri, 21 Feb 2025 00:28:20 +0000 (UTC) (envelope-from sr@genyosha.net) Received: from ns0.genyosha.net (ns0.genyosha.net [50.39.243.220]) (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 "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YzWFH1DVKz3dRy for ; Fri, 21 Feb 2025 00:28:19 +0000 (UTC) (envelope-from sr@genyosha.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sr@genyosha.net designates 50.39.243.220 as permitted sender) smtp.mailfrom=sr@genyosha.net Received: from dragon.home.genyosha.net (ops0.genyosha.net [50.39.243.219]) by ns0.genyosha.net (8.18.1/8.18.1) with ESMTPS id 51L0SBLe014707 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Feb 2025 16:28:12 -0800 (PST) (envelope-from sr@genyosha.net) Received: from dragon.home.genyosha.net (localhost [127.0.0.1]) by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 51L0S6dn025554; Thu, 20 Feb 2025 16:28:06 -0800 Received: (from sr@localhost) by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 51L0S6pg025553; Thu, 20 Feb 2025 16:28:06 -0800 Date: Thu, 20 Feb 2025 16:28:06 -0800 From: Steve Rikli To: Rick Macklem Cc: FreeBSD CURRENT , Gleb Smirnoff Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: inspected by milter-greylist-4.6.4 (ns0.genyosha.net [50.39.243.220]); Thu, 20 Feb 2025 16:28:12 -0800 (PST) for IP:'50.39.243.219' DOMAIN:'ops0.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns0.genyosha.net [50.39.243.220]); Thu, 20 Feb 2025 16:28:12 -0800 (PST) X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TAGGED_RCPT(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:20055, ipnet:50.39.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[genyosha.net]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4YzWFH1DVKz3dRy X-Spamd-Bar: --- On Wed, Feb 19, 2025 at 02:40:15PM -0800, Rick Macklem wrote: > > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. > > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. > > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) > > 3) Add a new NFS mount option "retrydns=", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". > > 4) ??? > > So, what do you think is the preferred change? I don't think I would change mount_nfs code behavior for this. That is, requiring services and daemons etc. to workaround missing, misconfigured, slow, or misbehaving nameservice (whether it's DNS, /etc/hosts, NIS, whatever) seems like more complexity, possibly not effective, and maybe not focused on the right thing. Now, without meaning to be presumptuous, it may be worth re-examining the startup sequence, e.g. to make sure NFS mounts are tried after the known dependencies can reasonably be expected to have started, including the network, plus local_unbound or bind (if used), possibly others. After a quick look, I don't see an obvious problem with the sequence, but more knowledgeable eyes than mine are welcome. I don't quite follow some of the output from rcorder and service -r. > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) In that area, I'll note FreeBSD rc.d has a "NETWORKING" dependency for PROVIDE and REQUIRE, and it's included in scripts like nfsclient, mountcritremote et al. However there seems to be no similar dependency for something like "NAMESERVICE" (generic, as opposed to "named" specifically), and I'm not sure how that might be implemented, even assuming it could be useful in a situation like this. I.e. there are many things to potentially check for "can the system resolve hostnames yet", and not all of them involve running a local instance of named, unbound, etc. In general, if I were running into problems with nameservice not being available by the time NFS mounts happen, I think I'd start by looking into possible nameservice issues, then check out some mechanisms other folks have mentioned (fstab IP addresses or late option, rc.conf netwait_enable, etc.) rather than coding workarounds into NFS itself. From nobody Fri Feb 21 02:39:03 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 4YzZ8W06HNz5nq34 for ; Fri, 21 Feb 2025 02:39:23 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 4YzZ8T6jQ9z3Qm7 for ; Fri, 21 Feb 2025 02:39:21 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5ded69e6134so2629195a12.0 for ; Thu, 20 Feb 2025 18:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740105560; x=1740710360; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kBVyqy8DD3GJybO/QYLYsmrkdGjEequYB2iXedxDng4=; b=kyhckzLzVc/b4iepJKvBVYi8qIOreT5MlbO/JSxH6CEu22fB5aEGKyEAXdMXI++x1f /K6CP/mbSWqkJxBytOAt2nzyEJdzwbQzBFCuARUJzligcPpsameTaBR4OmWGps42G7Ts MhWIrRLsuVVqREOM6BxbxI+OaggochU0VU2LU0iORbmsCxZDAxnskjMWTNtGbyu5zCGc be6NGjJgA5ioIs0rjtax9YSRR8Ea7nFQJOzDeIcle8JFR4gunCOApS1l+PfpGcFmoAvp PGcYq1U+jOYuBfj87kTE2auU0OPsYqf4zlHsMNapXahT3un/bUiAFhfSfUStY4lLdJjh TrrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740105560; x=1740710360; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kBVyqy8DD3GJybO/QYLYsmrkdGjEequYB2iXedxDng4=; b=t5rGVcAmYujfzwOV2MiL0TVD5McvmwvG6n18RnMSQq1LUX6fyo5o+tyyOmP5d2OcDA Qp7l1Kjm9M7ku95V0lobaVOge57WVjlFMbebsyoDpXboy6cdAja5pWUWwcP0Y7uWtt06 Q/mc+gk7+51kJ7YHqIcI6GHOCvD0jnzJQcCjlxi99OsiNmeCDVNa5AMQG9EUduPz9jSZ zg7Bm0PuDGlLKtlERAkm4dBo3dM/y/raNwoJH4NrIY+LtillrOmtktYSu7tDXJ07LKrm 1Rdb85y/hr+A1HyRvpvLZF9dAUd/YuU5vgK+eLnufqjBLTj2YmAM53KIgVzIbKcqiZlx F79w== X-Gm-Message-State: AOJu0YzyhsgXFa1ykFCb4TqcS3EWRA+t5QwI42Ylvk5UaI1D55OYOfXh FVCaixh/udk+2ylA0qoVkZGLdpaztE4EuOTT/feIvjDJ9Uks6MfGQVw+DQQBPbeszIpnyiYT5PI trzAgM+qrDS6DIABWvFw6u4r+ow== X-Gm-Gg: ASbGncucKQ2kF3omHV9yy9QhCi1HYfsEffou+lGe2YR8WCWoZheSoXVQUuK2lAKJJHU LUAJMjvMFLBy6WKalqXRqlnJ0LxY0FGgXpSQ90B4auSMrZrtpoDZ3MVacS6FQdxZd5JBZN2dADw IxHSnN2jsyea33MJgXK6g2MH4TahWkdfNQS1y3kbhT X-Google-Smtp-Source: AGHT+IGcnXgH968p+Wjv0vE3d6mvps+vN0iMgYNZO+fBldpu2kvPw3wHl2IMTr3ub8I/mL4l5aLSN8/q6gBkHjZESf4= X-Received: by 2002:a05:6402:2750:b0:5e0:9269:f54e with SMTP id 4fb4d7f45d1cf-5e0b70d7026mr946261a12.14.1740105559752; Thu, 20 Feb 2025 18:39:19 -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: In-Reply-To: From: Rick Macklem Date: Thu, 20 Feb 2025 18:39:03 -0800 X-Gm-Features: AWEUYZltPpX70N1mA7fFETHVkApExavu3E691zg96u5nQJt775askD-U19W5JTc Message-ID: Subject: Re: RFC: mount_nfs failure due to dns not running yet To: Steve Rikli Cc: FreeBSD CURRENT , Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4YzZ8T6jQ9z3Qm7 X-Spamd-Bar: ---- On Thu, Feb 20, 2025 at 4:28=E2=80=AFPM Steve Rikli wrote= : > > On Wed, Feb 19, 2025 at 02:40:15PM -0800, Rick Macklem wrote: > > > > The subject line basically describes the problem glebius@ > > ran into. When doing an NFS mount in /etc/fstab, it failed > > since the DNS service was not yet working and, as such, > > the DNS lookup of the server fqdn failed, causing the mount > > to fail. Note that this behaviour has existed for decades. > > > > He feels this is a bug and that mount_nfs(8) should retry > > getaddrinfo(3) calls until success, instead of failing the > > mount when the first attempt fails. > > The problem with just retrying getaddrinfo(3) is that it > > could retry forever for simple failures like a typo in the > > server fqdn. > > I can see several ways this can be handled and would > > like feedback from others w.r.t. these alternatives. > > > > 1) Simply document this case and encourage use of > > host names in /etc/hosts for NFS servers along with > > specifying use of file before dns in nsswitch.conf. > > Doing this results in the mounts working whether or > > not DNS is working. > > > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > > until it succeeds. (I feel this would be a POLA violation, > > given that the current behaviour has existed for decades > > and for simple cases where the fqdn will never resolve > > the behaviour would be to hang at the mount attempt > > during boot unless "bg" is specified for the /etc/fstab entry.) > > > > 3) Add a new NFS mount option "retrydns=3D", which would enable > > retries of getaddrinfo(3). This would avoid any POLA violation and > > would allow for a convenient way to document the behaviour in > > "man mount_nfs". > > > > 4) ??? > > > > So, what do you think is the preferred change? > > I don't think I would change mount_nfs code behavior for this. > > That is, requiring services and daemons etc. to workaround missing, > misconfigured, slow, or misbehaving nameservice (whether it's DNS, > /etc/hosts, NIS, whatever) seems like more complexity, possibly not > effective, and maybe not focused on the right thing. > > Now, without meaning to be presumptuous, it may be worth re-examining > the startup sequence, e.g. to make sure NFS mounts are tried after the > known dependencies can reasonably be expected to have started, including > the network, plus local_unbound or bind (if used), possibly others. > > After a quick look, I don't see an obvious problem with the sequence, > but more knowledgeable eyes than mine are welcome. I don't quite follow > some of the output from rcorder and service -r. > > > ps: I looked and the return value from getaddrinfo(3) does not > > appear to be useful to discern the case of "DNS service not > > running yet". (I think it replies EAI_FAIL for this case.) > > In that area, I'll note FreeBSD rc.d has a "NETWORKING" dependency for > PROVIDE and REQUIRE, and it's included in scripts like nfsclient, > mountcritremote et al. However there seems to be no similar dependency > for something like "NAMESERVICE" (generic, as opposed to "named" > specifically), and I'm not sure how that might be implemented, even > assuming it could be useful in a situation like this. > > I.e. there are many things to potentially check for "can the system > resolve hostnames yet", and not all of them involve running a local > instance of named, unbound, etc. > > In general, if I were running into problems with nameservice not being > available by the time NFS mounts happen, I think I'd start by looking > into possible nameservice issues, then check out some mechanisms other > folks have mentioned (fstab IP addresses or late option, rc.conf > netwait_enable, etc.) rather than coding workarounds into NFS itself. Well, the patch I have created (it took about 15min) only changes behaviour if a new "retrydns" option i used. As such, I think it might be useful for = some, but doesn't change things unless someone uses it. I agree with you that I don't think the rc scripts have a way to check REQU= IRE dns working. (I, personally, always put the fqdn for NFS servers in /etc/ho= sts and make sure "files" is first in nsswitch.conf, but others argue that is n= ot feasible for some deployments. (Using IP numbers works for AUTH_SYS, but not Kerberized mounts.) Note that there is already "retrycnt", which specifies retry the mount, but that retry loop doesn't include getaddrinfo(3) calls. --> Personally, I do not like always doing retries since I often type mount commands manually and I'm a terrible typist, so I often mistype the server's name. This reply was mostly a followup on all the good comments and not just yours. Thanks everyone, for your comments, rick From nobody Fri Feb 21 06:52: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 4YzgnQ0q65z5pFDC; Fri, 21 Feb 2025 06:53:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4YzgnN2pMxz3Gyx; Fri, 21 Feb 2025 06:53:12 +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=dW2FrVKz; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:30 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8: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 8F138240EA8; Fri, 21 Feb 2025 07:53:09 +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 0857F240443; Fri, 21 Feb 2025 07:53:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1740120788; 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=DhSMFwAwlR4r4hWjGUL8SnKf4Xj4P2t56pWoBFPn8s8=; b=dW2FrVKzLdC0Nzi7v2VBqJmVmbpPWdEBvdl23ne1vUImwtYvfCy9hz+UFTivViUxA0c83L uQVDEIQtzTldveV8jlmvZ9dzxgZ4xFLkcul7N4g0Bw/TK5arfl6vWclYqCnWs+RGeuWzQA +xD/NebkBllgHuK2EFMiV2xuI76WTxZS7pWWI473g+hTr4vWLgq96FedLrMlBl8HnPHzRQ 55FqrAQfMWtmEUKNAbMTlxr98+TYOct6OYeOEaqwua8+PKO/I6C44DF5rVxZss5KTtjc0W gkuJOJMkwGLqXPMWCM3DfmHuPN6RBxbuM8waXoKEhLvCQhA+nl/FWKgLZyT+iw== Received: from thor.sb211.local (dynamic-2a02-3100-2307-1202-b93b-33ab-6241-2cf4.310.pool.telefonica.de [IPv6:2a02:3100:2307:1202:b93b:33ab:6241:2cf4]) (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 B23B02405D9; Fri, 21 Feb 2025 07:53:07 +0100 (CET) Date: Fri, 21 Feb 2025 07:52:33 +0100 From: A FreeBSD User To: FreeBSD CURRENT , freebsd-net@freebsd.org Subject: rtadvd(8) How to IPv6 tokenize interface identifier Message-ID: <20250221075300.4466057d@thor.sb211.local> 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_/615oeyxN0dZVm=zV_2hbSF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 4ef876 X-Rspamd-UID: 1e51ba X-Spamd-Result: default: False [-5.69 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4YzgnN2pMxz3Gyx X-Spamd-Bar: ----- --Sig_/615oeyxN0dZVm=zV_2hbSF8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, Linux (especially OpenWRT we use) knows about a concept named "IPv6 tokeniz= ed interface identifier". The concept is self explanatory, a interface/router obtains a = propagated prefix and the concept allows the explicit definition of the host portion. I haven't managed to accomplish such a behaviour using FreeBSD's rtadvd(8) = daemon. I guess this task is subject of and performed through the rtadvd.conf(5) configurat= ion file, but I haven't managed yet to accomplish such a task (to speak simple: I'd like to= have a router of a subnet always at IPv6 Network PREFIX:0:0:0:1). The only config tag I can imagine is responsible for what I'd like to achiv= e is the "addr" tag mentioned in rtadvd.conf(5), but whatever I fill this tag with - the desire= d effect is never achived (i.e addr=3D"::0.0.0.1"). My "FreeBSD homebrewn" router has several= networks, attached to vlan. Each interface is subject of an ULA prefix and an IPv6 prefix prov= ided by our ISP. It is possible to pin the ULA toward the desired address, like addr=3D"fd50:c4= 50::1", but then the ISP provided prefix seems not to be set properly or is completely absent. O= mitting "addr=3D" provides the interface with ULA prefix and ISP prefix - but obviously with = the randomly generated 64bit host portion. Playing around with mutually suitable tags, like "pinfoflags", "raflags" or= "rtflags" and having probed almost every possible combination (with or without some sense= ), it seems impossible to provide a) both ULA and ISP prefix pin the host portion to a = desired 64bit address, like "PREFIX::1". I do not exclude that I'm possibly incapable of comprehension the manpage (= the language is and the deeper semantics seem then to be hidden for me). So, if there is a clea= r expalanation how to achive the desired, please point me towards it (thanks in advance!). Linux has this feature since a while and I can not believe that FreeBSD lac= ks such a feature. Thank you very much in advance, O. Hartmann --=20 A FreeBSD user --Sig_/615oeyxN0dZVm=zV_2hbSF8 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCZ7gizAAKCRCxzvs8Oqok r0m7AP0ZSdHzoVRagBPVuDWWxcGp7pr4qrWK4y/6urBN0V3V3wEAoJafULkNvzXP GfVCWOFbZze/RJuF76wGmqlZc/V0/gs= =dfnX -----END PGP SIGNATURE----- --Sig_/615oeyxN0dZVm=zV_2hbSF8-- From nobody Fri Feb 21 08:12: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 4YzjYl3xF0z5pMfb for ; Fri, 21 Feb 2025 08:13:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10011201.me.com (pv50p00im-ztdg10011201.me.com [17.58.6.39]) (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 4YzjYk3KT5z3S5j for ; Fri, 21 Feb 2025 08:13:14 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=T4sRLCIX; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.39 as permitted sender) smtp.mailfrom=tsoome@me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; bh=O9IqJNImP4w5Y6Ho5fdt+yEaafktBT5dCRaG9u5oqoE=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To:x-icloud-hme; b=T4sRLCIXY9LZn3I+FwojywnfP13ZG+LxCbhodDg08tNfGd1+Fzn6Heq1nm1PHdsoh cB8DNFc6Q2h1pSdmgS4XpY/qFxuXKnmf1cWUxgRBhQs0A1aGx3rDa4HFcsf8wCKnZi qZ8u75z+OCkYwUHTq2GjTvzrd9bGLsP6ezMeJF6YkALLtu30LCO4PLN6q3r0fBh1lw wEklO6NVTHwGA3wXkv2j3TdkcpOnp+iwP0qcs7AAbKFBT8f2zjG0TEjgn1FsFFUSKY FFEZLB+OX3JsVPJ10DB7ZhwsLRovK8t+jRqMgprclpo2VvbRLaon6KFTKLfNWDwRAC WLcfWeb1sTL9w== Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-ztdg10011201.me.com (Postfix) with ESMTPSA id 7761368028A; Fri, 21 Feb 2025 08:13:07 +0000 (UTC) From: Toomas Soome Message-Id: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0B07C6C2-EAA2-4586-90B7-D97B8E4A468B" 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.400.131.1.6\)) Subject: Re: RFC: mount_nfs failure due to dns not running yet Date: Fri, 21 Feb 2025 10:12:54 +0200 In-Reply-To: Cc: Steve Rikli , Gleb Smirnoff , Rick Macklem To: FreeBSD CURRENT References: X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Proofpoint-GUID: S8QUrAu9uBAkLAHHyNilGyDOlyCqblOl X-Proofpoint-ORIG-GUID: S8QUrAu9uBAkLAHHyNilGyDOlyCqblOl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-02-21_01,2025-02-20_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 phishscore=0 suspectscore=0 mlxscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2502210061 X-Spamd-Result: default: False [-2.90 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[17.58.6.39:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.39:from]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[genyosha.net,glebi.us,gmail.com]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; DKIM_TRACE(0.00)[me.com:+]; FREEFALL_USER(0.00)[tsoome]; FREEMAIL_ENVFROM(0.00)[me.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.39:from]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; DWL_DNSWL_NONE(0.00)[me.com:dkim] X-Rspamd-Queue-Id: 4YzjYk3KT5z3S5j X-Spamd-Bar: -- --Apple-Mail=_0B07C6C2-EAA2-4586-90B7-D97B8E4A468B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21. Feb 2025, at 04:39, Rick Macklem = wrote: >=20 > On Thu, Feb 20, 2025 at 4:28=E2=80=AFPM Steve Rikli = wrote: >>=20 >> On Wed, Feb 19, 2025 at 02:40:15PM -0800, Rick Macklem wrote: >>>=20 >>> The subject line basically describes the problem glebius@ >>> ran into. When doing an NFS mount in /etc/fstab, it failed >>> since the DNS service was not yet working and, as such, >>> the DNS lookup of the server fqdn failed, causing the mount >>> to fail. Note that this behaviour has existed for decades. >>>=20 >>> He feels this is a bug and that mount_nfs(8) should retry >>> getaddrinfo(3) calls until success, instead of failing the >>> mount when the first attempt fails. >>> The problem with just retrying getaddrinfo(3) is that it >>> could retry forever for simple failures like a typo in the >>> server fqdn. >>> I can see several ways this can be handled and would >>> like feedback from others w.r.t. these alternatives. >>>=20 >>> 1) Simply document this case and encourage use of >>> host names in /etc/hosts for NFS servers along with >>> specifying use of file before dns in nsswitch.conf. >>> Doing this results in the mounts working whether or >>> not DNS is working. >>>=20 >>> 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) >>> until it succeeds. (I feel this would be a POLA violation, >>> given that the current behaviour has existed for decades >>> and for simple cases where the fqdn will never resolve >>> the behaviour would be to hang at the mount attempt >>> during boot unless "bg" is specified for the /etc/fstab entry.) >>>=20 >>> 3) Add a new NFS mount option "retrydns=3D", which would enable >>> retries of getaddrinfo(3). This would avoid any POLA violation = and >>> would allow for a convenient way to document the behaviour in >>> "man mount_nfs". >>>=20 >>> 4) ??? >>>=20 >>> So, what do you think is the preferred change? >>=20 >> I don't think I would change mount_nfs code behavior for this. >>=20 >> That is, requiring services and daemons etc. to workaround missing, >> misconfigured, slow, or misbehaving nameservice (whether it's DNS, >> /etc/hosts, NIS, whatever) seems like more complexity, possibly not >> effective, and maybe not focused on the right thing. >>=20 >> Now, without meaning to be presumptuous, it may be worth re-examining >> the startup sequence, e.g. to make sure NFS mounts are tried after = the >> known dependencies can reasonably be expected to have started, = including >> the network, plus local_unbound or bind (if used), possibly others. >>=20 >> After a quick look, I don't see an obvious problem with the sequence, >> but more knowledgeable eyes than mine are welcome. I don't quite = follow >> some of the output from rcorder and service -r. >>=20 >>> ps: I looked and the return value from getaddrinfo(3) does not >>> appear to be useful to discern the case of "DNS service not >>> running yet". (I think it replies EAI_FAIL for this case.) >>=20 >> In that area, I'll note FreeBSD rc.d has a "NETWORKING" dependency = for >> PROVIDE and REQUIRE, and it's included in scripts like nfsclient, >> mountcritremote et al. However there seems to be no similar = dependency >> for something like "NAMESERVICE" (generic, as opposed to "named" >> specifically), and I'm not sure how that might be implemented, even >> assuming it could be useful in a situation like this. >>=20 >> I.e. there are many things to potentially check for "can the system >> resolve hostnames yet", and not all of them involve running a local >> instance of named, unbound, etc. >>=20 >> In general, if I were running into problems with nameservice not = being >> available by the time NFS mounts happen, I think I'd start by looking >> into possible nameservice issues, then check out some mechanisms = other >> folks have mentioned (fstab IP addresses or late option, rc.conf >> netwait_enable, etc.) rather than coding workarounds into NFS itself. > Well, the patch I have created (it took about 15min) only changes = behaviour > if a new "retrydns" option i used. As such, I think it might be useful = for some, > but doesn't change things unless someone uses it. >=20 > I agree with you that I don't think the rc scripts have a way to check = REQUIRE > dns working. (I, personally, always put the fqdn for NFS servers in = /etc/hosts > and make sure "files" is first in nsswitch.conf, but others argue that = is not > feasible for some deployments. (Using IP numbers works for AUTH_SYS, > but not Kerberized mounts.) >=20 > Note that there is already "retrycnt", which specifies retry the = mount, > but that retry loop doesn't include getaddrinfo(3) calls. > --> Personally, I do not like always doing retries since I often > type mount commands manually and I'm a terrible typist, so I > often mistype the server's name. >=20 > This reply was mostly a followup on all the good comments and > not just yours. >=20 > Thanks everyone, for your comments, rick >=20 my 2cents: there is a difference of name service not responding and name not = resolving. In first case, it will go to: bg If an initial attempt to contact the server fails, = fork off a child to keep trying the mount in the = background. Useful for fstab(5), where the file system mount is = not critical to multiuser operation. bgnow Like bg, fork off a child to keep trying the mount = in the background, but do not attempt to mount in the = foreground first. This eliminates a 60+ second timeout when = the server is not responding. Useful for speeding up = the boot process of a client when the server is likely = to be unavailable. This is often the case for = interdependent servers such as cross-mounted servers (each of two servers is an NFS client of the other) and for = cluster nodes that must boot before the file servers. in second case, its a failure you can not recover from. rgds, toomas --Apple-Mail=_0B07C6C2-EAA2-4586-90B7-D97B8E4A468B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21. Feb 2025, at 04:39, Rick Macklem = <rick.macklem@gmail.com> wrote:

On Thu, Feb 20, 2025 at = 4:28=E2=80=AFPM Steve Rikli <sr@genyosha.net> = wrote:

On Wed, Feb 19, 2025 at = 02:40:15PM -0800, Rick Macklem wrote:

The= subject line basically describes the problem glebius@
ran into. =  When doing an NFS mount in /etc/fstab, it failed
since the DNS = service was not yet working and, as such,
the DNS lookup of the = server fqdn failed, causing the mount
to fail. Note that this = behaviour has existed for decades.

He feels this is a bug and = that mount_nfs(8) should retry
getaddrinfo(3) calls until success, = instead of failing the
mount when the first attempt fails.
The = problem with just retrying getaddrinfo(3) is that it
could retry = forever for simple failures like a typo in the
server fqdn.
I can = see several ways this can be handled and would
like feedback from = others w.r.t. these alternatives.

1) Simply document this case = and encourage use of
   host names in /etc/hosts for = NFS servers along with
   specifying use of file = before dns in nsswitch.conf.
    Doing this = results in the mounts working whether or
=      not DNS is working.

2) Call it a = bug and patch mount_nfs(8) to retry getaddrinfo(3)
=     until it succeeds. (I feel this would be a POLA = violation,
    given that the current behaviour = has existed for decades
    and for simple cases = where the fqdn will never resolve
    the = behaviour would be to hang at the mount attempt
=     during boot unless "bg" is specified for the = /etc/fstab entry.)

3) Add a new NFS mount option = "retrydns=3D<N>", which would enable
   retries = of getaddrinfo(3). This would avoid any POLA violation and
=    would allow for a convenient way to document the = behaviour in
   "man mount_nfs".

4) = ???

So, what do you think is the preferred = change?

I don't think I would change mount_nfs code = behavior for this.

That is, requiring services and daemons etc. = to workaround missing,
misconfigured, slow, or misbehaving = nameservice (whether it's DNS,
/etc/hosts, NIS, whatever) seems like = more complexity, possibly not
effective, and maybe not focused on the = right thing.

Now, without meaning to be presumptuous, it may be = worth re-examining
the startup sequence, e.g. to make sure NFS mounts = are tried after the
known dependencies can reasonably be expected to = have started, including
the network, plus local_unbound or bind (if = used), possibly others.

After a quick look, I don't see an = obvious problem with the sequence,
but more knowledgeable eyes than = mine are welcome.  I don't quite follow
some of the output from = rcorder and service -r.

ps: I looked = and the return value from getaddrinfo(3) does not
=      appear to be useful to discern the case of = "DNS service not
     running yet". (I = think it replies EAI_FAIL for this case.)

In that = area, I'll note FreeBSD rc.d has a "NETWORKING" dependency = for
PROVIDE and REQUIRE, and it's included in scripts like = nfsclient,
mountcritremote et al. However there seems to be no = similar dependency
for something like "NAMESERVICE" (generic, as = opposed to "named"
specifically), and I'm not sure how that might be = implemented, even
assuming it could be useful in a situation like = this.

I.e. there are many things to potentially check for "can = the system
resolve hostnames yet", and not all of them involve = running a local
instance of named, unbound, etc.

In general, = if I were running into problems with nameservice not being
available = by the time NFS mounts happen, I think I'd start by looking
into = possible nameservice issues, then check out some mechanisms = other
folks have mentioned (fstab IP addresses or late option, = rc.conf
netwait_enable, etc.) rather than coding workarounds into NFS = itself.
Well, the patch I have created (it took about = 15min) only changes behaviour
if a new "retrydns" option i used. As = such, I think it might be useful for some,
but doesn't change things = unless someone uses it.

I agree with you that I don't think the = rc scripts have a way to check REQUIRE
dns working. (I, personally, = always put the fqdn for NFS servers in /etc/hosts
and make sure = "files" is first in nsswitch.conf, but others argue that is = not
feasible for some deployments. (Using IP numbers works for = AUTH_SYS,
but not Kerberized mounts.)

Note that there is = already "retrycnt", which specifies retry the mount,
but that retry = loop doesn't include getaddrinfo(3) calls.
--> Personally, I do = not like always doing retries since I often
=     type mount commands manually and I'm a terrible = typist, so I
    often mistype the server's = name.

This reply was mostly a followup on all the good comments = and
not just yours.

Thanks everyone, for your comments, = rick


my = 2cents:

there is a difference of name service = not responding and name not resolving. In first case, it will go = to:

            =  bg      If an initial attempt to contact the = server fails, fork

   =                   off a = child to keep trying the mount in the background.

   =                   Useful = for fstab(5), where the file system mount is not

   =                   critical = to multiuser operation.


   =           bgnow   Like bg, = fork off a child to keep trying the mount in the

   =                   = background, but do not attempt to mount in the foreground

   =                   = first.  This eliminates a 60+ second timeout when the

   =                   server is = not responding.  Useful for speeding up the

   =                   boot = process of a client when the server is likely to be

   =                   = unavailable.  This is often the case for interdependent

   =                   servers = such as cross-mounted servers (each of two

   =                   servers = is an NFS client of the other) and for cluster

   =                   nodes = that must boot before the file servers.


in second case, its a failure you = can not recover from.


rgds,

toomas





= --Apple-Mail=_0B07C6C2-EAA2-4586-90B7-D97B8E4A468B-- From nobody Fri Feb 21 10:44: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 4YzmwN6KDzz5pZkZ; Fri, 21 Feb 2025 10:44:36 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YzmwN340Cz3jmD; Fri, 21 Feb 2025 10:44:36 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 51LAiSaW048895; Fri, 21 Feb 2025 10:44:28 GMT (envelope-from rb@gid.co.uk) Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 51LAiNhd061401; Fri, 21 Feb 2025 10:44:23 GMT (envelope-from rb@gid.co.uk) Content-Type: multipart/signed; boundary="Apple-Mail=_9332C272-DF26-4103-A5EB-6DECEA582C4A"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 \(3776.700.51.11.1\)) Subject: Re: rtadvd(8) How to IPv6 tokenize interface identifier From: Bob Bishop In-Reply-To: <20250221075300.4466057d@thor.sb211.local> Date: Fri, 21 Feb 2025 10:44:12 +0000 Cc: FreeBSD CURRENT , "freebsd-net@freebsd.org" Message-Id: <2D84F83E-4548-40FA-B817-39703C670B43@gid.co.uk> References: <20250221075300.4466057d@thor.sb211.local> To: A FreeBSD User X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4YzmwN340Cz3jmD X-Spamd-Bar: ---- --Apple-Mail=_9332C272-DF26-4103-A5EB-6DECEA582C4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 21 Feb 2025, at 06:52, A FreeBSD User = wrote: >=20 > Hello, >=20 > Linux (especially OpenWRT we use) knows about a concept named "IPv6 = tokenized interface > identifier". The concept is self explanatory, a interface/router = obtains a propagated prefix > and the concept allows the explicit definition of the host portion. >=20 > I haven't managed to accomplish such a behaviour using FreeBSD's = rtadvd(8) daemon. I guess > this task is subject of and performed through the rtadvd.conf(5) = configuration file, but I > haven't managed yet to accomplish such a task (to speak simple: I'd = like to have a router of a > subnet always at IPv6 Network PREFIX:0:0:0:1). Isn=E2=80=99t sufficient just to give the router a static IPv6 address? = That=E2=80=99s what we do here. > The only config tag I can imagine is responsible for what I'd like to = achive is the "addr" tag > mentioned in rtadvd.conf(5), but whatever I fill this tag with - the = desired effect is never > achived (i.e addr=3D"::0.0.0.1"). My "FreeBSD homebrewn" router has = several networks, attached > to vlan. Each interface is subject of an ULA prefix and an IPv6 prefix = provided by our ISP. It > is possible to pin the ULA toward the desired address, like = addr=3D"fd50:c450::1", but then the > ISP provided prefix seems not to be set properly or is completely = absent. Omitting "addr=3D" > provides the interface with ULA prefix and ISP prefix - but obviously = with the randomly > generated 64bit host portion. >=20 > Playing around with mutually suitable tags, like "pinfoflags", = "raflags" or "rtflags" and > having probed almost every possible combination (with or without some = sense), it seems > impossible to provide a) both ULA and ISP prefix pin the host portion = to a desired 64bit > address, like "PREFIX::1". >=20 > I do not exclude that I'm possibly incapable of comprehension the = manpage (the language is and > the deeper semantics seem then to be hidden for me). So, if there is a = clear expalanation how > to achive the desired, please point me towards it (thanks in = advance!). >=20 > Linux has this feature since a while and I can not believe that = FreeBSD lacks such a feature. >=20 > Thank you very much in advance, >=20 > O. Hartmann >=20 >=20 > --=20 >=20 > A FreeBSD user -- Bob Bishop rb@gid.co.uk --Apple-Mail=_9332C272-DF26-4103-A5EB-6DECEA582C4A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQR+a6Wh87I/iYwcbE+8xpPppLfFvwUCZ7hY/AAKCRC8xpPppLfF v6/vAKDt8gafDpGCDIAbeQD6KdcT7ZNcFQCeI+wgOqwQfjiYEDGhR36lyVQsLik= =rg5L -----END PGP SIGNATURE----- --Apple-Mail=_9332C272-DF26-4103-A5EB-6DECEA582C4A-- From nobody Fri Feb 21 13:06:16 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 4Yzr4C6fD7z5pnFL for ; Fri, 21 Feb 2025 13:06:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4Yzr4C53mdz41Yg for ; Fri, 21 Feb 2025 13:06:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5dee07e51aaso3912318a12.3 for ; Fri, 21 Feb 2025 05:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740143194; x=1740747994; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/LTrwOy2tss8lRBDQonGnNAB9BXR7L3UUfVz/Mnpr6Q=; b=lFEthRLx17y1s/A5//XgqsBNczHbc3G+vjC0P4gh/x7kFEUfQBo4+80fWc72MWfILf zoFhDEeQp2hEthnq6S/dVOtV4Ak753Mtla9ULcKOmhXImvXW2RACYPUso1Ru8Ptzd1OP C74RU2HVaHT++Bna8oFl9W0+DG6xBAfDjD9VGAMbwne/ZT2vOWToVKVoH4DKTqjLfMOl 4yKTbucqg9mboThwXkenDegjXeF4XoiBGXPHo2b568pIRdjcLMNdSC0aYKeRkLlH6KGj oTCMvKZCCP9P7UPxJXdQFdKcfj4FavpjacuDw/e8NL0UXXiQAbrPbIyLmlw1oiMX2PPK ntfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740143194; x=1740747994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/LTrwOy2tss8lRBDQonGnNAB9BXR7L3UUfVz/Mnpr6Q=; b=aA74oCaMAv5KYsHKNxn2HrO5v6NioVNynAvd+LLEmiSroBcI8X1cX7EoHtiOrrublO nWCh/orx23SgN51Zwa9G0ExMiOGhlA0mhWgTzPV2Ehmytf0GU8Mp8WhLGrGdWdPFDj21 qpyzmdQPZkBg8u3toNgpm6ZTiWJqJJHwzkXbiihWU/LmmAEsQpFOuNfdoop6MSWaf+u3 yHqzxO1pC1HVP1InoMfmU7MCOcAZv+VYkb40uAjR8bL45rFeKuueZnmIRBrUdwZSzGIF BH9GBntSAGM1FLucaqH/vDYMTp5KKaOhkAZKNhguNcNliP39ZqicHVSFXOIt+pPVRpKS 5wPg== X-Gm-Message-State: AOJu0YwPiGSjA0nu5k1zFpJPm4bK4O1cWLUuhhj9DR3WchX+oQ2ftAQ+ NdwerhpsTiIh7FCnp0T1W8PG63VN/0cEv3RfLTgXuk7T4BdhLKAek+NK7RxShOBSIIxovnBXKCA p7/RjmzkRIq3tOEnJjXm1eC1yhw== X-Gm-Gg: ASbGncv4fMPpS2cbNGpbzmpcDChBzXj3bLkN9jmvTNrOisIXRfDR9ORrmuEs0nbcPm3 P97kdSR80xknINRsdWUQS1XoqxgmM4SSYueD3ix2zfKL3wid1cTMU6wUOrV1gl+OdFT3ETrmf7J E07O4YE9SLTiDInquu6fluQDK5kO73O4lnNNYnqtnk X-Google-Smtp-Source: AGHT+IEBbpz1dnONbAB9b45PwSps7jwhdiW3dk/JKCriD45ox8Y6I5AubuWSSBQknIPe96YxQqjI6a7jWUPREIS4eFw= X-Received: by 2002:a05:6402:c46:b0:5e0:8920:c4c5 with SMTP id 4fb4d7f45d1cf-5e0b70dac7emr2710400a12.11.1740143193533; Fri, 21 Feb 2025 05:06:33 -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: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> In-Reply-To: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> From: Rick Macklem Date: Fri, 21 Feb 2025 05:06:16 -0800 X-Gm-Features: AWEUYZmfMG1h8QYJGIIqPSnRlErosXuwF9R5AtF-mzHPC5H_9FnxUpCYQs-mFVI Message-ID: Subject: Re: RFC: mount_nfs failure due to dns not running yet To: Toomas Soome Cc: FreeBSD CURRENT , Steve Rikli , Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Yzr4C53mdz41Yg X-Spamd-Bar: ---- On Fri, Feb 21, 2025 at 12:13=E2=80=AFAM Toomas Soome wrote= : > > > > On 21. Feb 2025, at 04:39, Rick Macklem wrote: > > On Thu, Feb 20, 2025 at 4:28=E2=80=AFPM Steve Rikli wro= te: > > > On Wed, Feb 19, 2025 at 02:40:15PM -0800, Rick Macklem wrote: > > > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. > > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. > > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. > > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) > > 3) Add a new NFS mount option "retrydns=3D", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". > > 4) ??? > > So, what do you think is the preferred change? > > > I don't think I would change mount_nfs code behavior for this. > > That is, requiring services and daemons etc. to workaround missing, > misconfigured, slow, or misbehaving nameservice (whether it's DNS, > /etc/hosts, NIS, whatever) seems like more complexity, possibly not > effective, and maybe not focused on the right thing. > > Now, without meaning to be presumptuous, it may be worth re-examining > the startup sequence, e.g. to make sure NFS mounts are tried after the > known dependencies can reasonably be expected to have started, including > the network, plus local_unbound or bind (if used), possibly others. > > After a quick look, I don't see an obvious problem with the sequence, > but more knowledgeable eyes than mine are welcome. I don't quite follow > some of the output from rcorder and service -r. > > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) > > > In that area, I'll note FreeBSD rc.d has a "NETWORKING" dependency for > PROVIDE and REQUIRE, and it's included in scripts like nfsclient, > mountcritremote et al. However there seems to be no similar dependency > for something like "NAMESERVICE" (generic, as opposed to "named" > specifically), and I'm not sure how that might be implemented, even > assuming it could be useful in a situation like this. > > I.e. there are many things to potentially check for "can the system > resolve hostnames yet", and not all of them involve running a local > instance of named, unbound, etc. > > In general, if I were running into problems with nameservice not being > available by the time NFS mounts happen, I think I'd start by looking > into possible nameservice issues, then check out some mechanisms other > folks have mentioned (fstab IP addresses or late option, rc.conf > netwait_enable, etc.) rather than coding workarounds into NFS itself. > > Well, the patch I have created (it took about 15min) only changes behavio= ur > if a new "retrydns" option i used. As such, I think it might be useful fo= r some, > but doesn't change things unless someone uses it. > > I agree with you that I don't think the rc scripts have a way to check RE= QUIRE > dns working. (I, personally, always put the fqdn for NFS servers in /etc/= hosts > and make sure "files" is first in nsswitch.conf, but others argue that is= not > feasible for some deployments. (Using IP numbers works for AUTH_SYS, > but not Kerberized mounts.) > > Note that there is already "retrycnt", which specifies retry the mount, > but that retry loop doesn't include getaddrinfo(3) calls. > --> Personally, I do not like always doing retries since I often > type mount commands manually and I'm a terrible typist, so I > often mistype the server's name. > > This reply was mostly a followup on all the good comments and > not just yours. > > Thanks everyone, for your comments, rick > > > my 2cents: > > there is a difference of name service not responding and name not resolvi= ng. Agreed. Unfortunatey, the return values for getaddrinfo(3) do not clearly differentiate between them. I think Gleb's case returns EAI_FAIL, which is = also returned for other failures. I think EAI_NONAME is returned for the case wh= ere the resolver (dns, /etc/hosts or ???) does determine that the name is bogus= . I suppose the code could do retries for all return values other than EAI_NO= NAME, but to me that would still be a POLA violation, since the current behaviour has been in place for decades (as others have noted). Also, some of the feedback here has been "It is not broken, don't fix it", if I interpreted it correctly. A new option avoids changing the default behaviour. > In first case, it will go to: > > bg If an initial attempt to contact the server fails, f= ork > > off a child to keep trying the mount in the backgrou= nd. > > Useful for fstab(5), where the file system mount is = not > > critical to multiuser operation. > > > bgnow Like bg, fork off a child to keep trying the mount i= n the > > background, but do not attempt to mount in the foreg= round > > first. This eliminates a 60+ second timeout when th= e > > server is not responding. Useful for speeding up th= e > > boot process of a client when the server is likely t= o be > > unavailable. This is often the case for interdepend= ent > > servers such as cross-mounted servers (each of two > > servers is an NFS client of the other) and for clust= er > > nodes that must boot before the file servers. > > > in second case, its a failure you can not recover from. The only difference between "bg" and "bgnow" is whether or not the mount gows into background right away or after the first failed attempt. A name resolver failure still terminates the mount attempt, for both of these. "bg" does fix it for Gleb, but I think that is just timing. (Retries are of the actual NFS mount, assuming the NFS server is also booting and has not yet come up. Cross mounts between multiple systems is messy. Gleb also notes a different behaviour when "late" is used. I have not yet investigated this one rick > > > rgds, > > toomas > > > > > From nobody Fri Feb 21 16:07:19 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 4Yzw4v2968z5nrY8; Fri, 21 Feb 2025 16:07:27 +0000 (UTC) (envelope-from barney@databus.com) Received: from pit.databus.com (tunnel234559-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:80b::2]) (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 4Yzw4t5Sp3z3kPK; Fri, 21 Feb 2025 16:07:26 +0000 (UTC) (envelope-from barney@databus.com) Authentication-Results: mx1.freebsd.org; none Received: by pit.databus.com (Postfix, from userid 202) id DE55E200F39; Fri, 21 Feb 2025 11:07:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20140217; t=1740154039; bh=5nGPI32pMbE5vpRVQ0rJwg08zpAe5J53zNSCFJgHwrE=; l=2349; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=eDOPCFjBi/k/1FwSYlXc0bYJqBm5HsMpkkLDpeYjtMMHf1GWHFbGTKNOsqNs0BVX1 I7AWAqPQZD4np6mazmQfuLlojX3veve9oeNTwxbxPZYAoOEucwhzvSiPjhsqg/H9Sq vGkIKtMuf+D6GpnUL3RdbKLcuQXM9A/ApU7qLLF+73n/2y5VlsbnvsevRaOAn1XKKq wAdr8i6OAoK83nF47+tYRUhRQQo9VUMnYAU+m/KgdNPUchtzeFQt/lTw+XZ43bifWL UzgX6vJ6irEUEDXB5OAQH66DJBZJicabz3GQ7K0+7NpIe5oRZ4fS32EZe/QSU8kzM/ lYTvBh8pekhuQ== Date: Fri, 21 Feb 2025 11:07:19 -0500 From: Barney Wolff To: A FreeBSD User Cc: FreeBSD CURRENT , freebsd-net@freebsd.org Subject: Re: rtadvd(8) How to IPv6 tokenize interface identifier Message-ID: References: <20250221075300.4466057d@thor.sb211.local> 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: <20250221075300.4466057d@thor.sb211.local> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Yzw4t5Sp3z3kPK X-Spamd-Bar: ---- The problem is one of sequencing. A brute-force solution is not to start rtadvd until you get the prefix from upstream, then dynamically generate rtadvd.conf and start rtadvd. Ugly, but functional. On Fri, Feb 21, 2025 at 07:52:33AM +0100, A FreeBSD User wrote: > Hello, > > Linux (especially OpenWRT we use) knows about a concept named "IPv6 tokenized interface > identifier". The concept is self explanatory, a interface/router obtains a propagated prefix > and the concept allows the explicit definition of the host portion. > > I haven't managed to accomplish such a behaviour using FreeBSD's rtadvd(8) daemon. I guess > this task is subject of and performed through the rtadvd.conf(5) configuration file, but I > haven't managed yet to accomplish such a task (to speak simple: I'd like to have a router of a > subnet always at IPv6 Network PREFIX:0:0:0:1). > The only config tag I can imagine is responsible for what I'd like to achive is the "addr" tag > mentioned in rtadvd.conf(5), but whatever I fill this tag with - the desired effect is never > achived (i.e addr="::0.0.0.1"). My "FreeBSD homebrewn" router has several networks, attached > to vlan. Each interface is subject of an ULA prefix and an IPv6 prefix provided by our ISP. It > is possible to pin the ULA toward the desired address, like addr="fd50:c450::1", but then the > ISP provided prefix seems not to be set properly or is completely absent. Omitting "addr=" > provides the interface with ULA prefix and ISP prefix - but obviously with the randomly > generated 64bit host portion. > > Playing around with mutually suitable tags, like "pinfoflags", "raflags" or "rtflags" and > having probed almost every possible combination (with or without some sense), it seems > impossible to provide a) both ULA and ISP prefix pin the host portion to a desired 64bit > address, like "PREFIX::1". > > I do not exclude that I'm possibly incapable of comprehension the manpage (the language is and > the deeper semantics seem then to be hidden for me). So, if there is a clear expalanation how > to achive the desired, please point me towards it (thanks in advance!). > > Linux has this feature since a while and I can not believe that FreeBSD lacks such a feature. > > Thank you very much in advance, > > O. Hartmann > > > -- > > A FreeBSD user From nobody Fri Feb 21 18:39: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 4YzzSl1qhgz5p6kr for ; Fri, 21 Feb 2025 18:39:51 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 4YzzSk19KGz434G for ; Fri, 21 Feb 2025 18:39:50 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jURiRkjW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4398c8c8b2cso24973125e9.2 for ; Fri, 21 Feb 2025 10:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740163188; x=1740767988; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=NjFC7EIi1xTdZTpRfNaj/1e7ncYNoefYgSshbdHpbUE=; b=jURiRkjWMszC3KNrYurgyKh6KNVJ1DtQzoqTm1Fiuntwj+hCfIm+dIB//wM61ENoK7 3TbGvh5DXYyY1CwUsdB8RCnj2dPAbzePLpTXNenojyPOG5KopeX1BIZ7HeDZYz3BCWiQ EVZzUG9a8WVcJFIgUounC7EUeWUmJagKWX4PLIvIdotznaX9HuWGki6yxLJw6VE9S2ck sQzB2p6kIBopQaOg726q+THv1GsDMG2IKd4hkPdUCK8TyDWWC2616GOgErI8f2kWmbOV xRTVGK4j3H/LbpUwoSrdF4NVc3Y5d6mnWvx9C8C1WG7KZD7pfDpEFQjtorMVYuF0j2cp d5Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740163188; x=1740767988; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NjFC7EIi1xTdZTpRfNaj/1e7ncYNoefYgSshbdHpbUE=; b=FR0q6g0Lr8VppyroqxWktF/jS358lXo6ypxqTg3aDn3xdqHmuyfp1E7D4m0ugpQbEb K5aluta2PG79W/luTDXnW2ZmYvqWYltHq7puIBFMfICkunlkAP2jAdxUhpa29+1wUaoy Cv3FMtd/7MOE3xhrwsovH9le79/W812vRLazcyTQDLh93FPb0pg5psfTc3kyT2+0gu4H bp6LZEFWN7/P/MNxoxaiNlS5aAD6VkWt3el1bGgXngFqfRZxhxAC36y1rQ5RELy4gBwR UVhVzXvTF7I3p28Gf2S+J8B1YiknIUx3euQ8IMD8aPgXMGrWumffdH6FeGbVjSojbWNA E83Q== X-Gm-Message-State: AOJu0Yzs5Rw5uUP0qiE9PcJj0EUX5ZYiDMjoJwHzvDC0xeexz69ji3kR UerUh3kCxIZRYmuv1dpZCsQ6bhOWazIQqy9RJr4cYFW2CuCXB3CK9rSMH7eGi1c= X-Gm-Gg: ASbGnctLV27Yq1iWV8WiP2zae04rBUlNDs/rx4IpJtEpGwnJRYVoDJWZIQRreUQXFUM Pj5e/Yw0FT8S0wx/bnMvPS4i0DhJDYyeBeIIq/oMJLpMKRt568zaaPAZy2j8JYwrWHfJJRkL1LO D+GuruUKUa6rzrcoN28fhqIKMWNnNdgrsoIEtbufDTl2DOomakQtQMr2YOclEQwmsQnC1ri/j1S c0IoL5/VJ9cAa/jdQtzYoyOyPeXv7sbcYZ3jOf5gSykLlsmSqMp5oIFFBYpX+IMRUgcZ7k70uM3 Tforlpw8U0oAlVOXZPtL5khxAhNrmJQ9xovbGI44OyepciNGMu/+a9gwjaUxjbIXrwiMMn0N+54 = X-Google-Smtp-Source: AGHT+IGBkfrXVek1HpoS7JOi+QJb5t7uAVTy17Z9UrMjhrOTxpB37ef5NxRlVVp44sbSSxcRD6Okbw== X-Received: by 2002:a05:6000:1fa1:b0:38f:4cdc:5d21 with SMTP id ffacd0b85a97d-38f6e97a9dcmr4355305f8f.24.1740163187680; Fri, 21 Feb 2025 10:39:47 -0800 (PST) Received: from ?IPV6:2a01:cb15:8545:7700:62cf:84ff:fe81:caec? ([2a01:cb15:8545:7700:62cf:84ff:fe81:caec]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-439b02ce37fsm25691335e9.8.2025.02.21.10.39.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Feb 2025 10:39:47 -0800 (PST) Message-ID: Date: Fri, 21 Feb 2025 19:39:46 +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 Subject: Re: Empty structures have sizeof(1) in C++ now ? To: freebsd-current@freebsd.org References: <202502200940.51K9eswS003142@critter.freebsd.dk> <9A5B431C-2405-412A-90FF-DA016E80DF68@FreeBSD.org> Content-Language: en-US From: Paul Floyd In-Reply-To: <9A5B431C-2405-412A-90FF-DA016E80DF68@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.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]; 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]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; 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)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from] X-Rspamd-Queue-Id: 4YzzSk19KGz434G X-Spamd-Bar: -- On 2/20/25 12:03, David Chisnall wrote: > No, that’s always been the case in C++. It comes from the rule that two allocations must have unique addresses. If a structure could have size zero, an array of these structures would have size zero and the two elements in the array would have the same address. Similarly, two struct fields could have the same address, which breaks other bits of the language (pointers to members would compare equal when they should not). > > C++20 introduced the no_unique_address attribute. This allows you to embed a struct in another and, if the child struct has no fields, then its address is not required to be unique and you are explicitly saying that you won’t do any of the things where this would be a problem. > > This lets you do things like: > > ```c++ > template > struct SomeStructThatMayContainAnother > { > // Normal fields go here > > [[no_unique_address]] > std::conditional_t, struct {}, Embedded> embeddedStruct; > > // More fields maybe here > }; > ``` > > In this case, `embeddedStruct` will not add any space to the parent struct if the template parameter is `void`. There's also "EBO" (empty base optimization). https://en.cppreference.com/w/cpp/language/ebo Empty base classes aren't subject to the requirement that objexts should have an unique address. A+ Paul From nobody Fri Feb 21 19:53:34 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 4Z01746jjVz5pF0M for ; Fri, 21 Feb 2025 19:54:40 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z01731xqVz4FL5 for ; Fri, 21 Feb 2025 19:54:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=0gNL3J73; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 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=1740167669; 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=YbfCZI4MNM1ofIi+wa9dI6RJGwp4WI01kLaDJO0gVAE=; b=0gNL3J739TrnM8zldxJ7TC1nf8imbqliXR8mpKYQalYGRR0O4ix1437N5/JGlYhsvvt5jr fpBqQXqWrUjODGFj33jg6e8o2qEDgJ7buGEkZfgnn8hOY/KuZp7qr+QFbLnYar2ew17U2z jlzqSW+0pngl5Z05Wflcl2SPiDtMdTSUh/+YaPfMkIA1j0F4/1dmMGTWKagbHYtIOZ8Lld 0Vb1zDn5ET7ttOjUjsTFjv1ejMzfdETGe5Yt1ryaPgzFUJP4KmOMIwG8CMe0mRgogq372v YNzcNmGtuSVr2RziUjFwMCSgzztyud9hOWGL0XUeJu+Grc3FR7Xu+X15VAyB3Q== Date: Fri, 21 Feb 2025 20:53:34 +0100 From: Alexander Leidinger To: Current FreeBSD Subject: Re: crash with head as of 2h ago (in_pcblbgroup_insert) In-Reply-To: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> References: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> Message-ID: <115ab516d6fea7393247b0554e8879a9@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_18be35aa36967539581410a1085b108a"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.08 / 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.985]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Z01731xqVz4FL5 X-Spamd-Bar: ------ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_18be35aa36967539581410a1085b108a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-02-20 10:27, schrieb Alexander Leidinger: > Hi, > > I get this backtrace: > ---snip--- > [102] panic: invalid local group size 16 and count 16 > [102] cpuid = 17 > [102] time = 1740041984 > [102] KDB: stack backtrace: > [102] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe07453a5b80 > [102] vpanic() at vpanic+0x136/frame 0xfffffe07453a5cb0 > [102] panic() at panic+0x43/frame 0xfffffe07453a5d10 > [102] in_pcblbgroup_insert() at in_pcblbgroup_insert+0xaa/frame > 0xfffffe07453a5d30 > [102] in_pcblisten() at in_pcblisten+0x92/frame 0xfffffe07453a5d50 > [102] tcp_usr_listen() at tcp_usr_listen+0x18a/frame 0xfffffe07453a5db0 > [102] solisten() at solisten+0x47/frame 0xfffffe07453a5dd0 > [102] kern_listen() at kern_listen+0x3f/frame 0xfffffe07453a5e00 > [102] amd64_syscall() at amd64_syscall+0x15b/frame 0xfffffe07453a5f30 > [102] fast_syscall_common() at fast_syscall_common+0xf8/frame > 0xfffffe07453a5f30 > ---snip--- > > This is with head updated at 2025-02-20-080119 CET. The previous world > is from 1 month ago (2025-01-22-120655). A world of today with a cleaned /usr/obj works. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_18be35aa36967539581410a1085b108a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAme42c0ACgkQEg2wmwP4 2Ib6yxAAoXWb2C3k9DBB2BBMaXZKF6GZ9wuCNtbJOYBub+uVxfGMuYB2hf7CTB2q 4vvdhzFsiHFqqZQ8lihjp/ivoWsI32/KnGt43T9l6eO07XItANWZBWg++MeYIwNc 0FiS0PctsDdDfjhn55GlZMy/iAv5npNjfRkiSwVvIIxPXqubFf2W9UCu04WBPq79 T922cI1yzVif637cJd5byeKntxM+2lO2cB4gYzUvvggT4AosrZupQiqWifIMfYR1 hn4XebpEEtVhilQle86uVbh6nRmwg+1D3pvgZezylXkPylUTHOmXXRElZuCFSiAU NVSZVbjYZEjfQX6HrLQehQCy7CQpnl//sEF7PcYEM4WC21ED/Na8J2As7tIRJwEw BM7pxv99PxIo9DsoBeefoT4tGfC4KsOaNG5ZqpRhJDSVTI6Vs27ESZB7HJ/T9pmM ZiOc7FWzusecKcr3oBQRGnB5lxCbfA7jJe5bViYDTGvK6cTQOIMKClmQ318VVYOy mEgLwpqD9lUKHXjBLXcO6lst1uBvlkDaKEQU6/K9YMmWRtgkCBu6SWDkFegfl9PV aRVTd+qaz146MkUIQyFa2m0Z1nvEmnKojf2CfL5IJvDjPTQMwVlmAMUGFxAfwcTF qdpxCqweoFYUV+ffK6hAucgM8yqLE5x5ykuNI90KLjEMwl0UsE4= =b+92 -----END PGP SIGNATURE----- --=_18be35aa36967539581410a1085b108a-- From nobody Fri Feb 21 20:40: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 4Z027g6ps8z5pJdT for ; Fri, 21 Feb 2025 20:40:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z027g6BNlz4MBC; Fri, 21 Feb 2025 20:40:15 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740170415; 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=I7sVU80gpKO9cQPuNMb3gMqQEtIKQGux+OKowgqmN8o=; b=FmDm2KX2J0OmpjEaPJULpeVvrGWtE7KJSZdEzkaYMOL7brLXl9CLfbHz/CqwKZNI+qljO+ H5hiJjXkp/Z726Sr21Ta9pYAEDZssqtphm5zulv6v7+m+tXvIc8wTwtc+cAxfNw7+L5JHD 0dejID1wWAmYtczd3fHV6XK9qMM7AHPPBhoELMd3yuuJNMR4Modu/C9BLZsiyDzBCW0OTx p1yeEkI7oUfttyy67+KRXXkgn65CeyyYXESrNIbW+GZNaPZ7kW2F31NN+37lHe1jRbcVf5 4KGym+VniAYNcb0KpzfRGA55cdLm7jzum1avDDdwQdvs5HJtB7qUDcpDsZACfQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740170415; a=rsa-sha256; cv=none; b=daHkmJSX+gIET4GSow3izoxXrpAe9oPW/U5qXHqCYsvTJcMmAQmG4FzMM8P46WUrVDniNq 1yJa5dp48dM3l1xYDbfEeU9k9mXnIfCu8zvjeLC2M3ugeXpCLkucIYguxbZGGSbz6bVdq/ gEI8MPtLchKgUdJoE9x2FNbYNYC+ezuTn1eapMVIYGeUfFC24eD0EtUDAQHQJN+XtllJ+4 LakctAZBqASAInDN/TvrbqjL1OcntLkJpeHjex4I5bd9n83uQKMkAA2XXYTEjfaJpEoUft KPfznwqfohUFyk2pJG6SQg0pjTpEWF1/4Ifb8l0Re9+Y4h09X/D5u0IELzRKiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740170415; 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=I7sVU80gpKO9cQPuNMb3gMqQEtIKQGux+OKowgqmN8o=; b=H6NuZ4Ib8LjYjL+9P02GGit8X79RhvAvKp0ES040w3hTy2EGquDLuAW3Y+Av/x+0nUvBZI COwQg8Vik6uHWT9wMXB48D1xCdfpGrhphxUZz4z1VGi48iqUHz+KrlTSGDqFkPLqM4U1TF D08VI3gRYygemt0lPCD0vjiSsHIzTuzKsD8+3HDaHECgJECIxmdibKEyYiLxuLbUgiPuwX OMhqAQbHDYmJJMdH0E/Ew0sUrA09VhGX+pvBAuY2ZihwVI7aeLOf4sTNkmVp/7IHnuwSV/ yCyJ3lVoF9c8hmKaXSVUrbnAT1xTMHAO+gtgbDP8DU1zHY1BJ+ArWZ/aG+BtaQ== 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 4Z027g22VZzLFQ; Fri, 21 Feb 2025 20:40:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 21 Feb 2025 12:40:13 -0800 From: Gleb Smirnoff To: Steve Rikli Cc: Rick Macklem , FreeBSD CURRENT Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Feb 20, 2025 at 04:28:06PM -0800, Steve Rikli wrote: S> In that area, I'll note FreeBSD rc.d has a "NETWORKING" dependency for S> PROVIDE and REQUIRE, and it's included in scripts like nfsclient, S> mountcritremote et al. However there seems to be no similar dependency S> for something like "NAMESERVICE" (generic, as opposed to "named" S> specifically), and I'm not sure how that might be implemented, even S> assuming it could be useful in a situation like this. Let's once and for all in this email thread rule out, that this is not an rc(8) issue. A host can boot faster than its switch or other networking equipment. No rc(8) magic can help agains that. I mentioned 'late' option as a non-bulletproof workaround for the problem, and that's all. btw, your suggestion for NAMESERVICE provide in rc(8) is a nice one, could be useful for something else, but not for this problem. -- Gleb Smirnoff From nobody Fri Feb 21 20:54:37 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 4Z02SJ4HKmz5pKgX for ; Fri, 21 Feb 2025 20:54:40 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z02SJ3Gwfz4PSN; Fri, 21 Feb 2025 20:54:40 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740171280; 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=M5RUB1ywQdmPt1L/jRDWwS1NnuvFzm6EDkx/1iO0Axg=; b=wfM/MCLT5GrPwfml0LgynWLUgsgc+bPHlwPVBINoxHGdmNP/M0d4IecDnURfGHUnVAbNbI 53iJetjOgiIxfnhelwnD0fbv4TCgQHskqYpWbGas9+fdCZvJUQrPDu3QEbI86XG8usJU45 X9ehdrlO8sx/nAgxJBFr3aRWpIedpEQkFQ8vGhOQyo1cgdalORWjgU5fDTDwnGQHVZtoJU VgLKgtHZcnq6Syq8T6AaNZi3pECekNIAO8BWOyDmiLJaDIqHf58SkNMqG6HL8koE4xOe1H VVTWlM122K164twEb5w7OnapUQkVOgSHpmsYWe8DEbhcW0NnEM+5xN9ce2r8NA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740171280; a=rsa-sha256; cv=none; b=KDVO4iAvytTZF4aVzJQKyJBlzz8WnRTCSeAkCo/ZdM2VmfEAYejZKZH6kY2z7CpgdU9+pH kprdoc2Y8NcXSFtreLhYrGgfJQch6F1JKOLZ5uSMYwoFt2h0h1zlxxTGyq4Ruh4GqKWrb4 Jm1Uq8a4u4NttGwRB+bAbft+vC9ujRAWlpHK4IIsoFfypflmP+51PIb2GKdQ+GM4bgpNPh WC6aXxSefCZCd95rhl9SIoE4+exJ2Vd7ES+OJ3o/APr6kzsd/fNH5pHXs4d3vXa12SqEwV GkREB93vw1kDr5j2cfWcdwUAc0hnDZm3Qxazw5Io8FmsAWkOf5Kd2+cN0+pt4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740171280; 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=M5RUB1ywQdmPt1L/jRDWwS1NnuvFzm6EDkx/1iO0Axg=; b=FQyCxRFqbLBhYg1qMtc7hYaAJvabgy2t+BXaiB5r1loSvBtOFF6T/bCDIFz58mi7i8hL9R vSgMsufpbbCXxmG63jPdLAlpNxV12huZrVmgqkPPj0JeCGiKOn31YRPoXGf1aW6pSos4hJ AJNjecUvhyZfvdLw2skqFv/k9ZS9TonisFJGLx90UZyjEWVwvpa1rueyNNC6X4o75+DGzj xF+S6n8/f7OHRvwX1gUnt8MSbMnVPyDvG2JrAJKZxwGwZH8H/72Vw8VkkTTULX3poTQtIR x+iN/8qnG6QB6l5PbBJ60J3vKoUrSu+gzHz6x/8QVQuRFYpYZZFtJILDA2qzDg== 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 4Z02SH4pc4zLrS; Fri, 21 Feb 2025 20:54:39 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 21 Feb 2025 12:54:37 -0800 From: Gleb Smirnoff To: Rick Macklem Cc: Toomas Soome , FreeBSD CURRENT , Steve Rikli Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: References: <862576B0-EFBF-4CC9-B99A-723125D60983@me.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: On Fri, Feb 21, 2025 at 05:06:16AM -0800, Rick Macklem wrote: R> Agreed. Unfortunatey, the return values for getaddrinfo(3) do not clearly R> differentiate between them. I think Gleb's case returns EAI_FAIL, which is also R> returned for other failures. I think EAI_NONAME is returned for the case where R> the resolver (dns, /etc/hosts or ???) does determine that the name is bogus. R> R> I suppose the code could do retries for all return values other than EAI_NONAME, R> but to me that would still be a POLA violation, since the current R> behaviour has been R> in place for decades (as others have noted). Also, some of the R> feedback here has R> been "It is not broken, don't fix it", if I interpreted it correctly. R> A new option avoids R> changing the default behaviour. I would argue that there is no POLA breakage here. POLA violation means that people would need to learn something new, different to what they were doing for years. E.g, they need to run a new command to achieve same result as they did before, or run they same command but observe a different result. The fix does changes behavior of mount_nfs, but does it change anything for a user, an operator or a sysadmin? * Those who use IP addresses in /etc/fstab - nothing changes for them. * Those who use name from /etc/hosts in /etc/fstab - nothing changess for them. * Those who use DNS names in /etc/fstab (but didn't run into issues until now) - nothing changes for them. And a potential issue is fixed for them. What about somebody, who run mount_nfs(8) from command line? First, they would need to run with 'bg' option, to see any behavior difference, which is already very uncommon for command line mount_nfs. Second, again nothing changes for them if everything is all right with their network. Only if their network/DNS is off, they would see mount_nfs(8) going into background instead of failing. I do claim that this is a positive change, someone would argue that people may use mount_nfs(8) as a probe for working DNS and that would be broken. Well, very far fetched POLA violation. -- Gleb Smirnoff From nobody Fri Feb 21 21:31: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 4Z03HN0pwtz5pNmc for ; Fri, 21 Feb 2025 21:32:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 4Z03HM2t3jz3Fs2 for ; Fri, 21 Feb 2025 21:31:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=e5EHRZTK; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-6ddcff5a823so20832356d6.0 for ; Fri, 21 Feb 2025 13:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740173518; x=1740778318; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=I4Lwm11nK94BqJdToankrI90xx3btwdSzY4TxNoxiiI=; b=e5EHRZTKxGiEmIONZY9iTfvEjaa9kGL6ajHYrzYIVce5FuaijudH+uk1HuvjDZdN77 KggPx6zEana1UucJJbc9V2XlZR2yutz4qpqLy/t9OZ3BAdYtPWX8clxRCMjW5fGR3jwn zLcah+Z8ht7ZA2f9vZ9nvxL3c9dIJ8uUN+KZdGh7Dtbz8Q7IhVQDimQYe3snEDyF5gKs j1PdU0ItZxkMQ/LT7uUqcsAT2/jmehxxTfOcOosCdBVj7F8DQDJaBqFKxSA90+KeGunr JfQWFhODZeeLnxwrUhUgPLdfvOaCl8KbfaaUSgNtn1HUS33RoPmbyC+WcQViEnm4UN7i iypQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740173518; x=1740778318; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I4Lwm11nK94BqJdToankrI90xx3btwdSzY4TxNoxiiI=; b=FgGF8j8arJMxJSISt0Z2Fau2Z1yn1blJ8X+BjyjXtvI1lyJ2+FRv6FZbKz6O79zocY ncWqzCD8FcgTLdi8CVoKVI7Bcs2ymKwFr+zalezygn2LfKQK7YbSFOObQApa+Fd1T3cg yls5pzd17IX0PRaxOAkOCliccAY4wAyVxqk1ZAeZIFDy6LG17x6Z9b8DnlzpWF1LuoMF GOvJQmPk5slp/R7ffzkQinFqEpJSzDYyiRRJsqhOVZmCYS/nJ/jCA+/sSpl/XRvnkkNR uKcPkRYZ8bU/E+1MP5JgJctGEVz50AuodnB7ZiodYKDaV92F/pI94O6qrwEJTzMm9Mso Xvhg== X-Gm-Message-State: AOJu0YxGdm739cLq0W2jE2utTSOGw4xgewTXspvU2mPCAIvuaDv/QLFC XwJpCsFWFsWwJn/SuqEqjVU0N3kwUFt+iHP0bkaJw7IbhttLuhGb5swbJA== X-Gm-Gg: ASbGncu26NGdvWE6dZEdko9pLBOyU87f3nhcsbE3FuLo2oXIErjjh8hVUf1hKexDryp q0sE8OW+XzAhEWIPN2qaXz75AZzJCVKNWS89vzb3HLUWnm5fauTinqJHRs3DiIZ3a7IQw+5lwJf YgG92FRbrtGm4DJBX7xIEhDj7rGzAHSf/b8mpGmDqVLMjFI70NdrHJtyeCFkp609zs5TA1A8LA4 4U4qUvsjR+4M5IXvfKbqoOJ26tfaGElmKkGfNyxCCGcXwmdxhLdH4rz4YJbkuM74IHXvkUDRN0P 4Wp6I0iJiqkIvFsPIRZ7rjNkzijIEKe00y/mJELM X-Google-Smtp-Source: AGHT+IFi1AmRfS79Pb8lm9P3m9nzXnkwRg3VCuOQsTuv8HT/vMHlc7dNnguAafGCXnGUTdy3fWNyZA== X-Received: by 2002:a05:6214:2b06:b0:6e6:65df:5571 with SMTP id 6a1803df08f44-6e6ae7f8079mr58054846d6.13.1740173518444; Fri, 21 Feb 2025 13:31:58 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c096443dc4sm701476985a.60.2025.02.21.13.31.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Feb 2025 13:31:57 -0800 (PST) Date: Fri, 21 Feb 2025 16:31:54 -0500 From: Mark Johnston To: Alexander Leidinger Cc: Current FreeBSD Subject: Re: crash with head as of 2h ago (in_pcblbgroup_insert) Message-ID: References: <3d6c377f2567aaa2e0601a7c11c729d5@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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> X-Spamd-Result: default: False [-2.54 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.938]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from] X-Rspamd-Queue-Id: 4Z03HM2t3jz3Fs2 X-Spamd-Bar: -- On Thu, Feb 20, 2025 at 10:27:28AM +0100, Alexander Leidinger wrote: > Hi, > > I get this backtrace: > ---snip--- > [102] panic: invalid local group size 16 and count 16 > [102] cpuid = 17 > [102] time = 1740041984 > [102] KDB: stack backtrace: > [102] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe07453a5b80 > [102] vpanic() at vpanic+0x136/frame 0xfffffe07453a5cb0 > [102] panic() at panic+0x43/frame 0xfffffe07453a5d10 > [102] in_pcblbgroup_insert() at in_pcblbgroup_insert+0xaa/frame > 0xfffffe07453a5d30 > [102] in_pcblisten() at in_pcblisten+0x92/frame 0xfffffe07453a5d50 > [102] tcp_usr_listen() at tcp_usr_listen+0x18a/frame 0xfffffe07453a5db0 > [102] solisten() at solisten+0x47/frame 0xfffffe07453a5dd0 > [102] kern_listen() at kern_listen+0x3f/frame 0xfffffe07453a5e00 > [102] amd64_syscall() at amd64_syscall+0x15b/frame 0xfffffe07453a5f30 > [102] fast_syscall_common() at fast_syscall_common+0xf8/frame > 0xfffffe07453a5f30 > ---snip--- > > This is with head updated at 2025-02-20-080119 CET. The previous world is > from 1 month ago (2025-01-22-120655). I believe this would be fixed by https://reviews.freebsd.org/D49100 Please note that I haven't tested it yet (currently running it through the regression test suite to start). From nobody Sat Feb 22 12:06: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 4Z0QjC5Wqhz5plvj for ; Sat, 22 Feb 2025 12:07:11 +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 "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z0QjC1qbCz44P8; Sat, 22 Feb 2025 12:07:11 +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=1740226018; 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=acRizvidCkRw2njJ94UxpLXDD6MVdRZ/UAkFzPLPzVs=; b=ZhTuVtRerwffQ8ZcrO7DP4qBhZsXUGP0rgwsQfZe2LPnyDJhftUzjcxH3+Aj1K+pV5EkWP qtUXVhY6rwNxL4WbZiC/5jmdemUY0woSIVQuYFndsug8SQcnlID0V8pRwcdB+ZGTel8Av1 IcKXEw8XIWCiEcQttWSFoacAiiA6BZqJKh3xf5jFWqPxRJbpJ55z2yMa91tYDaDn4QNdH2 fTUjmU54B6zWIPxpOQyDv3nAWrP39o7dKnn21Rdp9t4f4sM8XOvDvVaUWq8Qoo3A16p/yC t9eT2cLu5NU1YnPLjQ6kTLIaZAYV4/My+Omx/BAPGHGuQoucasfX2YUJx3+W/w== Date: Sat, 22 Feb 2025 13:06:02 +0100 From: Alexander Leidinger To: Mark Johnston Cc: Current FreeBSD Subject: Re: crash with head as of 2h ago (in_pcblbgroup_insert) In-Reply-To: References: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> Message-ID: <8dfe920e6d26603030744799102133a0@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_d696f4eda737dc6f8e37752c1a3527b5"; micalg=pgp-sha256 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4Z0QjC1qbCz44P8 X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_d696f4eda737dc6f8e37752c1a3527b5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2025-02-21 22:31, schrieb Mark Johnston: > On Thu, Feb 20, 2025 at 10:27:28AM +0100, Alexander Leidinger wrote: >> Hi, >> >> I get this backtrace: >> ---snip--- >> [102] panic: invalid local group size 16 and count 16 >> [102] cpuid = 17 >> [102] time = 1740041984 >> [102] KDB: stack backtrace: >> [102] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe07453a5b80 >> [102] vpanic() at vpanic+0x136/frame 0xfffffe07453a5cb0 >> [102] panic() at panic+0x43/frame 0xfffffe07453a5d10 >> [102] in_pcblbgroup_insert() at in_pcblbgroup_insert+0xaa/frame >> 0xfffffe07453a5d30 >> [102] in_pcblisten() at in_pcblisten+0x92/frame 0xfffffe07453a5d50 >> [102] tcp_usr_listen() at tcp_usr_listen+0x18a/frame >> 0xfffffe07453a5db0 >> [102] solisten() at solisten+0x47/frame 0xfffffe07453a5dd0 >> [102] kern_listen() at kern_listen+0x3f/frame 0xfffffe07453a5e00 >> [102] amd64_syscall() at amd64_syscall+0x15b/frame 0xfffffe07453a5f30 >> [102] fast_syscall_common() at fast_syscall_common+0xf8/frame >> 0xfffffe07453a5f30 >> ---snip--- >> >> This is with head updated at 2025-02-20-080119 CET. The previous world >> is >> from 1 month ago (2025-01-22-120655). > > I believe this would be fixed by https://reviews.freebsd.org/D49100 So I was just luck that this works ATM... or unlucky that I got a panic on the previous try. > Please note that I haven't tested it yet (currently running it through > the regression test suite to start). As the config and number of applications/jails/services started didn't change, any idea how to provoke this race condition on a system with some real applications (instead of test cases; if you need an independent validation)? A reboot loop until it happens is not really something I want to do on this system. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_d696f4eda737dc6f8e37752c1a3527b5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAme5vbsACgkQEg2wmwP4 2IZkUw//V27vGlgLLBtnsmpwMh21GfUHAYI8OxRUcMFtVRczCdiLJxk5ZZ/71ARk AC6yK+G4S7SAKfoakgjoMS25Ltuhql9eVKJ9zVqo+W/9dOxGSuYZBOnIierB7LrU yJHg7fJXZIE+AG9L/KPD6U83Pr5ssygrl4gnNxqZw8vwxobMnNPFnqu6ct6g77nW vqWrVXa/8iDbnL/D5dw/7MJ/M1VF5PpswnNDne8VyzpmSRC6go5FSxxv2f+FtPWZ iPTCRYKHwgj1c6rHUyCH/uJrZXhA4OupNTUbBZo2+PhBP30N10uLuglHhClhPWnl 4TSyDjFtyXtJe/t1j2x+3BmwF3dXnI7xB+vIWrp289FasrACky+l2kLeOIZpKX5x 3Mlg7cqDjxuqpuZHym1Gas27le+Kqyc7RY07QHr3T7yggVpM5vRex3a9+cnpKYhR pNnYb5wwP2I3W+c/HtpVSECzrV1cF73IP2ljUjyFrib5SsZ3GLFZOQo5rQIDICjj xoLEgXN8ZR+967GlL2qz3tUgBewkCX4yuRpMQtTiYGZrcQbStmrqmXM2vFPVgQcK /ftL433eBSiwSo/NQQHRjIcKkYxnIu72OiAYOKUoDlxgO9hwJ4bPbHkHu1KiQmCi Ot/1QEOIRrB5QS8MNNgnz29SyTpc4bEwPIzCvK4X6B3IoS2J8KI= =sQ3i -----END PGP SIGNATURE----- --=_d696f4eda737dc6f8e37752c1a3527b5-- From nobody Sat Feb 22 14:47: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 4Z0VGb4yVKz5nmVZ for ; Sat, 22 Feb 2025 14:47:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 4Z0VGb0swfz3JC1 for ; Sat, 22 Feb 2025 14:47:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-7c089b2e239so328517785a.0 for ; Sat, 22 Feb 2025 06:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740235670; x=1740840470; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=F8jhihJNGo+FTzsKpG6jymZksOdvyOzSGrcgwgaEBY8=; b=KroR5Hqatp/VYPxSNwSAqbUFpt4bzR7CDQF1ZifzB+pqCOwb15HP6ynZIIgecXLmOQ z8C4noAGfmjLawMc9TD72TJsuUcjaqQmnVmYqpW5ra/ZL/Xk1usm1LUVvxVBOATcPfO5 JMCuFLK2OJ8V4onIbl7q803Wnt5AjEn4hcMSZ6ex5rIdthXZS13qaTYr3vC6kiUBkmVj JXd1CgznBY0iqV7LDz7PIuTYu1v5Ve/u8uL7oHHY0cHW2BCgzYE13oaZBmpfPGUlxDk9 VTBatm18LGuaL0Njn/NVKRCfslVOSoHielltwBjAe/UC3GzSbOrPh4GnwGYh1KzaRiW7 hNNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740235670; x=1740840470; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F8jhihJNGo+FTzsKpG6jymZksOdvyOzSGrcgwgaEBY8=; b=gfpJodBssuz6OyhJlpRcvryBOrJ9hclqBpMNcv3fB886xY4PKKxlmMIqEO4qoaJ4Ti x2rGb3HOOHym450nBIUmFxnfd0OGG8QCkwpqL9V3naxyszxLiblcwjjtEnrV2nsBEdyA ct3pAYmQYQSFB7+fhSF8Vme9YhRlb02FiCJJFJXvpr8pSAQl0faL3UEZFNghTET0+UHc nN3iq9dkJvER26GBpZRtU6BTtvyD7EYZ6OeVxJ4Ct/p+E1jTZ/tLvJx1y1FWHYmsXIDN 64HgskGKOMY9rOdq2KD4r3G3QB7b3XG56EHIFABYugJGU8zCjA88RmJfSTRhfg+DTYzJ 7BcQ== X-Gm-Message-State: AOJu0YxbET9vHhCe+eaYCHr0AaXnYk9cNnfWD5Va0yKWlm5D4TFkqXn2 P7/C6vQvxEDZaR0tBVmmPsnbieBdkOi2uVU4xtnL/AWh9l2hMc4Qa56Bog== X-Gm-Gg: ASbGnctcsAAUV7VpxFQ6rkvWReyVv7hZ8/F7zo3qk1gveyRGXYqcsK4AoaVWPh7Evcv 8xgpjmq39ZCDaIVQFWtf5lKq8MopPkqnt5YIkORQrUEvit1y5w97PJ+L+vL8IW5bolL4IP+QU/H Xhxn+Jbf+rKH/lbq9EBlmp3/zOG6+/9jQ5AATiSHxQTr6hqOXT+X6IUwzPCe+9aiL9PF0EvUa4x KLxpHuqtUEvpzLwgz0h53/eFnjhdKTX5/QiIXsnzXkj22jjORC67Ysg8Seqz71lyYyPAkw57bCe YInpv4LSvnVyZvvdXhfZPURcdZ9YPVr2Zd6pS4gC X-Google-Smtp-Source: AGHT+IEASqYvbkmEzOZaR2XFe6LEK7S8tMM1NBrenTu8X18Ko2hUooM8jd+kf9Pn0oTLyCRlhFcpzQ== X-Received: by 2002:a05:620a:4051:b0:7c0:b384:77bb with SMTP id af79cd13be357-7c0c21ad180mr1308235985a.14.1740235669934; Sat, 22 Feb 2025 06:47:49 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c0a46dbcdcsm672628285a.106.2025.02.22.06.47.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Feb 2025 06:47:48 -0800 (PST) Date: Sat, 22 Feb 2025 09:47:45 -0500 From: Mark Johnston To: Alexander Leidinger Cc: Current FreeBSD Subject: Re: crash with head as of 2h ago (in_pcblbgroup_insert) Message-ID: References: <3d6c377f2567aaa2e0601a7c11c729d5@Leidinger.net> <8dfe920e6d26603030744799102133a0@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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8dfe920e6d26603030744799102133a0@Leidinger.net> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Z0VGb0swfz3JC1 X-Spamd-Bar: ---- On Sat, Feb 22, 2025 at 01:06:02PM +0100, Alexander Leidinger wrote: > Am 2025-02-21 22:31, schrieb Mark Johnston: > > On Thu, Feb 20, 2025 at 10:27:28AM +0100, Alexander Leidinger wrote: > > > Hi, > > > > > > I get this backtrace: > > > ---snip--- > > > [102] panic: invalid local group size 16 and count 16 > > > [102] cpuid = 17 > > > [102] time = 1740041984 > > > [102] KDB: stack backtrace: > > > [102] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > 0xfffffe07453a5b80 > > > [102] vpanic() at vpanic+0x136/frame 0xfffffe07453a5cb0 > > > [102] panic() at panic+0x43/frame 0xfffffe07453a5d10 > > > [102] in_pcblbgroup_insert() at in_pcblbgroup_insert+0xaa/frame > > > 0xfffffe07453a5d30 > > > [102] in_pcblisten() at in_pcblisten+0x92/frame 0xfffffe07453a5d50 > > > [102] tcp_usr_listen() at tcp_usr_listen+0x18a/frame > > > 0xfffffe07453a5db0 > > > [102] solisten() at solisten+0x47/frame 0xfffffe07453a5dd0 > > > [102] kern_listen() at kern_listen+0x3f/frame 0xfffffe07453a5e00 > > > [102] amd64_syscall() at amd64_syscall+0x15b/frame 0xfffffe07453a5f30 > > > [102] fast_syscall_common() at fast_syscall_common+0xf8/frame > > > 0xfffffe07453a5f30 > > > ---snip--- > > > > > > This is with head updated at 2025-02-20-080119 CET. The previous > > > world is > > > from 1 month ago (2025-01-22-120655). > > > > I believe this would be fixed by https://reviews.freebsd.org/D49100 > > So I was just luck that this works ATM... or unlucky that I got a panic on > the previous try. > > > Please note that I haven't tested it yet (currently running it through > > the regression test suite to start). > > As the config and number of applications/jails/services started didn't > change, any idea how to provoke this race condition on a system with some > real applications (instead of test cases; if you need an independent > validation)? A reboot loop until it happens is not really something I want > to do on this system. I added a test case which triggers the same panic to the review. I don't have any suggestions for how to trigger it in your setup, I just offer the patch to keep your system stable until the next update. From nobody Sat Feb 22 14:49:55 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 4Z0VKN6D7tz5nmfW for ; Sat, 22 Feb 2025 14:50:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4Z0VKN0SBYz3L8H; Sat, 22 Feb 2025 14:50:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5ded1395213so5164488a12.2; Sat, 22 Feb 2025 06:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740235814; x=1740840614; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ja7P5wLM1wHtZKncQPPuVXEHtL+OaMNbLVnqisdsKdw=; b=Y0Z2u1enEqTe3w3A++Tt4Ill0fpV0ozwOi6I1sEPGzS32WqCDQADx2pvDLlzGxDFoD JWBu0Rk7+d2xVaTqfK/xlLAAt9xrXL2QxeYVg+0TLUP+CZcDJld08sf8ZpwsT18wD52t 3XkiTmXdvef6U5B1EMW63Uq963m0YsBefwDQxYBTp6jlAw+xL1cMFcpC3JxNAmdBtDvN Ks6Ca1xhAud8inffhffjdMhIAlizBWG27nn9myRNnT0Mcf3C6ZO3lCTOoa7l4loAZUZs gFViiRs+0AicY/ftfWaArShFf6aPGHgddqFZgfXmACqhHgPRIO6hUEy8LIn5pMNk9Xu4 LOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740235814; x=1740840614; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ja7P5wLM1wHtZKncQPPuVXEHtL+OaMNbLVnqisdsKdw=; b=M/kZuNgELDlatQCEaCm5HJ314oKESa9qur+qDCLAXPdP4j8GiOp19TjICjwLG6cnbw 4bvbXv9rn4hXNZ1G3swTrkzpyeAvJ+NpoPTe7DgLyY+1i9dMQg0pc9bPpccsjvqJrtsx 0TqjYA3ClBg9KzhIiLTj79KqOo6BaSuxplXvuJHIKv44zN/6rua3Dy1J6uStu6BtAxa0 G4Na6aVLD1BAppXQDDu2GFrs5x1izWOvRaigCWEWeASm6/PtwGLP6gkKarTAvvaM7OB3 8MdaVLucbDz9FCBKHwmR4bBYjoZOalmNDuIuYRFiywJOC6iEceDlub/BMn4O81235ta1 ZRew== X-Forwarded-Encrypted: i=1; AJvYcCVGGrwUMoX+KHwu8ljVAKknnIP6Zb4bwlqDbBOh7VytXmigaagqDUqeiJ/U+AZnvZkIaSAwfOuqKob7tBrYvj8=@freebsd.org X-Gm-Message-State: AOJu0YyamnFJvzec3dQXjrQQWc65yTMnKEOfKe8k65/bin5gRVbCK/9C LCVg/MOuGvvu0YVFgqMs4wW2cg03OlEdLHoNQ8psGC6yq33IS4fGIr/zU841nJQ12Wn8WwY4BMK FUC7hmVs8IOW+kn7B4CRMWAAEqxV5 X-Gm-Gg: ASbGncsTfdHroe3L2rclYXXA6MHpM12O/pSQCvsYSAZMp814cjqWS/WrGZfp0WfUheH 4MvrJHc/hJZ4Aqb3TPEqupmF7l2ZkIbaj1cuIiX+I/FOM7nrlm/HmEQWCmaRFA/EFipAOYaPVLY hL1MKwLbtqZi3fm8eISU2nYD44omsbNK9Xm7gTY93z X-Google-Smtp-Source: AGHT+IHb9Y+fhVJdlPT/4SJuhHJHJIsY2cqrY7IDjScA51cyORNC6UDBAUsjwGSGPujh1ZHyGu81+J3b7W0JgRkXK5w= X-Received: by 2002:a05:6402:350f:b0:5dc:c9ce:b022 with SMTP id 4fb4d7f45d1cf-5e0b70e4ddemr6559339a12.9.1740235813607; Sat, 22 Feb 2025 06:50:13 -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: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> In-Reply-To: From: Rick Macklem Date: Sat, 22 Feb 2025 06:49:55 -0800 X-Gm-Features: AWEUYZm7Qf9iSQxsA7Drp4oBQ9nq0dDGrrPDC-ncHtpZEfYnF0H8EfO3dIP1Ojk Message-ID: Subject: Re: RFC: mount_nfs failure due to dns not running yet To: Gleb Smirnoff Cc: Toomas Soome , FreeBSD CURRENT , Steve Rikli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z0VKN0SBYz3L8H X-Spamd-Bar: ---- On Fri, Feb 21, 2025 at 12:54=E2=80=AFPM Gleb Smirnoff wrote: > > On Fri, Feb 21, 2025 at 05:06:16AM -0800, Rick Macklem wrote: > R> Agreed. Unfortunatey, the return values for getaddrinfo(3) do not clea= rly > R> differentiate between them. I think Gleb's case returns EAI_FAIL, whic= h is also > R> returned for other failures. I think EAI_NONAME is returned for the ca= se where > R> the resolver (dns, /etc/hosts or ???) does determine that the name is = bogus. > R> > R> I suppose the code could do retries for all return values other than E= AI_NONAME, > R> but to me that would still be a POLA violation, since the current > R> behaviour has been > R> in place for decades (as others have noted). Also, some of the > R> feedback here has > R> been "It is not broken, don't fix it", if I interpreted it correctly. > R> A new option avoids > R> changing the default behaviour. > > I would argue that there is no POLA breakage here. POLA violation means = that > people would need to learn something new, different to what they were doi= ng for > years. E.g, they need to run a new command to achieve same result as the= y did > before, or run they same command but observe a different result. The fix= does > changes behavior of mount_nfs, but does it change anything for a user, an > operator or a sysadmin? What about the case where without any patch, the mount fails and the system continues to boot normally otherwise, whereas with a patch, the system hang= s while booting, trying to do the mount? (Although you noted different behaviour for "late", I believe an NFS mount without "bg" should block further startup until the mount succeeds. An NFS mounted = /usr, for example.) I have put a patch up on phabricator as D49104 which I hope you can test/re= view, ignoring the fact that you do not think fixing it by default is a POLA violation. rick > > * Those who use IP addresses in /etc/fstab - nothing changes for them. > * Those who use name from /etc/hosts in /etc/fstab - nothing changess for= them. > * Those who use DNS names in /etc/fstab (but didn't run into issues until= now) > - nothing changes for them. And a potential issue is fixed for them. > > What about somebody, who run mount_nfs(8) from command line? First, they= would > need to run with 'bg' option, to see any behavior difference, which is al= ready > very uncommon for command line mount_nfs. Second, again nothing changes = for > them if everything is all right with their network. Only if their networ= k/DNS > is off, they would see mount_nfs(8) going into background instead of fail= ing. I > do claim that this is a positive change, someone would argue that people = may > use mount_nfs(8) as a probe for working DNS and that would be broken. We= ll, > very far fetched POLA violation. > > -- > Gleb Smirnoff From nobody Sun Feb 23 13:52:44 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 4Z15196kpCz5nm8V; Sun, 23 Feb 2025 13:53:17 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.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 4Z15185sWpz3FHK; Sun, 23 Feb 2025 13:53:16 +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=tGIrO7CQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8: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 16883240F06; Sun, 23 Feb 2025 14:53:14 +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 83854240370; Sun, 23 Feb 2025 14:53:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1740318792; 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=q4F1ELXj9KfAp0UMRWW8vnSOY44mxTqTouKdq7zU5UA=; b=tGIrO7CQoseewEWiMe3qiQkX3Y0vPIszTnIXT5a9Lp158g+LFo7ECT+Pq2lcpSJARbYH4O sdui1mfvzo98gatNEZa3vIXrXIJObj+BA/yzxOnncMX1ITQhYtHjOaSHSajTBHwA3auc6b n7jkQ1JEt0JhxEs8y2OJ6EQZQqBS0FdEPYEcC+LShyBoSpM1vtJORk8n9fFaFMCI9soTeG F0pO0YpFvzU9WDVneYxFFgD3to5mt24kExE3JMGyPj4MOB1QvaRImnLAfWkaUitGCXvOA2 HVOn0kqDee54F6iwrswplVoz1ZMGVrPUpdLTPkpKy6bkYIAbRMoYXQlCuknVPg== Received: from thor.sb211.local (dynamic-2a02-3100-1a5d-2802-751a-9ae2-1d14-0faa.310.pool.telefonica.de [IPv6:2a02:3100:1a5d:2802:751a:9ae2:1d14:faa]) (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 229C42402ED; Sun, 23 Feb 2025 14:53:12 +0100 (CET) Date: Sun, 23 Feb 2025 14:52:44 +0100 From: A FreeBSD User To: Bob Bishop Cc: FreeBSD CURRENT , "freebsd-net@freebsd.org" Subject: Re: rtadvd(8) How to IPv6 tokenize interface identifier Message-ID: <20250223144203.7f61d0bf@thor.sb211.local> In-Reply-To: <2D84F83E-4548-40FA-B817-39703C670B43@gid.co.uk> References: <20250221075300.4466057d@thor.sb211.local> <2D84F83E-4548-40FA-B817-39703C670B43@gid.co.uk> 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_/vXO=ctu1Xv7nwtnQZNzQupa"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 3ad66d X-Rspamd-UID: 01953f X-Spamd-Result: default: False [-1.51 / 15.00]; SIGNED_PGP(-2.00)[]; RBL_SENDERSCORE_REPUT_9(-1.00)[85.220.129.31:from]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(0.99)[0.995]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(0.20)[0.200]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[85.220.129.31:from]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org,freebsd-net@FreeBSD.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Z15185sWpz3FHK X-Spamd-Bar: - --Sig_/vXO=ctu1Xv7nwtnQZNzQupa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Fri, 21 Feb 2025 10:44:12 +0000 Bob Bishop schrieb: > Hi, >=20 > > On 21 Feb 2025, at 06:52, A FreeBSD User wrote: > >=20 > > Hello, > >=20 > > Linux (especially OpenWRT we use) knows about a concept named "IPv6 tok= enized interface > > identifier". The concept is self explanatory, a interface/router obtain= s a propagated > > prefix and the concept allows the explicit definition of the host porti= on. > >=20 > > I haven't managed to accomplish such a behaviour using FreeBSD's rtadvd= (8) daemon. I guess > > this task is subject of and performed through the rtadvd.conf(5) config= uration file, but I > > haven't managed yet to accomplish such a task (to speak simple: I'd lik= e to have a router > > of a subnet always at IPv6 Network PREFIX:0:0:0:1). =20 >=20 > Isn=E2=80=99t sufficient just to give the router a static IPv6 address? T= hat=E2=80=99s what we do here. Hello. The router itself has on all inbound NICs static ULAs, ending as desired on= "fc:/7-PREFIX::1". Using KAME dhcp6c, software from 2008(!), with a configuration obatined for= delegating a prefix, each NIC - except tun0 for whatever reason - gets a prefix, the inb= ound NICs then seem to get a EUI64 generated IPv6 (although I sepcified "privacy", but this see= ms to be ignored, sadly ...).=20 =20 >=20 > > The only config tag I can imagine is responsible for what I'd like to a= chive is the "addr" > > tag mentioned in rtadvd.conf(5), but whatever I fill this tag with - th= e desired effect is > > never achived (i.e addr=3D"::0.0.0.1"). My "FreeBSD homebrewn" router h= as several networks, > > attached to vlan. Each interface is subject of an ULA prefix and an IPv= 6 prefix provided > > by our ISP. It is possible to pin the ULA toward the desired address, l= ike > > addr=3D"fd50:c450::1", but then the ISP provided prefix seems not to be= set properly or is > > completely absent. Omitting "addr=3D" provides the interface with ULA p= refix and ISP prefix > > - but obviously with the randomly generated 64bit host portion. > >=20 > > Playing around with mutually suitable tags, like "pinfoflags", "raflags= " or "rtflags" and > > having probed almost every possible combination (with or without some s= ense), it seems > > impossible to provide a) both ULA and ISP prefix pin the host portion t= o a desired 64bit > > address, like "PREFIX::1". > >=20 > > I do not exclude that I'm possibly incapable of comprehension the manpa= ge (the language is > > and the deeper semantics seem then to be hidden for me). So, if there i= s a clear > > expalanation how to achive the desired, please point me towards it (tha= nks in advance!). > >=20 > > Linux has this feature since a while and I can not believe that FreeBSD= lacks such a > > feature. > >=20 > > Thank you very much in advance, > >=20 > > O. Hartmann > >=20 > >=20 > > --=20 > >=20 > > A FreeBSD user =20 >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 --=20 A FreeBSD user --Sig_/vXO=ctu1Xv7nwtnQZNzQupa Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCZ7soRwAKCRCxzvs8Oqok rxDoAP0YSMsesSBXe+1o0NYxpLWXqSv7GOX992f+hO7mPWLRGQEAgrw6+F5PH+cP Z7xwzuKqcUfL7qWlOgW1ZVwy7jKz7QY= =201v -----END PGP SIGNATURE----- --Sig_/vXO=ctu1Xv7nwtnQZNzQupa-- From nobody Sun Feb 23 16:56: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 4Z194f6c8Dz5p4Nl; Sun, 23 Feb 2025 16:56:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z194f2gfcz3ZwJ; Sun, 23 Feb 2025 16:56:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 51NGuQ0g060112; Sun, 23 Feb 2025 16:56:26 GMT (envelope-from rb@gid.co.uk) Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 51NGuLH9093479; Sun, 23 Feb 2025 16:56:21 GMT (envelope-from rb@gid.co.uk) 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 \(3776.700.51.11.1\)) Subject: Re: rtadvd(8) How to IPv6 tokenize interface identifier From: rb@gid.co.uk In-Reply-To: <20250223144203.7f61d0bf@thor.sb211.local> Date: Sun, 23 Feb 2025 16:56:11 +0000 Cc: FreeBSD CURRENT , "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20250221075300.4466057d@thor.sb211.local> <2D84F83E-4548-40FA-B817-39703C670B43@gid.co.uk> <20250223144203.7f61d0bf@thor.sb211.local> To: A FreeBSD User X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Z194f2gfcz3ZwJ X-Spamd-Bar: ---- Hi, > On 23 Feb 2025, at 13:52, A FreeBSD User = wrote: >=20 > Am Fri, 21 Feb 2025 10:44:12 +0000 > Bob Bishop schrieb: >=20 >> Hi, >>=20 >>> On 21 Feb 2025, at 06:52, A FreeBSD User = wrote: >>>=20 >>> Hello, >>>=20 >>> Linux (especially OpenWRT we use) knows about a concept named "IPv6 = tokenized interface >>> identifier". The concept is self explanatory, a interface/router = obtains a propagated >>> prefix and the concept allows the explicit definition of the host = portion. >>>=20 >>> I haven't managed to accomplish such a behaviour using FreeBSD's = rtadvd(8) daemon. I guess >>> this task is subject of and performed through the rtadvd.conf(5) = configuration file, but I >>> haven't managed yet to accomplish such a task (to speak simple: I'd = like to have a router >>> of a subnet always at IPv6 Network PREFIX:0:0:0:1). =20 >>=20 >> Isn=E2=80=99t sufficient just to give the router a static IPv6 = address? That=E2=80=99s what we do here. >=20 > Hello. >=20 > The router itself has on all inbound NICs static ULAs, ending as = desired on "fc:/7-PREFIX::1". > Using KAME dhcp6c, Ah. Nothing good will happen if you mix DHCP6 and SLAAC. > software from 2008(!), with a configuration obatined for delegating a > prefix, each NIC - except tun0 for whatever reason - gets a prefix, = the inbound NICs then seem > to get a EUI64 generated IPv6 (although I sepcified "privacy", but = this seems to be > ignored, sadly ...).=20 >=20 >>=20 >>> The only config tag I can imagine is responsible for what I'd like = to achive is the "addr" >>> tag mentioned in rtadvd.conf(5), but whatever I fill this tag with - = the desired effect is >>> never achived (i.e addr=3D"::0.0.0.1"). My "FreeBSD homebrewn" = router has several networks, >>> attached to vlan. Each interface is subject of an ULA prefix and an = IPv6 prefix provided >>> by our ISP. It is possible to pin the ULA toward the desired = address, like >>> addr=3D"fd50:c450::1", but then the ISP provided prefix seems not to = be set properly or is >>> completely absent. Omitting "addr=3D" provides the interface with = ULA prefix and ISP prefix >>> - but obviously with the randomly generated 64bit host portion. >>>=20 >>> Playing around with mutually suitable tags, like "pinfoflags", = "raflags" or "rtflags" and >>> having probed almost every possible combination (with or without = some sense), it seems >>> impossible to provide a) both ULA and ISP prefix pin the host = portion to a desired 64bit >>> address, like "PREFIX::1". >>>=20 >>> I do not exclude that I'm possibly incapable of comprehension the = manpage (the language is >>> and the deeper semantics seem then to be hidden for me). So, if = there is a clear >>> expalanation how to achive the desired, please point me towards it = (thanks in advance!). >>>=20 >>> Linux has this feature since a while and I can not believe that = FreeBSD lacks such a >>> feature. >>>=20 >>> Thank you very much in advance, >>>=20 >>> O. Hartmann >>>=20 >>>=20 >>> --=20 >>>=20 >>> A FreeBSD user =20 >>=20 >> -- >> Bob Bishop >> rb@gid.co.uk >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > A FreeBSD user -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518