From nobody Mon Mar 4 07:25:22 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tp9G504Y3z5C3nn for ; Mon, 4 Mar 2024 07:25:33 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4Tp9G33J6Hz4SxJ for ; Mon, 4 Mar 2024 07:25:31 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=alvermark.net header.s=x header.b=hS2NQJMW; dmarc=none; spf=pass (mx1.freebsd.org: domain of jakob@alvermark.net designates 185.34.136.138 as permitted sender) smtp.mailfrom=jakob@alvermark.net Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1rh2fQ-0007d5-01; Mon, 04 Mar 2024 08:23:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=o9vaALYRi/9B4z49BSQWNPKwpq9lEV2hEneqjW98faE=; b=hS2NQJMWNgwsygJr0atbVModHH 54atuusCjo698m5ELevDxA2SS03IHqCDl6rmb0nCO+x4kyRancxkSU6MhiuMMVW/uky393mjYtMfS wlXd8vcKZpSFogmQ9/zX/OBGlmIf77I+05g+vdqeWkRWrINA5UYMoH53k47V377L2HHzXaFZoG4IZ 3HzwJJ7HpC0faRA+4zVfyXPCpvekSsS5IN5OfL57RygQTZPunULxbmPTk4HCj0qMJQA9Ld1Hn83wB 6eCV302ASQnlo01/ArYfbH4sIj6sT8llIJO4FlQw865FIZ3X2Oec/RwNMY4KgyNt2oCjrNsOTY8UC sdNw6ubQ==; Received: from office.as33885.net ([84.55.65.101] helo=[192.168.10.2]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1rh2hO-000IUC-UH; Mon, 04 Mar 2024 08:25:22 +0100 Message-ID: Date: Mon, 4 Mar 2024 08:25:22 +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: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information To: Mark Millard , Current FreeBSD References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> Content-Language: en-US From: Jakob Alvermark In-Reply-To: <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[alvermark.net:s=x]; R_SPF_ALLOW(-0.20)[+ip4:185.34.136.138]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; DMARC_NA(0.00)[alvermark.net: no valid DMARC record]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[alvermark.net:+] X-Rspamd-Queue-Id: 4Tp9G33J6Hz4SxJ On 12/4/23 09:16, Mark Millard wrote: > The following sort of thing is happening a lot: > > Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically > used on occasion, sometimes for long periods . . . > > Example contexts for the issue have been: > > FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 18:17:40 PDT 2023 > and: > FreeBSD 15.0-CURRENT #131 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 16:53:33 PST 2023 > > Both UFS and ZFS boot media, here part of a ed31b3f4a146 UFS example is shown > > Nov 29 18:26:27 7950X3D-UFS kernel: miibus0: on ure0 > Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: PHY 0 on miibus0 > Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > Nov 29 18:26:27 7950X3D-UFS kernel: ue0: on ure0 > Nov 29 18:26:27 7950X3D-UFS kernel: ue0: Ethernet address: REDACTED > Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to DOWN > . . . > Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to UP > . . . (no ue0: messages, then) . . . > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 2 link states coalesced > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:20 7950X3D-UFS dhclient[53725]: New IP Address (ue0): 192.168.1.157 > Nov 30 03:23:20 7950X3D-UFS dhclient[53730]: New Subnet Mask (ue0): 255.255.255.0 > Nov 30 03:23:20 7950X3D-UFS dhclient[53734]: New Broadcast Address (ue0): 192.168.1.255 > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 3 link states coalesced > Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:20 7950X3D-UFS dhclient[53771]: New Routers (ue0): 192.168.1.1 > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 3 link states coalesced > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 2 link states coalesced > Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP > . . . (lots more) . . . > > Other FreeBSD system on the Ethernet are not getting such but none > of them are currently using such a dongle. > > Note: The ASUS X670-P WiFi board's built in Ethernet is not > supported. > > === > Mark Millard > marklmi at yahoo.com > I see the same with my Lenovo dongle: ugen1.12: at usbus1 ure0 on uhub6 ure0: on usbus1 miibus1: on ure0 rgephy1: PHY 0 on miibus1 rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 Jakob From nobody Mon Mar 4 16:35:52 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpPTB5D7Jz5Ctt3 for ; Mon, 4 Mar 2024 16:35:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpPT95TjLz4JMq for ; Mon, 4 Mar 2024 16:35:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 424GZq9A036059 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 4 Mar 2024 08:35:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.17.1/Submit) id 424GZqC0036058 for freebsd-current@freebsd.org; Mon, 4 Mar 2024 08:35:52 -0800 (PST) (envelope-from fbsd) Date: Mon, 4 Mar 2024 08:35:52 -0800 From: bob prohaska To: freebsd-current@freebsd.org Subject: Buildworld stops for d3befb534b9 in tests Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [-0.76 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.66)[-0.661]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; DMARC_NA(0.00)[zefox.net]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TpPT95TjLz4JMq An armv7 (Pi2 v1.1) -current system stopped buildworld with c++: error: linker command failed with exit code 1 (use -v to see invocatio= n) *** [capsicum-test.full] Error code 1 make[6]: stopped in /usr/src/tests/sys/capsicum =2EERROR_TARGET=3D'capsicum-test.full' =2EERROR_META_FILE=3D'/usr/obj/usr/src/arm.armv7/tests/sys/capsicum/capsicu= m-test.full.meta' =2EMAKE.LEVEL=3D'6' MAKEFILE=3D'' =2EMAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -target armv7-gnueabihf-freebsd15.0 --sysroot=3D/usr/obj/= usr/src/arm.armv7/tmp -B/usr/obj/usr/src/arm.armv7/tmp/usr/bin -O2 -pipe -f= no-common -I/usr/src/tests -g -gz=3Dzlib -Wno-format-zero-length -fstack-pr= otector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unuse= d-parameter -Wpointer-arith -Wno-uninitialized -Wdate-time -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=3Dunused-but-set= -parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equ= ality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -= Wno-address-of-packed-member -Qunused-arguments -I/usr/obj/usr/src/arm.armv= 7/tmp/usr/include/private -DGTEST_HAS_POSIX_RE=3D1 -DGTEST_HAS_PTHREAD=3D1 = -DGTEST_HAS_STREAM_REDIRECTION=3D1 -frtti -std=3Dc++14 -Wno-c++11-extension= s -Wl,-zrelro -o capsicum-test.full capsicum-test-main.o capsicum-test.= o capability-fd.o copy_file_range.o fexecve.o procdesc.o capmode.o fcntl.o = ioctl.o openat.o sysctl.o select.o mqueue.o socket.o sctp.o capability-fd-p= air.o overhead.o rename.o -lprivategtest -lprocstat -lpthread;' =2ECURDIR=3D'/usr/src/tests/sys/capsicum' =2EMAKE=3D'make' =2EOBJDIR=3D'/usr/obj/usr/src/arm.armv7/tests/sys/capsicum' =2ETARGETS=3D' all' CPUTYPE=3D'' DESTDIR=3D'/usr/obj/usr/src/arm.armv7/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv7' MACHINE_CPUARCH=3D'arm' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20220726' PATH=3D'/usr/obj/usr/src/arm.armv7/tmp/bin:/usr/obj/usr/src/arm.armv7/tmp/u= sr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/usr/obj/usr/src/arm.armv7/t= mp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/u= sr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/l= ibexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src/arm.armv7' =2EMAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.e= nv.mk /usr/src/share/mk/src.sys.env.mk /usr/src/share/mk/bsd.mkopt.mk /usr/= src/share/mk/src.sys.obj.mk /usr/src/share/mk/local.sys.machine.mk /usr/src= /share/mk/meta.sys.mk /usr/src/share/mk/local.meta.sys.env.mk /usr/src/shar= e/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/= share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/t= ests/sys/capsicum/Makefile /usr/src/share/mk/src.opts.mk /usr/src/share/mk/= bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/= src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.endian.mk /usr/src/share= /mk/bsd.linker.mk /usr/src/share/mk/bsd.test.mk /usr/src/share/mk/bsd.init.= mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/t= ests/sys/capsicum/../Makefile.inc /usr/src/tests/Makefile.inc0 /usr/src/sha= re/mk/googletest.test.mk /usr/src/share/mk/googletest.test.inc.mk /usr/src/= share/mk/plain.test.mk /usr/src/share/mk/tap.test.mk=20 make[2]: stopped in /usr/src I just re-ran git pull, no changes Thanks for reading, bob prohaska From nobody Mon Mar 4 17:54:14 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpRCs40Q5z5D22W for ; Mon, 4 Mar 2024 17:54:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpRCq4bCrz4SXy for ; Mon, 4 Mar 2024 17:54:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="if9/IxKC"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709574868; bh=OV4ggUPxLY/quQzn4oj/GCiMwXlN4hvRL9svjhlLcw0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=if9/IxKCsnmbmE9zZmwLqg4gypKB9p+rEMqovfls9UhU09GEr1iBSpvlJNWJuRKvGpknO3xwA8LBlGcowLGPBfjK7h5lI1fDzvAvVs1Dn/2PvUznSUGjgJnOuPwNaTTLDalw2ZR6E5xkqWus/xIIu7Ypc2HhkE5s0wDObi/Rld1uLsy/d2wdA7xWv4czR8RNgszYAaG78fU9oYQVB9YU+SF+JWDmrdQz41kjLeFKvSmrp2CTfy3oRBG+6JNZH0BaFkBNpY6ZwhV95Kr+Ql7Rx86f7+b98TPJpvVUXBeO4BmpQJHnUjqNu1/kR85PjW2qH8y6hOomQEW1osp7Jn00qw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709574868; bh=irlKiVZDX8sGeuLrAUzveNknYHur/2ZDaUQ0/JciZWK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f3wq3zila+qqaSw0H2u6weB/boDtYlQzA4LTeHgKiXV93U0Ae60TR3veo71OXF/h7VkhzSL494pJZfvM0AZZTaOsywzJv+15juG8XN/ZgXE270/Ch/d82o0j/BtU7jAOtqvb83FUlMPeZcGEHDF/YsdEe6YoKsLgVcu9JENnY8349kTZW5qv78X8btjpM3T+tyU/IoN8KynKhV4ofT3obI8TxWmLFYrsK6PZ1ex59U9Y6DSINPhNc78+TC6WM9CTxRQXknIDm0r6m6H6xiCj03gIDjPyY8EwHlt1lVXZu8xGJEiMR1US0S04V3cSsgydn+eLQtNzQdxBi9hHVeZLxA== X-YMail-OSG: Z1ifwFEVM1mm7vxpYhFVxUaMXRd1fsFQe9IA30Uz0jVh7G2ikpGVJjdkVh0r0ul XEWJTy5tNk_H.w4jPujQd6HfkT.YNpOFf8m2XpNwcxXd5gMsPVkjtYvM12QmjsUrZNZ4F1._R9tN MW.eE4TxjZPWtt2U66TFgdOzxuB0pe8UdB7.bFuuFoq7ceY22TqGsIe8Dj0P6XZjW3I_gGmtPphW zq4Y6rvGYIOXwmUPeyXagBuZRusZK0iwILMYUfGCZ53r99m_KtTHES2bIPMV1XM7q6PA_bSBRe6a G8_kn42ShqQnZ_aW066mWCz4KYU5w9ADazcGAgCSc458HJHB4nd8gJ2OCqEhP2V1ATuAyWJKNimS uAqZNSw8MkCpVFF2KEuOwlEbMSnfnG9NrPJVn66wcMSN3Sfonf0xXLwyENSF5avEuxsiFvL4wwHr aW9Lms6oXYvDPyDtLiBF6m5d.hCbRYwfsighLWYad3_8BXQVl2dGSzwC94X98DDnSq.umwVpEhk3 Aviv57EFYaG0ltq_F_8p7bwADXi1wMdK2ZC2ILCZocu3EGEtf5jRt0v9lKNK.IXi_Wav6h0JAnUO tUlj52rr1gPSW_qHRe9QKB12ffn7gPOSd0SFtOmn7dWduThrTysvxtSsMcWoF9g1Yuim5mxVig1e ftUlUaFWLmZJ487982cKDUg1sbaPRSrrQQ4lm6ektzB4poNE7kkfLstB9LbxmEf0T_l_TtZ3ou64 kQK.j9jsQ_lm_wAgJUdR7b8_S0BKqh6t95ydTwouJ57jPDC5JqKTBzVXbT1fFIqyWJ8pSuO6r_ef 4p6uUPf0lkE3mmZltfbJfebCKonyHNuJllX6vGqsXvQZrFklBNUbpsmgEopVhH_fjAUd3TO.XkDm OkjKyDiNJ2mcORm3hOhfdzdX2L1vVHrazYaotT8TICfrasyifRbIy0HEGXkGaJRzH3GzX.yzkzC5 JSFFWd4ZwTJBaOuMW.oG5m0p8GjKKqtWxEJ1AuaINk6Afd2z3cAHBemgFngAmvma3xH2fgqHHTbc irFrKt5et.mhrGO9pMaimspfYwHoqqIAHoPVjtaPYy1y8oXII76H0PsVq6yZKRlgnOBsJnavEw.t 6GIVoFvVnOhKil5YKy7cy95WT8sEL39mEQXiJ89hi7s8ZUBJkqISIjfqishXEGNJNDgp6Z_Fmq7d csg2ug0Mf_9l56x9t4BmkywH3u1hlFNJLYrSacglNOwM.CgSAh1OPniR3fJxK2k.xkpCPrzVZShG etX6QFR0Ngkx5AcjzdpHen9VrHPVLqxO4MdcZJPhGvWs4Egvjoy1RmrZk12yge1FhUUIGERFv6wC pIXJmn1yEbv1R0khjyTE2tCyXMLgcPRHh77s27qdzbfQXGVWQJqRlgEUxM5I9QIYuGWaiJgNyv1x 66AhvaEOmb3xNsvm7F.y66ysrE96FT9jqySr9SC0eVZ19Kri3iE40Scr8RRzqo_l5suLMA4aoFK8 awzSJwvN85Zq29oFMFwm2vCpJ.b34iDRgbDlVNxsOzVzMD8eadcH8kyc64ZkZoKaZMIsFCy7UjwG tiu7C3bTrgf6WN8O9W8Zf60NxBjIV.zGT2zyUcEqWsmuDggl5NH2hg_KJbYLQLxSPRnh3izJHDCf xnHWydUXBrQzrYdrz8f8mUYzUVHU7p0055yWuXkRl7Jn_Lqd.ddsDzRBFus56XO.VYMqoo3BrvxB 8y46jx5n.Qt71CaOkZANoqv89u.bbix2_wg2jHEwNGW5doEkWoeqJDCwKtBuyjS8jRbClrb.7pxL RjkxCCrXB2NWYjwduOiLIvhKE56jcFNZWc_qRnG0q5ZUJGiou1ZVH4MyaX8BXJTHl8nZAxpxcKpM wNgsSQwcRlcIH5GM_HwuUkzaNu5ovq3UGhDel5eVo348tFN92iTlW1kpXztX0Y_rrBQtqaeHBP.R eyOMvBFRFv9vh8xMlfz5WBpw2ZTugANiAE2h8lcIxkoeLK8fM71qS1aAUvPThcfErZNPclVZfX3g AmDE2hzbiRiIfi6z_c48RzBwv.NtK3YYiiFb9MLn1w1RhVw2XU.KNdgxenfPWu6YKfGnLtXTrYA3 WtEeXBe4Wm9bsHTwqMrgQGTZsE1J6BEVyjgvjucqssE.L6pGuqqbzbI2cHApe0zhZKg9.oK2Ufri puAmAmVu0rOCqJC1bF.b0i7XKGurA_A6Qz8mWK1mMFdsK.3AjCzcn_mM6LPiOWAaYZWC1N89Tows xgi1HL4lkWeeSYNLvlI1CJyWO5ApaSjHs0GOb0I1Phu4CBOcLS9S956cynUc_1Boxa2C718ZY X-Sonic-MF: X-Sonic-ID: c6dc76cd-1d1a-469c-bba4-e490cb031aff Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Mar 2024 17:54:28 +0000 Received: by hermes--production-gq1-5c57879fdf-nxlqc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a8b0d63e0a6cc1c2bf033152f044abf; Mon, 04 Mar 2024 17:54:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Buildworld stops for d3befb534b9 in tests Message-Id: <72F038E6-64DB-4CCD-8C2E-AC76877F91EE@yahoo.com> Date: Mon, 4 Mar 2024 09:54:14 -0800 To: bob prohaska , FreeBSD Current X-Mailer: Apple Mail (2.3774.400.31) References: <72F038E6-64DB-4CCD-8C2E-AC76877F91EE.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from] X-Rspamd-Queue-Id: 4TpRCq4bCrz4SXy bob prohaska wrote on Date: Mon, 04 Mar 2024 16:35:52 UTC : > An armv7 (Pi2 v1.1) -current system stopped buildworld with >=20 > c++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [capsicum-test.full] Error code 1 There might have been more error messages at some earlier point prior to the above. Such likely would have more detail about what the issue was. > make[6]: stopped in /usr/src/tests/sys/capsicum > .ERROR_TARGET=3D'capsicum-test.full' > = .ERROR_META_FILE=3D'/usr/obj/usr/src/arm.armv7/tests/sys/capsicum/capsicum= -test.full.meta' > .MAKE.LEVEL=3D'6' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'c++ -target armv7-gnueabihf-freebsd15.0 = --sysroot=3D/usr/obj/usr/src/arm.armv7/tmp = -B/usr/obj/usr/src/arm.armv7/tmp/usr/bin -O2 -pipe -fno-common = -I/usr/src/tests -g -gz=3Dzlib -Wno-format-zero-length = -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k = -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wdate-time = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Qunused-arguments = -I/usr/obj/usr/src/arm.armv7/tmp/usr/include/private = -DGTEST_HAS_POSIX_RE=3D1 -DGTEST_HAS_PTHREAD=3D1 = -DGTEST_HAS_STREAM_REDIRECTION=3D1 -frtti -std=3Dc++14 = -Wno-c++11-extensions -Wl,-zrelro -o capsicum-test.full = capsicum-test-main.o capsicum-test.o capability-fd.o copy_file_range.o = fexecve.o procdesc.o capmode.o fcntl.o ioctl.o openat.o sysctl.o = select.o mqueue.o socket.o sctp.o capability-fd-pair.o overhead.o = rename.o -lprivategtest -lprocstat -lpthread;' > .CURDIR=3D'/usr/src/tests/sys/capsicum' > .MAKE=3D'make' > .OBJDIR=3D'/usr/obj/usr/src/arm.armv7/tests/sys/capsicum' > .TARGETS=3D' all' > CPUTYPE=3D'' > DESTDIR=3D'/usr/obj/usr/src/arm.armv7/tmp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm' > MACHINE_ARCH=3D'armv7' > MACHINE_CPUARCH=3D'arm' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20220726' > = PATH=3D'/usr/obj/usr/src/arm.armv7/tmp/bin:/usr/obj/usr/src/arm.armv7/tmp/= usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/usr/obj/usr/src/arm.armv7= /tmp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/ob= j/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/u= sr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > OBJTOP=3D'/usr/obj/usr/src/arm.armv7' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/local.sys.machine.mk /usr/src/share/mk/meta.sys.mk = /usr/src/share/mk/local.meta.sys.env.mk /usr/src/share/mk/auto.obj.mk = /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf = /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk = /etc/src.conf /usr/src/tests/sys/capsicum/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.endian.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.test.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/tests/sys/capsicum/../Makefile.inc /usr/src/tests/Makefile.inc0 = /usr/src/share/mk/googletest.test.mk = /usr/src/share/mk/googletest.test.inc.mk /usr/src/share/mk/plain.test.mk = /usr/src/share/mk/tap.test.mk=20 > make[2]: stopped in /usr/src =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 4 18:05:10 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpRSP1f7Yz5D325 for ; Mon, 4 Mar 2024 18:05:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpRSN12C6z4VF4 for ; Mon, 4 Mar 2024 18: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=1709575522; bh=bXzRFWYbjA80yZlUyP26txVPFk4SwIyCL0WuU+NLSW4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=R9St9QCNZwKHkkzLfw3VVQrs7ZaiuiTStj9r2Y0JFMDZowJoVGS4GafbFN6JHtvllRnapzCJplKoGhtVmaK3ejW805oNg7dsZN3UbzsuU89Um9b2s/S3nlLscD6ZAcGvzP1hwExSJCN699K73AGiVWSqU+rZc6gFSJq3Rr9vENvLjqpxuc9SorQB92YhUSBN1FTPaDLb9gmhlPocd5a3VM8WFHpax/fm6RmhoNxjMLsmDYzUzWHgEOxu9tJ5Hev/4gnI6GxNhkxZ/BA1B8g4tbcuABkhXHWdiqqAbzRSXm5j0jsEI5DbDMLIAZngUOJ3V+tBgWOQnI9f5eY5/iKA6A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709575522; bh=492cyLdRN+exyZayDoEyrx4XSFwuCHo54mMVHLb1NaZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kEb2ZheoFrvHRB+O/GOCErBZa+nuX9+twW3OUbk2QQHuz9C+2b0YpBQN6Q7nWiR0ndCu6sP+Bxe8dM2xrOKTMYGn246Mtj/Tk5q+96wROu2AHPorEfjhOk9LSuwrLA3VRi4RG2BPlbXzFHoE3YrSbDIg+/9X2xjEryut8fj9b3CrM+XbXtzTanLI18IrRghIx03UFjSg1wVQ3Zdm6Y9o/6c5n4LZORmBpReXz35tDi/prclNgRjHjXc5XSsXWxhIUDGjg4nKCReIU59A1/3FKYrQbP5mnt3QorJeQwASw1S+GbvhM45IZrrnAqV/rK87Jx+ng4T5SK87lUXyxXk8tw== X-YMail-OSG: FKRro5YVM1mjU5n0K.30Cfmh000RIL6_0m.TxGShBVeuXwXtmnn7EqyuBZ1CshS 8rzSCf1he6Ckl0ryQ73YGGWtxtff80aMQjxDHlJ4kkeBYi5gh9ewBnaMAxMhvCEHBGBwNOeYxS5a oL1FCI7FgoYzJ8njCt.Na8hxuQTATzeuIF2U4CZiqb0Cs_4a71lhA6XCvDajxGRcDigqIP2VdrDQ CZIc1Y3oy0XoKfXqf606B5uYKl.ei5JiVOQsxt9wLwIhTzLxv4wvFIrgUvdSaLCGN_AHFFBQQgUr WX7eNqDGOefyJVg0GSaOI0RlnV5UKuCaJOStaPMCWuZuah.K_8Z2vPSeIwAF1tqvXRIBM0d77rME YI3A2_Y.7YUkneV1aZNra4lIr1a0WpFr4igWm15Jd8jBQd91yG_GKrEzh8DBJSO1XLawVwvHQ7hg r4XoPeZlfvEuWBh_y8uXRjgI1a_Qv_CpfAd4iaxiC9asH3no0mxoHl4cQAB5hipZNCT5pcU6RYuR L84wJNHedmWvKb9luU3kHxmhRjW4elEMyMVFTwDYNf1yLNbFBm2HotHxQYefbFUz6xENDS0nkJ9N rmiGmgtMQgBPtGXTQrS1eoFcVHw4EUNoq.m0WoEbWdAT7y8Fg8TN6JJ9DB7RnWmfPGe3K_5K8dYA KwBQtgSKxW9O5jXAobZ2T1klPYtDNV__UTB0pnrnNSENzac.XvnpKcogd1122ch7PQAg6yW4MTbf afaefT8dRS3_2D0xh6XyWjC02V.1B0I9xIcPjxB_63rOJnSW1dix0KTEuofFYsqFnCvllz0drS9u fv7YsElk8MR4DQ.tac_y86wvEI6AGUqksqszokE5pEqPU0EA16EYOnWbVhuTkzjCpXCqA6IUrqZC g3jZogNpE1Zz8LDVWTJ7.AUqAGcTL.TmWb.fH85mj0bXRRuF0AmYQBjj_3qtEbfwYwIVW_tVVl72 4StRbdkXCVKgk31VKzuuUltaD6jucv2Kgbf68KiKgucOV1I5P227l3PEnqnT.bv25BZ.tYMEkBGc .FejRJ.8NWv3qS907vTu0JHuiMgYWrKn6oX5fnmh2.bOI8sDNLT57OtEMePOge8goIbpekzUYpbZ Adh82ZTHd7GyNAafkbUrVoxY2qo7CkngDrwWbBa0hpCa8njyGonIe95H3ywwcaCTY0s.HQHehpx3 u6Z1H1_T7vXgSoFdKVabj16t1pYrjpF9elaCCw2YvknWvDYKPuaNFpsW09Be5a6HutRYL_ULFolS MqDF1fqcjuKxNYCeeBgz7b2ZxgEecVcvF7R98VdjmCpme8UoB7VzS8g0Gxy2Qr0EcVbRE3kWUA9N 6bcb0UpqVWUihpVcXrB2_MfSGP6280GP2R.I4Z349VTU6SLVVwYtho_Qbs0vIBHNPpSwRJw588Qq 9umFyWKRJPfHu4zvXqIvmj5FVXF8F5dqGz1vfa1DLDz1HXnUZMwetRPDGawnc44_JoMO5eeacfOR XHveL0c3TR8tnO2iqDSAVdubzkfqJIr.2Kgx8vPRCNcmDHVZP76CyFEEYu2cXAkNP8VguRKrne53 OlUC7J6WudqbQ8iIw4xCZG.5wS8y4d2Te6PSuxeTTwIsKsu05bH5WCuBZ42ea31gIKXLp1SIWPDR 5d_a0P8pJYYw0rYw_EtpslitW5qJIdJX9JsvgnDV8JatonfTQqkC6JsWLE1t4JqdeJKPS1FcuDoo vKSfbGKYJuSCqrJrL03zHhrYgoL3Ho3CqiGv.nuheB14VKnJxbfsRqyhu8K8hc.43SYtrv4L_NZV 79pBFVN4euSn.th8ye5iD5UU0KLP8seG_YX_0XEL_Rdl.6F2y78Ap78MS6citnB5.gPs2b5ty9zG B_oDiR56HYu4iZ38zh5BRrPl6fgAAKClw7NQj5PIZs585sYZHFNg9aN6hSIHrAe0adTSWNIYhCTY MhkNeUtSZ7iYVme2MnJvODKgHzJ43qfxN2Oj3YfMeIg38f0If_i4YSp8KjzwslLSQ0JwSG4igOBO BwpXao7yho32DQTCugp0ACpmckZNryWZuUpdKkZrgO0jgCeSJNTuhpUQbKMDwmzZAINvNngd2bmW yTYvJYzoYx0GaMlSrHh3bdPsGUfBUU4N9AcEoZ_2u5ggmCJ7qYJD7Y2aJHiEtUOvD0VQf2S2uaQs uX2DZJBbgWP1_DzpnebHxof6aV1T9cd.blfoIglkQbYRt6wZU61XH3soPvdYKNj3Pr7HZ.CAXb4I 8R18l303W8cQJ24g9h9qioRc5tRSwKGcsr_bhHmLX9B.wKD69LnowyE1RXBAHNPU6s9dzfDb7qA- - X-Sonic-MF: X-Sonic-ID: 68101c13-d263-452b-9789-52227d2e6dd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Mar 2024 18:05:22 +0000 Received: by hermes--production-gq1-5c57879fdf-wt62k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 06cccb68d1b606129cc27c743747f2c5; Mon, 04 Mar 2024 18:05:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information From: Mark Millard In-Reply-To: Date: Mon, 4 Mar 2024 10:05:10 -0800 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> To: Jakob Alvermark X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4TpRSN12C6z4VF4 On Mar 3, 2024, at 23:25, Jakob Alvermark wrote: > On 12/4/23 09:16, Mark Millard wrote: >> The following sort of thing is happening a lot: >>=20 >> Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically >> used on occasion, sometimes for long periods . . . >>=20 >> Example contexts for the issue have been: >>=20 >> FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 = 18:17:40 PDT 2023 >> and: >> FreeBSD 15.0-CURRENT #131 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 = 16:53:33 PST 2023 >>=20 >> Both UFS and ZFS boot media, here part of a ed31b3f4a146 UFS example = is shown >>=20 >> Nov 29 18:26:27 7950X3D-UFS kernel: miibus0: on ure0 >> Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: PHY 0 on miibus0 >> Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: none, 10baseT, = 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, = 1000baseT-FDX-master, auto >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: on ure0 >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: Ethernet address: REDACTED >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to DOWN >> . . . >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to UP >> . . . (no ue0: messages, then) . . . >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 2 link states coalesced >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS dhclient[53725]: New IP Address (ue0): = 192.168.1.157 >> Nov 30 03:23:20 7950X3D-UFS dhclient[53730]: New Subnet Mask (ue0): = 255.255.255.0 >> Nov 30 03:23:20 7950X3D-UFS dhclient[53734]: New Broadcast Address = (ue0): 192.168.1.255 >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 3 link states coalesced >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS dhclient[53771]: New Routers (ue0): = 192.168.1.1 >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 3 link states coalesced >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 2 link states coalesced >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> . . . (lots more) . . . >>=20 >> Other FreeBSD system on the Ethernet are not getting such but none >> of them are currently using such a dongle. >>=20 >> Note: The ASUS X670-P WiFi board's built in Ethernet is not >> supported. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 > I see the same with my Lenovo dongle: >=20 > ugen1.12: at usbus1 > ure0 on uhub6 > ure0: on = usbus1 > miibus1: on ure0 > rgephy1: PHY 0 on miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 I've no had the problem since somewhat after my earlier list submittal. The timing would suggest that the change was tied to my moving things around and reconnecting the ethernet cabling afterwards. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 4 18:26:35 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpRwq2Zfvz5D4Fv for ; Mon, 4 Mar 2024 18:26:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpRwp6JvLz4YG7 for ; Mon, 4 Mar 2024 18:26:34 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 424IQZwb036357 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 10:26:35 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.17.1/Submit) id 424IQZnO036356; Mon, 4 Mar 2024 10:26:35 -0800 (PST) (envelope-from fbsd) Date: Mon, 4 Mar 2024 10:26:35 -0800 From: bob prohaska To: Mark Millard Cc: FreeBSD Current Subject: Re: Buildworld stops for d3befb534b9 in tests Message-ID: References: <72F038E6-64DB-4CCD-8C2E-AC76877F91EE.ref@yahoo.com> <72F038E6-64DB-4CCD-8C2E-AC76877F91EE@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <72F038E6-64DB-4CCD-8C2E-AC76877F91EE@yahoo.com> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4TpRwp6JvLz4YG7 On Mon, Mar 04, 2024 at 09:54:14AM -0800, Mark Millard wrote: > bob prohaska wrote on > Date: Mon, 04 Mar 2024 16:35:52 UTC : >=20 > > An armv7 (Pi2 v1.1) -current system stopped buildworld with > >=20 > > c++: error: linker command failed with exit code 1 (use -v to see invoc= ation) > > *** [capsicum-test.full] Error code 1 >=20 > There might have been more error messages at some earlier point prior to > the above. Such likely would have more detail about what the issue was. >=20 You're right, I missed the start. Here it is: Building /usr/obj/usr/src/arm.armv7/tests/sys/capsicum/capsicum-test.full cc -target armv7-gnueabihf-freebsd15.0 --sysroot=3D/usr/obj/usr/src/arm.arm= v7/tmp -B/usr/obj/usr/src/arm.armv7/tmp/usr/bin -O2 -pipe -fno-common -I= /usr/src/lib/libarchive/tests -I/usr/src/lib/libarchive -I/usr/obj/usr/src/= arm.armv7/lib/libarchive/tests -I/usr/src/contrib/libarchive/libarchive -I/= usr/src/contrib/libarchive/libarchive/test -I/usr/src/contrib/libarchive/te= st_utils -DHAVE_BZLIB_H=3D1 -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D1 -DHAVE_ZS= TD_H=3D1 -DHAVE_LIBZSTD=3D1 -DHAVE_LIBZSTD_COMPRESSOR=3D1 -DPLATFORM_CONFIG= _H=3D\"/usr/src/lib/libarchive/tests/config_freebsd.h\" -DWITH_OPENSSL -DOP= ENSSL_API_COMPAT=3D0x10100000L -g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-= length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=3Dunused-but-se= t-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-eq= uality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/lib= archive/libarchive/test/test_archive_pathmatch.c -o test_archive_pathmatch.o ld: error: undefined symbol: testing::internal::CmpHelperGE(char const*, ch= ar const*, long long, long long) >>> referenced by procdesc.cc:199 (/usr/src/contrib/capsicum-test/procdesc.= cc:199) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) ld: error: undefined symbol: testing::internal::CmpHelperEQ(char const*, ch= ar const*, long long, long long) >>> referenced by gtest.h:1502 (/usr/obj/usr/src/arm.armv7/tmp/usr/include/= private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) >>> referenced by gtest.h:1502 (/usr/obj/usr/src/arm.armv7/tmp/usr/include/= private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) >>> referenced by gtest.h:1502 (/usr/obj/usr/src/arm.armv7/tmp/usr/include/= private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x64b138 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x64b138 from unloaded dso, skipping Building /usr/obj/usr/src/arm.armv7/usr.bin/mandoc/mdoc_markdown.o =2E... Thanks for reading, and apologies for the omission! bob prohaska From nobody Mon Mar 4 20:00:49 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpV1k2yPFz5DBpj for ; Mon, 4 Mar 2024 20:00:58 +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 4TpV1k0DY0z4jpp for ; Mon, 4 Mar 2024 20:00:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 860778929A; Mon, 4 Mar 2024 20:00:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.18.1/8.16.1) with ESMTPS id 424K0oZX083668 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 20:00:50 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 424K0nnR083667; Mon, 4 Mar 2024 20:00:49 GMT (envelope-from phk) Message-Id: <202403042000.424K0nnR083667@critter.freebsd.dk> To: Mark Millard cc: Jakob Alvermark , Current FreeBSD Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information In-reply-to: From: "Poul-Henning Kamp" References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83665.1709582449.1@critter.freebsd.dk> Date: Mon, 04 Mar 2024 20:00:49 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4TpV1k0DY0z4jpp >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x0000, 0xffff, UQ_CFG_INDEX_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 Mon Mar 4 20:13:13 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpVJQ0rbXz5DD9J; Mon, 4 Mar 2024 20:13:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpVJP5ZVFz4lmT; Mon, 4 Mar 2024 20:13:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-3c1f55ba3ecso451001b6e.3; Mon, 04 Mar 2024 12:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709583221; x=1710188021; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=XPl5u1IxpWVs2bv5Jo1UAXSO7U3+o9CGzALaAUnGlFc=; b=jV9GaIuh7/wgrVAX9i99q74vNo4fVZS5Q3m6GQiwcoOr8S7+tsgqKVnO8BdLnJL4ox yYqgxiebuCafDiUBJBDhtV6cppTnjH8L7OdwBrJ/rlVLoI7+AIu+Xl51VycYO0fT5k+/ kLLJYtSxkxDXC9JDp79YEcgDFBNj/Pau2qCZuIJvwPiBRX/RLDgClIbcaDehDo9Bboig f6rABy5g4K0wH5/ZfD0EUEKphWtUm6pwnghXUY6wdfpdO7GRv36m0IQhWiBzAwen0KOu +XI+PP9EEToQtQdBdewKw46iffMak6pCtiu/NFBNjsc2iKgdBO5T2Ko31SnKD1wXcumn WOTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709583221; x=1710188021; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XPl5u1IxpWVs2bv5Jo1UAXSO7U3+o9CGzALaAUnGlFc=; b=tH3ZGVOjXT40av0PI/6fpUQ7BEE02bkR98U3rc3uq8XyIjP+lSTlCEidVPMb2EByQZ NJEWDmZwMP2L1xUrVwaGbTun0XFKuhbUKofh3LACdpJbEwuqpoiCf3bc/srMlIiJdyPb Y0WxQQ0ap/qbCGMAmcPgJrahXZjSX6Nl1/1c/751CP36ERdfXDLsbB8wWH5naLuHvKVp JoY6e6US5cPExpEz+fOhWtp0ge9mGtdENmJYZOgGIRIQjgECd6bmZe37xSao4gkcEiHe DmsyssQPCPPAv/jUWBVQGBvIEFbX/s46WTxgC6kfjEz26rir8TO0PsB1qchtvt4P1Xux 3uCA== X-Forwarded-Encrypted: i=1; AJvYcCW/rvh3MSHQk1OCoRUbKTVjoybZAofaEUj7/RN0j5QKJGUeF7SRs6n9ilfsjaL/+Kn8qT+DP8JEOQEFWLdFXB6GXOk8eeIEidfwCs4SF5gtPhcTtNfs4bXbpl0dwunC3fBstBFs X-Gm-Message-State: AOJu0YxLl7QKbXD/hch+qo7KyX1Tum+vOiEdKXfvHw//YmM2uwfrAxOD 2TDri4OEC4jsSanVqbF8L3oMnFWgafAvquzN1T5TB9YgUgQm0aKM X-Google-Smtp-Source: AGHT+IF1T8ArGDLV5jtlp5FnGhJ7UBvUmjCbzHMljWhXNTL4tCR2kJKXpsmnOPEpac6G6haNGrKarQ== X-Received: by 2002:a05:6870:a18d:b0:220:847a:14e2 with SMTP id a13-20020a056870a18d00b00220847a14e2mr11293477oaf.46.1709583220744; Mon, 04 Mar 2024 12:13:40 -0800 (PST) Received: from [10.230.45.5] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id gz14-20020a056870280e00b0022008c33ee0sm2591541oab.36.2024.03.04.12.13.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 12:13:40 -0800 (PST) Message-ID: <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> Date: Mon, 4 Mar 2024 15:13:13 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Poul-Henning Kamp , Mark Millard Cc: Jakob Alvermark , Current FreeBSD , FreeBSD-USB Mailing List References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> From: Alexander Motin Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information In-Reply-To: <202403042000.424K0nnR083667@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4TpVJP5ZVFz4lmT On 04.03.2024 15:00, Poul-Henning Kamp wrote: >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP > > I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad > Thunderbolt 3 Dock MCU", but they went away after I forced it to > use the if_cdce driver instead with this quirk: > > /* This works much better with if_cdce than if_ure */ > USB_QUIRK(LENOVO, TBT3LAN, 0x0000, 0xffff, UQ_CFG_INDEX_1), AFAIK it is only a workaround. I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it to one queue and some other hacks. IIRC if_cdce just has only one queue and other limitations, that not only makes it more stable, but also much slower. It would be good to understand what's wrong is there exactly, since IMHO it is a big problem now. Unfortunately HPS was unable to reproduce it on his laptop (that makes me wonder if is is specific to chipset(s) or thunderbolt?), so it ended nowhere so far. -- Alexander Motin From nobody Mon Mar 4 20:33:06 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpVl13zTPz5DFH4; Mon, 4 Mar 2024 20:33:17 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4TpVl11vLzz4pTN; Mon, 4 Mar 2024 20:33:17 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; none Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1rhExk-0008iD-04; Mon, 04 Mar 2024 21:31:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=R0GWLAECAHTwG0mqQb+NTB031gfBJ4NU7UcO9wh83GU=; b=nNm8gAXLES8ReS41lnanwVD8gl FgLX6WPKbh1HUXONjVvOmLlZ2u9FDU+Y7Q7JMsWWnlMutzzSCDlC2y3SToj5UZPA+vWqnlLoDCmIp Q+L5ipviwq1TiWwiUUu6TDTF2p0EWWtPYiq6XYlwg/MOz7btHSNN5NUS7pRrEH1LbfkWLVD+aEYEf yJAv+ePGNjth0Fh3AjnfyDIjUlrEEa1keK0L0yuNqk2h5uSUyatSMZyvCu5GE5n5g5xf7ymJCr3JA r2kbiC6kHZxMQDvTkuZVlqM+yG/jV0Mq+xNXmCWO26ccQkRz4+Gze0nLJe+poOdh49YHJPwZrcipb eCWNkcJQ==; Received: from [192.168.67.48] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1rhEzj-0000fM-8N; Mon, 04 Mar 2024 21:33:07 +0100 Message-ID: Date: Mon, 4 Mar 2024 21:33:06 +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: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information To: Alexander Motin , Poul-Henning Kamp , Mark Millard Cc: Current FreeBSD , FreeBSD-USB Mailing List References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> Content-Language: en-US From: Jakob Alvermark In-Reply-To: <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT] X-Rspamd-Queue-Id: 4TpVl11vLzz4pTN On 3/4/24 21:13, Alexander Motin wrote: > On 04.03.2024 15:00, Poul-Henning Kamp wrote: >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> >> I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad >> Thunderbolt 3 Dock MCU", but they went away after I forced it to >> use the if_cdce driver instead with this quirk: >> >>          /* This works much better with if_cdce than if_ure */ >>          USB_QUIRK(LENOVO, TBT3LAN,  0x0000, 0xffff, UQ_CFG_INDEX_1), > > AFAIK it is only a workaround.  I saw it myself on number of different > USB dongles and laptops, that USB starting experience some problems > with multiple NIC queues and some other factors. IIRC the Realtek > driver was much more stable once I limited it to one queue and some > other hacks. IIRC if_cdce just has only one queue and other > limitations, that not only makes it more stable, but also much > slower.  It would be good to understand what's wrong is there exactly, > since IMHO it is a big problem now. Unfortunately HPS was unable to > reproduce it on his laptop (that makes me wonder if is is specific to > chipset(s) or thunderbolt?), so it ended nowhere so far. I have a Lenovo USB 3 dongle, so no thunderbolt. USB ID 0x17ef/0x7205 rgephy1: PHY 0 on miibus1 I tried using the cdce driver, it gives me < 100Mb/s, while the ure driver gets > 500Mb/s Jakob From nobody Mon Mar 4 20:39:39 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpVtx5nGdz5DFtW; Mon, 4 Mar 2024 20:40:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpVtx43K1z4qjH; Mon, 4 Mar 2024 20:40:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-21fd278aa74so2915028fac.3; Mon, 04 Mar 2024 12:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709584807; x=1710189607; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=udVaEEgECnW+wHpyXpjUR4VNP4SBoZ7kmzCOavO23Hs=; b=lnA6yLliUggNA7AXxnztxmNQ9SdBGb7npLrRPAetIRzZbr3OnRVqWjNXCDLF9Qztkf 8/mmuszSSQsAjW95RdmGohaclq0Zl7yKJTrfsK+uqEt4KX+04gAA25lBtzpJNtYhPck7 Acz+IvfYgcogxVcF6YcU57nYDCecd/J6Hh0X8ZdZ9mLUksNlAX0DPrY2GC7F52GW984w pn6lv1/rBj2KC1nXmR8c7Eb7JPBL1O4gsiOgeduWU6t5zYoGFKp0Uy8nxjuHFNKoJzPb iRotLt1jheKBnBjyWkmoF5iRIt2x3knGuwOCyWCv/U6AT17O8M7pMvuaEpqxr+uifgT6 wENw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709584807; x=1710189607; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=udVaEEgECnW+wHpyXpjUR4VNP4SBoZ7kmzCOavO23Hs=; b=oGjgEM3tQZdXahZmsweAiTNZi++Jh7oA+14XgYCrnrlwGYnHDWneHsMP319Bw6Lrnu ++O9vxqf00uetRXCDv3Z2f9vV25mgqv2kFashOlydAHiIIyfEL9J8N3ujBibR4t0VqAA 2SbktxQGf+he1Ofx8r4ZSbOzpas1/xuFW+T3hrmhxKMpkZqrPy6UyKEFc3w1MDfH2XqM 1YI/tAQAMCM/eLMPgGF2mSYHuELM3Dj9AO075eY0tvyDMbhKEVZ1jU6g0Rgsbjzg5Imw RQCXP/UiO3bPaBR/gcAMbzdPAJ2B5YA5Z3FVte6iGXnd4EtlSzGa4xHPvxPp2OIMISW8 IByw== X-Forwarded-Encrypted: i=1; AJvYcCVq0R2SQv4LzKc8L1OdfJcms0XBkvTUA8K7kEv2dNCGS2glZgaQ6rrYIUnhNgpd0eoPyo0/q7sOAvTWcsTztiKxwoyRrL+k1g== X-Gm-Message-State: AOJu0YwgA023qSt6MLtuvz4UiGpDlWNHd9wNAlq1U9Rcq/qyalK2uO6J AhSBduCwJv+wVd4TTetQYByqQcZw9KKiH9Xp0DcQkiXfjsOreEmxlF69OrcT X-Google-Smtp-Source: AGHT+IFL7/ptt7zhh6VDsrqG0xVld2rKKS7SMacutY/1jTed9mNp7xTU+OckSYM80K54UhbbN+Y3Tg== X-Received: by 2002:a05:6870:c6a0:b0:220:bb45:21b9 with SMTP id cv32-20020a056870c6a000b00220bb4521b9mr11664609oab.6.1709584807371; Mon, 04 Mar 2024 12:40:07 -0800 (PST) Received: from [10.230.45.5] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id ns7-20020a056870ac8700b00220a0b057f4sm2303940oab.10.2024.03.04.12.40.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 12:40:07 -0800 (PST) Message-ID: <87db86a3-55a3-7d55-63a6-0058e0f98c2b@FreeBSD.org> Date: Mon, 4 Mar 2024 15:39:39 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information Content-Language: en-US To: Jakob Alvermark , Poul-Henning Kamp , Mark Millard Cc: Current FreeBSD , FreeBSD-USB Mailing List References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Queue-Id: 4TpVtx43K1z4qjH On 04.03.2024 15:33, Jakob Alvermark wrote: > On 3/4/24 21:13, Alexander Motin wrote: >> On 04.03.2024 15:00, Poul-Henning Kamp wrote: >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>> >>> I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad >>> Thunderbolt 3 Dock MCU", but they went away after I forced it to >>> use the if_cdce driver instead with this quirk: >>> >>>          /* This works much better with if_cdce than if_ure */ >>>          USB_QUIRK(LENOVO, TBT3LAN,  0x0000, 0xffff, UQ_CFG_INDEX_1), >> >> AFAIK it is only a workaround.  I saw it myself on number of different >> USB dongles and laptops, that USB starting experience some problems >> with multiple NIC queues and some other factors. IIRC the Realtek >> driver was much more stable once I limited it to one queue and some >> other hacks. IIRC if_cdce just has only one queue and other >> limitations, that not only makes it more stable, but also much >> slower.  It would be good to understand what's wrong is there exactly, >> since IMHO it is a big problem now. Unfortunately HPS was unable to >> reproduce it on his laptop (that makes me wonder if is is specific to >> chipset(s) or thunderbolt?), so it ended nowhere so far. > > I have a Lenovo USB 3 dongle, so no thunderbolt. I also use USB3 dongles. But in my laptops the USB 3 ports are provided by Intel Thunderbolt controller, while in HPS' they were plain from USB3 controller. Though it may be just a coincidence. > USB ID 0x17ef/0x7205 > > rgephy1: PHY 0 on miibus1 > > I tried using the cdce driver, it gives me < 100Mb/s, while the ure > driver gets > 500Mb/s Right, I saw about the same. -- Alexander Motin From nobody Mon Mar 4 22:49:09 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpYm51nhyz5DRZ3 for ; Mon, 4 Mar 2024 22:49:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TpYm441Byz4612 for ; Mon, 4 Mar 2024 22:49: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=1709592562; bh=vHK/rR2nY5OaYOaiM/n4D7xT5tDfHPYPRw3/LtWrs2I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G9mX7YgAG/xbHB/3yzI5XskJ0GhYAWNFdI9QOulfGfFADOWxdJ/QDOB5Q1IUPNp1l6DL6MCpFGj9h7uJWrGKrULqvFE4MnpOirq2UWoCkM55R3Udh2YFHytv8EKxg8S5qL4TiAFkJIo2bh+pO/VPWDIAp5Yf1Hl0cDPLuMxKIICSr2ko0LZChMMNyeKMw8+7yxOHNYYxpiQJDBRf9KL1hyii0TIXAqLrp1xInxXHiAACITJTz+3Q2lss5p+QYC68l9uKryJnLd07WSOt6xRT9A0/m3Ry0wqUX+nkmh7VGmgRpebRH1I53SR2G6NbBs2xpl7XaonHFbPW34FU/6XI+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709592562; bh=v43QGk270d4AR3jTqR6FlWjvAF8kTVwyoBoFM5KcUaW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DC8Nq1w3xgtjHqLU1v9eXzxBGxEj8PedJ2n05eYf0HkmkkCDVsY3ITJqjQ970e5zT/mXb5hk5A6xZm7mJY2YWEJ0KYc4VClnHQhcliBks+e1XU4xuhR98QQ0JpcuWsPrxQtJ+knv2K17SuBicGYdCChoPLJHCPVpB7QklK2gGcqyQe1qC2PQLOqMKSXTzPPfDSpEg9y9cjbIIAzU1lyVLwuxDMkYO4LhnVN8xn7JyHY37ZFp4ki6MFZtGF82pzDC139/YGJir8St9ZwpvmGtAc4FLV725RJlPeLDbPCuza0bnpWV/4v7HQ8B7OhdQXL7/q8ubAhsA0TN4J54/Zhsng== X-YMail-OSG: VZF76s0VM1lfb6nF5T4_DAXmSY0mzFYTd3cTKF5yf9WhYAwlxxc9i2Jrnp67ZJO 1jJeCKO0s8ImjCnvKkTpFpjHq9dns2CIMPhyHM9ZSaYecY6E.e3Dv0bMYGK9PPv.NpN2xb9izca4 NnuYWljyYFqd3CjK8KntgiFFN0UtQZTTPDk944OHc2LedCIhriIViJZ4nyDwqG3GpWYuWrasUNqW xc54wDJTHYDz9IjRtsqXJIoe5w7BZpyi0AkZHuv22hVRWWlEx5Ho4NTuomrs1EtBaTB73zgUYV1o pL5Eoozx2DmZB6QiiIAMYQTqVg.qgqyc2P4i2qsSP1DID6edFUuPs3anJL80PI3Qn6Vo2OvXKaEm vK2uLW9L0xbtIGDpXInDr8dRurob8IhsMUiof3koUPYvayjpefHNtrvrqeUjlcg2CA3UGTLXFexD TK34lVjZM_N_POeLScZGqM15CXQVx7gYmZGYdepxt080Dj9krP9.9F2auY15diyBGJm.mcWcCeNw HLuox1ZMhZW64hBBjphGunF.mKdIVk3RZnlYilylpW2_jdgs8bVPHbskDgQJl4pONNtKeKMp6CdM m.ONI3rUxjlK5lUNGIAv_BuRiNAKe9u2G66EB3nPZ9zE2tGHDcm9B1a1pgDcoFpaumahDdoHvODI w7qUyByl60LwRPmYOG4W57UclsXXzeykX1lQwjWAA_2MpQNy_H9jBYI2sLSYCg5TLJn_ZvRecD34 f6jdqM_XNSnsKTuKk0JV3lWANoOAQOxPYkNIcKjJ4h.kZbYvJZhXMbDVIV8zvmqppemLsOIoaijf hNK3kHy74X8q7KffYxNdXIzngFrtE7phoS.zLPN4Ek1McyW8Ja36KeLilSx8hFZcujs4GzJ4NaPY Q.liSz0hMHG7HL6Xz9l5o2Z8OLpdVPOXeQo_pfF106Lv6M0o4YgZ2NDm6uCq.VbrPAtqM5IFfJn6 Pg7QWMwQ0TYYDgi5UyuCelJZxyhSALWlk3fK3LBs8X.gK6IAq7V3nIFeQHI86LIcC.tmG8r7FRFD Xmpn4tMTpt6NIoy4OsnYQpP46nKrxgd5KXHymIrik7rwgZ0FSqyHYBGdCy.6abGD4PBHKogs9pUO 4KXaptd7t5j5LdhZnNT69RFs6Nfhw207KXsVzD3rVMhXg4dbxYS6pZOPRLDl6FHyv3xry8IHBbsG cMTCzLtvYgkw0ama3DTDmJVjbSSE9nIx4MawNwuqTZ30k_A4BCZtxvATiRJwEMafQUprMlyObkXF 5h5BGa7ZboNBY03UCoau9jqJx1H46anTb_tZ5jwwulbMasRjLNCNmYKg.mTEkMyhvHU2KZihQ4Vk 8WZkuaf.dQX.9C_oIkjxeh5rQ7gv1tiN5HIs_NAPYUZufc.7rKYnnnBbw0R5ic2PfB4mG4VZdAJP 84UH3hgi0K5LFyncCVAJ8XCYdpKSw9Jcu3Qqk.50zKwybcuKbEG2kyGzHsDLF3xKJwj_7Sd0awuu 8jCdn1O8tQ0j1XB7IP6DbS0wWHjdL9oDd6ryNAm23YhSKaxY_Z27Z5C.C_JA57MFWE2YQQVzDyn_ 7TYq_3G84KR8tNM0Q3CqhfqjgVvrFJs6vPB4lsbb0SkfLDZoJY_1EkNv0Fh4GUBVIUfFRahelD2z C.kX1iqsJ6hO4yPwSawxckxdL4gZOAGLFVYD8TT5NIyG9bT6QdzXT8l0TvtegRZR0zuIYfeqM9id UeNwB05fSIvPJF9TAMtx1sBrfUqWdm2CeqnezsPBLtpjHdjckYeo1.zeJyzvzg8cyHw0_CUb21w_ _xaUjCKzMnN3mi4Ujr2t13.la3.HLwHCGI6lQX42jxdpktZ4QPQUAYykGy5rtsxGlVOUtI8A3FyK 4NfgPjVGaRYl8afKdj54pRDXKvWNxN7RKaykkaq9f8YMCW4grZt08B8z7ebiq34.b4BsPk6yzcp3 YKNVx3gbKdrvLoQv5ZQ.nt6SYXlY0CmqBwZGZtNf0yDPvGxQADEQKXEjJpmw9srmHk3xcjgTWz4x b.nK2_49F1LzWgLFCMU_7_Z7u0VDtZunWeg8wM.HRhO1jRTrS6uv9G47MlTq1SQo3FiD6Frr7Tkb 4mTPkddTaPfhXJJTvjyRTE4371tvv2xg3GEySVGfjyphh7MTCC8RDcaDQGjsqZ4aeG0oXG3vl3y0 DCFHxG7gajzFz6aB1neJArUHIW8T5PIgG9WDPPoLkmx16E35vWEcIb18D.Ozqs16qZlvARM.djIJ 1pWxq.jKWycJf98bB7jU6nDQlGazOZKnl26ThHTnmyIhaVi3YfJTTGnWPkkQoxA3LUkLR52qGzrd _ X-Sonic-MF: X-Sonic-ID: 929a8fb8-c5a7-4a40-818d-76b437581f14 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Mar 2024 22:49:22 +0000 Received: by hermes--production-gq1-5c57879fdf-4h5cs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 57ae5c409700701e5a8057cd0d7e3b3e; Mon, 04 Mar 2024 22:49:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information From: Mark Millard In-Reply-To: <87db86a3-55a3-7d55-63a6-0058e0f98c2b@FreeBSD.org> Date: Mon, 4 Mar 2024 14:49:09 -0800 Cc: Jakob Alvermark , Poul-Henning Kamp , Current FreeBSD , FreeBSD-USB Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> <87db86a3-55a3-7d55-63a6-0058e0f98c2b@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4TpYm441Byz4612 On Mar 4, 2024, at 12:39, Alexander Motin wrote: > On 04.03.2024 15:33, Jakob Alvermark wrote: >> On 3/4/24 21:13, Alexander Motin wrote: >>> On 04.03.2024 15:00, Poul-Henning Kamp wrote: >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to = DOWN >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to = DOWN >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to = DOWN >>>>>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >>>>=20 >>>> I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad >>>> Thunderbolt 3 Dock MCU", but they went away after I forced it to >>>> use the if_cdce driver instead with this quirk: >>>>=20 >>>> /* This works much better with if_cdce than if_ure */ >>>> USB_QUIRK(LENOVO, TBT3LAN, 0x0000, 0xffff, = UQ_CFG_INDEX_1), >>>=20 >>> AFAIK it is only a workaround. I saw it myself on number of = different USB dongles and laptops, that USB starting experience some = problems with multiple NIC queues and some other factors. IIRC the = Realtek driver was much more stable once I limited it to one queue and = some other hacks. IIRC if_cdce just has only one queue and other = limitations, that not only makes it more stable, but also much slower. = It would be good to understand what's wrong is there exactly, since IMHO = it is a big problem now. Unfortunately HPS was unable to reproduce it on = his laptop (that makes me wonder if is is specific to chipset(s) or = thunderbolt?), so it ended nowhere so far. >> I have a Lenovo USB 3 dongle, so no thunderbolt. >=20 > I also use USB3 dongles. But in my laptops the USB 3 ports are = provided by Intel Thunderbolt controller, while in HPS' they were plain = from USB3 controller. Though it may be just a coincidence. To my knowledge, no USB4/Thunderbolt controller is present in the PRIME X670-P WIFI system that had been showing the messages and no built-in external port is an example of such. = https://www.asus.com/us/motherboards-components/motherboards/prime/prime-x= 670-p-wifi/techspec/ lists for USB: Rear USB (Total 10 ports) 1 x USB 3.2 Gen 2x2 port (1 x USB Type-C=C2=AE) 3 x USB 3.2 Gen 2 ports (3 x Type-A) 4 x USB 3.2 Gen 1 ports (4 x Type-A) 2 x USB 2.0 ports (2 x Type-A) Front USB (Total 9 ports) 1 x USB 3.2 Gen 1 connector (supports USB Type-C=C2=AE) 2 x USB 3.2 Gen 1 headers support additional 4 USB 3.2 Gen 1 ports 2 x USB 2.0 headers support additional 4 USB 2.0 ports * USB Type-C=C2=AE power delivery output: max. 5V/3A For Miscellaneous it lists: 1 x Thunderbolt=E2=84=A2 (USB4=C2=AE) header But, as I understand, it has to be tied to a PCie Thunderbolt card. For reference for the 7950X3D system: # pciconf -lcv | grep -B4 -A16 "subclass =3D USB" xhci0@pci0:11:0:0: class=3D0x0c0330 rev=3D0x01 hdr=3D0x00 = vendor=3D0x1022 device=3D0x43f7 subvendor=3D0x1b21 subdevice=3D0x1142 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' device =3D '600 Series Chipset USB 3.2 Controller' class =3D serial bus subclass =3D USB cap 05[50] =3D MSI supports 8 messages, 64 bit=20 cap 11[68] =3D MSI-X supports 8 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x2080] cap 01[78] =3D powerspec 3 supports D0 D3 current D0 cap 10[80] =3D PCI-Express 2 legacy endpoint max data 256(512) RO NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 0018[160] =3D LTR 1 ahci0@pci0:12:0:0: class=3D0x010601 rev=3D0x01 hdr=3D0x00 = vendor=3D0x1022 device=3D0x43f6 subvendor=3D0x1b21 subdevice=3D0x1062 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' device =3D '600 Series Chipset SATA Controller' class =3D mass storage subclass =3D SATA cap 05[50] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 01[70] =3D powerspec 3 supports D0 D3 current D0 -- xhci1@pci0:13:0:0: class=3D0x0c0330 rev=3D0x01 hdr=3D0x00 = vendor=3D0x1022 device=3D0x43f7 subvendor=3D0x1b21 subdevice=3D0x1142 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' device =3D '600 Series Chipset USB 3.2 Controller' class =3D serial bus subclass =3D USB cap 05[50] =3D MSI supports 8 messages, 64 bit=20 cap 11[68] =3D MSI-X supports 8 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x2080] cap 01[78] =3D powerspec 3 supports D0 D3 current D0 cap 10[80] =3D PCI-Express 2 legacy endpoint max data 256(512) RO NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 0018[160] =3D LTR 1 ahci1@pci0:14:0:0: class=3D0x010601 rev=3D0x01 hdr=3D0x00 = vendor=3D0x1022 device=3D0x43f6 subvendor=3D0x1b21 subdevice=3D0x1062 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' device =3D '600 Series Chipset SATA Controller' class =3D mass storage subclass =3D SATA cap 05[50] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 01[70] =3D powerspec 3 supports D0 D3 current D0 -- P2P Direct Translated unavailable, Enhanced = Capability unavailable xhci2@pci0:16:0:3: class=3D0x0c0330 rev=3D0x00 hdr=3D0x00 = vendor=3D0x1022 device=3D0x15b6 subvendor=3D0x1043 subdevice=3D0x8877 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' class =3D serial bus subclass =3D USB cap 09[48] =3D vendor (length 8) cap 01[50] =3D powerspec 3 supports D0 D3 current D0 cap 10[64] =3D PCI-Express 2 endpoint max data 256(256) RO NS max read 512 link x16(x16) speed 16.0(16.0) ASPM disabled(L0s/L1) cap 05[a0] =3D MSI supports 8 messages, 64 bit=20 cap 11[c0] =3D MSI-X supports 8 messages, enabled Table in map 0x10[0xfe000], PBA in map 0x10[0xff000] ecap 000b[100] =3D Vendor [1] ID 0001 Rev 1 Length 16 ecap 000d[2a0] =3D ACS 1 Source Validation unavailable, Translation = Blocking unavailable P2P Req Redirect unavailable, P2P Cmpl Redirect = unavailable P2P Upstream Forwarding unavailable, P2P Egress = Control unavailable P2P Direct Translated unavailable, Enhanced = Capability unavailable xhci3@pci0:16:0:4: class=3D0x0c0330 rev=3D0x00 hdr=3D0x00 = vendor=3D0x1022 device=3D0x15b7 subvendor=3D0x1043 subdevice=3D0x8877 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' class =3D serial bus subclass =3D USB cap 09[48] =3D vendor (length 8) cap 01[50] =3D powerspec 3 supports D0 D3 current D0 cap 10[64] =3D PCI-Express 2 endpoint max data 256(256) RO NS max read 512 link x16(x16) speed 16.0(16.0) ASPM disabled(L0s/L1) cap 05[a0] =3D MSI supports 8 messages, 64 bit=20 cap 11[c0] =3D MSI-X supports 8 messages, enabled Table in map 0x10[0xfe000], PBA in map 0x10[0xff000] ecap 000b[100] =3D Vendor [1] ID 0001 Rev 1 Length 16 ecap 000d[2a0] =3D ACS 1 Source Validation unavailable, Translation = Blocking unavailable P2P Req Redirect unavailable, P2P Cmpl Redirect = unavailable P2P Upstream Forwarding unavailable, P2P Egress = Control unavailable P2P Direct Translated unavailable, Enhanced = Capability unavailable hdac1@pci0:16:0:6: class=3D0x040300 rev=3D0x00 hdr=3D0x00 = vendor=3D0x1022 device=3D0x15e3 subvendor=3D0x1043 subdevice=3D0x87fb vendor =3D 'Advanced Micro Devices, Inc. [AMD]' device =3D 'Family 17h/19h HD Audio Controller' -- P2P Direct Translated unavailable, Enhanced = Capability unavailable xhci4@pci0:17:0:0: class=3D0x0c0330 rev=3D0x00 hdr=3D0x00 = vendor=3D0x1022 device=3D0x15b8 subvendor=3D0x1043 subdevice=3D0x8877 vendor =3D 'Advanced Micro Devices, Inc. [AMD]' class =3D serial bus subclass =3D USB cap 09[48] =3D vendor (length 8) cap 01[50] =3D powerspec 3 supports D0 D3 current D0 cap 10[64] =3D PCI-Express 2 endpoint max data 256(256) RO NS max read 512 link x16(x16) speed 16.0(16.0) ASPM disabled(L0s/L1) cap 05[a0] =3D MSI supports 8 messages, 64 bit=20 cap 11[c0] =3D MSI-X supports 8 messages, enabled Table in map 0x10[0xfe000], PBA in map 0x10[0xff000] ecap 000b[100] =3D Vendor [1] ID 0001 Rev 1 Length 16 ecap 0019[270] =3D PCIe Sec 1 lane errors 0 ecap 000d[2a0] =3D ACS 1 Source Validation unavailable, Translation = Blocking unavailable P2P Req Redirect unavailable, P2P Cmpl Redirect = unavailable P2P Upstream Forwarding unavailable, P2P Egress = Control unavailable P2P Direct Translated unavailable, Enhanced = Capability unavailable ecap 0026[410] =3D Physical Layer 16.0 GT/s 1 ecap 0027[450] =3D Lane Margining at Receiver 1 # usbconfig show_ifdrv ugen4.1: at usbus4, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DSAVE (0mA) ugen4.1.0: uhub0: ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DSAVE (0mA) ugen0.1.0: uhub1: ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DSAVE (0mA) ugen1.1.0: uhub3: ugen2.1: at usbus2, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DSAVE (0mA) ugen2.1.0: uhub4: ugen3.1: at usbus3, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DSAVE (0mA) ugen3.1.0: uhub2: ugen3.2: at usbus3, cfg=3D0 md=3DHOST = spd=3DSUPER (5.0Gbps) pwr=3DON (72mA) ugen3.2.0: ure0: . . ugen1.2: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL= (12Mbps) pwr=3DON (500mA) ugen1.2.0: ubt0: . . . (I omitted the CORSAIR related lines.) >> USB ID 0x17ef/0x7205 >> rgephy1: PHY 0 on miibus1 >> I tried using the cdce driver, it gives me < 100Mb/s, while the ure = driver gets > 500Mb/s >=20 > Right, I saw about the same. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 4 23:14:31 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TpZK75cwgz5DTNb; Mon, 4 Mar 2024 23:14:35 +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 4TpZK72pzmz49Qc; Mon, 4 Mar 2024 23:14:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4D3B28929A; Mon, 4 Mar 2024 23:14:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.18.1/8.16.1) with ESMTPS id 424NEWfT084762 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Mar 2024 23:14:32 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 424NEVll084761; Mon, 4 Mar 2024 23:14:31 GMT (envelope-from phk) Message-Id: <202403042314.424NEVll084761@critter.freebsd.dk> To: Jakob Alvermark cc: Alexander Motin , Mark Millard , Current FreeBSD , FreeBSD-USB Mailing List Subject: Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information In-reply-to: From: "Poul-Henning Kamp" References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84759.1709594071.1@critter.freebsd.dk> Date: Mon, 04 Mar 2024 23:14:31 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4TpZK72pzmz49Qc Jakob Alvermark writes: > I tried using the cdce driver, it gives me < 100Mb/s, while the ure > driver gets > 500Mb/s I'll take 100 stable Mb/s over 500 unstable Mb/s any day :-) (Back in my days we had only 10 Mb/s, and everybody shared them &c. &c.) But yes, I agree that it would be nice if this stuff (&TB) worked better. Poul-Henning PS: In other news: I think my main-n268442-2f4cbf459d4a kernel has managed to suspend&resume more times with iwlwifi than I've ever seen before :-> -- 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 Mar 5 19:08:50 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tq4qJ5PfKz5DFBr; Tue, 5 Mar 2024 19:09:00 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4Tq4qJ3Vgzz4YRb; Tue, 5 Mar 2024 19:09:00 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; none Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1rha7k-0009uH-0e; Tue, 05 Mar 2024 20:06:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UXspc7VsVKAldlfYmINEATN9WJqBEJfgWaB5xb2WVYU=; b=ggs4EoTm9DcJEGvht8qf1s9FTa qskugt7yyyxm7WVcQuz8HFJUaF762A1b3Sg7kMmCprSS3p6lVTvPcyQTQ3aWIKdaB+surDXsa37w1 ALhxN7VdU81NhtCtxt5yDt7SyguIeJHq9EaH0iiPHpkGAT9byXVhNg87UPFx6F5iLhtjoUTQVQxge sPnaov+Y1PW2GmhGmJE7HpgJz4pob9rrnWgENPAf+/J+kwHt68b3xltNm10kY5WwNCKYVLL2GdnR1 9YsS+IDVAJfjnxbJVdiJPbwl03QGLk0gaISG/sR8NotQUcOk5U+jv2RGFIXfWwg5J+YlffEI2pePf zFsaNAkA==; Received: from office.as33885.net ([84.55.65.101] helo=[192.168.10.2]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1rha9j-000GIK-9A; Tue, 05 Mar 2024 20:08:51 +0100 Message-ID: Date: Tue, 5 Mar 2024 20:08:50 +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: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information To: Alexander Motin , Poul-Henning Kamp , Mark Millard Cc: Current FreeBSD , FreeBSD-USB Mailing List References: <41913B2D-381A-4EEC-9B37-531445645F71.ref@yahoo.com> <41913B2D-381A-4EEC-9B37-531445645F71@yahoo.com> <202403042000.424K0nnR083667@critter.freebsd.dk> <42786924-babe-da63-b672-d546c41327c6@FreeBSD.org> <87db86a3-55a3-7d55-63a6-0058e0f98c2b@FreeBSD.org> Content-Language: en-US From: Jakob Alvermark In-Reply-To: <87db86a3-55a3-7d55-63a6-0058e0f98c2b@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT] X-Rspamd-Queue-Id: 4Tq4qJ3Vgzz4YRb On 3/4/24 21:39, Alexander Motin wrote: > >>> AFAIK it is only a workaround.  I saw it myself on number of >>> different USB dongles and laptops, that USB starting experience some >>> problems with multiple NIC queues and some other factors. IIRC the >>> Realtek driver was much more stable once I limited it to one queue >>> and some other hacks. IIRC if_cdce just has only one queue and other >>> limitations, that not only makes it more stable, but also much >>> slower.  It would be good to understand what's wrong is there >>> exactly, since IMHO it is a big problem now. Unfortunately HPS was >>> unable to reproduce it on his laptop (that makes me wonder if is is >>> specific to chipset(s) or thunderbolt?), so it ended nowhere so far. >> >> I have a Lenovo USB 3 dongle, so no thunderbolt. > > I also use USB3 dongles.  But in my laptops the USB 3 ports are > provided by Intel Thunderbolt controller, while in HPS' they were > plain from USB3 controller.  Though it may be just a coincidence. I don't think (how do I know?) I have thunderbolt in this Lenovo AMD Ryzen laptop. > >> USB ID 0x17ef/0x7205 >> >> rgephy1: PHY 0 on miibus1 >> >> I tried using the cdce driver, it gives me < 100Mb/s, while the ure >> driver gets > 500Mb/s > > Right, I saw about the same. > Just to try something else, I got another USB dongle, I does the exact same thing: ugen1.10: at usbus1 axge0 on uhub6 axge0: on usbus1 miibus1: on axge0 rgephy1: PHY 3 on miibus1 rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow ue0: on axge0 ue0: Ethernet address: xx:xx:xx:xx:xx:xx ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: 2 link states coalesced ue0: link state changed to UP From nobody Wed Mar 6 17:51:05 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tqg3Z0BMJz5D1dh for ; Wed, 6 Mar 2024 17:51:38 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [IPv6:2607:f170:34:11::b0]) (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 "mail.freebsdsolutions.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tqg3X4Cq7z4smX for ; Wed, 6 Mar 2024 17:51:36 +0000 (UTC) (envelope-from lists@jnielsen.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 2607:f170:34:11::b0 as permitted sender) smtp.mailfrom=lists@jnielsen.net Received: from smtpclient.apple ([50.207.241.62]) (authenticated bits=0) by webmail5.jnielsen.net (8.17.2/8.17.1) with ESMTPSA id 426HpGCN017491 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Mar 2024 10:51:18 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host [50.207.241.62] claimed to be smtpclient.apple From: John Nielsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Kernel build broken without "options KTRACE" Message-Id: <9E2E20A1-3A46-461A-B930-94EFEA6249BA@jnielsen.net> Date: Wed, 6 Mar 2024 10:51:05 -0700 To: current@freebsd.org X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; APPLE_MAILER_COMMON(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:6364, ipnet:2607:f170:30::/44, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[jnielsen.net]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; 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: 4Tqg3X4Cq7z4smX Getting a set but not used warning for =E2=80=9Ctd=E2=80=9D in = sys/kern/kern_condvar.c when doing a buildkernel for a config file = without =E2=80=9Coptions KTRACE=E2=80=9D. I failed to copy the full = error message/line numbers but I will reproduce this evening if needed. JN From nobody Wed Mar 6 18:56:00 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TqhTx0xv4z5D6YH for ; Wed, 6 Mar 2024 18:56:05 +0000 (UTC) (envelope-from Matthew.L.Dailey@dartmouth.edu) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2106.outbound.protection.outlook.com [40.107.101.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TqhTw0hkWz42vT for ; Wed, 6 Mar 2024 18:56:04 +0000 (UTC) (envelope-from Matthew.L.Dailey@dartmouth.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dartmouth.edu header.s=selector2 header.b=WYG7jlmt; dmarc=pass (policy=none) header.from=dartmouth.edu; spf=pass (mx1.freebsd.org: domain of Matthew.L.Dailey@dartmouth.edu designates 40.107.101.106 as permitted sender) smtp.mailfrom=Matthew.L.Dailey@dartmouth.edu; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PJmZZrdCfkJQ73cyJxo+mnsiUm8zqIGffy49ENhn8j2mrzzcdINwB0U6bQ3Y5qM5YCCJN2krKLZcf8PdGMgODtBLkPZlpVmRcmnBzgPLFHqvLxMKu7KK0ltysDnTmIGkBSo1kPOuliQQ9riGj7zkbFDGt1oV8mz0hSB+J73xHOYpOZVQWNijD/JJ7rjbkTM2Dw5sdSSunTlN3sd3/bHldNm/UgjoV/3t0Yh8GFfEAFvmw9bt4G/WFOmsZj1W5LqgFiaF137t2XhT7iG5K4hqwWVQPHJ0MVsIDRI9D0qFzAvOEDxZCK84CpO/5TkfgOYMVvz1/2RYPyWBWbCqM6RMMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DDE6G2q/89tZkVCsZSYa/5tC7djS7f9yAdlvu4oG8h0=; b=U086r6cvTOo0ioQeQCI3LgI/mFFQ6aa45gpR5sV6SlppuZHu57sbS0O+x+9Ry3O5PPsji8AvNxGUs08jDjzuA6qUxZNsWeYUwaI5E9HdOEuTTRWP0XtRlYXL80Vh+kUIzmRAmAwz2sNEZ/o+qTUZGL9LkLI0CTdvCa+IBcp7UiBSacvZC0RkUhTDRiglVanEIrjzm2GDeXEh9GFNcu0A3Os/A9n2JK0fyDmXeCuCTsulTe8CT0/wlfVk60BMNLmjuH6xudfspr32VgrC/Gtmf5D55dkpz340x6m+YQPiZ+z9xPPu3pXB+b0KU1jSQuQAu5rG3GXI+gIzNCtZVpYTtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dartmouth.edu; dmarc=pass action=none header.from=dartmouth.edu; dkim=pass header.d=dartmouth.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dartmouth.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DDE6G2q/89tZkVCsZSYa/5tC7djS7f9yAdlvu4oG8h0=; b=WYG7jlmtId6HQKvG9rUzvpW4bnJ2A22PDjbxhibHO1EEQr9U5aIjFb3eouMnrt/PFLv03LJZUsV7dPUjy4FTINtejs9zX407p6dRqX2fepGluZP0hpjY+7ejKm7GnQzW5J6j4Ru+wIN0eDeuhHY1n6sng2nrtSUbmHVmX3JsjqY= Received: from DS7PR03MB5574.namprd03.prod.outlook.com (2603:10b6:5:2c1::16) by PH0PR03MB7017.namprd03.prod.outlook.com (2603:10b6:510:170::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Wed, 6 Mar 2024 18:56:01 +0000 Received: from DS7PR03MB5574.namprd03.prod.outlook.com ([fe80::db67:1ab1:da71:659e]) by DS7PR03MB5574.namprd03.prod.outlook.com ([fe80::db67:1ab1:da71:659e%7]) with mapi id 15.20.7339.035; Wed, 6 Mar 2024 18:56:00 +0000 From: "Matthew L. Dailey" To: "freebsd-current@freebsd.org" Subject: Re: FreeBSD panics possibly caused by nfs clients Thread-Topic: FreeBSD panics possibly caused by nfs clients Thread-Index: AQHab/ft55VVTwbCXkKWD27so39oHA== Date: Wed, 6 Mar 2024 18:56:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla Thunderbird x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR03MB5574:EE_|PH0PR03MB7017:EE_ x-ms-office365-filtering-correlation-id: 32fde271-c0e5-473e-1c84-08dc3e0f1089 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qd2UqPwajEF3wWQZWD0/lg1Onlz72I4nT0QFnOQavjB9LiYpduYI/9kNZ+uT0yDpZAfLM4GZQK6wpifXpWaE/gtjKPAvEoQ5lw4oVOuDPSDUWRSGZAuVEw09KFcXSPzthK1VV7ofXRaQK0VDiKxve21p8teVtZRABldFZTmxgfq2/7Y40f2jWHaP6OZDaJNAA1tyxFvo8LnGd5M6Ro2E3tBDGHcbbVKj1Isv0SrPKhYzOD1CwWoi6uTTdJERZfFz2LUCH1+3CVfgB5FdocazkC0JazDcO3vfzLmR0LTbUqYh5PpEwgRSFMOIaOXTGiO+j43/+Ix5BzUfstw5hmbHEEemAV3dZYkJgd6WltYpY+6Q8EMS0NT42dX5ufai76w6I0rAiuWYon4rb1JyfEfo+vu3YCB6kuRYR9yY1OCX6a1/nl/sKg7mb4qQfl8dhS3/tO2BeRSHQBkZDhKgYHKZDY6GCa6194oX1ildmrqp9n9+f8R43h56jhuJN1LTq6NyRulMJ+EMHLHyQxbeCJDRK89eG4yzU74mTrTyRSfXAeM6R7cGYPWa0lHRmNJAS50mTADxs6srehtUOCfqhkd8TCezHJB6IGHDrBqLB2bEdEv1vhrOcPdryJksWTPmokPItkxptKFcA1qJ7mQ3TNjp+0MsqTRM5VbOURzj3h2r5OW8JtWQFWTJs5kaQ54DJrdmRY5/XsKR/ygc6LA8yzJSZuj4B4K+yTvhg19u62idKec= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:zh-cn;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR03MB5574.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(38070700009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M2NxUFl1dHUvU1UvSXF1SjJKQ0psR2g0eGNzSnVlYjZ1dlhJN1hFaFM0dWo1?= =?utf-8?B?NDc5dDlhM0pMMEh3aWFWa1VkRTZoTnVZT1hFL2JWQTVzVlFxMG9TdDFrdWJx?= =?utf-8?B?SDVKQ3pJQU5Kdm0zLzRKeHljYUxESVdOaW16Z0c1QjFjYmlvT2sxVzBxWnhP?= =?utf-8?B?MVFMUjZlN0xGdC9WQ1lDa0lQYWcva1ZQOHZGSzl6amRrYitXZGFuRlF6alE2?= =?utf-8?B?L1dNK1VEaVlQWm81MVlVTWlqemVKaUZ3L0dNNWJvb2VOcCtRZWJRdVpIL0Mx?= =?utf-8?B?eGEyMXFVbzJWNS9iSjhWUVJ1Z05jMTd1T2pRcVlET0JLbUt3TFNKOHRnRWNH?= =?utf-8?B?b0prUlJFamFtWlhSKzdES1B1RTE3UTJFanpIZmlHUFJYUDRIaUg1eW5BMHpx?= =?utf-8?B?UElRVnBzMXJNa1NKbGVTVjBiRkl1WnZLY2VUNVdVWHpLaktsOXVpSWxyamFz?= =?utf-8?B?cm9ybnVoTlQvWTVFR0pOY3lnWklZU296N3ZEMG45bHBXVmh6THZPb1poN0dk?= =?utf-8?B?SHBrUDJsZ1dIUjkvMnRHaEFIUVk4a0dPRTlTNVFMR2Nwc25TTzh4NmI2SCtj?= =?utf-8?B?VWpveXJicU9zWUhUMWU3T255ZFI5U29VaTFrY295ZzNjY2Z3blVla2dqZVlY?= =?utf-8?B?Z05wd0IvODJ0ZWt3dDVqdjhTZTdEMGx2UTRqdWVTOWdjRU9kSXlKZWFTczZZ?= =?utf-8?B?Q3g4ZndIaUFTa3RQQmRHTXZ5OEJSeVo1RVR2ZFRZOHBNUm0vb0tOQlVLOVR3?= =?utf-8?B?KzljV2R4cktiWklzWSszellwUnlpNHljWGNhNnA0bjQzbHlKQkVSRDE0V2JX?= =?utf-8?B?aUg5dXBPZE1qNGZodCt2Y1plUk9vaTdEN1BmZGEzNGx4eU9DMnhQK2FwZXg2?= =?utf-8?B?Ty9uWmZYcXlhZnYzL2JNbnkwaXRSdm5tMVI1MUdCRStSVlczektjek5kNmwr?= =?utf-8?B?WXlGWFdQOGFJUEk0KzEvZk5xU2dsL0VPN0trRDU0ZjRER216ZjVPbHNhRXh0?= =?utf-8?B?WjYvV0gyb0JDN3lja0R4aGRLOE9sc3pVYVNPZVR3WTJkcXpMN01US0NJZUMv?= =?utf-8?B?UVRlS2JRdE9OVFRRRCtBOGNzREZQaHAvS1ZxRStLUU1nVFVvd2VSZEFjM3dv?= =?utf-8?B?S1FzdWMybWEwR3JtOFFqV21LcFZmc09FL2Q1dWtPRmJBTW42dTUwcFNFUlVp?= =?utf-8?B?cVVrMjdaZnBGT3VsMHJXTmIyNzVpNE1FM2YxRlZUQ0psWEoreWtONEdzamxh?= =?utf-8?B?YUFPYm5DUjJEeDdnLzNyYVRmUFlHb3UwR0VLUWRncDIvTExUd1NqUUgrNi9P?= =?utf-8?B?QklYUVczVG5Mc01Wb25nMExCN0g1dmlPZmwxaFNzblBSSmh3cGJPWENPNEdz?= =?utf-8?B?WXE4SStsbnlqMmZJaDVzdzRiS21wemowN09zTXF1cGZ5UVJma2hzYy81WVdk?= =?utf-8?B?dUhPSmJtWXkyS1VXdEZpcG5ROTZXcUROcU9UQUVNS2Q3MFY0QlZVdmI3Wk9q?= =?utf-8?B?Z0hzMjVLS0x1ZWU0MFhNMjZDUTFuK3czZmc1QmZCdDF2WVBnRjljRE9TSTJW?= =?utf-8?B?N25meFEzS3UveTNHbFAyREVjNktuYWJVaTBxSVg1bmhJYUZHRVhXRVBWME5M?= =?utf-8?B?QnVKSnNPYkxIc1pJQjYzMzFlY00xVFU1bGpUV0ROZ1pqSkloVlE2OGx4MXJG?= =?utf-8?B?Q00wK015QXlsTUZKa3lRN1cwMXFDMCtnU3VSa1BoRTBBOUg4anZJMDVySml1?= =?utf-8?B?dCtwelVaYVdpNzlzcVdKMm1QeS8xQlNXNkJHR1F5RWN1cGFLWHVtdlk0RWJ1?= =?utf-8?B?TWhydnViME4zcWRBTGd6WU90cnRFc2VGL2xuTmdlUWpvZHdPVTVjSlVMWVR1?= =?utf-8?B?MWk5ODZPS0dqVmw5VHZFK3MxZHFrNWtOSnkyYTZPeEpmMzlMT1IyR291TDgy?= =?utf-8?B?NTU4a2Z3amlTTHpudDBPNUVIVkRCTWpaYUhNZTYzNWxtOHJ2Z0IzaHFTVzFs?= =?utf-8?B?MjZqSW11RXhOaHNLb3N3c3RKRGZwQmhnTEo1aTNldDZhbUtBL1NlNHBFeWdi?= =?utf-8?B?S0xxTnBvOTlLUmRTYTVwVHF6aXhZd012TFk0bndVSS9wSDE4b2FzaFRWdW1H?= =?utf-8?Q?g5reIcQGLeCcvCutN65YGbMIV?= Content-Type: text/plain; charset="utf-8" Content-ID: <75CFC111A9035447A06FDF944E420457@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: dartmouth.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR03MB5574.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32fde271-c0e5-473e-1c84-08dc3e0f1089 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2024 18:56:00.2479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 995b0936-48d6-40e5-a31e-bf689ec9446f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X7Nfe2q7EPFqsw26ax4h7SvSdZf6ZiN7xFCCyoHZWjktMah+j61X/UaHaK8qAQ27V4dyhmebVFhhdkacSOxuhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB7017 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[dartmouth.edu,none]; R_DKIM_ALLOW(-0.20)[dartmouth.edu:s=selector2]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[dartmouth.edu:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[dartmouth.edu:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.101.106:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_IN_DNSWL_NONE(0.00)[40.107.101.106:from] X-Rspamd-Queue-Id: 4TqhTw0hkWz42vT UG9zdGluZyBhIGZldyB1cGRhdGVzIG9uIHRoaXMgaXNzdWUuDQoNCkkgd2FzIGFibGUgdG8gaW5k dWNlIGEgcGFuaWMgb24gYSBDVVJSRU5UIGtlcm5lbCAoMjAyNDAyMTUpLCBidWlsdCB3aXRoIA0K R0VORVJJQy1LQVNBTiBhbmQgcnVubmluZyBrZXJuLmtzdGFja19wYWdlcz02IChkZWZhdWx0KSBh ZnRlciB+MTg5IA0KaG91cnMuIFRoZSBwYW5pYyBtZXNzYWdlIGFuZCBiYWNrdHJhY2UgYXJlIGJl bG93IC0gcGxlYXNlIHJlYWNoIG91dCANCmRpcmVjdGx5IGlmIHlvdSdkIGxpa2UgdG8gaGF2ZSBh IGxvb2sgYXQgdGhlIGNvcmUuIEknbSBzcGVjaWZpY2FsbHkgbm90IA0KaW5jcmVhc2luZyBrc3Rh Y2tfcGFnZXMgdG8gc2VlIHdoYXQgZWZmZWN0IHRoaXMgaGFzIG9uIHRoZSBwYW5pY3MuDQoNCkkg aGF2ZSBhbm90aGVyIHN5c3RlbSBydW5uaW5nIENVUlJFTlQgKDIwMjQwMjE1KSB3aXRob3V0IGFu eSBkZWJ1Z2dpbmcuIA0KSSdtIGFibGUgdG8gcmVndWxhcmx5IHBhbmljIHRoaXMgKDcgcGFuaWNz IG92ZXIgdHdvIHdlZWtzIHdpdGggYXZlcmFnZSANCnVwdGltZSBvZiB+NDIgaG91cnMpIHdpdGgg a3N0YWNrX3BhZ2VzPTQuIEkgc2V0IGtzdGFja19wYWdlcz02LCBhbmQgaGF2ZSANCmFsc28gaW5k dWNlZCBzZXZlcmFsIHBhbmljcy4gT2RkbHksIHRoaXMgc2VlbXMgdG8gaGFwcGVuIG1vcmUgcXVp Y2tseSAoNCANCnBhbmljcyBvdmVyIDIgZGF5cyB3aXRoIGF2ZXJhZ2UgdXB0aW1lIG9mIH4xMC41 IGhvdXJzKS4NCg0KQW5vdGhlciBzeXN0ZW0gcnVubmluZyBDVVJSRU5UICgyMDI0MDIwOCksIGJ1 aWx0IHdpdGggR0VORVJJQy1LQVNBTiBhbmQgDQpydW5uaW5nIGtlcm4ua3N0YWNrX3BhZ2VzPTgg aGFzIG5vdyBiZWVuIHJ1bm5pbmcgd2l0aCBvdXIgaGRmNSB3b3JrbG9hZCANCm5vbi1zdG9wIHNp bmNlIEZlYnJ1YXJ5IDEwdGggd2l0aCBubyBwYW5pY3Mgb3IgaXNzdWVzLg0KDQogRnJvbSBhbGwg dGhpcywgaXQgc2VlbXMgbGlrZSBpbmNyZWFzaW5nIGtzdGFja19wYWdlcyB0byA4IGVsaW1pbmF0 ZXMgDQp0aGUgcGFuaWNzLCBidXQgb2J2aW91c2x5IGRvZXNuJ3QgZml4IHRoZSB1bmRlcmx5aW5n IGNhdXNlIG9mIHRoZSANCmlzc3Vlcy4gU28sIGFsdGhvdWdoIHRoaXMgaXMgYW4gb2J2aW91cyB3 b3JrYXJvdW5kIGZvciBvdXIgcHJvZHVjdGlvbiANCnN5c3RlbSwgaXQgd291bGQgYmUgYmV0dGVy IHRvIGZpbmQgYW5kIGZpeCB0aGUgdW5kZXJseWluZyBjYXVzZSBvZiB0aGUgDQpwYW5pY3MuDQoN CkknbSBnb2luZyB0byBjb250aW51ZSB0ZXN0aW5nIHRvIHRyeSB0byBnZW5lcmF0ZSBtb3JlIGNv cmVzIHdpdGggDQprc3RhY2tfcGFnZXM8OCBvbiB0aGUgc3lzdGVtIHdpdGggdGhlIGRlYnVnIGtl cm5lbC4NCg0KQW55IG90aGVyIGlkZWFzIHRvIHRyeSB0byBuYXJyb3cgZG93biB0aGUgY2F1c2Ug YXJlIHdlbGNvbWUuDQoNClRoYW5rcywNCk1hdHQNCg0KWzY4MDk0MF0gS2VybmVsIHBhZ2UgZmF1 bHQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFibGUgbG9ja3MgaGVsZDoNCls2ODA5NDBd IGV4Y2x1c2l2ZSBzbGVlcCBtdXRleCBuZnNfc3RhdGVfbXV0ZXggKG5mc19zdGF0ZV9tdXRleCkg ciA9IDAgDQooMHhmZmZmZmZmZjgzMDQ5OGUwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMvZnMvbmZz c2VydmVyL25mc19uZnNkc3RhdGUuYzo2NjUyDQpbNjgwOTQwXSBzdGFjayBiYWNrdHJhY2U6DQpb NjgwOTQwXSAjMCAweGZmZmZmZmZmODEyNzk1OGYgYXQgd2l0bmVzc19kZWJ1Z2dlcisweDEzZg0K WzY4MDk0MF0gIzEgMHhmZmZmZmZmZjgxMjdiMTE0IGF0IHdpdG5lc3Nfd2FybisweDY3NA0KWzY4 MDk0MF0gIzIgMHhmZmZmZmZmZjgxYWJhMGE2IGF0IHRyYXBfcGZhdWx0KzB4MTE2DQpbNjgwOTQw XSAjMyAweGZmZmZmZmZmODFhYjkwMWMgYXQgdHJhcCsweDU0Yw0KWzY4MDk0MF0gIzQgMHhmZmZm ZmZmZjgxYTc1OTg4IGF0IGNhbGx0cmFwKzB4OA0KWzY4MDk0MF0gIzUgMHhmZmZmZmZmZjgwZmI0 YmZhIGF0IG5mc3J2X2ZyZWVzdGF0ZWlkKzB4MjNhDQpbNjgwOTQwXSAjNiAweGZmZmZmZmZmODBm ZDVlM2YgYXQgbmZzcnZkX2ZyZWVzdGF0ZWlkKzB4MWRmDQpbNjgwOTQwXSAjNyAweGZmZmZmZmZm ODBmOThkMzUgYXQgbmZzcnZkX2RvcnBjKzB4MjU4NQ0KWzY4MDk0MF0gIzggMHhmZmZmZmZmZjgw ZmJmNTg4IGF0IG5mc3N2Y19wcm9ncmFtKzB4MTA3OA0KWzY4MDk0MF0gIzkgMHhmZmZmZmZmZjgx NzNmY2U2IGF0IHN2Y19ydW5faW50ZXJuYWwrMHgxNzA2DQpbNjgwOTQwXSAjMTAgMHhmZmZmZmZm ZjgxNzQwOTRiIGF0IHN2Y190aHJlYWRfc3RhcnQrMHhiDQpbNjgwOTQwXSAjMTEgMHhmZmZmZmZm ZjgxMTEzN2EzIGF0IGZvcmtfZXhpdCsweGEzDQpbNjgwOTQwXSAjMTIgMHhmZmZmZmZmZjgxYTc2 OWVlIGF0IGZvcmtfdHJhbXBvbGluZSsweGUNCls2ODA5NDBdDQpbNjgwOTQwXQ0KWzY4MDk0MF0g RmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQ0KWzY4MDk0MF0g Y3B1aWQgPSAzOyBhcGljIGlkID0gMDYNCls2ODA5NDBdIGZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9 IDB4Nw0KWzY4MDk0MF0gZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0YSwgcGFnZSBu b3QgcHJlc2VudA0KWzY4MDk0MF0gaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZmZmZm ZjgwZmFmZDY3DQpbNjgwOTQwXSBzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZl MDE1M2JhMmRlMA0KWzY4MDk0MF0gZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZm ZTAxNTNiYTJlYjANCls2ODA5NDBdIGNvZGUgc2VnbWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhm ZmZmZiwgdHlwZSAweDFiDQpbNjgwOTQwXSAJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVm MzIgMCwgZ3JhbiAxDQpbNjgwOTQwXSBwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJs ZWQsIHJlc3VtZSwgSU9QTCA9IDANCls2ODA5NDBdIGN1cnJlbnQgcHJvY2VzcwkJPSA1NTIwMiAo bmZzZDogc2VydmljZSkNCls2ODA5NDBdIHJkaTogMDAwMDAwMDAwMDAwMDAwNyByc2k6IDAwMDAw MDAwMDAwMDAwMDAgcmR4OiBkZmZmZjdjMDAwMDAwMDAwDQpbNjgwOTQwXSByY3g6IGZmZmZmZTAw MWI5ZWMxZTggIHI4OiAwMDEyYzQzNTAwMDAwMDAyICByOTogMDAxMmM0MzUwMDAwMDAwMg0KWzY4 MDk0MF0gcmF4OiBmZmZmZmUwMDFiOWVjMWU4IHJieDogZmZmZmZmZmZmZmZmZmZmZiByYnA6IGZm ZmZmZTAxNTNiYTJlYjANCls2ODA5NDBdIHIxMDogMDAwMDAwMDAwMDAwMDAwNCByMTE6IDAwMDAw MDAwMDAwMDAwMDYgcjEyOiAwMDAwMDAwMDAwMDAwMDA3DQpbNjgwOTQwXSByMTM6IGZmZmZmZTAx OWNkNzU3MDAgcjE0OiAwMDAwMDAwMDAwMDAxYTFhIHIxNTogZmZmZmZlMDE5Y2Q3NTcwOA0KWzY4 MDk0MF0gdHJhcCBudW1iZXIJCT0gMTINCls2ODA5NDBdIHBhbmljOiBwYWdlIGZhdWx0DQpbNjgw OTQwXSBjcHVpZCA9IDMNCls2ODA5NDBdIHRpbWUgPSAxNzA5NjQ2MTc4DQpbNjgwOTQwXSBLREI6 IHN0YWNrIGJhY2t0cmFjZToNCls2ODA5NDBdIGRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRi X3RyYWNlX3NlbGZfd3JhcHBlcisweGE1L2ZyYW1lIA0KMHhmZmZmZmUwMTUzYmEyNTUwDQpbNjgw OTQwXSBrZGJfYmFja3RyYWNlKCkgYXQga2RiX2JhY2t0cmFjZSsweGM2L2ZyYW1lIDB4ZmZmZmZl MDE1M2JhMjZiMA0KWzY4MDk0MF0gdnBhbmljKCkgYXQgdnBhbmljKzB4MjEwL2ZyYW1lIDB4ZmZm ZmZlMDE1M2JhMjg1MA0KWzY4MDk0MF0gcGFuaWMoKSBhdCBwYW5pYysweGI1L2ZyYW1lIDB4ZmZm ZmZlMDE1M2JhMjkxMA0KWzY4MDk0MF0gdHJhcF9mYXRhbCgpIGF0IHRyYXBfZmF0YWwrMHg2NWIv ZnJhbWUgMHhmZmZmZmUwMTUzYmEyYTEwDQpbNjgwOTQwXSB0cmFwX3BmYXVsdCgpIGF0IHRyYXBf cGZhdWx0KzB4MTJiL2ZyYW1lIDB4ZmZmZmZlMDE1M2JhMmIzMA0KWzY4MDk0MF0gdHJhcCgpIGF0 IHRyYXArMHg1NGMvZnJhbWUgMHhmZmZmZmUwMTUzYmEyZDEwDQpbNjgwOTQwXSBjYWxsdHJhcCgp IGF0IGNhbGx0cmFwKzB4OC9mcmFtZSAweGZmZmZmZTAxNTNiYTJkMTANCls2ODA5NDBdIC0tLSB0 cmFwIDB4YywgcmlwID0gMHhmZmZmZmZmZjgwZmFmZDY3LCByc3AgPSANCjB4ZmZmZmZlMDE1M2Jh MmRlMCwgcmJwID0gMHhmZmZmZmUwMTUzYmEyZWIwIC0tLQ0KWzY4MDk0MF0gbmZzcnZfZnJlZWxv Y2tvd25lcigpIGF0IG5mc3J2X2ZyZWVsb2Nrb3duZXIrMHg5Ny9mcmFtZSANCjB4ZmZmZmZlMDE1 M2JhMmViMA0KWzY4MDk0MF0gbmZzcnZfZnJlZXN0YXRlaWQoKSBhdCBuZnNydl9mcmVlc3RhdGVp ZCsweDIzYS9mcmFtZSANCjB4ZmZmZmZlMDE1M2JhMmY3MA0KWzY4MDk0MF0gbmZzcnZkX2ZyZWVz dGF0ZWlkKCkgYXQgbmZzcnZkX2ZyZWVzdGF0ZWlkKzB4MWRmL2ZyYW1lIA0KMHhmZmZmZmUwMTUz YmEzMDMwDQpbNjgwOTQwXSBuZnNydmRfZG9ycGMoKSBhdCBuZnNydmRfZG9ycGMrMHgyNTg1L2Zy YW1lIDB4ZmZmZmZlMDE1M2JhMzU3MA0KWzY4MDk0MF0gbmZzc3ZjX3Byb2dyYW0oKSBhdCBuZnNz dmNfcHJvZ3JhbSsweDEwNzgvZnJhbWUgMHhmZmZmZmUwMTUzYmEzOTcwDQpbNjgwOTQwXSBzdmNf cnVuX2ludGVybmFsKCkgYXQgc3ZjX3J1bl9pbnRlcm5hbCsweDE3MDYvZnJhbWUgDQoweGZmZmZm ZTAxNTNiYTNlZTANCls2ODA5NDBdIHN2Y190aHJlYWRfc3RhcnQoKSBhdCBzdmNfdGhyZWFkX3N0 YXJ0KzB4Yi9mcmFtZSAweGZmZmZmZTAxNTNiYTNlZjANCls2ODA5NDBdIGZvcmtfZXhpdCgpIGF0 IGZvcmtfZXhpdCsweGEzL2ZyYW1lIDB4ZmZmZmZlMDE1M2JhM2YzMA0KWzY4MDk0MF0gZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4ZS9mcmFtZSAweGZmZmZmZTAxNTNiYTNm MzANCls2ODA5NDBdIC0tLSB0cmFwIDB4YywgcmlwID0gMHgzYjRmZjg5NmYwZGEsIHJzcCA9IDB4 M2I0ZmY2YTUwMGU4LCByYnAgPSANCjB4M2I0ZmY2YTUwMzgwIC0tLQ0KWzY4MDk0MF0gS0RCOiBl bnRlcjogcGFuaWMNCg0KIzAgIF9fY3VydGhyZWFkICgpIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9p bmNsdWRlL3BjcHVfYXV4Lmg6NTcNCiMxICBkb2FkdW1wICh0ZXh0ZHVtcD10ZXh0ZHVtcEBlbnRy eT0wKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDAzDQojMiAg MHhmZmZmZmZmZjgwNWE1MmY2IGluIGRiX2R1bXAgKGR1bW15PTxvcHRpbWl6ZWQgb3V0PiwNCiAg ICAgZHVtbXkyPTxvcHRpbWl6ZWQgb3V0PiwgZHVtbXkzPTxvcHRpbWl6ZWQgb3V0PiwgZHVtbXk0 PTxvcHRpbWl6ZWQgb3V0PikNCiAgICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6 NTkwDQojMyAgMHhmZmZmZmZmZjgwNWE1MTJiIGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD08b3B0 aW1pemVkIG91dD4sDQogICAgIGNtZF90YWJsZT08b3B0aW1pemVkIG91dD4sIGRvcGFnZXI9dHJ1 ZSkNCiAgICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NTAzDQojNCAgMHhmZmZm ZmZmZjgwNWE0YjNkIGluIGRiX2NvbW1hbmRfbG9vcCAoKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMv ZGRiL2RiX2NvbW1hbmQuYzo1NTANCiM1ICAweGZmZmZmZmZmODA1YWEyMDkgaW4gZGJfdHJhcCAo dHlwZT08b3B0aW1pemVkIG91dD4sIGNvZGU9PG9wdGltaXplZCANCm91dD4pDQogICAgIGF0IC91 c3Ivc3JjL3N5cy9kZGIvZGJfbWFpbi5jOjI2Nw0KIzYgIDB4ZmZmZmZmZmY4MTIzOWYyNSBpbiBr ZGJfdHJhcCAodHlwZT0zLCBjb2RlPWNvZGVAZW50cnk9MCwNCiAgICAgdGY9dGZAZW50cnk9MHhm ZmZmZmUwMTUzYmEyNWYwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX2tkYi5jOjc5MA0KIzcg IDB4ZmZmZmZmZmY4MWFiOGY4OCBpbiB0cmFwIChmcmFtZT0weGZmZmZmZTAxNTNiYTI1ZjApDQog ICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NjA2DQojOCAgPHNpZ25hbCBo YW5kbGVyIGNhbGxlZD4NCiM5ICBrZGJfZW50ZXIgKHdoeT08b3B0aW1pemVkIG91dD4sIG1zZz08 b3B0aW1pemVkIG91dD4pDQogICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfa2RiLmM6NTU2 DQojMTAgMHhmZmZmZmZmZjgxMThmZGYxIGluIHZwYW5pYyAoZm10PWZtdEBlbnRyeT0weGZmZmZm ZmZmODI0OTFkMjAgPHN0cj4gDQoiJXMiLA0KICAgICBhcD1hcEBlbnRyeT0weGZmZmZmZTAxNTNi YTI4YzApIGF0IA0KL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjk2MQ0KIzExIDB4 ZmZmZmZmZmY4MTE4ZmJhNSBpbiBwYW5pYyAoZm10PTB4ZmZmZmZmZmY4MjQ5MWQyMCA8c3RyPiAi JXMiKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6ODg5DQojMTIg MHhmZmZmZmZmZjgxYWI5ZjhiIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZmZmZmZlMDE1M2JhMmQy MCwgZXZhPTcpDQogICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6OTUwDQoj MTMgMHhmZmZmZmZmZjgxYWJhMGJiIGluIHRyYXBfcGZhdWx0IChmcmFtZT1mcmFtZUBlbnRyeT0w eGZmZmZmZTAxNTNiYTJkMjAsDQogICAgIHVzZXJtb2RlPWZhbHNlLCBzaWdubz1zaWdub0BlbnRy eT0weDAsIHVjb2RlPXVjb2RlQGVudHJ5PTB4MCkNCiAgICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0 L2FtZDY0L3RyYXAuYzo3NjENCiMxNCAweGZmZmZmZmZmODFhYjkwMWMgaW4gdHJhcCAoZnJhbWU9 MHhmZmZmZmUwMTUzYmEyZDIwKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJh cC5jOjQ0MA0KIzE1IDxzaWduYWwgaGFuZGxlciBjYWxsZWQ+DQojMTYgMHhmZmZmZmZmZjgwZmFm ZDY3IGluIG5mc3J2X2ZyZWVsb2Nrb3duZXIgKA0KICAgICBzdHA9c3RwQGVudHJ5PTB4ZmZmZmZl MDE5Y2Q3NTcwMCwgdnA9dnBAZW50cnk9MHgwLA0KICAgICBjYW5zbGVlcD1jYW5zbGVlcEBlbnRy eT0wLCBwPXBAZW50cnk9MHhmZmZmZmUwMTUzZTJjNzQwKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMv ZnMvbmZzc2VydmVyL25mc19uZnNkc3RhdGUuYzoxNTUwDQojMTcgMHhmZmZmZmZmZjgwZmI0YmZh IGluIG5mc3J2X2ZyZWVzdGF0ZWlkIChuZD1uZEBlbnRyeT0weGZmZmZmZTAxNTNiYTM3MTAsDQog ICAgIHN0YXRlaWRwPXN0YXRlaWRwQGVudHJ5PTB4ZmZmZmZlMDE1M2JhMmZjMCwgDQpwPXBAZW50 cnk9MHhmZmZmZmUwMTUzZTJjNzQwKQ0KICAgICBhdCAvdXNyL3NyYy9zeXMvZnMvbmZzc2VydmVy L25mc19uZnNkc3RhdGUuYzo2NjgxDQojMTggMHhmZmZmZmZmZjgwZmQ1ZTNmIGluIG5mc3J2ZF9m cmVlc3RhdGVpZCAobmQ9MHhmZmZmZmUwMTUzYmEzNzEwLA0KICAgICBpc2RncmFtPTxvcHRpbWl6 ZWQgb3V0PiwgdnA9PG9wdGltaXplZCBvdXQ+LCBleHA9PG9wdGltaXplZCBvdXQ+KQ0KICAgICBh dCAvdXNyL3NyYy9zeXMvZnMvbmZzc2VydmVyL25mc19uZnNkc2Vydi5jOjQ3NjQNCiMxOSAweGZm ZmZmZmZmODBmOThkMzUgaW4gbmZzcnZkX2NvbXBvdW5kIChuZD0weGZmZmZmZTAxNTNiYTM3MTAs IGlzZGdyYW09MCwNCiAgICAgdGFnPTxvcHRpbWl6ZWQgb3V0PiwgdGFnbGVuPTAsIG1pbm9ydmVy cz08b3B0aW1pemVkIG91dD4pDQogICAgIGF0IC91c3Ivc3JjL3N5cy9mcy9uZnNzZXJ2ZXIvbmZz X25mc2Rzb2NrZXQuYzoxMzM4DQojMjAgbmZzcnZkX2RvcnBjIChuZD1uZEBlbnRyeT0weGZmZmZm ZTAxNTNiYTM3MTAsIGlzZGdyYW09aXNkZ3JhbUBlbnRyeT0wLA0KICAgICB0YWc9dGFnQGVudHJ5 PTB4ZmZmZmZlMDE1M2JhMzY3MCAiIiwgdGFnbGVuPXRhZ2xlbkBlbnRyeT0wLA0KICAgICBtaW5v cnZlcnM9PG9wdGltaXplZCBvdXQ+KQ0KICAgICBhdCAvdXNyL3NyYy9zeXMvZnMvbmZzc2VydmVy L25mc19uZnNkc29ja2V0LmM6NjMzDQojMjEgMHhmZmZmZmZmZjgwZmJmNTg4IGluIG5mc19wcm9j ICh4aWQ9PG9wdGltaXplZCBvdXQ+LA0KICAgICB4cHJ0PTB4ZmZmZmZlMDE5OWYwYzYwMCwgbmQ9 PG9wdGltaXplZCBvdXQ+LCBycHA9PG9wdGltaXplZCBvdXQ+KQ0KICAgICBhdCAvdXNyL3NyYy9z eXMvZnMvbmZzc2VydmVyL25mc19uZnNka3JwYy5jOjQ2NA0KIzIyIG5mc3N2Y19wcm9ncmFtIChy cXN0PTB4ZmZmZmZlMDBmM2MwNzAwMCwgeHBydD0weGZmZmZmZTAxOTlmMGM2MDApDQogICAgIGF0 IC91c3Ivc3JjL3N5cy9mcy9uZnNzZXJ2ZXIvbmZzX25mc2RrcnBjLmM6MzQ4DQojMjMgMHhmZmZm ZmZmZjgxNzNmY2U2IGluIHN2Y19leGVjdXRlcmVxIChycXN0cD0weGZmZmZmZTAwZjNjMDcwMDAp DQogICAgIGF0IC91c3Ivc3JjL3N5cy9ycGMvc3ZjLmM6MTAzMg0KIzI0IHN2Y19ydW5faW50ZXJu YWwgKGdycD1ncnBAZW50cnk9MHhmZmZmZmUwMGYwNGVjMTAwLA0KICAgICBpc21hc3Rlcj1pc21h c3RlckBlbnRyeT0wKSBhdCAvdXNyL3NyYy9zeXMvcnBjL3N2Yy5jOjEzMDgNCiMyNSAweGZmZmZm ZmZmODE3NDA5NGIgaW4gc3ZjX3RocmVhZF9zdGFydCAoYXJnPTB4NywNCiAgICAgYXJnQGVudHJ5 PTB4ZmZmZmZlMDBmMDRlYzEwMCkgYXQgL3Vzci9zcmMvc3lzL3JwYy9zdmMuYzoxMzM2DQojMjYg MHhmZmZmZmZmZjgxMTEzN2EzIGluIGZvcmtfZXhpdCAoDQogICAgIGNhbGxvdXQ9MHhmZmZmZmZm ZjgxNzQwOTQwIDxzdmNfdGhyZWFkX3N0YXJ0PiwgYXJnPTB4ZmZmZmZlMDBmMDRlYzEwMCwNCiAg ICAgZnJhbWU9MHhmZmZmZmUwMTUzYmEzZjQwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Zv cmsuYzoxMTU3DQojMjcgPHNpZ25hbCBoYW5kbGVyIGNhbGxlZD4NCiMyOCAweDAwMDAzYjRmZjg5 NmYwZGEgaW4gPz8gKCkNCg== From nobody Wed Mar 6 23:00:10 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tqnvw56V9z5Db7q for ; Wed, 6 Mar 2024 23:00:28 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tqnvw2hrSz4b55 for ; Wed, 6 Mar 2024 23:00:28 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6e09143c7bdso209577b3a.3 for ; Wed, 06 Mar 2024 15:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709766026; x=1710370826; 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=aOQ3sKB5J4JCbq9h++JBWi5tdSd6GHgMbRa80AU0xsw=; b=djMMEu3G39bwK4jlo84SYa+r58xyBqNn1FC2nX9xVcJQnM7kQkUlg6ME+lUB2cyvak io7kj9x2jr1zagse+zfkBd2VC/Bg05xpU/dvuEF5kevsyl75V2WGUkoOKLgR9NNTaqo9 FfgImLGwbNSilRtUN6imnYMbbVOyOerkan0n+de8wf4uZNCojU43Ls1/UOIak/7wBZMV Y5rB6MdOEXdzGAcMzFcNOHgSyoeNy/8MN2XoWWWroTiY/1CLRAR4WwSaoWRFPhKgbrhM q/QZlKr1OT+HXkWaLg6ORuCAkMvV1meOxcG1n9oqHCht4apNXPHjpP+Ek9MhQxbdJar5 Vy+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709766026; x=1710370826; 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=aOQ3sKB5J4JCbq9h++JBWi5tdSd6GHgMbRa80AU0xsw=; b=Aeu2MOQzWcEBt+vGJGdiJe7kUezBQJixpYkWO+2z5DHMGYMWLqLb0pkjdsUckHLudb 5FbG6fBIxCdZVfSejr1bKusrnhRjOpeSsavnWTEWqDHfeinAK0rI86P608FIPg8XHjBc O+8zARzmKH+9bCOgAU5RcsVIKzbxywVM4xH4ViPj1AZwgUehHH4/YWKXMWZSrttvUAgM tyue9Hq2OuZEI+Hbn1U6DhA1mPFPEFFnsdlJkH9+yLpA/LPkhqrLuGYFrgnFgaL7VaFk vr8BkBk1zaZeK7qu3G2KbG7gjQ6dzJ4yT4mz+edgAy9uSc03ebInbqnIRwzrMbPzdxzP ZW3A== X-Gm-Message-State: AOJu0YzyZ807gVPE8HDuRDPabLNbTfQizwGuc40OR1IBeSj80MSinDnu Yr7HCmQNUuukJFs02wN6FUzLgiYjKiXj6FNArP7SSRQO003PdtVHlNfYkfUM0oZATqrpzPC/4Xq s9vRAdpDvz3MJ6Sp2BGSK+6hkVA== X-Google-Smtp-Source: AGHT+IFpw7Vru++Z8CFSsmxI6U0BGmVu9G9t5MiTvG+jaJDi/8FxplK4SKAC1L2ndwIaxoW/MIPKQWceuV72em8eHIs= X-Received: by 2002:a05:6a00:ad1:b0:6e6:276a:8ea4 with SMTP id c17-20020a056a000ad100b006e6276a8ea4mr11325528pfl.33.1709766025613; Wed, 06 Mar 2024 15:00:25 -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: Wed, 6 Mar 2024 15:00:10 -0800 Message-ID: Subject: Re: FreeBSD panics possibly caused by nfs clients To: "Matthew L. Dailey" Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Tqnvw2hrSz4b55 On Wed, Mar 6, 2024 at 10:56=E2=80=AFAM Matthew L. Dailey wrote: > > Posting a few updates on this issue. > > I was able to induce a panic on a CURRENT kernel (20240215), built with > GENERIC-KASAN and running kern.kstack_pages=3D6 (default) after ~189 > hours. The panic message and backtrace are below - please reach out > directly if you'd like to have a look at the core. I'm specifically not > increasing kstack_pages to see what effect this has on the panics. > > I have another system running CURRENT (20240215) without any debugging. > I'm able to regularly panic this (7 panics over two weeks with average > uptime of ~42 hours) with kstack_pages=3D4. I set kstack_pages=3D6, and h= ave > also induced several panics. Oddly, this seems to happen more quickly (4 > panics over 2 days with average uptime of ~10.5 hours). > > Another system running CURRENT (20240208), built with GENERIC-KASAN and > running kern.kstack_pages=3D8 has now been running with our hdf5 workload > non-stop since February 10th with no panics or issues. > > From all this, it seems like increasing kstack_pages to 8 eliminates > the panics, but obviously doesn't fix the underlying cause of the > issues. So, although this is an obvious workaround for our production > system, it would be better to find and fix the underlying cause of the > panics. > > I'm going to continue testing to try to generate more cores with > kstack_pages<8 on the system with the debug kernel. > > Any other ideas to try to narrow down the cause are welcome. You might try increasing KSTACK_GUARD_PAGES. I've never done this, but I think it must be done by editting/rebuilding fr= om patched sources. It is in /usr/src/sys/amd64/include/param.h. Typically, when KSTACK_GUARD_PAGES is 1, when the stack grows down into the guard page, a double fault occurs. For your case, it looks like something might be modifying a location that is a ways below (but within the 8 pages) of where the stack is. Increasing KSTACK_GUARD_PAGES to something like 4 and then using the default kstack_pages, it might get the double faults when the wild poin= ter first occurs? Another approach would be to get rid of everything else configured in these test systems, to see if they are involved in the crashes. (I vaguely rememb= er you mentioning packet filtering as one example.) > > Thanks, > Matt > > [680940] Kernel page fault with the following non-sleepable locks held: > [680940] exclusive sleep mutex nfs_state_mutex (nfs_state_mutex) r =3D 0 > (0xffffffff830498e0) locked @ /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c:6= 652 > [680940] stack backtrace: > [680940] #0 0xffffffff8127958f at witness_debugger+0x13f > [680940] #1 0xffffffff8127b114 at witness_warn+0x674 > [680940] #2 0xffffffff81aba0a6 at trap_pfault+0x116 > [680940] #3 0xffffffff81ab901c at trap+0x54c > [680940] #4 0xffffffff81a75988 at calltrap+0x8 > [680940] #5 0xffffffff80fb4bfa at nfsrv_freestateid+0x23a > [680940] #6 0xffffffff80fd5e3f at nfsrvd_freestateid+0x1df > [680940] #7 0xffffffff80f98d35 at nfsrvd_dorpc+0x2585 > [680940] #8 0xffffffff80fbf588 at nfssvc_program+0x1078 > [680940] #9 0xffffffff8173fce6 at svc_run_internal+0x1706 > [680940] #10 0xffffffff8174094b at svc_thread_start+0xb > [680940] #11 0xffffffff811137a3 at fork_exit+0xa3 > [680940] #12 0xffffffff81a769ee at fork_trampoline+0xe > [680940] > [680940] > [680940] Fatal trap 12: page fault while in kernel mode > [680940] cpuid =3D 3; apic id =3D 06 > [680940] fault virtual address =3D 0x7 > [680940] fault code =3D supervisor read data, page not presen= t > [680940] instruction pointer =3D 0x20:0xffffffff80fafd67 > [680940] stack pointer =3D 0x28:0xfffffe0153ba2de0 > [680940] frame pointer =3D 0x28:0xfffffe0153ba2eb0 > [680940] code segment =3D base 0x0, limit 0xfffff, type 0x1b > [680940] =3D DPL 0, pres 1, long 1, def32 0, gran = 1 > [680940] processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > [680940] current process =3D 55202 (nfsd: service) > [680940] rdi: 0000000000000007 rsi: 0000000000000000 rdx: dffff7c00000000= 0 > [680940] rcx: fffffe001b9ec1e8 r8: 0012c43500000002 r9: 0012c4350000000= 2 > [680940] rax: fffffe001b9ec1e8 rbx: ffffffffffffffff rbp: fffffe0153ba2eb= 0 > [680940] r10: 0000000000000004 r11: 0000000000000006 r12: 000000000000000= 7 > [680940] r13: fffffe019cd75700 r14: 0000000000001a1a r15: fffffe019cd7570= 8 > [680940] trap number =3D 12 > [680940] panic: page fault > [680940] cpuid =3D 3 > [680940] time =3D 1709646178 > [680940] KDB: stack backtrace: > [680940] db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame > 0xfffffe0153ba2550 > [680940] kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfffffe0153ba26b0 > [680940] vpanic() at vpanic+0x210/frame 0xfffffe0153ba2850 > [680940] panic() at panic+0xb5/frame 0xfffffe0153ba2910 > [680940] trap_fatal() at trap_fatal+0x65b/frame 0xfffffe0153ba2a10 > [680940] trap_pfault() at trap_pfault+0x12b/frame 0xfffffe0153ba2b30 > [680940] trap() at trap+0x54c/frame 0xfffffe0153ba2d10 > [680940] calltrap() at calltrap+0x8/frame 0xfffffe0153ba2d10 > [680940] --- trap 0xc, rip =3D 0xffffffff80fafd67, rsp =3D > 0xfffffe0153ba2de0, rbp =3D 0xfffffe0153ba2eb0 --- > [680940] nfsrv_freelockowner() at nfsrv_freelockowner+0x97/frame This seems to indicate that a list pointer (the one called ls_list in the nfsstateid structure is bogus). However the other list in the same structur= e (called ls_hash) seems ok, since it would not have gotten here otherwise. Both these lists are set to-gether with the structure is added, so it doesn= 't make sense that one would be bogus, unless some wild pointer overwrote that location, I think? rick > 0xfffffe0153ba2eb0 > [680940] nfsrv_freestateid() at nfsrv_freestateid+0x23a/frame > 0xfffffe0153ba2f70 > [680940] nfsrvd_freestateid() at nfsrvd_freestateid+0x1df/frame > 0xfffffe0153ba3030 > [680940] nfsrvd_dorpc() at nfsrvd_dorpc+0x2585/frame 0xfffffe0153ba3570 > [680940] nfssvc_program() at nfssvc_program+0x1078/frame 0xfffffe0153ba39= 70 > [680940] svc_run_internal() at svc_run_internal+0x1706/frame > 0xfffffe0153ba3ee0 > [680940] svc_thread_start() at svc_thread_start+0xb/frame 0xfffffe0153ba3= ef0 > [680940] fork_exit() at fork_exit+0xa3/frame 0xfffffe0153ba3f30 > [680940] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0153ba3f3= 0 > [680940] --- trap 0xc, rip =3D 0x3b4ff896f0da, rsp =3D 0x3b4ff6a500e8, rb= p =3D > 0x3b4ff6a50380 --- > [680940] KDB: enter: panic > > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > #1 doadump (textdump=3Dtextdump@entry=3D0) > at /usr/src/sys/kern/kern_shutdown.c:403 > #2 0xffffffff805a52f6 in db_dump (dummy=3D, > dummy2=3D, dummy3=3D, dummy4=3D) > at /usr/src/sys/ddb/db_command.c:590 > #3 0xffffffff805a512b in db_command (last_cmdp=3D, > cmd_table=3D, dopager=3Dtrue) > at /usr/src/sys/ddb/db_command.c:503 > #4 0xffffffff805a4b3d in db_command_loop () > at /usr/src/sys/ddb/db_command.c:550 > #5 0xffffffff805aa209 in db_trap (type=3D, code=3D out>) > at /usr/src/sys/ddb/db_main.c:267 > #6 0xffffffff81239f25 in kdb_trap (type=3D3, code=3Dcode@entry=3D0, > tf=3Dtf@entry=3D0xfffffe0153ba25f0) at /usr/src/sys/kern/subr_kdb.c:= 790 > #7 0xffffffff81ab8f88 in trap (frame=3D0xfffffe0153ba25f0) > at /usr/src/sys/amd64/amd64/trap.c:606 > #8 > #9 kdb_enter (why=3D, msg=3D) > at /usr/src/sys/kern/subr_kdb.c:556 > #10 0xffffffff8118fdf1 in vpanic (fmt=3Dfmt@entry=3D0xffffffff82491d20 > "%s", > ap=3Dap@entry=3D0xfffffe0153ba28c0) at > /usr/src/sys/kern/kern_shutdown.c:961 > #11 0xffffffff8118fba5 in panic (fmt=3D0xffffffff82491d20 "%s") > at /usr/src/sys/kern/kern_shutdown.c:889 > #12 0xffffffff81ab9f8b in trap_fatal (frame=3D0xfffffe0153ba2d20, eva=3D7= ) > at /usr/src/sys/amd64/amd64/trap.c:950 > #13 0xffffffff81aba0bb in trap_pfault (frame=3Dframe@entry=3D0xfffffe0153= ba2d20, > usermode=3Dfalse, signo=3Dsigno@entry=3D0x0, ucode=3Ducode@entry=3D0= x0) > at /usr/src/sys/amd64/amd64/trap.c:761 > #14 0xffffffff81ab901c in trap (frame=3D0xfffffe0153ba2d20) > at /usr/src/sys/amd64/amd64/trap.c:440 > #15 > #16 0xffffffff80fafd67 in nfsrv_freelockowner ( > stp=3Dstp@entry=3D0xfffffe019cd75700, vp=3Dvp@entry=3D0x0, > cansleep=3Dcansleep@entry=3D0, p=3Dp@entry=3D0xfffffe0153e2c740) > at /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c:1550 > #17 0xffffffff80fb4bfa in nfsrv_freestateid (nd=3Dnd@entry=3D0xfffffe0153= ba3710, > stateidp=3Dstateidp@entry=3D0xfffffe0153ba2fc0, > p=3Dp@entry=3D0xfffffe0153e2c740) > at /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c:6681 > #18 0xffffffff80fd5e3f in nfsrvd_freestateid (nd=3D0xfffffe0153ba3710, > isdgram=3D, vp=3D, exp=3D) > at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:4764 > #19 0xffffffff80f98d35 in nfsrvd_compound (nd=3D0xfffffe0153ba3710, isdgr= am=3D0, > tag=3D, taglen=3D0, minorvers=3D) > at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:1338 > #20 nfsrvd_dorpc (nd=3Dnd@entry=3D0xfffffe0153ba3710, isdgram=3Disdgram@e= ntry=3D0, > tag=3Dtag@entry=3D0xfffffe0153ba3670 "", taglen=3Dtaglen@entry=3D0, > minorvers=3D) > at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:633 > #21 0xffffffff80fbf588 in nfs_proc (xid=3D, > xprt=3D0xfffffe0199f0c600, nd=3D, rpp=3D) > at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:464 > #22 nfssvc_program (rqst=3D0xfffffe00f3c07000, xprt=3D0xfffffe0199f0c600) > at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:348 > #23 0xffffffff8173fce6 in svc_executereq (rqstp=3D0xfffffe00f3c07000) > at /usr/src/sys/rpc/svc.c:1032 > #24 svc_run_internal (grp=3Dgrp@entry=3D0xfffffe00f04ec100, > ismaster=3Dismaster@entry=3D0) at /usr/src/sys/rpc/svc.c:1308 > #25 0xffffffff8174094b in svc_thread_start (arg=3D0x7, > arg@entry=3D0xfffffe00f04ec100) at /usr/src/sys/rpc/svc.c:1336 > #26 0xffffffff811137a3 in fork_exit ( > callout=3D0xffffffff81740940 , arg=3D0xfffffe00f04= ec100, > frame=3D0xfffffe0153ba3f40) at /usr/src/sys/kern/kern_fork.c:1157 > #27 > #28 0x00003b4ff896f0da in ?? () From nobody Thu Mar 7 13:13:51 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tr8sq2V01z5D0Qm for ; Thu, 7 Mar 2024 13:14:55 +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 (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tr8sn3kzHz4pc0 for ; Thu, 7 Mar 2024 13:14:53 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="G9a/dR5u"; 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=1709817280; 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=celpwFQln5KBaoZDNNdkvhEupUN9/fSiYS/X8B019TA=; b=G9a/dR5uuAmhvqZ76LayPRAqT5O6x3PkuJwdhFGnt+lWHprCvNtWTo6fFE28XtMJnYono2 dUbN0FHmfCyUM5zhQbBAR2K/bIXuLogQ0ls+UH74nfKbMckZwyrjwKDa2e4PM0Wy9YnzXU PK4gInFqBoGpFmlrgx7ReYVMJAKw/NMdEfH7s++PrvxAa1/k6a3XN5o/RYmm+RPgqwFT/M iJXSzuFbZPiEppOtOBk0g8ZbFJew74+Ec5uId9DFdigahOYwpeNS358uuyoY4QYImLF2hg TuHQewcbc+8ClNOJpAg+4oNY0o8WAp5G0FaAQPNDAUo44T8NXN2CAjMqALsYPg== Date: Thu, 07 Mar 2024 14:13:51 +0100 From: Alexander Leidinger To: Current Subject: Reason why "nocache" option is not displayed in "mount"? Message-ID: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_3db30b9a1eac56808d820aaacdb0bf76"; micalg=pgp-sha256 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[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]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; MID_RHS_MATCH_FROM(0.00)[]; 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)[current@freebsd.org]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Tr8sn3kzHz4pc0 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_3db30b9a1eac56808d820aaacdb0bf76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? # grep packages /etc/fstab.commit_leidinger_net /shared/ports/packages /space/jails/commit.leidinger.net/shared/ports/packages nullfs rw,noatime,nocache 0 0 # mount | grep commit | grep packages /shared/ports/packages on /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, local, noatime, noexec, nosuid, nfsv4acls) Context: I wanted to check if poudriere is mounting with or without "nocache", and instead of reading the source I wanted to do it more quickly by looking at the mount options. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_3db30b9a1eac56808d820aaacdb0bf76 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXpvZ8ACgkQEg2wmwP4 2IaQSBAAmMqSVweaxr7iU/alEOf1S14Uq/x7NwwTVe4GRorS//Ljeg8m+8kHLSd0 iNnSZCdWZeVbhv/z8tZ5c3BkAZdD29QlRoutYtp3tlNpkCE0Fmp4bo/Z0AmYoJ31 fsXxETAdX1ygRBL1DMs2zWl8X3T9A2klrMEBTrU/cE/FKLJWOy9WRTpwoNWepKJ1 YynCtWCRDCkuXAPusWGmzcn85sQu9fr6sN7O8Qw75Aaj9K6gDG2SlmVs0sUwLiYa unj5sp32TgrZFPJ7RrOyt2wCSHe14KGH9bRKdpWCVYTR55trxPozjPzhSILm3Uqj xjzlthcQt8LXNkAE8/NDVVK+KpwdbDQvQtiPi3OReo4leMBbLtWhS7ThXQZZViT+ WcHYFf2FSDfVD5ACxUsvBAygM/RLvmZ+qob6H7LQe9jxeBxTzxI+RV9W2ZY9Lwyv 1d81zIKR48JFml03or7boj0XC/jOQJaZqm0+mspI/9sS+0bHgOs6oL2+b/BKi8+h C1sGWrePClj0poPLAsfW7aUoPKbfG+vkl7zPQkzc+UKsAFuxNq8pX64VIg7QjLzK Svm2sDmbZxARfO8ew/u286ycFU83fXsVz3wH1DwtL6uW36wsmxUVAhZo1qTyHvr1 tsEKL4Ydw9AIFPv/P+RBCBysrsi2TPNRl0lOR+byHfetkgjgO5E= =PG58 -----END PGP SIGNATURE----- --=_3db30b9a1eac56808d820aaacdb0bf76-- From nobody Thu Mar 7 13:59:48 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tr9sj4pWfz5D44b for ; Thu, 7 Mar 2024 13:59:53 +0000 (UTC) (envelope-from chris@cretaforce.gr) Received: from relay2.cretaforce.gr (relay2.cretaforce.gr [195.201.253.149]) (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 "*.cretaforce.gr", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tr9sh23Vpz4tYB for ; Thu, 7 Mar 2024 13:59:52 +0000 (UTC) (envelope-from chris@cretaforce.gr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cretaforce.gr header.s=cretaforce header.b=NGZcKaI3; dmarc=pass (policy=none) header.from=cretaforce.gr; spf=pass (mx1.freebsd.org: domain of chris@cretaforce.gr designates 195.201.253.149 as permitted sender) smtp.mailfrom=chris@cretaforce.gr Received: from server1.cretaforce.gr (server1.cretaforce.gr [94.130.217.104]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.cretaforce.gr", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by smtp2.cretaforce.gr (Postfix) with ESMTPS id D82AC200E7 for ; Thu, 7 Mar 2024 15:59:58 +0200 (EET) Received: from smtpclient.apple (ppp-2-87-82-142.home.otenet.gr [2.87.82.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: chris@cretaforce.gr) by server1.cretaforce.gr (Postfix) with ESMTPSA id 8240CD2E7 for ; Thu, 7 Mar 2024 15:59:49 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cretaforce.gr; s=cretaforce; t=1709819992; 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=5wPqLJ7mgSruUAbU0zkf9NLpTHwVhYrAM+M97IkDXp4=; b=NGZcKaI38QHm4u6wqYu/XSJt6ARccXH+noG36s+1Duph3Sebj7f9Duu0ZRw0MsjQ/++FeU chCsOf8zhoWXsVqSFKwU7sHkSKtqp4QWRL6wC7Qm2oeSs3DIcLOZwofZHAn2/lGjUh22zX EC/xtmuZMFr9HtU9oFAWqyQHPFBkJQ4= From: Christos Chatzaras Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Reason why "nocache" option is not displayed in "mount"? Date: Thu, 7 Mar 2024 15:59:48 +0200 References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> To: Current In-Reply-To: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> Message-Id: <22017329-8EA9-4477-B5DB-412ABA34788D@cretaforce.gr> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; DWL_DNSWL_LOW(-1.00)[cretaforce.gr:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[cretaforce.gr,none]; R_SPF_ALLOW(-0.20)[+ip4:195.201.253.149]; R_DKIM_ALLOW(-0.20)[cretaforce.gr:s=cretaforce]; RCVD_IN_DNSWL_LOW(-0.10)[195.201.253.149:from]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[cretaforce.gr:+]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[chris]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Tr9sh23Vpz4tYB > what is the reason why "nocache" is not displayed in the output of = "mount" for nullfs options? >=20 > # grep packages /etc/fstab.commit_leidinger_net > /shared/ports/packages = /space/jails/commit.leidinger.net/shared/ports/packages nullfs = rw,noatime,nocache 0 0 >=20 > # mount | grep commit | grep packages > /shared/ports/packages on = /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, local, = noatime, noexec, nosuid, nfsv4acls) >=20 > Context: I wanted to check if poudriere is mounting with or without = "nocache", and instead of reading the source I wanted to do it more = quickly by looking at the mount options. In my setup, I mount the /home directory using nullfs with the nocache = option to facilitate access for certain jails. The primary reason for = employing nocache is due to the implementation of ZFS quotas on the main = system, which do not accurately reflect changes in file usage by users = within the jail unless nocache is used. When files are added or removed = by a user within jail, their disk usage wasn't properly updated on the = main system until I started using nocache. Based on this experience, I'm = confident that applying nocache works as expected in your scenario as = well.= From nobody Thu Mar 7 14:09:19 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrB530nYzz5D53c for ; Thu, 7 Mar 2024 14:09:43 +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 (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TrB524bzCz3x0y for ; Thu, 7 Mar 2024 14:09:42 +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=1709820577; 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=pIczKGM0K3VexoXH1z4LhOyd5J6DbXAa8hTE+k+w6FQ=; b=UovWRMpkPzSpR1hCSvfMCkFEdKwnZpdbhEItBmPXfsq5Q4T3aPCpIhMMOI3bAmvmdyT0Se m0IluDnNP6rTRptUlgorwUy58K4eM2ZdI3aJxRhIYcpyOsWzvV0UW2Jr8bCaUwpOSbKcqK aMLK2ytyWfboA1WQtReldm946WbR3MtiuwMimsbtWKLLM4kHv3Hfx7oZ3F1xM7kTuGDj7z cEKeCr9z2UEJHhZLYo+tRkckOe9nMMTRjdmChfMZSw1qBeU8UR/ww2u93GwzyTtK0l+7Ag JexSqkJ2bpMJ56SKjO0vOctMQ0PPJm1dJu5BEb4wnFF4mRxEJrUsiZZCkoD9bg== Date: Thu, 07 Mar 2024 15:09:19 +0100 From: Alexander Leidinger To: Christos Chatzaras Cc: Current Subject: Re: Reason why "nocache" option is not displayed in "mount"? In-Reply-To: <22017329-8EA9-4477-B5DB-412ABA34788D@cretaforce.gr> References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <22017329-8EA9-4477-B5DB-412ABA34788D@cretaforce.gr> Message-ID: <0fc7f06e0d58f95c43198630e0895232@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_8b8d1a49efb7536f4fe6706c064f4810"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4TrB524bzCz3x0y This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_8b8d1a49efb7536f4fe6706c064f4810 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-03-07 14:59, schrieb Christos Chatzaras: >> what is the reason why "nocache" is not displayed in the output of >> "mount" for nullfs options? >> >> # grep packages /etc/fstab.commit_leidinger_net >> /shared/ports/packages >> /space/jails/commit.leidinger.net/shared/ports/packages nullfs >> rw,noatime,nocache 0 0 >> >> # mount | grep commit | grep packages >> /shared/ports/packages on >> /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, >> local, noatime, noexec, nosuid, nfsv4acls) >> >> Context: I wanted to check if poudriere is mounting with or without >> "nocache", and instead of reading the source I wanted to do it more >> quickly by looking at the mount options. > > In my setup, I mount the /home directory using nullfs with the nocache > option to facilitate access for certain jails. The primary reason for > employing nocache is due to the implementation of ZFS quotas on the > main system, which do not accurately reflect changes in file usage by > users within the jail unless nocache is used. When files are added or > removed by a user within jail, their disk usage wasn't properly updated > on the main system until I started using nocache. Based on this > experience, I'm confident that applying nocache works as expected in > your scenario as well. It does. The question is how to I _see_ that a mount point is _setup_ with nocache? In the above example the FS _is_ mounted with nocache, but it is _not displayed_ in the output. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_8b8d1a49efb7536f4fe6706c064f4810 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXpyp4ACgkQEg2wmwP4 2IYz4A//Ub8GLbwayEJ0E1G928O3DVv0oGso7Y9mtbMOW59LD/6bCCWg4+GrrfUg QcAPP/W46Nf7hVgBgDCxm7HdjWyHp5ZiOEFW0CjqyXgBKBEokfbkZE/2SATDBaZI zffn7O5fDAaLqrRkDdPRpzQZQ6t0ks5lHIuatUA+oVXmWxYx4Sp72EAgzTwdGAFq XAywc2IGK9TnvBqOKkSvI2IoOhiFdl/WBiiIfQtP/TfVjazRJQme3TFBC/JnODus AuIItjz8h+oVvXdqG0JcgQOPatAhYBW8j7cw1V41kjr2sNfEBZc7ZVIFGsGxt6Ct 3WFvvwQ/OH3OD6vo9GghRUnkDZG46Tf7lHaZ4msqDK7StGxAY8igOwBv2A0BaGE2 GZBjNayxk9dHjSnHQ/4BLMkyqmOGeEn0Vqd8PGR+zGSYGv9tkFQGX7aL99DqtCMi 1qt9rOpfMJhjUJYglCpth267wpTL5GlU+KplkqEGZAO02lSHVXcOTjz6o4Uu9ZLd nyQi/dwsOxJ+jYeMHycjY13uVtJrMstxzg+3uVZDXIIogLLkCOmLBaRZzbOxETgb Sfga23Eoi/6cYQuGHHSGWPuoxAL2htWYy/4pezDOieNmvZYjxxGIPAh44j8iyqzq NNew5pBxqhH2s+RAFK4j1+u0dJ/U2sz/tmsgHNJZKg4UFwSs4lI= =Hqe9 -----END PGP SIGNATURE----- --=_8b8d1a49efb7536f4fe6706c064f4810-- From nobody Thu Mar 7 18:15:48 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrHRt5g5fz5DXtM for ; Thu, 7 Mar 2024 18:11:22 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TrHRr2z0Vz4Qtf for ; Thu, 7 Mar 2024 18:11:19 +0000 (UTC) (envelope-from pj@smo.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=N4vbRaiF; dmarc=pass (policy=reject) header.from=smo.de; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de Received: from [192.168.153.212] (p4fe02148.dip0.t-ipconnect.de [79.224.33.72]) by mail.adebahr.de (Postfix) with ESMTPSA id 569CF600BB; Thu, 7 Mar 2024 19:11:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smo.de; s=mail; t=1709835068; 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=S0Vme2DzNpMZXn3jVrfOIquABt3nlU+0FPza0yAaDss=; b=N4vbRaiFaq3SAmrQ7a9Lb3A3AHpxXCd/hr/hsjXfoX/6HhrKp4mUl+RBK9fXOvZiGRLJSx pVlvKeb05orLOlReiRqRzlcedcfGGL2xdT/1qMIrAZH0JnJtWKbJMvfE9MUhUIuq1mydT+ JcnSv2pQdz58mClzkf1jVU492UaL9a5fIbrPyUeob8lbjkQIWPsDjFmw/gyv/E/vpHFXHY S1pZpk4dJ5ziufvS9NXf5f8zkvOj25gGf3YRsfn13P/+bQ1lxEYczDrfButKFJmbT8Y0Kv FsQhOEZFSP6fVwK6YYVAwOa8qQLyW2PfN2d7T8I5QfliOJGJ3T5qv2KAo/bmRw== Message-ID: <283774ec-156b-4bc8-850d-261ea0e0ed07@smo.de> Date: Thu, 7 Mar 2024 19:15:48 +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: Unable to boot -CURRENT on Thinkpad P16s G2 From: Philipp Ost To: current@freebsd.org Cc: Klaus-Dieter Ost References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- 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(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[smo.de,reject]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:212341, ipnet:185.66.176.0/22, country:DE]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[smo.de:+] X-Rspamd-Queue-Id: 4TrHRr2z0Vz4Qtf On 2/28/24 21:10, Philipp Ost wrote: [boot log stripped] > Does anyone have any suggestions on how to proceed at this point? [...] Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case it matters). Best Philipp From nobody Thu Mar 7 20:05:08 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrKzB5VZDz5Djnc for ; Thu, 7 Mar 2024 20:05:10 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TrKzB1YqFz4h6l for ; Thu, 7 Mar 2024 20:05:09 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: current@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 427K58h4014924; Thu, 7 Mar 2024 20:05:08 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 427K58KX014923; Thu, 7 Mar 2024 20:05:08 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> Date: Thu, 07 Mar 2024 20:05:08 +0000 Organization: Dyslexic Fish To: current@FreeBSD.org, Alexander@Leidinger.net Subject: Re: Reason why "nocache" option is not displayed in "mount"? References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> In-Reply-To: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 07 Mar 2024 20:05:08 +0000 (GMT) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] X-Rspamd-Queue-Id: 4TrKzB1YqFz4h6l Alexander Leidinger wrote: > Hi, > > what is the reason why "nocache" is not displayed in the output of > "mount" for nullfs options? Good catch. I also notice that "hidden" is not shown either. I guess that as for some time, "nocache" was a "secret" option, no-one update "mount" to display it? From nobody Thu Mar 7 20:09:13 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrL3t57Xwz5DkBP for ; Thu, 7 Mar 2024 20:09:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TrL3t0T9Gz4jMX for ; Thu, 7 Mar 2024 20:09:13 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:7400:8808:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Catflap-Envelope-From: X-Catflap-Envelope-To: current@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 427K9DFa014951; Thu, 7 Mar 2024 20:09:13 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 427K9DFG014950; Thu, 7 Mar 2024 20:09:13 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202403072009.427K9DFG014950@donotpassgo.dyslexicfish.net> Date: Thu, 07 Mar 2024 20:09:13 +0000 Organization: Dyslexic Fish To: current@FreeBSD.org, Alexander@Leidinger.net Subject: Re: Reason why "nocache" option is not displayed in "mount"? References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> In-Reply-To: <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 07 Mar 2024 20:09:13 +0000 (GMT) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.67 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US]; FREEFALL_USER(0.00)[jamie]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@FreeBSD.org] X-Rspamd-Queue-Id: 4TrL3t0T9Gz4jMX Jamie Landeg-Jones wrote: > Good catch. I also notice that "hidden" is not shown either. Sorry, I meant mount option "ignore" not "hidden". From nobody Thu Mar 7 23:49:53 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrQyf5ZCqz5CLPx for ; Thu, 7 Mar 2024 23:50:02 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from aws.ambrisko.com (aws.ambrisko.com [100.20.204.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ambrisko.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TrQyf2kg4z469c for ; Thu, 7 Mar 2024 23:50:02 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Authentication-Results: mx1.freebsd.org; none Received: from ambrisko.com (localhost [127.0.0.1]) by aws.ambrisko.com (8.17.2/8.17.2) with ESMTPS id 427Nnslm024936 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 Mar 2024 15:49:54 -0800 (PST) (envelope-from ambrisko@ambrisko.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ambrisko.com; s=default; t=1709855394; bh=uqwmsr/TU5C14jh03sI/Xmyd2FkahRvJukpV0O1OK4E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XCvY+74+Qh4IL8IoOfo13YtLjnb6gYM9K5ETatggd8DGcqKzfxpIEwBjqB75QlJjX S1g9HJtAoWl1aILM6n0RsOEz2wmPKH6ACkzqvXb8fa0Re3w9fPSBrPtUcuAgY9WpTG 7TLPDadzX2qNq2Ow5KcDNz0Nn5aLimCXlOoot03s= X-Authentication-Warning: aws.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.2/8.17.2/Submit) id 427NnrMb024935; Thu, 7 Mar 2024 15:49:53 -0800 (PST) (envelope-from ambrisko) Date: Thu, 7 Mar 2024 15:49:53 -0800 From: Doug Ambrisko To: Philipp Ost Cc: current@freebsd.org, Klaus-Dieter Ost Subject: Re: Unable to boot -CURRENT on Thinkpad P16s G2 Message-ID: References: <283774ec-156b-4bc8-850d-261ea0e0ed07@smo.de> 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: <283774ec-156b-4bc8-850d-261ea0e0ed07@smo.de> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:100.20.0.0/14, country:US] X-Rspamd-Queue-Id: 4TrQyf2kg4z469c On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote: | On 2/28/24 21:10, Philipp Ost wrote: | [boot log stripped] | > Does anyone have any suggestions on how to proceed at this point? [...] | | Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us | to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case | it matters). UARTS on AMD can be a bit different. Some BIOS implementations seem to set them up to work like legacy ports others do not. On a Naples platform I helped add support for them since they were not setup in the legacy configuration. The AMD servers I'm using now have them setup in legacy mode and just work like on other systems. If I remember right those UARTS were defined in ACPI. On a laptop they probably don't have serial ports and the probe is getting stuck on something. It might be good to instrument it to see what. Thanks, Doug A. From nobody Fri Mar 8 00:26:52 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrRnR2Ny7z5CPvX for ; Fri, 8 Mar 2024 00:27:07 +0000 (UTC) (envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TrRnR0PGSz4BGj for ; Fri, 8 Mar 2024 00:27:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-567fbbd723cso295243a12.3 for ; Thu, 07 Mar 2024 16:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1709857624; x=1710462424; 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=UXUK9k3Ho7083h1bZqGvVmqu5CthXYiVm6wQcY2/Bdo=; b=h5tjpNBIoyWbP2qGtxVnkLlIN8Qqqn5bFzZKj5MXGg3ofJimcBUAmYchHzLk4VpPKt H9ZXcnhmpUGnC/PhgWlCh+cxrph/L3AmEcyvJDA4EEbm8Z7Vbux9em2tr6vxmrh4hEzD PUGSzXumSq9qs5GEdIB2bQ8R/B/U4zmVyhXj4Ksi8U8Zx6vwYBSEFj4s+3w2tkRXjXcb YFjTOH9IIH6sua9HTg44z38XzbccncZl0NAcy/gTSO4gkpvt0mZBfTP40x9XnVc+gj2W NDAoDVgVF3oeeWoggMM5ux5QBfJjMN+Benbe8EbwrTDhgQs3pS6hV6yj6hhpX5R1qTHv pGPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709857624; x=1710462424; 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=UXUK9k3Ho7083h1bZqGvVmqu5CthXYiVm6wQcY2/Bdo=; b=v695IVWcMSaQp8xxgJfOX6HCldt5C/nfhPL3VyLfj8eWrpjRuPPDRymh5SXQQSreqr zsUSs+8tX40TXDqFImZI5wHNayCRmENO2Uo0D05yFya9S9mGKRcwEJBe1NUu0VHBNtAY vKqKHbJFWEnBv4yEua0cAMkFQrHqr1QyDDAydhbn7vNP54AgYmrshjBhTRppMwbQ0XPa OzdQZXGdzOljAV5sQ8Za+XEv/4KjHaia7PGtA3k5a4AML9BDmGM8viylOujQDXW6cNY5 sw0WHJHUoiuZB28sCt9hgFW+SxX24Sc9u7HGPXsklGFncT4YwoUdeVPaKvNzM4PMFJWG 2wkA== X-Forwarded-Encrypted: i=1; AJvYcCVACDaJ1Q17SbL+QDArl/m0mYgde7zBxAnFwDVtyoW+sOqhre7vAwqVbkNi5i5qGbs2zYUgYZBiYv/mJNb52oSIODvF X-Gm-Message-State: AOJu0Ywt74xlAGFwxpuPCUX4LhAsxVnXBeNWIjFpuCuFg5yemi+7EqpO ZE43KCwIQ5TNnbKmgoHZNcP7Z2bGNDtF/Re8+lggk9k+XnpQ2bppsTSK9QQPC/zWNzPw7hArzZC URiO4PH4y+eMjVSBFGenxqmB7AcCC/e0qnYXu7difBgAwxNHP+qY= X-Google-Smtp-Source: AGHT+IEVuK3G1gugJdMio6aP4q+ozHEEWqDNoUvijNNa4LqcMniYJKjU/pyqsE+ojlwdVyGvnR/1xqP6kM0PGM2r3Ok= X-Received: by 2002:a17:906:a896:b0:a45:bcac:c7e0 with SMTP id ha22-20020a170906a89600b00a45bcacc7e0mr3795435ejb.65.1709857623717; Thu, 07 Mar 2024 16:27:03 -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: <283774ec-156b-4bc8-850d-261ea0e0ed07@smo.de> In-Reply-To: From: Warner Losh Date: Thu, 7 Mar 2024 17:26:52 -0700 Message-ID: Subject: Re: Unable to boot -CURRENT on Thinkpad P16s G2 To: Doug Ambrisko Cc: Philipp Ost , current@freebsd.org, Klaus-Dieter Ost Content-Type: multipart/alternative; boundary="0000000000004756a206131b4017" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4TrRnR0PGSz4BGj --0000000000004756a206131b4017 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 7, 2024 at 4:50=E2=80=AFPM Doug Ambrisko wrote: > On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote: > | On 2/28/24 21:10, Philipp Ost wrote: > | [boot log stripped] > | > Does anyone have any suggestions on how to proceed at this point? [..= .] > | > | Short follow-up: disabling uart0 and uart1 at the loader prompt allowed > us > | to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in > case > | it matters). > > UARTS on AMD can be a bit different. Some BIOS implementations seem > to set them up to work like legacy ports others do not. On a Naples > platform I helped add support for them since they were not setup > in the legacy configuration. The AMD servers I'm using now have them > setup in legacy mode and just work like on other systems. > > If I remember right those UARTS were defined in ACPI. On a laptop they > probably don't have serial ports and the probe is getting stuck on > something. It might be good to instrument it to see what. > It might also be time to finally drop the UART fallback when ACPI is present. I've seen spotty reports of accessing these registers (for uart, kbd and maybe mouse) causing problems. The ACPI definition of the UARTs would be additional uart units. The fallback stuff is needed only for extremely edge cases at this point. Warner --0000000000004756a206131b4017 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2024 at 4:50=E2=80=AFP= M Doug Ambrisko <ambrisko@ambri= sko.com> wrote:
On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote:
| On 2/28/24 21:10, Philipp Ost wrote:
| [boot log stripped]
| > Does anyone have any suggestions on how to proceed at this point? [.= ..]
|
| Short follow-up: disabling uart0 and uart1 at the loader prompt allowed u= s
| to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in cas= e
| it matters).

UARTS on AMD can be a bit different.=C2=A0 Some BIOS implementations seem to set them up to work like legacy ports others do not.=C2=A0 On a Naples platform I helped add support for them since they were not setup
in the legacy configuration.=C2=A0 The AMD servers I'm using now have t= hem
setup in legacy mode and just work like on other systems.

If I remember right those UARTS were defined in ACPI.=C2=A0 On a laptop the= y
probably don't have serial ports and the probe is getting stuck on
something.=C2=A0 It might be good to instrument it to see what.

It might also be time to finally drop the UART fal= lback when ACPI is present.
I've seen spotty reports of acces= sing these registers (for uart, kbd and maybe
mouse) causing prob= lems. The ACPI definition of the UARTs would be additional
uart u= nits. The fallback stuff is needed only for extremely edge cases at this po= int.

Warner

--0000000000004756a206131b4017-- From nobody Sat Mar 9 05:07:07 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ts9yM2wQBz5CsVW for ; Sat, 9 Mar 2024 05:07:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ts9yL5BPrz4r3D for ; Sat, 9 Mar 2024 05:07:22 +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=aXzOGqdv; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::634) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a36126ee41eso378599066b.2 for ; Fri, 08 Mar 2024 21:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1709960839; x=1710565639; 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=UXGRtcXOmabz1QlClhmq5rwxDH+LWuCL1GkT9+Ss0bs=; b=aXzOGqdvTC5vl/CsheZBnt2a+0cEzGQv3UdQjwxFA1DvAu17n4pR6gU5vJQE2sD2mb V9+GJntc8oHiA7oXcq7OmYvs1/vss2P0GYQ7/1jK3E5OZLl0I2lRiP0OiC5AChO6OZmL HCk9gi1GkO+OjeGeLSLuAqxKHoGTk5Y0cqrVtb/JJZ1VM/92NKYJ63YYhrM3rl/NFpdS oYmVMZ7niH95uvTIIcy46mX36iOOsqIvBKTLJBa97xiWNlHU3uILDZHzHy1NlX1s4GWQ MwLHsA6b6Jbr+X1aaI/EjYrO4TRkhZOR7yRJ/CEDppCkN6w7gXdpGga6TzRe2Z3vhyGY 6Bbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709960839; x=1710565639; 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=UXGRtcXOmabz1QlClhmq5rwxDH+LWuCL1GkT9+Ss0bs=; b=asVdoFixMzgGoxRcMyvfQ327B+73/OviutT9EHWjClM8c10KadiLKywJ6Le4v0A4xH hupsKaHHfHbTzeLVHESsQacZkNdjaMV+C0B3EIMZvbQ0Fnk80E4Ki5w7+QYrTmZ1ec6C QSxb3H0TAvjj7oDI1EDnrrqLgJ7B5FB47K74M7OEMHT8Lnj8AHEmj+VGmdi9V//lDjTy YQDF6HrFUIpt7cIr049aI2KRC1mLCkx16aiuLmslCE1MbW921wykToQN2YLRkJIncOhy iewCNhOnpbAD16Pmb88sGpEw+cNPxPKXkt6DI/SyslqD1ILFMBvQx9WbEL7XLRK6MsnK j5RQ== X-Gm-Message-State: AOJu0YzNThaLF+WzpE5zFiVYOlkrcx0kIPLaLshQ1SytA0FapDn5aGB+ iBfxyFApFvK0glaY97OIcSuxNTJ/i9sNmGsVouk4RUPmlQoMEkwEUnQ1SRSQLgmDf4/iUlHJ1+U UxbFV8P4aY5N17SCfPdw5P2O6/uHcmgi765b4bw== X-Google-Smtp-Source: AGHT+IF/gbMF1zKwy1RCvIJIjCw/nS0SNMYdi2dt29EzWimom5kBhyuyM5KnSi1WMmPjhkGPSZGv2WxWzgkjlXcaQWI= X-Received: by 2002:a17:907:8b8b:b0:a3e:7cf7:2fb7 with SMTP id tb11-20020a1709078b8b00b00a3e7cf72fb7mr412327ejc.33.1709960839165; Fri, 08 Mar 2024 21:07: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: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> In-Reply-To: <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> From: Warner Losh Date: Fri, 8 Mar 2024 22:07:07 -0700 Message-ID: Subject: Re: Reason why "nocache" option is not displayed in "mount"? To: Jamie Landeg-Jones Cc: current@freebsd.org, Alexander@leidinger.net Content-Type: multipart/alternative; boundary="000000000000661900061333488d" X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4Ts9yL5BPrz4r3D --000000000000661900061333488d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 7, 2024 at 1:05=E2=80=AFPM Jamie Landeg-Jones wrote: > Alexander Leidinger wrote: > > > Hi, > > > > what is the reason why "nocache" is not displayed in the output of > > "mount" for nullfs options? > > Good catch. I also notice that "hidden" is not shown either. > > I guess that as for some time, "nocache" was a "secret" option, no-one > update "mount" to display it? > So a couple of things to know. First, there's a list of known options. These are converted to a bitmask. This is then decoded and reported by mount. The other strings are passed to the filesystem directly. They decode it and do things, but they don't export them (that I can find). I believe that's why they aren't reported with 'mount'. There's a couple of other options in /etc/fstab that are pseudo options too. Warner --000000000000661900061333488d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2024 at 1:05=E2=80=AFP= M Jamie Landeg-Jones <jamie@catflap= .org> wrote:
Alexander Leidinger <Alexander@Leidinger.net> wrote:

> Hi,
>
> what is the reason why "nocache" is not displayed in the out= put of
> "mount" for nullfs options?

Good catch. I also notice that "hidden" is not shown either.

I guess that as for some time, "nocache" was a "secret"= option, no-one
update "mount" to display it?

So a couple of things to know.

First, there's= a list of known options. These are converted to a bitmask. This is then de= coded and reported by mount. The other strings are passed to the filesystem= directly. They decode it and do things, but they don't export them (th= at I can find). I believe that's why they aren't reported with '= ;mount'. There's a couple of other options in /etc/fstab that are p= seudo options too.

Warner
--000000000000661900061333488d-- From nobody Sat Mar 9 05:40:43 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsBhz0272z5CvsL for ; Sat, 9 Mar 2024 05:40:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsBhx6m7nz4vdj for ; Sat, 9 Mar 2024 05:40:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=d2BDRTBa; 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::52c as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5e4f79007ffso319830a12.2 for ; Fri, 08 Mar 2024 21:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709962848; x=1710567648; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=sYj2oYDhRwMTmGJMBRHngUdQIWprGevVRqFY5GkLlMM=; b=d2BDRTBaRof0A/WoCYQinwNRqFKj0/FGJ5f4Z4wIykyg1vtW9VEblpJI+3gfmDN9Xo kwSGBreAtZ77GWxAb35dbXfwi5vkHiYFqx92riNfX7PafHQtLi/ASXKsEfoD0TFnkEmq 1HroWiww5OZmhVQ4UJv4Uwqm5hr1PnDHifDWxVyMEC8P50EaGIhC+VbBzplCXfKEzdKs NtLfwUu2kcJirV5H5yR/Lvjw+gaX+EYJAMYc/Dz/uv3mQwokSc6NPqFFFvxamVfVOfdd DMzwfqAkkhIejFev1whBatS+1NrsszpViOeQtzTAW9AyHYlyP8PN6hDlk1o6tO7YIAeA PsBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709962848; x=1710567648; h=in-reply-to:content-transfer-encoding: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=sYj2oYDhRwMTmGJMBRHngUdQIWprGevVRqFY5GkLlMM=; b=XAV0YCvZ1+Y0QHvsOsOBxJy+rdRglyGqbyK7gYYqB/QYk5tXbRy8Oqb6AnmFb25Rk9 Ahx65Rh9Wgqa5YNF3kQtSLT2sWPaxYgMaJ/fmFTOosIBGiej+mIZzkKiLlty4jcFdnxr 9Pwnmcqw2IcqWf+JCcweL5+GtqW6BR3/fxbgnjbUgs6Qt9kyIiC6NfxUEtnsN/+tp1YG KHjsIZxq350tNrp1iD4itZsewzMX/NcDzyCNxhawy5Xp+GOlXWdCJELSF0yIcduowuZA vwZbuEw0qvIfVfmmlokYPF0nsOc27t9jPs+unyUHDOco1og/VxxNZIa+/sqVHZuQrXZW Go5w== X-Gm-Message-State: AOJu0Yym1pqhlpBazEbPcrCdOnnywpzU6/mYShQtwx38+Ut/QOgfM0Ga gfv5T09foHYPo73F9mKrtUyeZC9g0El4ig/jDbMPfOpQDqhJ7/wU1RDvki6E X-Google-Smtp-Source: AGHT+IGfdcuarTwOhCTEeCYcYkWlxBCa3afnG+eBM9X+pnVdbqTRgtmMaQ11NqD/lHydlu2aM/dJHA== X-Received: by 2002:a05:6a20:1605:b0:1a1:7e9c:fe96 with SMTP id l5-20020a056a20160500b001a17e9cfe96mr982671pzj.19.1709962848354; Fri, 08 Mar 2024 21:40:48 -0800 (PST) Received: from framework (223-140-45-220.emome-ip.hinet.net. [223.140.45.220]) by smtp.gmail.com with ESMTPSA id g4-20020a056a0023c400b006e5db93342asm552978pfc.208.2024.03.08.21.40.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 21:40:47 -0800 (PST) Date: Sat, 9 Mar 2024 00:40:43 -0500 From: Mark Johnston To: John Nielsen Cc: current@freebsd.org Subject: Re: Kernel build broken without "options KTRACE" Message-ID: References: <9E2E20A1-3A46-461A-B930-94EFEA6249BA@jnielsen.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9E2E20A1-3A46-461A-B930-94EFEA6249BA@jnielsen.net> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.59 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; 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]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; 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)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[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::52c:from] X-Rspamd-Queue-Id: 4TsBhx6m7nz4vdj On Wed, Mar 06, 2024 at 10:51:05AM -0700, John Nielsen wrote: > Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when doing a buildkernel for a config file without “options KTRACE”. I failed to copy the full error message/line numbers but I will reproduce this evening if needed. I've fixed this in the main branch. Thanks for the report. From nobody Sat Mar 9 09:52:25 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsJHL5FBMz5CpZ5 for ; Sat, 9 Mar 2024 09:52:30 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsJHK399Sz4LWG for ; Sat, 9 Mar 2024 09:52:29 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XOCdyvqb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-51340e89df1so3116460e87.1 for ; Sat, 09 Mar 2024 01:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709977947; x=1710582747; darn=freebsd.org; h=content-transfer-encoding:subject:autocrypt:from:content-language :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=scyyPF74eqryDiAqpLHytOf/iP0icapMUuo7oZB1Gos=; b=XOCdyvqbfeYK54oMfJVNlFZl47G75YIVwGtu43+JHl13xTjlCojA16CPPYhyMFkWk8 py+sVUJYkkwsvCcVDHuyqP3KDQxPPsEkL4ZxVP20Cs/SY2Wl0sPx1WnPr+2Db+ANadaM 0PkznHZrPm1N9vTwDVSTwmsBadt3ctDuL4UpBOdNKplH5KUEqJhPpV47CMt41NEoaWWN Hf2d/kCMPVtc0IOQodN9twV9kzjtooZ8FTjpTKA58/GcTbf6nH7pbyNZxJuf3iPUSbbR PJz7YlDYm8VyZUYiv9krMugkmZl8yqFaGp7sohdXf7YSGpXd/hVDODjFwsGcUXfw8QBY LOOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709977947; x=1710582747; h=content-transfer-encoding:subject:autocrypt:from:content-language :to:user-agent:mime-version:date:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=scyyPF74eqryDiAqpLHytOf/iP0icapMUuo7oZB1Gos=; b=ZfKGiZ0W5c3rhKruJRGd1hStzUzZm8ZZtNtnDOxa2k7+yWF4ocUHci2v0AuyXzrjc9 T5f2Rs17DFDU8HgZdvQS3aAM/8SMNj0IaqrQZDljrASXHTbWS6sabMdziMSU7qQNst5g +a/V5Wm1n+tin6FaS+O1nHZdeOJE9w/Xp7ez1sK/kHaVsOn2jV9eausniRZu1E++XlHV iieJoLQqRJ39ZcRyCsC2tYJs91bOzh4fTiTquWoTOay7PHrnO5vzKSLJ9cbda/jQ1O6q JQBFjTGUleZ0IAiXw+V77cGqtldzw/CPToIm1BToGsVwnuKgMty2hh0aXo8PXvUsYi36 C8oQ== X-Gm-Message-State: AOJu0Yw9pgULlURZPm0TR+zksi20xdThhb4P8kDQvwU/L+4072RpKrZd +mL92Mq6EJ/pXlKu3GI5du1NbmxgsMVBsda/n7IG+hBJSLW4uUTI7FSO+oilZ+c= X-Google-Smtp-Source: AGHT+IEHMPCagVlMh5M5nQU37hvj35jMKmhXZpu/zVPaNbNp32M4Jojs/WDPn14Uwtt40lyjpEkFvw== X-Received: by 2002:a05:6512:3d09:b0:513:8a39:e0d9 with SMTP id d9-20020a0565123d0900b005138a39e0d9mr1122920lfv.64.1709977947276; Sat, 09 Mar 2024 01:52:27 -0800 (PST) Received: from [192.168.1.10] (host-92-22-93-189.as13285.net. [92.22.93.189]) by smtp.gmail.com with ESMTPSA id bg13-20020a05600c3c8d00b00412fe0eb806sm8507966wmb.14.2024.03.09.01.52.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Mar 2024 01:52:26 -0800 (PST) Message-ID: Date: Sat, 9 Mar 2024 09:52:25 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: FreeBSD-CURRENT Content-Language: en-GB From: Graham Perrin Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= Subject: Boot failure, amd64 (HP EliteBook 650 G10) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.953]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from] X-Rspamd-Queue-Id: 4TsJHK399Sz4LWG amd64. AFAICT the EliteBook 650 G10 was introduced around May 2023. Does anything in the three photographs tally with a report in Bugzilla? Any overlap with for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))? From nobody Sat Mar 9 13:07:10 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsNd822G9z5D7xf for ; Sat, 9 Mar 2024 13:08: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 (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsNd74F2tz4jBL for ; Sat, 9 Mar 2024 13:08: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=1709989678; 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=Pql17oWXoYRgHwyK6IBC7StGDTdos31qHbxcad5Boe4=; b=y+F8Mswor4OjYZFp0lYPi/GNg63myN8aqI/tGxe9nfoyGmRwZfdb5VjJotTS/kAW3+EY8s UblB1Qx5fZj3S8iLK+/+M3wMdCblzX16z8uLLtVPS16cxmdPqlJkmKbhQCukTr6DOFLR50 unQczUtUmlgKL8LpC63ZJqOChAsDfKv8hV3wbUcIABy6+HXyCA3Tpe15CDBiDifOvUPbaL 3qnuNHjQYYR5MD36pDue/28RRlX2toCgigR5HM0A0ltwTAUlvwngLAVL+wVQhBDlK+7g5I 2pjuVWQPbUwV57xCKyri4cYoyQxE3Bi/dj7bzFOkt/W3eOnqoT1PRSO0qGAg3w== Date: Sat, 09 Mar 2024 14:07:10 +0100 From: Alexander Leidinger To: Warner Losh Cc: Jamie Landeg-Jones , current@freebsd.org Subject: Re: Reason why "nocache" option is not displayed in "mount"? In-Reply-To: References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_2fa80b1d684482adebd320c12be819ec"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4TsNd74F2tz4jBL This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_2fa80b1d684482adebd320c12be819ec Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-03-09 06:07, schrieb Warner Losh: > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones > wrote: > >> Alexander Leidinger wrote: >> >>> Hi, >>> >>> what is the reason why "nocache" is not displayed in the output of >>> "mount" for nullfs options? >> >> Good catch. I also notice that "hidden" is not shown either. >> >> I guess that as for some time, "nocache" was a "secret" option, no-one >> update "mount" to display it? > > So a couple of things to know. > > First, there's a list of known options. These are converted to a > bitmask. This is then decoded and reported by mount. The other strings > are passed to the filesystem directly. They decode it and do things, > but they don't export them (that I can find). I believe that's why they > aren't reported with 'mount'. There's a couple of other options in > /etc/fstab that are pseudo options too. That's the technical explanation why it doesn't work. I'm a step further since initial mail, I even had a look at the code and know that nocache is recorded in a nullfs private flag and that the userland can not access this (mount looks at struct statfs which doesn't provide info to this and some other things). My question was targeted more in the direction if there is a conceptual reason or if it was an oversight that it is not displayed. I admit that this was lost in translation... Regarding the issue of not being able to see all options which are in effect for a given mount point (not specific to nocache): I consider this to be a bug. Pseudo options like "late" or "noauto" in fstab which don't make sense to use when you use mount(8) a FS by hand, I do not consider here. I'm not sure if this warrants a bug tracker item (which maybe nobody is interested to take ownership of), or if we need to extend the man pages with info which option will not by displayed in the output of mounted FS, or both. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_2fa80b1d684482adebd320c12be819ec Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXsXw0ACgkQEg2wmwP4 2IaNCA//Yr+MfIg2g36NjHCTdJpuvIg3+Y9D2GGdL8zciNN/pLptqOhnNWZhHnJJ 5m6uGmgQ8lCkubkQB/OQRxLcnezBltLpTQwlW4mVheoWo76MeUKon/MWPznXanV/ bEmZFApUHcPwMgPMUuorMhxoL/WmMsOQhYdW/ZboQa0qMnV2qKoQC3XnoeIpcSyQ LkatTAuZM6slT+TcSsoPzQfPc4ad9tWWfkZjlyqhyK+Cl4FBDPkDgXN8s2KuwNou CKG4dP8kosd5808mkQx5PEHJZK6zjcbhq5Vn3V37mvCo+c/bO2MIOFnX7++CTXmg auwWco1N9LWwgyeUVo1Br/PQemC2Kz8Qg0SMYGSXvUdDFES+SI9bWbRLs0HdDciS ynRKOzT0TkXXAxMCy25rjFCTuJHg+SdGpK0L5GCwg0S71xqP7kK2f6mkLlthD0eU ZYXBwXf+/3OmlXIdhuGa/liNfjY/ZyzAlFmwSHE3PZVKIrt7SetO5/1FeeNl2bHd UWgAXmo5z7ZkFmpGnkyucgaN3OduyxKAf/oRNhNTSbUX3CLZZCmg06zGiJUuLVki QQoWZk7WUqXm1rXUUVyelVHv3QbIFxPz3h3az3IUd5/YUz5y/3/8wdbIDYgkW+n2 tkSOosBxP+jq5l2WMFLHffMO+J1Ul82tm+6rO3RmTAob0vcEP64= =A5xJ -----END PGP SIGNATURE----- --=_2fa80b1d684482adebd320c12be819ec-- From nobody Sat Mar 9 14:27:28 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsQNz4XnLz5DK3C for ; Sat, 9 Mar 2024 14:27:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsQNz1tl0z4WR9 for ; Sat, 9 Mar 2024 14:27:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-29b70bf6c58so1390278a91.0 for ; Sat, 09 Mar 2024 06:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709994466; x=1710599266; 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=FMmdDFLHnPEuDbVGv+jR9Svqqx4nXwpjA+POa6gdkck=; b=JVfRnV+g7RNbsHQurlArPtfuQmE5vZoNMLDEN7ipgnPlx/T4PrRAbsYKPb0gQl0xsv PlY0gYbrfmNQqQnUnpfFQoAoxFNlAPY/dTp9FvuBH6fiwhwP2Sf5efo3RZyUVFWjt0t/ keNG37XCPEv4rXruGXFFSSUozP3dAt7AMRIEVk58X/PU8DJP4NM+nIApDCxFCrf5MgXN CmUds4v5dPDcSuhUF8OhcaVczWn2Jdqjr0o2yiAvkjrZn0HCgLC7QnHrAD3d/V071gVR Iw15ZqtenKLSHm8GcKVWnK4iUh0I8k6/NeUeMMvI2raKKhD3niuMIYy7CGFWBznuDhlh ZyOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709994466; x=1710599266; 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=FMmdDFLHnPEuDbVGv+jR9Svqqx4nXwpjA+POa6gdkck=; b=WJbJBqmRjo26TvlRcveyYctDKjTZy2zrkkJJZEqlAcBDgSk/L2zxC3wrP404kptmWg NQDlPxMBgUg4FH/5yh538vLfPH0rNQusqhh4R1TPh8JtUvr0aCQdCpyS3adJw62bfBFv gZL8ozT2vKDfx8vwggmsyFXB1nkccuXkEY+psCPlqt7+ZJq1qIwCOyq6katBfEArMwR5 QaoBkf/Sqx+Prn3JSjzZteSz+qnAkf1B21HdfNwmzxICRF0Mb+WycmeiZE7mtxTWPZqn nTRv2X/aa8by37vTWF5s6L9Qxqfo0wiWngvKOzxHEfjdAN1SnIImJxJAm30s96mnW7jt 7pNw== X-Forwarded-Encrypted: i=1; AJvYcCWaAkQwtWKKLSacn61On4itimThOY0a6b+0ztsCXzT91J+c//kHGqn+aewiF8vqfylWel1QHNYdUhkFUiCn1xjWi4VI X-Gm-Message-State: AOJu0YzO+oujNBnTOlrSR++EGCeVMtGZB7cOL1uO+YjURsHmsAlBuKmv 2OClpkHh+MCe81F0fu1CsZShzg5Skt5ic3me7WnkdscMiekPBKZM/DRAWUUIJ1hTlCRcPz2prrD gYxw9FugFL9WP0npQ2nYapMrsqnJGcRM= X-Google-Smtp-Source: AGHT+IF+coxLo3UHDpX6ktuHoyStZRg+1RE7vj//EnZMldH+plqSfb/Ntx1FrgXsQroZwa9FB3lnYXX0Jin6dK73msM= X-Received: by 2002:a17:90b:1089:b0:29b:b902:bd2d with SMTP id gj9-20020a17090b108900b0029bb902bd2dmr1437107pjb.43.1709994465517; Sat, 09 Mar 2024 06:27:45 -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: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> In-Reply-To: From: Rick Macklem Date: Sat, 9 Mar 2024 06:27:28 -0800 Message-ID: Subject: Re: Reason why "nocache" option is not displayed in "mount"? To: Alexander Leidinger Cc: Warner Losh , Jamie Landeg-Jones , current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4TsQNz1tl0z4WR9 On Sat, Mar 9, 2024 at 5:08=E2=80=AFAM Alexander Leidinger wrote: > > Am 2024-03-09 06:07, schrieb Warner Losh: > > > On Thu, Mar 7, 2024 at 1:05=E2=80=AFPM Jamie Landeg-Jones > > wrote: > > > >> Alexander Leidinger wrote: > >> > >>> Hi, > >>> > >>> what is the reason why "nocache" is not displayed in the output of > >>> "mount" for nullfs options? > >> > >> Good catch. I also notice that "hidden" is not shown either. > >> > >> I guess that as for some time, "nocache" was a "secret" option, no-one > >> update "mount" to display it? > > > > So a couple of things to know. > > > > First, there's a list of known options. These are converted to a > > bitmask. This is then decoded and reported by mount. The other strings > > are passed to the filesystem directly. They decode it and do things, > > but they don't export them (that I can find). I believe that's why they > > aren't reported with 'mount'. There's a couple of other options in > > /etc/fstab that are pseudo options too. > > That's the technical explanation why it doesn't work. I'm a step further > since initial mail, I even had a look at the code and know that nocache > is recorded in a nullfs private flag and that the userland can not > access this (mount looks at struct statfs which doesn't provide info to > this and some other things). > > My question was targeted more in the direction if there is a conceptual > reason or if it was an oversight that it is not displayed. I admit that > this was lost in translation... > > Regarding the issue of not being able to see all options which are in > effect for a given mount point (not specific to nocache): I consider > this to be a bug. > Pseudo options like "late" or "noauto" in fstab which don't make sense > to use when you use mount(8) a FS by hand, I do not consider here. As a data point, I added the "-m"option to nfsstat(1) so that all the nfs related options get displayed. Part of the problem is that this will be file system specific, since nmount= () defers processing options to the file systems. rick > > I'm not sure if this warrants a bug tracker item (which maybe nobody is > interested to take ownership of), or if we need to extend the man pages > with info which option will not by displayed in the output of mounted > FS, or both. > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Sat Mar 9 17:33:18 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsVWK07whz5Dc9k for ; Sat, 9 Mar 2024 17:33:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsVWJ41yjz45cq for ; Sat, 9 Mar 2024 17:33:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a3fb8b0b7acso210968766b.2 for ; Sat, 09 Mar 2024 09:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1710005609; x=1710610409; 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=8WluSgq86wSW0FSZ2m337cx/4rxbIvq++F3x3wUPzYA=; b=U5QVYv3/NaUAGI3zhA1G3wq12MG1mawtDbn0vh7sZonwiM7HEyRKHddPhTLfDrEM0Q VdXgaj8/R7tto1mPM5+CEoL6tz0m8DjwFjVuT0Q6tzdEeLuPw1bgbF8i+KVuQIqplQyq AaD94aaWkh2Qn2Kh31hZ5I9bnicMmB/RsPAd7Zkuu7WBQawRE7cqXucva1pfFFb2TXdS S0zHenmqErYVfwUFGB8okOtM8sT272i00pUpK6mKtJgGSYxzcw2onWUbUONIWN8Rgazs wgWrwTxdgLR7l7cJdBv0zVkn9+M19o/zu4aOHqflgawRBf6yAUg23s5HdWPWmW+KxoDJ 2qhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710005609; x=1710610409; 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=8WluSgq86wSW0FSZ2m337cx/4rxbIvq++F3x3wUPzYA=; b=xDKbBdYNnQRWE/ZiuIVOiDuPysDymHuW8y4vGYYccgCdmzP0dZEzelpb5Nsqw7b+tc dLHd5GW5xwzmR42SuKPB9//f3PFgcY6nJgHuORrj5cXAJpu53/scwVRUS4+BNcHQ0eDu x1n+PL0nvLH+8Myd7LwTzxFspdfCkVH2OX6I7Uu62PST5TLDgI0wiZiJX96sMJ/2fJgT oeIuc+P/p4cSpeI8uPvTa3YtGh77ZHLFBJyDR2Mvf3uNrMqQIkpSiQnwh+TZhr9xA6TG ynE1SSL4CejOJNkeVkdM9CQrEPT/hXmBAtQdXYPuyxJ65yz4vHBIzdfX7C4QaC41P/y4 6vyg== X-Gm-Message-State: AOJu0YzQJjh0M9eDST5oRiCiYesYxbc867a1dxH70WQqGSFR0Bh/mcTk BUL+T6Ngwf7UNoCzI83Th8oTupsPJ4tsthBLYNFRtJjvBaYfxVcMyAwp8HzzbMQEB4j1BmSkpUz NicInl4T1MoKQtOlW+xAM9cwp06d1mn0Lo07Ll7ZWPPODzSys9RY= X-Google-Smtp-Source: AGHT+IE/yn5YToz3n7cRmeu6X8mhjux0a6Cvubu1o0/ChZYTcicyLNARlbb5zYS+78NYj9GdCapajx8s3qXUtWoRxgs= X-Received: by 2002:a17:907:c201:b0:a46:13a9:6dc0 with SMTP id ti1-20020a170907c20100b00a4613a96dc0mr601681ejc.64.1710005609540; Sat, 09 Mar 2024 09:33: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: In-Reply-To: From: Warner Losh Date: Sat, 9 Mar 2024 10:33:18 -0700 Message-ID: Subject: Re: Boot failure, amd64 (HP EliteBook 650 G10) To: Graham Perrin Cc: FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="000000000000ebc2dc06133db4f9" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4TsVWJ41yjz45cq --000000000000ebc2dc06133db4f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd love to borrow one of these machines fir a week or so. Warner On Sat, Mar 9, 2024, 2:52=E2=80=AFAM Graham Perrin = wrote: > > > amd64. > > AFAICT the EliteBook 650 G10 was introduced around May 2023. > > Does anything in the three photographs tally with a report in Bugzilla? > > Any overlap with > > > for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))? > > > > --000000000000ebc2dc06133db4f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd love to borrow one of these machines fir a week o= r so.

Warner=C2=A0
=
On Sat= , Mar 9, 2024, 2:52=E2=80=AFAM Graham Perrin <grahamperrin@gmail.com> wrote:
<https://code= berg.org/grahamperrin/freebsd-src/issues/8>

amd64.

AFAICT the EliteBook 650 G10 was introduced around May 2023.

Does anything in the three photographs tally with a report in Bugzilla?

Any overlap with
<https://list= s.freebsd.org/archives/freebsd-current/2024-March/005697.html>
for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?



--000000000000ebc2dc06133db4f9-- From nobody Sat Mar 9 19:20:13 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsXvc3nHzz5Dn03 for ; Sat, 9 Mar 2024 19:21:16 +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 (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsXvb0fTzz4Ndf for ; Sat, 9 Mar 2024 19:21:15 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=xFNEltfD; 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=1710012061; 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=rAHGvTHA8/MZtMY4YOAVidohL2/5GTvh/cDqaEpW6rk=; b=xFNEltfDE8nSlliXFktpJxz/aebO43TT4WUR6P9CwCp8cCI0ZDXaI5Nj27594c7ZNBhiPM GQ7EBBY5pOLdALh7fwvlUfz6e7Piw1FvbFOIivYAINnPnuritYNFr9qwwVzZaJbTuzMGR6 N0QYvGv56smLvG8ih1qsCoWQQkUZm5QZVOijcMidVzz7uCfZlOHm3yalV7zkcHUEOVXQgk cKcEPaq+PePi+080lg0B/KPOnC8LygdVWlEN8hnyfuKJbnzjbzaMa1o3V10BLHVilmDiYa xQ2ahDi1RLccOhzBjXIJML07UpFABm9lIXFY6P7aBjKLgcMLM4GPBC2WFFlkVg== Date: Sat, 09 Mar 2024 20:20:13 +0100 From: Alexander Leidinger To: Rick Macklem Cc: Warner Losh , Jamie Landeg-Jones , current@freebsd.org Subject: Re: Reason why "nocache" option is not displayed in "mount"? In-Reply-To: References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> Message-ID: <32d3aed1d5632fbc43b8ec0f083ed90e@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_15e4e632b118ed346b5f64d4ad065209"; micalg=pgp-sha256 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4TsXvb0fTzz4Ndf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_15e4e632b118ed346b5f64d4ad065209 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-03-09 15:27, schrieb Rick Macklem: > On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger > wrote: >> >> Am 2024-03-09 06:07, schrieb Warner Losh: >> >> > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones >> > wrote: >> > >> >> Alexander Leidinger wrote: >> >> >> >>> Hi, >> >>> >> >>> what is the reason why "nocache" is not displayed in the output of >> >>> "mount" for nullfs options? >> >> >> >> Good catch. I also notice that "hidden" is not shown either. >> >> >> >> I guess that as for some time, "nocache" was a "secret" option, no-one >> >> update "mount" to display it? >> > >> > So a couple of things to know. >> > >> > First, there's a list of known options. These are converted to a >> > bitmask. This is then decoded and reported by mount. The other strings >> > are passed to the filesystem directly. They decode it and do things, >> > but they don't export them (that I can find). I believe that's why they >> > aren't reported with 'mount'. There's a couple of other options in >> > /etc/fstab that are pseudo options too. >> >> That's the technical explanation why it doesn't work. I'm a step >> further >> since initial mail, I even had a look at the code and know that >> nocache >> is recorded in a nullfs private flag and that the userland can not >> access this (mount looks at struct statfs which doesn't provide info >> to >> this and some other things). >> >> My question was targeted more in the direction if there is a >> conceptual >> reason or if it was an oversight that it is not displayed. I admit >> that >> this was lost in translation... >> >> Regarding the issue of not being able to see all options which are in >> effect for a given mount point (not specific to nocache): I consider >> this to be a bug. >> Pseudo options like "late" or "noauto" in fstab which don't make sense >> to use when you use mount(8) a FS by hand, I do not consider here. > As a data point, I added the "-m"option to nfsstat(1) so that all the > nfs > related options get displayed. > > Part of the problem is that this will be file system specific, since > nmount() > defers processing options to the file systems. There exists values for a lot of the mount opions which are not displayed. For example the nocache option for nullfs is MNTK_NULL_NOCACHE in https://cgit.freebsd.org/src/tree/sys/sys/mount.h#n515 This may not be useable as is, but I use it to show that there are already bits public about it, just not in the proper place to be useful to the userland. Even FS specific options could be set as part of statfs (by letting the FS set them in struct statfs). Or there could be a per-mount callback / ioctl / whatever which provides the options in some way to the userland if requested. So we either have something which could be used but requires some interface to let a FS set a value somewhere, or if this is a too gross hack, we would need to come up with a new interface to query this info. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_15e4e632b118ed346b5f64d4ad065209 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXstnwACgkQEg2wmwP4 2IZPrA/8CyBuQDhcEzqqV206Bj9SfWZsObaLtDGdECsaVYcm0GEeqvIRT+DDYpWN QyUOgMPAhJjACSGE2MCqqzINX8aUBQD7VnWnbhwao7coim5fE+UF+ruQ8NTqpSN6 P6Z7RCiuc7T8rvucbZBHc8dyxbj4u5fR62egzL3cgnblIEJzjYxLFrFD9jNFKwYb 8jdKNIMeiQg17cLYkJmm22vESLfnUxx6RKL9O9B0tuY6FoWumMawNg/4RtdSPgCZ FjApQTQw09F977pnB5ZjlpcRTojv/DnCcTWr16NKJO6puY8i5PR4WyZfvQYrxhAg Sj+HgKJRTYv0GR2IceZ1C7B56Y5C4EgOW6E8MljhO6QOYWVdiwsTouHV+kw+zsnC 3F0jm9+y57k8muzhHamfCIOV6duTCFUNsvPrlYww7QxlrcnQoYaTxgRK99qg3/jJ 7o4q7WiVuusVJ9yrkU+JGiq91emKw/U3kXmjvz7RFCn7oXUtWLlE+bOhXymuEj6F UQzOuoz6QVO9EC/wpFmSJXrErVuU+zBR1BxIISAM+wJbjloXimyjqe7m303urexN Lq0oGF1ZVP7p74+SD+9KF7liaE+HRsdBmJNW5C/IqpnpqOp8ir4RiuGftsglE5tP wWf4gpnGShCxf134RmHjoGAttjPFhoxcjDCsxoNi6HNIZo5RxfY= =0Vua -----END PGP SIGNATURE----- --=_15e4e632b118ed346b5f64d4ad065209-- From nobody Sat Mar 9 20:12:45 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TsYxv1xwwz5DrnJ for ; Sat, 9 Mar 2024 20:08:19 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsYxt6xMwz4TGw for ; Sat, 9 Mar 2024 20:08:18 +0000 (UTC) (envelope-from pj@smo.de) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.153.212] (p4fe02148.dip0.t-ipconnect.de [79.224.33.72]) by mail.adebahr.de (Postfix) with ESMTPSA id A04F6600E9; Sat, 9 Mar 2024 21:08:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smo.de; s=mail; t=1710014884; 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=eSg7uxk2fSQZZKo+sZm/e3aAqLkoAvs/B8Ih9MECw5Y=; b=eOW9yPeaRzmDhOqBQFom8TPw3MKthphE6lIOyg8BTGVVkGi1Xq8RX5MSE4HRfxlt7lz0cd FkmqY4trAU3+jpqmEFHKzk3DsG5FDtAMXpntKUfjBP3Y+OEGUMRuGrJ5Rz/EWi2TQcMtgG zJl7m1GhDS3lwlBl6E7Bb1EAa1Dlgfyjtal4mlg4bWHcSMxS5nNaY+BWmVkGm6+pl9WMVQ /nW1d10CCL2pyItMk5kx8sQbVe1AXp8foMc1FFeX03eOTERKKX0mm5ywAUxC+T+v7oeZWA QlF1pRTkTSZu+ipf7DAe2OTF0J7r6kkVAhvoddvYbqCoilg6++ejcJ71lgf1oA== Message-ID: <73353855-d13f-4eca-b2e2-aadf89083779@smo.de> Date: Sat, 9 Mar 2024 21:12:45 +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: Boot failure, amd64 (HP EliteBook 650 G10) To: Graham Perrin , FreeBSD-CURRENT References: Content-Language: en-US From: Philipp Ost In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:212341, ipnet:185.66.176.0/22, country:DE] X-Rspamd-Queue-Id: 4TsYxt6xMwz4TGw Hi Graham, On 3/9/24 10:52, Graham Perrin wrote: > > > amd64. > > AFAICT the EliteBook 650 G10 was introduced around May 2023. > > Does anything in the three photographs tally with a report in Bugzilla? > > Any overlap with > for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))? I would try booting with uart{0,1} disabled at the loader prompt. I stumbled upon that by chance, here: https://forums.freebsd.org/threads/debugging-the-boot-process.60224/ (the forum thread is from 2017, so the issue seems to be somewhat persistent ;-)). Best of luck Philipp From nobody Sun Mar 10 00:59:49 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TshQf2yxxz5Cr4T for ; Sun, 10 Mar 2024 01:00:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TshQd4N4yz4rwV; Sun, 10 Mar 2024 01:00:09 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="DAV/CsZC"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1dd878da011so2421335ad.2; Sat, 09 Mar 2024 17:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710032408; x=1710637208; darn=freebsd.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cS6eFDzkQlGaJmN1FI26T1fB/GQgsyBhZbc/b964gN8=; b=DAV/CsZC9fRwQ4GFUjvgXFvODxpF3Kp2Z8NKAnGELo/sIvnk28/VH9WdyqP4K82ofc iBsME6S/8K1WyI/OdZ81gn/3boEQxxyuLqG7oJv6HZmMfPWcCinhKdvwXwP0C+BMLViN /4SSNc3WkW9JofwWIAzOv4GkYL5ojOcup1kGhDHt6i2QWUjh7RwoI9GXJDh/3Xb7klup j9NAXCWck9M77IjCcCn1Dc6loufi3UtwkfaMo0adwnqYk1n/hyChiEncENnKbYdV4CBJ tGe23trq4NmxV+hg61a07sJ2GdQBr1za9xzAeazEFsc4Z/yq6SQLZeBtLieY2b64FfUu HsQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710032408; x=1710637208; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cS6eFDzkQlGaJmN1FI26T1fB/GQgsyBhZbc/b964gN8=; b=OGq94ft9r/H8kIhAaEn3jgiut7b0mj3gA/eaVL8tUHi9edkFTqX+dpBKHai8MuqNWG qw6aHrFssjaLDw2O7MNchZcbgm13+W+U3RP05HWRV4AzzvA57FdSttFUq+SiwjNrDuqZ 2fhleFhtFNWX9hZl2s2+6Xn8YRoJYZljhIhC1ThoOEimyQimh8JvzyKmECPM4YWonZxT fCXsycoTza3cUuHMb9wx8NWSUqAZz2f9eISwrtMoCVuqd+ueqiK1M8UAaJAfXF/mnw8I uY/t5CsGufyAg2pXtagkceG72GghSFWGAKzJE0fD2tkXhKlzQgw8/ANTGCOQCKGE2vU8 TBLQ== X-Forwarded-Encrypted: i=1; AJvYcCXONr7gm3MQdE6O9vHxcrhoJved3OcB00oNLwqGWiVYVBYkfPUngJwaLesayN4SiCpglnHcgPZz+mmsxWFCxXA= X-Gm-Message-State: AOJu0Yy19ATMetUXIPKndagRbFNrinsB6dRdqbIK5fl3fRJ5qiZfput0 YdZheqJTKsajrnS0VIAcLRINDbQhy0KAE0FEiYmMSCEq1Ab9GXSKMLFZjzGxRWXi7SoiALOmBwL 1bdjNLo8BVM7DCpw6bPUMzEzhYtCA3Es= X-Google-Smtp-Source: AGHT+IHisz8652R6ta7TuLlfLZXFFnKnQ6seT7QzSRylpTWvr3ftRyont8vPnUKZrMtzjmLz0pxBtMwOaqCTzuFGPKU= X-Received: by 2002:a17:903:2443:b0:1dd:6c28:4cfe with SMTP id l3-20020a170903244300b001dd6c284cfemr2033250pls.42.1710032407340; Sat, 09 Mar 2024 17:00:07 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Rick Macklem Date: Sat, 9 Mar 2024 16:59:49 -0800 Message-ID: Subject: RFC: should a va_bytes option be added to vn_getsize_locked()? To: mjg@freebsd.org, Konstantin Belousov Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.975]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; 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]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62d:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4TshQd4N4yz4rwV Hi, I would like to compare va_size to va_bytes in vn_generic_copy_file_range(), as a heuristic to check for a sparse file (only works for non-compressed file systems). The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked() in vn_generic_copy_file_range(). To get va_bytes I can either modify the code to again use VOP_GETATTR() or I could add an additional return argument to vn_getsize_locked(). Since vn_getsize_locked() is descibed as a first step towards not using VOP_GETATTR() it sounds like adding an agument to vn_getsize_locked() is not the preferred alternative, but I thought I'd ask. Thanks for any comments, rick From nobody Sun Mar 10 01:53:05 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tsjbj3zGrz5CwQV for ; Sun, 10 Mar 2024 01:53:05 +0000 (UTC) (envelope-from mckusick@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tsjbj35tKz4xvM; Sun, 10 Mar 2024 01:53:05 +0000 (UTC) (envelope-from mckusick@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710035585; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=cnXORXyyU1uiYGMI5dUwkph6ruQwzkXl5f0JMEKvTR8=; b=K81hPtZ5qNPjVsSfsT4QQ6tmPzpg4Nb3PyXufLo8czCoZ7cY0zrmAR+mdSrTPbigaRyi3V qnOg6jLufr7bWNAaeKA+Z+zsO55WA37A9egyIVBpwvY16MIsd6voCBmmdbJMxhCLzEj6sA rT+iLBM6Hg0KIumUijksIeQAOH3aIe6qnPcnigGmSMBM4n4rolurXqpqg47pFynza1Ri6n 3Cnoau27ce10Tl8/3kPsbG2KHG/gKLE4Pu5f0F/10FmV3hUS7eVAnZlKaoQ4evZ9rXlpbT GCGtpXwg7is2QNOqtOUBDJxl0txey3/2zYY8NMIa3qswkdNo+xr//oUrhRkQtA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710035585; a=rsa-sha256; cv=none; b=rlONmYpuBlzQytkS9Fko7jAs2UBj1GI9m1uUpczqle0M3Tnyn509bHgcYzKWhAPJZ091uQ U+34GaPrfDAHIti/mT6nnf3jKWGcp1M26DrieXWk3UWdus9p8s6g8kxrU1YP/NJrmKbXgK QxWta4UhpeLOuecj/p+58RuMihb70PDB3FVgFLYMqumC/Wv2cQGfzMKxJJZhTJ1r54bUMI LAxfVZkzVXNutpu5ZBl0FkYrc1ISf5TgZ3UnmSJ5kLTW3ox9b55Z2QVEQFbrIteRvzthvN sqavz52Isbd9QfBwf+QRiuI33bm3isHg0/WGCPqUIUrvOWgXBCpKDz9S5X6uPg== 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=1710035585; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=cnXORXyyU1uiYGMI5dUwkph6ruQwzkXl5f0JMEKvTR8=; b=ghnZIusX+UWGPKd5QR6o25YNHetS8PbCOrJ0wGKSGDobs5SbCEyfFYCqzDhlE8oziCQqZ2 NNoAbBXDDUtZjm7mQClR5vt6DIwppAqbOcUDD/AUlVRUGeOYMs67oEqwwK+bxVqN+SM8tM RNBSzG5QbCVWRn5VRe5EnGhSzfp/tXYOd+QQT/qREtn/pke7CW1VG+77oun3/6437yHbq4 RqmKeO8ot2dbA3Ww02Dxo4lof4kmHbmnyxk4bp1UFAZTVhnc2VH4uo61zYAlQCI4TP8lDl /plLkAATiPqLZpnXbGeSmiv+hodayfP6Es1Trm1+zWlYAxMdvHnOEFGuSy8S3w== Received: by freefall.freebsd.org (Postfix, from userid 740) id 447EF6CF0; Sun, 10 Mar 2024 01:53:05 +0000 (UTC) From: Kirk McKusick To: Warner Losh Subject: Re: Reason why "nocache" option is not displayed in "mount"? cc: Alexander Leidinger , Jamie Landeg-Jones , macklem@freebsd.org, current@freebsd.org X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Alexander Leidinger message dated "Sat, 09 Mar 2024 14:07:10 +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 Content-Type: text/plain; charset="us-ascii" Content-ID: <65801.1710035585.1@freefall.freebsd.org> Date: Sun, 10 Mar 2024 01:53:05 +0000 Message-Id: <20240310015305.447EF6CF0@freefall.freebsd.org> The issue has to do with how flags are defined in mount.h. Specifically there are the flags that are externally visible (prefixed with MNT_) and those that are for internal use (prefixed with MNTK_, the K standing for KERNEL). If it is desirable to have MNTK_NULL_NOCACHE visible, then it should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, and listed in MNTOPT_NAMES. It probably belongs in the set described as `Flags set by internal operations, but visible to the user.' With this change, it will be displayed by the mount command and show up in the statfs flags. Kirk McKusick From nobody Sun Mar 10 03:05:07 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TslC92jCLz5D3F9 for ; Sun, 10 Mar 2024 03:05:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TslC80NhZz54BY for ; Sun, 10 Mar 2024 03:05:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pqUqmRrv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710039920; bh=il+SiFG9mHqml2EzczqR07H3ZmDgYMlP1BZrbaRAFcY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=pqUqmRrvqdBqMFLL8sZgh1cd74K6uoiIwUwCAovnlzdZJUeRpdOPDJIr1k8Fnp/CKiY2IJM0xZ1Kt+WvF9L2CFhjB9di1PgCvHSPXk1+ctQRA0FgkaIZ7TpOt2vhtLvcKkHMFySMpneXbLk+9WxlDWdlB59L660RKVZvuL/Cx6uKIbvFevOkBSyJXqwPZVaF9se0jpTRRxvp63WiSOIA+i/HRg+Z0JqPKucbCxzrktsgVu5pKNjPSF3R+y+T0ZSJF7p+C0XN0G/ZsCSyUr9Qt+CL65C8TSS9NiehLlsbrhY6McadPAM4CcTBygTzXFXNCUZSeKm577sS8REPXhUaLg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710039920; bh=kDcAEDwakwoFITR0cSOKEkvoSBkgWbJthbGAvK3JUle=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QW48qLvnT/0cNTYnDXfdQrDzNvz5llvsgxbu0gbsEt6AysAyUgO9y02HTix/3iWRx+zRDsCLkdwqW0TeUKqWHSDatNFMmvHT0PBtEzSzFy0S2GP9Bvkj0j90UzMzUp50t8khfFgPKqUyzCk/HyeTz1SMq/4VUUwItIpp1wyhQOTsXFwER+OaTn01bj76NEudnlwyfbSy5g2aG0iHZVxtSU6SDjjaKvHIkeGEZhm7JJKTsQINJnBctbfKgCZvPDMYyEVt3bey4IADIEga22JM0wIEMmc0uihO4dG1BcbUTZpe4PLjKE8rTS9/+sHOqmAqqaW2wN0kNO1AbuwnpA+M7w== X-YMail-OSG: Irty9uIVM1lBxQXbEdpegVEAkQr3AGhevowi5cHmRjjMskvNgyQH5khtprqIK9M wm90y7qmFQYs0woQ2PPe43P.wMVOuNNnwMzLSucmoSropT1ZeDir8TfPGnYbHKbmj.jVEngtjCuD arFBnlw9Ys1R1S.hproiL_r1FtnCZQ7euw4VbxO8bVtmlEg4IJ_1Q77F0b4VEx.OOpeLJJBVif8V sZEMrZkcHg0eHaLoqHAvMqZtxu3yVFjYsUmUgtvhwmg0U9z3hDpsCJ53l_ONj4HIOVjlPBO4mwpE DaMlwo_fx_.VJ7_C20EnaQ7EzfMYComr41riWy78ctbi_Y4MwKqrdwIKcvTCSuR5dbHf7GETumj1 rqgOwLpzlgDzMFVIWckjw7GilbyaJjaXJa_F12mWFoK8NwOJuzJI0B.TI6lzwnS1NdnT5XIairL0 RlTTF10WDAWft08RP1OdztIpyu.Grxen5FhB_.gnimlgqn6Bvg7ab0zpC4Mn1qj8Z4r3xESYI_bv B3QPWwQ8XTByo41BKP8.T5yv_vlmAiUIODQ0oi5gQGSohz2hUMT0XaGm9_p0.km7nSyghfRPaZ9K Vr8z4JWiTi0vA_K11Zuc5_YCkZLtCKdi4JB26V_81P1S8Fgo.hVli6SOVnEsQDYwMtGvD9CaGsMT voKrUuLbBQwzbgiGl4WXO1gHKH.2WRVUmfI9oF36HY7JcCtLAI61CLvxcoZaSRJaEWsmGWo_H8d6 X.XzK9kLhRU7XLSRKNSIUol2h0XwPfbVpL7H1dc62vKVAcITZ412r_Qp1EHO9OuJHzaJT5Qw0iyp xm3odYiXL3X33_0sQ84UX1QxyV3XYbCuijwqrLITn66jo_.oRSCd5jEnMxZfRIQqQnXkGqMPdoSP 9kndcfrPxjKrD0Iv0v2VRimXZInXnA3vtGAczrDMg6uGbOE.tVrHvE0Dig.2BAXqsePo40byEv6I u1AUcIcwpknVGlOsaHLqzV6z4u2qUP0Tl71FTEjovlw2CTIlXa1HosDuV5bEm.KiJObxG8dlklyQ 7eTrtqRpoCGevhngiu6ADcVJCsdwPIS2TC0gYDvOYyXRReFT7OXy3mNYdfs9yxeJGXeI2wif4oTm N6us8qZZPYtqawEmIFtZwGe6Zo_iY31I7RmssdQ6CgepLe73berr5N4vd5i5_roPnd52PWntkQ9C 2qbQ0wtVa94p25ux5YqHfUbYGo.tRxiOlvViFiul0mscEw66l0uxkQ1IPxZASaSXO9Ch6j9a556d uSWfLtGV0XGR8_owlwJWkKPAo42Y8zsP2XyVDu13.g6jxdoEj9o7g6san3jXw3zI7n2kh_y8.awy kgcbRAkz6w6vbcQNie_psLVUIMyqOVAnnG9iueerQX7_nej8GRyIMSOYYQ3KLr8UcOY3JVUYKZzs E.XYVrPrLyltN3VI0SwK87Yhy_VQFtrw8_HJ.dV0OTKTWZVyvYsZpEXl45rMtJIwGWWuBoHe9q5o O3efzSCsvcQWCmIw7kyyepLib4L38KGYlRrjPy4EhaNoQ7uV3B2xgpcQox0rfejiKNbDowKjS0xc TVXkrPTa6ZEl8mmzy00Z7vm4h6ALu3jaPIllKwHHJTuEG4e5i9pIQFepWgVhG.JsCvDzJGPuY55N kSZGrL1XzbpuQFDlnG_3gzGxihFAVrdz9SDN05V89P4VR8yxWYpjh4yy2DGwtcA8iv.Cc.UPEtwi oI2vHLzBkTfIHr.ixKTDPWYVvQ7vdJmrAxAruhA1OJXocD5vzw86eGk2ggcpXpSAumhi_aevprU1 Ol7iNyTRJ8dj8bI9QGmDJ4MZzNZZ6DRUTUT7g8tazB6N8I2cwXDnrhp8VjKFAc3LLa.YiTfVJA16 YjcG6LkcpybMptzaAFEN2uYrT3UGb.F3uV6tW4xEiLE5D_Ui5mBLWlD6tyHRHspHI3vd7aTCGeL3 .HbjrXCYeurlulnA4C0_UD9FaeBCskrPhy86g5EziwKs3QOe9a5chPLLnK2DZxnaR4CESPidRAkN hl.mWLWkqaojcmRzjJKxKcO6juk_RgY.46YXsHhfkEIWOkSBNVDGTnqc36WaSGA1ZnFdQPnkkm6e ZjNOb_1HhtpiDe0i9lZzjIFo82HObJXhTXHjWsiXyipcyqwSJzdu.T7KGeYSt8kcpYcLvClQv3dj fgUBwyMTHD5JaMCrc2EzehU7PoZRDtw7qAmM1mDJcCCLGw5gNQBVoORgqWylNXAQXbKZUj0rll1X iZTYtbK5yhuSGplFeEKiJee9zqUUpj0BVYmBzW2IulwG87ZVqJVyl2h2cd7mcL9pTUTRnfE0ARg- - X-Sonic-MF: X-Sonic-ID: 6e9da922-34fc-4c65-9949-445e9d246aa9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Mar 2024 03:05:20 +0000 Received: by hermes--production-gq1-5c57879fdf-bmngc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4edfb80e279368de4ddb2aba73997ad9; Sun, 10 Mar 2024 03:05:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Reason why "nocache" option is not displayed in "mount"? Message-Id: Date: Sat, 9 Mar 2024 19:05:07 -0800 To: "mckusick@freebsd.org" , Current FreeBSD X-Mailer: Apple Mail (2.3774.400.31) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4TslC80NhZz54BY Kirk McKusick wrote on Date: Sun, 10 Mar 2024 01:53:05 UTC : > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL). If it > is desirable to have MNTK_NULL_NOCACHE visible, then it > should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > and listed in MNTOPT_NAMES. It probably belongs in the set > described as `Flags set by internal operations, but visible > to the user.' With this change, it will be displayed by > the mount command and show up in the statfs flags. -o nocache appears to be mount_nullfs specific: man mount_nullfs reports: The options are as follows: -o Options are specified with a -o flag followed by a comma separated string of options. See the mount(8) man page for possible options and their meanings. Additionally the following option is supported: nocache Disable metadata caching in the null layer. Some lower- layer file systems may force this option. Depending on the access pattern, this may result in increased lock contention. There is also the recent addition to main of: QUOTE +The +.Dv vfs.nullfs.cache_vnodes +sysctl specifies global default for mount-specific cache/nocache option. END QUOTE The vfs.nullfs.cache_vnodes related commits listed a 1 week MFC. Now -o cache is an option as well, in order to cover both defaults being possible. (While it is not limited to what initiated the additions, that initiation is associated with some ZFS performance problem avoidance work that is going on where the caching was having negative consequences when nullfs was also in use.) kib's wording when I asked about the display-of-mode-status issue was: QUOTE Mount uses getfsstat(2) which has no knowledge of nmount(2). END QUOTE === Mark Millard marklmi at yahoo.com From nobody Sun Mar 10 17:21:54 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tt6Cc6kZ3z5DFPM for ; Sun, 10 Mar 2024 17:22:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tt6Cb5XGTz47DX for ; Sun, 10 Mar 2024 17:22:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42AHLtVH009618; Sun, 10 Mar 2024 19:21:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42AHLtVH009618 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42AHLtu1009617; Sun, 10 Mar 2024 19:21:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2024 19:21:54 +0200 From: Konstantin Belousov To: Kirk McKusick Cc: current@freebsd.org Subject: Re: Reason why "nocache" option is not displayed in "mount"? Message-ID: References: <20240310015305.447EF6CF0@freefall.freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240310015305.447EF6CF0@freefall.freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Tt6Cb5XGTz47DX On Sun, Mar 10, 2024 at 01:53:05AM +0000, Kirk McKusick wrote: > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL). If it > is desirable to have MNTK_NULL_NOCACHE visible, then it > should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > and listed in MNTOPT_NAMES. It probably belongs in the set > described as `Flags set by internal operations, but visible > to the user.' With this change, it will be displayed by > the mount command and show up in the statfs flags. There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. When userspace communicates the "cache" or "nocache" option to the VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) system call. The strings are explicitly queried by nullfs_mount(), mixed with the "default" sysctl, and then the nullfs-mount specific data flag is set, in mp->mnt_data.null_flag. There is no space in the struct statfs for ABI extension. The getfsstat(2) system call cannot report arbitrary fs-specific options. If somebody wants to uniformilly report fs-specific options, instead of scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and nfsstat -m (nfsclient), then some extension for nmount(2) is due, say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back. From nobody Sun Mar 10 18:52:17 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tt8Cr6lVcz5DPjn for ; Sun, 10 Mar 2024 18:52:24 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tt8Cr23Qnz4HRG; Sun, 10 Mar 2024 18:52:24 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42AIqHjo033185; Sun, 10 Mar 2024 20:52:20 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42AIqHjo033185 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42AIqH8O033184; Sun, 10 Mar 2024 20:52:17 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 10 Mar 2024 20:52:17 +0200 From: Konstantin Belousov To: Rick Macklem Cc: mjg@freebsd.org, FreeBSD CURRENT Subject: Re: RFC: should a va_bytes option be added to vn_getsize_locked()? 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-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-1.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEFALL_USER(0.00)[kib]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4Tt8Cr23Qnz4HRG On Sat, Mar 09, 2024 at 04:59:49PM -0800, Rick Macklem wrote: > Hi, > > I would like to compare va_size to va_bytes in vn_generic_copy_file_range(), > as a heuristic to check for a sparse file (only works for non-compressed > file systems). > > The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked() > in vn_generic_copy_file_range(). > > To get va_bytes I can either modify the code to again use VOP_GETATTR() > or I could add an additional return argument to vn_getsize_locked(). > Since vn_getsize_locked() is descibed as a first step towards not using > VOP_GETATTR() it sounds like adding an agument to vn_getsize_locked() > is not the preferred alternative, but I thought I'd ask. For me it sounds as very specific usage. You might be better served by directly using VOP_GETATTR() then IMO. From nobody Sun Mar 10 21:50:51 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TtD9m15jyz5Cx9W for ; Sun, 10 Mar 2024 21:50:52 +0000 (UTC) (envelope-from mckusick@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TtD9m0h2fz4fK0; Sun, 10 Mar 2024 21:50:52 +0000 (UTC) (envelope-from mckusick@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710107452; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=PbxJCuRdX1dUm9Ep2v6jZkr7vBjwjIqDJ8aihWjEhpY=; b=XPbiGMMlGZo1kbop762siWOZQYQeqLNrSDf5csfKOXP1lT9CGG0UZr4+unLZ/B45VVFt6N rDwD7foHEXU7+7yNBzFAHVdVSFVM1EF3DTAI6pUz+WaruPSSHzu8jZAl3kBP5gRknPQOnl CYRFW3QiRh/jEW8xGmfM8C7G1lHGilafMF0JSvHzcR4fq5MpNwRx25nLfqQ6bVBIkFX4t6 f1kH53rD6UTlY2QH6a8cwPcpZq69WHBuRx0GqeqrqC1TRtNCKfqixxlizuc596kp2SATHI PjYSMSkG8tqy0yVSiLeifYQzDXkcjQFjwyxcU+fgUxkGnOT+yH0oXorVCTNEWw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710107452; a=rsa-sha256; cv=none; b=mGb9PScoat7hlYpkOJU0KsgIwUCEHjUEpw13OMRDQ8XPKmnZmJGiqZoGksSgPgjp3eJII0 4pN6/0UXUSiwmkal05b7Gal3HTCvVuHCfN09e6qY4j5tF0TAZawHV6sM+NFYoCYUNii829 H6WKClKDx5RoKxmwv0fth5Su6dPyEqZ7wppdG4HOpCS2umcnM+L9Udc/q+PkBBo3wxVdjE i2noLqwYh9iJyZ1k9Jjd4E73YB4ze0RWWPLX0rWFOHkEQdKCTHp3OA0yfUD8KofdCrLzhm NcGqX1Sl5V5TRT3faO8E9zvfRe6iNYhcmR8kzJhKUdnBsE45QVZV9ZYpujrQpA== 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=1710107452; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=PbxJCuRdX1dUm9Ep2v6jZkr7vBjwjIqDJ8aihWjEhpY=; b=wYQlMzmwdOvPJTCFEFmLDL8XoSMN/JIyhbqojSUjbGHM31kZsiyPGmx1qj6hB5mmuW1VAx ChydzHqbaMRV+eHm1wBHWSjb/LpeM6IEVUnr/8ho6A2wI3Z2ADQM7HskxD7JcDti8EyxVv i/l/OHN/KznsFwHoiH9ayMrVxPSu8pQhlE6CNy4yZdDdyMkockyONAJWutUUGGpMoKxc1A SGQaKaIdYNOf4OKp0q0gBN6CwkbLr9r3hLPhLHxNKThP9EWrcCeJUYIBA7PuPSadtIgoJl A38fptp5pKhXnUxMN7uYawcqWD+S3MnkCvKiLoKJxc04/TVfKHcja0bgnzFgdw== Received: by freefall.freebsd.org (Postfix, from userid 740) id EC14296B7; Sun, 10 Mar 2024 21:50:51 +0000 (UTC) From: Kirk McKusick To: Konstantin Belousov Subject: Re: Reason why "nocache" option is not displayed in "mount"? cc: current@freebsd.org, Mark Millard Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Konstantin Belousov message dated "Sun, 10 Mar 2024 19:21:54 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70117.1710107451.1@freefall.freebsd.org> Date: Sun, 10 Mar 2024 21:50:51 +0000 Message-Id: <20240310215051.EC14296B7@freefall.freebsd.org> > Date: Sun, 10 Mar 2024 19:21:54 +0200 > From: Konstantin Belousov > To: Kirk McKusick > Cc: current@freebsd.org > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > On Sun, Mar 10, 2024 at 01:53:05AM +0000, Kirk McKusick wrote: >> The issue has to do with how flags are defined in mount.h. >> Specifically there are the flags that are externally visible >> (prefixed with MNT_) and those that are for internal use >> (prefixed with MNTK_, the K standing for KERNEL). If it >> is desirable to have MNTK_NULL_NOCACHE visible, then it >> should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, >> and listed in MNTOPT_NAMES. It probably belongs in the set >> described as `Flags set by internal operations, but visible >> to the user.' With this change, it will be displayed by >> the mount command and show up in the statfs flags. > > There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. > > When userspace communicates the "cache" or "nocache" option to the > VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) > system call. The strings are explicitly queried by nullfs_mount(), mixed > with the "default" sysctl, and then the nullfs-mount specific data flag > is set, in mp->mnt_data.null_flag. > > There is no space in the struct statfs for ABI extension. > The getfsstat(2) system call cannot report arbitrary fs-specific options. > > If somebody wants to uniformilly report fs-specific options, instead of > scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and > nfsstat -m (nfsclient), then some extension for nmount(2) is due, > say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back. As you note there are some filesystem specific flags already in mnt_flag that get copied to the statfs f_flags field. My point is that the NOCACHE flag could be moved to mnt_flag and made visible in the f_flags field. While it is currently specific to nullfs, it might be useful to implement it in other filesystems. Kirk McKusick From nobody Sun Mar 10 21:57:05 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TtDK51ChQz5Cxx3 for ; Sun, 10 Mar 2024 21:57:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TtDK459vdz4gF1 for ; Sun, 10 Mar 2024 21:57:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42ALv5GB078877; Sun, 10 Mar 2024 23:57:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42ALv5GB078877 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42ALv5KN078876; Sun, 10 Mar 2024 23:57:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2024 23:57:05 +0200 From: Konstantin Belousov To: Kirk McKusick Cc: current@freebsd.org, Mark Millard Subject: Re: Reason why "nocache" option is not displayed in "mount"? Message-ID: References: <20240310215051.EC14296B7@freefall.freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240310215051.EC14296B7@freefall.freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4TtDK459vdz4gF1 On Sun, Mar 10, 2024 at 09:50:51PM +0000, Kirk McKusick wrote: > > Date: Sun, 10 Mar 2024 19:21:54 +0200 > > From: Konstantin Belousov > > To: Kirk McKusick > > Cc: current@freebsd.org > > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > > > On Sun, Mar 10, 2024 at 01:53:05AM +0000, Kirk McKusick wrote: > >> The issue has to do with how flags are defined in mount.h. > >> Specifically there are the flags that are externally visible > >> (prefixed with MNT_) and those that are for internal use > >> (prefixed with MNTK_, the K standing for KERNEL). If it > >> is desirable to have MNTK_NULL_NOCACHE visible, then it > >> should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > >> and listed in MNTOPT_NAMES. It probably belongs in the set > >> described as `Flags set by internal operations, but visible > >> to the user.' With this change, it will be displayed by > >> the mount command and show up in the statfs flags. > > > > There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. > > > > When userspace communicates the "cache" or "nocache" option to the > > VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) > > system call. The strings are explicitly queried by nullfs_mount(), mixed > > with the "default" sysctl, and then the nullfs-mount specific data flag > > is set, in mp->mnt_data.null_flag. > > > > There is no space in the struct statfs for ABI extension. > > The getfsstat(2) system call cannot report arbitrary fs-specific options. > > > > If somebody wants to uniformilly report fs-specific options, instead of > > scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and > > nfsstat -m (nfsclient), then some extension for nmount(2) is due, > > say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back. > > As you note there are some filesystem specific flags already in > mnt_flag that get copied to the statfs f_flags field. My point is > that the NOCACHE flag could be moved to mnt_flag and made visible > in the f_flags field. While it is currently specific to nullfs, it > might be useful to implement it in other filesystems. We are already low on the free bits in the flags, even after expanding them to 64bit. More, there are useful common fs services continuously consuming that flags, e.g. the recent NFS TLS options. I object against using the flags for absolutely not important things, like this nullfs "cache" option. In long term, we would have to export nmount(2) strings since bits in flags are finite, but I prefer to delay it as much as possible.