From nobody Mon Feb 12 09:35:56 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 4TYK8T2FpMz59QH9
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 09:36:09 +0000 (UTC)
(envelope-from alexleidingerde@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
(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 4TYK8S46Pdz4HrS
for <current@freebsd.org>; Mon, 12 Feb 2024 09:36:08 +0000 (UTC)
(envelope-from alexleidingerde@gmail.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=gmail.com header.s=20230601 header.b=O+ujF7Er;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (mx1.freebsd.org: domain of alexleidingerde@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=alexleidingerde@gmail.com
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a3864258438so542561366b.0
for <current@freebsd.org>; Mon, 12 Feb 2024 01:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1707730567; x=1708335367; darn=freebsd.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=REkx0YSksUNGgXrm/IJ3OxjMXNZbvYJeYE0eXUqtG6Y=;
b=O+ujF7EriOLOKwoBrO3wGGRGhx1SdoljjI+fEiW9wE4mT/6qPmETBHmpCucfoa2mBQ
7xkKaEx5RHDHyITwikKruyWUjWoIb3JX3cTKpvYh/3VtX/Hm/4YsnHWt+NoYoenRS9+F
CrQamGGeaObJIYolBWpbI+NKImxIz+oCgiEF0fwqzVBgBfE33TXtx43rMC2f5h2zSViM
TVXGqVq2o3jDP1Xb3ZpVzkBoHIJ6qtLIlpw7nHYr3OXno9Vhdr5hnMamvkRc91PtTwtQ
uFQ6EGORcZh/+4p27dVLYagLG7CSXqQHpoI4IilUAUKgjloSHCy+NyvRorNdxDGYHwmw
7tJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707730567; x=1708335367;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=REkx0YSksUNGgXrm/IJ3OxjMXNZbvYJeYE0eXUqtG6Y=;
b=OCVinudKJBULpNNTXEfZsRz4F4SP95l5pg49x4vAOotTUCR/etbUqu0vcyCDTL8GWu
mlJ5J/OTVkJPZcUS7++/QMNbQFZ1pt8FyiA8Jz01cjb9cx4A1HF3jyCh3AVfjTJ1c5sW
HeOT2NAZ5ITkCG2TBB3jMQZdPHR+FflaeF8cXQmZNNOynNVHUJ2vKDf6fPqfX+bU68yF
MKh0BnscvKS28bWtY9Kbpyf7lOUwPv514oD/m7Vkadrsw8dChFW1MlJkDjGKJjBa2Hmo
jGfoCAjBqPZ0J6y/gdP2JdKtSSng+OMq5V93MDAcHMmEXIFilpWZDM6wghfM+JrdaCIg
aKrA==
X-Gm-Message-State: AOJu0YxHfVnmrYvcB1LiYGyhEUPRk5BaaNTA6aqroJJ5Sb5CwUHq4cJM
p0bSmvmv9g7hrF8aoB/XHsgLG4gsidm4Y6eB2mFvT3iO1EiBI6jvHlhv0o053qsq9jhiKSivqvw
jTYkPHNu4zQPbwFMlb9euQQ82wzYCq6Nx
X-Google-Smtp-Source: AGHT+IHrCmcYA3mWCG7m/wYq1iHdKpD7e7+/TeEj3Nbe+81WRv9Mp1ZuO55mb5udS5MFOHfJtnCv7uqIswxQT4fpI4Q=
X-Received: by 2002:a17:907:da1:b0:a3c:698:635f with SMTP id
go33-20020a1709070da100b00a3c0698635fmr8553995ejc.28.1707730567021; Mon, 12
Feb 2024 01:36:07 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
In-Reply-To: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
From: Alexander Leidinger <alexleidingerde@gmail.com>
Date: Mon, 12 Feb 2024 10:35:56 +0100
Message-ID: <CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
Subject: segfault in ld-elf.so.1
To: current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d1c78a06112c01a4"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.93 / 15.00];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_LONG(-0.98)[-0.975];
NEURAL_HAM_SHORT(-0.95)[-0.953];
DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
MIME_GOOD(-0.10)[multipart/alternative,text/plain];
RCVD_TLS_LAST(0.00)[];
ARC_NA(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
FREEMAIL_ENVFROM(0.00)[gmail.com];
TO_MATCH_ENVRCPT_ALL(0.00)[];
FREEMAIL_FROM(0.00)[gmail.com];
MIME_TRACE(0.00)[0:+,1:+,2:~];
FROM_HAS_DN(0.00)[];
RCVD_COUNT_ONE(0.00)[1];
MISSING_XM_UA(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
TO_DN_NONE(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
DKIM_TRACE(0.00)[gmail.com:+];
MID_RHS_MATCH_FROMTLD(0.00)[];
ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
MLMMJ_DEST(0.00)[current@freebsd.org];
DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]
X-Rspamd-Queue-Id: 4TYK8S46Pdz4HrS
--000000000000d1c78a06112c01a4
Content-Type: text/plain; charset="UTF-8"
Hi,
dovecot (and no other program I use on this machine... at least not that I
notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
have been fixed by changes to libc/libsys since 2024-02-10-144617). The
issue shows up when I try to do an IMAP login. A successful authentication
starts the imap process which immediately segfaults.
I didn't recompile dovecot for the initial update, but I did now to rule
out a regression in this area (and to get access via imap do my normal mail
account).
Backtrace:
---snip---
(lldb) target create "/usr/local/libexec/dovecot/imap" --core
"/var/run/dovecot/imap.core"
Core file '/var/run/dovecot/imap.core' (x86_64) was loaded.
* thread #1, name = 'imap', stop reason = signal SIGSEGV
* frame #0: 0x00004d3dfa2a4761 ld-elf.so.1`load_object [inlined]
object_match_name(obj=0x000049a47c203408, name="") at rtld.c:5606:6
frame #1: 0x00004d3dfa2a4742 ld-elf.so.1`load_object(name="", fd_u=-1,
refobj=0x000049a47c228008, flags=0) at rtld.c:2704:10
frame #2: 0x00004d3dfa2a3eaa ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3747:8
frame #3: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #4: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #5: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded011502e0, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #6: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded01150368, objlist=<unavailable>,
dlp=0x00001ded011504b0) at rtld.c:4637:13
frame #7: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded01150470,
donelist=0x00001ded011504b0) at rtld.c:4541:8
frame #8: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #9: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded01150988,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #10: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #11: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #12: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #13: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded01150a80, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #14: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded01150b08, objlist=<unavailable>,
dlp=0x00001ded01150c50) at rtld.c:4637:13
frame #15: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded01150c10,
donelist=0x00001ded01150c50) at rtld.c:4541:8
frame #16: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #17: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded01151128,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #18: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #19: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #20: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #21: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded01151220, obj=0x000049a47c228008) at
rtldc:4735:6
frame #22: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded011512a8, objlist=<unavailable>,
dlp=0x00001ded011513f0) at rtld.c:4637:13
frame #23: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded011513b0,
donelist=0x00001ded011513f0) at rtld.c:4541:8
frame #24: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #25: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded011518c8,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #26: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #27: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #28: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #29: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded011519c0, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #30: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded01151a48, objlist=<unavailable>,
dlp=0x00001ded01151b90) at rtld.c:4637:13
frame #31: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded01151b50,
donelist=0x00001ded01151b90) at rtld.c:4541:8
frame #32: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #33: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded01152068,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #34: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #35: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #36: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #37: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded01152160, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #38: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded011521e8, objlist=<unavailable>,
dlp=0x00001ded01152330) at rtld.c:4637:13
frame #39: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded011522f0,
donelist=0x00001ded01152330) at rtld.c:4541:8
frame #40: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #41: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded01152808,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #42: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #43: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #44: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #45: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded01152900, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #46: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded01152988, objlist=<unavailable>,
dlp=0x00001ded01152ad0) at rtld.c:4637:13
frame #47: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded01152a90,
donelist=0x00001ded01152ad0) at rtld.c:4541:8
frame #48: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
frame #49: 0x00004d3dfa2a4374 ld-elf.so1`dlopen_object [inlined]
distribute_static_tls(list=0x00001ded01152fa8,
lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
frame #50: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
refobj=0x000049a47c228008, lo_flags=0, mode=1,
lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
frame #51: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
frame #52: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
at rtld.c:2589:2
frame #53: 0x00004d3dfa2a223e
ld-elf.so.1`symlook_obj(req=0x00001ded011530a0, obj=0x000049a47c228008) at
rtld.c:4735:6
frame #54: 0x00004d3dfa2a6992
ld-elf.so.1`symlook_list(req=0x00001ded01153128, objlist=<unavailable>,
dlp=0x00001ded01153270) at rtld.c:4637:13
frame #55: 0x00004d3dfa2a680b
ld-elf.so.1`symlook_global(req=0x00001ded01153230,
donelist=0x00001ded01153270) at rtld.c:4541:8
frame #56: 0x00004d3dfa2a6673
ld-elf.so.1`get_program_var_addr(name=<unavailable>,
lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
---snip---
Bye,
Alexander.
--000000000000d1c78a06112c01a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div class=3D"gmail_quote"><div dir=3D"ltr"><div><br></=
div><div>dovecot (and no other program I use on this machine... at least no=
t that I notice it) segfaults in ld-elf.so.1 after an update from 2024-01-1=
8-092730 to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the is=
sue would have been fixed by changes to libc/libsys since=20
2024-02-10-144617). The issue shows up when I try to do an IMAP login. A su=
ccessful authentication starts the imap process which immediately segfaults=
.<br></div><div><br></div><div>I didn't recompile dovecot for the initi=
al update, but I did now to rule out a regression in this area (and to get =
access via imap do my normal mail account).</div><div><br></div><div><br></=
div><div>Backtrace:<br></div><div>---snip---</div><div>(lldb) target create=
"/usr/local/libexec/dovecot/imap" --core "/var/run/dovecot/=
imap.core"<br>Core file '/var/run/dovecot/imap.core' (x86_64) =
was loaded.<br>* thread #1, name =3D 'imap', stop reason =3D signal=
SIGSEGV<br>=C2=A0 * frame #0: 0x00004d3dfa2a4761 ld-elf.so.1`load_object [=
inlined] object_match_name(obj=3D0x000049a47c203408, name=3D"") a=
t rtld.c:5606:6<br>=C2=A0 =C2=A0 frame #1: 0x00004d3dfa2a4742 ld-elf.so.1`l=
oad_object(name=3D"", fd_u=3D-1, refobj=3D0x000049a47c228008, fla=
gs=3D0) at rtld.c:2704:10<br>=C2=A0 =C2=A0 frame #2: 0x00004d3dfa2a3eaa ld-=
elf.so.1`dlopen_object(name=3D"", fd=3D-1, refobj=3D0x000049a47c2=
28008, lo_flags=3D0, mode=3D1, lockstate=3D0x00001ded0f98cb80) at rtld.c:37=
47:8<br>=C2=A0 =C2=A0 frame #3: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj =
[inlined] load_filtee1(obj=3D<unavailable>, needed=3D0x000049a47c2007=
c8, flags=3D<unavailable>, lockstate=3D<unavailable>) at rtld.c=
:2576:16<br>=C2=A0 =C2=A0 frame #4: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_=
obj [inlined] load_filtees(obj=3D0x000049a47c228008, flags=3D0, lockstate=
=3D0x00001ded0f98cb80) at rtld.c:2589:2<br>=C2=A0 =C2=A0 frame #5: 0x00004d=
3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001ded011502e0, obj=3D0x000049=
a47c228008) at rtld.c:4735:6<br>=C2=A0 =C2=A0 frame #6: 0x00004d3dfa2a6992 =
ld-elf.so.1`symlook_list(req=3D0x00001ded01150368, objlist=3D<unavailabl=
e>, dlp=3D0x00001ded011504b0) at rtld.c:4637:13<br>=C2=A0 =C2=A0 frame #=
7: 0x00004d3dfa2a680b ld-elf.so.1`symlook_global(req=3D0x00001ded01150470, =
donelist=3D0x00001ded011504b0) at rtld.c:4541:8<br>=C2=A0 =C2=A0 frame #8: =
0x00004d3dfa2a6673 ld-elf.so.1`get_program_var_addr(name=3D<unavailable&=
gt;, lockstate=3D0x00001ded0f98cb80) at rtld.c:4483:9<br>=C2=A0 =C2=A0 fram=
e #9: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined] distribute_sta=
tic_tls(list=3D0x00001ded01150988, lockstate=3D0x00001ded0f98cb80) at rtld.=
c:5908:6<br>=C2=A0 =C2=A0 frame #10: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_=
object(name=3D"", fd=3D-1, refobj=3D0x000049a47c228008, lo_flags=
=3D0, mode=3D1, lockstate=3D0x00001ded0f98cb80) at rtld.c:3831:6<br>=C2=A0 =
=C2=A0 frame #11: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined] load=
_filtee1(obj=3D<unavailable>, needed=3D0x000049a47c2007c8, flags=3D&l=
t;unavailable>, lockstate=3D<unavailable>) at rtld.c:2576:16<br>=
=C2=A0 =C2=A0 frame #12: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inline=
d] load_filtees(obj=3D0x000049a47c228008, flags=3D0, lockstate=3D0x00001ded=
0f98cb80) at rtld.c:2589:2<br>=C2=A0 =C2=A0 frame #13: 0x00004d3dfa2a223e l=
d-elf.so.1`symlook_obj(req=3D0x00001ded01150a80, obj=3D0x000049a47c228008) =
at rtld.c:4735:6<br>=C2=A0 =C2=A0 frame #14: 0x00004d3dfa2a6992 ld-elf.so.1=
`symlook_list(req=3D0x00001ded01150b08, objlist=3D<unavailable>, dlp=
=3D0x00001ded01150c50) at rtld.c:4637:13<br>=C2=A0 =C2=A0 frame #15: 0x0000=
4d3dfa2a680b ld-elf.so.1`symlook_global(req=3D0x00001ded01150c10, donelist=
=3D0x00001ded01150c50) at rtld.c:4541:8<br>=C2=A0 =C2=A0 frame #16: 0x00004=
d3dfa2a6673 ld-elf.so.1`get_program_var_addr(name=3D<unavailable>, lo=
ckstate=3D0x00001ded0f98cb80) at rtld.c:4483:9<br>=C2=A0 =C2=A0 frame #17: =
0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined] distribute_static_tl=
s(list=3D0x00001ded01151128, lockstate=3D0x00001ded0f98cb80) at rtld.c:5908=
:6<br>=C2=A0 =C2=A0 frame #18: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object=
(name=3D"", fd=3D-1, refobj=3D0x000049a47c228008, lo_flags=3D0, m=
ode=3D1, lockstate=3D0x00001ded0f98cb80) at rtld.c:3831:6<br>=C2=A0 =C2=A0 =
frame #19: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined] load_filtee=
1(obj=3D<unavailable>, needed=3D0x000049a47c2007c8, flags=3D<unava=
ilable>, lockstate=3D<unavailable>) at rtld.c:2576:16<br>=C2=A0 =
=C2=A0 frame #20: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined] load=
_filtees(obj=3D0x000049a47c228008, flags=3D0, lockstate=3D0x00001ded0f98cb8=
0) at rtld.c:2589:2<br>=C2=A0 =C2=A0 frame #21: 0x00004d3dfa2a223e ld-elf.s=
o.1`symlook_obj(req=3D0x00001ded01151220, obj=3D0x000049a47c228008) at rtld=
c:4735:6<br>=C2=A0 =C2=A0 frame #22: 0x00004d3dfa2a6992 ld-elf.so.1`symlook=
_list(req=3D0x00001ded011512a8, objlist=3D<unavailable>, dlp=3D0x0000=
1ded011513f0) at rtld.c:4637:13<br>=C2=A0 =C2=A0 frame #23: 0x00004d3dfa2a6=
80b ld-elf.so.1`symlook_global(req=3D0x00001ded011513b0, donelist=3D0x00001=
ded011513f0) at rtld.c:4541:8<br>=C2=A0 =C2=A0 frame #24: 0x00004d3dfa2a667=
3 ld-elf.so.1`get_program_var_addr(name=3D<unavailable>, lockstate=3D=
0x00001ded0f98cb80) at rtld.c:4483:9<br>=C2=A0 =C2=A0 frame #25: 0x00004d3d=
fa2a4374 ld-elf.so.1`dlopen_object [inlined] distribute_static_tls(list=3D0=
x00001ded011518c8, lockstate=3D0x00001ded0f98cb80) at rtld.c:5908:6<br>=C2=
=A0 =C2=A0 frame #26: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name=3D&=
quot;", fd=3D-1, refobj=3D0x000049a47c228008, lo_flags=3D0, mode=3D1, =
lockstate=3D0x00001ded0f98cb80) at rtld.c:3831:6<br>=C2=A0 =C2=A0 frame #27=
: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined] load_filtee1(obj=3D&=
lt;unavailable>, needed=3D0x000049a47c2007c8, flags=3D<unavailable>=
;, lockstate=3D<unavailable>) at rtld.c:2576:16<br>=C2=A0 =C2=A0 fram=
e #28: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined] load_filtees(ob=
j=3D0x000049a47c228008, flags=3D0, lockstate=3D0x00001ded0f98cb80) at rtld.=
c:2589:2<br>=C2=A0 =C2=A0 frame #29: 0x00004d3dfa2a223e ld-elf.so.1`symlook=
_obj(req=3D0x00001ded011519c0, obj=3D0x000049a47c228008) at rtld.c:4735:6<b=
r>=C2=A0 =C2=A0 frame #30: 0x00004d3dfa2a6992 ld-elf.so.1`symlook_list(req=
=3D0x00001ded01151a48, objlist=3D<unavailable>, dlp=3D0x00001ded01151=
b90) at rtld.c:4637:13<br>=C2=A0 =C2=A0 frame #31: 0x00004d3dfa2a680b ld-el=
f.so.1`symlook_global(req=3D0x00001ded01151b50, donelist=3D0x00001ded01151b=
90) at rtld.c:4541:8<br>=C2=A0 =C2=A0 frame #32: 0x00004d3dfa2a6673 ld-elf.=
so.1`get_program_var_addr(name=3D<unavailable>, lockstate=3D0x00001de=
d0f98cb80) at rtld.c:4483:9<br>=C2=A0 =C2=A0 frame #33: 0x00004d3dfa2a4374 =
ld-elf.so.1`dlopen_object [inlined] distribute_static_tls(list=3D0x00001ded=
01152068, lockstate=3D0x00001ded0f98cb80) at rtld.c:5908:6<br>=C2=A0 =C2=A0=
frame #34: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name=3D""=
;, fd=3D-1, refobj=3D0x000049a47c228008, lo_flags=3D0, mode=3D1, lockstate=
=3D0x00001ded0f98cb80) at rtld.c:3831:6<br>=C2=A0 =C2=A0 frame #35: 0x00004=
d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined] load_filtee1(obj=3D<unavai=
lable>, needed=3D0x000049a47c2007c8, flags=3D<unavailable>, lockst=
ate=3D<unavailable>) at rtld.c:2576:16<br>=C2=A0 =C2=A0 frame #36: 0x=
00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined] load_filtees(obj=3D0x000=
049a47c228008, flags=3D0, lockstate=3D0x00001ded0f98cb80) at rtld.c:2589:2<=
br>=C2=A0 =C2=A0 frame #37: 0x00004d3dfa2a223e ld-elf.so.1`symlook_obj(req=
=3D0x00001ded01152160, obj=3D0x000049a47c228008) at rtld.c:4735:6<br>=C2=A0=
=C2=A0 frame #38: 0x00004d3dfa2a6992 ld-elf.so.1`symlook_list(req=3D0x0000=
1ded011521e8, objlist=3D<unavailable>, dlp=3D0x00001ded01152330) at r=
tld.c:4637:13<br>=C2=A0 =C2=A0 frame #39: 0x00004d3dfa2a680b ld-elf.so.1`sy=
mlook_global(req=3D0x00001ded011522f0, donelist=3D0x00001ded01152330) at rt=
ld.c:4541:8<br>=C2=A0 =C2=A0 frame #40: 0x00004d3dfa2a6673 ld-elf.so.1`get_=
program_var_addr(name=3D<unavailable>, lockstate=3D0x00001ded0f98cb80=
) at rtld.c:4483:9<br>=C2=A0 =C2=A0 frame #41: 0x00004d3dfa2a4374 ld-elf.so=
.1`dlopen_object [inlined] distribute_static_tls(list=3D0x00001ded01152808,=
lockstate=3D0x00001ded0f98cb80) at rtld.c:5908:6<br>=C2=A0 =C2=A0 frame #4=
2: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name=3D"", fd=3D-=
1, refobj=3D0x000049a47c228008, lo_flags=3D0, mode=3D1, lockstate=3D0x00001=
ded0f98cb80) at rtld.c:3831:6<br>=C2=A0 =C2=A0 frame #43: 0x00004d3dfa2a227=
4 ld-elf.so.1`symlook_obj [inlined] load_filtee1(obj=3D<unavailable>,=
needed=3D0x000049a47c2007c8, flags=3D<unavailable>, lockstate=3D<=
unavailable>) at rtld.c:2576:16<br>=C2=A0 =C2=A0 frame #44: 0x00004d3dfa=
2a2245 ld-elf.so.1`symlook_obj [inlined] load_filtees(obj=3D0x000049a47c228=
008, flags=3D0, lockstate=3D0x00001ded0f98cb80) at rtld.c:2589:2<br>=C2=A0 =
=C2=A0 frame #45: 0x00004d3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001d=
ed01152900, obj=3D0x000049a47c228008) at rtld.c:4735:6<br>=C2=A0 =C2=A0 fra=
me #46: 0x00004d3dfa2a6992 ld-elf.so.1`symlook_list(req=3D0x00001ded0115298=
8, objlist=3D<unavailable>, dlp=3D0x00001ded01152ad0) at rtld.c:4637:=
13<br>=C2=A0 =C2=A0 frame #47: 0x00004d3dfa2a680b ld-elf.so.1`symlook_globa=
l(req=3D0x00001ded01152a90, donelist=3D0x00001ded01152ad0) at rtld.c:4541:8=
<br>=C2=A0 =C2=A0 frame #48: 0x00004d3dfa2a6673 ld-elf.so.1`get_program_var=
_addr(name=3D<unavailable>, lockstate=3D0x00001ded0f98cb80) at rtld.c=
:4483:9<br>=C2=A0 =C2=A0 frame #49: 0x00004d3dfa2a4374 ld-elf.so1`dlopen_ob=
ject [inlined] distribute_static_tls(list=3D0x00001ded01152fa8, lockstate=
=3D0x00001ded0f98cb80) at rtld.c:5908:6<br>=C2=A0 =C2=A0 frame #50: 0x00004=
d3dfa2a4364 ld-elf.so.1`dlopen_object(name=3D"", fd=3D-1, refobj=
=3D0x000049a47c228008, lo_flags=3D0, mode=3D1, lockstate=3D0x00001ded0f98cb=
80) at rtld.c:3831:6<br>=C2=A0 =C2=A0 frame #51: 0x00004d3dfa2a2274 ld-elf.=
so.1`symlook_obj [inlined] load_filtee1(obj=3D<unavailable>, needed=
=3D0x000049a47c2007c8, flags=3D<unavailable>, lockstate=3D<unavail=
able>) at rtld.c:2576:16<br>=C2=A0 =C2=A0 frame #52: 0x00004d3dfa2a2245 =
ld-elf.so.1`symlook_obj [inlined] load_filtees(obj=3D0x000049a47c228008, fl=
ags=3D0, lockstate=3D0x00001ded0f98cb80) at rtld.c:2589:2<br>=C2=A0 =C2=A0 =
frame #53: 0x00004d3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001ded01153=
0a0, obj=3D0x000049a47c228008) at rtld.c:4735:6<br>=C2=A0 =C2=A0 frame #54:=
0x00004d3dfa2a6992 ld-elf.so.1`symlook_list(req=3D0x00001ded01153128, objl=
ist=3D<unavailable>, dlp=3D0x00001ded01153270) at rtld.c:4637:13<br>=
=C2=A0 =C2=A0 frame #55: 0x00004d3dfa2a680b ld-elf.so.1`symlook_global(req=
=3D0x00001ded01153230, donelist=3D0x00001ded01153270) at rtld.c:4541:8<br>=
=C2=A0 =C2=A0 frame #56: 0x00004d3dfa2a6673 ld-elf.so.1`get_program_var_add=
r(name=3D<unavailable>, lockstate=3D0x00001ded0f98cb80) at rtld.c:448=
3:9</div><div>---snip---</div><div><br></div><div>Bye,</div><div>Alexander.=
<br></div></div>
</div></div>
--000000000000d1c78a06112c01a4--
From nobody Mon Feb 12 09:36:32 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 4TYK9B30yqz59Qr2
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 09:36:46 +0000 (UTC)
(envelope-from alexleidingerde@gmail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
(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 4TYK993vFlz4JwM
for <current@freebsd.org>; Mon, 12 Feb 2024 09:36:45 +0000 (UTC)
(envelope-from alexleidingerde@gmail.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=gmail.com header.s=20230601 header.b="MZ/vFV/p";
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (mx1.freebsd.org: domain of alexleidingerde@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=alexleidingerde@gmail.com
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a30f7c9574eso344273766b.0
for <current@freebsd.org>; Mon, 12 Feb 2024 01:36:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1707730603; x=1708335403; darn=freebsd.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=7TJpHMaGIrzXbOBtBRaW6TR+8VAmpakhfgI6P1GcWns=;
b=MZ/vFV/p+W5uwrgfIT+PGcedE9O8MvosqXYP16pqpmxmlICgPZjCin2hxeWbL296tw
QmD0wC4WClOHOSGQPEAibgIwhsXxiwKbWzEHuIs4XFMOfZV+SgFHXMdZo83yYz1YVQHJ
ISHRfsvfygYflLOz0J5l1mGzvcKTmrb9xxIinyBNYuFCWfIRzggJt+HBVgt35OntKMZr
pc6n8WdV3s1W6JrhnqDDv/orp+heXYDTthYc+D5siq+L4jWdL7wahLa2JV3ocmSl0o8R
+84ACHVnPWUSJfTAx58NWrFCyrYvZ/mrfHXQb2sPKs22iYDwcuZ+EGfVg9grhuxinTTW
tbmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707730603; x=1708335403;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=7TJpHMaGIrzXbOBtBRaW6TR+8VAmpakhfgI6P1GcWns=;
b=LE4SbT1sQS395gT2uzpWHWW5VT1P2z4Ti1u7v0NdfgKSeVd4FAmsOZ0wX4RCAO23YZ
vN1tptwq4X0jBLxoRewbgm0psHX6gzln8a7gVsY68xmEuw1kTCpdYOWGSgFYiMIuJxB6
sJbBas6yaNGS3rg+tDwrj3J6v91dQ/JCKFjMP/P8HOCY61jeUdqF0XqaV3389C4bw3bI
lkMue4wnBYufc00OvH6mN7EObbQ+yaP3JplR4eyepOEVL6mfTlc2G+Q/jKd/ZQk+7gGe
rJtJRssRar3o2GaQWgmkSntLBAcnegTTG9ZlMUkS9ferUELtNokVYUSbKUdKeve4KoHs
9Sgg==
X-Gm-Message-State: AOJu0YxzP0T2jJJzvTbdi16ZaLvbaTC0j27tJeLXR7vVYoQhKF5LQ2ZB
rBVTOL1jXu+O4bPYUneaIg+hlfewr498ZS9t88deiQrieg8dT7wNAeIVQHyNcLKF5sEbLXsVleD
eknqe8oLIzX9PY2rBl0JDVWP6Jg49t6UZ
X-Google-Smtp-Source: AGHT+IFVf3xLRl+pfJ7CetyfVNM3v8Qg6+6sjBERfN/rh7rcvvfyLElkKGVPTZW280hjM6EPprZGQq1sGk9lP/UdWpM=
X-Received: by 2002:a17:906:f28d:b0:a3c:cfc0:9f55 with SMTP id
gu13-20020a170906f28d00b00a3ccfc09f55mr400395ejb.48.1707730603002; Mon, 12
Feb 2024 01:36:43 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org>
In-Reply-To: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org>
From: Alexander Leidinger <alexleidingerde@gmail.com>
Date: Mon, 12 Feb 2024 10:36:32 +0100
Message-ID: <CAJg7qzH_c8JCKQvLPki6Cv7GRzaQs9vA-omSWBxnFTPy_9Rczw@mail.gmail.com>
Subject: kernel crash in tcp_subr.c:2386
To: current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f6d20a06112c031b"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.96 / 15.00];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_LONG(-0.99)[-0.991];
NEURAL_HAM_SHORT(-0.97)[-0.972];
DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
MIME_GOOD(-0.10)[multipart/alternative,text/plain];
TO_MATCH_ENVRCPT_ALL(0.00)[];
RCVD_TLS_LAST(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
MIME_TRACE(0.00)[0:+,1:+,2:~];
ARC_NA(0.00)[];
DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
FREEMAIL_FROM(0.00)[gmail.com];
DKIM_TRACE(0.00)[gmail.com:+];
FROM_HAS_DN(0.00)[];
FREEMAIL_ENVFROM(0.00)[gmail.com];
PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
TO_DN_NONE(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
MISSING_XM_UA(0.00)[];
MID_RHS_MATCH_FROMTLD(0.00)[];
ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
MLMMJ_DEST(0.00)[current@freebsd.org];
RCVD_COUNT_ONE(0.00)[1];
RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]
X-Rspamd-Queue-Id: 4TYK993vFlz4JwM
--000000000000f6d20a06112c031b
Content-Type: text/plain; charset="UTF-8"
Hi,
I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
---snip---
__curthread () at /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) #0 __curthread () at
/space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
td = <optimized out>
#1 doadump (textdump=textdump@entry=1)
at /space/system/usr_src/sys/kern/kern_shutdown.c:403
error = 0
coredump = <optimized out>
#2 0xffffffff8052fe85 in kern_reboot (howto=260)
at /space/system/usr_src/sys/kern/kern_shutdown.c:521
once = 0
__pc = <optimized out>
#3 0xffffffff80530382 in vpanic (
fmt=0xffffffff808df476 "Assertion %s failed at %s:%d",
ap=ap@entry=0xfffffe08a079ebf0)
at /space/system/usr_src/sys/kern/kern_shutdownc:973
buf = "Assertion !callout_active(&tp->t_callout) failed at
/space/system/usr_src/sys/netinet/tcp_subr.c:2386", '\000' <repeats 154
times>
__pc = <optimized out>
__pc = <optimized out>
__pc = <optimized out>
other_cpus = {__bits = {14680063, 0 <repeats 15 times>}}
td = 0xfffff8068ef99740
bootopt = <unavailable>
newpanic = <optimized out>
#4 0xffffffff805301d3 in panic (fmt=<unavailable>)
at /space/system/usr_src/sys/kern/kern_shutdown.c:889
ap = {{gp_offset = 32, fp_offset = 48,
overflow_arg_area = 0xfffffe08a079ec20,
reg_save_area = 0xfffffe08a079ebc0}}
#5 0xffffffff806c9d8c in tcp_discardcb (tp=tp@entry=0xfffff80af441ba80)
at /space/system/usr_src/sys/netinet/tcp_subr.c:2386
inp = 0xfffff80af441ba80
so = 0xfffff804d23d2780
m = <optimized out>
isipv6 = <optimized out>
#6 0xffffffff806d6291 in tcp_usr_detach (so=0xfffff804d23d2780)
at /space/system/usr_src/sys/netinet/tcp_usrreq.c:214
inp = 0xfffff80af441ba80
tp = 0xfffff80af441ba80
#7 0xffffffff805dba57 in sofree (so=0xfffff804d23d2780)
at /space/system/usr_src/sys/kern/uipc_socket.c:1205
pr = 0xffffffff80a8bd18 <tcp_protosw>
#8 sorele_locked (so=so@entry=0xfffff804d23d2780)
at /space/system/usr_src/sys/kern/uipc_socket.c:1232
No locals.
#9 0xffffffff805dc8c0 in soclose (so=0xfffff804d23d2780)
at /space/system/usr_src/sys/kern/uipc_socket.c:1302
lqueue = {tqh_first = 0xfffff8068ef99740,
tqh_last = 0xfffffe08a079ed40}
error = 0
saved_vnet = 0x0
last = <optimized out>
listening = <optimized out>
#10 0xffffffff804ccbd1 in fo_close (fp=0xfffff805f2dfc500, td=<unavailable>)
at /space/system/usr_src/sys/sys/file.h:390
No locals.
#11 _fdrop (fp=fp@entry=0xfffff805f2dfc500, td=<unavailable>,
td@entry=0xfffff8068ef99740)
at /space/system/usr_src/sys/kern/kern_descrip.c:3666
count = <unavailable>
error = <optimized out>
#12 0xffffffff804d02f3 in closef (fp=fp@entry=0xfffff805f2dfc500,
td=td@entry=0xfffff8068ef99740)
at /space/system/usr_src/sys/kern/kern_descrip.c:2839
_error = 0
_fp = 0xfffff805f2dfc500
lf = {l_start = -8791759350504, l_len = -8791759350528, l_pid = 0,
l_type = 0, l_whence = 0, l_sysid = 0}
vp = <optimized out>
fdtol = <optimized out>
fdp = <optimized out>
#13 0xffffffff804cd50c in closefp_impl (fdp=0xfffffe07afebf860, fd=19,
fp=0xfffff805f2dfc500, td=0xfffff8068ef99740, audit=<optimized out>)
at /space/system/usr_src/sys/kern/kern_descrip.c:1315
error = <optimized out>
#14 closefp (fdp=0xfffffe07afebf860, fd=19, fp=0xfffff805f2dfc500,
td=0xfffff8068ef99740, holdleaders=true, audit=<optimized out>)
at /space/system/usr_src/sys/kern/kern_descrip.c:1372
No locals.
#15 0xffffffff808597d6 in syscallenter (td=0xfffff8068ef99740)
at /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:186
se = 0xffffffff80a48330 <sysent+192>
p = 0xfffffe07f29995c0
sa = 0xfffff8068ef99b30
error = <optimized out>
sy_thr_static = <optimized out>
traced = <optimized out>
#16 amd64_syscall (td=0xfffff8068ef99740, traced=0)
at /space/system/usr_src/sys/amd64/amd64/trap.c:1192
ksi = {ksi_link = {tqe_next = 0xfffffe08a079ef30,
tqe_prev = 0xffffffff808588af <trap+2351>}, ksi_info = {
si_signo = 1, si_errno = 0, si_code = 2015268872, si_pid = -512,
si_uid = 2398721856, si_status = -2042,
si_addr = 0xfffffe08a079ef40, si_value = {sival_int =
-1602621824,
sival_ptr = 0xfffffe08a079ee80, sigval_int = -1602621824,
sigval_ptr = 0xfffffe08a079ee80}, _reason = {_fault = {
_trapno = 1489045984}, _timer = {_timerid = 1489045984,
_overrun = 17999}, _mesgq = {_mqd = 1489045984}, _poll = {
_band = 77306605406688}, _capsicum = {_syscall =
1489045984},
__spare__ = {__spare1__ = 77306605406688, __spare2__ = {
1489814048, 17999, 208, 0, 0, 0, 992191072}}}},
ksi_flags = 975329968, ksi_sigq = 0xffffffff8082f8f3
<Xinvlop+179>}
#17 <signal handler called>
No locals.
#18 0x00003af13b17fc9a in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x3af13a225ab8
---snip---
Any ideas?
Due to another issue in userland, I updated to 2024-02-11-212006, but I
have the above mentioned version and core still in a BE if needed.
Bye,
Alexander.
--000000000000f6d20a06112c031b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div class=3D"gmail_quote"><div dir=3D"ltr"><br>I got a=
coredump with sources from 2024-02-10-144617 (GMT+0100):<br>---snip---<br>=
__curthread () at /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57<br>=
57 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__asm("movq %%gs:%P=
1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcpu,<b=
r>(kgdb) #0 =C2=A0__curthread () at /space/system/usr_src/sys/amd64/include=
/pcpu_aux.h:57<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 td =3D <optimized out><=
br>#1 =C2=A0doadump (textdump=3Dtextdump@entry=3D1)<br>=C2=A0 =C2=A0 at /sp=
ace/system/usr_src/sys/kern/kern_shutdown.c:403<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 error =3D 0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 coredump =3D <optimized o=
ut><br>#2 =C2=A00xffffffff8052fe85 in kern_reboot (howto=3D260)<br>=C2=
=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_shutdown.c:521<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 once =3D 0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <=
;optimized out><br>#3 =C2=A00xffffffff80530382 in vpanic (<br>=C2=A0 =C2=
=A0 fmt=3D0xffffffff808df476 "Assertion %s failed at %s:%d",<br>=
=C2=A0 =C2=A0 ap=3Dap@entry=3D0xfffffe08a079ebf0)<br>=C2=A0 =C2=A0 at /spac=
e/system/usr_src/sys/kern/kern_shutdownc:973<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
buf =3D "Assertion !callout_active(&tp->t_callout) failed at /=
space/system/usr_src/sys/netinet/tcp_subr.c:2386", '\000' <=
repeats 154 times><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized=
out><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized out><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized out><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 other_cpus =3D {__bits =3D {14680063, 0 <repeats 15 times=
>}}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 td =3D 0xfffff8068ef99740<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 bootopt =3D <unavailable><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 newpanic =3D <optimized out><br>#4 =C2=A00xffffffff805301d=
3 in panic (fmt=3D<unavailable>)<br>=C2=A0 =C2=A0 at /space/system/us=
r_src/sys/kern/kern_shutdown.c:889<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ap =3D {{=
gp_offset =3D 32, fp_offset =3D 48,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 overflow_arg_area =3D 0xfffffe08a079ec20,<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 reg_save_area =3D 0xfffffe08a079ebc0}}<br>#5 =C2=A00xf=
fffffff806c9d8c in tcp_discardcb (tp=3Dtp@entry=3D0xfffff80af441ba80)<br>=
=C2=A0 =C2=A0 at /space/system/usr_src/sys/netinet/tcp_subr.c:2386<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 inp =3D 0xfffff80af441ba80<br>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 so =3D 0xfffff804d23d2780<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 m =3D <=
optimized out><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 isipv6 =3D <optimized o=
ut><br>#6 =C2=A00xffffffff806d6291 in tcp_usr_detach (so=3D0xfffff804d23=
d2780)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/netinet/tcp_usrreq.c:2=
14<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 inp =3D 0xfffff80af441ba80<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 tp =3D 0xfffff80af441ba80<br>#7 =C2=A00xffffffff805dba57 =
in sofree (so=3D0xfffff804d23d2780)<br>=C2=A0 =C2=A0 at /space/system/usr_s=
rc/sys/kern/uipc_socket.c:1205<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pr =3D 0xffff=
ffff80a8bd18 <tcp_protosw><br>#8 =C2=A0sorele_locked (so=3Dso@entry=
=3D0xfffff804d23d2780)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/u=
ipc_socket.c:1232<br>No locals.<br>#9 =C2=A00xffffffff805dc8c0 in soclose (=
so=3D0xfffff804d23d2780)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern=
/uipc_socket.c:1302<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 lqueue =3D {tqh_first =
=3D 0xfffff8068ef99740,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tqh_last =3D =
0xfffffe08a079ed40}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D 0<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 saved_vnet =3D 0x0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 last=
=3D <optimized out><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 listening =3D <=
;optimized out><br>#10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2=
dfc500, td=3D<unavailable>)<br>=C2=A0 =C2=A0 at /space/system/usr_src=
/sys/sys/file.h:390<br>No locals.<br>#11 _fdrop (fp=3Dfp@entry=3D0xfffff805=
f2dfc500, td=3D<unavailable>,<br>=C2=A0 =C2=A0 td@entry=3D0xfffff8068=
ef99740)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:=
3666<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 count =3D <unavailable><br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 error =3D <optimized out><br>#12 0xffffffff804d=
02f3 in closef (fp=3Dfp@entry=3D0xfffff805f2dfc500,<br>=C2=A0 =C2=A0 td=3Dt=
d@entry=3D0xfffff8068ef99740)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys=
/kern/kern_descrip.c:2839<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 _error =3D 0<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _fp =3D 0xfffff805f2dfc500<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 lf =3D {l_start =3D -8791759350504, l_len =3D -8791759350528, l_=
pid =3D 0,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l_type =3D 0, l_whence =3D=
0, l_sysid =3D 0}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 vp =3D <optimized out&=
gt;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 fdtol =3D <optimized out><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 fdp =3D <optimized out><br>#13 0xffffffff804=
cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, fd=3D19,<br>=C2=A0 =C2=A0 =
fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D<optimized out=
>)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:131=
5<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D <optimized out><br>#14 clo=
sefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,<br>=C2=A0=
=C2=A0 td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D<optimized =
out>)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:=
1372<br>No locals.<br>#15 0xffffffff808597d6 in syscallenter (td=3D0xfffff8=
068ef99740)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/amd64/amd64/../..=
/kern/subr_syscall.c:186<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 se =3D 0xffffffff80=
a48330 <sysent+192><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 p =3D 0xfffffe07f2=
9995c0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sa =3D 0xfffff8068ef99b30<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 error =3D <optimized out><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 sy_thr_static =3D <optimized out><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 traced =3D <optimized out><br>#16 amd64_syscall (td=3D0xfffff8=
068ef99740, traced=3D0)<br>=C2=A0 =C2=A0 at /space/system/usr_src/sys/amd64=
/amd64/trap.c:1192<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ksi =3D {ksi_link =3D {tq=
e_next =3D 0xfffffe08a079ef30,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
tqe_prev =3D 0xffffffff808588af <trap+2351>}, ksi_info =3D {<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 si_signo =3D 1, si_errno =3D 0, si_c=
ode =3D 2015268872, si_pid =3D -512,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 si_uid =3D 2398721856, si_status =3D -2042,<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 si_addr =3D 0xfffffe08a079ef40, si_value =3D {sival_in=
t =3D -1602621824,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 siva=
l_ptr =3D 0xfffffe08a079ee80, sigval_int =3D -1602621824,<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sigval_ptr =3D 0xfffffe08a079ee80}, _rea=
son =3D {_fault =3D {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 _trapno =3D 1489045984}, _timer =3D {_timerid =3D 1489045984,<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _overrun =3D 17999}, _=
mesgq =3D {_mqd =3D 1489045984}, _poll =3D {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _band =3D 77306605406688}, _capsicum =3D {_sys=
call =3D 1489045984},<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _=
_spare__ =3D {__spare1__ =3D 77306605406688, __spare2__ =3D {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1489814048, 17999, 208=
, 0, 0, 0, 992191072}}}},<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ksi_flags =
=3D 975329968, ksi_sigq =3D 0xffffffff8082f8f3 <Xinvlop+179>}<br>#17 =
<signal handler called><br>No locals.<br>#18 0x00003af13b17fc9a in ??=
()<br>No symbol table info available.<br>Backtrace stopped: Cannot access =
memory at address 0x3af13a225ab8<br>---snip---<br><br>Any ideas?<br><div><b=
r></div><div>Due to another issue in userland, I updated to 2024-02-11-2120=
06, but I have the above mentioned version and core still in a BE if needed=
.<br></div><div><br></div>Bye,<br>Alexander.<br></div>
</div></div>
--000000000000f6d20a06112c031b--
From nobody Mon Feb 12 09:53:57 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 4TYKY84qFWz59SgL
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 09:54: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 4TYKY833wyz4Lrh
for <current@freebsd.org>; Mon, 12 Feb 2024 09:54:04 +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 41C9rvAt067580;
Mon, 12 Feb 2024 11:54:00 +0200 (EET)
(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 41C9rvAt067580
Received: (from kostik@localhost)
by tom.home (8.18.1/8.18.1/Submit) id 41C9rvGi067579;
Mon, 12 Feb 2024 11:53:57 +0200 (EET)
(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Mon, 12 Feb 2024 11:53:57 +0200
From: Konstantin Belousov <kostikbel@gmail.com>
To: Alexander Leidinger <alexleidingerde@gmail.com>
Cc: current@freebsd.org
Subject: Re: segfault in ld-elf.so.1
Message-ID: <ZcnqtY0dQoed9yjw@kib.kiev.ua>
References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
<CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
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-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: 4TYKY833wyz4Lrh
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Mon, Feb 12, 2024 at 10:35:56AM +0100, Alexander Leidinger wrote:
> Hi,
>
> dovecot (and no other program I use on this machine... at least not that I
> notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
> to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
> have been fixed by changes to libc/libsys since 2024-02-10-144617). The
> issue shows up when I try to do an IMAP login. A successful authentication
> starts the imap process which immediately segfaults.
>
> I didn't recompile dovecot for the initial update, but I did now to rule
> out a regression in this area (and to get access via imap do my normal mail
> account).
>
>
> Backtrace:
The backtrace looks incomplete. It might be the case of infinite recursion,
but I cannot claim it from the trace.
Does the program segfault if you run it manually? If yes, please provide
me with the tarball of the binary and all required shared libs, including
base system libraries, from your machine.
> ---snip---
> (lldb) target create "/usr/local/libexec/dovecot/imap" --core
> "/var/run/dovecot/imap.core"
> Core file '/var/run/dovecot/imap.core' (x86_64) was loaded.
> * thread #1, name = 'imap', stop reason = signal SIGSEGV
> * frame #0: 0x00004d3dfa2a4761 ld-elf.so.1`load_object [inlined]
> object_match_name(obj=0x000049a47c203408, name="") at rtld.c:5606:6
> frame #1: 0x00004d3dfa2a4742 ld-elf.so.1`load_object(name="", fd_u=-1,
> refobj=0x000049a47c228008, flags=0) at rtld.c:2704:10
> frame #2: 0x00004d3dfa2a3eaa ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3747:8
> frame #3: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #4: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #5: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded011502e0, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #6: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded01150368, objlist=<unavailable>,
> dlp=0x00001ded011504b0) at rtld.c:4637:13
> frame #7: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded01150470,
> donelist=0x00001ded011504b0) at rtld.c:4541:8
> frame #8: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #9: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded01150988,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #10: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #11: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #12: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #13: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded01150a80, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #14: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded01150b08, objlist=<unavailable>,
> dlp=0x00001ded01150c50) at rtld.c:4637:13
> frame #15: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded01150c10,
> donelist=0x00001ded01150c50) at rtld.c:4541:8
> frame #16: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #17: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded01151128,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #18: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #19: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #20: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #21: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded01151220, obj=0x000049a47c228008) at
> rtldc:4735:6
> frame #22: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded011512a8, objlist=<unavailable>,
> dlp=0x00001ded011513f0) at rtld.c:4637:13
> frame #23: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded011513b0,
> donelist=0x00001ded011513f0) at rtld.c:4541:8
> frame #24: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #25: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded011518c8,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #26: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #27: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #28: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #29: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded011519c0, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #30: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded01151a48, objlist=<unavailable>,
> dlp=0x00001ded01151b90) at rtld.c:4637:13
> frame #31: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded01151b50,
> donelist=0x00001ded01151b90) at rtld.c:4541:8
> frame #32: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #33: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded01152068,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #34: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #35: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #36: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #37: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded01152160, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #38: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded011521e8, objlist=<unavailable>,
> dlp=0x00001ded01152330) at rtld.c:4637:13
> frame #39: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded011522f0,
> donelist=0x00001ded01152330) at rtld.c:4541:8
> frame #40: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #41: 0x00004d3dfa2a4374 ld-elf.so.1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded01152808,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #42: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #43: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #44: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #45: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded01152900, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #46: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded01152988, objlist=<unavailable>,
> dlp=0x00001ded01152ad0) at rtld.c:4637:13
> frame #47: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded01152a90,
> donelist=0x00001ded01152ad0) at rtld.c:4541:8
> frame #48: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> frame #49: 0x00004d3dfa2a4374 ld-elf.so1`dlopen_object [inlined]
> distribute_static_tls(list=0x00001ded01152fa8,
> lockstate=0x00001ded0f98cb80) at rtld.c:5908:6
> frame #50: 0x00004d3dfa2a4364 ld-elf.so.1`dlopen_object(name="", fd=-1,
> refobj=0x000049a47c228008, lo_flags=0, mode=1,
> lockstate=0x00001ded0f98cb80) at rtld.c:3831:6
> frame #51: 0x00004d3dfa2a2274 ld-elf.so.1`symlook_obj [inlined]
> load_filtee1(obj=<unavailable>, needed=0x000049a47c2007c8,
> flags=<unavailable>, lockstate=<unavailable>) at rtld.c:2576:16
> frame #52: 0x00004d3dfa2a2245 ld-elf.so.1`symlook_obj [inlined]
> load_filtees(obj=0x000049a47c228008, flags=0, lockstate=0x00001ded0f98cb80)
> at rtld.c:2589:2
> frame #53: 0x00004d3dfa2a223e
> ld-elf.so.1`symlook_obj(req=0x00001ded011530a0, obj=0x000049a47c228008) at
> rtld.c:4735:6
> frame #54: 0x00004d3dfa2a6992
> ld-elf.so.1`symlook_list(req=0x00001ded01153128, objlist=<unavailable>,
> dlp=0x00001ded01153270) at rtld.c:4637:13
> frame #55: 0x00004d3dfa2a680b
> ld-elf.so.1`symlook_global(req=0x00001ded01153230,
> donelist=0x00001ded01153270) at rtld.c:4541:8
> frame #56: 0x00004d3dfa2a6673
> ld-elf.so.1`get_program_var_addr(name=<unavailable>,
> lockstate=0x00001ded0f98cb80) at rtld.c:4483:9
> ---snip---
>
> Bye,
> Alexander.
From nobody Mon Feb 12 10:23: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 4TYLCg1k7vz59WZ4
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 10:23:59 +0000 (UTC)
(envelope-from tuexen@freebsd.org)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYLCf5zNtz4RCl
for <current@freebsd.org>; Mon, 12 Feb 2024 10:23:58 +0000 (UTC)
(envelope-from tuexen@freebsd.org)
Authentication-Results: mx1.freebsd.org;
none
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:2000:826:171b:5496])
(Authenticated sender: micmac)
by drew.franken.de (Postfix) with ESMTPSA id 2998A721E2806;
Mon, 12 Feb 2024 11:23:55 +0100 (CET)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: kernel crash in tcp_subr.c:2386
From: tuexen@freebsd.org
In-Reply-To: <CAJg7qzH_c8JCKQvLPki6Cv7GRzaQs9vA-omSWBxnFTPy_9Rczw@mail.gmail.com>
Date: Mon, 12 Feb 2024 11:23:54 +0100
Cc: current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>
References: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org>
<CAJg7qzH_c8JCKQvLPki6Cv7GRzaQs9vA-omSWBxnFTPy_9Rczw@mail.gmail.com>
To: Alexander Leidinger <alexleidingerde@gmail.com>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]
X-Rspamd-Queue-Id: 4TYLCf5zNtz4RCl
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
> On Feb 12, 2024, at 10:36, Alexander Leidinger =
<alexleidingerde@gmail.com> wrote:
>=20
> Hi,
>=20
> I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
Hi Alexander,
we are aware of this problem, but haven't found a way to reproduce it.
Do you know how to reproduce this?
Best regards
Michael
> ---snip---
> __curthread () at =
/space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
> 57 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" =
(offsetof(struct pcpu,
> (kgdb) #0 __curthread () at =
/space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
> td =3D <optimized out>
> #1 doadump (textdump=3Dtextdump@entry=3D1)
> at /space/system/usr_src/sys/kern/kern_shutdown.c:403
> error =3D 0
> coredump =3D <optimized out>
> #2 0xffffffff8052fe85 in kern_reboot (howto=3D260)
> at /space/system/usr_src/sys/kern/kern_shutdown.c:521
> once =3D 0
> __pc =3D <optimized out>
> #3 0xffffffff80530382 in vpanic (
> fmt=3D0xffffffff808df476 "Assertion %s failed at %s:%d",
> ap=3Dap@entry=3D0xfffffe08a079ebf0)
> at /space/system/usr_src/sys/kern/kern_shutdownc:973
> buf =3D "Assertion !callout_active(&tp->t_callout) failed at =
/space/system/usr_src/sys/netinet/tcp_subr.c:2386", '\000' <repeats 154 =
times>
> __pc =3D <optimized out>
> __pc =3D <optimized out>
> __pc =3D <optimized out>
> other_cpus =3D {__bits =3D {14680063, 0 <repeats 15 times>}}
> td =3D 0xfffff8068ef99740
> bootopt =3D <unavailable>
> newpanic =3D <optimized out>
> #4 0xffffffff805301d3 in panic (fmt=3D<unavailable>)
> at /space/system/usr_src/sys/kern/kern_shutdown.c:889
> ap =3D {{gp_offset =3D 32, fp_offset =3D 48,
> overflow_arg_area =3D 0xfffffe08a079ec20,
> reg_save_area =3D 0xfffffe08a079ebc0}}
> #5 0xffffffff806c9d8c in tcp_discardcb =
(tp=3Dtp@entry=3D0xfffff80af441ba80)
> at /space/system/usr_src/sys/netinet/tcp_subr.c:2386
> inp =3D 0xfffff80af441ba80
> so =3D 0xfffff804d23d2780
> m =3D <optimized out>
> isipv6 =3D <optimized out>
> #6 0xffffffff806d6291 in tcp_usr_detach (so=3D0xfffff804d23d2780)
> at /space/system/usr_src/sys/netinet/tcp_usrreq.c:214
> inp =3D 0xfffff80af441ba80
> tp =3D 0xfffff80af441ba80
> #7 0xffffffff805dba57 in sofree (so=3D0xfffff804d23d2780)
> at /space/system/usr_src/sys/kern/uipc_socket.c:1205
> pr =3D 0xffffffff80a8bd18 <tcp_protosw>
> #8 sorele_locked (so=3Dso@entry=3D0xfffff804d23d2780)
> at /space/system/usr_src/sys/kern/uipc_socket.c:1232
> No locals.
> #9 0xffffffff805dc8c0 in soclose (so=3D0xfffff804d23d2780)
> at /space/system/usr_src/sys/kern/uipc_socket.c:1302
> lqueue =3D {tqh_first =3D 0xfffff8068ef99740,
> tqh_last =3D 0xfffffe08a079ed40}
> error =3D 0
> saved_vnet =3D 0x0
> last =3D <optimized out>
> listening =3D <optimized out>
> #10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2dfc500, =
td=3D<unavailable>)
> at /space/system/usr_src/sys/sys/file.h:390
> No locals.
> #11 _fdrop (fp=3Dfp@entry=3D0xfffff805f2dfc500, td=3D<unavailable>,
> td@entry=3D0xfffff8068ef99740)
> at /space/system/usr_src/sys/kern/kern_descrip.c:3666
> count =3D <unavailable>
> error =3D <optimized out>
> #12 0xffffffff804d02f3 in closef (fp=3Dfp@entry=3D0xfffff805f2dfc500,
> td=3Dtd@entry=3D0xfffff8068ef99740)
> at /space/system/usr_src/sys/kern/kern_descrip.c:2839
> _error =3D 0
> _fp =3D 0xfffff805f2dfc500
> lf =3D {l_start =3D -8791759350504, l_len =3D -8791759350528, =
l_pid =3D 0,
> l_type =3D 0, l_whence =3D 0, l_sysid =3D 0}
> vp =3D <optimized out>
> fdtol =3D <optimized out>
> fdp =3D <optimized out>
> #13 0xffffffff804cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, =
fd=3D19,
> fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D<optimized =
out>)
> at /space/system/usr_src/sys/kern/kern_descrip.c:1315
> error =3D <optimized out>
> #14 closefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,=
> td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D<optimized =
out>)
> at /space/system/usr_src/sys/kern/kern_descrip.c:1372
> No locals.
> #15 0xffffffff808597d6 in syscallenter (td=3D0xfffff8068ef99740)
> at =
/space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:186
> se =3D 0xffffffff80a48330 <sysent+192>
> p =3D 0xfffffe07f29995c0
> sa =3D 0xfffff8068ef99b30
> error =3D <optimized out>
> sy_thr_static =3D <optimized out>
> traced =3D <optimized out>
> #16 amd64_syscall (td=3D0xfffff8068ef99740, traced=3D0)
> at /space/system/usr_src/sys/amd64/amd64/trap.c:1192
> ksi =3D {ksi_link =3D {tqe_next =3D 0xfffffe08a079ef30,
> tqe_prev =3D 0xffffffff808588af <trap+2351>}, ksi_info =3D =
{
> si_signo =3D 1, si_errno =3D 0, si_code =3D 2015268872, =
si_pid =3D -512,
> si_uid =3D 2398721856, si_status =3D -2042,
> si_addr =3D 0xfffffe08a079ef40, si_value =3D {sival_int =3D =
-1602621824,
> sival_ptr =3D 0xfffffe08a079ee80, sigval_int =3D =
-1602621824,
> sigval_ptr =3D 0xfffffe08a079ee80}, _reason =3D {_fault =3D=
{
> _trapno =3D 1489045984}, _timer =3D {_timerid =3D =
1489045984,
> _overrun =3D 17999}, _mesgq =3D {_mqd =3D 1489045984}, =
_poll =3D {
> _band =3D 77306605406688}, _capsicum =3D {_syscall =3D =
1489045984},
> __spare__ =3D {__spare1__ =3D 77306605406688, __spare2__ =
=3D {
> 1489814048, 17999, 208, 0, 0, 0, 992191072}}}},
> ksi_flags =3D 975329968, ksi_sigq =3D 0xffffffff8082f8f3 =
<Xinvlop+179>}
> #17 <signal handler called>
> No locals.
> #18 0x00003af13b17fc9a in ?? ()
> No symbol table info available.
> Backtrace stopped: Cannot access memory at address 0x3af13a225ab8
> ---snip---
>=20
> Any ideas?
>=20
> Due to another issue in userland, I updated to 2024-02-11-212006, but =
I have the above mentioned version and core still in a BE if needed
>=20
> Bye,
> Alexander.
From nobody Mon Feb 12 12:46:25 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 4TYPNK1ZSTz59lc9
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 12:46:41 +0000 (UTC)
(envelope-from wschnr@googlemail.com)
Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45])
(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 4TYPNJ2WHFz4hYY
for <current@freebsd.org>; Mon, 12 Feb 2024 12:46:40 +0000 (UTC)
(envelope-from wschnr@googlemail.com)
Authentication-Results: mx1.freebsd.org;
dkim=none;
dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none);
spf=pass (mx1.freebsd.org: domain of wschnr@googlemail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=wschnr@googlemail.com
Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-55f279dca99so4648713a12.3
for <current@freebsd.org>; Mon, 12 Feb 2024 04:46:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707741997; x=1708346797;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=FDK4uTihe0mLWsXf/JGJrSaCThtbs9prbFzkC5L73NA=;
b=riFndHZvykgeijG0Vu8y2+69IZDdlZ6g3rwk37/nMAtGRd9P3NIxJ/ApjYozLRzM+R
Va2Kk4F/oJEQu7cra2rDh1pIIzZ7bVL1eEZOTmTIZUDKtSJOo6nO2ALtPpV7a/J5SwIW
hFkKIaTKjPPrAopQWOXkTf5jPo0zkBY+TPWROXrqAeYLNkQDOgy3hTjMLRNruN8DduSv
0RfYCcBZb9ZvZptmsdRUsoSm5YaQ73J+xhHhh2/hAhdMwz3kOVJzdyk4m+3ZTizOLXnh
ME2Z2uJewLM9otlYBKMIC9q0EiLJKxAXTNkOB7wcyziOQu+9iqByT3VA3viHIjOs9q0F
+lfg==
X-Gm-Message-State: AOJu0YwRhJIaaKnBCAv4cRDKhsvTHvvSm6XvprEa5DNfy/ImsFFetxx2
86cns8ir66XCpk6nHGLTt515X8KS47FHH3GkdbyLKDSjvhv78UebkRt0NP2q57WowuNdcn5oz44
ogZbYg1jVNfSIe8SsP2QqIIJTo62NnfvwCRI=
X-Google-Smtp-Source: AGHT+IG1GJiLTc3YIW9a8pjjppD/YMBetv3oqxZSCe4El0GS4cVE4/xwkTfA/9gYXoOBJ8PFunFbLG2W/gfo45YWTFo=
X-Received: by 2002:a05:6402:1a41:b0:55f:c9cb:208a with SMTP id
bf1-20020a0564021a4100b0055fc9cb208amr4390904edb.35.1707741997611; Mon, 12
Feb 2024 04:46:37 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Wolfram Schneider <wosch@freebsd.org>
Date: Mon, 12 Feb 2024 13:46:25 +0100
Message-ID: <CAMWY7CCBhji24WPi28U_Mp23+ODHGF75eWXxkzdbwgLqhnkaAg@mail.gmail.com>
Subject: Kernel Panic sys/netinet/tcp_subr.c 2386
To: current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.61 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-0.999];
NEURAL_HAM_SHORT(-0.71)[-0.712];
FORGED_SENDER(0.30)[wosch@freebsd.org,wschnr@googlemail.com];
R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17];
DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none];
MIME_GOOD(-0.10)[text/plain];
RCPT_COUNT_ONE(0.00)[1];
ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
RCVD_COUNT_ONE(0.00)[1];
RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.45:from];
MISSING_XM_UA(0.00)[];
MIME_TRACE(0.00)[0:+];
TO_DOM_EQ_FROM_DOM(0.00)[];
R_DKIM_NA(0.00)[];
MLMMJ_DEST(0.00)[current@freebsd.org];
TO_DN_NONE(0.00)[];
FROM_NEQ_ENVFROM(0.00)[wosch@freebsd.org,wschnr@googlemail.com];
FROM_HAS_DN(0.00)[];
FREEMAIL_ENVFROM(0.00)[googlemail.com];
TO_MATCH_ENVRCPT_ALL(0.00)[];
RCVD_TLS_LAST(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
ARC_NA(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[209.85.208.45:from]
X-Rspamd-Queue-Id: 4TYPNJ2WHFz4hYY
Hi,
I just got a kernel panic on my 15.0-CURRENT machine, with an
Assertion in sys/netinet/tcp_subr.c 2386
full log:
https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png
OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src)
Should I worry?
-Wolfram
--
Wolfram Schneider <wosch@FreeBSD.org> https://wolfram.schneider.org
From nobody Mon Feb 12 17:32:34 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYWkF2YQ6z5BCXl;
Mon, 12 Feb 2024 17:32:37 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYWkF0gVcz4LrM;
Mon, 12 Feb 2024 17:32:37 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707759157;
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=LsyJLlg3EirIgXm1spHayzb3Tu9WXObkdrJBXLjF7dk=;
b=lvIC3N0tuOvBoWEz2v+riXovBl+OKlRVs3GRQG5jGMsx0JE1Bj2IUIJ2J7HC+I3bS6JH5s
7xXdU9Q4pEXmsUZpGrNhmkiXbV2HlASjT0FkLciwCMFNEi2+SYHfiRG5ehrmzU+K/BEo06
+ex6WhDubZdXGV8dgqyjm9/NMHAr+4z2x8mCGtpa1YdJAFm9jqxTVpFmE94NAYRf+MGTR7
gt5bMuWMQwme9dGtofa15XV15e+4t+wPmgZ1HLo/l7tpXB6EVbtHnXs86lV2RnQRQM8je4
alCPWDO/DHbu15fK92eFCDfpp4fvuhqxnbBN6DzbsZA/WhFpN3z6bx2JBuOYgw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707759157; a=rsa-sha256; cv=none;
b=IMEaPIfAHELyBe6wiyKiEM3t0uyAqly3U8HuKSv8Hl05qRIqDVMoKoWkIx+3npVEXTDVtt
p48+w+nivJHlOZ8BZ/TS5RYAoF1MpQnm/7ZbQM2VXBFnU9+b8H8HtvESmZeLmDNckASu0N
/xmdJSp2+bs9AtTYee9cEH9bqBi/NEs0enRvxJbe6UrPG1lq5ekkRAD6mHhbZcCM0N7kM/
WdHpcIuCuNnAB+tnsiMHakRwLm+sSFmq3TDo1U+XVZQVO3dgk0YWzen88pLsmtW6TtBrud
5mjJ1Wpwkre3J1933G4kDTqiJkjeBLGlh0mw+08C6k3xL/cjIWIwT8Xqe6ul1A==
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=1707759157;
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=LsyJLlg3EirIgXm1spHayzb3Tu9WXObkdrJBXLjF7dk=;
b=fz8Gxhqmjf1WxMCSwiu1XDcxZKmxN2CLXbQH4brHe1JAgfLrmxLKoY1pLC/PssnT1ObM+l
U/CAnceU20/V3lW2xBZEQARITEgtd+nbJSmPdGTG4aK7tqLwVBKkaj3LnJNZMd7YDAu46L
u0yZgAto3FD15IekoSb4ZruiUDAO2nRrBLX3pWhg1PRBTSGYf5HmR7cLEl2QtMLx6ngOMk
3xUyMexxgzSJHyTf5mIOJBlPlFOgOK/VC0luPEef681nVJORszLdyNzDAY6mmsw041iXM1
FH1hPi3wSz+1C75I1r47VZA2PfxZbBSc1voebXr4BPQhjnzY/lWKXk4B6ji6KQ==
Received: from [IPV6:2601:644:937c:5920:4c63:23c7:5c22:d7ba] (unknown [IPv6:2601:644:937c:5920:4c63:23c7:5c22:d7ba])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYWkD3XvBzTfh;
Mon, 12 Feb 2024 17:32:36 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
Date: Mon, 12 Feb 2024 09:32:34 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Cc: Warner Losh <imp@bsdimp.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/9/24 8:13 PM, Mark Millard wrote:
> Summary:
>
> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
> . . .
> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
> panic: Failed to add resource to rman
Hmmm, I suspect this is due to the way that bus_translate_resource works which is
fundamentally broken. It rewrites the start address of a resource in-situ instead
of keeping downstream resources separate from the upstream resources. For example,
I don't see how you could ever release a resource in this design without completely
screwing up your rman. That is, I expect trying to detach a PCI device behind a
translating bridge that uses the current approach should corrupt the allocated
resource ranges in an rman long before my changes.
That said, that doesn't really explain the panic. Hmm, the panic might be because
for PCI bridge windows the driver now passes RF_ACTIVE and the bus_translate_resource
hack only kicks in the activate_resource method of pci_host_generic.c.
> Detail:
>
>
> . . .
> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
This indicates this is a translating bus.
> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000
> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1
> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
> considering [0xc0000000, 0xffffffff]
> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested 0x100000)
> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
> allocating from the beginning
> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
The fact that we are trying to reserve the CPU addresses in the rman is because
bus_translate_resource rewrote the start address in the resource after it was allocated.
That said, I can't see why rman_manage_region would actually fail. At this point the
rman is empty (this is the first call to rman_manage_region for "pcib1 memory window"),
so only the check that should be failing are the checks against rm_start and
rm_end. For the memory window, rm_start is always 0, and rm_end is always
0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new (0x60000000 - 0x600fffffff)
ranges are within those bounds. I would instead expect to see some other issue later
on where we fail to allocate a resource for a child BAR, but I wouldn't expect
rman_manage_region to fail.
Logging the return value from rman_manage_region would be the first step I think
to see which error value it is returning.
Probably I should fix pci_host_generic.c to handle translation properly however.
I can work on a patch for that.
--
John Baldwin
From nobody Mon Feb 12 17:36:46 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYWq50h03z5BCjm;
Mon, 12 Feb 2024 17:36:49 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYWq509qdz4Pl4;
Mon, 12 Feb 2024 17:36:49 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707759409;
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=9pxY1kA+m6XoNdh8a1flJdAb3IyijMRAYas9FhCoImA=;
b=wtWHCesOkUtCbRIf3bB568DyLXoY9Fq6WNiQEZu/sld8NUFXwEnz4/vusvd+jdYFrdWZwp
0CWfYXqBTGIA4h6n8M7Gl9q+1CPUFncl8zlJdvsBWeYy2kFuOpBmAR4ybn9FFFLmxb6rYE
p4QzuEMtt0pkAhZ9L/nQNQNdHVB41a9zCkneDntR7E+TbE5Fs1McxB6pP49YMKgUQ2wiIG
cinwooe3oe2Z4GaSVurUFCw4A2wtZruzDWLIbfOIXXymWIQKvCFkK1CbK3HIPWMbCl/Odw
/AOaR65fEGbA9b+h6RHPec6KqRKsMkev8qteVOQuvXMxXVz5bp0yArUyX6HLQA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707759409; a=rsa-sha256; cv=none;
b=u+afM9/+JzN2QcPvF43sXq3hIMOatCQ5u/qpvcEP6e1wBG6OookvawofhwPMl6JxpLjOpM
6kO45SLWgAHeKEt46raBWMYlb3b50qWeDW+MLW09nOGVbGARJjM/DXdzVVlPOXO+jZlGea
s7+e6Fmw0Hm76fS0XGiSAZKrUTXKUYAbs/K/r8reNj+D+V26o84lnp1a0ZFKjCBi9yb7Jy
UH1vUwtX06F5Tl06Y/5LlBRWm3ASKuKwgyMl9ah8K7SM1gT7qGQ4M112SX0VVKQeZbGfOr
jqYAsPoVbMCxrSauSSZC+Ed2uMn2ENlb2pbFN9IijBZFMWW576rEB7WqNZ9nUQ==
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=1707759409;
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=9pxY1kA+m6XoNdh8a1flJdAb3IyijMRAYas9FhCoImA=;
b=JYgK58FAapPgBQnRwBPI2Yg4MVs9RgWf6wXMz6g7Jj3WEllEn7i9YpC5HvoXkNltxaKa0u
WoOV8RvCGKxcCjxv/HQ7TQ5lb0dEPN94xdvC2DSwCn27ZZLN3750CWMkntvKrNYoc4BQqB
kHm4HSMfcnmF+tkzwL9rpNp16exfdLMqWP6zPxhbLW/ZAgyArRAopu2PWB5eyjToWokQ0J
rL4Ac6gr5chBVQSRD8eNgUxc2DNH/afR/SQWRbI3mw6joJhzzfb4iYozePYVi7stt/Cl2w
VAM3IOXRY6F6xGg85ihnl3iKmypTTIAO4qrlzcSLzvHS/skfkjvSY70M+QVFJw==
Received: from [IPV6:2601:644:937c:5920:9426:11ce:b04a:f99b] (unknown [IPv6:2601:644:937c:5920:9426:11ce:b04a:f99b])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYWq422t8zTVl;
Mon, 12 Feb 2024 17:36:48 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
Date: Mon, 12 Feb 2024 09:36:46 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Michael Butler <imb@protected-networks.net>,
Mark Millard <marklmi@yahoo.com>, FreeBSD ARM List
<freebsd-arm@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org>
Cc: Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/10/24 2:09 PM, Michael Butler wrote:
> I have stability problems with anything at or after this commit
> (b377ff8) on an amd64 laptop. While I see the following panic logged, no
> crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
> (X).
>
> Reverting to 36efc64 seems to work reliably (after ACPI changes but
> before the problematic PCI one)
>
> kernel: Fatal trap 12: page fault while in kernel mode
> kernel: cpuid = 2; apic id = 02
> kernel: fault virtual address = 0x48
> kernel: fault code = supervisor read data, page not present
> kernel: instruction pointer = 0x20:0xffffffff80acb962
> kernel: stack pointer = 0x28:0xfffffe00c4318d80
> kernel: frame pointer = 0x28:0xfffffe00c4318d80
> kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
> kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
> kernel: processor eflags = interrupt enabled, resume, IOPL = 0
> kernel: current process = 2 (clock (0))
> kernel: rdi: fffff802e460c000 rsi: 0000000000000000 rdx: 0000000000000002
> kernel: rcx: 0000000000000000 r8: 000000000000001e r9: fffffe00c4319000
> kernel: rax: 0000000000000002 rbx: fffff802e460c000 rbp: fffffe00c4318d80
> kernel: r10: 0000000000001388 r11: 000000007ffc765d r12: 000f000000000000
> kernel: r13: 0002000000000000 r14: fffff8000193e740 r15: 0000000000000000
> kernel: trap number = 12
> kernel: panic: page fault
> kernel: cpuid = 2
> kernel: time = 1707573802
> kernel: Uptime: 6m19s
> kernel: Dumping 942 out of 16242
> MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..92%
> kernel: Dump complete
> kernel: Automatic reboot in 15 seconds - press a key on the console to abort
Without a stack trace it is pretty much impossible to debug a panic like this.
Do you have KDB_TRACE enabled in your kernel config? I'm also not sure how the
PCI changes can result in a panic post-boot. If you were going to have problems
they would be during device attach, not after you are booted and running X.
Short of a stack trace, you can at least use lldb or gdb to lookup the source
line associated with the faulting instruction pointer (as long as it isn't in
a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' and then
'l *<instruction pointer address>', e.g. from above: 'l *0xffffffff80acb962'
--
John Baldwin
From nobody Mon Feb 12 17:45:27 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 4TYX1D1XrWz5BDlC;
Mon, 12 Feb 2024 17:45:36 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8])
(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.protected-networks.net", Issuer "R3" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYX1C6ZB6z4WvB;
Mon, 12 Feb 2024 17:45:35 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Authentication-Results: mx1.freebsd.org;
none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
protected-networks.net; h=content-transfer-encoding:content-type
:content-type:in-reply-to:from:from:content-language:references
:subject:subject:user-agent:mime-version:date:date:message-id;
s=201508; t=1707759928; bh=NDeTl7pk6+Z1BEM+tQOohzw3kDNFsnUqJhMg
OFayl3A=; b=i+TXyAalo7udPf14NYGCPhDhMH0R6ctY9mCD3uGQJi6CuYZSP/Lz
eOlLm1Td4a6SzGFDaf44QXc7l1PFdBYT1ufaqn9fhSECqvKfC1eGp/JKfjIYrZEf
fBZPHRKSuVyNio95PAiS4WurM5LC6q5Zd5naQCfrJ35cbvpl7RfTKv4=
Received: from [IPV6:2600:4040:53d9:8200:f21f:afff:fe66:957e] (unknown [IPv6:2600:4040:53d9:8200:f21f:afff:fe66:957e])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
(Authenticated sender: imb@mail.protected-networks.net)
by mail.protected-networks.net (Postfix) with ESMTPSA id 8B64E394F0;
Mon, 12 Feb 2024 12:45:28 -0500 (EST)
Message-ID: <c151f7f9-4251-48ea-9d51-80d4497a8c3c@protected-networks.net>
Date: Mon, 12 Feb 2024 12:45:27 -0500
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
To: John Baldwin <jhb@FreeBSD.org>, Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Cc: Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
<b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
Content-Language: en-NZ
From: Michael Butler <imb@protected-networks.net>
Autocrypt: addr=imb@protected-networks.net; keydata=
xsDiBETHZAURBACJicNaIbVVVZahtQcdJeogtTLjCYAdj4kFMpy6Y3Ac19UNWDM+TrD4yFPi
5nc/pp9M/5Q4RNBr6a97fTYroTaq+vDwWdklOHwD2ZXs7FqwWOtVSIPT/rev5fUvwEF2VFYE
sNDbpE5HHpP/oFUw5scEJZVyOBJSGvYb1IhV55NWswCgzkUGbG8A3s+oZXkHqTCYGW/seukD
+wTo/L835xLpbTJxoxEKeGA3aWifSsRvpWWHyXye6sTkSN3SmtE9A8Pqmdb1dBEO0eOms6GD
RamvCFgdvg2HesAv9l7L/7Mm9iKJs6uTAa+taIQslpumGh4PRc94IepVFzAa4Ef/FA4mWx9w
P/EqNsKUPE2U5HI1decbopkxH/d/A/9Hupc10lPsXVMACd54/YZRsSTTcArheekm8qE/f8Hl
1Q7At+yuFgfMll4QPAhefnrLUanXF1bWtxG5PmaJktDYp3HOmy43giZgacgt+a3TVd6vu8Gs
DnI4FOfYllq7mZFezMIulCWUYtnkMEXEeyzp39dygi7blPIjckWlQ2sc380rTWljaGFlbCBC
dXRsZXIgPGltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0PsJgBBMRAgAgBQJEx2QFAhsDBgsJ
CAcDAgQVAggDBBYCAwECHgECF4AACgkQQv9rrgRC1JL7mgCdEnPeo22kqT/bES+D78QSGhNR
r8cAn2xOMeu6pBrc2tDY8Ky/70HBctmjzsFNBETHZA4QCACKbm/PMn4QcyDEvIn4MF+t2E1A
zgiBAkPCMtWT1CcqeUj13OwNM8qJD/mBWjCZCnr1hKVbvzOmgKaM4uDCWIcSCdoDTJx1DqMx
abr+EpHz1fL6aagEOKHz5sCYOkDXt3zzZ/5RBMdkEJwunXYtAbu5e68oty+d0DFzAM3pBp6l
GC0TE3VutmFR/KK66rf0KB83YQBf/IAtyqsRIQPP9t0SLfJ+kqKXf73nvAUFEtb21gZSzhTm
QP87QKyQvenE8o4PQ2tEslq2jICB7pGcqIrwP4o3Hl4V+HXi3lA26MMJ5rakQB2sKKWroPVQ
BiRXO+W8Qf+0oQFq38oMXR5sPOs/AAMFB/sEKcjzvkwviZOsDElthxtgrmqUNKC9G/4Fw0tK
k6fMynv+bcKz85k2uWOIfefUKBFoQ0SCphU4jquJENqqy6BPTkXePlIJok2/GkF7xtHm2FPq
tTTuYmoBrGsls28Z9dn2LcBwFHz59SSWM9JFPIvFr9HCkKtp6zPUsJd5b02+0wgzDubTMQS9
M2LwGSh9xK6xl4MGgngl22b0TZDh5qHwmsywOX6SbGsQfeNpkptJ4gPjShypusFyF+pevnCM
wTfUPCBd/AFbu2fHFQjA8sgkr5IqXuc4PoiIBXc9upoFpDqGkYssAKbzGcRsK94a8hRROJV9
bzPyYempIWaPXr2EwkkEGBECAAkFAkTHZA4CGwwACgkQQv9rrgRC1JKqhwCeOov6gTo8eWte
es3gbLr2n2b5AXMAoItSlajet574lkouzY3u3scSRfiE
In-Reply-To: <b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: 4TYX1C6ZB6z4WvB
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On 2/12/24 12:36, John Baldwin wrote:
> On 2/10/24 2:09 PM, Michael Butler wrote:
>> I have stability problems with anything at or after this commit
>> (b377ff8) on an amd64 laptop. While I see the following panic logged, no
>> crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
>> (X).
>>
>> Reverting to 36efc64 seems to work reliably (after ACPI changes but
>> before the problematic PCI one)
>>
>> kernel: Fatal trap 12: page fault while in kernel mode
>> kernel: cpuid = 2; apic id = 02
>> kernel: fault virtual address    = 0x48
>> kernel: fault code               = supervisor read data, page not
>> present
>> kernel: instruction pointer      = 0x20:0xffffffff80acb962
>> kernel: stack pointer            = 0x28:0xfffffe00c4318d80
>> kernel: frame pointer            = 0x28:0xfffffe00c4318d80
>> kernel: code segment             = base 0x0, limit 0xfffff, type 0x1b
>> kernel:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = DPL 0, pres 1, long 1, def32 0, gran 1
>> kernel: processor eflags = interrupt enabled, resume, IOPL = 0
>> kernel: current process          = 2 (clock (0))
>> kernel: rdi: fffff802e460c000 rsi: 0000000000000000 rdx: 0000000000000002
>> kernel: rcx: 0000000000000000 r8: 000000000000001e r9: fffffe00c4319000
>> kernel: rax: 0000000000000002 rbx: fffff802e460c000 rbp: fffffe00c4318d80
>> kernel: r10: 0000000000001388 r11: 000000007ffc765d r12: 000f000000000000
>> kernel: r13: 0002000000000000 r14: fffff8000193e740 r15: 0000000000000000
>> kernel: trap number              = 12
>> kernel: panic: page fault
>> kernel: cpuid = 2
>> kernel: time = 1707573802
>> kernel: Uptime: 6m19s
>> kernel: Dumping 942 out of 16242
>> MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..92%
>> kernel: Dump complete
>> kernel: Automatic reboot in 15 seconds - press a key on the console to
>> abort
>
> Without a stack trace it is pretty much impossible to debug a panic like
> this.
> Do you have KDB_TRACE enabled in your kernel config? I'm also not sure
> how the
> PCI changes can result in a panic post-boot. If you were going to have
> problems
> they would be during device attach, not after you are booted and running X.
>
> Short of a stack trace, you can at least use lldb or gdb to lookup the
> source
> line associated with the faulting instruction pointer (as long as it
> isn't in
> a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel'
> and then
> 'l *<instruction pointer address>', e.g. from above: 'l
> *0xffffffff80acb962'
I suspect the absence of a core dump was due to my use of tmpfs for /tmp
and /var/tmp while still having clear_tmp enabled in rc.conf (that may
touch swap on restart).
Since then, I've removed tmpfs, everything under /usr/obj am rebuilding
from scratch. I'll update when it finally finishes (i5-3340s are quick :-()
Michael
From nobody Mon Feb 12 18:02:41 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 4TYXTs5ndHz5BGhB;
Mon, 12 Feb 2024 18:06:57 +0000 (UTC)
(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYXTs19T5z4bTQ;
Mon, 12 Feb 2024 18:06:57 +0000 (UTC)
(envelope-from warlock@phouka1.phouka.net)
Authentication-Results: mx1.freebsd.org;
none
Received: from phouka1.phouka.net (localhost [127.0.0.1])
by phouka1.phouka.net (8.17.1/8.17.1) with ESMTPS id 41CI2fWC028945
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
Mon, 12 Feb 2024 10:02:41 -0800 (PST)
(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
by phouka1.phouka.net (8.17.1/8.17.1/Submit) id 41CI2fTM028944;
Mon, 12 Feb 2024 10:02:41 -0800 (PST)
(envelope-from warlock)
Date: Mon, 12 Feb 2024 10:02:41 -0800
From: John Kennedy <warlock@phouka.net>
To: John Baldwin <jhb@freebsd.org>
Cc: Michael Butler <imb@protected-networks.net>,
Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org>
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Message-ID: <ZcpdQQwxQ1Nplg7_@phouka1.phouka.net>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
<b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]
X-Rspamd-Queue-Id: 4TYXTs19T5z4bTQ
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Mon, Feb 12, 2024 at 09:36:46AM -0800, John Baldwin wrote:
> Without a stack trace it is pretty much impossible to debug a panic like this.
> Do you have KDB_TRACE enabled in your kernel config? I'm also not sure how the
> PCI changes can result in a panic post-boot. If you were going to have problems
> they would be during device attach, not after you are booted and running X.
>
> Short of a stack trace, you can at least use lldb or gdb to lookup the source
> line associated with the faulting instruction pointer (as long as it isn't in
> a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' and then
> 'l *<instruction pointer address>', e.g. from above: 'l *0xffffffff80acb962'
I know on my RPI4 where I saw that, my USB keyboard was dead at that point
and I couldn't get a trace or continue along to get the crashdump.
From nobody Mon Feb 12 18:41:55 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 4TYYGZ0DKdz5BL85
for <freebsd-current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 18:42:14 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYYGY1WTtz4hGC
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 18:42:12 +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=1707763330; bh=Yd2DIrIA/QSXA+wsPbV5dwmQIQlse/+QachCcoyatx0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ouwnnp41isMVep5LIW9Zs+OCheOFdya+RRdq/6Ey7ByFhyhy6T3ycVf432kq2qUQ7AOh0gvebrEHCgEcZDjUOrsRj9ANxd/lM7m7Wp0MejTLNYHKc0smtH/1nMC2pAHAzV65e/zw/qxVGNcVDAUCn30F159MasIWs/DfFBSgVr4kFckGueg/bw4lzBgHTkxbznXovVPtAMgVCfN8m2Hi9yOXUQrQ5XANJyEmlF1DTWuCOymcW0XKVlnkPyKXgWy99EmXkDtc+n4OclvWEYIjwutZ2eHPupUPvLf7HfGqlB1XdUdcujXubzXG9WbiXWOfn7EcVYg4BNDymOkA4YvgfQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707763330; bh=kcG0vqm6PtEPB3dGxBQwRKT0umVjSv1YuBoAdKAX5p0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TnTytltks55wRUSUMhYOBwTMZz/Xn0ZZi4LvcsftYEfOWjxf43GHBvZLP++Tz1l/rFgdFjbPRlbzsjPXsv8yP1iVqEfr2T8opJWyciG/T2wg+xNut/qh46qUubajM0IQQ1V8Zt5aGPgfdwvv/3zyErs2KUtVcvH0TLbsTGj4j8an4q+Eba+DT8Zew3uCbCJqerSlc/BHLf067hz9QgzPLzFLDIyBKSzEpLTLRfCdh7ulF0KFcabnKX6nYrCuUlGi2uzg1NJjbI0oIZnaHGNuzeMsF9lyJ86lEUSaJD16qA7b8Qb8wT8QWV0w+W5lFphxrEGDao0KkmLR/mFlatbSeA==
X-YMail-OSG: 50VU.9AVM1mhymbfJuxht2FXtzGb7OcxH53SHdpUffCyG9hh_5vLO.LYTHofVy.
MrecZNVJo9Cr.im8JE0BD3SrEMc271mJvp9EZ_Hx8RY7WpDkp_Ab.Je9.Bk2wsJ.Uidfy4KuonIT
jsLVW998urMrV8MSVFD.sxk34wvU1RYMHCfT8C7BvnPXwUp61UoOxv3ld5T9K6E7eJn8CKFhX19.
zV8MTZk29QazdhH5Hh17IfYs1WuVnTwERfUD1bYFnI581we0aIX632IR1ZEMga9DrHxLysK1CVT_
MYZIn5AnolY1TNJ8GrM11fHlv2c2RtgVj.q_vZ0Nm2VMK416Rdq8VpfgyKQD6eFj_vxdlx0RRmr1
OxphENkPCphELkQvTTvBMo34nRZieWtVyBjlGSbRepBYZ5RfipfockEo_wVWa3NjWaHghkhdkT1x
I4d0UWOFd7nxLuh0BXhelKnI39hrdTCIMBuvexlfJRZnJUzA1anmHOXc2j3rwfrLYfVjUYr9bBCc
QeNYop9XJAoFZ.E1gW5x6TPaTNg9PNMdYsEkhXyUlIgAJ61ckq4hFTngjUaPTBbyT9v9T0XVKcOG
HUgokDaNhy8pXofU5am2ycBGN1WPpnVGVDfLTWbahj2_s3faDPAoTjgTHl7mSA2XJBnksfAsmBW9
aHj3LMID0KCCYgDsdKEEF_3rFaeugHL1D.AWP1sNcfI6mUXpYKSa1ByVZEoYoeMAwrot1tOLrNsN
ry0p.xU6fJnFpRN16RL4nTA_ElQsL8d9OL2UpG.LQ6mstz8thjwtW6q.Ls4XufxFXhlteKQlFqWV
CrNv0WOj5gQdKbuVhdX4laCmf1UKiUS79YHE_HW9YCJfHpWOLSur2Pg6M0Grhz5vqPowpZLLHc0Z
8Xl8cHTUggN_u22mrcxf9BpulZv.kxCY89njWEieFRDOwt_79Jy1Kvz1M7Yzg1vVkaeQFUazVUIQ
EsGom6AhSCVNemgLozTgWwtRc07A0094TPTu_FZxY7Ffavd5pMR213o5bIRiaWgvdhzhPOn7P3s.
89qyqF0bCCe_WPpaxhgva5gDrM_2zeWbF6AzMRUNTOVLX3tB.FKrvJw9FNAmdtp9cr4cdVsBDz4P
zTWyTPvtLjR0b_WS9qnGV4LFchVYQa7qS.EikI7RgM474XeO6kMNvS2SLoa0uLdfb0Ytb0CIeSXc
cxqCBQLKBLNxdsfsmWEe.C.cTzjdaFpsRgOEqQmBqLUAO_GlllnxIHxsxDmmerb8CnZLAUD_Dewp
SeSp9oAuzkc7abeNCeHW2htdl95Wv6wlxIUfD35wKFjaX56GHjKpvnsl.8S8UQz8o.1G9ddDVc8P
dZrAgQcQgzxY.sQ729tbOHlQ0FgzpRj3I98ASqSFiqpMvx0rigA4NIsAlMACaIwdhc2iAoHuZ2Hk
z5LDh9KRrK1NEayOgV.c1QcqOeYFT9rz_Nwl8TFYQ56Q84PUiz9I9NauUVTSFl31kamtO0rkhpBy
8c3StunSeibwMIkqVikD5Zqi1ZpOYf_uQuleKYCh.zsixNnuZIXZipmGORs8LEd9Jn89ngBcnvZN
y82njc6OEatuVFx5tlDrlM0kvvK0p9JCtKWXEUci.Gaw.V1RDMuoUV1LL_ZVL3I2aHDtZBJrjbUy
_K6hPykkXUl4Uglpek1HXwh_SdJ0k.Tb.XO12gu0dc_HtBmBP1YYatT2Meyka2HdvTBKj6gjbVfG
Qao8jWjHHI.tGsl9fXR7fv4eRzTpfCyUHcGtsnObiMgCHeRw8W_O1fRB2_hVD2._udyTwEvFWRWF
WEB_7nPAMMBn5ZDcE1E76F0Uq8.684aYAy7f4GGvmDQBY46Eh4OH4zLfyIobY1en96cnARqRuKdE
H0FaTjtjnTV46NiGk5DjlMNsnrRMYe3YqJyDdAKP5FwZaR8XRJaia3ViXxczwesQZWlnWtSmIA1O
AcNTitZressfYLH54CRyxXd35rcNLBSs9tLfLM54yiLXfBrqnvuhsqqT8rZmAvB.iCgrFXTEQ2Vu
vvOyVkZ8nYM5CBwFipje28FrDP797YdOPUIBpklkXRKRlRwpYYcrWGSHcCbkU3iHyBBE0WD7t63j
vCS_nYPDhc2NtOeiden.05hvCQoiaFNTTWRDZ2.w9wS7Sgul1Pno2a_QjA0h8snxPM2c1zoS.yxw
StUxXeIX88Bv3XT5nmgtIqgt0651QYmXeN5Em6yOmvA_gv9vYpyBDB.MsU3MvRlYrylFEQq3E0iw
qh3cceHENqnV6u6nWRPj8XJnrQegdYrRxd.Iw8Z_.EeS.3THCYY8VskanlUboJYo56DUb8edH_Sk
-
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 6b369b64-70c3-40aa-b0af-62fa45efb13c
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Feb 2024 18:42:10 +0000
Received: by hermes--production-gq1-5c57879fdf-27p5r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 040bb44139625531b00f5b5a08bc626a;
Mon, 12 Feb 2024 18:42:06 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
Date: Mon, 12 Feb 2024 10:41:55 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
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: 4TYYGY1WTtz4hGC
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
> On 2/9/24 8:13 PM, Mark Millard wrote:
>> Summary:
>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>> pcib0: parsing FDT for ECAM0:
>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>> . . .
>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, =
end 0x6000fffff
>> panic: Failed to add resource to rman
>=20
> Hmmm, I suspect this is due to the way that bus_translate_resource =
works which is
> fundamentally broken. It rewrites the start address of a resource =
in-situ instead
> of keeping downstream resources separate from the upstream resources. =
For example,
> I don't see how you could ever release a resource in this design =
without completely
> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
> translating bridge that uses the current approach should corrupt the =
allocated
> resource ranges in an rman long before my changes.
>=20
> That said, that doesn't really explain the panic. Hmm, the panic =
might be because
> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
> hack only kicks in the activate_resource method of pci_host_generic.c.
>=20
>> Detail:
>> . . .
>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>> pcib0: parsing FDT for ECAM0:
>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>=20
> This indicates this is a translating bus.
>=20
>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>> considering [0xc0000000, 0xffffffff]
>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested =
0x100000)
>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>> allocating from the beginning
>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, =
end 0x6000fffff
>=20
> The fact that we are trying to reserve the CPU addresses in the rman =
is because
> bus_translate_resource rewrote the start address in the resource after =
it was allocated.
>=20
> That said, I can't see why rman_manage_region would actually fail. At =
this point the
> rman is empty (this is the first call to rman_manage_region for "pcib1 =
memory window"),
> so only the check that should be failing are the checks against =
rm_start and
> rm_end. For the memory window, rm_start is always 0, and rm_end is =
always
> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
> ranges are within those bounds. I would instead expect to see some =
other issue later
> on where we fail to allocate a resource for a child BAR, but I =
wouldn't expect
> rman_manage_region to fail.
>=20
> Logging the return value from rman_manage_region would be the first =
step I think
> to see which error value it is returning.
Looking at the code in sys/kern/subr_rman.c for rman_manage_region I see
the (mostly) return rv related logic only has ENONMEM (explicit return) =
and
EBUSY as non-0 possibilities (no other returns). All the rv references =
and
all the returns are shown below:
int rv =3D 0;
. . .
r =3D int_alloc_resource(M_NOWAIT);
if (r =3D=3D NULL)
return ENOMEM;
. . .
/* Check for any overlap with the current region. */
if (r->r_start <=3D s->r_end && r->r_end >=3D =
s->r_start) {
rv =3D EBUSY;
goto out;
}
/* Check for any overlap with the next region. */
t =3D TAILQ_NEXT(s, r_link);
if (t && r->r_start <=3D t->r_end && r->r_end >=3D =
t->r_start) {
rv =3D EBUSY;
goto out;
}
. . .
out:
mtx_unlock(rm->rm_mtx);
return rv;
int_alloc_resource failure would be failure (NULL) from the:
struct resource_i *r;
=20
r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO);
(associated with the M_NOWAIT argument).
The malloc failure would likely go in a very different direction.
Side note: looks like the EBUSY cases leak what r references.
> Probably I should fix pci_host_generic.c to handle translation =
properly however.
> I can work on a patch for that.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Mon Feb 12 18:44:36 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 4TYYKL4zp0z5BLBN;
Mon, 12 Feb 2024 18:44:38 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8])
(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.protected-networks.net", Issuer "R3" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYYKL1MHQz4kSQ;
Mon, 12 Feb 2024 18:44:38 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Authentication-Results: mx1.freebsd.org;
none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
protected-networks.net; h=content-transfer-encoding:content-type
:content-type:in-reply-to:from:from:content-language:references
:subject:subject:user-agent:mime-version:date:date:message-id;
s=201508; t=1707763477; bh=xc2kJFck7CC9gYBzGmPQVjxLP0z4/g49d1jr
GwIKpF4=; b=d6DotjePFPj+OD1itaXouZoEcyZhRjNbJALFcymWgKNzN9GgWiqf
pdP8n5JqdnM0TP3+YmQzTj0QNkbKibWWHglSG27de2u3XTmI2BlKZx3Ly9NWMc2J
u7j8MDjmKCcfiSwn9S7Ro2y3llX5XgMUXOFiePgzZU+5+IBnwO9GN30=
Received: from [IPV6:2600:4040:53d9:8200:f21f:afff:fe66:957e] (unknown [IPv6:2600:4040:53d9:8200:f21f:afff:fe66:957e])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
(Authenticated sender: imb@mail.protected-networks.net)
by mail.protected-networks.net (Postfix) with ESMTPSA id 1E4A13BCD8;
Mon, 12 Feb 2024 13:44:37 -0500 (EST)
Message-ID: <0b289f85-152b-45b2-a81e-ff34e398c964@protected-networks.net>
Date: Mon, 12 Feb 2024 13:44:36 -0500
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
To: John Baldwin <jhb@FreeBSD.org>, Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Cc: Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
<b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
Content-Language: en-NZ
From: Michael Butler <imb@protected-networks.net>
Autocrypt: addr=imb@protected-networks.net; keydata=
xsDiBETHZAURBACJicNaIbVVVZahtQcdJeogtTLjCYAdj4kFMpy6Y3Ac19UNWDM+TrD4yFPi
5nc/pp9M/5Q4RNBr6a97fTYroTaq+vDwWdklOHwD2ZXs7FqwWOtVSIPT/rev5fUvwEF2VFYE
sNDbpE5HHpP/oFUw5scEJZVyOBJSGvYb1IhV55NWswCgzkUGbG8A3s+oZXkHqTCYGW/seukD
+wTo/L835xLpbTJxoxEKeGA3aWifSsRvpWWHyXye6sTkSN3SmtE9A8Pqmdb1dBEO0eOms6GD
RamvCFgdvg2HesAv9l7L/7Mm9iKJs6uTAa+taIQslpumGh4PRc94IepVFzAa4Ef/FA4mWx9w
P/EqNsKUPE2U5HI1decbopkxH/d/A/9Hupc10lPsXVMACd54/YZRsSTTcArheekm8qE/f8Hl
1Q7At+yuFgfMll4QPAhefnrLUanXF1bWtxG5PmaJktDYp3HOmy43giZgacgt+a3TVd6vu8Gs
DnI4FOfYllq7mZFezMIulCWUYtnkMEXEeyzp39dygi7blPIjckWlQ2sc380rTWljaGFlbCBC
dXRsZXIgPGltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0PsJgBBMRAgAgBQJEx2QFAhsDBgsJ
CAcDAgQVAggDBBYCAwECHgECF4AACgkQQv9rrgRC1JL7mgCdEnPeo22kqT/bES+D78QSGhNR
r8cAn2xOMeu6pBrc2tDY8Ky/70HBctmjzsFNBETHZA4QCACKbm/PMn4QcyDEvIn4MF+t2E1A
zgiBAkPCMtWT1CcqeUj13OwNM8qJD/mBWjCZCnr1hKVbvzOmgKaM4uDCWIcSCdoDTJx1DqMx
abr+EpHz1fL6aagEOKHz5sCYOkDXt3zzZ/5RBMdkEJwunXYtAbu5e68oty+d0DFzAM3pBp6l
GC0TE3VutmFR/KK66rf0KB83YQBf/IAtyqsRIQPP9t0SLfJ+kqKXf73nvAUFEtb21gZSzhTm
QP87QKyQvenE8o4PQ2tEslq2jICB7pGcqIrwP4o3Hl4V+HXi3lA26MMJ5rakQB2sKKWroPVQ
BiRXO+W8Qf+0oQFq38oMXR5sPOs/AAMFB/sEKcjzvkwviZOsDElthxtgrmqUNKC9G/4Fw0tK
k6fMynv+bcKz85k2uWOIfefUKBFoQ0SCphU4jquJENqqy6BPTkXePlIJok2/GkF7xtHm2FPq
tTTuYmoBrGsls28Z9dn2LcBwFHz59SSWM9JFPIvFr9HCkKtp6zPUsJd5b02+0wgzDubTMQS9
M2LwGSh9xK6xl4MGgngl22b0TZDh5qHwmsywOX6SbGsQfeNpkptJ4gPjShypusFyF+pevnCM
wTfUPCBd/AFbu2fHFQjA8sgkr5IqXuc4PoiIBXc9upoFpDqGkYssAKbzGcRsK94a8hRROJV9
bzPyYempIWaPXr2EwkkEGBECAAkFAkTHZA4CGwwACgkQQv9rrgRC1JKqhwCeOov6gTo8eWte
es3gbLr2n2b5AXMAoItSlajet574lkouzY3u3scSRfiE
In-Reply-To: <b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: 4TYYKL1MHQz4kSQ
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
> Short of a stack trace, you can at least use lldb or gdb to lookup
> the source line associated with the faulting instruction pointer (as
> long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
> /boot/kernel/kernel' and then 'l *<instruction pointer address>',
> e.g. from above: 'l *0xffffffff80acb962'
I still didn't manage to get a core but .. does this make any sense in
htis context?
(kgdb) l *0xffffffff80acb962
0xffffffff80acb962 is in cc_conn_init
(/usr/src/sys/amd64/include/counter.h:92).
87 static inline void
88 counter_u64_add(counter_u64_t c, int64_t inc)
89 {
90
91 KASSERT(IS_BSP() || c != EARLY_COUNTER, ("EARLY_COUNTER
used on AP"));
92 zpcpu_add(c, inc);
93 }
94
95 #endif /* ! __MACHINE_COUNTER_H__ */
96
Michael
From nobody Mon Feb 12 19:30:44 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 4TYZLZ62zDz5BQqQ
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 19:30:46 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "Client", Issuer "CA" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYZLZ4xz1z4vj8;
Mon, 12 Feb 2024 19:30:46 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Authentication-Results: mx1.freebsd.org;
none
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
by cmsmtp with ESMTPS
id ZZSorkjxuxDxGZc0srnVoS; Mon, 12 Feb 2024 19:30:46 +0000
Received: from spqr.komquats.com ([70.66.152.170])
by cmsmtp with ESMTPSA
id Zc0rrCZ9FZ0jDZc0rr3vLQ; Mon, 12 Feb 2024 19:30:46 +0000
X-Authority-Analysis: v=2.4 cv=P8GZhTAu c=1 sm=1 tr=0 ts=65ca71e6
a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17
a=kj9zAlcOel0A:10 a=k7vzHIieQBIA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8
a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=5X-dCmgiurBNT7On90IA:9 a=CjuIK1q_8ugA:10
a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
by spqr.komquats.com (Postfix) with ESMTP id EAD46B5;
Mon, 12 Feb 2024 11:30:44 -0800 (PST)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
id E089D185; Mon, 12 Feb 2024 11:30:44 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev
Reply-to: Cy Schubert <Cy.Schubert@cschubert.com>
From: Cy Schubert <Cy.Schubert@cschubert.com>
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: tuexen@freebsd.org
cc: Alexander Leidinger <alexleidingerde@gmail.com>, current@freebsd.org
Subject: Re: kernel crash in tcp_subr.c:2386
In-reply-to: <625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>
References: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org>
<CAJg7qzH_c8JCKQvLPki6Cv7GRzaQs9vA-omSWBxnFTPy_9Rczw@mail.gmail.com>
<625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>
Comments: In-reply-to tuexen@freebsd.org
message dated "Mon, 12 Feb 2024 11:23:54 +0100."
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Feb 2024 11:30:44 -0800
Message-Id: <20240212193044.E089D185@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfFWKmf6syDprgDaxB4zGD7Tz9Y/5Upfu+EwMxV/5Yybo1aN2rUrjvraD6mynpePEaK1uNkJ/8h5h25aUWpyOWIcgVw3SMnXn81cKpu44qxAJ+ycOlXh+
ABK61Uaw4u4mQbZj8R9zbOUjg0ufa6aq2IMkOr2xzZg4Db74Ch07kGTPq70bq3V/Ija2cr11P+xA7+JK0hKpjjAMVJPkQAi8Vjrb5RuQ6ERfvTwWPOpU0V6p
DXDlA1MFicJGLSw8rIQuwmSUnMIWOk6judbV/APYZxM=
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]
X-Rspamd-Queue-Id: 4TYZLZ4xz1z4vj8
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
In message <625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>,
tuexen@freebsd.o
rg writes:
> > On Feb 12, 2024, at 10:36, Alexander Leidinger =
> <alexleidingerde@gmail.com> wrote:
> >=20
> > Hi,
> >=20
> > I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
> Hi Alexander,
>
> we are aware of this problem, but haven't found a way to reproduce it.
> Do you know how to reproduce this?
I've reproduced this by rebooting any one of my machines in my basement.
The other machines will panic as below.
I've reverted the three tcp timer commits, expecting one of them to be the
cause.
>
> Best regards
> Michael
> > ---snip---
> > __curthread () at =
> /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
> > 57 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" =
> (offsetof(struct pcpu,
> > (kgdb) #0 __curthread () at =
> /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
> > td =3D <optimized out>
> > #1 doadump (textdump=3Dtextdump@entry=3D1)
> > at /space/system/usr_src/sys/kern/kern_shutdown.c:403
> > error =3D 0
> > coredump =3D <optimized out>
> > #2 0xffffffff8052fe85 in kern_reboot (howto=3D260)
> > at /space/system/usr_src/sys/kern/kern_shutdown.c:521
> > once =3D 0
> > __pc =3D <optimized out>
> > #3 0xffffffff80530382 in vpanic (
> > fmt=3D0xffffffff808df476 "Assertion %s failed at %s:%d",
> > ap=3Dap@entry=3D0xfffffe08a079ebf0)
> > at /space/system/usr_src/sys/kern/kern_shutdownc:973
> > buf =3D "Assertion !callout_active(&tp->t_callout) failed at =
> /space/system/usr_src/sys/netinet/tcp_subr.c:2386", '\000' <repeats 154 =
> times>
> > __pc =3D <optimized out>
> > __pc =3D <optimized out>
> > __pc =3D <optimized out>
> > other_cpus =3D {__bits =3D {14680063, 0 <repeats 15 times>}}
> > td =3D 0xfffff8068ef99740
> > bootopt =3D <unavailable>
> > newpanic =3D <optimized out>
> > #4 0xffffffff805301d3 in panic (fmt=3D<unavailable>)
> > at /space/system/usr_src/sys/kern/kern_shutdown.c:889
> > ap =3D {{gp_offset =3D 32, fp_offset =3D 48,
> > overflow_arg_area =3D 0xfffffe08a079ec20,
> > reg_save_area =3D 0xfffffe08a079ebc0}}
> > #5 0xffffffff806c9d8c in tcp_discardcb =
> (tp=3Dtp@entry=3D0xfffff80af441ba80)
> > at /space/system/usr_src/sys/netinet/tcp_subr.c:2386
> > inp =3D 0xfffff80af441ba80
> > so =3D 0xfffff804d23d2780
> > m =3D <optimized out>
> > isipv6 =3D <optimized out>
> > #6 0xffffffff806d6291 in tcp_usr_detach (so=3D0xfffff804d23d2780)
> > at /space/system/usr_src/sys/netinet/tcp_usrreq.c:214
> > inp =3D 0xfffff80af441ba80
> > tp =3D 0xfffff80af441ba80
> > #7 0xffffffff805dba57 in sofree (so=3D0xfffff804d23d2780)
> > at /space/system/usr_src/sys/kern/uipc_socket.c:1205
> > pr =3D 0xffffffff80a8bd18 <tcp_protosw>
> > #8 sorele_locked (so=3Dso@entry=3D0xfffff804d23d2780)
> > at /space/system/usr_src/sys/kern/uipc_socket.c:1232
> > No locals.
> > #9 0xffffffff805dc8c0 in soclose (so=3D0xfffff804d23d2780)
> > at /space/system/usr_src/sys/kern/uipc_socket.c:1302
> > lqueue =3D {tqh_first =3D 0xfffff8068ef99740,
> > tqh_last =3D 0xfffffe08a079ed40}
> > error =3D 0
> > saved_vnet =3D 0x0
> > last =3D <optimized out>
> > listening =3D <optimized out>
> > #10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2dfc500, =
> td=3D<unavailable>)
> > at /space/system/usr_src/sys/sys/file.h:390
> > No locals.
> > #11 _fdrop (fp=3Dfp@entry=3D0xfffff805f2dfc500, td=3D<unavailable>,
> > td@entry=3D0xfffff8068ef99740)
> > at /space/system/usr_src/sys/kern/kern_descrip.c:3666
> > count =3D <unavailable>
> > error =3D <optimized out>
> > #12 0xffffffff804d02f3 in closef (fp=3Dfp@entry=3D0xfffff805f2dfc500,
> > td=3Dtd@entry=3D0xfffff8068ef99740)
> > at /space/system/usr_src/sys/kern/kern_descrip.c:2839
> > _error =3D 0
> > _fp =3D 0xfffff805f2dfc500
> > lf =3D {l_start =3D -8791759350504, l_len =3D -8791759350528, =
> l_pid =3D 0,
> > l_type =3D 0, l_whence =3D 0, l_sysid =3D 0}
> > vp =3D <optimized out>
> > fdtol =3D <optimized out>
> > fdp =3D <optimized out>
> > #13 0xffffffff804cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, =
> fd=3D19,
> > fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D<optimized =
> out>)
> > at /space/system/usr_src/sys/kern/kern_descrip.c:1315
> > error =3D <optimized out>
> > #14 closefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,=
>
> > td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D<optimized =
> out>)
> > at /space/system/usr_src/sys/kern/kern_descrip.c:1372
> > No locals.
> > #15 0xffffffff808597d6 in syscallenter (td=3D0xfffff8068ef99740)
> > at =
> /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:186
> > se =3D 0xffffffff80a48330 <sysent+192>
> > p =3D 0xfffffe07f29995c0
> > sa =3D 0xfffff8068ef99b30
> > error =3D <optimized out>
> > sy_thr_static =3D <optimized out>
> > traced =3D <optimized out>
> > #16 amd64_syscall (td=3D0xfffff8068ef99740, traced=3D0)
> > at /space/system/usr_src/sys/amd64/amd64/trap.c:1192
> > ksi =3D {ksi_link =3D {tqe_next =3D 0xfffffe08a079ef30,
> > tqe_prev =3D 0xffffffff808588af <trap+2351>}, ksi_info =3D =
> {
> > si_signo =3D 1, si_errno =3D 0, si_code =3D 2015268872, =
> si_pid =3D -512,
> > si_uid =3D 2398721856, si_status =3D -2042,
> > si_addr =3D 0xfffffe08a079ef40, si_value =3D {sival_int =3D =
> -1602621824,
> > sival_ptr =3D 0xfffffe08a079ee80, sigval_int =3D =
> -1602621824,
> > sigval_ptr =3D 0xfffffe08a079ee80}, _reason =3D {_fault =3D=
> {
> > _trapno =3D 1489045984}, _timer =3D {_timerid =3D =
> 1489045984,
> > _overrun =3D 17999}, _mesgq =3D {_mqd =3D 1489045984}, =
> _poll =3D {
> > _band =3D 77306605406688}, _capsicum =3D {_syscall =3D =
> 1489045984},
> > __spare__ =3D {__spare1__ =3D 77306605406688, __spare2__ =
> =3D {
> > 1489814048, 17999, 208, 0, 0, 0, 992191072}}}},
> > ksi_flags =3D 975329968, ksi_sigq =3D 0xffffffff8082f8f3 =
> <Xinvlop+179>}
> > #17 <signal handler called>
> > No locals.
> > #18 0x00003af13b17fc9a in ?? ()
> > No symbol table info available.
> > Backtrace stopped: Cannot access memory at address 0x3af13a225ab8
> > ---snip---
> >=20
> > Any ideas?
> >=20
> > Due to another issue in userland, I updated to 2024-02-11-212006, but =
> I have the above mentioned version and core still in a BE if needed
> >=20
> > Bye,
> > Alexander.
>
>
--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
From nobody Mon Feb 12 19:34: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 4TYZQc1DnWz5BRQ9;
Mon, 12 Feb 2024 19:34:16 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228])
(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.protected-networks.net", Issuer "R3" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYZQZ5x4Rz3xmy;
Mon, 12 Feb 2024 19:34:14 +0000 (UTC)
(envelope-from imb@protected-networks.net)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=protected-networks.net header.s=201508 header.b=OGnjD1Vh;
dmarc=pass (policy=reject) header.from=protected-networks.net;
spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
protected-networks.net; h=content-transfer-encoding:content-type
:content-type:in-reply-to:references:from:from:content-language
:subject:subject:user-agent:mime-version:date:date:message-id;
s=201508; t=1707766447; bh=hJUCpSo9AIv6zz2G/uHrI3/a7zG8LKk4HSI0
XyXt2y4=; b=OGnjD1VhxQyJykElrrO5OGSchaPEv38cFakg8jQFHwTQSG5JXObb
KpGxlcRGhTCqQqy1EvmwNyqd5opk+7+8l1hFmP190mjFxPNJOlfLXuy5i4L1G25c
urmoP0lMmQlmLUaw9BrLxMD2LNVOGk57t2zeCjYPg7uev3zAJ8OHV5E=
Received: from [IPV6:2600:4040:53d9:8200:f21f:afff:fe66:957e] (unknown [IPv6:2600:4040:53d9:8200:f21f:afff:fe66:957e])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
(Authenticated sender: imb@mail.protected-networks.net)
by mail.protected-networks.net (Postfix) with ESMTPSA id 805673D2A2;
Mon, 12 Feb 2024 14:34:07 -0500 (EST)
Message-ID: <7fecae82-636d-4907-999a-e672d138b237@protected-networks.net>
Date: Mon, 12 Feb 2024 14:34:06 -0500
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-NZ
From: Michael Butler <imb@protected-networks.net>
To: John Baldwin <jhb@FreeBSD.org>, Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Cc: Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
<b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
<0b289f85-152b-45b2-a81e-ff34e398c964@protected-networks.net>
Autocrypt: addr=imb@protected-networks.net; keydata=
xsDiBETHZAURBACJicNaIbVVVZahtQcdJeogtTLjCYAdj4kFMpy6Y3Ac19UNWDM+TrD4yFPi
5nc/pp9M/5Q4RNBr6a97fTYroTaq+vDwWdklOHwD2ZXs7FqwWOtVSIPT/rev5fUvwEF2VFYE
sNDbpE5HHpP/oFUw5scEJZVyOBJSGvYb1IhV55NWswCgzkUGbG8A3s+oZXkHqTCYGW/seukD
+wTo/L835xLpbTJxoxEKeGA3aWifSsRvpWWHyXye6sTkSN3SmtE9A8Pqmdb1dBEO0eOms6GD
RamvCFgdvg2HesAv9l7L/7Mm9iKJs6uTAa+taIQslpumGh4PRc94IepVFzAa4Ef/FA4mWx9w
P/EqNsKUPE2U5HI1decbopkxH/d/A/9Hupc10lPsXVMACd54/YZRsSTTcArheekm8qE/f8Hl
1Q7At+yuFgfMll4QPAhefnrLUanXF1bWtxG5PmaJktDYp3HOmy43giZgacgt+a3TVd6vu8Gs
DnI4FOfYllq7mZFezMIulCWUYtnkMEXEeyzp39dygi7blPIjckWlQ2sc380rTWljaGFlbCBC
dXRsZXIgPGltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0PsJgBBMRAgAgBQJEx2QFAhsDBgsJ
CAcDAgQVAggDBBYCAwECHgECF4AACgkQQv9rrgRC1JL7mgCdEnPeo22kqT/bES+D78QSGhNR
r8cAn2xOMeu6pBrc2tDY8Ky/70HBctmjzsFNBETHZA4QCACKbm/PMn4QcyDEvIn4MF+t2E1A
zgiBAkPCMtWT1CcqeUj13OwNM8qJD/mBWjCZCnr1hKVbvzOmgKaM4uDCWIcSCdoDTJx1DqMx
abr+EpHz1fL6aagEOKHz5sCYOkDXt3zzZ/5RBMdkEJwunXYtAbu5e68oty+d0DFzAM3pBp6l
GC0TE3VutmFR/KK66rf0KB83YQBf/IAtyqsRIQPP9t0SLfJ+kqKXf73nvAUFEtb21gZSzhTm
QP87QKyQvenE8o4PQ2tEslq2jICB7pGcqIrwP4o3Hl4V+HXi3lA26MMJ5rakQB2sKKWroPVQ
BiRXO+W8Qf+0oQFq38oMXR5sPOs/AAMFB/sEKcjzvkwviZOsDElthxtgrmqUNKC9G/4Fw0tK
k6fMynv+bcKz85k2uWOIfefUKBFoQ0SCphU4jquJENqqy6BPTkXePlIJok2/GkF7xtHm2FPq
tTTuYmoBrGsls28Z9dn2LcBwFHz59SSWM9JFPIvFr9HCkKtp6zPUsJd5b02+0wgzDubTMQS9
M2LwGSh9xK6xl4MGgngl22b0TZDh5qHwmsywOX6SbGsQfeNpkptJ4gPjShypusFyF+pevnCM
wTfUPCBd/AFbu2fHFQjA8sgkr5IqXuc4PoiIBXc9upoFpDqGkYssAKbzGcRsK94a8hRROJV9
bzPyYempIWaPXr2EwkkEGBECAAkFAkTHZA4CGwwACgkQQv9rrgRC1JKqhwCeOov6gTo8eWte
es3gbLr2n2b5AXMAoItSlajet574lkouzY3u3scSRfiE
In-Reply-To: <0b289f85-152b-45b2-a81e-ff34e398c964@protected-networks.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.98 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.99)[-0.993];
DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
R_SPF_ALLOW(-0.20)[+mx];
R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
MIME_GOOD(-0.10)[text/plain];
XM_UA_NO_VERSION(0.01)[];
RCVD_TLS_ALL(0.00)[];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
FREEMAIL_TO(0.00)[FreeBSD.org,yahoo.com,freebsd.org];
DKIM_TRACE(0.00)[protected-networks.net:+];
RCVD_COUNT_ONE(0.00)[1];
ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US];
TO_MATCH_ENVRCPT_SOME(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
MIME_TRACE(0.00)[0:+];
MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org];
RCVD_VIA_SMTP_AUTH(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RCPT_COUNT_FIVE(0.00)[6]
X-Rspamd-Queue-Id: 4TYZQZ5x4Rz3xmy
On 2/12/24 13:44, Michael Butler wrote:
> On 2/12/24 12:36, John Baldwin wrote:
>
> Â [ .. trimmed .. ]
>
>> Short of a stack trace, you can at least use lldb or gdb to lookup
>> the source line associated with the faulting instruction pointer (as
>> long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
>> /boot/kernel/kernel' and then 'l *<instruction pointer address>',
>> e.g. from above: 'l *0xffffffff80acb962'
>
> I still didn't manage to get a core but .. does this make any sense in
> htis context?
I apologize .. too many crashes and I grabbed the wrong instruction
pointer; this was the most recent attempt. I have no idea why this
networking code and PCI configurations are seemingly related :-(
(kgdb) l *0xffffffff80acbc02
0xffffffff80acbc02 is in cc_cong_signal
(/usr/src/sys/netinet/tcp_input.c:465).
460 tp->t_flags &= ~TF_PREVVALID;
461 tp->t_badrxtwin = 0;
462 break;
463 }
464
465 if (CC_ALGO(tp)->cong_signal != NULL) {
466 if (th != NULL)
467 tp->t_ccv.curack = th->th_ack;
468 CC_ALGO(tp)->cong_signal(&tp->t_ccv, type);
469 }
From nobody Mon Feb 12 19:55:03 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 4TYZtf0bjJz5BT1R
for <current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 19:55:06 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "Client", Issuer "CA" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYZtd702yz42Hl;
Mon, 12 Feb 2024 19:55:05 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Authentication-Results: mx1.freebsd.org;
none
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
by cmsmtp with ESMTPS
id ZWf1rkaKexDxGZcOPrnbIf; Mon, 12 Feb 2024 19:55:05 +0000
Received: from spqr.komquats.com ([70.66.152.170])
by cmsmtp with ESMTPSA
id ZcOOrgM8tWhyfZcOPrZAPf; Mon, 12 Feb 2024 19:55:05 +0000
X-Authority-Analysis: v=2.4 cv=MenPuI/f c=1 sm=1 tr=0 ts=65ca7799
a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17
a=kj9zAlcOel0A:10 a=k7vzHIieQBIA:10 a=VxmjJ2MpAAAA:8 a=6I5d2MoRAAAA:8
a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=P8UMhXQfQG_xj_VZIjcA:9
a=CjuIK1q_8ugA:10 a=lYGsSHVhVPcA:10 a=7gXAzLPJhVmCkEl4_tsf:22
a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
by spqr.komquats.com (Postfix) with ESMTP id 0D9AE112;
Mon, 12 Feb 2024 11:55:04 -0800 (PST)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
id EDEA298; Mon, 12 Feb 2024 11:55:03 -0800 (PST)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev
Reply-to: Cy Schubert <Cy.Schubert@cschubert.com>
From: Cy Schubert <Cy.Schubert@cschubert.com>
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Cy Schubert <Cy.Schubert@cschubert.com>
cc: tuexen@freebsd.org, Alexander Leidinger <alexleidingerde@gmail.com>,
current@freebsd.org
Subject: Re: kernel crash in tcp_subr.c:2386
In-reply-to: <20240212193044.E089D185@slippy.cwsent.com>
References: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org>
<CAJg7qzH_c8JCKQvLPki6Cv7GRzaQs9vA-omSWBxnFTPy_9Rczw@mail.gmail.com>
<625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>
<20240212193044.E089D185@slippy.cwsent.com>
Comments: In-reply-to Cy Schubert <Cy.Schubert@cschubert.com>
message dated "Mon, 12 Feb 2024 11:30:44 -0800."
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Feb 2024 11:55:03 -0800
Message-Id: <20240212195503.EDEA298@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfHEWS27e1xNlqg5jM68ka57SdNij5Cq72XIxIrngP0oFxZifgyl8nSFbVF0LfvJZZx01oLEEo0my9uVmaTCSrOVzpbPfroAsAlrI2NKhpfOiRU11/7Y1
BvqlNP+PHZ25HbYQaANAq963We94GsTq7cNrKHzQppSUsm3Xm1QTtsb2itgo2N4P0vpyq1ZKbli9jgYovjoCI3eKAvsAmIyvuVEzBMskj43cbdbeslbwcCk6
VPN2+xncCYwQORmXO42J9Gm+LjDr5dKUcJERFZj/yRw=
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]
X-Rspamd-Queue-Id: 4TYZtd702yz42Hl
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
In message <20240212193044.E089D185@slippy.cwsent.com>, Cy Schubert writes:
> In message <625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org>,
> tuexen@freebsd.o
> rg writes:
> > > On Feb 12, 2024, at 10:36, Alexander Leidinger =
> > <alexleidingerde@gmail.com> wrote:
> > >=20
> > > Hi,
> > >=20
> > > I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
> > Hi Alexander,
> >
> > we are aware of this problem, but haven't found a way to reproduce it.
> > Do you know how to reproduce this?
>
> I've reproduced this by rebooting any one of my machines in my basement.
> The other machines will panic as below.
>
> I've reverted the three tcp timer commits, expecting one of them to be the
> cause.
Another data point:
I build on a build machine and NFS mount /usr/obj on my other machines.
Another symptom of this problem is that the NFS share will appear
corrupted. And df -htnfs will sometimes not display the mounted NFS share.
If not a kernel page fault, random kernel memory can be overwritten
resulting in bizarre behaviour prior.
--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
From nobody Mon Feb 12 20:00:16 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYb0x1lV4z5BTGr
for <freebsd-current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 20:00:33 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4TYb0w39vsz43SZ
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 20:00:32 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=kbzG8HaK;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707768029; bh=G8j0tnRXRCO2xAZjQvWZnJ4hPvXSgdIDKRGQKVs/SVI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kbzG8HaKxtvkCoILEfYw9jWzvCRGccLjQU+f9hHnZmF9ZahGWxDhcLZtQdK/UzcuJ/TH3EduXee8Gs08GtuGq3j9EcIQGO3xcxCCoBhc08XXJfjCrkThoEyj86HESvN85UK3wfSZDutVMdxAG4TLdcCE9Ffgst8BW/NjsJdpdd4cGe2dO4DHOsiqjEgnw77dLFA+iou80vG91I6avtqsqEudXnZihsVf1L+DHlwmVQuwGvTWRrmM/mcD/uQVSEBu3/GLfwC3JnGSRnHKDqrOO0b69XtYCgm/Qo9icfhMTo764yKCBMP/91TacUWBvTWabCNueXSt5LufGSKIM0M4XA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707768029; bh=ts6CMOyIS7djgJxcf2y2dNlZjt3Y6hiSnSdAeIfgnCH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GC6rMmiU6a+ryTOd+9/3qR9RLM05pdwb6FxtcixkrJA05W0OVv2eZMEti8oowlgnBHyD8h9/tFjh/s8MB8JolaRyxv1UGCA2KNS6wH+IRagm0yIGcckH2OWq1QYPr4np4EceeSmckg6bBaY3YS7JEbPepBwUag/B5UStFhC0tZUywqkp9Ak3LoKAZ2sAYvAInuToQ0bQiJCYSnw5FqkIJsDzAe6zUmyhjAxr5+nz1JmTOLGVTRU+yQi7cf59Dmy/OYbmTtKn+GSNs+cXUq7w7B5RHflr5k4ft/Vr3G2yznKHRYLGdzdNQJ4Tho7XK/6BVv6U3t8hAyHaCYJTg4CB6Q==
X-YMail-OSG: gxcR.tsVM1mhndE7Dc4gWvyNQvxEm2tIM.TSMNtir8..IfpVAHMn1Zo4ipTsywm
DQy194QeI_1UUHFerRzVyulbSpkYdedfJ411b0vmGJkCSVv4dZJTy2BJb1qD_wwYc9r4eEwypZPD
G.VuL.5CFr.y8c567ou_Gbx5dYJfDPWiO677CqEWvRLMu42tt0fsL5QG3rRpVnQ_jGShEpZNrt2p
wGSL1SBzoKVtYfAmSFWAeb_Bo.PhN0APCYHdC..3Jsi7vFnlKDgTySpK4_ERZMLIJzeqDZyU2bLc
b0ALzKYLk6CFqIHTRToOgL_jKYzYznSQM3ckMehbIIUipSCi7KU6iUMFdxZtQtpQUggZaHeQP1P8
Bj2bqvG1sWmPu1dGLXPPAlVx0vK0lbWPeh8h9iqtVnkS7lVDi25K3GyZgYLWrr3za1rIVkOGBqhC
lXWwazIEuISC05OHBoJoTF3ulrrw722EWCtEnB.7PDQX6BZlQFtgsSRbJFYt1zwD5hpan5JmCb1F
_xBA1_UBBCU9hJ8bmz_2AwRXcQxniA_BvQ.ts.KMWam4tNXxjEa0Li2zhc1ngDxWOAQxOWOQJqI0
xy3BX.BCPJkL7b_R3KJ0aEm_dKkPoLjTN8S5NxMMPlm.W07ei9LQq9E1KdH9PS_b0Zu8ju2zYc9i
0wlqbeM8.RHBicdVExEJUbu.uLUwHAEepsLZwYuJeP3MvR2KF8Aq4pggT5TAhcN0GEWNu10jbE4W
JZW77q.RNJyJghSS59eTFQE7Jh5GZLi.7kCqz68PxKr4k4LTTl2GiYDmsyXrNJK8bZeGv1d4gqQN
ofW92t_pFZcfQQBLKeiMu5CC8_C4CszQMzUswEnaMrDfWCwyzzQgKmfOn0sSYD.Ah9AMf5PT.AXs
IgfvV0GSwrT8IP__1.yS9vTeZoYAx_R6CWWh2GldRgLaPWDiPBymX.rw1.G2RLlMAz3NJqS47XLS
hY7knZuYZxdvwQQV4GciTdms2DNz7gsXubOuOSBXPh3DML.aC7lsKpcDi7nQ4Orwsky3zduCfG2v
EC5BXKeAATRVGrImJyG1EhAkM1c2LQa4u7lnUk9Wb87cJho1tCUjVGi6qTlzJdMAw9k1vKGZaLWg
.uWsDaHa5Hcu5NirCAligClxMzGH3l5zhbGRcmXQUlxwS1TrMJXCcbYhklxX5NjmvhkrfYF5jC9N
6bxfJBVEr1jdoGhI57MJ1s_6MeTLDETXU9PKf.lZIur2fkFO57VU4S5UgkJOdVpUspOb6Zh0bs1I
CVvHlTtWfwYYhBe.1aAMY2oNtU2dZNFDcCaU5xQkiW1bhoQ9lH3rTSRMNWT46nXnSIgXxYgHXJ8l
wbTqIR6lnBDyLeIWiuiX5DjYaphXOcXziuy9sWJljgyMLxOtDG98__tSqYyZmKl.htm3dTtw47Pt
Egt3qB0hDQdJIzoS1CnkSP8CE2kBZrMpr.F8BnY.ko3chIJilDJBcuiorHQZkLNi0p9pL0FYqMHF
_EzACguOu5TuG1Zy0iULI_tB._sPA2VkmpfgPDDqHej98aS.nat1Y1UYX75hQ26fEuYS.hbrEAKL
KR3U_dsdH5Msbh0WDvrXuwy5kihQSfEp0xKVQ4DJ6Rb51QIujdgBB65Lw3jlWhhaCLSs1NzQVEvT
McM29l34CTnZ.a17wAYHI.QOZTRZQXqwZhTTwF7Z1__rV1r8Q3fEBWXvis4ZoVA0N4K9doz4y_rh
_gY8u7f7mFAPl0F6kuQX_8gqYTb7rHWiN2.WYU7EmBnBFNV3UumhtlVH5g0qANIcTFhkJmVXkktD
zyYv_HXTBJUvbjkzFPFTpOxFzo8QNbwDfa8t5jaXBazsbS63tLXGKizpEIFvh2rKGDhMOL2jmaQJ
KMGGfPNcZtvKS4Otpm6v4.KRDtXsfRv4Pn3rt5f81wl_Jbc_48FgmxViWr7APOoC5Lf1iC2Z4ekd
zcmoeLPC_PyeaYUawqsGwLPRPx3L7Oj4RRmU20zFcs1ZQG1FDbbdug0ecukEwN.08Wkj8zDbR..S
xZz5D5em96sf7Da35WCdOiP.ocRWIyLFPjWaNIvNi1oINqFbhNSplTU3KI4YJL3hWmYzJXKfCH1q
S8Og3fxJ5NpGYU01unSGWy48TDOxIvOBDeGlhkYKDev.jOSz7JsnkgCs19B0yFAxBfi9_yLW33i5
hnsxUMScWxhOeyl9mz_3VNlwtpl_ROm_x4S2iLMgc2pm4JVT3oJZ8akEX74sOu2uJoJrYtqDW4LR
78h7tC6tBmu2rMWQeReR7F3Wc4hCRFvjvFFfzNy4yNtZ.v2j0HawnHQoZ8E30wOZzs5f3XDY46ts
-
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 6c6cc0f3-3a3b-4919-ad8f-cddc5ce9064e
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Feb 2024 20:00:29 +0000
Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ec8a9cfc035de1a91425f5ef22695fc;
Mon, 12 Feb 2024 20:00:26 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
Date: Mon, 12 Feb 2024 12:00:16 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from];
RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]
X-Rspamd-Queue-Id: 4TYb0w39vsz43SZ
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>=20
>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>> Summary:
>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>> pcib0: parsing FDT for ECAM0:
>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>> . . .
>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>> panic: Failed to add resource to rman
>>=20
>> Hmmm, I suspect this is due to the way that bus_translate_resource =
works which is
>> fundamentally broken. It rewrites the start address of a resource =
in-situ instead
>> of keeping downstream resources separate from the upstream resources. =
For example,
>> I don't see how you could ever release a resource in this design =
without completely
>> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
>> translating bridge that uses the current approach should corrupt the =
allocated
>> resource ranges in an rman long before my changes.
>>=20
>> That said, that doesn't really explain the panic. Hmm, the panic =
might be because
>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>=20
>>> Detail:
>>> . . .
>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>> pcib0: parsing FDT for ECAM0:
>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>>=20
>> This indicates this is a translating bus.
>>=20
>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>>> considering [0xc0000000, 0xffffffff]
>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested =
0x100000)
>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>> allocating from the beginning
>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>=20
>> The fact that we are trying to reserve the CPU addresses in the rman =
is because
>> bus_translate_resource rewrote the start address in the resource =
after it was allocated.
>>=20
>> That said, I can't see why rman_manage_region would actually fail. =
At this point the
>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>> so only the check that should be failing are the checks against =
rm_start and
>> rm_end. For the memory window, rm_start is always 0, and rm_end is =
always
>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>> ranges are within those bounds. I would instead expect to see some =
other issue later
>> on where we fail to allocate a resource for a child BAR, but I =
wouldn't expect
>> rman_manage_region to fail.
>>=20
>> Logging the return value from rman_manage_region would be the first =
step I think
>> to see which error value it is returning.
>=20
> Looking at the code in sys/kern/subr_rman.c for rman_manage_region I =
see
> the (mostly) return rv related logic only has ENONMEM (explicit =
return) and
> EBUSY as non-0 possibilities (no other returns).
The modern code also has EINVAL via an explicit return.
> All the rv references and
> all the returns are shown below:
>=20
> int rv =3D 0;
> . . .
The modern code also has here:
DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
rm->rm_descr, start, end));
if (start < rm->rm_start || end > rm->rm_end)
return EINVAL;
Adding rm->rm_start and rm->rm_end to the message might be
appropriate --and would also be enough additional information
to know if EINVAL would be returned.
> r =3D int_alloc_resource(M_NOWAIT);
> if (r =3D=3D NULL)
> return ENOMEM;
> . . .
> /* Check for any overlap with the current region. */
> if (r->r_start <=3D s->r_end && r->r_end >=3D =
s->r_start) {
> rv =3D EBUSY;
> goto out;
> }
>=20
> /* Check for any overlap with the next region. */
> t =3D TAILQ_NEXT(s, r_link);
> if (t && r->r_start <=3D t->r_end && r->r_end >=3D =
t->r_start) {
> rv =3D EBUSY;
> goto out;
> }
> . . .
> out:
> mtx_unlock(rm->rm_mtx);
> return rv;
>=20
> int_alloc_resource failure would be failure (NULL) from the:
>=20
> struct resource_i *r;
>=20
> r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO);
>=20
> (associated with the M_NOWAIT argument).
>=20
> The malloc failure would likely go in a very different direction.
>=20
>=20
>=20
> Side note: looks like the EBUSY cases leak what r references.
Still true in the newer code.
>> Probably I should fix pci_host_generic.c to handle translation =
properly however.
>> I can work on a patch for that.
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Mon Feb 12 20:21:27 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 4TYbTN65GVz5BWlK
for <freebsd-current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 20:21:44 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYbTN3QFgz46Mq
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 20:21:44 +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=1707769302; bh=iRklNIyJW3dgjnbFU/rJc84i78OnTiX8kR3DnpKBESE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YLTPUr+MvbuYQjQ1uZeqggjl05NbPbpFE4gWMPOBIB/fSRngo4QmfZcyEZNCb586ckFG3aUcsAIV11iOtUfGF+3y0VX51bWiHvL38ckfePtFV2XHSzM7qjQ5HH20jPDBaM/7rDNdhLMIzTOcOqBnXT0wyu4wsMdHenNH59X4rGWO5n5MBXxaJcGbhvj+oBHPaxxNLj10hUC/2Rum8029Kc2isKTPG42eZtV+4wHejwsuHM0P1oaBJ6ChN8+xrUEskYY/3LDc62lbZbkUbHYnRarXy7o/rv6kH2ZlYrgXzzw5nyRFCyvK3RznpUd/AGbZaMAH5+eiZ107uDSsqyPA1Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707769302; bh=trd+Tz3QDcrWyLEE7TR6ftyzwFObMNl5xCVIpeXvTIb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=c8Mwk9i85cyzG3A6qk9bOcMj3N/iicUs2S8360BrsANKfKllmqH7YDDDIZaupz1Z2aFjCpnX3V5Z2K3yelMCFZvCmCrc7ezCV4c+4dVOOwEKc8wsrktv80weXSH8aPWs3jJJ1JKCdPtuwjrhshR3HwZ/d4vVQzl1t1mLQuvjp5O/Sixpn4IZ8mAUWb6h2uI/qwfJNPlnYxAoy0okHSvoC6jm0eCNv/q8tKMtarD84lZG9bk3Wq/2KwE/a6HeTeMC7nTfDVj901e/8sI4/FZxWD8ojdaT8oCuQ8WTmzmSbW8xNiIC4R9dMSnGc/LADNTEPbk4g62iviuNk5r//qCxtw==
X-YMail-OSG: VhJH12gVM1km9EXr5l6yxnfUiOPWU_OmgHjErSI.Si072OoweiHfbLSZ79nK2x0
GnCanvZbGhrJJBzIG.ZUkKFMHemEqXKNPr9ownT0BIyuDAWTcpLOpp5t8e7tPtH24xkJkd2Iv1hg
SS7nSPehekTF7sFuQHBgJrk9XtM5xpgYkO0Qf3llBfBghKFhVNldyxGrXlHcZugeCZMAJfzDdY2h
NOH3DKm_5V92qOJZdVBD1t230ZhpeJpXgdgihMI05ucQRa8riejG_y18u7qIFPAbfID3GR4KMiDg
wHfdd0YCZq3aCCil5FfmgqQi_GBjCl8OpToewt0UCKbm.hsQqSqG0nMNrnGiZl4bdUCYLMo7QP78
WzpVNTO43DM70_FH_kUVdfi8w.vS.uVjq3KQ9VggFQl0ZF0XQK0du7nIvgo1UMH08Y.iHpSNC8W3
gj8MMiO0XzLWmjzmtlIlya6ckYUuY0hLQitVUyFyZ8QJQ1qCJMfDCr6PoB6uxpxBq7omRAy5cYcI
IDafm6B.lbHTsG6bMrDk.9a4DgMBTXE2WXs2Hi6Cx343qRUC4loYLceV7_Xh9eJ3GhqByj9hX.F6
zC5UOA02YJE5rNZpnsFV2z1HSeEspZE_aZjqfGd5T0ftQsXCVMpVlmpTga0vEyjS2H2tWnee0rBy
s_97IWM6nMz7mZF1zpKwHvP61UPIOmOi7ZTE_J5xIvrO4_Xo4FzFH3XNCKFyJqaptFrUClp.A7tU
Roio.CqYOC0ym5swrypDP5OqtBo.24c1SHywvcwf.YO2OOs41Fnpt.F5NNkfAovlvS6MkZ_eMo6F
RftB2mdC2CToJA11_tnCMb2h9JTCb36vXS5qfOzgjm6t9hlvrPqPrIWaRNbOdnm70CuYV4Dxl3Ee
D7yHrHTzyMuDpYhuL1cxrYBlNSYUY_1xsTrdLmPizF7NvIdMEsk3EVF6Kkr3241Rpf4UujjvGRnq
55iL42sQxWeKCYUUC8YUwsHCko7zx0gCdN9X5bJzsuYn6QeACwgCioMsw82Chnq7QWDk445Ecn56
0zZrefq8GA_SDSc1t6Pe7_0lT8A93iHGEbAIk4t_2c_px7NLj7UBY7OiowGzK3aVV8LHGewJP2Yh
k1.dwA9IrBtDJz_9rVxYyPobex.q0378HKpdUUfbLg7lNMKp6gDPefkLbyKVpwJib47BU8VY3qiE
.9zTOMO76y9MUafQJt6qQJtEJBqGqUOJLZCqeeqmyjKPe90n5n9IdMJqocgbUr_FmRwOgEly7qaT
Dzn63vtJL..euK4kjafwpN_a6YMSWuHPdBWMSyLGl6dPsPECCTotbMqoY5DOYjBl7zrW6KS6V7e5
L3ozwEKp.aTnJu2IuV6p8OgSInaIVrgBM46eRY1d5WnfRjtQFc1r.Z.PQIVHEkzSSL4m1fpw7D2F
dTg3uxQ_0.Q8aADcwt4FDG75Pps7GuJ1V2oDy6WLgP359xmmzcuBf.PDhCu9QqLHGNgvWf4VL8oX
6FUd15K8Bops3O0BCs6uosgvUoqI63_0a9ob21Xw3eHEFzX4KriP3EcrQtoUcUAvhErCoJUuQX1q
WelKD1a482.aLHxTqPNBqTC2D6Fh0qcj2Ut3.ii3nzzVvdVSxgaz7Nq34gvFPAr7R0y8iJXnueJl
DezqFqLOCXq21zTbpUwOKeDJBGrwoqzCndM3SKN.fUdG4AP7i2hmk4CeotU6d1YYNbMXuAuSJNEs
j.u_deY5V1q3E05nmWlIyfzspS6CfHxANlabN6GY8JRjozE0Z0oo0Wd2vAM4w0fc0yUlKaRFZNm4
IytEXft90r0HBrSXzVAdNjgLvtbqH7cE1x.2pvg6p4PIvotn5ntr1l.j2ZdtUSBhppOHU3wurh0r
cEJjt3tK6DhcEZdi07XLj64Bm4pP_lAqmlZWdk__K5CvkFg8L79rVDUPxEmj0kOPT7e0iO3mobGV
hWoAMJxeiDrdqguPVeE8golnE6g.Kq477aD18WYVfLDZ22dArCmm7_eaYhp6ysPVHcgin3wYcSCG
ihqGmbBTGqV.zsjOComGdddKZPHc9E2k56MS0CrCOWmrRmB3wExCcg7WqeqV6dJT0nqT5qz92VMv
5a0ZQ5bkqye_XLTBQUyxvPOTyDDkyeUZZsDcUB7pJSycd8TfXaNcXBC9Ejp6MEqAyb_Oq2IPqG7N
42pyk6LWhnQ9JkfnP17qbKsvMRweeJ9a_4b8tkFiQWg3R.tu_BHPRIAK8fY7A7MVvCEJuT31jS0M
yUpCoJhGAm_XJQw1z2ztVHUPVEPzMzZTal5AEZBmVzcc8Xvc_0YVKL.oqIr3fJC3q4IHZwuRof1e
yXQ--
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: c5e7cf0a-ae65-4221-b7ec-903391a33421
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Feb 2024 20:21:42 +0000
Received: by hermes--production-gq1-5c57879fdf-vxz7c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0aab6ab516ff3bc8a096222fb49422f8;
Mon, 12 Feb 2024 20:21:37 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <ZcpdQQwxQ1Nplg7_@phouka1.phouka.net>
Date: Mon, 12 Feb 2024 12:21:27 -0800
Cc: John Baldwin <jhb@freebsd.org>,
Michael Butler <imb@protected-networks.net>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>,
Bakul Shah <bakul@iitbombay.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AEF0FB0-F8CB-46C9-B14F-0723136AA116@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org>
<986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com>
<b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
<b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org>
<ZcpdQQwxQ1Nplg7_@phouka1.phouka.net>
To: John Kennedy <warlock@phouka.net>
X-Mailer: Apple Mail (2.3774.400.31)
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: 4TYbTN3QFgz46Mq
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Feb 12, 2024, at 10:02, John Kennedy <warlock@phouka.net> wrote:
> On Mon, Feb 12, 2024 at 09:36:46AM -0800, John Baldwin wrote:
>> Without a stack trace it is pretty much impossible to debug a panic =
like this.
>> Do you have KDB_TRACE enabled in your kernel config? I'm also not =
sure how the
>> PCI changes can result in a panic post-boot. If you were going to =
have problems
>> they would be during device attach, not after you are booted and =
running X.
>>=20
>> Short of a stack trace, you can at least use lldb or gdb to lookup =
the source
>> line associated with the faulting instruction pointer (as long as it =
isn't in
>> a kernel module), e.g. for gdb you would use 'gdb =
/boot/kernel/kernel' and then
>> 'l *<instruction pointer address>', e.g. from above: 'l =
*0xffffffff80acb962'
>=20
> I know on my RPI4 where I saw that, my USB keyboard was dead at that =
point
> and I couldn't get a trace or continue along to get the crashdump.
My serial console context still works at the panic.
But:
. . .
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at kdb_enter+0x4c: str xzr, [x19, #1280]
db> dump
Cannot dump: no dump device specified.
db>=20
This is despite:
# grep dumpdev /boot/loader.conf
dumpdev=3D"/dev/da0p3"
and:
# gpart show -p
=3D> 40 468862048 da0 GPT (224G)
40 32728 - free - (16M)
32768 102400 da0p1 efi (50M)
135168 451809280 da0p2 freebsd-ufs (215G)
451944448 16916480 da0p3 freebsd-swap (8.1G)
468860928 1160 - free - (580K)
So, the panic may be before dumping is set up, at
least for USB3 media.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Mon Feb 12 22:22:51 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYf9w26bSz593Hj
for <freebsd-current@mlmmj.nyi.freebsd.org>; Mon, 12 Feb 2024 22:23:32 +0000 (UTC)
(envelope-from freebsd@walstatt-de.de)
Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYf9t5Y2kz4PjM
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 22:23:30 +0000 (UTC)
(envelope-from freebsd@walstatt-de.de)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=Atv0i7br;
dmarc=none;
spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de
Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by smtp6.goneo.de (Postfix) with ESMTPS id 1D266240A62
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 23:23:21 +0100 (CET)
Received: from hub1.goneo.de (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by hub1.goneo.de (Postfix) with ESMTPS id 83BBE240223
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 23:23:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
s=DKIM001; t=1707776599;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=PpJ9j5Veg8RLYXqiqXG/bze3imH+3EVU1TCgnLmo9iM=;
b=Atv0i7br/XqWTm4vDg2Gl4jsxfp2aktooDa5lHef86NaIMyaDOMgLwdjyQJb/4I5KDUvQa
xz/l2keQjEwiiZ1yyFMDZNyXm/4h8f7/Ig85kN1uya3ybFVINSoL802PnHASvbsuaj51Vp
2AAWHStCDJX9g1FAF2IbiqJHYEit7o9QhyxH4un0k+AvppWsQLTZA1POw1MeHKz8SGNFnj
DCgxQ/on3rqJmGg6KJrxp8BvRQsw2gRQ862jxETiOBcCOkfiQi6W03zfw8eBLXoDP/XFIC
jS/2ZHfivDrNsVlqQW1s5A8ask7znC7pofLxtUYWU0Yci8fjRLVRmAgbgbAjvQ==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-054-151-114.78.54.pool.telefonica.de [78.54.151.114])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by hub1.goneo.de (Postfix) with ESMTPSA id 56695240128
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 23:23:19 +0100 (CET)
Date: Mon, 12 Feb 2024 23:22:51 +0100
From: FreeBSD User <freebsd@walstatt-de.de>
To: FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject: CURRENT: ld: error: undefined symbol: zpool_open
Message-ID: <20240212232318.2d7e242d@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 413392
X-Rspamd-UID: 5cdf02
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.50 / 15.00];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-0.998];
R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112];
MIME_GOOD(-0.10)[text/plain];
RCPT_COUNT_ONE(0.00)[1];
RCVD_VIA_SMTP_AUTH(0.00)[];
ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE];
MIME_TRACE(0.00)[0:+];
HAS_ORG_HEADER(0.00)[];
MISSING_XM_UA(0.00)[];
RCVD_TLS_ALL(0.00)[];
DMARC_NA(0.00)[walstatt-de.de];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
TO_DN_ALL(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
RCVD_COUNT_THREE(0.00)[3];
DKIM_TRACE(0.00)[walstatt-de.de:+]
X-Rspamd-Queue-Id: 4TYf9t5Y2kz4PjM
Hello,
recent CURRENT (last commit 57e27ff07aff35289892f79288bebf76a3c31fec (HEAD -> main,
origin/main, origin/HEAD)) sources won't compile (ZFS staitcally compiled into kernel, if this
is of importance). Compiling world and kernel from scratch (make cleandir issued) results in a
linker error:
[...]
===> stand/i386/pmbr (all)
--- all_subdir_rescue ---
ld: error: undefined symbol: libzfs_init
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_set_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_get_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_nvlist_get)
>>> referenced 1 more times
ld: error: undefined symbol: zpool_open
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_set_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_get_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_nvlist_get)
>>> referenced 1 more times
>>> did you mean: mpool_open
>>> defined in: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a(mpool.o)
ld: error: undefined symbol: zpool_get_bootenv
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_set_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_get_boot_device)
>>> referenced by _$$hide$$ zfsbootcfg.lo lzbe_pair.c
>>> zfsbootcfg.lo:(_$$hide$$ zfsbootcfg.lo lzbe_nvlist_get)
>>> referenced 1 more times
Thanks in advance,
oh
--
O. Hartmann
From nobody Tue Feb 13 00:10:38 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 4TYhYr3sX3z59Gb5
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 00:10:56 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYhYq5tmJz4bL0
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 00:10:55 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=JFvBMZJk;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707783053; bh=fmC1BrYywDybpqqpl/CAHYMD81hpa1dY1DeQd9rDaKo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JFvBMZJkgLZAR2oAqbklyugsMe9H5B5ZOp9faKAG5xGl6RpACCjq1kFlbW8Y8PFGWIharBLm2v6F+JpwRhvS2pFS8GOoB6jNpAHa5W/jQp3jyOKFZxc1reeWYnxX9us+pNGUB+ys/ATkZav2P865JAGjlF+ou3F/NcZbnNzrXQJ1X4AH6m9as1p+Q5UWUOyvf0qr0xr/Yzbqb29WL6hAhcBmTjWMIVy5kX5pS6hzghrY0QFBhzLx4EXyfUmUclr7D7u6sP5vaKJcu09qH1OE4HCKVecvNivIKEjnIWQAXQwFeODCkRm4j6YlBdBlod7NsWjSPQWjD4DsJD+QgqikjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707783053; bh=0phXzRBikRx/pKt+HA5L9XzzXDkskjqKXaT0cXfcWa1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bmIjFr+ktnSCNK7E4Ef188gzGBJrYG/i8dapzaLfd3IcHIi36+n5j5Yy2gpx3dV/GPGRDX7+Di/5uj7BEaGovZQ5ZcyQEgbyGeWT2JKUEFD08GcCiJ3TgKpyiFJxXREk/fWQpNl634gVJrbYzbKz0z273Le5U3Bn0tCz7LnuEzfnw8aSrfG9GCcVjqeSBCO9BGJ5sGQjaWqZ4iRQNxOk4kS00T5bVjSFJWtChFei0R1MPDR0IICNj8xAlxs0uHxjMEm7IMxpuknBMJ5YgxDhUdOQf9+WDnDgTRJzeqngFoOcXU4wY3x+CIyFic1gXJoDGMFeZLhAWRMal84IRyZskQ==
X-YMail-OSG: u9sXt8MVM1mJP6XZXF03tSwo1sIPTKZuLfDx8H5YWvALYpfQ2z8yaFKZMT092Nl
1aY8f9sVSVOY0D1YM68R4xK6XbNB0diBZXBs1I0nKechScm1GGGGu12k4gBA46A3qR7R9gUbEgCE
iJAq_ovzH.suy3f1XFDvgsJCkM08KXvd9X1siS.pYknWNpJOpys1sIuon80UedSmoPpLBx4Ooln_
gCsRtnPDhmgfkI.nlKPGSmlAPvJk9g7iGfK1OvtHGOv55_RzMBzVyg_AupqRzw9ah8S0cqXwc_.m
.ljsQ4.tKqvVTIQFCbeCH42q.grH5RNWFnk1eqcigQRe1PW5MMg5E9JfnqDkTeb9NPeuThP.AjNz
rd.EWhgzYgz2W.Kw8XTnLN4LlR5i_WqowUZlPKeDbEC.I1d5dCvEoZ6rUS8yC.53mCMGf9nmkEZ_
jCScj5Lum69Z_ItTDtupEmMMlZ_.OMZsQRnIOc.mPlbP.mOO4lGlSbhUw2Cx0za3E9WyFo.msHqN
X2aJBypeR2BN3jo6hxWZWXwWUj7IVQMS.LOgQ7lLzvyo0339UU__Caucz.8WrMrPN.ZdK8aFdcM.
GdkNu9my5KX_5BJZZ1gsGblgQg_I.vsBZPAmy8M6LIHVFsVsALONMMu8gXpiJm.s3VQouI9gIJKA
ZTNs5EpamQouaaSOHl8AFH2WMwpzncOuAZKe9eUcuyHMAu4is3RCQ8vVW_q.e7BdjKqpDp4j8beg
g2gKOYSEn0Cu3kaweeBokLdVbReWibK1WQg8svQ.NfRvoek7zZ_T4xjcMj_K.5XDXxIFuR2sry6R
xJou81bgwlx5uEFY5DP.AT1e7.OCjMlXFQ5Wf4AS_4oUxc4bIZvpyg3HjspEJmh6WRGXyCQsRLvB
mmEnMe1y3VBROKYaxG.PzPlWHjgwGyy..7Ygs3nzRKubTjyxymnmmTW3P3Bz.WB.u4vxoMpfMYzC
E5aECfiFRa7hEkh16XYOSF72xfVJxyHsDLo1dAp320RKKjlEdl3iiYCOohJ_R9Oj_Wmqx7CRQfmq
VWLXZKjfddMcK9e6B7Hw5.ZL3jpKJ.tFtBcKFfYfIrVUB__HduVVt4cDpjPIu1xMcJzdM9b9oUhq
6gnHbpY0J91HkIeBW_fi7P5Hx8lN_J4tDEGXu0aO8.Tm8QOJuCmnglbYHpn1kEf6Vo1JFRMz6rE3
QhosLUigwMG5d5BAIzIuAdlmeZl4PF3Zk32igHYRgEjwb4XRNNnG0x.2rjZOKEkM1fwFLfENCoXq
Q6c2gowX132XEUO9PfKKGzWWIORoMi5YaFD1IVLujExj4rHtD_nl3ud5g_qzAvNypL4qH_1uLYD_
sO4RfBguHM9E2ITvebMUowCb6fd5XXMJUHLDhZ1G6oRfaxlfD_F9eFA6OAKH7WLTxcwMjBJa5sZf
rHP4zGlVMLiZrJE7_aNN00LP92WYW3Iy_z9AVVuhAmVspJo4pYr08SglFuf8i9IJMAr0CvLA_qZ0
ECqimfr0otUaXVP0mDEAxyTzYwUbUrgsg2QG2oAZfenzUJO2XiI9SI6IYWz4wnef_5vlp4fOrz03
KjZNOJ6c0Z9KugoTn8MxmZkrczwQOpN8f3v7yeYh6eg9vIIaCJnTf5s361ENk1Nl5yl2By.jP2cO
ZniqYhoHjFbaKo.WJN2AsBlzqXOoj_FRQQucxmqleRKYKrQS9CFVbS_8XG.yF_DlF07IT5fwsFhs
pDDCgk1WZz1eygL1pDNIY4M0xR7IXacm78_lTZ4Xg3NyyNGhVV8we35157d2lnRIhXJZ78TTm40e
iWIOOL736ZQJvLWb6Pp6Mu5P584tPMESlZJnYmJ.JfGWrlKw3yaEGJWWQLlSRzW3zsye0y_7S1lQ
Z09BvIddINavMvXmUbMISavkOdJaNbvYqIn8HZyxBeqLsZR24bECLk9uryjG0X83XcL7zFUZkVBO
OmonfQWVsF_3ZGFtxdHGeJtj5rYivad1Inzibx_K_E0vP3xFS5j0ygkfj8tvSUzonJ4xJ2brh7VQ
M53hvXJPZwKsRaTPWjHhawxRHNhYsI0Ul_QI8pQ7E3bjKuoanMpdb5Umzij83zh9LrRBT6U9ZlC1
43ZqO8Wodjl8EpaIvrsPtSmIvBKSjaBdEz_a1cLcr1c_ts3kL0ktom.tD92j.tIyuhj3QE9O9vXv
L0xIMQBxgGVqiLIWnMoTw4m2Sin9Pw002MeCj65pN9hwD6_b0VQ3D1JBeZOjfxqf_1jaRY.tm2T.
iLfhwqEOxl_U10V6.B.85lzEebD2LIqmXZXsO5721QDmis0XFS3CI5dPoFVhpIrd7Xgcb.VwM2Sc
0zR54GQ--
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: c8d9593c-dcac-4a56-b259-740cbef7bed3
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Feb 2024 00:10:53 +0000
Received: by hermes--production-gq1-5c57879fdf-4h5cs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cee797ca66f1f6d12376825ab98ef016;
Tue, 13 Feb 2024 00:10:49 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
Date: Mon, 12 Feb 2024 16:10:38 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4TYhYq5tmJz4bL0
On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
> [Gack: I was looking at the wrong vintage of source code, predating
> your changes: wrong system used.]
>=20
>=20
> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>=20
>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>> Summary:
>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>> pcib0: parsing FDT for ECAM0:
>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>> . . .
>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>> panic: Failed to add resource to rman
>>>=20
>>> Hmmm, I suspect this is due to the way that bus_translate_resource =
works which is
>>> fundamentally broken. It rewrites the start address of a resource =
in-situ instead
>>> of keeping downstream resources separate from the upstream =
resources. For example,
>>> I don't see how you could ever release a resource in this design =
without completely
>>> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
>>> translating bridge that uses the current approach should corrupt the =
allocated
>>> resource ranges in an rman long before my changes.
>>>=20
>>> That said, that doesn't really explain the panic. Hmm, the panic =
might be because
>>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>>=20
>>>> Detail:
>>>> . . .
>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>> pcib0: parsing FDT for ECAM0:
>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>=20
>>> This indicates this is a translating bus.
>>>=20
>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>>>> considering [0xc0000000, 0xffffffff]
>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 =
(requested 0x100000)
>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>> allocating from the beginning
>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
What you later typed does not match:
0x600000000
0x6000fffff
You later typed:
0x60000000
0x600fffffff
This seems to have lead to some confusion from using the
wrong figure(s).
>>> The fact that we are trying to reserve the CPU addresses in the rman =
is because
>>> bus_translate_resource rewrote the start address in the resource =
after it was allocated.
>>>=20
>>> That said, I can't see why rman_manage_region would actually fail. =
At this point the
>>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>>> so only the check that should be failing are the checks against =
rm_start and
>>> rm_end. For the memory window, rm_start is always 0, and rm_end is =
always
>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>>> ranges are within those bounds.
No:
0xffffffff
.vs (actual):
0x600000000
0x6000fffff
Both the actuals are larger then the 0xffffffff figure you list above.
I've no clue if the 0xffffffff might have its own typos.
>>> I would instead expect to see some other issue later
>>> on where we fail to allocate a resource for a child BAR, but I =
wouldn't expect
>>> rman_manage_region to fail.
>>>=20
>>> Logging the return value from rman_manage_region would be the first =
step I think
>>> to see which error value it is returning.
>>=20
>> Looking at the code in sys/kern/subr_rman.c for rman_manage_region I =
see
>> the (mostly) return rv related logic only has ENONMEM (explicit =
return) and
>> EBUSY as non-0 possibilities (no other returns).
>=20
> The modern code also has EINVAL via an explicit return.
>=20
>> All the rv references and
>> all the returns are shown below:
>>=20
>> int rv =3D 0;
>> . . .
>=20
> The modern code also has here:
>=20
> DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
> rm->rm_descr, start, end));
> if (start < rm->rm_start || end > rm->rm_end)
> return EINVAL;
>=20
> Adding rm->rm_start and rm->rm_end to the message might be
> appropriate --and would also be enough additional information
> to know if EINVAL would be returned.
I added such code and built, installed, and tried booting
a separate kernel. The result was:
rman_manage_region: <pcib1 memory window> range 0..0xffffffff : request: =
start 0x600000000, end 0x6000fffff
panic: Failed to add resource to rman
So:
0
vs. start:
0x600000000
and:
0xffffffff
vs. end:
0x6000fffff
The 0x600000000..0x6000fffff range is not a range of RAM addresses
[too large for that for the 8 GiByte RPi4B] and, so, is well above
the 32 bit boundary too.
That is the only line referencing "memory window". A 32 bit initial =
range
for some reason. For reference, the source change in question was:
- DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
- rm->rm_descr, start, end));
+ DPRINTF(("rman_manage_region: <%s> range %#jx..%#jx : request: =
start %#jx, end %#jx\n",
+ rm->rm_descr, rm->rm_start, rm->rm_end, start, end));
if (start < rm->rm_start || end > rm->rm_end)
return EINVAL;
I'll show a larger boot output context at the bottom of the message
for reference.
>> r =3D int_alloc_resource(M_NOWAIT);
>> if (r =3D=3D NULL)
>> return ENOMEM;
>> . . .
>> /* Check for any overlap with the current region. */
>> if (r->r_start <=3D s->r_end && r->r_end >=3D =
s->r_start) {
>> rv =3D EBUSY;
>> goto out;
>> }
>>=20
>> /* Check for any overlap with the next region. */
>> t =3D TAILQ_NEXT(s, r_link);
>> if (t && r->r_start <=3D t->r_end && r->r_end >=3D =
t->r_start) {
>> rv =3D EBUSY;
>> goto out;
>> }
>> . . .
>> out:
>> mtx_unlock(rm->rm_mtx);
>> return rv;
>>=20
>> int_alloc_resource failure would be failure (NULL) from the:
>>=20
>> struct resource_i *r;
>>=20
>> r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO);
>>=20
>> (associated with the M_NOWAIT argument).
>>=20
>> The malloc failure would likely go in a very different direction.
>>=20
>>=20
>>=20
>> Side note: looks like the EBUSY cases leak what r references.
>=20
> Still true in the newer code.
>=20
>>> Probably I should fix pci_host_generic.c to handle translation =
properly however.
>>> I can work on a patch for that.
>>=20
For reference:
. . .
pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: Bus is not cache-coherent
rman_reserve_resource_bound: <I/O memory addresses> request: =
[0xfd500000, 0xfd50930f], length 0x9310, flags 100, device pcib0
rman_reserve_resource_bound: trying 0x1fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x1fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x31bfffff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x33298fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39bf1fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c02fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c06fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c07fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c08fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c2afff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c36fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x39c37fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3b03ffff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3b04ffff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3b2fffff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3ee61fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3ee63fff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0x3fffffff <0xfd500000,0x930f>
rman_reserve_resource_bound: tried 0xfbffffff <0xfd500000,0x930f>
considering [0xfc000000, 0xfd5d1fff]
truncated region: [0xfd500000, 0xfd50930f]; size 0x9310 (requested =
0x9310)
candidate region: [0xfd500000, 0xfd50930f], size 0x9310
splitting region in three parts: [0xfc000000, 0xfd4fffff]; [0xfd500000, =
0xfd50930f]; [0xfd509310, 0xfd5d1fff]
rman_manage_region: <PCIe Memory> range 0..0xffffffffffffffff : request: =
start 0xc0000000, end 0xffffffff
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
rman_reserve_resource_bound: <Interrupts> request: [0x51, 0x51], length =
0x1, flags 0, device pcib0
rman_reserve_resource_bound: trying 0 <0x51,0>
rman_reserve_resource_bound: tried 0 <0x51,0>
rman_reserve_resource_bound: tried 0x1 <0x51,0>
rman_reserve_resource_bound: tried 0x2 <0x51,0>
rman_reserve_resource_bound: tried 0x3 <0x51,0>
rman_reserve_resource_bound: tried 0x4 <0x51,0>
rman_reserve_resource_bound: tried 0x5 <0x51,0>
rman_reserve_resource_bound: tried 0x6 <0x51,0>
rman_reserve_resource_bound: tried 0x7 <0x51,0>
rman_reserve_resource_bound: tried 0xc <0x51,0>
rman_reserve_resource_bound: tried 0xd <0x51,0>
rman_reserve_resource_bound: tried 0xe <0x51,0>
rman_reserve_resource_bound: tried 0xf <0x51,0>
rman_reserve_resource_bound: tried 0x10 <0x51,0>
rman_reserve_resource_bound: tried 0x11 <0x51,0>
rman_reserve_resource_bound: tried 0x12 <0x51,0>
rman_reserve_resource_bound: tried 0x17 <0x51,0>
rman_reserve_resource_bound: tried 0x18 <0x51,0>
rman_reserve_resource_bound: tried 0x1a <0x51,0>
rman_reserve_resource_bound: tried 0x1b <0x51,0>
rman_reserve_resource_bound: tried 0x22 <0x51,0>
rman_reserve_resource_bound: tried 0x23 <0x51,0>
rman_reserve_resource_bound: tried 0x24 <0x51,0>
rman_reserve_resource_bound: tried 0x25 <0x51,0>
rman_reserve_resource_bound: tried 0x26 <0x51,0>
rman_reserve_resource_bound: tried 0x27 <0x51,0>
rman_reserve_resource_bound: tried 0x28 <0x51,0>
rman_reserve_resource_bound: tried 0x29 <0x51,0>
rman_reserve_resource_bound: tried 0x4e <0x51,0>
rman_reserve_resource_bound: tried 0x4f <0x51,0>
considering [0x50, 0xffffffffffffffff]
truncated region: [0x51, 0x51]; size 0x1 (requested 0x1)
candidate region: [0x51, 0x51], size 0x1
splitting region in three parts: [0x50, 0x50]; [0x51, 0x51]; [0x52, =
0xffffffffffffffff]
pci0: <OFW PCI bus> on pcib0
rman_manage_region: <PCI domain 0 bus numbers> range 0..0xff : request: =
start 0, end 0xff
rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: [0, 0], =
length 0x1, flags 0, device pci0
rman_reserve_resource_bound: trying 0xff <0,0>
considering [0, 0xff]
truncated region: [0, 0]; size 0x1 (requested 0x1)
candidate region: [0, 0], size 0x1
allocating from the beginning
pci0: domain=3D0, physical bus=3D0
found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00
domain=3D0, bus=3D0, slot=3D0, func=3D0
class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0
cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
intpin=3Da, irq=3D0
powerspec 3 supports D0 D3 current D0
secbus=3D1, subbus=3D1
rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: [0x1, =
0x1], length 0x1, flags 0, device (null)
rman_reserve_resource_bound: trying 0 <0x1,0>
rman_reserve_resource_bound: tried 0 <0x1,0>
considering [0x1, 0xff]
truncated region: [0x1, 0x1]; size 0x1 (requested 0x1)
candidate region: [0x1, 0x1], size 0x1
allocating from the beginning
pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
rman_manage_region: <pcib1 bus numbers> range 0..0xff : request: start =
0x1, end 0x1
pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
considering [0xc0000000, 0xffffffff]
truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested =
0x100000)
candidate region: [0xc0000000, 0xc00fffff], size 0x100000
allocating from the beginning
rman_manage_region: <pcib1 memory window> range 0..0xffffffff : request: =
start 0x600000000, end 0x6000fffff
panic: Failed to add resource to rman
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x38
vpanic() at vpanic+0x1a4
panic() at panic+0x48
pcib_add_window_resources() at pcib_add_window_resources+0xf4
pcib_alloc_window() at pcib_alloc_window+0xfc
pcib_attach_common() at pcib_attach_common+0xa18
pcib_attach() at pcib_attach+0x14
device_attach() at device_attach+0x3fc
device_probe_and_attach() at device_probe_and_attach+0x80
bus_generic_attach() at bus_generic_attach+0x1c
pci_attach() at pci_attach+0xec
device_attach() at device_attach+0x3fc
device_probe_and_attach() at device_probe_and_attach+0x80
bus_generic_attach() at bus_generic_attach+0x1c
device_attach() at device_attach+0x3fc
device_probe_and_attach() at device_probe_and_attach+0x80
bus_generic_new_pass() at bus_generic_new_pass+0x100
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_set_pass() at bus_set_pass+0x50
mi_startup() at mi_startup+0x1e0
virtdone() at virtdone+0x68
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at kdb_enter+0x4c: str xzr, [x19, #1280]
db>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Tue Feb 13 00:28: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 4TYhxq6BLgz59Jnw
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 00:28:15 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYhxq4l2Rz4dpS
for <freebsd-current@FreeBSD.org>; Tue, 13 Feb 2024 00:28:15 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707784095;
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=Ry4yxrGADBulMAWnHSuvKz9pQAwLBG3AwRiqUeBneUU=;
b=P5mBOtt0L6scTQTTOBf6MVvxbzbvUB/s+hVN+xcF3H/dI0Z5pe0s1GlKL/vnEBbfORnv5v
Uwcu8v4jbWEJ++aA02beXMHGZNEHNlc6DXJ83BOxKc3MGPwYaO4m4S3M8+GF12XkxRJ05c
OniHYJRf37Sa28oxXMqqDoFdNFaklxD2fhs1mHdq3z5Hsja5xAnO4XjxGooefZpGmUuwd5
y048/5H1y16fXqHemX/NLhVyVsricy29hQ+QqntgnJIh3EM57ZLD+2GdKB6x+tqTb5aR3y
AMpEarLs1dmGwmki59aIjM2nyh6mZ8IOzEp13hT0ZeAZRN+L1KCByBpGWAh8Cw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707784095; a=rsa-sha256; cv=none;
b=DWmPlLAcS9O+FMG4KBNBMKaWzwu/iYfhrN4KQLDDmtmU/X2cD969A1I7WVhcwSMJ4wUKyx
QN625Rd5yOlfwTJ2h0lfxcSsxLRFrVXX5dUTiLJ9+s87CMJDfFn0Lpzv8ryUNU2rKcj+th
J4/sd5/+XMGckiqWYbVQYVXaI43gMm8UOM3l/VTfMxO82Po7GQMF0QOnQzScFDwuh0xcpy
2UINlX4y78J7IshtAjH9Xn4FbidvHfskQQA34driW/0kELGyhTWIpUip5D97tTui7N2LeN
wLfZAUsDWpADD1nkFS39q6smsC3kJVh3AAuc1SrHC0j96wnBqIIrzAe/e7Qtgw==
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=1707784095;
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=Ry4yxrGADBulMAWnHSuvKz9pQAwLBG3AwRiqUeBneUU=;
b=Zis9FWPoy+7dgrwBuu02dk7tWkSJG6HKoUM8EHOIPC1FdqqYsB+hJNpm6hmesQQdoeD0/U
VBzrzwvD5QMbcVMWPcthNklJszuX/VuTLbMK0G00Y42VFeYIIZh4d37yooWEntmTj9LGJ4
RNCHIdLVV/fvf+IstX0ORh/ZZZxx4ycwaUEZAvsaknvXdeIKyHkHyl8nwg7HViNxG8RxfH
fASCCRusOZp2gvJWZ6FDHburpsmOBr2Krzi0OB6XpidSSVQwJmcyIUGSDeD/PtOErrdDip
DlAk/UuSgu91P3a8bHSkbLTyoXDzMbpT7jp+x6ysO0kYgT8o1InIRyLQG0LHDA==
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:cd45:5b11::2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: truckman)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYhxq1VJnzcJM
for <freebsd-current@FreeBSD.org>; Tue, 13 Feb 2024 00:28:15 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from dl (uid 1001)
(envelope-from truckman@FreeBSD.org)
id 22de5f
by gw.catspoiler.org (DragonFly Mail Agent v0.13 on mousie.catspoiler.org);
Mon, 12 Feb 2024 16:28:12 -0800
Date: Mon, 12 Feb 2024 16:28:10 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: nvme controller reset failures on recent -CURRENT
To: FreeBSD current <freebsd-current@FreeBSD.org>,
John Baldwin <jhb@FreeBSD.org>
Message-ID: <tkrat.edddc2469f43baf6@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Disposition: INLINE
I just upgraded my package build machine to:
FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
from:
FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
and I've had two nvme-triggered panics in the last day.
nvme is being used for swap and L2ARC. I'm not able to get a crash
dump, probably because the nvme device has gone away and I get an error
about not having a dump device. It looks like a low-memory panic
because free memory is low and zfs is calling malloc().
This shows up in the log leading up to the panic:
Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
nd possible hot unplug.
Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
nd possible hot unplug.
Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdog ti
meout.
The device looks healthy to me:
SMART/Health Information Log
============================
Critical Warning State: 0x00
Available spare: 0
Temperature: 0
Device reliability: 0
Read only: 0
Volatile memory backup: 0
Temperature: 312 K, 38.85 C, 101.93 F
Available spare: 100
Available spare threshold: 10
Percentage used: 3
Data units (512,000 byte) read: 5761183
Data units written: 29911502
Host read commands: 471921188
Host write commands: 605394753
Controller busy time (minutes): 32359
Power cycles: 110
Power on hours: 19297
Unsafe shutdowns: 14
Media errors: 0
No. error info log entries: 0
Warning Temp Composite Time: 0
Error Temp Composite Time: 0
Temperature 1 Transition Count: 5231
Temperature 2 Transition Count: 0
Total Time For Temperature 1: 41213
Total Time For Temperature 2: 0
From nobody Tue Feb 13 00:36:28 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 4TYj7h4WNCz59KTf
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 00:36:48 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYj7g3GDPz4gLh
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 00:36:47 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=OOQMW93e;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707784603; bh=FkLc1IgGFEAIaFWdUc50wyrkuti9yEW8yGO+SkPReDY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OOQMW93eqt1KXB+bdguy+m3dUdbqvE8VeA5UWs5ed9GGHhtV4Yy94re+qZzzW7LXcTNzSgjwp5SriOdCUDBpp0mIc3jX/r0LTl8Ox7+ZHOdpR4QS3Ts6Y7So/k4mS/c/aSPRYKUXsQuqKBIQsE8TeOfb/abmI0uQ1q9yk/Yoa3CIxmaIVLTnokknWB1ymu/XkE2GeP1Ee09bnCLQQ67QBhQQp/0nK+LWWUxEes5MH/fr+kPq6iXIRMujPOmWtaiHabDFklJh+G3pe2k60LsA02nz3gD4PeS/k9MD8bwMkIXDSBWCghVX59o1VrLomG4SziaLYclyuGjM9mFn78p5TQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707784603; bh=1GFWolNelIPabwY2vVZ5Apv+EHc1AaI8dBCFetbIP2y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l1Q0AO2O+0Bie6j1XEiyIzVBdttY4XhoyZCJNCWX6RfKuoh25o3vFJBDWahrQigjOaakxsliIu0jtX3wOtXjldbv26FEmfw2r1BEfZ1DXfZfb+k2rCgYsDDXppB0W5t5N1F0TjmcRLxU3HBYRoMPq8i57FMdsdLDsY2z47d4rmkSkVpaJpfuCNiN9eIiGmUgJbh52lMIaOPXcKGDjhbOiZ/jc7EILprfK8wIf4MeEWlc+p+EKc7ZgbAMg2vpLULJ+9YNr4rosxtKZtmMPHrZrXfDRwfWKwJe/DTU/M4zxOYm+de3OqgGo+VYDuv4r5zDbe70UtrbhXhSK7gicK/nBg==
X-YMail-OSG: ZiGa9cIVM1l956LKTBTsZv6B8Hh.R0Iw5ABN7k2iW4YW.KohnXHoS4XKMfuIHeD
uDHL7u_yZo_SnWp9vAq172RruIMa3jexBCOxAnvIOubf587MPN6AiSaLkhcFxQ6q6bGhqy4vLGei
ZhHWWJQ5fEJTqkUAPG_a3yISL6hmg8i9daZuvf18PuUHFKMa_67BfbcRSQSHxh7b1IQWe0oUBhiN
aQhHBd.YxbK_c7Fuzd9lD_pL.4TnwT8llehA_UqgRNlhlxx2nAH0bMMGVy7e7bsCcsD7ix3rRQ9Z
Gozzv4veqXgAZCOXIDUCQ1bUidUR1SUhxNRk7UX0lvrwi_xt8Ak_IxbXENvcqQT6usLbgK_BFXc1
OoaPEFX1ADmoRsskQHjZGH0Fuwcv5QHDNNms945TFyx69pUID5gLH_e7LQFizv1BL.p_uTQEm0uT
I58hcnaEUOGdgO9vGFC4Z55FEK4P2pB.q04y86oBrxNpmCu_kNs9i0ODIHIOKBkZ4Bsix8MnTm4_
9SuPIsL.WGxIjRTGLhu6i8s7OOKv8xEY0a6s35fWNTZQebdqs8DYvg9WYX4hRqCznq3OaW9lf04F
FSsFOWFPL8y0j1Nv5hFFjEGyCpHdXLsPIEarAHHE0NdUDrbFNUjfT80Tr1rwEEOscWIJBbVi.6JY
LqwR3iPpiZD4N.xICljXM173MHw5kQVRSqfQlB.CaQtwF9TzK_jKD3N2KsLwJlK7NLd5jcOybqDg
q6Gc77gsO.MAXyGe3R68u7VlPAuiNmrkhhuqwvIxLps3dc5TYiObkpUSdj8Ic1zuztHnUJmZGUPG
tbZ.1u89V1UQN_uUlYllbvy0lDv2sZhcai52p6TgecSr6pm_82rjwF44GP.k56nHd.8xDpFOEi6_
rZmXYdzRkrRiqnNefeaxiiBbTE2pn2NMGegYtFLIg1r9HBhmrWC7CUhHPzfOse1mgQatFqcQ9jlc
F8FcZgprYR9xvlq7PBBNRo7jeX5uFUD1QVEf5Qk7bqVMWO9mziIyIAhRII8GqoX23hNX7mG8vLzT
jDE25Qg.dPJj93h7xCXOtDO7sKarvIvnisIqoGMEC4RDmvI6DW60L3zZnP0SaVCz9uDd08Nnhids
4vlWQAA_u_MJ9WWThL907CXQ2Pvh802MvHtSf2s10FH9ssylejLOKYGNjZRYg3SIkeNObr6Equjl
y47km6Y7AUMA1jpi3PvfU9MDLoGKm4EtxuP8NRbixrsBfydK3bh1Yq4zi3DXAt1h9_1drCwhJKMO
HGcHPsChrTrmM6jIDskF6UMKGwPq1IcMaXBJMBrXNrdZCXeZ4jhucPq7fYc2D_tlBza7qO5UdIE2
DORAd96Dpi87B5Z_mYIVa1RM6J43bJn1g4gRw37N4lmhkl4eSnGpLPXi7eocyvTSnGzrRfbZqZP0
24OIYgHV6AMw6E7kZbqFzykZOO7vZtIQMCHOs3bKy6BcqAEgvW1fOzgGCIzb_3nOFXhNO2i64o66
zQ0i7mk03ktAcEJiDz_6LH94UJRxl7jpogrlwbpm.SgmReewrkFjbe5cP2NHKj3TU3rIsBJAMhCT
krwHbzCdMHI2FO8t.eI3L5TuBq6sjGcA1uk7iq05Ezvv_df8R5dcVAg48VaS_whBM26H_OVjnEtC
78OOiYNXD_sDSCYkb7eNXzvT64.FCw7ZzUsSGDpYRPDb1wTyH0KNoVrkl9rnK9Y9YPL8KqgoLSIk
UsIuxR0pw86tYN_3EZPPmYUlN71n4NEPIi_4pEOtq12aiByR.npH029S0egKnuHdGhQIdz9aQ5vJ
A9.Im5byzafyt.A6ywCJnxO2JyJLPKOqatM5oZdAMFJNN3XsPPdYphi6r7evRJPtUMbdbh7jaLaa
Q6DSri_vd5VaBYnKSbei29gD5vP1QkMnWG3cEnsGauDenVqSTklWGpKn_MwNg5vVYb7gEHLTmsmy
JFxzphMUdTxN3MP6IYXTYCLWvwnoZOv.bao.6FuDnyOXLIkDTYG5WGoBVnYYHZUWmjl0nD8wJLVK
kviJPu64nVCXQBsZGndUT9BDUGgujAfgHBVPhLy2XNe_WAW1uVTCnovEe7b_7TXYgoJT11rRgt00
etdcksN9NOX_XlIXAKbpIAzwqfzxfTVWs.mHp5sRPfJ9IPJkTdujdx7A6AwZgX84h0L1GxAEAVJ_
XG7Rdn8.nsNuKLKD_WLwGahgEC0NF8GKRhXQ16OSjH3ElPvxwfqeD58wnYT84LF4x4ktnF6FVUZd
hr1onHqyZ0irqqKj2kTXyo_TX28.ooaSy5BWrlpYbgwktN513bbc_2ISiixYf05jlmj1axPT_nYu
WwQ--
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: a4421fc4-f21c-43f3-9c72-84142ed6a712
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Feb 2024 00:36:43 +0000
Received: by hermes--production-gq1-5c57879fdf-c7xks (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2ad79929a038886e274ede3c44f9d34d;
Tue, 13 Feb 2024 00:36:39 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
Date: Mon, 12 Feb 2024 16:36:28 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4TYj7g3GDPz4gLh
On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> [Gack: I was looking at the wrong vintage of source code, predating
>> your changes: wrong system used.]
>>=20
>>=20
>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>=20
>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>=20
>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>> Summary:
>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>> pcib0: parsing FDT for ECAM0:
>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>> . . .
>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>> panic: Failed to add resource to rman
>>>>=20
>>>> Hmmm, I suspect this is due to the way that bus_translate_resource =
works which is
>>>> fundamentally broken. It rewrites the start address of a resource =
in-situ instead
>>>> of keeping downstream resources separate from the upstream =
resources. For example,
>>>> I don't see how you could ever release a resource in this design =
without completely
>>>> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
>>>> translating bridge that uses the current approach should corrupt =
the allocated
>>>> resource ranges in an rman long before my changes.
>>>>=20
>>>> That said, that doesn't really explain the panic. Hmm, the panic =
might be because
>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>>>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>>>=20
>>>>> Detail:
>>>>> . . .
>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>> pcib0: parsing FDT for ECAM0:
>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>=20
>>>> This indicates this is a translating bus.
>>>>=20
>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end =
0x1
>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>> rman_reserve_resource_bound: trying 0xffffffff =
<0xc0000000,0xfffff>
>>>>> considering [0xc0000000, 0xffffffff]
>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 =
(requested 0x100000)
>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>> allocating from the beginning
>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>=20
> What you later typed does not match:
>=20
> 0x600000000
> 0x6000fffff
>=20
> You later typed:
>=20
> 0x60000000
> 0x600fffffff
>=20
> This seems to have lead to some confusion from using the
> wrong figure(s).
>=20
>>>> The fact that we are trying to reserve the CPU addresses in the =
rman is because
>>>> bus_translate_resource rewrote the start address in the resource =
after it was allocated.
>>>>=20
>>>> That said, I can't see why rman_manage_region would actually fail. =
At this point the
>>>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>>>> so only the check that should be failing are the checks against =
rm_start and
>>>> rm_end. For the memory window, rm_start is always 0, and rm_end is =
always
>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>>>> ranges are within those bounds.
>=20
> No:
>=20
> 0xffffffff
>=20
> .vs (actual):
>=20
> 0x600000000
> 0x6000fffff
>=20
> Both the actuals are larger then the 0xffffffff figure you list above.
>=20
> I've no clue if the 0xffffffff might have its own typos.
>=20
>>>> I would instead expect to see some other issue later
>>>> on where we fail to allocate a resource for a child BAR, but I =
wouldn't expect
>>>> rman_manage_region to fail.
>>>>=20
>>>> Logging the return value from rman_manage_region would be the first =
step I think
>>>> to see which error value it is returning.
>>>=20
>>> Looking at the code in sys/kern/subr_rman.c for rman_manage_region I =
see
>>> the (mostly) return rv related logic only has ENONMEM (explicit =
return) and
>>> EBUSY as non-0 possibilities (no other returns).
>>=20
>> The modern code also has EINVAL via an explicit return.
>>=20
>>> All the rv references and
>>> all the returns are shown below:
>>>=20
>>> int rv =3D 0;
>>> . . .
>>=20
>> The modern code also has here:
>>=20
>> DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
>> rm->rm_descr, start, end));
>> if (start < rm->rm_start || end > rm->rm_end)
>> return EINVAL;
>>=20
>> Adding rm->rm_start and rm->rm_end to the message might be
>> appropriate --and would also be enough additional information
>> to know if EINVAL would be returned.
>=20
> I added such code and built, installed, and tried booting
> a separate kernel. The result was:
>=20
> rman_manage_region: <pcib1 memory window> range 0..0xffffffff : =
request: start 0x600000000, end 0x6000fffff
> panic: Failed to add resource to rman
>=20
> So:
>=20
> 0
> vs. start:
> 0x600000000
>=20
> and:
>=20
> 0xffffffff
> vs. end:
> 0x6000fffff
>=20
> The 0x600000000..0x6000fffff range is not a range of RAM addresses
> [too large for that for the 8 GiByte RPi4B] and, so, is well above
> the 32 bit boundary too.
>=20
> That is the only line referencing "memory window". A 32 bit initial =
range
> for some reason. For reference, the source change in question was:
>=20
> - DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
> - rm->rm_descr, start, end));
> + DPRINTF(("rman_manage_region: <%s> range %#jx..%#jx : request: =
start %#jx, end %#jx\n",
> + rm->rm_descr, rm->rm_start, rm->rm_end, start, end));
> if (start < rm->rm_start || end > rm->rm_end)
> return EINVAL;
>=20
> I'll show a larger boot output context at the bottom of the message
> for reference.
>=20
>>> r =3D int_alloc_resource(M_NOWAIT);
>>> if (r =3D=3D NULL)
>>> return ENOMEM;
>>> . . .
>>> /* Check for any overlap with the current region. */
>>> if (r->r_start <=3D s->r_end && r->r_end >=3D =
s->r_start) {
>>> rv =3D EBUSY;
>>> goto out;
>>> }
>>>=20
>>> /* Check for any overlap with the next region. */
>>> t =3D TAILQ_NEXT(s, r_link);
>>> if (t && r->r_start <=3D t->r_end && r->r_end >=3D =
t->r_start) {
>>> rv =3D EBUSY;
>>> goto out;
>>> }
>>> . . .
>>> out:
>>> mtx_unlock(rm->rm_mtx);
>>> return rv;
>>>=20
>>> int_alloc_resource failure would be failure (NULL) from the:
>>>=20
>>> struct resource_i *r;
>>>=20
>>> r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO);
>>>=20
>>> (associated with the M_NOWAIT argument).
>>>=20
>>> The malloc failure would likely go in a very different direction.
>>>=20
>>>=20
>>>=20
>>> Side note: looks like the EBUSY cases leak what r references.
>>=20
>> Still true in the newer code.
>>=20
>>>> Probably I should fix pci_host_generic.c to handle translation =
properly however.
>>>> I can work on a patch for that.
>>>=20
>=20
> For reference:
>=20
> . . .
> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: Bus is not cache-coherent
> rman_reserve_resource_bound: <I/O memory addresses> request: =
[0xfd500000, 0xfd50930f], length 0x9310, flags 100, device pcib0
> rman_reserve_resource_bound: trying 0x1fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x1fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x31bfffff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x33298fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39bf1fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c02fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c06fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c07fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c08fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c2afff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c36fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x39c37fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3b03ffff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3b04ffff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3b2fffff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3ee61fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3ee63fff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0x3fffffff <0xfd500000,0x930f>
> rman_reserve_resource_bound: tried 0xfbffffff <0xfd500000,0x930f>
> considering [0xfc000000, 0xfd5d1fff]
> truncated region: [0xfd500000, 0xfd50930f]; size 0x9310 (requested =
0x9310)
> candidate region: [0xfd500000, 0xfd50930f], size 0x9310
> splitting region in three parts: [0xfc000000, 0xfd4fffff]; =
[0xfd500000, 0xfd50930f]; [0xfd509310, 0xfd5d1fff]
> rman_manage_region: <PCIe Memory> range 0..0xffffffffffffffff : =
request: start 0xc0000000, end 0xffffffff
> pcib0: hardware identifies as revision 0x304.
> pcib0: note: reported link speed is 5.0 GT/s.
> rman_reserve_resource_bound: <Interrupts> request: [0x51, 0x51], =
length 0x1, flags 0, device pcib0
> rman_reserve_resource_bound: trying 0 <0x51,0>
> rman_reserve_resource_bound: tried 0 <0x51,0>
> rman_reserve_resource_bound: tried 0x1 <0x51,0>
> rman_reserve_resource_bound: tried 0x2 <0x51,0>
> rman_reserve_resource_bound: tried 0x3 <0x51,0>
> rman_reserve_resource_bound: tried 0x4 <0x51,0>
> rman_reserve_resource_bound: tried 0x5 <0x51,0>
> rman_reserve_resource_bound: tried 0x6 <0x51,0>
> rman_reserve_resource_bound: tried 0x7 <0x51,0>
> rman_reserve_resource_bound: tried 0xc <0x51,0>
> rman_reserve_resource_bound: tried 0xd <0x51,0>
> rman_reserve_resource_bound: tried 0xe <0x51,0>
> rman_reserve_resource_bound: tried 0xf <0x51,0>
> rman_reserve_resource_bound: tried 0x10 <0x51,0>
> rman_reserve_resource_bound: tried 0x11 <0x51,0>
> rman_reserve_resource_bound: tried 0x12 <0x51,0>
> rman_reserve_resource_bound: tried 0x17 <0x51,0>
> rman_reserve_resource_bound: tried 0x18 <0x51,0>
> rman_reserve_resource_bound: tried 0x1a <0x51,0>
> rman_reserve_resource_bound: tried 0x1b <0x51,0>
> rman_reserve_resource_bound: tried 0x22 <0x51,0>
> rman_reserve_resource_bound: tried 0x23 <0x51,0>
> rman_reserve_resource_bound: tried 0x24 <0x51,0>
> rman_reserve_resource_bound: tried 0x25 <0x51,0>
> rman_reserve_resource_bound: tried 0x26 <0x51,0>
> rman_reserve_resource_bound: tried 0x27 <0x51,0>
> rman_reserve_resource_bound: tried 0x28 <0x51,0>
> rman_reserve_resource_bound: tried 0x29 <0x51,0>
> rman_reserve_resource_bound: tried 0x4e <0x51,0>
> rman_reserve_resource_bound: tried 0x4f <0x51,0>
> considering [0x50, 0xffffffffffffffff]
> truncated region: [0x51, 0x51]; size 0x1 (requested 0x1)
> candidate region: [0x51, 0x51], size 0x1
> splitting region in three parts: [0x50, 0x50]; [0x51, 0x51]; [0x52, =
0xffffffffffffffff]
> pci0: <OFW PCI bus> on pcib0
> rman_manage_region: <PCI domain 0 bus numbers> range 0..0xff : =
request: start 0, end 0xff
> rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: [0, =
0], length 0x1, flags 0, device pci0
> rman_reserve_resource_bound: trying 0xff <0,0>
> considering [0, 0xff]
> truncated region: [0, 0]; size 0x1 (requested 0x1)
> candidate region: [0, 0], size 0x1
> allocating from the beginning
> pci0: domain=3D0, physical bus=3D0
> found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00
> domain=3D0, bus=3D0, slot=3D0, func=3D0
> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0
> cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
> intpin=3Da, irq=3D0
> powerspec 3 supports D0 D3 current D0
> secbus=3D1, subbus=3D1
> rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: [0x1, =
0x1], length 0x1, flags 0, device (null)
> rman_reserve_resource_bound: trying 0 <0x1,0>
> rman_reserve_resource_bound: tried 0 <0x1,0>
> considering [0x1, 0xff]
> truncated region: [0x1, 0x1]; size 0x1 (requested 0x1)
> candidate region: [0x1, 0x1], size 0x1
> allocating from the beginning
> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
> rman_manage_region: <pcib1 bus numbers> range 0..0xff : request: start =
0x1, end 0x1
> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
> considering [0xc0000000, 0xffffffff]
> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested =
0x100000)
> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
> allocating from the beginning
> rman_manage_region: <pcib1 memory window> range 0..0xffffffff : =
request: start 0x600000000, end 0x6000fffff
> panic: Failed to add resource to rman
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> vpanic() at vpanic+0x1a4
> panic() at panic+0x48
> pcib_add_window_resources() at pcib_add_window_resources+0xf4
> pcib_alloc_window() at pcib_alloc_window+0xfc
> pcib_attach_common() at pcib_attach_common+0xa18
> pcib_attach() at pcib_attach+0x14
> device_attach() at device_attach+0x3fc
> device_probe_and_attach() at device_probe_and_attach+0x80
> bus_generic_attach() at bus_generic_attach+0x1c
> pci_attach() at pci_attach+0xec
> device_attach() at device_attach+0x3fc
> device_probe_and_attach() at device_probe_and_attach+0x80
> bus_generic_attach() at bus_generic_attach+0x1c
> device_attach() at device_attach+0x3fc
> device_probe_and_attach() at device_probe_and_attach+0x80
> bus_generic_new_pass() at bus_generic_new_pass+0x100
> bus_generic_new_pass() at bus_generic_new_pass+0xb0
> bus_generic_new_pass() at bus_generic_new_pass+0xb0
> bus_generic_new_pass() at bus_generic_new_pass+0xb0
> bus_set_pass() at bus_set_pass+0x50
> mi_startup() at mi_startup+0x1e0
> virtdone() at virtdone+0x68
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at kdb_enter+0x4c: str xzr, [x19, #1280]
> db>=20
>=20
FYI:
bcm2711-peripherals.pdf "Figure 1. BCM2711 Address Maps"
documents the PCIe address space range as (their "_"
notation):
0x6_0000_0000..0x7_FFFF_FFFF
for both of the address maps:
'Full 35-bit Address Map'
'ARM view of the Address Map in "Low Peripheral" mode'
The Low Peripheral mode is what is in use.
So the 0x6_0000_0000..0x6_000f_ffff range looks
to be a valid ARM system address space for the
PCIe to map to.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Tue Feb 13 00:58:09 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 4TYjcV0CTsz59Mmg
for <current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 00:58:18 +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 4TYjcS6LYxz4kPM
for <current@freebsd.org>; Tue, 13 Feb 2024 00:58:16 +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 41D0w9l0093933;
Tue, 13 Feb 2024 02:58:12 +0200 (EET)
(envelope-from kib@freebsd.org)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 41D0w9l0093933
Received: (from kostik@localhost)
by tom.home (8.18.1/8.18.1/Submit) id 41D0w9Kh093932;
Tue, 13 Feb 2024 02:58:09 +0200 (EET)
(envelope-from kib@freebsd.org)
X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f
Date: Tue, 13 Feb 2024 02:58:09 +0200
From: Konstantin Belousov <kib@freebsd.org>
To: Alexander Leidinger <alexleidingerde@gmail.com>
Cc: current@freebsd.org
Subject: Re: segfault in ld-elf.so.1
Message-ID: <Zcq-oU_4X7o_TfND@kib.kiev.ua>
References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
<CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
<ZcnqtY0dQoed9yjw@kib.kiev.ua>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZcnqtY0dQoed9yjw@kib.kiev.ua>
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 [-2.34 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.34)[-0.340];
DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none];
MIME_GOOD(-0.10)[text/plain];
RCPT_COUNT_TWO(0.00)[2];
HAS_XAW(0.00)[];
ARC_NA(0.00)[];
FREEFALL_USER(0.00)[kib];
ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
TO_DN_SOME(0.00)[];
MIME_TRACE(0.00)[0:+];
FREEMAIL_TO(0.00)[gmail.com];
R_DKIM_NA(0.00)[];
MLMMJ_DEST(0.00)[current@freebsd.org];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
R_SPF_SOFTFAIL(0.00)[~all];
RCVD_COUNT_TWO(0.00)[2];
RCVD_TLS_LAST(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
MISSING_XM_UA(0.00)[]
X-Rspamd-Queue-Id: 4TYjcS6LYxz4kPM
On Mon, Feb 12, 2024 at 11:54:02AM +0200, Konstantin Belousov wrote:
> On Mon, Feb 12, 2024 at 10:35:56AM +0100, Alexander Leidinger wrote:
> > Hi,
> >
> > dovecot (and no other program I use on this machine... at least not that I
> > notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
> > to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
> > have been fixed by changes to libc/libsys since 2024-02-10-144617). The
> > issue shows up when I try to do an IMAP login. A successful authentication
> > starts the imap process which immediately segfaults.
> >
> > I didn't recompile dovecot for the initial update, but I did now to rule
> > out a regression in this area (and to get access via imap do my normal mail
> > account).
> >
> >
> > Backtrace:
> The backtrace looks incomplete. It might be the case of infinite recursion,
> but I cannot claim it from the trace.
>
> Does the program segfault if you run it manually? If yes, please provide
> me with the tarball of the binary and all required shared libs, including
> base system libraries, from your machine.
Regardless of my request, you might try the following. Note that I did
not tested the patch, ensure that you have a way to recover ld-elf.so.1
if something goes wrong.
diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
index 24abc4580f53..2ff6455c87fc 100644
--- a/libexec/rtld-elf/rtld.c
+++ b/libexec/rtld-elf/rtld.c
@@ -2583,7 +2583,7 @@ static void
load_filtees(Obj_Entry *obj, int flags, RtldLockState *lockstate)
{
- if (!obj->filtees_loaded) {
+ if (!obj->filtees_loaded && (flags & RTLD_LO_NOFILTEES) == 0) {
lock_restart_for_upgrade(lockstate);
load_filtee1(obj, obj->needed_filtees, flags, lockstate);
load_filtee1(obj, obj->needed_aux_filtees, flags, lockstate);
@@ -4479,6 +4479,7 @@ get_program_var_addr(const char *name, RtldLockState *lockstate)
symlook_init(&req, name);
req.lockstate = lockstate;
+ req.flags |= SYMLOOK_VAR;
donelist_init(&donelist);
if (symlook_global(&req, &donelist) != 0)
return (NULL);
@@ -4690,6 +4691,22 @@ symlook_needed(SymLook *req, const Needed_Entry *needed, DoneList *dlp)
return (ESRCH);
}
+static int
+symlook_obj_load_filtees(SymLook *req, SymLook *req1, const Obj_Entry *obj,
+ Needed_Entry *needed)
+{
+ DoneList donelist;
+ int flags, res;
+
+ flags = (req->flags & SYMLOOK_EARLY) != 0 ? RTLD_LO_EARLY : 0;
+ flags |= (req->flags & SYMLOOK_VAR) != 0 ? RTLD_LO_NOFILTEES : 0;
+ load_filtees(__DECONST(Obj_Entry *, obj), flags, req->lockstate);
+ donelist_init(&donelist);
+ symlook_init_from_req(req1, req);
+ res = symlook_needed(req1, needed, &donelist);
+ return (res);
+}
+
/*
* Search the symbol table of a single shared object for a symbol of
* the given name and version, if requested. Returns a pointer to the
@@ -4702,9 +4719,8 @@ symlook_needed(SymLook *req, const Needed_Entry *needed, DoneList *dlp)
int
symlook_obj(SymLook *req, const Obj_Entry *obj)
{
- DoneList donelist;
SymLook req1;
- int flags, res, mres;
+ int res, mres;
/*
* If there is at least one valid hash at this point, we prefer to
@@ -4719,11 +4735,8 @@ symlook_obj(SymLook *req, const Obj_Entry *obj)
if (mres == 0) {
if (obj->needed_filtees != NULL) {
- flags = (req->flags & SYMLOOK_EARLY) ? RTLD_LO_EARLY : 0;
- load_filtees(__DECONST(Obj_Entry *, obj), flags, req->lockstate);
- donelist_init(&donelist);
- symlook_init_from_req(&req1, req);
- res = symlook_needed(&req1, obj->needed_filtees, &donelist);
+ res = symlook_obj_load_filtees(req, &req1, obj,
+ obj->needed_filtees);
if (res == 0) {
req->sym_out = req1.sym_out;
req->defobj_out = req1.defobj_out;
@@ -4731,11 +4744,8 @@ symlook_obj(SymLook *req, const Obj_Entry *obj)
return (res);
}
if (obj->needed_aux_filtees != NULL) {
- flags = (req->flags & SYMLOOK_EARLY) ? RTLD_LO_EARLY : 0;
- load_filtees(__DECONST(Obj_Entry *, obj), flags, req->lockstate);
- donelist_init(&donelist);
- symlook_init_from_req(&req1, req);
- res = symlook_needed(&req1, obj->needed_aux_filtees, &donelist);
+ res = symlook_obj_load_filtees(req, &req1, obj,
+ obj->needed_aux_filtees);
if (res == 0) {
req->sym_out = req1.sym_out;
req->defobj_out = req1.defobj_out;
diff --git a/libexec/rtld-elf/rtld.h b/libexec/rtld-elf/rtld.h
index e8b15095812b..77776f241290 100644
--- a/libexec/rtld-elf/rtld.h
+++ b/libexec/rtld-elf/rtld.h
@@ -298,6 +298,7 @@ TAILQ_HEAD(obj_entry_q, Struct_Obj_Entry);
#define SYMLOOK_EARLY 0x04 /* Symlook is done during initialization. */
#define SYMLOOK_IFUNC 0x08 /* Allow IFUNC processing in
reloc_non_plt(). */
+#define SYMLOOK_VAR 0x10
/* Flags for load_object(). */
#define RTLD_LO_NOLOAD 0x01 /* dlopen() specified RTLD_NOLOAD. */
@@ -309,6 +310,8 @@ TAILQ_HEAD(obj_entry_q, Struct_Obj_Entry);
initialization during the image start. */
#define RTLD_LO_IGNSTLS 0x40 /* Do not allocate static TLS */
#define RTLD_LO_DEEPBIND 0x80 /* Force symbolic for this object */
+#define RTLD_LO_NOFILTEES 0x100 /* Skip loading filtees, sym resolution
+ from dlopen() */
/*
* Symbol cache entry used during relocation to avoid multiple lookups
From nobody Tue Feb 13 01:52: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 4TYkpj1dw7z59TGD
for <current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 01:52:13 +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 4TYkph34wBz4rc3
for <current@freebsd.org>; Tue, 13 Feb 2024 01:52:12 +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 41D1q5Y5008283;
Tue, 13 Feb 2024 03:52:08 +0200 (EET)
(envelope-from kib@freebsd.org)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 41D1q5Y5008283
Received: (from kostik@localhost)
by tom.home (8.18.1/8.18.1/Submit) id 41D1q5Aa008282;
Tue, 13 Feb 2024 03:52:05 +0200 (EET)
(envelope-from kib@freebsd.org)
X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f
Date: Tue, 13 Feb 2024 03:52:05 +0200
From: Konstantin Belousov <kib@freebsd.org>
To: Alexander Leidinger <alexleidingerde@gmail.com>
Cc: current@freebsd.org
Subject: Re: segfault in ld-elf.so.1
Message-ID: <ZcrLRUuKwQ-Md4x-@kib.kiev.ua>
References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
<CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
<ZcnqtY0dQoed9yjw@kib.kiev.ua>
<Zcq-oU_4X7o_TfND@kib.kiev.ua>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zcq-oU_4X7o_TfND@kib.kiev.ua>
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 [-2.99 / 15.00];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.99)[-0.991];
DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none];
MIME_GOOD(-0.10)[text/plain];
RCPT_COUNT_TWO(0.00)[2];
HAS_XAW(0.00)[];
ARC_NA(0.00)[];
FREEFALL_USER(0.00)[kib];
ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
TO_DN_SOME(0.00)[];
MIME_TRACE(0.00)[0:+];
FREEMAIL_TO(0.00)[gmail.com];
MLMMJ_DEST(0.00)[current@freebsd.org];
RCVD_TLS_LAST(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
R_DKIM_NA(0.00)[];
R_SPF_SOFTFAIL(0.00)[~all:c];
RCVD_COUNT_TWO(0.00)[2];
TO_MATCH_ENVRCPT_SOME(0.00)[];
MISSING_XM_UA(0.00)[]
X-Rspamd-Queue-Id: 4TYkph34wBz4rc3
On Tue, Feb 13, 2024 at 02:58:14AM +0200, Konstantin Belousov wrote:
> On Mon, Feb 12, 2024 at 11:54:02AM +0200, Konstantin Belousov wrote:
> > On Mon, Feb 12, 2024 at 10:35:56AM +0100, Alexander Leidinger wrote:
> > > Hi,
> > >
> > > dovecot (and no other program I use on this machine... at least not that I
> > > notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
> > > to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
> > > have been fixed by changes to libc/libsys since 2024-02-10-144617). The
> > > issue shows up when I try to do an IMAP login. A successful authentication
> > > starts the imap process which immediately segfaults.
> > >
> > > I didn't recompile dovecot for the initial update, but I did now to rule
> > > out a regression in this area (and to get access via imap do my normal mail
> > > account).
> > >
> > >
> > > Backtrace:
> > The backtrace looks incomplete. It might be the case of infinite recursion,
> > but I cannot claim it from the trace.
> >
> > Does the program segfault if you run it manually? If yes, please provide
> > me with the tarball of the binary and all required shared libs, including
> > base system libraries, from your machine.
>
> Regardless of my request, you might try the following. Note that I did
> not tested the patch, ensure that you have a way to recover ld-elf.so.1
> if something goes wrong.
Or better https://reviews.freebsd.org/D43858
From nobody Tue Feb 13 01:57:54 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 4TYkxd65hqz59V7g
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 01:58:13 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYkxc37Njz4snd
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 01:58:12 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=UQpVBNSh;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707789490; bh=yFdUWVGnKaC0hJq5OciUhv7RAE1dQWRhgaCkqTdoQmg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UQpVBNShUOYbXGYAon+rZcyxmqG1Vy0nYUQrWeXJ9MrljXEmBJG5QHc51ZKBJmdX/Qfw8cTL0hDU0ra35dIPJ/PVGJKtoOJMskaIDF8F5UzttNCkW+Mik2r3bk7FH/UqdD55e6H4m8pv6aTahZFnIE/jHAhtNUC/gzHpX1J4U4y2bYSc4PSfgpV7/81PhPviXFbAczHJFqUeX6DUBuwzExRUJiZVluFvtcMS72aoKI+39g4UGKFpsqm1WihBXxiSj7Bsx7iw94fj9RLpsn0P4bp3KfnSwOTlSAUk+mIwhr7rgec8S1XiKUcXB3mTbaYPzz6BM2/pYsX8Cj64dmyF2g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707789490; bh=UDt+I4D1OB/a7Jn4SUOBZVGxyvjYDHrK4/acf3Gqpqd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FOacDyF+Th9Fv+zMUOYQIGUMNuOD+Vjzn13XiigrLTUQw4HixqeL5q4vPUxMHsB+hlHCYS9laJ4w+2H8BqPFBW8Hu3dn6HJJx2S1iYa2Av0dXi38FlR4HwOBrf14eL+c9MfeYBRnZR1aqfPHtnt/sHiux30i7fqY++CAHs23MgnQA+UxL6RqY0sFc9hWfKJiGTX2WOiQ4sJETj5GASDOn983J2fHZL6lcdpEWpsHffxP1HKqnZku0a3+njig0i54StXjPngtVnDENtvVX8nlhBB1+8sqH5EVnexPo+XiPXhRWH9Fb7tbPbIk+z6O5zQHXIwzAolHFMwRFjbi7qFKwQ==
X-YMail-OSG: WCeifLsVM1lRuZdxXxFjvlwTzuKew4d5K85ZvXCj5sr5uhrhzXs8C1dtuI4ulJa
LH8GLPqBXT0u._3gi09JEL_445n_7WdGxbXdRB26iaR5AfQSv5cZQ0NBwpRUyREvEFOh3Bc_GIxi
IchSR97jQf9z3B1wouusBqwOQLQUh8U3Lq.yluPn0PuMWGZ.be1o2CY28jg2Oae2Og4E1E5YP5Ys
ifYxua6zleuOjaV3KGzvsxgA0lUvrON9ZQwfzloqkRHlFGyFkmZ3YMZcr82D5NJhh93kWvmAa_fY
uF25qpuunxL8eRAoPrVj.1oUBH2XHHcXe7rB0HM8FElx_25x.zUuqSwrUlVEKTku60RED5QI5ibo
s3Zgs66Yc2tShn5_Gb3HtZtHQZZMLorkNYCnaXnPnLRfgLt2KgDrkJ.c3KGo8Hx6fksgPLUfAP_5
oE.Hwf4nIGEpBwqFxPFvVsOocY5MfmaQanbM7vfpVgRaFlvxLk48XXcqil9JUmlVlUV7CIGZaf.1
PyVMznuCDUy1Aaq0rAZCackajthIKvlKrMAJNRSRpeMGQn2Dy7rZ.RU1YSGBe1P7Dmaf8qHzFM4E
qWL6hr3ERwtgmsDoL5uLEbbAnmh9C97rqV2Xi56Wh_Gu9Ctj07YTOJsNq2ts8rxDfgqdHqhDOmh3
9dDeFv9AJf0zGFXCbww06WGkuFODmyPqs3JCnkl8OjSubKPVEnjtYLgG0CMJCG6ufdnCkcv1yc2K
zPmZvLTzVLeUDhR2tmJ4y2TcesCLG.nu3ICGtzbJ.WPhE1hJRE6GBr3cNqLtfh30ySz._4zawfJX
i3IcbVeXTgWAyh9sXf8vj11DrRuC1jT2oLxkSI3PjExrWg5D.mdMNqW0bo1QF4jg1oLFp8mF9hD1
B3CxVXPmAAZ2CnnK0BoRYWh2Qpb.C8WnOEVJs0qvnEpKe3Nl.goBLEKImqN2K3.sLxOtR6sVQcoN
wyh9N94aMr1WrUe8hPfiNooJBhhwJyh86nXXVXSwCa50QPZabymW0UAKy97gEosWjBgUelAVYcZx
NMUs1TsGYHlB7oQwRR.P6BK6p2ZJ0sCuHuHJFrOdFvCWHUo0ywSIM4JqQLpAIYSdGUZ3vGh5gU.B
COUdfU2bz2v44h803u3Q.AoK77y1RlJD5zSIupKC6VpB1bXYdAM.DuaPz4zwLT3PhaKXMupvOiEy
GoSgfENF1dC.iYcT3uyQJy1hDzPgSxuiamPhvhg_d6NAqJE2EVHR2MdFHZA6mfgf5HJR1eanV3nm
rhFoXIxtkwbYb0O4thO.F5dhyc6zwCIjwYv8xB40nw.qb_fREBFGsLZanvX6UTXD9DIOruRWa1T.
AlXzUZuq4CFvfQXZR7oGgeuR4H58HqQJB1DanbB6wWB.NxQ5WWFYfzPHSaEwQGmNZx_H786LzXJK
cqOEsVmnGnwtEOxRH6xOVjagJiW5WWzglZinIvk6MFVBOeDM9XUJQnZ4ssiujoEvzlT1Xxtm.TQG
xXKNj8XxxfWaomRJg_MUdfES0.4iiAWqgRBXCKCbX_LsqLQDxlN_jh1yHLS8JttBGwSqijlprYXo
etvS5KJaagHP9JzIuGAPHdqiKCTqsr0aA.eCPb7NIJH8YzybidPl.v1m.6imUUGO5iNEYPS_wSTf
6UFKx79gfD4e9XNi8JWUbP.J8W.Xx.9uUjlU5gJVGfjw_vPBuz2RlA.MqakbTMIJlMSD1NXoKn2S
iOWAfrXR1dtZmJVmYC61FXZ2vIPPABSAHDeRFyI_BRd8dhBt5V59lDvrhYR3hJWXiBLyXNR5Ybpn
OJ_fP07Fs7HD3Huwpst5er1RJ33a1xxOdvKG6HRr4Oo_g19pPJ_Fsj8iIS4.0CCNBGKUvPvtY6a.
8VgYQ0CqelObqb8JP6j_c5UEiDYePlH2VC7R.Nyjz0hRibtGXKqGdJ6VgAOxOe_9J0wj60puJUY.
vRhZX1pHTPdXGk0OB25SxShV.Qa3S4Tp5TApJ7HPNB2gNlBJBE7jkrJn.AcZxoUCKHII4hei5843
ifzYC_4tatcK9bpuNlcRPl_sOLtSI0EZPeSn5R1rvY_tembs7Zj_3rnMoix0qIhzpwgZOu1N85Nw
rYciNCmQtMhk2diGU5POsuiBCmSWtQ593OlX40TNf22r1GIZrQfgdoJnJU.pvlPdWpGgz2jslI81
6qrAGmXJJkc_7Y8Z1rO2caQ4nQD5N9oh_Q32sEUukh6tOcBLvquUu1XzYI_HBX29FtlKKwx9abyu
yJV.5TITw2s6MbyOpD0xRhIwTmgC7udr7L1AsXLD1XwDrbTK_Mm.fxNqTkT__zz_bvmlNSPkG3x8
88GE-
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: db472841-ae12-47c3-a723-2fc5cedf1274
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Feb 2024 01:58:10 +0000
Received: by hermes--production-gq1-5c57879fdf-27p5r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ae8256dfa2d8bb9483f05df3dc891bec;
Tue, 13 Feb 2024 01:58:05 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
Date: Mon, 12 Feb 2024 17:57:54 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from];
RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]
X-Rspamd-Queue-Id: 4TYkxc37Njz4snd
On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>=20
>>> [Gack: I was looking at the wrong vintage of source code, predating
>>> your changes: wrong system used.]
>>>=20
>>>=20
>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>=20
>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>> Summary:
>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>> . . .
>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>>> panic: Failed to add resource to rman
>>>>>=20
>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource =
works which is
>>>>> fundamentally broken. It rewrites the start address of a resource =
in-situ instead
>>>>> of keeping downstream resources separate from the upstream =
resources. For example,
>>>>> I don't see how you could ever release a resource in this design =
without completely
>>>>> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
>>>>> translating bridge that uses the current approach should corrupt =
the allocated
>>>>> resource ranges in an rman long before my changes.
>>>>>=20
>>>>> That said, that doesn't really explain the panic. Hmm, the panic =
might be because
>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>>>>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>>>>=20
>>>>>> Detail:
>>>>>> . . .
>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>=20
>>>>> This indicates this is a translating bus.
>>>>>=20
>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end =
0x1
>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff,=
count=3D0x100000
>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>> rman_reserve_resource_bound: trying 0xffffffff =
<0xc0000000,0xfffff>
>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 =
(requested 0x100000)
>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>> allocating from the beginning
>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>=20
>> What you later typed does not match:
>>=20
>> 0x600000000
>> 0x6000fffff
>>=20
>> You later typed:
>>=20
>> 0x60000000
>> 0x600fffffff
>>=20
>> This seems to have lead to some confusion from using the
>> wrong figure(s).
>>=20
>>>>> The fact that we are trying to reserve the CPU addresses in the =
rman is because
>>>>> bus_translate_resource rewrote the start address in the resource =
after it was allocated.
>>>>>=20
>>>>> That said, I can't see why rman_manage_region would actually fail. =
At this point the
>>>>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>>>>> so only the check that should be failing are the checks against =
rm_start and
>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end =
is always
>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>>>>> ranges are within those bounds.
>>=20
>> No:
>>=20
>> 0xffffffff
>>=20
>> .vs (actual):
>>=20
>> 0x600000000
>> 0x6000fffff
>>=20
>> Both the actuals are larger then the 0xffffffff figure you list =
above.
>>=20
>> I've no clue if the 0xffffffff might have its own typos.
>>=20
>>>>> I would instead expect to see some other issue later
>>>>> on where we fail to allocate a resource for a child BAR, but I =
wouldn't expect
>>>>> rman_manage_region to fail.
>>>>>=20
>>>>> Logging the return value from rman_manage_region would be the =
first step I think
>>>>> to see which error value it is returning.
>>>>=20
>>>> Looking at the code in sys/kern/subr_rman.c for rman_manage_region =
I see
>>>> the (mostly) return rv related logic only has ENONMEM (explicit =
return) and
>>>> EBUSY as non-0 possibilities (no other returns).
>>>=20
>>> The modern code also has EINVAL via an explicit return.
>>>=20
>>>> All the rv references and
>>>> all the returns are shown below:
>>>>=20
>>>> int rv =3D 0;
>>>> . . .
>>>=20
>>> The modern code also has here:
>>>=20
>>> DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
>>> rm->rm_descr, start, end));
>>> if (start < rm->rm_start || end > rm->rm_end)
>>> return EINVAL;
>>>=20
>>> Adding rm->rm_start and rm->rm_end to the message might be
>>> appropriate --and would also be enough additional information
>>> to know if EINVAL would be returned.
>>=20
>> I added such code and built, installed, and tried booting
>> a separate kernel. The result was:
>>=20
>> rman_manage_region: <pcib1 memory window> range 0..0xffffffff : =
request: start 0x600000000, end 0x6000fffff
>> panic: Failed to add resource to rman
>>=20
>> So:
>>=20
>> 0
>> vs. start:
>> 0x600000000
>>=20
>> and:
>>=20
>> 0xffffffff
>> vs. end:
>> 0x6000fffff
>>=20
>> The 0x600000000..0x6000fffff range is not a range of RAM addresses
>> [too large for that for the 8 GiByte RPi4B] and, so, is well above
>> the 32 bit boundary too.
>>=20
>> That is the only line referencing "memory window". A 32 bit initial =
range
>> for some reason. For reference, the source change in question was:
>>=20
>> - DPRINTF(("rman_manage_region: <%s> request: start %#jx, end =
%#jx\n",
>> - rm->rm_descr, start, end));
>> + DPRINTF(("rman_manage_region: <%s> range %#jx..%#jx : =
request: start %#jx, end %#jx\n",
>> + rm->rm_descr, rm->rm_start, rm->rm_end, start, end));
>> if (start < rm->rm_start || end > rm->rm_end)
>> return EINVAL;
>>=20
>> I'll show a larger boot output context at the bottom of the message
>> for reference.
>>=20
>>>> r =3D int_alloc_resource(M_NOWAIT);
>>>> if (r =3D=3D NULL)
>>>> return ENOMEM;
>>>> . . .
>>>> /* Check for any overlap with the current region. */
>>>> if (r->r_start <=3D s->r_end && r->r_end >=3D =
s->r_start) {
>>>> rv =3D EBUSY;
>>>> goto out;
>>>> }
>>>>=20
>>>> /* Check for any overlap with the next region. */
>>>> t =3D TAILQ_NEXT(s, r_link);
>>>> if (t && r->r_start <=3D t->r_end && r->r_end >=3D =
t->r_start) {
>>>> rv =3D EBUSY;
>>>> goto out;
>>>> }
>>>> . . .
>>>> out:
>>>> mtx_unlock(rm->rm_mtx);
>>>> return rv;
>>>>=20
>>>> int_alloc_resource failure would be failure (NULL) from the:
>>>>=20
>>>> struct resource_i *r;
>>>>=20
>>>> r =3D malloc(sizeof *r, M_RMAN, malloc_flag | M_ZERO);
>>>>=20
>>>> (associated with the M_NOWAIT argument).
>>>>=20
>>>> The malloc failure would likely go in a very different direction.
>>>>=20
>>>>=20
>>>>=20
>>>> Side note: looks like the EBUSY cases leak what r references.
>>>=20
>>> Still true in the newer code.
>>>=20
>>>>> Probably I should fix pci_host_generic.c to handle translation =
properly however.
>>>>> I can work on a patch for that.
>>>>=20
>>=20
>> For reference:
>>=20
>> . . .
>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>> pcib0: parsing FDT for ECAM0:
>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
>> pcib0: Bus is not cache-coherent
>> rman_reserve_resource_bound: <I/O memory addresses> request: =
[0xfd500000, 0xfd50930f], length 0x9310, flags 100, device pcib0
>> rman_reserve_resource_bound: trying 0x1fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x1fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x31bfffff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x33298fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39bf1fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c02fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c06fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c07fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c08fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c2afff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c36fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x39c37fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3b03ffff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3b04ffff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3b2fffff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3ee61fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3ee63fff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0x3fffffff <0xfd500000,0x930f>
>> rman_reserve_resource_bound: tried 0xfbffffff <0xfd500000,0x930f>
>> considering [0xfc000000, 0xfd5d1fff]
>> truncated region: [0xfd500000, 0xfd50930f]; size 0x9310 (requested =
0x9310)
>> candidate region: [0xfd500000, 0xfd50930f], size 0x9310
>> splitting region in three parts: [0xfc000000, 0xfd4fffff]; =
[0xfd500000, 0xfd50930f]; [0xfd509310, 0xfd5d1fff]
>> rman_manage_region: <PCIe Memory> range 0..0xffffffffffffffff : =
request: start 0xc0000000, end 0xffffffff
>> pcib0: hardware identifies as revision 0x304.
>> pcib0: note: reported link speed is 5.0 GT/s.
>> rman_reserve_resource_bound: <Interrupts> request: [0x51, 0x51], =
length 0x1, flags 0, device pcib0
>> rman_reserve_resource_bound: trying 0 <0x51,0>
>> rman_reserve_resource_bound: tried 0 <0x51,0>
>> rman_reserve_resource_bound: tried 0x1 <0x51,0>
>> rman_reserve_resource_bound: tried 0x2 <0x51,0>
>> rman_reserve_resource_bound: tried 0x3 <0x51,0>
>> rman_reserve_resource_bound: tried 0x4 <0x51,0>
>> rman_reserve_resource_bound: tried 0x5 <0x51,0>
>> rman_reserve_resource_bound: tried 0x6 <0x51,0>
>> rman_reserve_resource_bound: tried 0x7 <0x51,0>
>> rman_reserve_resource_bound: tried 0xc <0x51,0>
>> rman_reserve_resource_bound: tried 0xd <0x51,0>
>> rman_reserve_resource_bound: tried 0xe <0x51,0>
>> rman_reserve_resource_bound: tried 0xf <0x51,0>
>> rman_reserve_resource_bound: tried 0x10 <0x51,0>
>> rman_reserve_resource_bound: tried 0x11 <0x51,0>
>> rman_reserve_resource_bound: tried 0x12 <0x51,0>
>> rman_reserve_resource_bound: tried 0x17 <0x51,0>
>> rman_reserve_resource_bound: tried 0x18 <0x51,0>
>> rman_reserve_resource_bound: tried 0x1a <0x51,0>
>> rman_reserve_resource_bound: tried 0x1b <0x51,0>
>> rman_reserve_resource_bound: tried 0x22 <0x51,0>
>> rman_reserve_resource_bound: tried 0x23 <0x51,0>
>> rman_reserve_resource_bound: tried 0x24 <0x51,0>
>> rman_reserve_resource_bound: tried 0x25 <0x51,0>
>> rman_reserve_resource_bound: tried 0x26 <0x51,0>
>> rman_reserve_resource_bound: tried 0x27 <0x51,0>
>> rman_reserve_resource_bound: tried 0x28 <0x51,0>
>> rman_reserve_resource_bound: tried 0x29 <0x51,0>
>> rman_reserve_resource_bound: tried 0x4e <0x51,0>
>> rman_reserve_resource_bound: tried 0x4f <0x51,0>
>> considering [0x50, 0xffffffffffffffff]
>> truncated region: [0x51, 0x51]; size 0x1 (requested 0x1)
>> candidate region: [0x51, 0x51], size 0x1
>> splitting region in three parts: [0x50, 0x50]; [0x51, 0x51]; [0x52, =
0xffffffffffffffff]
>> pci0: <OFW PCI bus> on pcib0
>> rman_manage_region: <PCI domain 0 bus numbers> range 0..0xff : =
request: start 0, end 0xff
>> rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: [0, =
0], length 0x1, flags 0, device pci0
>> rman_reserve_resource_bound: trying 0xff <0,0>
>> considering [0, 0xff]
>> truncated region: [0, 0]; size 0x1 (requested 0x1)
>> candidate region: [0, 0], size 0x1
>> allocating from the beginning
>> pci0: domain=3D0, physical bus=3D0
>> found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00
>> domain=3D0, bus=3D0, slot=3D0, func=3D0
>> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0
>> cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
>> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
>> intpin=3Da, irq=3D0
>> powerspec 3 supports D0 D3 current D0
>> secbus=3D1, subbus=3D1
>> rman_reserve_resource_bound: <PCI domain 0 bus numbers> request: =
[0x1, 0x1], length 0x1, flags 0, device (null)
>> rman_reserve_resource_bound: trying 0 <0x1,0>
>> rman_reserve_resource_bound: tried 0 <0x1,0>
>> considering [0x1, 0xff]
>> truncated region: [0x1, 0x1]; size 0x1 (requested 0x1)
>> candidate region: [0x1, 0x1], size 0x1
>> allocating from the beginning
>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>> rman_manage_region: <pcib1 bus numbers> range 0..0xff : request: =
start 0x1, end 0x1
>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, =
0xc00fffff], length 0x100000, flags 102, device pcib1
>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>> considering [0xc0000000, 0xffffffff]
>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested =
0x100000)
>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>> allocating from the beginning
>> rman_manage_region: <pcib1 memory window> range 0..0xffffffff : =
request: start 0x600000000, end 0x6000fffff
>> panic: Failed to add resource to rman
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
>> vpanic() at vpanic+0x1a4
>> panic() at panic+0x48
>> pcib_add_window_resources() at pcib_add_window_resources+0xf4
>> pcib_alloc_window() at pcib_alloc_window+0xfc
>> pcib_attach_common() at pcib_attach_common+0xa18
>> pcib_attach() at pcib_attach+0x14
>> device_attach() at device_attach+0x3fc
>> device_probe_and_attach() at device_probe_and_attach+0x80
>> bus_generic_attach() at bus_generic_attach+0x1c
>> pci_attach() at pci_attach+0xec
>> device_attach() at device_attach+0x3fc
>> device_probe_and_attach() at device_probe_and_attach+0x80
>> bus_generic_attach() at bus_generic_attach+0x1c
>> device_attach() at device_attach+0x3fc
>> device_probe_and_attach() at device_probe_and_attach+0x80
>> bus_generic_new_pass() at bus_generic_new_pass+0x100
>> bus_generic_new_pass() at bus_generic_new_pass+0xb0
>> bus_generic_new_pass() at bus_generic_new_pass+0xb0
>> bus_generic_new_pass() at bus_generic_new_pass+0xb0
>> bus_set_pass() at bus_set_pass+0x50
>> mi_startup() at mi_startup+0x1e0
>> virtdone() at virtdone+0x68
>> KDB: enter: panic
>> [ thread pid 0 tid 100000 ]
>> Stopped at kdb_enter+0x4c: str xzr, [x19, #1280]
>> db>=20
>>=20
>=20
> FYI:
>=20
> bcm2711-peripherals.pdf "Figure 1. BCM2711 Address Maps"
> documents the PCIe address space range as (their "_"
> notation):
>=20
> 0x6_0000_0000..0x7_FFFF_FFFF
>=20
> for both of the address maps:
>=20
> 'Full 35-bit Address Map'
> 'ARM view of the Address Map in "Low Peripheral" mode'
>=20
> The Low Peripheral mode is what is in use.
>=20
> So the 0x6_0000_0000..0x6_000f_ffff range looks
> to be a valid ARM system address space for the
> PCIe to map to.
It looks to me like in sys/dev/pci/pci_pci.c the:
static void
pcib_probe_windows(struct pcib_softc *sc)
{
. . .
pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
. . .
is just inappropriately restrictive about where in the system
address space a PCIe can validly be mapped to on the high end.
That, in turn, leads to the rejection on the RPi4B now that
the range use is checked.
More: Even the size (0xffffffff-0)+1 is smaller than the size of
the range that the BCM2711 documentation indicates as reserved
for PCIe (not that the fdt indicates to use the upper half of
that range at all):
(0x7_FFFF_FFFF - 0x6_0000_0000)+1 =3D=3D 0x1_FFFF_FFFF + 1
(I'm not so sure that this matters for the RPi4B. It
is not a great example of the generality of PCIe
uses. But might there be contexts where it does matter?)
The lower bound being 0 allows for the actual low
bound. But I wonder if use of the fdt (or ACPI)
information should be possible to then indicate a
actual low bound to check against instead. (A
smaller high bound may be reasonable, at least
for a RPi4B like context.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Tue Feb 13 02:56:34 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYmFC1yY6z59bnc
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 02:56:47 +0000 (UTC)
(envelope-from sobomax@sippysoft.com)
Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176])
(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 4TYmFB52wBz419V
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 02:56:46 +0000 (UTC)
(envelope-from sobomax@sippysoft.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2d0ed7cbd76so30946981fa.1
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 18:56:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707793004; x=1708397804;
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=vceK35YAtNLYk3P7Obzd/nlU8fP7ewXITpsb3WYZ9fw=;
b=pNvYnMxdPPrv5idTNjpoQTIcnVuev6hltO7IT6qgfPPYV6MzEdI8nRYGDzHAFV4N5/
f0fTL7jyUwXE9dgfQflPXk/4/bRou+BJW6nty5IoyEwOngpDuEmGaRVtSim6I+JK2Cui
RMp3GWZ+sA2o0O4Gx2OQqrKK0ikEAzi2JKgonnrVzpt0gcYaN06cynX7KIElEHqH2F50
EFlSzciNW8foldNXzuJGBhbSNwy5YDWKaFBnpKETRnl5N0UgebfmtDvxwAgvTlrK/O43
9BNfstElxKkDknJApxk9Nnyy9AzjhMGTwPlCxUpn9G62oBgGrT0T8r0CGdC1/uFbD9Ag
9cNw==
X-Gm-Message-State: AOJu0YzTYcIArnwpYYBRUa/KJEiHaOu283uG2W/PtWvIYk6Q0oopLjuA
DlvY+CCf9/SVRem5OMTKK27NHpIn5NRBghszxscDw3A48kWr+IgDNDNMbR9vExRT2yWzCp/6PXS
rQGIIokhNu1FCSq3xkW1S49LJVzJJ2YFIdG/6TA==
X-Google-Smtp-Source: AGHT+IGSG5+WESWfNXq4GSheaGXHQu0gwTPrDmRw5vPgogNgTD5uXns/w3fptobW8zkf4evSxSCTJ88PKBn/sSl4bGU=
X-Received: by 2002:a05:651c:b27:b0:2d0:f62b:63c9 with SMTP id
b39-20020a05651c0b2700b002d0f62b63c9mr4846678ljr.31.1707793004476; Mon, 12
Feb 2024 18:56:44 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
In-Reply-To: <tkrat.edddc2469f43baf6@FreeBSD.org>
From: Maxim Sobolev <sobomax@freebsd.org>
Date: Mon, 12 Feb 2024 18:56:34 -0800
Message-ID: <CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
Subject: Re: nvme controller reset failures on recent -CURRENT
To: Don Lewis <truckman@freebsd.org>
Cc: FreeBSD current <freebsd-current@freebsd.org>, John Baldwin <jhb@freebsd.org>
Content-Type: multipart/alternative; boundary="00000000000061cf0606113a8b53"
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]
X-Rspamd-Queue-Id: 4TYmFB52wBz419V
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
--00000000000061cf0606113a8b53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Might be an overheating. Today's nvme drives are notoriously flaky if you
run them without proper heat sink attached to it.
-Max
On Mon, Feb 12, 2024, 4:28=E2=80=AFPM Don Lewis <truckman@freebsd.org> wrot=
e:
> I just upgraded my package build machine to:
> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> from:
> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
> and I've had two nvme-triggered panics in the last day.
>
> nvme is being used for swap and L2ARC. I'm not able to get a crash
> dump, probably because the nvme device has gone away and I get an error
> about not having a dump device. It looks like a low-memory panic
> because free memory is low and zfs is calling malloc().
>
> This shows up in the log leading up to the panic:
> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> timeout a
> nd possible hot unplug.
> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> timeout a
> nd possible hot unplug.
> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdo=
g
> ti
> meout.
>
> The device looks healthy to me:
> SMART/Health Information Log
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> Critical Warning State: 0x00
> Available spare: 0
> Temperature: 0
> Device reliability: 0
> Read only: 0
> Volatile memory backup: 0
> Temperature: 312 K, 38.85 C, 101.93 F
> Available spare: 100
> Available spare threshold: 10
> Percentage used: 3
> Data units (512,000 byte) read: 5761183
> Data units written: 29911502
> Host read commands: 471921188
> Host write commands: 605394753
> Controller busy time (minutes): 32359
> Power cycles: 110
> Power on hours: 19297
> Unsafe shutdowns: 14
> Media errors: 0
> No. error info log entries: 0
> Warning Temp Composite Time: 0
> Error Temp Composite Time: 0
> Temperature 1 Transition Count: 5231
> Temperature 2 Transition Count: 0
> Total Time For Temperature 1: 41213
> Total Time For Temperature 2: 0
>
>
>
--00000000000061cf0606113a8b53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Might be an overheating. Today's nvme drives are noto=
riously flaky if you run them without proper heat sink attached to it.=C2=
=A0<div dir=3D"auto"><br></div><div dir=3D"auto">-Max<br><div dir=3D"auto">=
<br></div><div dir=3D"auto"><br></div></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 12, 2024, 4:28=E2=
=80=AFPM Don Lewis <<a href=3D"mailto:truckman@freebsd.org">truckman@fre=
ebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just upgr=
aded my package build machine to:<br>
=C2=A0 FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e<br>
from:<br>
=C2=A0 FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38<br>
and I've had two nvme-triggered panics in the last day.<br>
<br>
nvme is being used for swap and L2ARC.=C2=A0 I'm not able to get a cras=
h<br>
dump, probably because the nvme device has gone away and I get an error<br>
about not having a dump device.=C2=A0 It looks like a low-memory panic<br>
because free memory is low and zfs is calling malloc().<br>
<br>
This shows up in the log leading up to the panic:<br>
Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout=
a<br>
nd possible hot unplug.<br>
Feb 12 10:07:41 zipper syslogd: last message repeated 1 times<br>
Feb 12 10:07:41 zipper kernel: nvme0: resetting controller<br>
Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout=
a<br>
nd possible hot unplug.<br>
Feb 12 10:07:41 zipper syslogd: last message repeated 1 times<br>
Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete<br>
Feb 12 10:07:41 zipper syslogd: last message repeated 2 times<br>
Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o<br>
Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdog =
ti<br>
meout.<br>
<br>
The device looks healthy to me:<br>
SMART/Health Information Log<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br>
Critical Warning State:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00<br>
=C2=A0Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00<br>
=C2=A0Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00<br>
=C2=A0Device reliability:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0<br>
=C2=A0Read only:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00<br>
=C2=A0Volatile memory backup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 0<br>
Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 312 K, 38.85 C, 101.93 F<br>
Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100=
<br>
Available spare threshold:=C2=A0 =C2=A0 =C2=A0 10<br>
Percentage used:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<b=
r>
Data units (512,000 byte) read: 5761183<br>
Data units written:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A029911502=
<br>
Host read commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A047192118=
8<br>
Host write commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 605394753<br>
Controller busy time (minutes): 32359<br>
Power cycles:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0110<br>
Power on hours:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A019297<br>
Unsafe shutdowns:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014<=
br>
Media errors:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A00<br>
No. error info log entries:=C2=A0 =C2=A0 =C2=A00<br>
Warning Temp Composite Time:=C2=A0 =C2=A0 0<br>
Error Temp Composite Time:=C2=A0 =C2=A0 =C2=A0 0<br>
Temperature 1 Transition Count: 5231<br>
Temperature 2 Transition Count: 0<br>
Total Time For Temperature 1:=C2=A0 =C2=A041213<br>
Total Time For Temperature 2:=C2=A0 =C2=A00<br>
<br>
<br>
</blockquote></div>
--00000000000061cf0606113a8b53--
From nobody Tue Feb 13 03:03:29 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 4TYmP34Pnxz59cZV
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 03:03:35 +0000 (UTC)
(envelope-from markjdb@gmail.com)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35])
(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 4TYmP30LQXz42q9;
Tue, 13 Feb 2024 03:03:35 +0000 (UTC)
(envelope-from markjdb@gmail.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-dcc80d6004bso205827276.0;
Mon, 12 Feb 2024 19:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1707793413; x=1708398213; darn=freebsd.org;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=y+14Lfv2ghy0pdcKD/fCBPSDwLu3LVniUZnnSEXd1vg=;
b=i0sfoplh5SVHfBln3Fwbn3vyvjFLwF7lcdry01mJx2YOscpow886yJuE6HoW/GCBPb
OrllUzdHVFd5SqOSmwY7SP7zt7yKSEfltDK6FFTfcLCKgoTHVFDbeImByPwFyvXh1FaD
KFefa8Dqn+7KM2BEsrLSv3rCwPVv3umkYpCBPH42kBFYoMx9WUDFk7sJ1Xx8B1YdPoex
OEvB3qTLKf2Ks3IsOKCXBCtWbnICDoxoGADKyGl7fjkjN1/3K4nh+nu/mRfRt0plNEFy
LlpRvOCvR7fPLJW+wWSsv1vbmHNeXNmqUEooKUQ9HPPIL6VMc9u/qvM9PeW7AHz9I03X
5s3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707793413; x=1708398213;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=y+14Lfv2ghy0pdcKD/fCBPSDwLu3LVniUZnnSEXd1vg=;
b=N6Tb37SguNbU5umh3smh/m8Cq1qptiEprkW68hesS6BJ0UnhhZDm1vQ+uhAa9vgkoN
COLQk7KfWU7bL79kSrtwrx2Kfrpgr4eOBeYYGECIwzGK4LXSFSb2RqoJs3p+k7SmZH5C
q6HcY8wZk7fkMNfh6N0aXngb5HkLqf5TBis5tAWk57Y7VkpPe0nII+Z0zE8G72yicHnw
NLu5LUCFtaeD5WDyyf4w6DM5/P22mszXTVyB7Mr+9W+hf8zD0aXBwhUG5jv+nvhsrChs
s3Ou9hdX6Tf8EoFXPFM6ESBBsdfutwH3r5XEh7A4tpOluJBzdMXgTNNeuinLr8BrKyXY
CqFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUxi7MGq5jevMOS4p3lXd+qeQFQrV708QCCuZxrct85yT8/5+EWYC/Tx9OsldSA3S+t/NxaCAP6GyyRESoHSwU=
X-Gm-Message-State: AOJu0YymmEWCd3DShOSHtju3Po118maiwBHUEhk8c+P48FIyKak55A/z
ErpRmFo4aIm/OWq1eNB8eagR5Q04e6kJ7OHGljpoVjF7dnDp3Oz4FrukENYF
X-Google-Smtp-Source: AGHT+IGS0vNcuYT+QQZLKr0yUrW7gjF/cjWf5qk3864Vfarg4gIqfGcLjUsn4gqdnv0OHo/HPdw8UA==
X-Received: by 2002:a25:5f09:0:b0:dc2:2d75:5fde with SMTP id t9-20020a255f09000000b00dc22d755fdemr6820956ybb.29.1707793412731;
Mon, 12 Feb 2024 19:03:32 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCVis1yyNL1X740qfOeQnbw6moUqAoRRsr471FDcNsMsIvyueINv3quGB46RkrZ5nHEHjm2vx00Hbm0DlCrKJuQ=
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
by smtp.gmail.com with ESMTPSA id g4-20020a05620a40c400b00785b02c5784sm2598706qko.86.2024.02.12.19.03.31
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 12 Feb 2024 19:03:32 -0800 (PST)
Date: Mon, 12 Feb 2024 22:03:29 -0500
From: Mark Johnston <markj@freebsd.org>
To: Don Lewis <truckman@freebsd.org>
Cc: FreeBSD current <freebsd-current@freebsd.org>,
John Baldwin <jhb@freebsd.org>
Subject: Re: nvme controller reset failures on recent -CURRENT
Message-ID: <ZcrcAbxh9Ii8hicC@nuc>
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <tkrat.edddc2469f43baf6@FreeBSD.org>
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: 4TYmP30LQXz42q9
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote:
> I just upgraded my package build machine to:
> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> from:
> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
> and I've had two nvme-triggered panics in the last day.
>
> nvme is being used for swap and L2ARC. I'm not able to get a crash
> dump, probably because the nvme device has gone away and I get an error
> about not having a dump device. It looks like a low-memory panic
> because free memory is low and zfs is calling malloc().
>
> This shows up in the log leading up to the panic:
> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
> nd possible hot unplug.
> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
> nd possible hot unplug.
> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdog ti
> meout.
Are you by chance using the drive mentioned here? https://github.com/openzfs/zfs/discussions/14793
I was bitten by that and ended up replacing the drive with a different
model. The crash manifested exactly as you describe, though I didn't
have L2ARC or swap enabled on it.
> The device looks healthy to me:
> SMART/Health Information Log
> ============================
> Critical Warning State: 0x00
> Available spare: 0
> Temperature: 0
> Device reliability: 0
> Read only: 0
> Volatile memory backup: 0
> Temperature: 312 K, 38.85 C, 101.93 F
> Available spare: 100
> Available spare threshold: 10
> Percentage used: 3
> Data units (512,000 byte) read: 5761183
> Data units written: 29911502
> Host read commands: 471921188
> Host write commands: 605394753
> Controller busy time (minutes): 32359
> Power cycles: 110
> Power on hours: 19297
> Unsafe shutdowns: 14
> Media errors: 0
> No. error info log entries: 0
> Warning Temp Composite Time: 0
> Error Temp Composite Time: 0
> Temperature 1 Transition Count: 5231
> Temperature 2 Transition Count: 0
> Total Time For Temperature 1: 41213
> Total Time For Temperature 2: 0
>
>
From nobody Tue Feb 13 04:06:21 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 4TYnnX6Fbzz59k2G
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 04:06:24 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYnnX5kCxz47gJ
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 04:06:24 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707797184;
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=Fs7J4jfA6FZQpbnWD9Mc5cKrmoG12EZIajnfqhzqhXk=;
b=EHC0O8O1DxkrVZx7lwqJcPqq9cHpHaoCd9Uxd/GwrAVb9SY09U4Ua2p0l5BQnWs4Y5HJgZ
FJiqOP+DZ+5Qp91s+LLz1aodmcHyE117qj6KFCavizmZIFj1sDgFIjsEnuhEa9ebWr8wl8
xYlU+9LX4t6ZCD/pXMc98rIbQaTS+DdIFTV4S3p9bzHYVGbsiaY5wgBWy3NurVFc8sWD2c
logPfMWZ7hPBoKShF4Ng/QSJI/schg6x1o7F52vhzbuUBwDn7ivwyYj6Pue0zrcUJxgZyi
VG7OyDvpVqHVZ8iYxen+PzaUY2Rh5hBCnBPisSxwGJ2Mvn4ZXa81fRZhCv+9xg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707797184; a=rsa-sha256; cv=none;
b=iggunIMpTe5vC/P95xHPGIR24bDRpviRw3WIA8d7C6CWPhdTCwxJlFTFv+hdRIFEGAx9hb
7fg2jau++70sDv7y3Jhc7/mzVNo7NM8kAlIv/Na5CQFzqyRqKLuaWR1feX1yQV9tCcos//
fs3zCgzCIRWu4MaalXqnbP/S4Dz4HIP345TCub49zyMblNN9Lb8BATVRiRo6HzHIkZWyg2
fjrStuIFP/VYi6jqg4me6bO0qzjijYrV4tnHtitG9sOseMz9b/RPMWgDY4l0tEo3SwiO2M
Er4LZ6okkFJaZysnSScKP9sqPGx0+K68Tt6j7mlCgHi+09J4Z4RImZlPU1jAbA==
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=1707797184;
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=Fs7J4jfA6FZQpbnWD9Mc5cKrmoG12EZIajnfqhzqhXk=;
b=UpO2v3fSHmGgZFZ+DSSHoSt+wus3F0RDPkFTl+BhWYqBm3ortb2dfPyKDPjg0qtPfNwwck
LNhz7Z7BZ8QiEt+yKr72uofO50CRyuGlal4gS+/s7IlRvP82prYLEJ0TJ98p2gyHin67ET
UfOLdj+eQcSwzWBwhFctg0C77cxPHe41OuMxyKgrw1OIrC9QaDW/amacvtr79Pnsjf9JRk
6p/0guRynn01DtgvhmHmsMP7/W1ERQvzpsfxz1rvc43sM9ivizO6Bouzhc+KJpP324ys1Y
+LvaRWEioGFLxi9nW3zTaeDb1rTNiSzuWbS+NcTSIO5y6fJ02pF2fLcjPpCzug==
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:cd45:5b11::2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: truckman)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYnnX1yh8zgn0
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 04:06:24 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from dl (uid 1001)
(envelope-from truckman@FreeBSD.org)
id 239f63
by gw.catspoiler.org (DragonFly Mail Agent v0.13 on mousie.catspoiler.org);
Mon, 12 Feb 2024 20:06:21 -0800
Date: Mon, 12 Feb 2024 20:06:21 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: nvme controller reset failures on recent -CURRENT
To: Mark Johnston <markj@freebsd.org>
cc: FreeBSD current <freebsd-current@freebsd.org>,
John Baldwin <jhb@freebsd.org>
In-Reply-To: <ZcrcAbxh9Ii8hicC@nuc>
Message-ID: <tkrat.728a6a6a65e7c4c5@FreeBSD.org>
References: <tkrat.edddc2469f43baf6@FreeBSD.org> <ZcrcAbxh9Ii8hicC@nuc>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Disposition: INLINE
On 12 Feb, Mark Johnston wrote:
> On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote:
>> I just upgraded my package build machine to:
>> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
>> from:
>> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
>> and I've had two nvme-triggered panics in the last day.
>>
>> nvme is being used for swap and L2ARC. I'm not able to get a crash
>> dump, probably because the nvme device has gone away and I get an error
>> about not having a dump device. It looks like a low-memory panic
>> because free memory is low and zfs is calling malloc().
>>
>> This shows up in the log leading up to the panic:
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
>> nd possible hot unplug.
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a timeout a
>> nd possible hot unplug.
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
>> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
>> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
>> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdog ti
>> meout.
>
> Are you by chance using the drive mentioned here? https://github.com/openzfs/zfs/discussions/14793
>
> I was bitten by that and ended up replacing the drive with a different
> model. The crash manifested exactly as you describe, though I didn't
> have L2ARC or swap enabled on it.
Nope:
nda0 at nvme0 bus 0 scbus9 target 0 lun 1
nda0: <INTEL SSDPEKNW512G8 002C BTNH940617WE512A>
nda0: Serial Number BTNH940617WE512A
nda0: nvme version 1.3
nda0: 488386MB (1000215216 512 byte sectors)
I'm not seeing super high I/O rates> I happened to have iostat running
when the machine paniced:
0 584 88.4 31 2.68 65.8 112 7.18 68.2 107 7.13 80 0 20 0 0
0 565 99.1 32 3.06 27.9 74 2.01 30.5 70 2.08 80 0 20 0 0
0 612 92.8 31 2.77 18.9 148 2.74 18.9 148 2.73 86 0 14 0 0
0 618 88.6 13 1.17 25.0 59 1.44 24.2 61 1.44 89 0 11 0 0
0 586 45.4 5 0.22 31.4 55 1.70 30.8 57 1.70 84 0 16 0 0
0 598 12.7 3 0.03 38.1 64 2.40 37.1 66 2.40 84 0 16 0 0
0 675 36.1 6 0.21 23.7 156 3.62 22.7 164 3.63 88 0 12 0 0
0 641 6.9 6 0.04 25.7 243 6.10 25.3 246 6.08 71 0 29 0 0
0 737 20.1 9 0.18 36.4 148 5.24 37.2 144 5.24 78 0 22 0 0
0 578 44.7 23 1.03 25.1 164 4.01 25.5 161 3.99 86 0 14 0 0
0 608 70.3 15 1.06 51.1 64 3.19 51.3 64 3.19 89 0 11 0 0
0 624 38.6 9 0.35 32.3 121 3.80 32.2 121 3.79 90 0 10 0 0
0 577 80.6 16 1.28 37.8 66 2.44 36.5 69 2.46 90 0 10 0 0
tty nda0 ada0 ada1 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 566 87.7 16 1.39 27.2 60 1.60 25.3 66 1.62 87 0 13 0 0
0 599 77.2 11 0.83 17.4 391 6.66 17.3 395 6.66 74 0 26 0 0
0 660 45.0 7 0.31 18.7 575 10.51 18.6 578 10.49 76 0 24 0 0
0 615 37.7 8 0.31 24.0 303 7.11 24.0 303 7.11 58 0 42 0 0
Fssh_packet_write_wait: ... port 22: Broken pipe
ada* are old and slow spinning rust.
That report does mention something else that could also be a cause. I
upgraded the motherboard BIOS around the same time. When I get a
chance, I'll drop back to the older FreeBSD version and see if the
problem goes away.
From nobody Tue Feb 13 04:15: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 4TYp055xM1z59lBb
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 04:15:33 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TYp055WPyz4CWL
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 04:15:33 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707797733;
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: references:references;
bh=sb3sR4HxUH0hbUvGB0voplfYc9TP6z4kM9T+LbKAZFU=;
b=JsR9AWRX7UDWNpnR1gAA2b3AmKIkaOsA6Z7qoo3fVKlg84gG78dvCHwTCpJgUD5lmK+uIi
xCC2gIiwf14CRYorsAZaLw1ozSJlW4aC48kr2h7abjV6hbPd+Dm9zyQx3WxWMdkUXvE9vL
X7nxji2/CuDl5hHhJvdCb1+tqymb1B5E893g6QMODSbsr6MJ85IsoyqzkEET5vtTqWAgiA
kYCBEZhxfolFcEqWnkR0zHO76zxodYFq4lJU+9YvgvFOKYkBqGKKHarZpJXJU+7r4cd8sN
rIaQ+Bnd4jjdSiWkaYAV807U5t55XfV8EP9j/hQTkpD6JDVKY2E9kqrLd+9S8g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707797733; a=rsa-sha256; cv=none;
b=G7gx9YddoJK+2jhLJrOebNwGKsPEzxXtpir83o7QPTxZDmKrwXjviRoJMYYGWjsG9KU/nW
CYIsNjWDbVBuoJreVzRNdJr9gNjeP9ozTrMXzrTBAmF2xzwM+s8E9fiusLwnX8n/bBMJ9G
hx+whkF7J77cOEuRM4Rg1FmC0FDZE47q+E7U802RxNeCz31Sv8Aq76ThJ6XrYv/GrmMZZ7
VfFepq1qNpGbfggNpypg+1ORiSAzpAFzQLHV/eNJyyPpK0xW0Ysk4jpNl0TkDpUoSXQUAG
MS/l7/2v1VJy8J4TPDyX6395tusqhiRAZUo2JRZetKA8cgSMggNHbfcsqwlHCw==
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=1707797733;
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: references:references;
bh=sb3sR4HxUH0hbUvGB0voplfYc9TP6z4kM9T+LbKAZFU=;
b=Li1ujsv7+iwEDJEz24kJMVV/iHfv44BShjRV4fAQRUYlbwMm/4btus3/SpX8JRM/IwL7ik
3iDbonY9KPhoGQlVIe63yfE6fLFIS0r5fIbaxi1xgy0AQfYmYuwPgDHj5mXGGMRN98E49/
lLg/XZFXttHBomMmAuJWiDmUBR14peRdXKMZKnzDYlC3/pFZl6hZwr3HEy5VcNB2KQjUHJ
g7Ew1F99vIWTANtYGM3znEI63i8Z/DV+0mCCbva4aLoRaAoQEhdv93tR5+8SRvogm8OGub
k5IGdyrzK9yKzP87ikuoVsLTQePOF2hZ/IVCYkLfnDrTiRflJYcFmPi+mkpjbA==
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:cd45:5b11::2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: truckman)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TYp051QPRzh1R
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 04:15:33 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from dl (uid 1001)
(envelope-from truckman@FreeBSD.org)
id 23bc8e
by gw.catspoiler.org (DragonFly Mail Agent v0.13 on mousie.catspoiler.org);
Mon, 12 Feb 2024 20:15:31 -0800
Date: Mon, 12 Feb 2024 20:15:31 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: nvme controller reset failures on recent -CURRENT
To: Maxim Sobolev <sobomax@freebsd.org>
cc: FreeBSD current <freebsd-current@freebsd.org>,
John Baldwin <jhb@freebsd.org>
Message-ID: <tkrat.76b39844cd6da514@FreeBSD.org>
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
<CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=utf-8
Content-Transfer-Encoding: 8BIT
Content-Disposition: INLINE
On 12 Feb, Maxim Sobolev wrote:
> Might be an overheating. Today's nvme drives are notoriously flaky if you
> run them without proper heat sink attached to it.
I don't think it is a thermal problem. According to the drive health
page, the device temperature has never reached Temperature 2, whatever
that is. The room temperature is around 65F. The system was stable
last summer when the room temperature spent a lot of time in the 80-85F
range. The device temperature depends a lot on the I/O rate, and the
last panic happened when the I/O rate had been below 40tps for quite a
while.
> On Mon, Feb 12, 2024, 4:28 PM Don Lewis <truckman@freebsd.org> wrote:
>
>> I just upgraded my package build machine to:
>> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
>> from:
>> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
>> and I've had two nvme-triggered panics in the last day.
>>
>> nvme is being used for swap and L2ARC. I'm not able to get a crash
>> dump, probably because the nvme device has gone away and I get an error
>> about not having a dump device. It looks like a low-memory panic
>> because free memory is low and zfs is calling malloc().
>>
>> This shows up in the log leading up to the panic:
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
>> timeout a
>> nd possible hot unplug.
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
>> timeout a
>> nd possible hot unplug.
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
>> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
>> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
>> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping watchdog
>> ti
>> meout.
>>
>> The device looks healthy to me:
>> SMART/Health Information Log
>> ============================
>> Critical Warning State: 0x00
>> Available spare: 0
>> Temperature: 0
>> Device reliability: 0
>> Read only: 0
>> Volatile memory backup: 0
>> Temperature: 312 K, 38.85 C, 101.93 F
>> Available spare: 100
>> Available spare threshold: 10
>> Percentage used: 3
>> Data units (512,000 byte) read: 5761183
>> Data units written: 29911502
>> Host read commands: 471921188
>> Host write commands: 605394753
>> Controller busy time (minutes): 32359
>> Power cycles: 110
>> Power on hours: 19297
>> Unsafe shutdowns: 14
>> Media errors: 0
>> No. error info log entries: 0
>> Warning Temp Composite Time: 0
>> Error Temp Composite Time: 0
>> Temperature 1 Transition Count: 5231
>> Temperature 2 Transition Count: 0
>> Total Time For Temperature 1: 41213
>> Total Time For Temperature 2: 0
>>
>>
>>
From nobody Tue Feb 13 05:31:46 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYqhG66gnz59t3t
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 05:31:58 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450: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 4TYqhG19tSz4MCG
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 05:31:58 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-55f0b2c79cdso5316519a12.3
for <freebsd-current@freebsd.org>; Mon, 12 Feb 2024 21:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1707802315; x=1708407115; 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=EZ2/UX9FY6GAHdvcf41d4eoOarN0qHc7DamnD8KcfWs=;
b=FWIal0ShMuakMuI7RVkkPGhExFGwsLXj3ZyyxhJbjVRVzV5AvUncCX4qx2LIIqIL5L
V1LKjqt35VmuXoSxDc2tM1IaUJLUFBYszQkgBuHhkSXHYm3l/f/imW6nnqcJkQVmmZYJ
jnV9AaDOQGFlINMsYaa9zmQ+9EqF4QLyPXKHrE4DEF2LbYqUUyOpJ11DUQrG44mX2hWf
VUgXggIM5oSPOIJkbh1XIgrqxej4rl6tIFwFQ8ewVF3/j7Kb0NhPbX+SDGFZGegunoun
N5zvc5tsuAK12CpIzdklCHnsTBeGp1wlvopiyACr0CDXO6n64bGvZsZjlBk0wkIJWjq4
zXww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707802315; x=1708407115;
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=EZ2/UX9FY6GAHdvcf41d4eoOarN0qHc7DamnD8KcfWs=;
b=CJ/HAoHkuQUPXTKyYFFDT19MX63jskGd8j/Ea1+cSu6txQ9EbBxovQspAtADup6WHw
XhsP8j7qGmYjx1JCBMgtLb1OPqG3GZkJxI/EX3zIl5d1XKLjbGtmjjpURvXWU5liojZX
OPHdESZRsyDHadLE74x67kQunkkmbBHKaahUq8h5pHLpkIIizoEhG+sCagnqisu34hUI
I1IpnAfyOXQOraw9+tNbNvv0VZ+WbhCjrCUbg2PkhkBpOWiP78TApC5LI5ZhTktNTFq1
+V1KPiLOpEiY+ApyjWmIRSkQnFojWqfdRX5/j4N82mCnhlAbiEm3aHRThzvBCFBtHf3o
YzFQ==
X-Forwarded-Encrypted: i=1; AJvYcCXKbxLfH8g3iUIBH+fm1SyKQ0hd/hv3ivU0d3EKYY0KwxBqvkfMoZVMJi0qDc5tuSGld8zJBTxLWhmgFDhHzTBAYfuTluS9GLg4RUE=
X-Gm-Message-State: AOJu0YzyRj1u1gaPjBu3YYzI1xWYAw4nJnnX5+XlHlOnJS87fIjfO8Oj
DHDrwf87niojfw9NCpaxss9p6eDW8pNk3sC8JiCjpABS6w45I//1fafj2ZXcv+1UcHpoAVINV3n
793MyL6x5Fb/bocRzjirikwKn6ZC+CxYnmCd+3Q==
X-Google-Smtp-Source: AGHT+IH24MSqMu9foMNXPi2k3TJBgXDWP9q5OQfbLJru0JzjcqimhHeFx/jif9Bru9nyp8flz1uR6Wo1M7w28HMQ87o=
X-Received: by 2002:aa7:d9cc:0:b0:561:ef01:3fa3 with SMTP id
v12-20020aa7d9cc000000b00561ef013fa3mr629314eds.39.1707802315317; Mon, 12 Feb
2024 21:31:55 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <tkrat.edddc2469f43baf6@FreeBSD.org> <CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
<tkrat.76b39844cd6da514@FreeBSD.org>
In-Reply-To: <tkrat.76b39844cd6da514@FreeBSD.org>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 12 Feb 2024 22:31:46 -0700
Message-ID: <CANCZdfrKeHJg5Tt-3cUq9hBgwwNqF4qnOWyFpF=TUjMdANOMfg@mail.gmail.com>
Subject: Re: nvme controller reset failures on recent -CURRENT
To: Don Lewis <truckman@freebsd.org>
Cc: Maxim Sobolev <sobomax@freebsd.org>, FreeBSD current <freebsd-current@freebsd.org>,
John Baldwin <jhb@freebsd.org>
Content-Type: multipart/alternative; boundary="00000000000059f3b006113cb621"
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: 4TYqhG19tSz4MCG
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
--00000000000059f3b006113cb621
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 12, 2024 at 9:15=E2=80=AFPM Don Lewis <truckman@freebsd.org> wr=
ote:
> On 12 Feb, Maxim Sobolev wrote:
> > Might be an overheating. Today's nvme drives are notoriously flaky if y=
ou
> > run them without proper heat sink attached to it.
>
> I don't think it is a thermal problem. According to the drive health
> page, the device temperature has never reached Temperature 2, whatever
> that is. The room temperature is around 65F. The system was stable
> last summer when the room temperature spent a lot of time in the 80-85F
> range. The device temperature depends a lot on the I/O rate, and the
> last panic happened when the I/O rate had been below 40tps for quite a
> while.
>
It did reach temperature 1, though. That's the 'Warning this drive is too
hot' temperature. It has spent 41213 minutes of your 19297 hours of up
time, or an average of 2 minutes per hour. That's too much. Temperature
2 is critical error: we are about to shut down completely due to it
being too hot. It's only a couple degrees below hardware power off
due to temperature in many drives. Some really cheap ones don't really
implement it at all. On my card with the bad heat sink, Warning temp is
70C while critical is 75C while IIRC thermal shutdown is 78C or 80C.
I don't think we report these values in nvmecontrol identify. But you can
do a raw dump with -x look at bytes 266:267 for warning and 268:269
for critical.
In contrast, the few dozen drives that I have, all of which have been
abused in various ways, And only one of them has any heat issues,
and that one is an engineering special / sample with what I think is
a damaged heat sink. If your card has no heat sink, this could well
be what's going on.
This panic means "the nvme card lost its mind and stopped talking
to the host". Its status registers read 0xff's, which means that the card
isn't decoding bus signals. Usually this means that the firmware on the
card has faulted and rebooted. If the card is overheating, then this could
well be what's happening.
There's a tiny chance that this could be something more exotic,
but my money is on hardware gone bad after 2 years of service. I don't thin=
k
this is 'wear out' of the NAND (it's only 15TB written, but it could be if
this
drive is really really crappy nand: first generation QLC maybe, but it seem=
s
too new). It might also be a connector problem that's developed over time.
There might be a few other things too, but I don't think this is a U.2 driv=
e
with funky cables.
Warner
> > On Mon, Feb 12, 2024, 4:28=E2=80=AFPM Don Lewis <truckman@freebsd.org> =
wrote:
> >
> >> I just upgraded my package build machine to:
> >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> >> from:
> >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
> >> and I've had two nvme-triggered panics in the last day.
> >>
> >> nvme is being used for swap and L2ARC. I'm not able to get a crash
> >> dump, probably because the nvme device has gone away and I get an erro=
r
> >> about not having a dump device. It looks like a low-memory panic
> >> because free memory is low and zfs is calling malloc().
> >>
> >> This shows up in the log leading up to the panic:
> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> >> timeout a
> >> nd possible hot unplug.
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> >> timeout a
> >> nd possible hot unplug.
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
> >> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping
> watchdog
> >> ti
> >> meout.
> >>
> >> The device looks healthy to me:
> >> SMART/Health Information Log
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> >> Critical Warning State: 0x00
> >> Available spare: 0
> >> Temperature: 0
> >> Device reliability: 0
> >> Read only: 0
> >> Volatile memory backup: 0
> >> Temperature: 312 K, 38.85 C, 101.93 F
> >> Available spare: 100
> >> Available spare threshold: 10
> >> Percentage used: 3
> >> Data units (512,000 byte) read: 5761183
> >> Data units written: 29911502
> >> Host read commands: 471921188
> >> Host write commands: 605394753
> >> Controller busy time (minutes): 32359
> >> Power cycles: 110
> >> Power on hours: 19297
> >> Unsafe shutdowns: 14
> >> Media errors: 0
> >> No. error info log entries: 0
> >> Warning Temp Composite Time: 0
> >> Error Temp Composite Time: 0
> >> Temperature 1 Transition Count: 5231
> >> Temperature 2 Transition Count: 0
> >> Total Time For Temperature 1: 41213
> >> Total Time For Temperature 2: 0
> >>
> >>
> >>
>
>
>
--00000000000059f3b006113cb621
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 12, 2024 at 9:15=E2=80=AF=
PM Don Lewis <<a href=3D"mailto:truckman@freebsd.org">truckman@freebsd.o=
rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On 12 Feb, Maxim Sobolev wrote:<br>
> Might be an overheating. Today's nvme drives are notoriously flaky=
if you<br>
> run them without proper heat sink attached to it.<br>
<br>
I don't think it is a thermal problem.=C2=A0 According to the drive hea=
lth<br>
page, the device temperature has never reached Temperature 2, whatever<br>
that is.=C2=A0 The room temperature is around 65F.=C2=A0 The system was sta=
ble<br>
last summer when the room temperature spent a lot of time in the 80-85F<br>
range.=C2=A0 The device temperature depends a lot on the I/O rate, and the<=
br>
last panic happened when the I/O rate had been below 40tps for quite a<br>
while.<br></blockquote><div><br></div><div>It did reach temperature 1, thou=
gh. That's the 'Warning this drive is too</div><div>hot' temper=
ature. It has spent 41213 minutes of your 19297 hours of up</div><div>time,=
or an average of 2 minutes per hour. That's too much. Temperature</div=
><div>2 is critical error: we are about to shut down completely due to it</=
div><div>being too hot. It's only a couple degrees below hardware power=
off</div><div>due to temperature in many drives. Some really cheap ones do=
n't really</div><div>implement it at all. On my card with the bad heat =
sink, Warning temp is</div><div>70C while critical is 75C while IIRC therma=
l shutdown is 78C or 80C.</div><div><br></div><div>I don't think we rep=
ort these values in nvmecontrol identify. But you can</div><div>do a raw du=
mp with -x look at bytes 266:267 for warning and 268:269</div><div>for crit=
ical.<br></div><div><br></div><div>In contrast, the few dozen drives that I=
have, all of which have been</div><div>abused in various ways, And only on=
e of them has any heat issues,</div><div>and that one is an engineering spe=
cial / sample with what I think is</div><div>a damaged heat sink. If your c=
ard has no heat sink, this could well</div><div>be what's going on.<br>=
</div><div><br></div><div>This panic means "the nvme card lost its min=
d and stopped talking</div><div>to the host". Its status registers rea=
d 0xff's, which means that the card</div><div>isn't decoding bus si=
gnals. Usually this means that the firmware on the</div><div>card has fault=
ed and rebooted. If the card is overheating, then this could</div><div>well=
be what's happening.</div><div><br></div><div>There's a tiny chanc=
e that this could be something more exotic,</div><div>but my money is on ha=
rdware gone bad after 2 years of service. I don't think</div><div>this =
is 'wear out' of the NAND (it's only 15TB written, but it could=
be if this</div><div>drive is really really crappy nand: first generation =
QLC maybe, but it seems</div><div>too new). It might also be a connector pr=
oblem that's developed over time.</div><div>There might be a few other =
things too, but I don't think this is a U.2 drive</div><div>with funky =
cables.</div><div><br></div><div>Warner<br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
> On Mon, Feb 12, 2024, 4:28=E2=80=AFPM Don Lewis <<a href=3D"mailto:=
truckman@freebsd.org" target=3D"_blank">truckman@freebsd.org</a>> wrote:=
<br>
> <br>
>> I just upgraded my package build machine to:<br>
>>=C2=A0 =C2=A0FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e<br=
>
>> from:<br>
>>=C2=A0 =C2=A0FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38<br=
>
>> and I've had two nvme-triggered panics in the last day.<br>
>><br>
>> nvme is being used for swap and L2ARC.=C2=A0 I'm not able to g=
et a crash<br>
>> dump, probably because the nvme device has gone away and I get an =
error<br>
>> about not having a dump device.=C2=A0 It looks like a low-memory p=
anic<br>
>> because free memory is low and zfs is calling malloc().<br>
>><br>
>> This shows up in the log leading up to the panic:<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to =
a<br>
>> timeout a<br>
>> nd possible hot unplug.<br>
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to =
a<br>
>> timeout a<br>
>> nd possible hot unplug.<br>
>> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complet=
e<br>
>> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o<br>
>> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping =
watchdog<br>
>> ti<br>
>> meout.<br>
>><br>
>> The device looks healthy to me:<br>
>> SMART/Health Information Log<br>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br>
>> Critical Warning State:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00<br>
>>=C2=A0 Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00<br>
>>=C2=A0 Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A00<br>
>>=C2=A0 Device reliability:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
0<br>
>>=C2=A0 Read only:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A00<br>
>>=C2=A0 Volatile memory backup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 0<br>
>> Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 312 K, 38.85 C, 101.93 F<br>
>> Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 100<br>
>> Available spare threshold:=C2=A0 =C2=A0 =C2=A0 10<br>
>> Percentage used:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 3<br>
>> Data units (512,000 byte) read: 5761183<br>
>> Data units written:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A029911502<br>
>> Host read commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0471921188<br>
>> Host write commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6053=
94753<br>
>> Controller busy time (minutes): 32359<br>
>> Power cycles:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0110<br>
>> Power on hours:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A019297<br>
>> Unsafe shutdowns:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A014<br>
>> Media errors:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00<br>
>> No. error info log entries:=C2=A0 =C2=A0 =C2=A00<br>
>> Warning Temp Composite Time:=C2=A0 =C2=A0 0<br>
>> Error Temp Composite Time:=C2=A0 =C2=A0 =C2=A0 0<br>
>> Temperature 1 Transition Count: 5231<br>
>> Temperature 2 Transition Count: 0<br>
>> Total Time For Temperature 1:=C2=A0 =C2=A041213<br>
>> Total Time For Temperature 2:=C2=A0 =C2=A00<br>
>><br>
>><br>
>><br>
<br>
<br>
</blockquote></div></div>
--00000000000059f3b006113cb621--
From nobody Tue Feb 13 13:12:51 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZ1w72rffz5BHJJ
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 13:12:55 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZ1w72H1Bz4HPK
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 13:12:55 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707829975;
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: references:references;
bh=mpsephCL1aYeikFvtyMfy/iYZxXgNOVMVN83jVb8HVo=;
b=ZXU/So4eF+L55fBK4JET7slwNE/fkRfYEEZlU1yOo9N9ulebSBdcmwHSuKhuY4cYbHbuYY
51R/qRAY//7g6abJhVjXgRJ5eiQ2frPYER+Ijt92s/5fJNORVCMq0ptcg4g3lk58cLeMEy
nPFCni2h7wZNZMXWhAiIG4hYJisPbKs6fnET683XA+wAnBmn+iDtwizOjT4okIM0aDJEX/
Gbv8DA0/yr6ztp1Gr/6pNtTUzeGxBx/5eQXUlGv0DJ59czRHJWome3jJVuest03VEWCXUH
40PhdlN+qMb8Cghp8QdVgP9rZ9ZXl5bqbDS6wixIQcme36n+tlf/vm4hpy7RlQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707829975; a=rsa-sha256; cv=none;
b=WzfJLyvKcgVrO/51ffKmenq1xm2OfTWKq7W/Uzfd9+wq2DN8rYe1lURrp54EqNyxGvUBM/
jNHzq8NdMa8DFyagSFw10cbvvS4aAPOar6o2wp+9/nwzwJxzrG5UPg/rvzZLWjXhD+2GwY
sw1Ia4czQBB9O0ZEVp7OX/K82KRcPqz/As2TSDNuDPwskx7mfz8eSMbdSO9XHUwr/qoc7m
vAGLd2VwMWPiYxAO2LpeB8AbUHEQCLZqnGlmLKEj5biKGlJ2xj2xiDlT1PDDxdIU+60TMd
H+9hbOe7s+BU6YKOoBVzDzfPWxAC+7PLx9JVJCoNBCchTFiYlVO1BlA9SJKIxQ==
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=1707829975;
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: references:references;
bh=mpsephCL1aYeikFvtyMfy/iYZxXgNOVMVN83jVb8HVo=;
b=mRJdLh7ziSwX/ESWmrFoVfyVCnpnbtv0hBJFqKhafz9mGZAGoMBHT0GlIIya9HSlVzaPPw
TuvvfSvlyt1AWn0jbeq/81xKs1ytYaOQFhyhYNiciixEj0yuJwDEwYbbowjQ5YQYHRJJnx
DCGvk3jkab9HyoVBvrSVuttf7JcEkkg078sF7uJ8rsklWmo/4G6E24/Psq96if+UkQWGo6
TTXdD6IjXoA5I0dcnBLv+HPB2xzTeNxnEkREjaIxJjJTPw/+wOsNxGTnxFQGUY7ut+/KSI
tAOrwI2HRL9Lr52MZwBVb0RZKVSNkxcmvHxyhNS95epD+YLlBvB+OVApwJHuJg==
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:cd45:5b11::2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: truckman)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZ1w64lN4z16yW
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 13:12:54 +0000 (UTC)
(envelope-from truckman@FreeBSD.org)
Received: from dl (uid 1001)
(envelope-from truckman@FreeBSD.org)
id 21a34c
by gw.catspoiler.org (DragonFly Mail Agent v0.13 on mousie.catspoiler.org);
Tue, 13 Feb 2024 05:12:52 -0800
Date: Tue, 13 Feb 2024 05:12:51 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: nvme controller reset failures on recent -CURRENT
To: Warner Losh <imp@bsdimp.com>
cc: Maxim Sobolev <sobomax@freebsd.org>,
FreeBSD current <freebsd-current@freebsd.org>,
John Baldwin <jhb@freebsd.org>
Message-ID: <tkrat.9717b2cdbbab83de@FreeBSD.org>
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
<CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
<tkrat.76b39844cd6da514@FreeBSD.org>
<CANCZdfrKeHJg5Tt-3cUq9hBgwwNqF4qnOWyFpF=TUjMdANOMfg@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=utf-8
Content-Transfer-Encoding: 8BIT
Content-Disposition: INLINE
On 12 Feb, Warner Losh wrote:
> On Mon, Feb 12, 2024 at 9:15 PM Don Lewis <truckman@freebsd.org> wrote:
>
>> On 12 Feb, Maxim Sobolev wrote:
>> > Might be an overheating. Today's nvme drives are notoriously flaky if you
>> > run them without proper heat sink attached to it.
>>
>> I don't think it is a thermal problem. According to the drive health
>> page, the device temperature has never reached Temperature 2, whatever
>> that is. The room temperature is around 65F. The system was stable
>> last summer when the room temperature spent a lot of time in the 80-85F
>> range. The device temperature depends a lot on the I/O rate, and the
>> last panic happened when the I/O rate had been below 40tps for quite a
>> while.
>>
>
> It did reach temperature 1, though. That's the 'Warning this drive is too
> hot' temperature. It has spent 41213 minutes of your 19297 hours of up
> time, or an average of 2 minutes per hour. That's too much. Temperature
> 2 is critical error: we are about to shut down completely due to it
> being too hot. It's only a couple degrees below hardware power off
> due to temperature in many drives. Some really cheap ones don't really
> implement it at all. On my card with the bad heat sink, Warning temp is
> 70C while critical is 75C while IIRC thermal shutdown is 78C or 80C.
>
> I don't think we report these values in nvmecontrol identify. But you can
> do a raw dump with -x look at bytes 266:267 for warning and 268:269
> for critical.
>
> In contrast, the few dozen drives that I have, all of which have been
> abused in various ways, And only one of them has any heat issues,
> and that one is an engineering special / sample with what I think is
> a damaged heat sink. If your card has no heat sink, this could well
> be what's going on.
>
> This panic means "the nvme card lost its mind and stopped talking
> to the host". Its status registers read 0xff's, which means that the card
> isn't decoding bus signals. Usually this means that the firmware on the
> card has faulted and rebooted. If the card is overheating, then this could
> well be what's happening.
>
> There's a tiny chance that this could be something more exotic,
> but my money is on hardware gone bad after 2 years of service. I don't think
> this is 'wear out' of the NAND (it's only 15TB written, but it could be if
> this
> drive is really really crappy nand: first generation QLC maybe, but it seems
> too new). It might also be a connector problem that's developed over time.
> There might be a few other things too, but I don't think this is a U.2 drive
> with funky cables.
The system was probably idle the majority of those two years of power on
time.
It's one of these:
https://www.techpowerup.com/ssd-specs/intel-660p-512-gb.d437
I've seen comments that these generally don't need cooling.
I just ordered a heatsink with some nice big fins, but it will take a
week or more to arrive.
>
>> > On Mon, Feb 12, 2024, 4:28 PM Don Lewis <truckman@freebsd.org> wrote:
>> >
>> >> I just upgraded my package build machine to:
>> >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
>> >> from:
>> >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
>> >> and I've had two nvme-triggered panics in the last day.
>> >>
>> >> nvme is being used for swap and L2ARC. I'm not able to get a crash
>> >> dump, probably because the nvme device has gone away and I get an error
>> >> about not having a dump device. It looks like a low-memory panic
>> >> because free memory is low and zfs is calling malloc().
>> >>
>> >> This shows up in the log leading up to the panic:
>> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
>> >> timeout a
>> >> nd possible hot unplug.
>> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> >> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
>> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
>> >> timeout a
>> >> nd possible hot unplug.
>> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
>> >> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
>> >> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
>> >> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
>> >> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping
>> watchdog
>> >> ti
>> >> meout.
>> >>
>> >> The device looks healthy to me:
>> >> SMART/Health Information Log
>> >> ============================
>> >> Critical Warning State: 0x00
>> >> Available spare: 0
>> >> Temperature: 0
>> >> Device reliability: 0
>> >> Read only: 0
>> >> Volatile memory backup: 0
>> >> Temperature: 312 K, 38.85 C, 101.93 F
>> >> Available spare: 100
>> >> Available spare threshold: 10
>> >> Percentage used: 3
>> >> Data units (512,000 byte) read: 5761183
>> >> Data units written: 29911502
>> >> Host read commands: 471921188
>> >> Host write commands: 605394753
>> >> Controller busy time (minutes): 32359
>> >> Power cycles: 110
>> >> Power on hours: 19297
>> >> Unsafe shutdowns: 14
>> >> Media errors: 0
>> >> No. error info log entries: 0
>> >> Warning Temp Composite Time: 0
>> >> Error Temp Composite Time: 0
>> >> Temperature 1 Transition Count: 5231
>> >> Temperature 2 Transition Count: 0
>> >> Total Time For Temperature 1: 41213
>> >> Total Time For Temperature 2: 0
>> >>
>> >>
>> >>
>>
>>
>>
From nobody Tue Feb 13 15:16:14 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 4TZ4gh22KYz5BW08
for <current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 15:17:20 +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 4TZ4gg5w48z4ZMn;
Tue, 13 Feb 2024 15:17:19 +0000 (UTC)
(envelope-from Alexander@Leidinger.net)
Authentication-Results: mx1.freebsd.org;
none
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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=1707833826;
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=wVNIJjftb4PvSVtzLcJErwHFXu+pYA/0NKRHx7qQ1tA=;
b=rGzLWJ2tNHDMBfyT4p7flPLO6A3TOiOx2sLtEXvaX/ouEpjAdYbN0yGUDuAyj6T/UcI4Xo
mxI6KcDOZxYOyjgqJJOg4zHMhqQHD1aONtR54uZLmk3AI2JG+N/Y2ghB0vsTDC0ztbwKkP
kdZ7IdHGgMqh3ulWaBpGvm9ERdablqi5cJCZksT12/seFkULz+z8Ezhy1lUBIpm+1+sk4v
49VOll/ikKOosirNU3xud4GZrAbmvITJ5oFJZrJl4KrVlGjrKlvHnGtNZuV9f0lm0Vub+f
xBK5xKHjjhlfvqG7ITDklnImvKjtEG6MYTAWgWL1HngAq/+Dqmc9W5J8fehwHA==
Date: Tue, 13 Feb 2024 16:16:14 +0100
From: Alexander Leidinger <Alexander@Leidinger.net>
To: Konstantin Belousov <kib@freebsd.org>
Cc: Alexander Leidinger <alexleidingerde@gmail.com>, current@freebsd.org
Subject: Re: segfault in ld-elf.so.1
In-Reply-To: <Zcq-oU_4X7o_TfND@kib.kiev.ua>
References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org>
<CAJg7qzFV2bY14tn1-wdpeBb5W1XeZ7v6bk3Qhf5A=hV98kSXFw@mail.gmail.com>
<ZcnqtY0dQoed9yjw@kib.kiev.ua> <Zcq-oU_4X7o_TfND@kib.kiev.ua>
Message-ID: <bf350a2507ecf9185d98120da0663e25@Leidinger.net>
Organization: No organization, this is a private message.
Content-Type: multipart/signed;
protocol="application/pgp-signature";
boundary="=_f725242c86850af7c6b4e976eb858030";
micalg=pgp-sha256
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: 4TZ4gg5w48z4ZMn
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--=_f725242c86850af7c6b4e976eb858030
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Am 2024-02-13 01:58, schrieb Konstantin Belousov:
> On Mon, Feb 12, 2024 at 11:54:02AM +0200, Konstantin Belousov wrote:
>> On Mon, Feb 12, 2024 at 10:35:56AM +0100, Alexander Leidinger wrote:
>> > Hi,
>> >
>> > dovecot (and no other program I use on this machine... at least not that I
>> > notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
>> > to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
>> > have been fixed by changes to libc/libsys since 2024-02-10-144617). The
>> > issue shows up when I try to do an IMAP login. A successful authentication
>> > starts the imap process which immediately segfaults.
>> >
>> > I didn't recompile dovecot for the initial update, but I did now to rule
>> > out a regression in this area (and to get access via imap do my normal mail
>> > account).
>> >
>> >
>> > Backtrace:
>> The backtrace looks incomplete. It might be the case of infinite
>> recursion,
>> but I cannot claim it from the trace.
>>
>> Does the program segfault if you run it manually? If yes, please
>> provide
No.
>> me with the tarball of the binary and all required shared libs,
>> including
>> base system libraries, from your machine.
>
> Regardless of my request, you might try the following. Note that I did
> not tested the patch, ensure that you have a way to recover ld-elf.so.1
> if something goes wrong.
>
[inline patch]
This did the trick and I have IMAP access to my emails again. As this
runs in a jail, it was easy to test without fear to kill something.
I will try the patch in the review next.
Bye,
Alexander.
--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
--=_f725242c86850af7c6b4e976eb858030
Content-Type: application/pgp-signature;
name=signature.asc
Content-Disposition: attachment;
filename=signature.asc;
size=833
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXLh80ACgkQEg2wmwP4
2IaGhw/+LJBE50rDUsWWsa9urrDUc3Mdh2CHfofApji0faUkWrdFajTWq6rO3s9R
eiHlK+y2SB7qAoQQIMMRGYTrfqE8bycZBwsWBcZcH/CJjKTdI94sEUG8MCVN/RY3
1boKd6ICk7caKYUapRzObSgze8uVPHO9JxmBgX+PKp0J0dNH3g2Pp2Uoonyvo5qa
G7UsL3+Jt1Kg5FTDrNcU5GOf801KwYnFd6FnB6RSjzVf87osHnEBxHvrureXfUzN
ci+f2CRkIOUe4NP4i8xprxDfzOQ0g/5b27RODKHsxVg4H8ovn4iWkm80fVmYxJxl
RnjYc5jta4MvuHuyPeK3B/iWcV0uKcXm0jlX11dV7mBTs7fArhZ1bjFltgg2nVG/
h4aFHZzEOPQOLmFMvcNbUvxViBvl6GYNtWGztFh3nMGF7RQ2PjadgMmGmsQr2dfe
u9tCc7Kp0bnzoXZcWKu3sEaQWF8eDZAuQt+jSnhpA88QPmSZJld5Tmel7Ss9O5aY
w97SiJtSEaO0NALMCnhdhrNILGn1z9ThCyL8zNc0fao31FjTCSiC4BYprNDCta/Q
LxgG7hJQ4s/Z0su6Vo6lwciSxgPrhbvSj092Db+v+dHD4yAnajeaaCfNXZPHE0cG
r5xwV12oom9MvEBbXJpfCuZxVVCgBAyUf1DjuG/FgiOnbFBaQvY=
=rnA/
-----END PGP SIGNATURE-----
--=_f725242c86850af7c6b4e976eb858030--
From nobody Tue Feb 13 19:56: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 4TZBtY3jGRz59dRL
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 19:57:09 +0000 (UTC)
(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
(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 4TZBtX6ZlFz4K3t;
Tue, 13 Feb 2024 19:57:08 +0000 (UTC)
(envelope-from pete@nomadlogic.org)
Authentication-Results: mx1.freebsd.org;
none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org;
s=04242021; t=1707854209;
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=GRGggJYJjz+0MeLRAeEWM2R37InBbW1RkQNT3b1Hzws=;
b=Wjp8gtrUwLv8ZN8zNWRRdlu3zBYvP3VCeNpvj6/R8eoglfILYMBfUlJWZYzECTP+tMH1MR
S2+Az9vtasbDDiQz0jSEXjQZjrB6RHDeLROTMTtHksFL5QzVKnhLMCGQrBx2JqSXa1O6VF
NrhziPDr4z1ngichtOxEeOafewJQtj8=
Received: from [192.168.1.160] (<unknown> [47.150.83.63])
by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id c67f3c74 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Tue, 13 Feb 2024 19:56:48 +0000 (UTC)
Message-ID: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org>
Date: Tue, 13 Feb 2024 11:56:52 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: nvme controller reset failures on recent -CURRENT
Content-Language: en-US
To: Don Lewis <truckman@FreeBSD.org>, Warner Losh <imp@bsdimp.com>
Cc: Maxim Sobolev <sobomax@freebsd.org>,
FreeBSD current <freebsd-current@freebsd.org>, John Baldwin <jhb@freebsd.org>
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
<CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
<tkrat.76b39844cd6da514@FreeBSD.org>
<CANCZdfrKeHJg5Tt-3cUq9hBgwwNqF4qnOWyFpF=TUjMdANOMfg@mail.gmail.com>
<tkrat.9717b2cdbbab83de@FreeBSD.org>
From: Pete Wright <pete@nomadlogic.org>
In-Reply-To: <tkrat.9717b2cdbbab83de@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]
X-Rspamd-Queue-Id: 4TZBtX6ZlFz4K3t
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
>> There's a tiny chance that this could be something more exotic,
>> but my money is on hardware gone bad after 2 years of service. I don't think
>> this is 'wear out' of the NAND (it's only 15TB written, but it could be if
>> this
>> drive is really really crappy nand: first generation QLC maybe, but it seems
>> too new). It might also be a connector problem that's developed over time.
>> There might be a few other things too, but I don't think this is a U.2 drive
>> with funky cables.
> The system was probably idle the majority of those two years of power on
> time.
>
> It's one of these:
> https://www.techpowerup.com/ssd-specs/intel-660p-512-gb.d437
> I've seen comments that these generally don't need cooling.
>
> I just ordered a heatsink with some nice big fins, but it will take a
> week or more to arrive.
just wanted to add another data-point to this discussion. i had a
crucial NVME drive on my workstation that recently was showing similar
problems. after much debugging i came to the same conclusion that it
was getting too hot. i went ahead an purchased a Sabrent NVME drive
that came with a heat sink. i've also starting making much more use of
my workstation (and the disk subsystem) and have had zero issues.
so lessons learnt:
1. M.2 nvme really does need proper cooling, much more so than
traditional SATA/SAS/SCSI drives.
2. not all vendors do a great job reporting the health of devices
-pete
--
Pete Wright
pete@nomadlogic.org
From nobody Tue Feb 13 20:39:47 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZCqp4lHDz59k4K
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 20:39:50 +0000 (UTC)
(envelope-from leres@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZCqp2ttRz4Qlp;
Tue, 13 Feb 2024 20:39:50 +0000 (UTC)
(envelope-from leres@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707856790;
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=CGIOKJ9dperaCJvDdWumwLAuoZuvrLdonENCSKzdZZE=;
b=rb6ewpGdagaOc9shUi4iIML58fpa3LZly0mtuUysPvSL9li0TCCBTQATD3cF+cts8RqwwO
3HNCbI1TXF+jrdReg0nqDMyz94HVjt6lLkCxUSts3vyYMMZOR0n29py/vkRL9vMyggf7wn
1EtXVmIa4UZX33OrrzZkpOBUD4T6zavxAKP9/LJxVGuJM51u6C4swvmFvW5gs9bI8CAvgj
mYA84DcbPnsWRKrP6BumxQDk+Dy9fic9mGUeO4pOJSaTutdGcenhNtP/en4YfRuG9aqNKo
cjDZhMAa4SkzYp9aEUfxpIO21E/aIEadMK8aAbN1Fff/w2Cs7sJj9LhSMX/X+A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707856790; a=rsa-sha256; cv=none;
b=ZMRyW193ZQ7NxA3EoXmtFBTsvHY7DhuI+tpiMFmUI/PZ6uHbb4k+XPVocVHGXJOsyzrifF
yhyjB7h66dASV9gCzbUPqnl2z1HsLXuz1ONqItP11xwf53z9wTtovW+2/bCQnn9zeAIaRY
7BP1D8CoO/Fag4CEd8CmOUHw8qBQ80AjtCsxHN6Ha+V5KB/WxR0EKVNlADISodF3JXAv5R
Nli4CFD0efSJzx+BfN/jUgLmg3gQtgBxc9dvPeHzc4DxQNp9QLZqQT7TZcDgqcb6Yogikw
iNsakSqY68ZoGGs5yGOgUfgSzpAwNX1lYTA/tHoM6uEggjfVuEEkKHxDkInWCA==
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=1707856790;
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=CGIOKJ9dperaCJvDdWumwLAuoZuvrLdonENCSKzdZZE=;
b=FpFoQaXXiaiaaJc1Y8X7rAb7uFhR8C/FA+I4IXDMzGCOnbC8OmxJguqWUblMNjh6QT/gWL
XketigWVFs2s181XkMYCochM2JJagb+UmhSm83lEuZRfwNZS6IRk0G+39h9+htpmIvnZ0X
OmRTZPs5uJSHsBGuOlAcWEGGHIPlIMetnJmEtb3hfgMVn6hznqjsBuo9HlaASSi/KxOxRe
qrFw34eYQoErWBHyJfCDRYHslcjRAsxBvgcLdOH1A6gg8UNKqUmzC72UoP6ppduxKaw43P
DhMMTJgiqDwkPQo2wkO1sti7jjJAgLbXpNuEXlF4c6HEmtauYvcpdSdOt7isYg==
Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: leres)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZCqn592pz1GRZ;
Tue, 13 Feb 2024 20:39:49 +0000 (UTC)
(envelope-from leres@freebsd.org)
Message-ID: <a58b17d2-7946-4316-b441-fa300206dd83@freebsd.org>
Date: Tue, 13 Feb 2024 12:39:47 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: nvme controller reset failures on recent -CURRENT
Content-Language: en-US
To: Pete Wright <pete@nomadlogic.org>, Don Lewis <truckman@FreeBSD.org>,
Warner Losh <imp@bsdimp.com>
Cc: Maxim Sobolev <sobomax@freebsd.org>,
FreeBSD current <freebsd-current@freebsd.org>, John Baldwin <jhb@freebsd.org>
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
<CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
<tkrat.76b39844cd6da514@FreeBSD.org>
<CANCZdfrKeHJg5Tt-3cUq9hBgwwNqF4qnOWyFpF=TUjMdANOMfg@mail.gmail.com>
<tkrat.9717b2cdbbab83de@FreeBSD.org>
<65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org>
From: Craig Leres <leres@freebsd.org>
In-Reply-To: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I had issues with a nvme drive in an intel nuc. When I asked
freebsd-hackers, overheating was the first guess:
https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052783.html
I blew the dust out of the fan assembly and changed the bios fan
settings to be more aggressive and the system has been rock solid since.
Craig
From nobody Tue Feb 13 20:45:57 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZCz80RvRz59kjV
for <freebsd-current@mlmmj.nyi.freebsd.org>; Tue, 13 Feb 2024 20:46:12 +0000 (UTC)
(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZCz66pf3z4SqM
for <freebsd-current@freebsd.org>; Tue, 13 Feb 2024 20:46:10 +0000 (UTC)
(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
dkim=none;
dmarc=none;
spf=pass (mx1.freebsd.org: domain of pmh@hausen.com designates 217.29.33.228 as permitted sender) smtp.mailfrom=pmh@hausen.com
Received: from smtpclient.apple (87.138.185.145)
by mail2.pluspunkthosting.de (Axigen)
with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 1372A4;
Tue, 13 Feb 2024 21:46:09 +0100
From: "Patrick M. Hausen" <pmh@hausen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Subject: Re: nvme controller reset failures on recent -CURRENT
Date: Tue, 13 Feb 2024 21:45:57 +0100
References: <tkrat.edddc2469f43baf6@FreeBSD.org>
<CAH7qZfunD154VYPD1vh_GNtOMM-quX=S00iQGvrpbhaegpXRnw@mail.gmail.com>
<tkrat.76b39844cd6da514@FreeBSD.org>
<CANCZdfrKeHJg5Tt-3cUq9hBgwwNqF4qnOWyFpF=TUjMdANOMfg@mail.gmail.com>
<tkrat.9717b2cdbbab83de@FreeBSD.org>
<65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org>
To: FreeBSD current <freebsd-current@freebsd.org>
In-Reply-To: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org>
Message-Id: <CB1FCE1E-83DF-4134-B2D0-1483A0DB0464@hausen.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.80 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-0.997];
MV_CASE(0.50)[];
R_SPF_ALLOW(-0.20)[+a:mail2.pluspunkthosting.de];
MIME_GOOD(-0.10)[text/plain];
RCVD_VIA_SMTP_AUTH(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
RCVD_COUNT_ONE(0.00)[1];
ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
MIME_TRACE(0.00)[0:+];
RCVD_TLS_ALL(0.00)[];
R_DKIM_NA(0.00)[];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
DMARC_NA(0.00)[hausen.com];
TO_DN_ALL(0.00)[];
ARC_NA(0.00)[]
X-Rspamd-Queue-Id: 4TZCz66pf3z4SqM
Hi all,
> Am 13.02.2024 um 20:56 schrieb Pete Wright <pete@nomadlogic.org>:
> 1. M.2 nvme really does need proper cooling, much more so than =
traditional SATA/SAS/SCSI drives.
I recently found a tool named "Scrutiny" that presents a nice dashboard
of all your disk devices and their SMART data including crucial points
like temperature.
Pros:
Open source
Nice web UI
Uses smartmontools to gather the data, not reinventing the wheel
Agents that can be called from cron jobs for many OSes including FreeBSD
Alerting via a variety of communication channels
Cons:
Central hub best run on Linux plus docker compose
No authentication whatsoever, so strictly internal use
No grouping or any organisation of systems so does not scale beyond tens =
of servers
I found a couple of problematic HDDs and SSDs right after deploying it
which regular SMART tests overlooked.
https://github.com/AnalogJ/scrutiny
Look for the Hub/Spoke deployment if you are willing to use e.g.
a Linux VM to run the tool, then point your FreeBSD systems at that.
It probably can be deployed strictly on FreeBSD, too, using the manual
installation instructions.
HTH, kind regards,
Patrick=
From nobody Wed Feb 14 11:46:56 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 4TZbyh4pdBz59Zxr
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 11:47:08 +0000 (UTC)
(envelope-from eduardo@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZbyh4KgDz4TZl
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 11:47:08 +0000 (UTC)
(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707911228;
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=EXFmgQeO2AJPyjHTbpFsOUpi3CcV5aJOlapJF18w6T8=;
b=HiIKhX8DzfCmdo2gayBz24h6Yt3b8DfNNzznW0lpbrajLwKnyRclGLnz2NmRwrf53gUd/0
0loenpt3adZuqn75p+7U3tl9KhsmB+BHOlVZOzdtldj/kx2By9RreWpP+IUF86X+ZFkcBr
mxun4y/hnrdSQEClr+zxyoBObagF1a0fJWMGgqYs3Xp4xnXp8aW1/S521QL/l0eUTgZJMI
kejA426l+KNpZjd0P8BxL/IJVCP0gtKxE5iIz0i1Sqispjs+XE/xpLF5lsSUs9x4dBGF5e
J+TG1hfDDWNftjSUozhIkHVQNJjm5UvlWxmOhtvZHJqNrondoya4pbflld1kGA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707911228; a=rsa-sha256; cv=none;
b=oZaiaXyQRyOJIkszdZxKeCWJm632s25HKjzGyZbWoy2sibHwlSj8gufZ/yL33Htka+ygYE
CvU1c0UI943zYMjbCqtIDEZvTwf86oGKYxiFQ+X5DukForamtlIFxvlhQ//sbHCHw0qGKp
NWzjoTNyUQKxM7Te2PguVSpook4tHjETUuKPXbLT7rB65XNey2QR46Z6X6UDFWsJieYukS
sOxQDpByvf0wyy2+f3dqzVutSN+P7JEwfUT9P3pBdXK1E5pzbzFfY5MmjxsJVyOboX+ook
CI7jocMPj8vVXQ3FvlYikrUfLx8jf+P0TjFnPJ/bqL4lb848kVh8bRMjtt68rA==
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=1707911228;
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=EXFmgQeO2AJPyjHTbpFsOUpi3CcV5aJOlapJF18w6T8=;
b=xUSADG/eSkvX90+uR6vpnuSfnSbODUZff/t6MCnPIWyAZLIMB6BaEF87AodwokpMvC55NM
c4uQHGtYkLnRUj3vM6c1tmFtMOhnIivBmNKeBJUk6ZiHHbMD0jbjkiczfafKb1YLPnq2Tu
W1NMb7aA0q4zBTlwZKkHRhUSC7I2etJlNPbNnE1u2puoHCF8Q65DTFkP9Ui2BU3DM2w24i
+keQJfVVZDl/S8IMEBhbQFKcxi7mTRTNxkDIgDrcdP+AcnOp8yYHE+c/+XrOlbgEeAS2Re
w0Jm/KIEbbXqYkScQJdWr8RTOMDOfWELZk0UtTllIIrO8na452WzCWRzkbfVow==
Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170])
(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))
(Authenticated sender: eduardo)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZbyh3GjMzKf9
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 11:47:08 +0000 (UTC)
(envelope-from eduardo@freebsd.org)
Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-42c7c1cb2e9so7849211cf.3
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 03:47:08 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWptFYHmItus4pbLN3SlqQIb2ynw2BmQ9klOl9yjrkZgKvdIxO8dUdIwKARTSKjep1L7i/HUwOUpAHZjeqgHF5tN2MST3X+E72xMhs=
X-Gm-Message-State: AOJu0Yyap6U6oK2cNUA72wAJhMstMqFfqoJAuFa21QEG2PiTxE2gPadX
0M1y6NNq/qVTqSG2yVwfXl2GMGRwG+478+2w2/86cxmRMbYZxRY10/UFc3dj8kfdDBxet5TfrT0
+J16hOooBAvKkkTHRExZmxaiOP5Y=
X-Google-Smtp-Source: AGHT+IEprrFOy25VoSwJs5yI7dOyYHd6Fozxiz+bfg7fvTrPlrzzi9K3Vqr8b7Ld2vilRYYTYdoshX/fBIJOPU05Bv4=
X-Received: by 2002:ac8:1244:0:b0:42d:bf5e:70dd with SMTP id
g4-20020ac81244000000b0042dbf5e70ddmr732376qtj.26.1707911227801; Wed, 14 Feb
2024 03:47:07 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <8c42cc06-d3de-432e-82ab-7fe040197223@app.fastmail.com> <71141.1706406125@kaos.jnpr.net>
In-Reply-To: <71141.1706406125@kaos.jnpr.net>
From: Nuno Teixeira <eduardo@freebsd.org>
Date: Wed, 14 Feb 2024 11:46:56 +0000
X-Gmail-Original-Message-ID: <CAFDf7U+jmc9oEYTDSN83AFuTA1a-W6Z_RSqPHG=0nQDFP8W44w@mail.gmail.com>
Message-ID: <CAFDf7U+jmc9oEYTDSN83AFuTA1a-W6Z_RSqPHG=0nQDFP8W44w@mail.gmail.com>
Subject: Re: meta mode
To: "Simon J. Gerraty" <sjg@juniper.net>
Cc: void <void@f-m.fm>, freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Can we say that META is for speeding consecutives builds tracking
current/stable and META + DIRDEPS for developing/testing specific
parts of base code with speed + debug in mind?
Simon J. Gerraty <sjg@juniper.net> escreveu (domingo, 28/01/2024 =C3=A0(s) =
01:43):
>
> > I use meta-mode in /etc/src-env.conf so that if (for example) a small
> > change in the kernel config is made, the machine doesn't take hours
> > recompiling.
>
> > But, from time to time, one might be required to make
> > cleanworld && make cleandir (to be sure) && make clean (to be *really* =
sure)
>
> Almost never (as Warner said).
> I have trees that go for years without ever being cleaned.
> Unless I'm collecting timing data for clean tree builds.
>
> If you use DIRDEPS_BUILD as well as META_MODE, there can be cases where
> you need the stage tree cleaned (staging is like auto-install to
> DESTDIR). The most common case is when a library has switched from
> staging its headers from $STAGE_ROOT/$MACHINE/usr/include to
> $STAGE_ROOT/common/usr/include (so they only get staged once), if you
> don't clean out $STAGE_ROOT/$MACHINE/usr/include, builds will continue to
> find headers there that should be found in
> $STAGE_ROOT/common/usr/include and thus revert Makefile.depend changes.
> We added a mechanism to allow triggering auto-clean of stage tree when su=
ch
> changes are made.
>
> --sjg
>
--=20
Nuno Teixeira
FreeBSD Committer (ports)
From nobody Wed Feb 14 16:08:37 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZjmT2M8wz5BFhr;
Wed, 14 Feb 2024 16:08:41 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZjmT1r5hz45dx;
Wed, 14 Feb 2024 16:08:41 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707926921;
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=h/9057JLSucUzDn0y2NbBakKBsDjDVq0e9ZdHAvInfg=;
b=eb1klHDE9V+Mrn52KhDuXMf24igekCq5PL3xerBqtNKHKwuLwoSNHopkeN71y5NR05mO9R
e2p3zhk0eNQKWXmjFdc9BIWabbfoC+JhzAL3A/cRH8Kp36SPsPehNWF0ChpRMdj78NijSi
zb4CQvf2nk5HSdCqI9z8l4lNHGGIHHYb3mk/JY4qBRWPkjchoandiVxbrzTR3hd26gKtB7
BH83Pm0x6sCNfG471g23qFdMS9chDRdyPZa5IXMUs2/WybF3YkjsjYQRi/LqTDkRRcCYtL
+vy4O9kVr+j57WTZhwWc91L0n5BBJuhf08LlArJja4NSsaRw4euWciwfxAjyYQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707926921; a=rsa-sha256; cv=none;
b=m5QuIKaGUme/KVnjhrF9h/5uQTk6X1nXKYiJUpYR9Ogfj7x0D7icsnCKGIYBRnJd9ACdy/
zZJ10gBWXLrlyNTwnit6+ujCsqqp0VbwOLcUbCS53MKq1DS4XelDdYbeAWrjNHYktxJI+t
+GwDFvTVf1l1UaPpEpNX7IpbjOGkbS7zODtqq+OXtFGNNYlWwjsA4AvWywyZ3f7EqR3G9T
8pAasI/FxgOD+Qz6kjAN9dv7bb7Ei3YunKmEudrURZpZ9eQCmsBngtutpBdbSlA5DaoEne
qfOYadsmsduN+pnDppanyNjvR+V12YiYz59fhDFzl0oZ/JOYMu3U3DPzRN0+Bw==
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=1707926921;
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=h/9057JLSucUzDn0y2NbBakKBsDjDVq0e9ZdHAvInfg=;
b=uAFe+XVcMYwBqBiqFB7UQ+MXuGXXOeIFC5OwODxmSeMOoiK1QIBE5GPGNJh6/le+UIQFZc
hHHHc2LXaBSmYobF9IRnclZOGUGPUvWU1JxBgDns9k1SNRiZh700lWlHfpZXBPj8KrRXXX
vzENceLr4xHEEYCtPJdqPHYB42ciHbMFvnK+h0sTl1DFscieciyesjDXBJAZbS2FPAQW2y
XYHD7dZc9qRnuJZ4Kh+NEDPy2HST8OUl06LYchEmAUQW3LmxPcCBZYide5x39aZEs4/qz/
Em5GJd1DtD6jcwOe74gRW5QVKy8e4N2nM1huWjy0C+SGnsXia2sGaJX0fNhMgg==
Received: from [IPV6:2601:644:937c:5920:4c63:23c7:5c22:d7ba] (unknown [IPv6:2601:644:937c:5920:4c63:23c7:5c22:d7ba])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZjmS3sx7zNsB;
Wed, 14 Feb 2024 16:08:40 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
Date: Wed, 14 Feb 2024 08:08:37 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Mark Millard <marklmi@yahoo.com>
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/12/24 5:57 PM, Mark Millard wrote:
> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
>
>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>>
>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>
>>>> [Gack: I was looking at the wrong vintage of source code, predating
>>>> your changes: wrong system used.]
>>>>
>>>>
>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>>
>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>>
>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>>> Summary:
>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>>>>>>> . . .
>>>>>>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
>>>>>>> panic: Failed to add resource to rman
>>>>>>
>>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource works which is
>>>>>> fundamentally broken. It rewrites the start address of a resource in-situ instead
>>>>>> of keeping downstream resources separate from the upstream resources. For example,
>>>>>> I don't see how you could ever release a resource in this design without completely
>>>>>> screwing up your rman. That is, I expect trying to detach a PCI device behind a
>>>>>> translating bridge that uses the current approach should corrupt the allocated
>>>>>> resource ranges in an rman long before my changes.
>>>>>>
>>>>>> That said, that doesn't really explain the panic. Hmm, the panic might be because
>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the bus_translate_resource
>>>>>> hack only kicks in the activate_resource method of pci_host_generic.c.
>>>>>>
>>>>>>> Detail:
>>>>>>> . . .
>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>>>>>>
>>>>>> This indicates this is a translating bus.
>>>>>>
>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000
>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested 0x100000)
>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>>> allocating from the beginning
>>>>>>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
>>>
>>> What you later typed does not match:
>>>
>>> 0x600000000
>>> 0x6000fffff
>>>
>>> You later typed:
>>>
>>> 0x60000000
>>> 0x600fffffff
>>>
>>> This seems to have lead to some confusion from using the
>>> wrong figure(s).
>>>
>>>>>> The fact that we are trying to reserve the CPU addresses in the rman is because
>>>>>> bus_translate_resource rewrote the start address in the resource after it was allocated.
>>>>>>
>>>>>> That said, I can't see why rman_manage_region would actually fail. At this point the
>>>>>> rman is empty (this is the first call to rman_manage_region for "pcib1 memory window"),
>>>>>> so only the check that should be failing are the checks against rm_start and
>>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end is always
>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new (0x60000000 - 0x600fffffff)
>>>>>> ranges are within those bounds.
>>>
>>> No:
>>>
>>> 0xffffffff
>>>
>>> .vs (actual):
>>>
>>> 0x600000000
>>> 0x6000fffff
Ok, then this explains the failure if the "raw" addresses are above 4G. I have
access to an emag I'm currently using to test fixes to pci_host_generic.c to
avoid corrupting struct resource objects. I'll post the diff once I've got
something verified to work.
> It looks to me like in sys/dev/pci/pci_pci.c the:
>
> static void
> pcib_probe_windows(struct pcib_softc *sc)
> {
> . . .
> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
> . . .
>
> is just inappropriately restrictive about where in the system
> address space a PCIe can validly be mapped to on the high end.
> That, in turn, leads to the rejection on the RPi4B now that
> the range use is checked.
No, the physical register in PCI-PCI bridges is only 32-bits. Only the
prefetchable BAR supports 64-bit addresses. This is why the host bridge
is doing a translation from the CPU side (0x600000000) to the PCI BAR
addresses (0xc0000000) so that the BAR addresses are down in the 32-bit
address range. It's also true that many PCI devices only support 32-bit
addresses in memory BARs. 64-bit BARs are an optional extension not
universally supported.
The translation here is somewhat akin to a type of MMU where the CPU
addresses are mapped to PCI addresses. The problem here is that the
PCI BAR resources need to "stay" as PCI addresses since we depend on
being able to use rman_get_start/end to get the PCI addresses of
allocated resources, but pci_host_generic.c currently rewrites the
addresses.
Probably I should remove rman_set_start/end entirely (Warner added them
back in 2004) as the methods don't do anything to deal with the fallout
that the rman.rm_list linked-list is no longer sorted by address once
some addresses get rewritten, etc.
--
John Baldwin
From nobody Wed Feb 14 16:42:36 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 4TZkWt1qCQz50y0p
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 16:42:50 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535])
(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 4TZkWs3YNBz49yd
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 16:42:49 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-561587ce966so1892623a12.1
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 08:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1707928968; x=1708533768; 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=nU/C/L6NJboRjZ/WwavYS7/vNGqdk8Pa7agypyoDG/0=;
b=FrfSwvqKY97+6UXh3/7Ae1lng/09/GfKdcFjGeicRnTM8wg7PhTJFu61zTmIkY6+2w
Oh8aUoXgL3amc55cDJSTvj17wENDDU27GQw3i+q/R8JgioYMFyU+V0GzDRupHp7R959q
RIh+dg+j4x4M6iVn5SMfO3vurAWZhXrCRVqv4sWQnCePW6ylbiH8GJC9v0fXUz03NloA
+QemISutfbIYrzHvpwFW0zkYywz9VknZacRXusGbeN9iQ2TTJe9MLFinIEO0lTZg6fN6
CH/D//2bFwc3J+rn8/JaRpS1BLSwwDDMooMjDvd9SuEof2z1AxPOECJUNPDOMzyBRxWK
k1jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707928968; x=1708533768;
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=nU/C/L6NJboRjZ/WwavYS7/vNGqdk8Pa7agypyoDG/0=;
b=jN4GmCG0Mewo5Iq600NbiRmg4gluFehc/CdHrJdzGEVuHSpfR3A79S9YEQgsx2RGmY
1cPbHNJTkfxTtBFsH9CV8jg32kTfH4QV+1MaxMAF56Z5Ho9tS/W/Xq/KAgD1JYkwwY69
7SrC5j4auJagrCF5NfgQ0DG9J0yf/CCh03C6nnLDL7GJbmxF/BqPZC4eh4Q+hI28oNk8
qQsj6nHFSj+QfiSbO6i2P6KvSarSXehrF3Cg2n5TdJq0x+a2m2ze7zTJ1X4mt+7ME0df
599eaIlTWyCFDdP8iXNPj29sX7QXd3pZ/tG0DAq8x5ax1IoMg5y3KxTlERWSyHOqRcgP
UdSQ==
X-Forwarded-Encrypted: i=1; AJvYcCWKwiloJYu8ccKccU6rgzPlFlJ7hZ1ftnW8EZzt35uaX4g58KKiUXlXG55ltQnJf5ES8lZ9xatDJGgNVQOJlNL8yyNGQOXskuGDTJU=
X-Gm-Message-State: AOJu0Yw8hV+eom5PIY+nQaH6CJfHzkt8vCv0zfVgBstL+KIhqm1MP4+9
N+tZHmhg2nl4FplSGNZw5znBnkYIPlWg1qbu9exOc0RpYRuCltl18lMGTBCqCifYd5ug8vCqkvN
5gEoWHztx1vD52/sCxxawMhPcVJPqbx3sp2V/1g==
X-Google-Smtp-Source: AGHT+IGmRp0UgqfN56Q3LCOBf4380b7Ci5HLenp16NpKSk4pV0fO/E+qlL7A4PJ6U3MZJA+d8m4nyF1vP61+TxITDno=
X-Received: by 2002:aa7:c1d8:0:b0:561:f7d9:d77e with SMTP id
d24-20020aa7c1d8000000b00561f7d9d77emr2223033edp.10.1707928967583; Wed, 14
Feb 2024 08:42:47 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com> <3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com> <d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
In-Reply-To: <d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
From: Warner Losh <imp@bsdimp.com>
Date: Wed, 14 Feb 2024 09:42:36 -0700
Message-ID: <CANCZdfrX+JpiKgU4Bo+-dwX_YVszYXT9hy_S+xS91Z8RmiWONQ@mail.gmail.com>
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
To: John Baldwin <jhb@freebsd.org>
Cc: Mark Millard <marklmi@yahoo.com>, FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Content-Type: multipart/alternative; boundary="0000000000006a28f106115a33e8"
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: 4TZkWs3YNBz49yd
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
--0000000000006a28f106115a33e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 14, 2024 at 9:08=E2=80=AFAM John Baldwin <jhb@freebsd.org> wrot=
e:
> On 2/12/24 5:57 PM, Mark Millard wrote:
> > On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
> >
> >> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
> >>
> >>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
> >>>
> >>>> [Gack: I was looking at the wrong vintage of source code, predating
> >>>> your changes: wrong system used.]
> >>>>
> >>>>
> >>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
> >>>>
> >>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
> >>>>>
> >>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
> >>>>>>> Summary:
> >>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> >>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
> 0x40000000
> >>>>>>> . . .
> >>>>>>> rman_manage_region: <pcib1 memory window> request: start
> 0x600000000, end 0x6000fffff
> >>>>>>> panic: Failed to add resource to rman
> >>>>>>
> >>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource
> works which is
> >>>>>> fundamentally broken. It rewrites the start address of a resource
> in-situ instead
> >>>>>> of keeping downstream resources separate from the upstream
> resources. For example,
> >>>>>> I don't see how you could ever release a resource in this design
> without completely
> >>>>>> screwing up your rman. That is, I expect trying to detach a PCI
> device behind a
> >>>>>> translating bridge that uses the current approach should corrupt
> the allocated
> >>>>>> resource ranges in an rman long before my changes.
> >>>>>>
> >>>>>> That said, that doesn't really explain the panic. Hmm, the panic
> might be because
> >>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the
> bus_translate_resource
> >>>>>> hack only kicks in the activate_resource method of
> pci_host_generic.c.
> >>>>>>
> >>>>>>> Detail:
> >>>>>>> . . .
> >>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> >>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
> 0x40000000
> >>>>>>
> >>>>>> This indicates this is a translating bus.
> >>>>>>
> >>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
> >>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0=
x1
> >>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00ffff=
f,
> count=3D0x100000
> >>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000,
> 0xc00fffff], length 0x100000, flags 102, device pcib1
> >>>>>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xffff=
f>
> >>>>>>> considering [0xc0000000, 0xffffffff]
> >>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000
> (requested 0x100000)
> >>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
> >>>>>>> allocating from the beginning
> >>>>>>> rman_manage_region: <pcib1 memory window> request: start
> 0x600000000, end 0x6000fffff
> >>>
> >>> What you later typed does not match:
> >>>
> >>> 0x600000000
> >>> 0x6000fffff
> >>>
> >>> You later typed:
> >>>
> >>> 0x60000000
> >>> 0x600fffffff
> >>>
> >>> This seems to have lead to some confusion from using the
> >>> wrong figure(s).
> >>>
> >>>>>> The fact that we are trying to reserve the CPU addresses in the
> rman is because
> >>>>>> bus_translate_resource rewrote the start address in the resource
> after it was allocated.
> >>>>>>
> >>>>>> That said, I can't see why rman_manage_region would actually fail.
> At this point the
> >>>>>> rman is empty (this is the first call to rman_manage_region for
> "pcib1 memory window"),
> >>>>>> so only the check that should be failing are the checks against
> rm_start and
> >>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end i=
s
> always
> >>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new
> (0x60000000 - 0x600fffffff)
> >>>>>> ranges are within those bounds.
> >>>
> >>> No:
> >>>
> >>> 0xffffffff
> >>>
> >>> .vs (actual):
> >>>
> >>> 0x600000000
> >>> 0x6000fffff
>
> Ok, then this explains the failure if the "raw" addresses are above 4G. =
I
> have
> access to an emag I'm currently using to test fixes to pci_host_generic.c
> to
> avoid corrupting struct resource objects. I'll post the diff once I've g=
ot
> something verified to work.
>
> > It looks to me like in sys/dev/pci/pci_pci.c the:
> >
> > static void
> > pcib_probe_windows(struct pcib_softc *sc)
> > {
> > . . .
> > pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff)=
;
> > . . .
> >
> > is just inappropriately restrictive about where in the system
> > address space a PCIe can validly be mapped to on the high end.
> > That, in turn, leads to the rejection on the RPi4B now that
> > the range use is checked.
>
> No, the physical register in PCI-PCI bridges is only 32-bits. Only the
> prefetchable BAR supports 64-bit addresses. This is why the host bridge
> is doing a translation from the CPU side (0x600000000) to the PCI BAR
> addresses (0xc0000000) so that the BAR addresses are down in the 32-bit
> address range. It's also true that many PCI devices only support 32-bit
> addresses in memory BARs. 64-bit BARs are an optional extension not
> universally supported.
>
> The translation here is somewhat akin to a type of MMU where the CPU
> addresses are mapped to PCI addresses. The problem here is that the
> PCI BAR resources need to "stay" as PCI addresses since we depend on
> being able to use rman_get_start/end to get the PCI addresses of
> allocated resources, but pci_host_generic.c currently rewrites the
> addresses.
>
> Probably I should remove rman_set_start/end entirely (Warner added them
> back in 2004) as the methods don't do anything to deal with the fallout
> that the rman.rm_list linked-list is no longer sorted by address once
> some addresses get rewritten, etc.
>
At the time, they made sense. Removing it, though may take some doing
since we use it in about 284 places in sys/dev today... Somewhat more
pervasive than I'd have thought they'd be...
Warner
--0000000000006a28f106115a33e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 14, 2024 at 9:08=E2=80=AF=
AM John Baldwin <<a href=3D"mailto:jhb@freebsd.org">jhb@freebsd.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/=
12/24 5:57 PM, Mark Millard wrote:<br>
> On Feb 12, 2024, at 16:36, Mark Millard <<a href=3D"mailto:marklmi@=
yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> <br>
>> On Feb 12, 2024, at 16:10, Mark Millard <<a href=3D"mailto:mark=
lmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
>><br>
>>> On Feb 12, 2024, at 12:00, Mark Millard <<a href=3D"mailto:=
marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
>>><br>
>>>> [Gack: I was looking at the wrong vintage of source code, =
predating<br>
>>>> your changes: wrong system used.]<br>
>>>><br>
>>>><br>
>>>> On Feb 12, 2024, at 10:41, Mark Millard <<a href=3D"mai=
lto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<b=
r>
>>>><br>
>>>>> On Feb 12, 2024, at 09:32, John Baldwin <<a href=3D=
"mailto:jhb@freebsd.org" target=3D"_blank">jhb@freebsd.org</a>> wrote:<b=
r>
>>>>><br>
>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:<br>
>>>>>>> Summary:<br>
>>>>>>> pcib0: <BCM2838-compatible PCI-express cont=
roller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2<br>
>>>>>>> pcib0: parsing FDT for ECAM0:<br>
>>>>>>> pcib0:=C2=A0 PCI addr: 0xc0000000, CPU addr: 0=
x600000000, Size: 0x40000000<br>
>>>>>>> . . .<br>
>>>>>>> rman_manage_region: <pcib1 memory window>=
; request: start 0x600000000, end 0x6000fffff<br>
>>>>>>> panic: Failed to add resource to rman<br>
>>>>>><br>
>>>>>> Hmmm, I suspect this is due to the way that bus_tr=
anslate_resource works which is<br>
>>>>>> fundamentally broken.=C2=A0 It rewrites the start =
address of a resource in-situ instead<br>
>>>>>> of keeping downstream resources separate from the =
upstream resources.=C2=A0 =C2=A0For example,<br>
>>>>>> I don't see how you could ever release a resou=
rce in this design without completely<br>
>>>>>> screwing up your rman.=C2=A0 That is, I expect try=
ing to detach a PCI device behind a<br>
>>>>>> translating bridge that uses the current approach =
should corrupt the allocated<br>
>>>>>> resource ranges in an rman long before my changes.=
<br>
>>>>>><br>
>>>>>> That said, that doesn't really explain the pan=
ic.=C2=A0 Hmm, the panic might be because<br>
>>>>>> for PCI bridge windows the driver now passes RF_AC=
TIVE and the bus_translate_resource<br>
>>>>>> hack only kicks in the activate_resource method of=
pci_host_generic.c.<br>
>>>>>><br>
>>>>>>> Detail:<br>
>>>>>>> . . .<br>
>>>>>>> pcib0: <BCM2838-compatible PCI-express cont=
roller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2<br>
>>>>>>> pcib0: parsing FDT for ECAM0:<br>
>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x60000=
0000, Size: 0x40000000<br>
>>>>>><br>
>>>>>> This indicates this is a translating bus.<br>
>>>>>><br>
>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device=
0.0 on pci0<br>
>>>>>>> rman_manage_region: <pcib1 bus numbers> =
request: start 0x1, end 0x1<br>
>>>>>>> pcib0: rman_reserve_resource: start=3D0xc00000=
00, end=3D0xc00fffff, count=3D0x100000<br>
>>>>>>> rman_reserve_resource_bound: <PCIe Memory&g=
t; request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pc=
ib1<br>
>>>>>>> rman_reserve_resource_bound: trying 0xffffffff=
<0xc0000000,0xfffff><br>
>>>>>>> considering [0xc0000000, 0xffffffff]<br>
>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; si=
ze 0x100000 (requested 0x100000)<br>
>>>>>>> candidate region: [0xc0000000, 0xc00fffff], si=
ze 0x100000<br>
>>>>>>> allocating from the beginning<br>
>>>>>>> rman_manage_region: <pcib1 memory window>=
; request: start 0x600000000, end 0x6000fffff<br>
>>><br>
>>> What you later typed does not match:<br>
>>><br>
>>> 0x600000000<br>
>>> 0x6000fffff<br>
>>><br>
>>> You later typed:<br>
>>><br>
>>> 0x60000000<br>
>>> 0x600fffffff<br>
>>><br>
>>> This seems to have lead to some confusion from using the<br>
>>> wrong figure(s).<br>
>>><br>
>>>>>> The fact that we are trying to reserve the CPU add=
resses in the rman is because<br>
>>>>>> bus_translate_resource rewrote the start address i=
n the resource after it was allocated.<br>
>>>>>><br>
>>>>>> That said, I can't see why rman_manage_region =
would actually fail.=C2=A0 At this point the<br>
>>>>>> rman is empty (this is the first call to rman_mana=
ge_region for "pcib1 memory window"),<br>
>>>>>> so only the check that should be failing are the c=
hecks against rm_start and<br>
>>>>>> rm_end.=C2=A0 For the memory window, rm_start is a=
lways 0, and rm_end is always<br>
>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00ff=
fff) and new (0x60000000 - 0x600fffffff)<br>
>>>>>> ranges are within those bounds.<br>
>>><br>
>>> No:<br>
>>><br>
>>> 0xffffffff<br>
>>><br>
>>> .vs (actual):<br>
>>><br>
>>> 0x600000000<br>
>>> 0x6000fffff<br>
<br>
Ok, then this explains the failure if the "raw" addresses are abo=
ve 4G.=C2=A0 I have<br>
access to an emag I'm currently using to test fixes to pci_host_generic=
.c to<br>
avoid corrupting struct resource objects.=C2=A0 I'll post the diff once=
I've got<br>
something verified to work.<br>
<br>
> It looks to me like in sys/dev/pci/pci_pci.c the:<br>
> <br>
> static void<br>
> pcib_probe_windows(struct pcib_softc *sc)<br>
> {<br>
> . . .<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pcib_alloc_window(sc, &sc->me=
m, SYS_RES_MEMORY, 0, 0xffffffff);<br>
> . . .<br>
> <br>
> is just inappropriately restrictive about where in the system<br>
> address space a PCIe can validly be mapped to on the high end.<br>
> That, in turn, leads to the rejection on the RPi4B now that<br>
> the range use is checked.<br>
<br>
No, the physical register in PCI-PCI bridges is only 32-bits.=C2=A0 Only th=
e<br>
prefetchable BAR supports 64-bit addresses.=C2=A0 This is why the host brid=
ge<br>
is doing a translation from the CPU side (0x600000000) to the PCI BAR<br>
addresses (0xc0000000) so that the BAR addresses are down in the 32-bit<br>
address range.=C2=A0 It's also true that many PCI devices only support =
32-bit<br>
addresses in memory BARs.=C2=A0 64-bit BARs are an optional extension not<b=
r>
universally supported.<br>
<br>
The translation here is somewhat akin to a type of MMU where the CPU<br>
addresses are mapped to PCI addresses.=C2=A0 The problem here is that the<b=
r>
PCI BAR resources need to "stay" as PCI addresses since we depend=
on<br>
being able to use rman_get_start/end to get the PCI addresses of<br>
allocated resources, but pci_host_generic.c currently rewrites the<br>
addresses.<br>
<br>
Probably I should remove rman_set_start/end entirely (Warner added them<br>
back in 2004) as the methods don't do anything to deal with the fallout=
<br>
that the rman.rm_list linked-list is no longer sorted by address once<br>
some addresses get rewritten, etc.<br></blockquote><div><br></div><div>At t=
he time, they made sense. Removing it, though may take some doing</div><div=
>since we use it in about 284 places=C2=A0 in sys/dev today... Somewhat mor=
e</div><div>pervasive than I'd have thought they'd be...</div><div>=
<br></div><div>Warner=C2=A0</div></div></div>
--0000000000006a28f106115a33e8--
From nobody Wed Feb 14 17:30:46 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZlbD66n0z514xL;
Wed, 14 Feb 2024 17:30:48 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZlbD5g25z4JC0;
Wed, 14 Feb 2024 17:30:48 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707931848;
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=LsxTKj68riQhYjKMYsHXvMxX5HZyz+blVVNaAspRYdQ=;
b=Ex/4r+jTh0fbheJXSDpf0vXJmSWa3zv0eAdtzREBVc9imqX573yYCsBPSkdtNYyFTP+y2l
W8mzN6zd8JfNUivuYBYzIH3gV5TL4VAatB8VNWDzo/wr+riWLTY5V6DRNJV0mzhJdMqjqT
DpnFL5+FDv+lIVZmiW6TnyBFVsRizQpxJQoxBCuuhv3VpEv8e3fh1qWHCGdJqKLSR7j31b
d3fV2c9FbZvV9+BkA72QI1GkeXn7oDYZP/S3zfD4epaTnJVM4unSBlvMXSLEQX+EprhDMA
xyDDq1dM824qQEO7u1BqqhBy3YmiQTn8G/UPGuvpHcw9ekpiJhWYo8C0ZtK8UA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707931848; a=rsa-sha256; cv=none;
b=bX3SP/sCs26aosB184r6RqoAkJVaED0EQ4dlOvFqNskl9MO2Yitmz89EBtYII9NSIhttqp
LkEW7MWmi3Uj/ckVj0B1kbUSj7NFTguLLMBU+CzpzkDrs4DCpXQ9LFi0Zk8OY0dvdpErGw
4aq/FAJa6SrQw5cmSqA6LDrdeR8GNt7YIMEt+0zIfTPsIHigiV+E+IfUvowFHC+yVuS/MR
NvKDsdU17tm5nMX8z2qa0v+E80RWVzjwwp9P5/pxXy+WXvc6mbpWE7Zhl2JIZjffHsKpZF
xcDa6sVcIIJnZ8Y8B4LqM35wyEi1lrZRujzC6qlSR4PPPndJ24t3Y0hIk6kfuw==
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=1707931848;
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=LsxTKj68riQhYjKMYsHXvMxX5HZyz+blVVNaAspRYdQ=;
b=udUTfm/tGhI+GH+nFU1mm7tEWns6FUgC4KvKRE7Khw/2wSgHKTu0+zn5vSYSIaFEw2cFJI
dzpbBAybiOFrwrUeS1uPvvMJNZcqqbxDRaDoWRBM5vk4GgNPq2tzAAgAvcV7tb2fMTkYqd
o2HMD4ShtNQfLGCQrn27eq3y+rP9IjYBKXE41Hg1tyo7PxTp5Xr09etxmU/n/t9Gkg/Kz5
1lhCx1UTXMPI4sxyoxzsT+aFRkL4veO2OXOsEy2YT43nnz90+atYBgrE6jJgch3cvF53ds
cLc1ILUIhjsNfcyisvEHnuCoGhQL4FnJnigxxfc3t9C8OOCwIkHsVx91U0u7DA==
Received: from [IPV6:2601:644:937c:5920:5974:74f9:c690:271e] (unknown [IPv6:2601:644:937c:5920:5974:74f9:c690:271e])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZlbD1hB6zNJH;
Wed, 14 Feb 2024 17:30:48 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <f07d8fa2-c3e1-44f1-b355-544619ed2e5e@FreeBSD.org>
Date: Wed, 14 Feb 2024 09:30:46 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Warner Losh <imp@bsdimp.com>
Cc: Mark Millard <marklmi@yahoo.com>,
FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<CANCZdfrX+JpiKgU4Bo+-dwX_YVszYXT9hy_S+xS91Z8RmiWONQ@mail.gmail.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <CANCZdfrX+JpiKgU4Bo+-dwX_YVszYXT9hy_S+xS91Z8RmiWONQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2/14/24 8:42 AM, Warner Losh wrote:
> On Wed, Feb 14, 2024 at 9:08 AM John Baldwin <jhb@freebsd.org> wrote:
>
>> On 2/12/24 5:57 PM, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
>>>
>>>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>>>>
>>>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>
>>>>>> [Gack: I was looking at the wrong vintage of source code, predating
>>>>>> your changes: wrong system used.]
>>>>>>
>>>>>>
>>>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>>
>>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>>>>
>>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>>>>> Summary:
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
>> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
>> 0x40000000
>>>>>>>>> . . .
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start
>> 0x600000000, end 0x6000fffff
>>>>>>>>> panic: Failed to add resource to rman
>>>>>>>>
>>>>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource
>> works which is
>>>>>>>> fundamentally broken. It rewrites the start address of a resource
>> in-situ instead
>>>>>>>> of keeping downstream resources separate from the upstream
>> resources. For example,
>>>>>>>> I don't see how you could ever release a resource in this design
>> without completely
>>>>>>>> screwing up your rman. That is, I expect trying to detach a PCI
>> device behind a
>>>>>>>> translating bridge that uses the current approach should corrupt
>> the allocated
>>>>>>>> resource ranges in an rman long before my changes.
>>>>>>>>
>>>>>>>> That said, that doesn't really explain the panic. Hmm, the panic
>> might be because
>>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the
>> bus_translate_resource
>>>>>>>> hack only kicks in the activate_resource method of
>> pci_host_generic.c.
>>>>>>>>
>>>>>>>>> Detail:
>>>>>>>>> . . .
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
>> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
>> 0x40000000
>>>>>>>>
>>>>>>>> This indicates this is a translating bus.
>>>>>>>>
>>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>>>>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff,
>> count=0x100000
>>>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000,
>> 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>>>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000
>> (requested 0x100000)
>>>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>>>>> allocating from the beginning
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start
>> 0x600000000, end 0x6000fffff
>>>>>
>>>>> What you later typed does not match:
>>>>>
>>>>> 0x600000000
>>>>> 0x6000fffff
>>>>>
>>>>> You later typed:
>>>>>
>>>>> 0x60000000
>>>>> 0x600fffffff
>>>>>
>>>>> This seems to have lead to some confusion from using the
>>>>> wrong figure(s).
>>>>>
>>>>>>>> The fact that we are trying to reserve the CPU addresses in the
>> rman is because
>>>>>>>> bus_translate_resource rewrote the start address in the resource
>> after it was allocated.
>>>>>>>>
>>>>>>>> That said, I can't see why rman_manage_region would actually fail.
>> At this point the
>>>>>>>> rman is empty (this is the first call to rman_manage_region for
>> "pcib1 memory window"),
>>>>>>>> so only the check that should be failing are the checks against
>> rm_start and
>>>>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end is
>> always
>>>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new
>> (0x60000000 - 0x600fffffff)
>>>>>>>> ranges are within those bounds.
>>>>>
>>>>> No:
>>>>>
>>>>> 0xffffffff
>>>>>
>>>>> .vs (actual):
>>>>>
>>>>> 0x600000000
>>>>> 0x6000fffff
>>
>> Ok, then this explains the failure if the "raw" addresses are above 4G. I
>> have
>> access to an emag I'm currently using to test fixes to pci_host_generic.c
>> to
>> avoid corrupting struct resource objects. I'll post the diff once I've got
>> something verified to work.
>>
>>> It looks to me like in sys/dev/pci/pci_pci.c the:
>>>
>>> static void
>>> pcib_probe_windows(struct pcib_softc *sc)
>>> {
>>> . . .
>>> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
>>> . . .
>>>
>>> is just inappropriately restrictive about where in the system
>>> address space a PCIe can validly be mapped to on the high end.
>>> That, in turn, leads to the rejection on the RPi4B now that
>>> the range use is checked.
>>
>> No, the physical register in PCI-PCI bridges is only 32-bits. Only the
>> prefetchable BAR supports 64-bit addresses. This is why the host bridge
>> is doing a translation from the CPU side (0x600000000) to the PCI BAR
>> addresses (0xc0000000) so that the BAR addresses are down in the 32-bit
>> address range. It's also true that many PCI devices only support 32-bit
>> addresses in memory BARs. 64-bit BARs are an optional extension not
>> universally supported.
>>
>> The translation here is somewhat akin to a type of MMU where the CPU
>> addresses are mapped to PCI addresses. The problem here is that the
>> PCI BAR resources need to "stay" as PCI addresses since we depend on
>> being able to use rman_get_start/end to get the PCI addresses of
>> allocated resources, but pci_host_generic.c currently rewrites the
>> addresses.
>>
>> Probably I should remove rman_set_start/end entirely (Warner added them
>> back in 2004) as the methods don't do anything to deal with the fallout
>> that the rman.rm_list linked-list is no longer sorted by address once
>> some addresses get rewritten, etc.
>>
>
> At the time, they made sense. Removing it, though may take some doing
> since we use it in about 284 places in sys/dev today... Somewhat more
> pervasive than I'd have thought they'd be...
Eh, I only find the one that I'm now removing:
% git grep -E 'rman_set_(start|end)' sys/
sys/dev/pci/pci_host_generic.c: rman_set_start(r, start);
sys/dev/pci/pci_host_generic.c: rman_set_end(r, end);
sys/kern/subr_rman.c:rman_set_start(struct resource *r, rman_res_t start)
sys/kern/subr_rman.c:rman_set_end(struct resource *r, rman_res_t end)
sys/sys/rman.h:void rman_set_end(struct resource *_r, rman_res_t _end);
sys/sys/rman.h:void rman_set_start(struct resource *_r, rman_res_t _start);
Also, I managed to boot the emag I have access to this morning. I had to
fix a few other bugs in acpi(4) for my changes in pci_host_generic to work
but will post reviews later today.
--
John Baldwin
From nobody Wed Feb 14 17:57:33 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 4TZmBQ6swKz518Ll
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 17:57:50 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZmBQ4TxTz4Msv
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 17:57:50 +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=1707933467; bh=RbzmeBWXn/60twKqejHyraerRAaQJoY0gqzcIyAj/Mk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ny5WtN3ziXLVjX8fnTAiuuFAgfEVyST4d8JN80B9xKuI90J8ghqmzQJWDiHrs+f+ITTzkkBnWfqLNDTGa9zBZGr+5jpGiKwqqmb9UMe5xYIK2Y2ob2x056TCl+yvojts7uzugIoGQO4BLs4+R1jmczHIaXAPfCExlfs2CZ33RsoRAcIl08uqZtn8jmcF6BglsakiQ5rVWgPyACap8jjb+kiVzmfBPXQuKA7+O3SEDOt9yUgA6F6Z+wjsBZsCwCWwpAeK5sREo2wq6ZO7QTjA1mHISO+jwDcqmAdq/rC+opJ9sz801Z2stCQtOarZo9l1V9xGJqXv7Sa0DB2yYTG8KQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707933467; bh=vtJGLELHLITbF/ZS8UJ5bB2o/yXIkArHJCzIgKYvvbZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nD81xY/2/hdG0oPuB8S8YE6NNnQYVGAmBPEy50Q+gdW+4jCk6vDZ0imJb2t0D8FQSBD3GzFhYivynZ7kW13qnfMN58sNmvGwLA/9Z/PUuKpTdfdKMoX5DICBAmKFql/bZlJzLRq0V4famoCOUqQk2JCgmWsMne/4rTwv2lMB5aHT7ZYMXmWFeUDEPC9VnH1e90yZT+p8hBkZnB6UFLsz/t1W/LQim6XTBg7MibqM5MAzKP/C2SUymvIb1xHI+5CEMUIFL6xAlM3hXubFLcCFZga04IBGXqur+8yHWWtpymQ0tC7+KvC6zhL5SfbKMFFk0UB1Ry6byzDZXEnf4PBdEw==
X-YMail-OSG: KO2UigkVM1nKjO9OPgctBmpFB4XReArEo1fpGCjJO8QTnid2LPBPsLYQy_Gf0tx
1QXfFDOH5H779h9aYifRQ28SUe5Gh7Kzvjl0YiKwkmBbghWw8kxhWcTbGH31tJKsjSKZO_moBxhd
cRsjWOGUCL0h8tUxyMQvpK_b0JO1tfqpm0AosY6uhikz19iAGsaxsizjfY_hR.oPtMceb5PDQ6mi
BtbBwWDtJ3k_WPhsbopmh5bWwLAtbGiMljTvRW6XegVGj4VSoJHi5iVEkkqqQ7w2aUqSIYt0Tiiv
5krGRBEbuq6fATmlMxlaLraUxJDJ1z84c4JY5uJBUAM361DmMaEgTJ..eBuMLG2D8WQTuy5oJLZF
qMfr8JXLGgG0B0XfEcPjGaIUxbsZd2z67LWwx8YZwNmkqKjBhS2B1UhCSyjTc6VSWIEIrDI5hig5
I_ZkEc3_ureATzFAadcavcxFQbKV8d6wioRTCgQtVpUCW0v7kwCghuAPRQ3wpdUpvmdBQlE935Hq
efLuRnHDXckSisoLiSVpAFEUsXkBlUuYsI3Updq7LzkjTbC38Zh7qDtgc5rJuycv6_1Fq3wPquee
D1QuCwuHYbzBBqf7cR49h2ES8KaG__PynC7lVsVEoMfcphw2sYo1lY_dP_PA4oIDVzw6Uy_Th0lC
2dFsK7sqstf2kT9CtJXEetS97SqAsES2lY1Y_gH6tKAfCS_63._lBCtKTSqQQWT_RTHPSlMto5xF
3YqJcBNqg0L96JHp7WzdNe4G4L79dYjJpIuLnZw0RRggoV_ptGgxM3_6jdLUCLx7MVr1D0BoRk5k
s0Fxv6Ji1L3YWDbBFSzXEFaTIFQt.hz4L.sOQofhq6iWF183ozG_13N2.nstKTouAYict4hK_aN3
nGEqtB0rENvQ7MBNLcxE2bGGVS4gmBDMa2X3FhP9012sM8GNH2hmGItIeEEDdyOLvxG3CljTQNGA
kbbVTKv8b1VT9B.DOmvlNpTdmLMznFAsoiecw1kl3qjOOOCMOkq1QB8p5lFG9K_k2OoRdLtyfEEM
xl3T84U8X3o54RMGF_E.iEtQKumgpTuQId3bf5l269l_Zkh0F5Lbqqt.xQkMVWVZt9DOPMPsSNIs
Mku1wWMbNEh9EU.cfmSm_A0r1aKU9cXE5vN9kNcGOvH8X3Ym5FS0uamERC9BEwQYhQcaNGUie6Cs
PiiBTOq9itF2yqlrLSmMeIDA3EJ5_rxNzTpp965fLz2i.sKtnmAthUhiYaBSxaU5ycCsGpQf3BQM
MD2SGZMr4nywFqDj44QCpLqzfMDVlXuZjSPLrt13FWy.g.nrXn7w3AP9ucD4GWGNJLfCkjkFHW9g
0E3iYH5lL8O5DkGTXpIhuAvjIJFlg4L61w_iteakW6s5rz8E41k5FWoP._8Jeq0KAL5sprLec3Nu
KGh58FkXJLqImrClNv7Kd1ffhZAdHGxo07loU0Tys1.TL8mkFjUv1pNlBnW55mqmnsuq4iJK5RLu
_p_jkZBeqx5Wc6_tLA9FwceQ_ORypt4x4CtW6_uEhZ1YvKSMXGkrssbzQQzVaOn51PwWgkFY_Yuq
b7JTb_AaByzmj9NkywTLIBUUeQdPbIlt1OrmOeN5qfZ1OGCYoY.8AqRuPzRm6VDFazWEwwhNVGPG
7kt5RmCNC1rF8suKyb6vU3PVKwNpE7rvNy7.EMjQY1GDEQnMgliW83TAsJwbEXkpSR5erUfYpghv
PtP26AGipFnD1rDPkZJZU.4vimyTd7pJ_ejUQXhJdlmY7hiDUdxW2RvS6vdUjKbBVXNHYprgJeC0
bQ.eReO13DNrozSFgK56ZvX4I9tML0QHkaITM1OypcWxqSpqxUL9Ffkm00T2cC5T2KeaWNSbxUpr
c6238u191s6Do8BwsjrIMNNPSmaWxBMp4uDdIBlPWc3ZO8iIEq3omvSUcFjHiZ5sq9N7chBxhbTe
sTOPEjR5BqhrF.pJVRk_Ve6YbbiJ9VqQ9vOVrltbbpF72bFyQvPrbkHB9hRy3HuAmwrt.0V1n2vt
ML2GCrTd_HEUX.5KGsAiqEzzLr65p15wZafp2DFyxvJJz3KLIx1WBbOIMVwkZM4WnsH1PcIOxUJ.
dbq2f0uv4nacMLjeyFXH4G5ZNgfJx3notEQZoPDKfRQ6k1ZPpMrHMPREDGWEIhioV_Dia3x.oxuW
mtTkIOEWUlB6Q4XIDuzomeZIGK1BDpbhik_wlWqDYFk4_c_m8SiItjk1_fxiiob7AaxtdRNRjF_h
ZHcmPj_GxvEeXPzdBG8G8Bl1aT8ocZOKlIxt7ZgviP9N.pfpaTHwQyNa4ZZybKRS0.tfDG8mS18t
E
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: d036ca9a-cc79-47b5-8043-c2dbc5079fab
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Feb 2024 17:57:47 +0000
Received: by hermes--production-gq1-5c57879fdf-tnlsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a26232e89c8c9752c58f7c52f7c49bc1;
Wed, 14 Feb 2024 17:57:44 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
Date: Wed, 14 Feb 2024 09:57:33 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
To: John Baldwin <jhb@FreeBSD.org>
X-Mailer: Apple Mail (2.3774.400.31)
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: 4TZmBQ4TxTz4Msv
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Feb 14, 2024, at 08:08, John Baldwin <jhb@FreeBSD.org> wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
>> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
>>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>>=20
>>>>> [Gack: I was looking at the wrong vintage of source code, =
predating
>>>>> your changes: wrong system used.]
>>>>>=20
>>>>>=20
>>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>=20
>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>>>=20
>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>>>> Summary:
>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>>>> . . .
>>>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>>>>> panic: Failed to add resource to rman
>>>>>>>=20
>>>>>>> Hmmm, I suspect this is due to the way that =
bus_translate_resource works which is
>>>>>>> fundamentally broken. It rewrites the start address of a =
resource in-situ instead
>>>>>>> of keeping downstream resources separate from the upstream =
resources. For example,
>>>>>>> I don't see how you could ever release a resource in this design =
without completely
>>>>>>> screwing up your rman. That is, I expect trying to detach a PCI =
device behind a
>>>>>>> translating bridge that uses the current approach should corrupt =
the allocated
>>>>>>> resource ranges in an rman long before my changes.
>>>>>>>=20
>>>>>>> That said, that doesn't really explain the panic. Hmm, the =
panic might be because
>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>>>>>>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>>>>>>=20
>>>>>>>> Detail:
>>>>>>>> . . .
>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>>>=20
>>>>>>> This indicates this is a translating bus.
>>>>>>>=20
>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end =
0x1
>>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, =
end=3D0xc00fffff, count=3D0x100000
>>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: =
[0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>>> rman_reserve_resource_bound: trying 0xffffffff =
<0xc0000000,0xfffff>
>>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 =
(requested 0x100000)
>>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>>>> allocating from the beginning
>>>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>=20
>>>> What you later typed does not match:
>>>>=20
>>>> 0x600000000
>>>> 0x6000fffff
>>>>=20
>>>> You later typed:
>>>>=20
>>>> 0x60000000
>>>> 0x600fffffff
>>>>=20
>>>> This seems to have lead to some confusion from using the
>>>> wrong figure(s).
>>>>=20
>>>>>>> The fact that we are trying to reserve the CPU addresses in the =
rman is because
>>>>>>> bus_translate_resource rewrote the start address in the resource =
after it was allocated.
>>>>>>>=20
>>>>>>> That said, I can't see why rman_manage_region would actually =
fail. At this point the
>>>>>>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>>>>>>> so only the check that should be failing are the checks against =
rm_start and
>>>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end =
is always
>>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>>>>>>> ranges are within those bounds.
>>>>=20
>>>> No:
>>>>=20
>>>> 0xffffffff
>>>>=20
>>>> .vs (actual):
>>>>=20
>>>> 0x600000000
>>>> 0x6000fffff
>=20
> Ok, then this explains the failure if the "raw" addresses are above =
4G. I have
> access to an emag I'm currently using to test fixes to =
pci_host_generic.c to
> avoid corrupting struct resource objects. I'll post the diff once =
I've got
> something verified to work.
>=20
>> It looks to me like in sys/dev/pci/pci_pci.c the:
>> static void
>> pcib_probe_windows(struct pcib_softc *sc)
>> {
>> . . .
>> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, =
0xffffffff);
>> . . .
>> is just inappropriately restrictive about where in the system
>> address space a PCIe can validly be mapped to on the high end.
>> That, in turn, leads to the rejection on the RPi4B now that
>> the range use is checked.
>=20
> No, the physical register in PCI-PCI bridges is only 32-bits. Only =
the
> prefetchable BAR supports 64-bit addresses.
Just for my edification . . .
As I understand, SYS_RES_MEMORY for the BCM2711
means the 35 bit addressing space in the BCM2711,
not a PCIe device internal address range that
corresponds. Am I wrong about that?
If I'm wrong, what does identify the 35 bit
addressing space in the BCM2711?
If I'm correct, then the 0..0xffffffff
seems to be from the wrong address space up
front. Or, may be, the SYS_RES_MEMORY and the
0xffffffff argments are not related as I
expected and the 0xffffffff is not a
SYS_RES_MEMORY value?
> This is why the host bridge
> is doing a translation from the CPU side (0x600000000) to the PCI BAR
> addresses (0xc0000000) so that the BAR addresses are down in the =
32-bit
> address range. It's also true that many PCI devices only support =
32-bit
> addresses in memory BARs. 64-bit BARs are an optional extension not
> universally supported.
>=20
> The translation here is somewhat akin to a type of MMU where the CPU
> addresses are mapped to PCI addresses. The problem here is that the
> PCI BAR resources need to "stay" as PCI addresses since we depend on
> being able to use rman_get_start/end to get the PCI addresses of
> allocated resources, but pci_host_generic.c currently rewrites the
> addresses.
>=20
> Probably I should remove rman_set_start/end entirely (Warner added =
them
> back in 2004) as the methods don't do anything to deal with the =
fallout
> that the rman.rm_list linked-list is no longer sorted by address once
> some addresses get rewritten, etc.
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Wed Feb 14 18:16:02 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 4TZmbn2yp8z51hRX
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 18:16:21 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZmbm1rmMz4R6x
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 18:16:20 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=jnlLwFf9;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707934578; bh=STGOR7uwlL32Djb90xxLmXVD4396T33A28E2CKIUUiA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jnlLwFf956VErlaD5eg2zmji0xilni35r1lTBDgpORVFrxWhGdklGgZ7GbGxpJ+2LqQqw/C08smgogeLBRBxbNg7dIhkxi2WhMnsE2VAB0yC0R+FJMdpr+LLLS4P3MH1/RBiKqST85tVWsT0nYVQsoqzfKXZKVirxpcg6TRgzx+pWZu8Lo7vChW3ld2Gyc9bG6kkG8vBz7FyMu/tQiRXxB5gternbUnc4S++ncgNyPmrOnOGO54jikus0917FFhCD9JKAXI33voDotcIQQbty5NWcQstE1OKpyJqvjGRS9fXGcl+JSeBmyHW1m1+9LVoY+t+HByrV3wp+JJwrPFynA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707934578; bh=YWkWVdzVaGbxA38ur6vxKcaSvb0o6IjTw2Cd08kox5V=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kD5tTLvB0g5ld5mAnxNqAwi7a9VYzb62aBeaVRbX0Y7HYB4X7RuDou1aAQHammI7uDA98E2agLyHOqJeM9eq1SbPBhwyEnZQpu1Z6xjuafHxv+GCcMdWh6neKxTnFUj7cUuboUOugtwTD8dVfIGjdKBoigjNfZAuZzNqWzeLSJeY4tKRtI1KeNsc8O4OEjxH/qtHle+PBuqT8BKBaBRB+472Tk1E4JuW6spQ1vh14ldkoG5noJCfivIr5IZLhVrVZUac0wmrCUfw65Yfex+f+XdiQQnFxtKZzgqAcWUQG9rD6Kn2TSfSukrENPfAqyfT+Zp/nUGTxJtqdKXQqBSO4A==
X-YMail-OSG: qX7yZVUVM1ki2loZzACq3_QDIMR8yV4n2qYJDLeLGqBA79ALqRiojnCCbQywhtr
9.OmEH1SIgDl_bNVIG.gyCNZ_PBJtKa1bvMqPUqJxjy4I2agSU8k1w1_xFc9pds9azyCORktWtYS
ada5jVmrCos0AENmnyH4yS.21_f3px6zirSM2_KQQecPA7mitEq4AY3seKZ_3mxhPR3nFdT7tvY5
3JVsDeggwAj5jlTK7I1KJ8mJ4dYuBYiVQXUSCM_AP5JH8iAjeqw3R3nOUJfkRHMf9ykKPogm.cCM
ap3mo7Go7vyoiyhfRAW0eoIgn8YjPxNy0fok4w5Yb0Yelhw8HTTNrieDHmKL0vrOeaMVlyHV7ZsJ
ovqOznhyz5RtnTZOmuEveMpdsMRi3C.AeJ0ngnZBNl0o6q8Gp4Y5gLaizc_O7ECO4yJZy79w9Zbz
D4hP_BGjOUsIHsWJhivgsnfP1q0E19oSuttrMW8VYBTR5CkHPrhLL6IqYLlobEXIB22rr601OoWx
hq5A27.QxKfDJSme4YN7EUXqZU50nsEh2hseWWlO9zM23O.Nw0cE8306TLzfGpfalkHOmUuEwyCi
qHdLfjj8xK4FFEwCGsBeZENrZsuQvB47uXPKleDD7D7dqiXF.hY3s1zDqoooWdVkJ7oH2Boqxfw5
kZY0mk2HmY8WmOthvYF.eDXLYe.a1jm3kQ4a8zatqTymj5mL2S5ZFswWDTfgdeTpwcg7BJ2Qnz4I
H3shA058piGmgMWyF1tsdIit2UwZ98U99AWXAU4cN0r5GKeSECinjyLOosnVFcSjiQynru6c9uBp
vKLD3HiQtwHj5tg2BgcPuYHdQTZypNZfhLzdk6AN8.mrlM1BGjXy6_UhIiACF2e7pNvNIz6PmPWT
tKtfbtyOx6OAfNJlzBZUOb9rVj4k0._pHrk5on94YOgjqHIEtNHqtObs44lpZgntUrWJq33RmsF6
4ax0UivhZPRhMRpM9PYf22z5T0wzPoujfuP51.itKSZ2VKAowLg0MysNknwq_EsxeSUaieEQUenU
kWEmnpEtcHIs3hONv5sDJeQc3nD53PFp4ZkndgUy3M72g7Em06rH5vI5OXWNO2sqIaufEjtecF.3
M9H6xwMxO0KfgisA1kR.QNwtunzq12tRL.En_j__oNg4JwuPFcuq_.vIBxrCVBJvgUoIpTztZZA7
9Q4eSfmUNxLp8Pder65N620UBhU5g2PgI9fRCQm5bmuj2LUHQoxyVQ6uj8roE26GifO.e201jySq
crXezzuAg_3b5NkCPrDR36RmXCIZXDQGAzIbr4HkPb4Y0LWvQgAfwxggDzIk6lcQ8LbAWa1coA_A
o2lSEUeoWe4RxXToLMgmN_Wr_CNZjJDgQRVet0Rv0Yl0P3fqxKBI5rDzOHmGsNBX5gFVX3op9O.z
04nkVP.NLKPMOl561SAYTTvn3KEQSKrHnPpScwfgnRncsbepYw5u46c.McRbAt3BwfNgOgexSozo
dLXvoYcfuLFN3qvBHUvR7maxL8SvqKnezGxFv.D3At6WtekvbqUPrdj_kc1A49.Wp3S.8SvEqA0i
bDjAICLfOLveKGx006lUmpD0ou1PCNwiwffOx3_hny.yRDAIc0oILzCH_wGSEYb2woJkHhmc4Qgq
BTwXVIaU5M.W.NzZ6O_.eMunhV3TI6rJNUNiMVLnB2d_4JE0h0jY29ne1BmrovqJEJS9vbGrtiz7
p9A5h10D.oSZ3oGVBP5kCXMLS5pt8O4WkGckfkwNZSSowQT0dkSTevmrwguoPfmo..0QRce1DWf4
qrzoSD7OrLvs2lo2iu8zeIZM1.vkSDu00ANinznflOH.vmAS4_5ISwdgo_NBkywcPIKFwwqkCh43
9HLe657WJeODJ4XLkT9ZZ2o98XsXGIL7cdMhl2xBhhMQQ.wRwonmJWhaV5DIYAsZl0SyXJDfdcYs
wNtYYKIRvHgscAyWP9a5oXi2B4MIcvALHRmw2KAuHmUhRnUIWASmN8kcmXVlxy58oFcWRR_zneR8
nswZvsZUAzwiDL9KNbupkWa6vHqwUQ37csE_NhRqq8XqKbec2qY3N_Rblao0zXC2kdiBe4.7uIt7
Oy3DR8a6iPdvsHH4w59iD_VaccxLxDLZTiV9UPwnQ93NxASX.WZYptyEPbNtlkqy.5csDyI..Lr0
2zzVEk4w6CljfnUJlFvLXcal4ctCmQJ96Hv1d5JSb93j_aKnM2ltq2QGdqqLTzveSztoFRqj7aMZ
rAayWhVjJ4I8LotDcvIa7F5o5iDIYY76jK8i5ne0Ty7g.9.0VCKac.E6yw3TiUF5IxvfhrogjZYq
q564-
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 0d52a574-75f6-4567-869f-8a3446ac7e69
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Feb 2024 18:16:18 +0000
Received: by hermes--production-gq1-5c57879fdf-tnlsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 75bd2ec618e725ea0b4cd6d8312a2072;
Wed, 14 Feb 2024 18:16:13 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
Date: Wed, 14 Feb 2024 10:16:02 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
To: John Baldwin <jhb@FreeBSD.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from];
RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from]
X-Rspamd-Queue-Id: 4TZmbm1rmMz4R6x
Top posting a related but separate item:
I looked up some old (2022-Dec-17) lspci -v output from
a Linux boot. Note the "Memory at" value 600000000 (in
the 35 bit BCM2711 address space) and the "(64-bit,
non-prefetchable)" (and "[size=3D4K]").
01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller (rev 01) (prog-if 30 [XHCI])
Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller
Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
Flags: bus master, fast devsel, latency 0, IRQ 51
Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+
Capabilities: [c4] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: xhci_hcd
"Memory at 600000000 (64-bit, non-prefetchable)":
Violation of a PCIe standard?
On Feb 14, 2024, at 09:57, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 14, 2024, at 08:08, John Baldwin <jhb@FreeBSD.org> wrote:
>=20
>> On 2/12/24 5:57 PM, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
>>>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>>>>=20
>>>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>=20
>>>>>> [Gack: I was looking at the wrong vintage of source code, =
predating
>>>>>> your changes: wrong system used.]
>>>>>>=20
>>>>>>=20
>>>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> =
wrote:
>>>>>>=20
>>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>>>>=20
>>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>>>>> Summary:
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>>>>> . . .
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>>>>>> panic: Failed to add resource to rman
>>>>>>>>=20
>>>>>>>> Hmmm, I suspect this is due to the way that =
bus_translate_resource works which is
>>>>>>>> fundamentally broken. It rewrites the start address of a =
resource in-situ instead
>>>>>>>> of keeping downstream resources separate from the upstream =
resources. For example,
>>>>>>>> I don't see how you could ever release a resource in this =
design without completely
>>>>>>>> screwing up your rman. That is, I expect trying to detach a =
PCI device behind a
>>>>>>>> translating bridge that uses the current approach should =
corrupt the allocated
>>>>>>>> resource ranges in an rman long before my changes.
>>>>>>>>=20
>>>>>>>> That said, that doesn't really explain the panic. Hmm, the =
panic might be because
>>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the =
bus_translate_resource
>>>>>>>> hack only kicks in the activate_resource method of =
pci_host_generic.c.
>>>>>>>>=20
>>>>>>>>> Detail:
>>>>>>>>> . . .
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: =
0x40000000
>>>>>>>>=20
>>>>>>>> This indicates this is a translating bus.
>>>>>>>>=20
>>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, =
end 0x1
>>>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, =
end=3D0xc00fffff, count=3D0x100000
>>>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: =
[0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>>>> rman_reserve_resource_bound: trying 0xffffffff =
<0xc0000000,0xfffff>
>>>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 =
(requested 0x100000)
>>>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>>>>> allocating from the beginning
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start =
0x600000000, end 0x6000fffff
>>>>>=20
>>>>> What you later typed does not match:
>>>>>=20
>>>>> 0x600000000
>>>>> 0x6000fffff
>>>>>=20
>>>>> You later typed:
>>>>>=20
>>>>> 0x60000000
>>>>> 0x600fffffff
>>>>>=20
>>>>> This seems to have lead to some confusion from using the
>>>>> wrong figure(s).
>>>>>=20
>>>>>>>> The fact that we are trying to reserve the CPU addresses in the =
rman is because
>>>>>>>> bus_translate_resource rewrote the start address in the =
resource after it was allocated.
>>>>>>>>=20
>>>>>>>> That said, I can't see why rman_manage_region would actually =
fail. At this point the
>>>>>>>> rman is empty (this is the first call to rman_manage_region for =
"pcib1 memory window"),
>>>>>>>> so only the check that should be failing are the checks against =
rm_start and
>>>>>>>> rm_end. For the memory window, rm_start is always 0, and =
rm_end is always
>>>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new =
(0x60000000 - 0x600fffffff)
>>>>>>>> ranges are within those bounds.
>>>>>=20
>>>>> No:
>>>>>=20
>>>>> 0xffffffff
>>>>>=20
>>>>> .vs (actual):
>>>>>=20
>>>>> 0x600000000
>>>>> 0x6000fffff
>>=20
>> Ok, then this explains the failure if the "raw" addresses are above =
4G. I have
>> access to an emag I'm currently using to test fixes to =
pci_host_generic.c to
>> avoid corrupting struct resource objects. I'll post the diff once =
I've got
>> something verified to work.
>>=20
>>> It looks to me like in sys/dev/pci/pci_pci.c the:
>>> static void
>>> pcib_probe_windows(struct pcib_softc *sc)
>>> {
>>> . . .
>>> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, =
0xffffffff);
>>> . . .
>>> is just inappropriately restrictive about where in the system
>>> address space a PCIe can validly be mapped to on the high end.
>>> That, in turn, leads to the rejection on the RPi4B now that
>>> the range use is checked.
>>=20
>> No, the physical register in PCI-PCI bridges is only 32-bits. Only =
the
>> prefetchable BAR supports 64-bit addresses.
>=20
> Just for my edification . . .
>=20
> As I understand, SYS_RES_MEMORY for the BCM2711
> means the 35 bit addressing space in the BCM2711,
> not a PCIe device internal address range that
> corresponds. Am I wrong about that?
>=20
> If I'm wrong, what does identify the 35 bit
> addressing space in the BCM2711?
>=20
> If I'm correct, then the 0..0xffffffff
> seems to be from the wrong address space up
> front. Or, may be, the SYS_RES_MEMORY and the
> 0xffffffff argments are not related as I
> expected and the 0xffffffff is not a
> SYS_RES_MEMORY value?
>=20
>> This is why the host bridge
>> is doing a translation from the CPU side (0x600000000) to the PCI BAR
>> addresses (0xc0000000) so that the BAR addresses are down in the =
32-bit
>> address range. It's also true that many PCI devices only support =
32-bit
>> addresses in memory BARs. 64-bit BARs are an optional extension not
>> universally supported.
>>=20
>> The translation here is somewhat akin to a type of MMU where the CPU
>> addresses are mapped to PCI addresses. The problem here is that the
>> PCI BAR resources need to "stay" as PCI addresses since we depend on
>> being able to use rman_get_start/end to get the PCI addresses of
>> allocated resources, but pci_host_generic.c currently rewrites the
>> addresses.
>>=20
>> Probably I should remove rman_set_start/end entirely (Warner added =
them
>> back in 2004) as the methods don't do anything to deal with the =
fallout
>> that the rman.rm_list linked-list is no longer sorted by address once
>> some addresses get rewritten, etc.
>>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Wed Feb 14 18:17:43 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 4TZmdQ53SMz51hfL;
Wed, 14 Feb 2024 18:17:46 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZmdQ48Jyz4SPB;
Wed, 14 Feb 2024 18:17:46 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707934666;
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=1DODsuObWTMBP56lJdKpk5bTPZocrl/yKB0jED9XwG8=;
b=j7KF7iCdBM3q+xjFzu/qjalhYwG85ocoYiuk+CueGTuaRUUSMP0hJTSvhue8D7hd2OA+41
LqrAHqxdwS8j5f42u4+Qa6CDoS6Ad8HIcy0vPpcE2YVtoW5ghU0B24xq6H9PWiWt6wsmh7
l4nVl9PvtJNZ/kl3aWfhbtO1PEfEZc/V3UdR/W66uJnS+ndm4vdPvfInuZoV9O09OCUaqe
DOD58cei3s6fr/aC+SWsSQw6z4eLEy6kzGLQH50brcNKMZ882TNEdw0GBnp5zminMbq5l9
1+U5C1vxFn752BoeccHEbHqRQ01UEadjDv89yV9vSp/xXQuUxx1zBpxLBku87w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707934666; a=rsa-sha256; cv=none;
b=bIPdZdiYNu6LKdPUyt1+pFK1AJcftwCxx165gomfdHvVd9TNdM3BghKkeLPdBvnwDOcWYP
7mUGXgJxEU7xoKpNC4RFgmu2GJgxCCiJsn1H3Rm0noMJvTH4lH/rbwOAgxmGtfhv+WeE63
te20zMVlgGx83eIfms957h3OmQOA/8SL/+JynX5Swnym9mck72W5jpviFCGmnD6vKfZL5Z
3Sya6yTWyNKs3mc8Md9/RP3GTZm6JoYhlssjCUT3W0thc0JlaqXwPpQncotYG1pkk+W5lD
grmk9LGou+e7KnVZ3cvAkTcrSGZ1h75NSkEg6oMZ3gy7EIUl7Fj3LECJqv+Qtg==
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=1707934666;
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=1DODsuObWTMBP56lJdKpk5bTPZocrl/yKB0jED9XwG8=;
b=B4N5VvsKwOz1iO4el6vzX58bgtLdrCLmaZ6ZsBi0f60jduASnYBVL/UiNV0Hj98dBdbr1A
POi91s2jxuYOgpDWDRiyLRDIgqlDpAQnsoQT8QXJQcNaeQqqhi+A6hEUGNKYVEWPAhsDOE
31M18h2g7OvwRDzDhVbVjHpxJLcpKGETfEQf4qdjZG46rkfFu6X8+cAWX6O6nn40svsGvL
vecfYpYy0tjqkZDfe/1R+ph8AwIufdyZQkZtyYtCzf2WguUUDoIwdi+M7gAfNEXzUIWKkq
wlBmhaqsv21KFOlarDHOk9dHsL9LnC0UYl56NoPqetFls48SO1BnEBoWadHRhg==
Received: from [IPV6:2601:644:937c:5920:5974:74f9:c690:271e] (unknown [IPv6:2601:644:937c:5920:5974:74f9:c690:271e])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZmdP74cJzRgh;
Wed, 14 Feb 2024 18:17:45 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <cf2a5394-f52f-4b6c-b0f8-50f8391467c4@FreeBSD.org>
Date: Wed, 14 Feb 2024 10:17:43 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Mark Millard <marklmi@yahoo.com>
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/14/24 9:57 AM, Mark Millard wrote:
> On Feb 14, 2024, at 08:08, John Baldwin <jhb@FreeBSD.org> wrote:
>
>> On 2/12/24 5:57 PM, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
>>>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
>>>>
>>>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>
>>>>>> [Gack: I was looking at the wrong vintage of source code, predating
>>>>>> your changes: wrong system used.]
>>>>>>
>>>>>>
>>>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>>
>>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
>>>>>>>
>>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>>>>>>>> Summary:
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>>>>>>>>> . . .
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
>>>>>>>>> panic: Failed to add resource to rman
>>>>>>>>
>>>>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource works which is
>>>>>>>> fundamentally broken. It rewrites the start address of a resource in-situ instead
>>>>>>>> of keeping downstream resources separate from the upstream resources. For example,
>>>>>>>> I don't see how you could ever release a resource in this design without completely
>>>>>>>> screwing up your rman. That is, I expect trying to detach a PCI device behind a
>>>>>>>> translating bridge that uses the current approach should corrupt the allocated
>>>>>>>> resource ranges in an rman long before my changes.
>>>>>>>>
>>>>>>>> That said, that doesn't really explain the panic. Hmm, the panic might be because
>>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the bus_translate_resource
>>>>>>>> hack only kicks in the activate_resource method of pci_host_generic.c.
>>>>>>>>
>>>>>>>>> Detail:
>>>>>>>>> . . .
>>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
>>>>>>>>
>>>>>>>> This indicates this is a translating bus.
>>>>>>>>
>>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
>>>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end 0x1
>>>>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000
>>>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>>>> rman_reserve_resource_bound: trying 0xffffffff <0xc0000000,0xfffff>
>>>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000 (requested 0x100000)
>>>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
>>>>>>>>> allocating from the beginning
>>>>>>>>> rman_manage_region: <pcib1 memory window> request: start 0x600000000, end 0x6000fffff
>>>>>
>>>>> What you later typed does not match:
>>>>>
>>>>> 0x600000000
>>>>> 0x6000fffff
>>>>>
>>>>> You later typed:
>>>>>
>>>>> 0x60000000
>>>>> 0x600fffffff
>>>>>
>>>>> This seems to have lead to some confusion from using the
>>>>> wrong figure(s).
>>>>>
>>>>>>>> The fact that we are trying to reserve the CPU addresses in the rman is because
>>>>>>>> bus_translate_resource rewrote the start address in the resource after it was allocated.
>>>>>>>>
>>>>>>>> That said, I can't see why rman_manage_region would actually fail. At this point the
>>>>>>>> rman is empty (this is the first call to rman_manage_region for "pcib1 memory window"),
>>>>>>>> so only the check that should be failing are the checks against rm_start and
>>>>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end is always
>>>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new (0x60000000 - 0x600fffffff)
>>>>>>>> ranges are within those bounds.
>>>>>
>>>>> No:
>>>>>
>>>>> 0xffffffff
>>>>>
>>>>> .vs (actual):
>>>>>
>>>>> 0x600000000
>>>>> 0x6000fffff
>>
>> Ok, then this explains the failure if the "raw" addresses are above 4G. I have
>> access to an emag I'm currently using to test fixes to pci_host_generic.c to
>> avoid corrupting struct resource objects. I'll post the diff once I've got
>> something verified to work.
>>
>>> It looks to me like in sys/dev/pci/pci_pci.c the:
>>> static void
>>> pcib_probe_windows(struct pcib_softc *sc)
>>> {
>>> . . .
>>> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
>>> . . .
>>> is just inappropriately restrictive about where in the system
>>> address space a PCIe can validly be mapped to on the high end.
>>> That, in turn, leads to the rejection on the RPi4B now that
>>> the range use is checked.
>>
>> No, the physical register in PCI-PCI bridges is only 32-bits. Only the
>> prefetchable BAR supports 64-bit addresses.
>
> Just for my edification . . .
>
> As I understand, SYS_RES_MEMORY for the BCM2711
> means the 35 bit addressing space in the BCM2711,
> not a PCIe device internal address range that
> corresponds. Am I wrong about that?
>
> If I'm wrong, what does identify the 35 bit
> addressing space in the BCM2711?
>
> If I'm correct, then the 0..0xffffffff
> seems to be from the wrong address space up
> front. Or, may be, the SYS_RES_MEMORY and the
> 0xffffffff argments are not related as I
> expected and the 0xffffffff is not a
> SYS_RES_MEMORY value?
We use SYS_RES_MEMORY for both address spaces. SYS_RES_MEMORY is more of
an address space "type" and doesn't necessarily name a single, unique
address space. The way to think about these address spaces is instances
of 'struct rman'. There's a global 'struct rman' in the arm64 nexus
driver that represents the CPU physical memory address space. The
pci_host_generic driver contains its own 'struct rman' instances that
represent the SYS_RES_MEMORY (for memory PCI BARs) and SYS_RES_IOPORT
(for I/O port PCI BARs) address spaces.
Put another way, SYS_RES_MEMORY names an I/O memory address space
relative to a device's given position in the tree. For a given device
node in the tree, SYS_RES_MEMORY is unique, but what it maps onto is
defined by a parent bus device.
--
John Baldwin
From nobody Wed Feb 14 18:23:56 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 4TZmmZ1n83z51jvq;
Wed, 14 Feb 2024 18:23:58 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZmmZ12Plz4WTr;
Wed, 14 Feb 2024 18:23:58 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1707935038;
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=TLwPYqfHBEgA07fG6sinqIBnb97j/AJBeN2GM4tRIUE=;
b=dTabW5U61wyZwVxbMez5kvq7y6ddH1j3iAHf6zdmLbnqMB5v9s9f3xJODerlnCCoL+vAIZ
jszsgTxLbporIC0visJZmKFpoUPDZcZAhVKgxwOLjvjUYFzpZCeTy7JktiqgEfYYTQa2iE
UjCmybcPOr288ydRn/trw3LswlD9Giu6Lu2wnU8GBBByvyDLnjIjD9Q1Q9LFE66zRRCRhA
r33kOoBnMhsF32JPX1jKAeILnIRh4JeShYG3YpxgAUGNKB2rRf6Bx0+obAyGO6CYzQ/tgV
qS8htP/TIuogmz68GzSX4OlOWAAKahtLmJZsD9Jkj9VXTK1GDRs+ai4iVY/dWQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707935038; a=rsa-sha256; cv=none;
b=MUiAkl51VuBQEaeo8OtDQrWxGinsmA5Z91g7scOIG5xdQdmOs4Rz+ynY3RdV+CwxON5Ywe
ClK88fWsA34D9AlmqBDi1yJtE2F7hLhLhBjeJ07dm45iy1TavsSBQ7J0+I8TSO261Hm9AP
ezfv7j2up32Jkfsstbt69q9TioTrjnVFeRpdyvl8AuYIMY2Id7HlBgVfJXlj0Unx0lYluI
VGbuuqSWTdqETIIrydaWxR8DSu2u1glem8k7igFajkf9rfH17pqir7JgJ14F9mZ8gFU5lg
L1G1LEf1lU5666gNZvkXRuPH20YXU25AKpupGkqCtqMkZyKScUZWtjRsQnO6kQ==
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=1707935038;
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=TLwPYqfHBEgA07fG6sinqIBnb97j/AJBeN2GM4tRIUE=;
b=yrIZ7eSUzbeccUiEoJAYgMCjfo3A8mw8BwIo6q8RorhBkIaItYSGR1bKwmZpokIpimg0dz
PzgbaT8M/9RMEPAZJPofQsFR5gFhodWYsiLH6ubT5usOx31CxhAKjb75bcUZF0by/X5Y8J
DMYH3liUl8kQLZND+60iWAclg5zj0ch5QYcW31olZKVRZB1K83NHziGuXhpTHHoJoqLJTB
dcFmlnhqyuxk5XDwZl+TeJZi7oCv8pN/eaT4wMsTlpg+GUPNY3LklWg3dFW9fP4DZXw6rr
e2mrYFtnTSswyx9eESDI8IP/udoPaiCBLSqaSV+ywAG/GKUtL1bGTYE+OitQMA==
Received: from [IPV6:2601:644:937c:5920:4c63:23c7:5c22:d7ba] (unknown [IPv6:2601:644:937c:5920:4c63:23c7:5c22:d7ba])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TZmmY46YWzRjN;
Wed, 14 Feb 2024 18:23:57 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
Date: Wed, 14 Feb 2024 10:23:56 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
Content-Language: en-US
To: Mark Millard <marklmi@yahoo.com>
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/14/24 10:16 AM, Mark Millard wrote:
> Top posting a related but separate item:
>
> I looked up some old (2022-Dec-17) lspci -v output from
> a Linux boot. Note the "Memory at" value 600000000 (in
> the 35 bit BCM2711 address space) and the "(64-bit,
> non-prefetchable)" (and "[size=4K]").
>
> 01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01) (prog-if 30 [XHCI])
> Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller
> Device tree node: /sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
> Flags: bus master, fast devsel, latency 0, IRQ 51
> Memory at 600000000 (64-bit, non-prefetchable) [size=4K]
> Capabilities: [80] Power Management version 3
> Capabilities: [90] MSI: Enable+ Count=1/4 Maskable- 64bit+
> Capabilities: [c4] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Kernel driver in use: xhci_hcd
>
>
> "Memory at 600000000 (64-bit, non-prefetchable)":
> Violation of a PCIe standard?
No, this is a device BAR which can be 64-bit (memory BARs can either
be 32-bits or 64-bits). However, the "window" in a PCI _bridge_ for
memory is only defined to be 32-bits. Windows in PCI-PCI bridges
are a special type of BAR that defines the address ranges that the
bridge decodes on the parent side and passes down to child devices.
The prefetchable window in PCI-PCI bridges can optionally be 64-bit.
BAR == a range of memory or I/O port addresses decoded by a device,
usually mapped to a register bank, but sometimes mapped to internal
memory (e.g. a framebuffer)
Window == a range of memory or I/O port addresses decoded by a bridge
for which transactions are passed across the bridge to be handled by
a child device.
--
John Baldwin
From nobody Wed Feb 14 18:45: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 4TZnFz3RMsz51mmy
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 18:45:59 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b])
(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 4TZnFz1KHjz4b4y
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 18:45:59 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-561587ce966so153430a12.1
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 10:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1707936358; x=1708541158; 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=ksiIdJwHkc+JLXgXUyQdZyacITAs7IyrYG0GJD+9dbA=;
b=yyILMmYyHwVQPP62pfdJnXyJXpTIQ0ZhzD1NPezPaZ22Mcf1oWJiI6oL9CJjp0qQfZ
fSGNiDgloKy6kVVLWK0COp0n1IOVa3ihXHX30F/j4A1cgo/FwpKF6Gy0jZd0WiWUb14x
vze+Lme11AXfm6W7hxpPYCgCPScOnKxPTrgdJGmwyQCrOV2iFedvae+h/ejZveaz9HuQ
rh5glcuCLTpKcWqNQLRs2SIiEYZ8BzFoHHMjq1K+IS7NHqbtFEG+jT0bn7iDJl8BZdpu
rxZMLRRiEVEHZgk4JjgIOfBgRT18Q35zysl3jPXp0QrZtBEqcipHQLQdihOmgw8FAyJK
83qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707936358; x=1708541158;
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=ksiIdJwHkc+JLXgXUyQdZyacITAs7IyrYG0GJD+9dbA=;
b=C0uMkZPktTePp/D7Vvyapy8WBPEHzifTvD6ndmK7yGT3elJLhGIo53pWYnlnnWmesv
lDii6iyMJo7fXS3TuU3E+nQVdR159yAkra9VIlBfPPCI/gn4SiIWFNAWAFskOpCNw0Ri
UwABS63QIGo61EiAAuJT+UySBzkvfEnpO5Nsggxo7H8cB+BjK16lafxqS5F3mdNWvd+e
Baw0xLxCs1G/5DpP0YcBOPDEg50hTVoCGyaw5BFI7uSdaHTxuesrV8Ro80tCOy+1uDZZ
22Z0VhX0D2kakN0gyNLbDuwaDPjos/QjTqDB0F9+8vuydfM0R7nrccuNFYTor62Z3LDN
vXCw==
X-Forwarded-Encrypted: i=1; AJvYcCUpStw2wvksV9MJ7qFO3Zp4aFkOOmawSZdVFZDARno/WXb3LqgzciQEZ091KxX7kxDFxsG7jnCHrX3M0jk74HGx4q9v2nI+9+t9W30=
X-Gm-Message-State: AOJu0YzOW3EdGUjSrOYpKBS62bGzhhwIKliFb6v/Dnonq8o/HS1YRwWo
6COQYy8GBUNvHAl25FWH0g4EGzCj6yoonhFcVPqCPVJ+64LxgSj4aSY425WiRqMF2AXLHIk9pmV
AqiuC9Sv8LzrMFNxz95d80lNe/Mc93bndYeUxAw==
X-Google-Smtp-Source: AGHT+IHJu5L8SOUlWD8AmH7X8Md6iZrTY1c2M1JmDaPGRi/pCeAMEV0zhOkXuotcoNjL0cYLyrpK367MLTJ3lHH/BGk=
X-Received: by 2002:aa7:c541:0:b0:562:1a77:19a7 with SMTP id
s1-20020aa7c541000000b005621a7719a7mr2696303edr.11.1707936357796; Wed, 14 Feb
2024 10:45:57 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com> <3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com> <d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<CANCZdfrX+JpiKgU4Bo+-dwX_YVszYXT9hy_S+xS91Z8RmiWONQ@mail.gmail.com> <f07d8fa2-c3e1-44f1-b355-544619ed2e5e@FreeBSD.org>
In-Reply-To: <f07d8fa2-c3e1-44f1-b355-544619ed2e5e@FreeBSD.org>
From: Warner Losh <imp@bsdimp.com>
Date: Wed, 14 Feb 2024 11:45:45 -0700
Message-ID: <CANCZdfrsjfDmn8zfz9LBsjwH+Ro5iUA6mK_6GiuVpJCrky2_XQ@mail.gmail.com>
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
To: John Baldwin <jhb@freebsd.org>
Cc: Mark Millard <marklmi@yahoo.com>, FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>
Content-Type: multipart/alternative; boundary="000000000000e7df3f06115beb28"
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: 4TZnFz1KHjz4b4y
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
--000000000000e7df3f06115beb28
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey John,
On Wed, Feb 14, 2024 at 10:30=E2=80=AFAM John Baldwin <jhb@freebsd.org> wro=
te:
> On 2/14/24 8:42 AM, Warner Losh wrote:
> > On Wed, Feb 14, 2024 at 9:08=E2=80=AFAM John Baldwin <jhb@freebsd.org> =
wrote:
> >
> >> On 2/12/24 5:57 PM, Mark Millard wrote:
> >>> On Feb 12, 2024, at 16:36, Mark Millard <marklmi@yahoo.com> wrote:
> >>>
> >>>> On Feb 12, 2024, at 16:10, Mark Millard <marklmi@yahoo.com> wrote:
> >>>>
> >>>>> On Feb 12, 2024, at 12:00, Mark Millard <marklmi@yahoo.com> wrote:
> >>>>>
> >>>>>> [Gack: I was looking at the wrong vintage of source code, predatin=
g
> >>>>>> your changes: wrong system used.]
> >>>>>>
> >>>>>>
> >>>>>> On Feb 12, 2024, at 10:41, Mark Millard <marklmi@yahoo.com> wrote:
> >>>>>>
> >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <jhb@freebsd.org> wrote:
> >>>>>>>
> >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
> >>>>>>>>> Summary:
> >>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
> >> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> >>>>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
> >> 0x40000000
> >>>>>>>>> . . .
> >>>>>>>>> rman_manage_region: <pcib1 memory window> request: start
> >> 0x600000000, end 0x6000fffff
> >>>>>>>>> panic: Failed to add resource to rman
> >>>>>>>>
> >>>>>>>> Hmmm, I suspect this is due to the way that bus_translate_resour=
ce
> >> works which is
> >>>>>>>> fundamentally broken. It rewrites the start address of a resour=
ce
> >> in-situ instead
> >>>>>>>> of keeping downstream resources separate from the upstream
> >> resources. For example,
> >>>>>>>> I don't see how you could ever release a resource in this design
> >> without completely
> >>>>>>>> screwing up your rman. That is, I expect trying to detach a PCI
> >> device behind a
> >>>>>>>> translating bridge that uses the current approach should corrupt
> >> the allocated
> >>>>>>>> resource ranges in an rman long before my changes.
> >>>>>>>>
> >>>>>>>> That said, that doesn't really explain the panic. Hmm, the pani=
c
> >> might be because
> >>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the
> >> bus_translate_resource
> >>>>>>>> hack only kicks in the activate_resource method of
> >> pci_host_generic.c.
> >>>>>>>>
> >>>>>>>>> Detail:
> >>>>>>>>> . . .
> >>>>>>>>> pcib0: <BCM2838-compatible PCI-express controller> mem
> >> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
> >>>>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x600000000, Size:
> >> 0x40000000
> >>>>>>>>
> >>>>>>>> This indicates this is a translating bus.
> >>>>>>>>
> >>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 at device 0.0 on pci0
> >>>>>>>>> rman_manage_region: <pcib1 bus numbers> request: start 0x1, end
> 0x1
> >>>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00ff=
fff,
> >> count=3D0x100000
> >>>>>>>>> rman_reserve_resource_bound: <PCIe Memory> request: [0xc0000000=
,
> >> 0xc00fffff], length 0x100000, flags 102, device pcib1
> >>>>>>>>> rman_reserve_resource_bound: trying 0xffffffff
> <0xc0000000,0xfffff>
> >>>>>>>>> considering [0xc0000000, 0xffffffff]
> >>>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; size 0x100000
> >> (requested 0x100000)
> >>>>>>>>> candidate region: [0xc0000000, 0xc00fffff], size 0x100000
> >>>>>>>>> allocating from the beginning
> >>>>>>>>> rman_manage_region: <pcib1 memory window> request: start
> >> 0x600000000, end 0x6000fffff
> >>>>>
> >>>>> What you later typed does not match:
> >>>>>
> >>>>> 0x600000000
> >>>>> 0x6000fffff
> >>>>>
> >>>>> You later typed:
> >>>>>
> >>>>> 0x60000000
> >>>>> 0x600fffffff
> >>>>>
> >>>>> This seems to have lead to some confusion from using the
> >>>>> wrong figure(s).
> >>>>>
> >>>>>>>> The fact that we are trying to reserve the CPU addresses in the
> >> rman is because
> >>>>>>>> bus_translate_resource rewrote the start address in the resource
> >> after it was allocated.
> >>>>>>>>
> >>>>>>>> That said, I can't see why rman_manage_region would actually fai=
l.
> >> At this point the
> >>>>>>>> rman is empty (this is the first call to rman_manage_region for
> >> "pcib1 memory window"),
> >>>>>>>> so only the check that should be failing are the checks against
> >> rm_start and
> >>>>>>>> rm_end. For the memory window, rm_start is always 0, and rm_end
> is
> >> always
> >>>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00fffff) and new
> >> (0x60000000 - 0x600fffffff)
> >>>>>>>> ranges are within those bounds.
> >>>>>
> >>>>> No:
> >>>>>
> >>>>> 0xffffffff
> >>>>>
> >>>>> .vs (actual):
> >>>>>
> >>>>> 0x600000000
> >>>>> 0x6000fffff
> >>
> >> Ok, then this explains the failure if the "raw" addresses are above
> 4G. I
> >> have
> >> access to an emag I'm currently using to test fixes to
> pci_host_generic.c
> >> to
> >> avoid corrupting struct resource objects. I'll post the diff once I'v=
e
> got
> >> something verified to work.
> >>
> >>> It looks to me like in sys/dev/pci/pci_pci.c the:
> >>>
> >>> static void
> >>> pcib_probe_windows(struct pcib_softc *sc)
> >>> {
> >>> . . .
> >>> pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0,
> 0xffffffff);
> >>> . . .
> >>>
> >>> is just inappropriately restrictive about where in the system
> >>> address space a PCIe can validly be mapped to on the high end.
> >>> That, in turn, leads to the rejection on the RPi4B now that
> >>> the range use is checked.
> >>
> >> No, the physical register in PCI-PCI bridges is only 32-bits. Only th=
e
> >> prefetchable BAR supports 64-bit addresses. This is why the host brid=
ge
> >> is doing a translation from the CPU side (0x600000000) to the PCI BAR
> >> addresses (0xc0000000) so that the BAR addresses are down in the 32-bi=
t
> >> address range. It's also true that many PCI devices only support 32-b=
it
> >> addresses in memory BARs. 64-bit BARs are an optional extension not
> >> universally supported.
> >>
> >> The translation here is somewhat akin to a type of MMU where the CPU
> >> addresses are mapped to PCI addresses. The problem here is that the
> >> PCI BAR resources need to "stay" as PCI addresses since we depend on
> >> being able to use rman_get_start/end to get the PCI addresses of
> >> allocated resources, but pci_host_generic.c currently rewrites the
> >> addresses.
> >>
> >> Probably I should remove rman_set_start/end entirely (Warner added the=
m
> >> back in 2004) as the methods don't do anything to deal with the fallou=
t
> >> that the rman.rm_list linked-list is no longer sorted by address once
> >> some addresses get rewritten, etc.
> >>
> >
> > At the time, they made sense. Removing it, though may take some doing
> > since we use it in about 284 places in sys/dev today... Somewhat more
> > pervasive than I'd have thought they'd be...
>
> Eh, I only find the one that I'm now removing:
>
> % git grep -E 'rman_set_(start|end)' sys/
> sys/dev/pci/pci_host_generic.c: rman_set_start(r, start);
> sys/dev/pci/pci_host_generic.c: rman_set_end(r, end);
> sys/kern/subr_rman.c:rman_set_start(struct resource *r, rman_res_t start)
> sys/kern/subr_rman.c:rman_set_end(struct resource *r, rman_res_t end)
> sys/sys/rman.h:void rman_set_end(struct resource *_r, rman_res_t _end=
);
> sys/sys/rman.h:void rman_set_start(struct resource *_r, rman_res_t
> _start);
>
> Also, I managed to boot the emag I have access to this morning. I had to
> fix a few other bugs in acpi(4) for my changes in pci_host_generic to wor=
k
> but will post reviews later today.
>
That's what happens when you grep for 'get' instead of 'set' before the
morning caffeine kicks in ..
Warner
--000000000000e7df3f06115beb28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hey John,<br></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 14, 2024 at 10:3=
0=E2=80=AFAM John Baldwin <<a href=3D"mailto:jhb@freebsd.org">jhb@freebs=
d.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">On 2/14/24 8:42 AM, Warner Losh wrote:<br>
> On Wed, Feb 14, 2024 at 9:08=E2=80=AFAM John Baldwin <<a href=3D"ma=
ilto:jhb@freebsd.org" target=3D"_blank">jhb@freebsd.org</a>> wrote:<br>
> <br>
>> On 2/12/24 5:57 PM, Mark Millard wrote:<br>
>>> On Feb 12, 2024, at 16:36, Mark Millard <<a href=3D"mailto:=
marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
>>><br>
>>>> On Feb 12, 2024, at 16:10, Mark Millard <<a href=3D"mai=
lto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<b=
r>
>>>><br>
>>>>> On Feb 12, 2024, at 12:00, Mark Millard <<a href=3D=
"mailto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrot=
e:<br>
>>>>><br>
>>>>>> [Gack: I was looking at the wrong vintage of sourc=
e code, predating<br>
>>>>>> your changes: wrong system used.]<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Feb 12, 2024, at 10:41, Mark Millard <<a hre=
f=3D"mailto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> =
wrote:<br>
>>>>>><br>
>>>>>>> On Feb 12, 2024, at 09:32, John Baldwin <<a=
href=3D"mailto:jhb@freebsd.org" target=3D"_blank">jhb@freebsd.org</a>> =
wrote:<br>
>>>>>>><br>
>>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:<br>
>>>>>>>>> Summary:<br>
>>>>>>>>> pcib0: <BCM2838-compatible PCI-expr=
ess controller> mem<br>
>> 0x7d500000-0x7d50930f irq 80,81 on simplebus2<br>
>>>>>>>>> pcib0: parsing FDT for ECAM0:<br>
>>>>>>>>> pcib0:=C2=A0 PCI addr: 0xc0000000, CPU=
addr: 0x600000000, Size:<br>
>> 0x40000000<br>
>>>>>>>>> . . .<br>
>>>>>>>>> rman_manage_region: <pcib1 memory w=
indow> request: start<br>
>> 0x600000000, end 0x6000fffff<br>
>>>>>>>>> panic: Failed to add resource to rman<=
br>
>>>>>>>><br>
>>>>>>>> Hmmm, I suspect this is due to the way tha=
t bus_translate_resource<br>
>> works which is<br>
>>>>>>>> fundamentally broken.=C2=A0 It rewrites th=
e start address of a resource<br>
>> in-situ instead<br>
>>>>>>>> of keeping downstream resources separate f=
rom the upstream<br>
>> resources.=C2=A0 =C2=A0For example,<br>
>>>>>>>> I don't see how you could ever release=
a resource in this design<br>
>> without completely<br>
>>>>>>>> screwing up your rman.=C2=A0 That is, I ex=
pect trying to detach a PCI<br>
>> device behind a<br>
>>>>>>>> translating bridge that uses the current a=
pproach should corrupt<br>
>> the allocated<br>
>>>>>>>> resource ranges in an rman long before my =
changes.<br>
>>>>>>>><br>
>>>>>>>> That said, that doesn't really explain=
the panic.=C2=A0 Hmm, the panic<br>
>> might be because<br>
>>>>>>>> for PCI bridge windows the driver now pass=
es RF_ACTIVE and the<br>
>> bus_translate_resource<br>
>>>>>>>> hack only kicks in the activate_resource m=
ethod of<br>
>> pci_host_generic.c.<br>
>>>>>>>><br>
>>>>>>>>> Detail:<br>
>>>>>>>>> . . .<br>
>>>>>>>>> pcib0: <BCM2838-compatible PCI-expr=
ess controller> mem<br>
>> 0x7d500000-0x7d50930f irq 80,81 on simplebus2<br>
>>>>>>>>> pcib0: parsing FDT for ECAM0:<br>
>>>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr:=
0x600000000, Size:<br>
>> 0x40000000<br>
>>>>>>>><br>
>>>>>>>> This indicates this is a translating bus.<=
br>
>>>>>>>><br>
>>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 a=
t device 0.0 on pci0<br>
>>>>>>>>> rman_manage_region: <pcib1 bus numb=
ers> request: start 0x1, end 0x1<br>
>>>>>>>>> pcib0: rman_reserve_resource: start=3D=
0xc0000000, end=3D0xc00fffff,<br>
>> count=3D0x100000<br>
>>>>>>>>> rman_reserve_resource_bound: <PCIe =
Memory> request: [0xc0000000,<br>
>> 0xc00fffff], length 0x100000, flags 102, device pcib1<br>
>>>>>>>>> rman_reserve_resource_bound: trying 0x=
ffffffff <0xc0000000,0xfffff><br>
>>>>>>>>> considering [0xc0000000, 0xffffffff]<b=
r>
>>>>>>>>> truncated region: [0xc0000000, 0xc00ff=
fff]; size 0x100000<br>
>> (requested 0x100000)<br>
>>>>>>>>> candidate region: [0xc0000000, 0xc00ff=
fff], size 0x100000<br>
>>>>>>>>> allocating from the beginning<br>
>>>>>>>>> rman_manage_region: <pcib1 memory w=
indow> request: start<br>
>> 0x600000000, end 0x6000fffff<br>
>>>>><br>
>>>>> What you later typed does not match:<br>
>>>>><br>
>>>>> 0x600000000<br>
>>>>> 0x6000fffff<br>
>>>>><br>
>>>>> You later typed:<br>
>>>>><br>
>>>>> 0x60000000<br>
>>>>> 0x600fffffff<br>
>>>>><br>
>>>>> This seems to have lead to some confusion from using t=
he<br>
>>>>> wrong figure(s).<br>
>>>>><br>
>>>>>>>> The fact that we are trying to reserve the=
CPU addresses in the<br>
>> rman is because<br>
>>>>>>>> bus_translate_resource rewrote the start a=
ddress in the resource<br>
>> after it was allocated.<br>
>>>>>>>><br>
>>>>>>>> That said, I can't see why rman_manage=
_region would actually fail.<br>
>> At this point the<br>
>>>>>>>> rman is empty (this is the first call to r=
man_manage_region for<br>
>> "pcib1 memory window"),<br>
>>>>>>>> so only the check that should be failing a=
re the checks against<br>
>> rm_start and<br>
>>>>>>>> rm_end.=C2=A0 For the memory window, rm_st=
art is always 0, and rm_end is<br>
>> always<br>
>>>>>>>> 0xffffffff, so both the old (0xc00000000 -=
0xc00fffff) and new<br>
>> (0x60000000 - 0x600fffffff)<br>
>>>>>>>> ranges are within those bounds.<br>
>>>>><br>
>>>>> No:<br>
>>>>><br>
>>>>> 0xffffffff<br>
>>>>><br>
>>>>> .vs (actual):<br>
>>>>><br>
>>>>> 0x600000000<br>
>>>>> 0x6000fffff<br>
>><br>
>> Ok, then this explains the failure if the "raw" addresse=
s are above 4G.=C2=A0 I<br>
>> have<br>
>> access to an emag I'm currently using to test fixes to pci_hos=
t_generic.c<br>
>> to<br>
>> avoid corrupting struct resource objects.=C2=A0 I'll post the =
diff once I've got<br>
>> something verified to work.<br>
>><br>
>>> It looks to me like in sys/dev/pci/pci_pci.c the:<br>
>>><br>
>>> static void<br>
>>> pcib_probe_windows(struct pcib_softc *sc)<br>
>>> {<br>
>>> . . .<br>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pcib_alloc_window(sc, =
&sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);<br>
>>> . . .<br>
>>><br>
>>> is just inappropriately restrictive about where in the system<=
br>
>>> address space a PCIe can validly be mapped to on the high end.=
<br>
>>> That, in turn, leads to the rejection on the RPi4B now that<br=
>
>>> the range use is checked.<br>
>><br>
>> No, the physical register in PCI-PCI bridges is only 32-bits.=C2=
=A0 Only the<br>
>> prefetchable BAR supports 64-bit addresses.=C2=A0 This is why the =
host bridge<br>
>> is doing a translation from the CPU side (0x600000000) to the PCI =
BAR<br>
>> addresses (0xc0000000) so that the BAR addresses are down in the 3=
2-bit<br>
>> address range.=C2=A0 It's also true that many PCI devices only=
support 32-bit<br>
>> addresses in memory BARs.=C2=A0 64-bit BARs are an optional extens=
ion not<br>
>> universally supported.<br>
>><br>
>> The translation here is somewhat akin to a type of MMU where the C=
PU<br>
>> addresses are mapped to PCI addresses.=C2=A0 The problem here is t=
hat the<br>
>> PCI BAR resources need to "stay" as PCI addresses since =
we depend on<br>
>> being able to use rman_get_start/end to get the PCI addresses of<b=
r>
>> allocated resources, but pci_host_generic.c currently rewrites the=
<br>
>> addresses.<br>
>><br>
>> Probably I should remove rman_set_start/end entirely (Warner added=
them<br>
>> back in 2004) as the methods don't do anything to deal with th=
e fallout<br>
>> that the rman.rm_list linked-list is no longer sorted by address o=
nce<br>
>> some addresses get rewritten, etc.<br>
>><br>
> <br>
> At the time, they made sense. Removing it, though may take some doing<=
br>
> since we use it in about 284 places=C2=A0 in sys/dev today... Somewhat=
more<br>
> pervasive than I'd have thought they'd be...<br>
<br>
Eh, I only find the one that I'm now removing:<br>
<br>
% git grep -E 'rman_set_(start|end)' sys/<br>
sys/dev/pci/pci_host_generic.c: rman_set_start(r, start);<br>
sys/dev/pci/pci_host_generic.c: rman_set_end(r, end);<br>
sys/kern/subr_rman.c:rman_set_start(struct resource *r, rman_res_t start)<b=
r>
sys/kern/subr_rman.c:rman_set_end(struct resource *r, rman_res_t end)<br>
sys/sys/rman.h:void=C2=A0 =C2=A0 =C2=A0rman_set_end(struct resource *_r, rm=
an_res_t _end);<br>
sys/sys/rman.h:void=C2=A0 =C2=A0 =C2=A0rman_set_start(struct resource *_r, =
rman_res_t _start);<br>
<br>
Also, I managed to boot the emag I have access to this morning.=C2=A0 I had=
to<br>
fix a few other bugs in acpi(4) for my changes in pci_host_generic to work<=
br>
but will post reviews later today.<br></blockquote><div><br></div><div>That=
's what happens when you grep for 'get' instead of 'set'=
; before the morning caffeine kicks in ..</div><div><br></div><div>Warner</=
div></div></div>
--000000000000e7df3f06115beb28--
From nobody Wed Feb 14 20:04: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 4TZq0n65N4z52kFg
for <freebsd-current@mlmmj.nyi.freebsd.org>; Wed, 14 Feb 2024 20:04:41 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZq0n3C0Gz4pBg
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 20:04:41 +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=1707941079; bh=uQn9c2r1u6XAou+9lOv3df9TplyPdH0dHnMgHP8UgYY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qY4go2lUYaUzT76jq38SuSGtGIRd14015cAO5BcnZmXtVIIEB9o05VNkZhQOehABjBtTkkNcSbcGhKGEwwsZAVs2YGWxaOPp8b+ZBvhRVvKAT+khBI/gCFAmqbNA2Op9Z2TNCv2VDrG04q8yehiDvBQLVSRrUb9kyYk9zFD9tVR/+2SADJmTixRmlwVg1HaAByixmt4Wgm5pHRdkX9s0JJ6b+JSK5h7I14ba5TM5dOGvm85aqNRxoyeieAGAlIRSKilSNzENS/oGd0tRa1h5BLeZXlTUhVXK/36P3YkZZY4GCtQ2Wi/Lvwg5jqfnfmciIGsNdoDBU8Ac4sNGRAbECA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707941079; bh=91WMRUCvXjNLbRZh/mfvCQQXHrxC5h4QaOmuyepbDyC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LWQsnhWdyoFkHFvdtFntZ6zXU0u66iT9sQAhHLQO16lQ9pTCR91nhHJNvXgsxG8PKn11Nkl1i/AAY82YzArjpWEfoFJDYqChzrD/TZAs87E2KnQQwckIoehbYP5jFKurrQ+c8TJ9cCQbHTLrYbwV1/cp73DY+sZmt6Xg+H/T2wS4H/zORSi5yko/HvcpZGYTTvJPTiUKM6c6iCzDzeEA38kOPiMW4QKvtkBXfsTPyzgWYPXhFGJrYQRjIhivq0lIBKBPJEXjzuzmCqxORh+mRb3HVqbNu3P/Vj2kCZlkAs3LwyoaAaz8YCvJbgI4KZPgIcacvoxeDdhrm8xVuzzMtQ==
X-YMail-OSG: Lm3eQi4VM1nqGsfifZWO8BiA._cNrdfQGyWLQ_RThvXogK.kJWr3yCjtZpuJUkC
PuD9eAstissGbNb3GvKWIna5GG0VFL1mlNW3ZZukZLbmNIxzvWcEOk4oFgzsaLV6lCElpdekbG0X
yU_usdugvaStrw2wKY3M00cDrIX7MkRRi_oyQwPGhoTX.Kcmyk1PYUwyFUZkUEJmpfK_BnVDqUdO
2rfYSCaAFJe12A87Q0lmerBKAyOGu7rFNmK3Su6w2i4Dygob3Z42GQ_gZFnQLQ706NyTpvL3xnlO
mNwTYP2Zjz7LKAakv9z1y11vHDvJX.35Y2gpeABVZKoYqHFadN.z2RLwthHu9wtyDy21dSeGXyxm
OELumNg3vZhADSKvX74IKdi3.UjeXiqri_8rGnoTOsfl5KlkTZ.xo1gnsgp19MgSxbFmmNvgFs6B
o6zTIWw3BPGZ1XAbdA2x7WGLJnSnc76I5_5RWcYsyoLJoSiV.1GIuEcu5648J4hdJixDPo6T2Tk2
xpXYiOnOK4MhhLHo21mdlP45_8tkpAFY1dQTl.Rbzn8FHjMOpVbVo8FSvduntJ9WKDX56LKIB9lQ
OSHy6fEZu2UHG8pgKyYWD01cHY21NeKm9mPXCXg3fZIRN2mJqw4g4xZLh5CHfax0GXmVWToYkd0W
VuLVK.4DQzoNWZwfOaQp4f8zXOp6NYEJUAN_xLupzYclnHwZzqS.NUJtJjULxWagwuWJ3s29Klvv
BomASwP_Y4qlvqouiBuIcAVLhquglMUXQPa_u26CW7kFyakdTwd4Dhg8dTbgM7xm1FNtBGcZITrg
mUgTPT6CdDJKdzlgh1NfU1_gTL1TEcnZ9qhzlvKKdy.xftp54QURkt3HGmk3dpvINo2as1.DXb4C
oJJST.2GBRTTaMHKwBlFJwDjEXTQDM6ZES_xtddrb4lmTJPH0w9nA4InTrJPxcpkEsPfNYnKv6ck
tqUwUH9iUq.xmHV4vmGte4rSiJ69.Aua0Bgnd1hQBoUa_29k.v4tfDzqoLQEo6RVNIeA3_kDqEYR
0xKerjVeDoiNU82ghruPyE4vHmCfaujh_q1PQqmepwJF9evCwgkvSMQ4kl9_BmtvXBYCJ48wpuDe
lGbkYkXe6.eFeGxAlKg9UhxLCUBHZbWdmdM4LO9C5Nvs5F6lGzuaWKC.1xFWz376KqFxDdUVFLui
9I_8vQJToe6s1FydI4UdKoGeKgePjpdzGu9eDoUeKg.EsK8wlgve.jI9edunTL7WbMXtLG2rgVzZ
cQ_I8xTxqONH4fvqqOLW4SABrMCxi2FUMs77L8RSo9zkafn7dbS4xnhfKX7FK5uvbtj54QS08W_E
NQpHwnIuKwKgUaC3kVn4glSPWdulHu0x6_.9Gdcf8ArTtzaRg6aL_O3beRk_QY5DrWhYLEt3UZGK
eeHSIGHga6l4sUJOc4vRii1dIMYjIOwAlGqKuInrHu0EEt0JRy8ElgZBIGXjj5ZwEh1atLo0bzKB
D86XXRffbP1P4Onfg2A5gURhLfq8o7StCDJWiDtaxIqGLxVqOvjns9KWsKP29VQRrmQteqSqKXTF
eXl6cd7QqvwRowBUDKZ0DQ6vDCRL2S67F8x3wfFimZQSrL92Fx6Zv94O9ku4xHwboaepa4D7qXbG
KjLzirY83dwYX7Sqy1gHe6IXUf.mfbjoybjLzp.1uXLY8dqJ2qqN_EaLQC1xc2tvr4oME0iEn0E0
AVCiIiSmECe2YhZmpws18iW62sKVd7UIsYbwK.77.WmJsyHOsPNztUKF0pQw3Xx5YIey2VgyzbBS
udtoQti96Z_mtIJj7zCT8HPn_fm4eWF.Mtwsp29LMdJkAfN5RE4mmwOtBjjrTPjWjVsbvIxdRZp5
_dYzR_FK_nSSMLLW.I.feJw9OOuuKli4tVo28M1OKjT_7on1dIPHtR16sWVlNj85YD0KJMMy_1C2
5bIb4sjakoOpigndpWfPNOizKF4BSt8TzqamIT9q.jQqQe2qUbt_4bxUG9cl0yZ476pkeyi0QvvV
gbOIycwOvG8t6O6hndKA4ZaqjLqJfEwLI0Dyb.CUe4dqGvhChkZIN8p_pJip0FoOoBvrmUtKSVVV
sV81FlUpyT9DCdLs.vQzjruYbguXW7e2dS3kZcs0NA5Jml5eIlUpBbG5vhNBgMCxtprZSROrKanr
wZ7P0I4oxSiDnmhuS7a2yJmLOdtLgoX4mp0OZdUremn7iyqaskNq7zm8nJC9O1dEkPTFrE6BMnIq
maUMR2wruakdBER5oTQnROvsbnelNzpIhEgcEUDqedMV1AuJlPON0B88cTpeEoAW7kf1kEl9VhDv
LYQOFEcUkki48DMJ6gWsc
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 0e1f2332-e8d8-4a82-8e4a-7f36db08e4be
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Feb 2024 20:04:39 +0000
Received: by hermes--production-gq1-5c57879fdf-7xbd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ae84ef058a9f03c91879aa66a7f75d31;
Wed, 14 Feb 2024 20:04:33 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
Date: Wed, 14 Feb 2024 12:04:22 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
<0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
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: 4TZq0n3C0Gz4pBg
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
[Added at bottom: EDK2 notes referencing the non-ECAM compliant
PCie in the BCM2711.]
On Feb 14, 2024, at 10:23, John Baldwin <jhb@freebsd.org> wrote:
> On 2/14/24 10:16 AM, Mark Millard wrote:
>> Top posting a related but separate item:
>> I looked up some old (2022-Dec-17) lspci -v output from
>> a Linux boot. Note the "Memory at" value 600000000 (in
>> the 35 bit BCM2711 address space) and the "(64-bit,
>> non-prefetchable)" (and "[size=3D4K]").
>> 01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller (rev 01) (prog-if 30 [XHCI])
>> Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller
>> Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
>> Flags: bus master, fast devsel, latency 0, IRQ 51
>> Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K]
>> Capabilities: [80] Power Management version 3
>> Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+
>> Capabilities: [c4] Express Endpoint, MSI 00
>> Capabilities: [100] Advanced Error Reporting
>> Kernel driver in use: xhci_hcd
>> "Memory at 600000000 (64-bit, non-prefetchable)":
>> Violation of a PCIe standard?
>=20
> No, this is a device BAR which can be 64-bit (memory BARs can either
> be 32-bits or 64-bits). However, the "window" in a PCI _bridge_ for
> memory is only defined to be 32-bits. Windows in PCI-PCI bridges
> are a special type of BAR that defines the address ranges that the
> bridge decodes on the parent side and passes down to child devices.
> The prefetchable window in PCI-PCI bridges can optionally be 64-bit.
>=20
> BAR =3D=3D a range of memory or I/O port addresses decoded by a =
device,
> usually mapped to a register bank, but sometimes mapped to internal
> memory (e.g. a framebuffer)
>=20
> Window =3D=3D a range of memory or I/O port addresses decoded by a =
bridge
> for which transactions are passed across the bridge to be handled by
> a child device.
Good to know. Thanks.
FYI:
From: =
https://github.com/tianocore/edk2-non-osi/commit/c1075e9ddd647fa7f7cb17b31=
2f6bf8246952e09
There are these notes that indicate the non-standard ECAM status:
(Other details are just for reference. EDK2 UEFI/ACPI is not
the official usage context.)
QUOTE
The RPi4 has a single nonstandard PCI config region. It is broken into =
two
pieces, the root port config registers and a window to a single device's
config space which can move between devices. However there isn't (yet) =
an
authoritative public document on this since the available BCM2711 =
reference
notes that there is a PCIe root port in the memory map but doesn't =
describe
it.
Considering that it's not ECAM compliant, yet relatively simple, it is
however possible to make use of the newly introduced PCI SMCCC interface
that was added for the RPi4 platform as part of the TF-A 2.6 release.
As a result, we update the RPi4 TF-A to the 2.6 release version, and, =
for
good measure, the RPi3 also, using binaries that were built in an open =
and
verifiable manner through the GitHub Actions build script located at
https://github.com/pftf/pitf.
For more details on the SMCCC interface, see DEN0115 available from:
https://developer.arm.com/documentation/den0115/latest
END QUOTE
Other notes:
I remember, FreeBSD supports the SMCCC interfacing in question. By
contrast, Linux refused to add such support.
The default RPi4B EDK2 configuration avoids exposing the PCIe but
there is an option that uses the SMCCC technique to expose it.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Thu Feb 15 00:35:41 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 4TZx2d23Btz54ych
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 00:36:41 +0000 (UTC)
(envelope-from sjg@juniper.net)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZx2d01JSz4RlX;
Thu, 15 Feb 2024 00:36:40 +0000 (UTC)
(envelope-from sjg@juniper.net)
Authentication-Results: mx1.freebsd.org;
none
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1])
by mx0b-00273201.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41EJAStk023133;
Wed, 14 Feb 2024 16:36:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=
to:cc:subject:in-reply-to:references:from:mime-version
:content-type:content-transfer-encoding:date:message-id; s=
PPS1017; bh=SM7SeobT5uFXM8ucE5QVgV49aaWiLsUesjTVO8txbVQ=; b=mIT1
HJNLSVQZupGhlI3cV5fvj9juIN4VjB5gSp2YLf9o0+A01EU3rFKS24miFGdubPIg
Mx+kVtKcb0KF5ujUJE+SjmVtskrJ92sGqP5Id3tHWrQ+TvwVZtj1uYHNuC8WzSqD
MZInZEJDt0aHJNZq/Z7NY5OB4XOWyFVRXcu2CdxKZ7rnxdBQaFA/anFAkH00VQQR
SHft4YNHYdEb0/QQFbOI7YNJCtFyeCdZBBj8rQO5Ni8NMkueuJVjEb7If5XXJ+VC
s2PGGRf/PH5vS1khK0imyKkIZZ9Z9qDYUlr0WGJqDc4MxLMahwsMgxmVrttHDTi3
SQXsZQxNQCWNfKybOQ==
Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazlp17010002.outbound.protection.outlook.com [40.93.20.2])
by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3w67xgsy89-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Wed, 14 Feb 2024 16:36:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=iqYkaJ/1rupriHDBEG3ESercDsQxvxVh4xJnofFFq0jLibRIcDMSreKyy7BZlmAhizZt3Eiey25UD5976xZwjU/ZJ9Wb/CmLBG1O/gvXV26UyBnRP36MmwOQdyDRrPpYrY6xbmwu7/xeqKQ0FhCnGvS4NlQZeJP47jHPvwxiKAhc8PVvQATxE8ICr84pEIjOIVwZ6KD/OabCACv+lQcDhff8ixlpJGXtFQtGG43d3IiEwfM9DUTdre7ydQ35TpwzJtrSsfPyU6UCp8mnMcfMYi26zHrldZSXBsoADda9ZdSyyh+GOJLrreDIneKNPI93UoRbiKm34GnxUFnrV8alWA==
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=SM7SeobT5uFXM8ucE5QVgV49aaWiLsUesjTVO8txbVQ=;
b=lKgYTeutod43FhHqzf23SQmo4WziJO69OL6wW9MYzCWurE/mSF4tueI47wAOfygbGl8AwVljaBBKr/Hom7TuNXtwYb0pYc9143jPeeTsuzpN2suhALpAGPhDxqG6G44Hpv1B/o7Vwn7UTFCScMsdbd3OijV9Q57K2fOkjQqeHLTnBjSCiN7/ZQgqOa1GicQ9KJ5Ksd99asRVTpoH0Q0Hie8KeQQtYv8IoOAmVPv+ZZ+PQE52uNDX6JzhX6bCzrgIuuPMl80hWzWs9TjDd8BucSyGoLxLpxsZfFe5s9oef02ROwF4KF2TUpRUGx++Hnewal0Dw6oSZAuFMkdwX2/N/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
is 66.129.242.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net;
dmarc=fail (p=reject sp=reject pct=100) action=oreject
header.from=juniper.net; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=SM7SeobT5uFXM8ucE5QVgV49aaWiLsUesjTVO8txbVQ=;
b=OXBXyUuqAyJqrq2f1LlmcrPQ1xGmHRHsgdOG0DaU47QKpUoFLM4nzvAVbj75rPze7UwNJFOlUfnbHdFp3uF3YtOZoYYi41OJm1aQjeLXRlj6/IrbCC7inIrDc8fPBGIBMZO540Z2mk+yX2yLs2NI2IKrvW6Hr9kau434P90kkgw=
Received: from BN0PR02CA0022.namprd02.prod.outlook.com (2603:10b6:408:e4::27)
by BLAPR05MB7490.namprd05.prod.outlook.com (2603:10b6:208:296::20) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.26; Thu, 15 Feb
2024 00:36:35 +0000
Received: from BN8NAM12FT104.eop-nam12.prod.protection.outlook.com
(2603:10b6:408:e4:cafe::e) by BN0PR02CA0022.outlook.office365.com
(2603:10b6:408:e4::27) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.26 via Frontend
Transport; Thu, 15 Feb 2024 00:36:35 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
66.129.242.15) smtp.mailfrom=juniper.net; dkim=none (message not signed)
header.d=none;dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
juniper.net discourages use of 66.129.242.15 as permitted sender)
Received: from p-exchfe-eqx-02.jnpr.net (66.129.242.15) by
BN8NAM12FT104.mail.protection.outlook.com (10.13.182.180) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.7316.11 via Frontend Transport; Thu, 15 Feb 2024 00:36:35 +0000
Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by
p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.39; Wed, 14 Feb 2024 18:36:35 -0600
Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by
p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.39; Wed, 14 Feb 2024 18:36:34 -0600
Received: from p-mailhub01.juniper.net (10.104.20.6) by
p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.39 via Frontend Transport; Wed, 14 Feb 2024 18:36:34 -0600
Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201])
by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 41F0aY5f018285;
Wed, 14 Feb 2024 16:36:34 -0800
(envelope-from sjg@juniper.net)
Received: by kaos.jnpr.net (Postfix, from userid 1377)
id F1AFB801ED; Wed, 14 Feb 2024 16:35:41 -0800 (PST)
Received: from kaos.jnpr.net (localhost [127.0.0.1])
by kaos.jnpr.net (Postfix) with ESMTP id EFF20804A0;
Wed, 14 Feb 2024 16:35:41 -0800 (PST)
To: Nuno Teixeira <eduardo@freebsd.org>
CC: void <void@f-m.fm>, <freebsd-current@freebsd.org>, <sjg@juniper.net>
Subject: Re: meta mode
In-Reply-To: <CAFDf7U+jmc9oEYTDSN83AFuTA1a-W6Z_RSqPHG=0nQDFP8W44w@mail.gmail.com>
References: <8c42cc06-d3de-432e-82ab-7fe040197223@app.fastmail.com> <71141.1706406125@kaos.jnpr.net> <CAFDf7U+jmc9oEYTDSN83AFuTA1a-W6Z_RSqPHG=0nQDFP8W44w@mail.gmail.com>
Comments: In-reply-to: Nuno Teixeira <eduardo@freebsd.org>
message dated "Wed, 14 Feb 2024 11:46:56 +0000."
From: "Simon J. Gerraty" <sjg@juniper.net>
X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 29.1
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Feb 2024 16:35:41 -0800
Message-ID: <24.1707957341@kaos.jnpr.net>
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN8NAM12FT104:EE_|BLAPR05MB7490:EE_
X-MS-Office365-Filtering-Correlation-Id: 20bc0e36-bbd1-4c08-b67b-08dc2dbe2a69
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
lijNCparSueLqSJPZDx0U+ayHnfGDdx31ejJTi2wlFAZB2j66LgDSoa22U5cQ4wwv1kp8BGaQahbOlrDgdwU+ey4o+OS+lGfFPzQ/ZUwwJE1sOdLcSDo7fbt7CCrcQlxqahdOg2Q2N2AqJ33aYgTH8V+/FNcioz63TicPv4Cdh29PFuzonh8oL+HTp8naBeG8ijQbXQCJeiBU+lPD1sIdpB+bZKPY0DxB+stVARBkBeXkKcc4oUy/sX1qJ0Cd7uTdT618lgLlDU/KEh/eZDUuHeePNcd9x3G17KA9R3MYGatLhFyk7JCNW3MUGUrTvIXc25kwFQCbPXBQiQvBdjadTzaLYin4N4uB7D8A9qNY1f0RV6S977V0zABoCo3YIngf9uZEByY5QxVDDvt54sDZ+H78YYmvn8sGaS6uj+6twz2/0BVejJtr5h7wXPe3PlaVtufPzFtjrxSpvwvN2dzhbrvzKZPjVsbzJ3a/recT0UWZPi50ljflNP2U9QcrBH2z5nqgob1hPos9Ag369FbYKvS2HvBmf9he/lxUifWlEsUC4qLqjBKbaiVjp6DdqA+J0L8Px5wISVc3r302tVlRKVW/+zjiOpVlxA7J7T7XGdNyAh6ThHHgq1zmzkE/GFt+ipWvKgbrKWakbzKTF7ZeuGe8MdE0oILGrNRmZVoHfE=
X-Forefront-Antispam-Report:
CIP:66.129.242.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(136003)(346002)(396003)(376002)(39860400002)(230922051799003)(1800799012)(451199024)(186009)(64100799003)(36860700004)(82310400011)(40470700004)(46966006)(316002)(6916009)(54906003)(70206006)(70586007)(41300700001)(55016003)(2906002)(5660300002)(8676002)(7116003)(3480700007)(4326008)(86362001)(8936002)(478600001)(9686003)(26005)(7696005)(107886003)(7126003)(82740400003)(336012)(6266002)(83380400001)(356005)(81166007);DIR:OUT;SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2024 00:36:35.6968
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 20bc0e36-bbd1-4c08-b67b-08dc2dbe2a69
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.15];Helo=[p-exchfe-eqx-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource:
BN8NAM12FT104.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7490
X-Proofpoint-ORIG-GUID: I_CEr7aBqcXGVANlVeXi1MdQdT766NxO
X-Proofpoint-GUID: I_CEr7aBqcXGVANlVeXi1MdQdT766NxO
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
definitions=2024-02-14_16,2024-02-14_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0
adultscore=0 mlxlogscore=630 malwarescore=0 impostorscore=0
lowpriorityscore=0 priorityscore=1501 spamscore=0 clxscore=1011 mlxscore=0
phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.19.0-2401310000 definitions=main-2402150002
X-Spamd-Result: default: False [-4.00 / 15.00];
REPLY(-4.00)[];
ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]
X-Rspamd-Queue-Id: 4TZx2d01JSz4RlX
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
> Can we say that META is for speeding consecutives builds tracking
> current/stable and META + DIRDEPS for developing/testing specific
> parts of base code with speed + debug in mind?
The key focus of META_MODE is more reliable incremental builds, ensuring
targets are updated when anything that contributed is updated.
That deep introspection can go too far so there are mechanisms to
exclude certain paths from consideration.
That allows for some optimizations, eg. you don't need to make
targets out-of-date just because any makefile changed for example.
META_MODE helps ensure what needs to be re-built is, and can avoid
rebuilding things that do not need to be.
DIRDEPS_BUILD is a different beast - its goal is to avoid tree walks,
to greatly simplify the build in general - a top-level build works
exactly the same as a build started from any random location in the
tree, and in each case only the directories needed to satisfy that
initial target will be visited, in the correct order allowing full
advantage of large numbers of cpus.
We can leverage META_MODE to automatically update the tree DIRDEPS (kept
in Makefile.depend files) that make the DIRDEPS_BUILD work.
If the pkg-base work had resulted in a src directory per package, it
would be trivial to convert the build to using DIRDEPS_BUILD.
Absent that, it is not really possible.
When we build FreeBSD for our internal projects we build a number of
packages each with its own directory and hence Makefile.depend
and thus we can use DIRDEPS_BUILD to optimize our builds.
--sjg
> Simon J. Gerraty <sjg@juniper.net> escreveu (domingo, 28/01/2024 =C3=A0(s=
) 01:43):
> >
> > > I use meta-mode in /etc/src-env.conf so that if (for example) a small
> > > change in the kernel config is made, the machine doesn't take hours
> > > recompiling.
> >
> > > But, from time to time, one might be required to make
> > > cleanworld && make cleandir (to be sure) && make clean (to be *really=
* sure)
> >
> > Almost never (as Warner said).
> > I have trees that go for years without ever being cleaned.
> > Unless I'm collecting timing data for clean tree builds.
> >
> > If you use DIRDEPS_BUILD as well as META_MODE, there can be cases where
> > you need the stage tree cleaned (staging is like auto-install to
> > DESTDIR). The most common case is when a library has switched from
> > staging its headers from $STAGE_ROOT/$MACHINE/usr/include to
> > $STAGE_ROOT/common/usr/include (so they only get staged once), if you
> > don't clean out $STAGE_ROOT/$MACHINE/usr/include, builds will continue =
to
> > find headers there that should be found in
> > $STAGE_ROOT/common/usr/include and thus revert Makefile.depend changes.
> > We added a mechanism to allow triggering auto-clean of stage tree when =
such
> > changes are made.
> >
> > --sjg
> >
>=20
>=20
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
From nobody Thu Feb 15 00:50:46 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZxMh3520z551QZ;
Thu, 15 Feb 2024 00:51:28 +0000 (UTC)
(envelope-from marietto2008@gmail.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
(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 4TZxMg4JNFz4VXd;
Thu, 15 Feb 2024 00:51:27 +0000 (UTC)
(envelope-from marietto2008@gmail.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=gmail.com header.s=20230601 header.b=ext1PDgp;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=marietto2008@gmail.com
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-55f50cf2021so440017a12.1;
Wed, 14 Feb 2024 16:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1707958283; x=1708563083; darn=freebsd.org;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=QBcRte46KoGQQwVd3ukluhewgGTVRssG7yLLgW/rGLg=;
b=ext1PDgp4TiAJhh4r6TA9ZXgIznf2TDEoqEK8R+XKgHrkYjlMqLS2l35vCveHtzMn2
88yPdmRpNWlXZKWfZK43niwnfb7jXZETMmXlMhgCe+G/Vtk/V6WwHF0xPNYQFmEC+CAK
Rbyv1aCdcRUYrBmI+NYjiYJGxKg3sL7CYwTxegch2RXVjyZfco1ehcbtnj4RLOZSSf1t
w1rQn7DT9NM8WuEtEWOdRYtN2asXdpEgOKVJterq7IXNTWoJovbbBZ6KlE1l9u0HvnPH
LGTDiCYQ+0TftxgoKjLvVBU5OWEJM5QBe43YbLlVb6MFoOUo1JiL/HrimcXK4gDTaobB
22+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707958283; x=1708563083;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=QBcRte46KoGQQwVd3ukluhewgGTVRssG7yLLgW/rGLg=;
b=WS2pvddmEB/b90SQeUG+vAkMGqiCKOQd/hFty6/PAfZf3ytnDf7BkOLNRDjpAkeikm
sdSOclv00jpwPy8OLc58TG7xquLFIb/SNQc5eqpPm4lWNj0clkKLYyq0OuFNs8EpbvWX
UojBaVgZ6PKdz6ybd3tQXrIBXLfQgyqw1OM8vGf+aVUUZ0eNsOa99/B6yM8+l7m88qG+
cIeGO37ZdgQ7JMVe8RsS1G3fnfFBmXo4MZfkM41UFxPV7Qb0CCgsj4PJMkpdEKAwi3Yt
Dq865Aa1YxS0nUHFPJ03wxwsqhXl8rVFIp2/RBv1mWgQreKFWXwd+tNi3q0pMzt+OYWo
VHmw==
X-Forwarded-Encrypted: i=1; AJvYcCXH9W4HGYu9gFvWGygVape5GoGyufn4WYmgeEEzanOK9pi2EQ7wS3hZr7A67YZ4imR9kfBI8usEBgxBKjuUk+QvCVS60omQ/GcovGydqPw6YqDFlhzEHJwDfn0E4KtxNB9xDouqtfdaZ0T+gcUZELfK51xSI3SYjKT5eHwsaKStKfAdbDRQkEg=
X-Gm-Message-State: AOJu0YwENEJiEeG2DA0+eRpRLzGbDKhMn1zMOEshiAUCCR9r4APyI1PO
x/Zm8hJw7uaelmdUfW/irM5Kam0lqwDn1BfR220VILS85pQliPup21ZX5sIlA+RJEAdHY/syjVV
QoZzBfwJBk+NpUz8fjdPkkpC92pYMaGNTI8M=
X-Google-Smtp-Source: AGHT+IGegySJdSfaQcO/IP17JBuRJiTnmxtDg3qr6CmOWLAP6V/et/F8fzzRLMKEF+bXuePZ3XnENeyE5KbAmBTgRlg=
X-Received: by 2002:a17:906:b0d9:b0:a38:63d4:2273 with SMTP id
bk25-20020a170906b0d900b00a3863d42273mr117728ejb.35.1707958282885; Wed, 14
Feb 2024 16:51:22 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Mario Marietto <marietto2008@gmail.com>
Date: Thu, 15 Feb 2024 01:50:46 +0100
Message-ID: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
Subject: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
not found -- snapshot corrupt.
To: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>,
FreeBSD Mailing List <freebsd-questions@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>
Content-Type: multipart/alternative; boundary="000000000000be1e9f0611610622"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.98 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.98)[-0.984];
DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
MIME_GOOD(-0.10)[multipart/alternative,text/plain];
MIME_TRACE(0.00)[0:+,1:+,2:~];
RCVD_COUNT_ONE(0.00)[1];
MISSING_XM_UA(0.00)[];
FREEMAIL_FROM(0.00)[gmail.com];
FREEMAIL_ENVFROM(0.00)[gmail.com];
ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from];
ARC_NA(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
RCVD_TLS_LAST(0.00)[];
TO_DN_ALL(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
MID_RHS_MATCH_FROMTLD(0.00)[];
FROM_HAS_DN(0.00)[];
MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org,freebsd-current@freebsd.org];
RCPT_COUNT_THREE(0.00)[4];
DKIM_TRACE(0.00)[gmail.com:+]
X-Rspamd-Queue-Id: 4TZxMg4JNFz4VXd
--000000000000be1e9f0611610622
Content-Type: text/plain; charset="UTF-8"
Hello.
After a lot of work I've been able to install FreeBSD 12.04 for armv7 on my
ARM Chromebook. Now I would like to install some ports. This is what
happens when I try to get a fresh ports tree :
marietto@freebsd:/usr # sudo portsnap fetch extract
......
/usr/ports/databases/py-sqlalchemy10/
/usr/ports/databases/py-sqlalchemy11/
/usr/ports/databases/py-sqlalchemy12/
/usr/ports/databases/py-sqlalchemy13/
/usr/ports/databases/py-sqlalchemy14/
/usr/ports/databases/py-sqlalchemy20/
/usr/ports/databases/py-sqlcipher3/
files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
not found -- snapshot corrupt.
I repeated the "portsnap fetch extract" command,but I always get the same
error.
--
Mario.
--000000000000be1e9f0611610622
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">Hello.<br>
<br>
After a lot of work I've been able to install FreeBSD 12.04 for armv7 on
my ARM Chromebook. Now I would like to install some ports. This is what
happens when I try to get a fresh ports tree :<br>
<br>
<div class="gmail-bbCodeBlock gmail-bbCodeBlock--screenLimited gmail-bbCodeBlock--code">
<div class="gmail-bbCodeBlock-title"></div>
<div class="gmail-bbCodeBlock-content" dir="ltr">
<pre class="gmail-bbCodeCode" dir="ltr"><code>marietto@freebsd:/usr # sudo portsnap fetch extract<br>
......
/usr/ports/databases/py-sqlalchemy10/
/usr/ports/databases/py-sqlalchemy11/
/usr/ports/databases/py-sqlalchemy12/
/usr/ports/databases/py-sqlalchemy13/
/usr/ports/databases/py-sqlalchemy14/
/usr/ports/databases/py-sqlalchemy20/
/usr/ports/databases/py-sqlcipher3/
files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt.</code></pre>
</div>
</div><br>
I repeated the "portsnap fetch extract" command,but I always get the same error.<br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Mario.<br></div></div>
--000000000000be1e9f0611610622--
From nobody Thu Feb 15 02:19:04 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 4TZzK56FVmz59hS9
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 02:19:21 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZzK45Ncrz4kRV
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 02:19:20 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=rwBAf1TO;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707963557; bh=b+qjQjzkceIwmpemBK9JYxEdx05pf6UN1WTcBfmouEk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rwBAf1TOpKIXFoB/T8Y4FHom0ahJ3KNCGtyKgJ30s+HnmMF08tAds93qRMVy++brQeZNrCmbOXayk4grYIeFBS28vmU+/BpSnYmUbESuCnSRxT86sw0isqG1aeU04D2ITFdHDKWJNiIM0L84hC8UzZ9x3HTplGt19Lk9qUpLhmc8my/gETuLgcTfM7W19ka44/VqeBLy1MwRp7aMGCqiHf3PJNMlFAcx+S4c1YrELJfZCPBVmsUDCilNY538Gd7lMfS29xe2nInezgaKMNVKvcGS9SzsK6M1DtAtWsfRCH3m+tS+rEb/FBbWRa6wlqoLu0Dm1zzHodmr9CkeWlbrww==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707963557; bh=CK6VPUa2V5nnBHpjN/a6HvQ9CWgYzhWJlsjejLixHo1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ei10ioVCBJ8xG/iw1ht+Ki1SaPY0naCXJnBm1N1i4dl60MWwLxGW56VqUfSFA5pmU9oBwbNY3eQDe+uq24cWjnKBwm9/dUbNl7qe+b8KTDcdNQLpBp1YkPU4CD4deIxjl6Zb6gfEJoXsg0AdqJtM9fM8EUpuFCoMf/wNSsELpst1jzfA73cqDckXmnRwyv5nbWdplEgY/bmR9YWMGjKRL0IxxENpe6fHMjBHUAykrBchsJbJfYRoO6v4B5kwZAqjJS77Tr4JgApfis8Le7I37XfrgzIUXLP/C2LUEX9oYWkXMMvaTcQupF3C+uG99XW3P8MOuOYGBbxVLVp5ah7pXA==
X-YMail-OSG: eO6ZTxsVM1lFD.S4ugIkVlxRtBpOuNdwEoIUuUQ1gx7qiZAybZYfZ5A6Q4uS5dQ
vutcrPdRy2.PAM9zuZKSpNToaDltLu8ixgcUXo8OqsNKOvgDeqlB8ZYip7HUzZWZJ3N0YA1jYQW7
YEfm4geNduxEl8jzBHqf4ysgbvbYh6hWxMAY9YBYxbNnG00RSk5es8SJJJpjl0DvBeAEWS1hrBd9
DshLdZq5uQJrDSs5vSweDCSt2FcSEXb5jHCATxI6ojyzPZaKEIqwWr7HiBPpD29mghudAPvsiB6a
dvSa9wEKLYFbTYT4Zb5XisFslN_XincjERU.S_SKpCaqP9KOKZO2BzETseZnG9qv_Qi5B1ToalhE
yPCopH48pyGY1NH8cusCBcr5EPuu4Ob.rYg5wbS80p_7eYRm1b_H1sG5VI859jj.d3m.KSxUygX0
05pZV1xx0OWwTvNoRdo2vFLxpIquH.yZQEJr0pnOGnErH.OtmrsZCaPJNvaN9sO.3RvE28p4RUFI
V.OMkNM6nWJQj3Jhj9emhHuo6iiqhAcRO2CMWY46LHc0FGYZcpJICW6U_MDkaH3f3cRYDTA4v17D
Bkw42f9_NYTjUnzWOiB71PPKfDdz.4B1fItTws7k16BSj4WM3akban4AGUHew3IQs49Dftvw83oB
h7ZeaJc9x_71PSl8LCqVYRw64BLppCooyREbMP2wLYD4X5LcL9RvyhZY5TAR2yaFh5N7QefGxRET
RLcuMXZJJgkEj8cbcsgnzBQlQ5Xav2dRRKj5WniufXGhJz5s922u5WXVYrMyRDeHq2xfiq42SSue
33WN7ZTVCBuoOJwIiqUthC_5UULxIyHdDUY7IpSuBiKGbFeW2PfyAT29UDskQCj8FMsa01oOBC67
lUNZtm9fnbVLCldFtKHJj3J6p.ZpI6zeiB12cdGEgDevZrborFMNRn7Rz_IuiBNTL7MQDB7uyUt3
hCOxIzUK2eSboqnEM3IaUmM9BZHXl19dGXTN46EDDCbhpJgYYY8D0Cvi_WJ_BK6nx_ivLMfaN1Iq
Rb86wQW.TZbp1Tn.RuMh.FKVxO._72mgPb_Xes6INFjAj04CJ8LkoKzJeYNjbFL0sm0SyiYCK.Vc
OX7RmPdl9pPfpXTQGHg7bS7c2ErXF42RuNEYqVHmZxns1Ete4d9cimH2Kmb7n5ou4LJDAYlaBPR2
E0nHme07ROchQ2U1ytwCOk_Q0nhWMefInRfQZA14ze2g1IsCla6UhQKlSer_U8L3YFF1tzTMwj0b
H31ZL6eNpFmlwFOM46ENiBiQE2VQrI6bH2TAzDi1QGD94u_ykFMBUEhLcPWm0PYRC_HjKSEByTYZ
jbKvjPahhnfy2V1h9BB5Bh3x7VSXxGVd9z8aioS8m8RMm2vMTCDxwMI6fqbA_.NCwzngt7mUjaj4
jHws_RUJzVBjXJtNRj9bUqEzyImiNArO0tD6PmwfWQm9W9ZdETvgibbqSIp5G4hEGIMNqpR8UKIz
MZ8.oFdpXJZzm7OMOtCyW1sp4PAp1OaSbknFy7l7VsqsXXGDgEzqYEhxIWkht_kYEK.vs1DaOCBU
Xhp59ZbqV13UkW5Ca2DLB.8gPLi.pKjUuLXQ4BM88_DSfxVJGq0azxLyM3pp.8OI0izHeS5CFeyr
7ReXUMsxUd2La_qORdQWF7hm5_.jb5rG.wAaO2AzDOPG6CslvmD6HXw6eLCTB9LBU39ESH540UPL
eX53q39PEW3wtNGCF9rOlHgmvGTdy9P9vPhGNFd___tGyKDZjhNpcsS03H2Y._t_n4Ju1U7bE5Tf
VuhrCgJBY_HpNvC6wHXRnG3XftqwE_dbfRov4WlTiF7q4Lv27NX5Os2e.Y9r.V8goPHQbxniDRUy
gL__mOBDU9E7b1MccZdf1BKVbZ107riZsCkeJMJFp3EiY6sp4j1dEH08YdwHRnVTZ0fqwst_nqFk
6u8Vaj27FG9RTEo69QmQ1letX7pe_.5OaNK1kZ7DQj61973gOUqxPUH_xLd6.GC51c2x.r403fHs
Zod3BVNFR6w_8W3TNk59VV1_f_NX7D.ODtrZt44I71OjjuV.lSNsMrBj..3Z_N_Phf0zwEGAF8AG
vbPNr31wq.dCj5kPrJftQNHrY1fXKlV8CbavrxT.JWkff0m5loYGdjnCZcUMkRmjL0o3AgRU3fqF
0DR04JnZEkzqcQcx.FORSiS7PW0zmRv2dZf7E70b_SwbGBPTfx34.T3zGZCJWqBaz_zuBFiyH4jb
9KuJnTrTtxXB6UsaWyBcV9hCgyIT9oOsQXL3lCNbx25fCn20HXRfzR_cf3qt74Zv5GtDkPW8U
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: e09eabad-ee1b-443b-9425-a66e837d3d24
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Feb 2024 02:19:17 +0000
Received: by hermes--production-gq1-5c57879fdf-4h5cs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6c24a661158ac8166ee0dff3c467d587;
Thu, 15 Feb 2024 02:19:15 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic [now
fixed]
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
Date: Wed, 14 Feb 2024 18:19:04 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
<0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
<072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
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.31:from];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4TZzK45Ncrz4kRV
Your changes have the RPi4B that previously got the
panic to boot all the way instead. Details:
I have updated my pkg base environment to have the
downloaded kernels (and kernel source) with your
changes and have booted with each of:
/boot/kernel/kernel
/boot/kernel.GENERIC-NODEBUG/kernel
For reference:
# uname -apKU
FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT =
main-n268300-d79b6b8ec267 GENERIC-NODEBUG arm64 aarch64 1500014 1500012
Thanks for the fix.
Now I'll update the rest of pkg base materials.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Thu Feb 15 02:23: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 4TZzQc1yKxz59j35
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 02:24:08 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TZzQb4jdXz4mTW
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 02:24:07 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-55f0b2c79cdso611254a12.3
for <freebsd-current@freebsd.org>; Wed, 14 Feb 2024 18:24:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1707963844; x=1708568644; 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=3vqM5+iVuqKR9W8y85S9lq6wDNYJwsWHb0tSin9+8jA=;
b=lF6gRuvNySTwxgYo2GtwPUhzF6l9jdkyJMpxjdqm2yieJ7ScRVpjG6fq/0x0/0mS32
1bFseaSUprplpbJkdpDnkZ6sPnnLC1vl7JLntblhIin3tcmBi/XyKGzLR3r+VNbRNgQQ
vjjavizl0wCfeU9Q3Vz6qPCh2L1zt8VZ87TqrwBS9224HPssVEJd59Vze8ENpabdlYfg
qDOjTSZfXC8HAc5jeeosRPnZxvOCojUCHBXUCAQmHfNP0wtbRxOPHdIw3TGQkTd1LsC1
QZaDfFezXkq7XOAC14FQZr3uwa70h0rM6dzo5V6AOtwc4Es5O2ZeW+GVM6xAgO0fnrxY
swnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1707963844; x=1708568644;
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=3vqM5+iVuqKR9W8y85S9lq6wDNYJwsWHb0tSin9+8jA=;
b=n09SkogJdNri33dHGsDD62wU9BxFRFkEzTSxzuWrqO1UOUWQtmcz400YyMwFJl2qhl
tethzZWm73qYSsDer0Zk84MAjciT+62AjycokylQezq3sSFuUX26EQMfy7xe+PHYaWnP
eXn1n2ee3sJqDGLDpddsPbWdbpHvEeSJKZ2HmaVo4Wl8iuSBO77KzhX1mXD2xFSJz9bG
H98yq7j2CSRo+cFL/8jUhfQtYx3ppidZwl7hRDkh+OzrKIXxftdZNdEBfdH4iEAJojq9
7PdWsxQWSz85Na42fB+OeLP8TDjE7I0AuUTPeD3hlMJvyTskW+zJpEL3YsOGIQpU1jQa
iUqA==
X-Forwarded-Encrypted: i=1; AJvYcCUrbdOkBzZRGUNppM4GRyPO+YNTQhNNXZNxYq/tlPe0rgj3NV8NBIPeFTFgw7sO7wdiEgvuVMX2/8SKvmwAU9LoUrt6cRXbovvm9R0=
X-Gm-Message-State: AOJu0YyTupllc8Y70VHrHm/tC4x3iE6OAV5Tp9RYML0epA7TZqgcI+ga
5ke+cMM8+yTlDwATrqbh984NHzCIxO5Sx/hkSh1VC90Wudd4+OrQXTFGHUm5D3NT9jj19FUj8U4
Om1yokIJkpF2BNuAg5IitTcqFURRlzVZNeeqyMw==
X-Google-Smtp-Source: AGHT+IGYARZBQp+Sdj6ZOLXG5q5fIrfvnssdZkPdgmQyi71+RQbaZklybelZxBSBPEgScXgfqfgitzddW/qZFkl6ifw=
X-Received: by 2002:aa7:d7d1:0:b0:560:64e2:98a5 with SMTP id
e17-20020aa7d7d1000000b0056064e298a5mr276205eds.21.1707963844349; Wed, 14 Feb
2024 18:24:04 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
In-Reply-To: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Wed, 14 Feb 2024 19:23:52 -0700
Message-ID: <CANCZdfr3pOgs8CUFwheG1JUphXr4huGwTXHudQLapkw-jhmT7Q@mail.gmail.com>
Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
not found -- snapshot corrupt.
To: Mario Marietto <marietto2008@gmail.com>
Cc: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>,
FreeBSD Mailing List <freebsd-questions@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>
Content-Type: multipart/alternative; boundary="0000000000003b6397061162521f"
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: 4TZzQb4jdXz4mTW
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
--0000000000003b6397061162521f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You may need to grab the repo. You may have to back up to December's ports
tree...
Warner
On Wed, Feb 14, 2024, 5:51=E2=80=AFPM Mario Marietto <marietto2008@gmail.co=
m> wrote:
> Hello.
>
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on
> my ARM Chromebook. Now I would like to install some ports. This is what
> happens when I try to get a fresh ports tree :
>
> marietto@freebsd:/usr # sudo portsnap fetch extract
>
> .....
> /usr/ports/databases/py-sqlalchemy10/
> /usr/ports/databases/py-sqlalchemy11/
> /usr/ports/databases/py-sqlalchemy12/
> /usr/ports/databases/py-sqlalchemy13/
> /usr/ports/databases/py-sqlalchemy14/
> /usr/ports/databases/py-sqlalchemy20/
> /usr/ports/databases/py-sqlcipher3/
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz=
not found -- snapshot corrupt.
>
>
> I repeated the "portsnap fetch extract" command,but I always get the same
> error.
>
> --
> Mario.
>
--0000000000003b6397061162521f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">You may need to grab the repo. You may have to back up to=
December's ports tree...=C2=A0<div dir=3D"auto"><br></div><div dir=3D"=
auto">Warner=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Wed, Feb 14, 2024, 5:51=E2=80=AFPM Mario Mariett=
o <<a href=3D"mailto:marietto2008@gmail.com">marietto2008@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello.<=
br>
<br>
After a lot of work I've been able to install FreeBSD 12.04 for armv7 o=
n
my ARM Chromebook. Now I would like to install some ports. This is what
happens when I try to get a fresh ports tree :<br>
<br>
=09
=09
<div>
<div></div>
<div dir=3D"ltr">
<pre dir=3D"ltr"><code>marietto@freebsd:/usr # sudo portsnap fetch extrac=
t<br>
.....
/usr/ports/databases/py-sqlalchemy10/
/usr/ports/databases/py-sqlalchemy11/
/usr/ports/databases/py-sqlalchemy12/
/usr/ports/databases/py-sqlalchemy13/
/usr/ports/databases/py-sqlalchemy14/
/usr/ports/databases/py-sqlalchemy20/
/usr/ports/databases/py-sqlcipher3/
files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz n=
ot found -- snapshot corrupt.</code></pre>
</div>
</div><br>
I repeated the "portsnap fetch extract" command,but I always get =
the same error.<br clear=3D"all"><br><span class=3D"gmail_signature_prefix"=
>-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D=
"gmail_signature">Mario.<br></div></div>
</blockquote></div>
--0000000000003b6397061162521f--
From nobody Thu Feb 15 03:15:43 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 4Tb0ZS6NV9z59r29
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 03:16:00 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4Tb0ZR4L9lz4vsJ
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 03:15:59 +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=1707966956; bh=dnrTAgWr5MF+1i28AxpapS8xiHiCfQqEb/oNihHf1I0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CJiDYcVJbGaYGFV7FOwYmRBDj6bvyfSN2Sv8om0ZQapf6JYzVIq/gyKesVwnPCUHv/5LXpfNxcBU3Nm/mfp3gvTb3RzD2aXH9gF7oRJhSvFHu06LdfJgN/rm5NkKqCMCwz7IW1WmmoxNpmOSDce3ykCa4jzypSUUtoTqQ6ZiBOmRC/4AP+ar3w/Yk1oDPOyueO5RulAc/fX5PUgMToN/4xllpzx6jY/tR9ICWqtB4RGCRz2I778XEqUEOR7TQUEC5lHWv7uk6qBlh7FoT27DFFvGOKN4SCvpYUqgVhDdiTTEzFOO3qDKXwfEqIrD24DJAmchR3FIUe7FXHq4GZfE7Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707966956; bh=mVFwqiIzo8xoApvcdYqXQ9Wg+zQjvg9FrAwkNKDGp0f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U9PXdlS5D+nrWOVzsfmACUvB674bVNWhB95tkBwHlf/Qy94ypwvxBD+3X5zBXWr8rHM8vW2HEihsxuQ12NWDnpt/3htDkHJ+aC8BJSQRRGfNFMnDabs5y37Y3rtpLszkYxJF4YdyofK2hbyf8SrgAH2Nu2zFkwJsZMkz7Is9sHJ5S831Lc+E6M4G7gfKKOToxkSj2g9dG+hriY94rXnzSFiwjj6tm7O3PqV/y5Xr9RtY77npgyYqDTfhlEP+lOcg0UOmXSrQC045uLX3Ja8N6viPk6mEPb/GtVsoP4pRuh+3K3t6zwZlY0YfPHnrzPqtFL6nFRAKFxSSAlL58fDItA==
X-YMail-OSG: VjSLtBwVM1nbvJ_nXWby1UTb08K36h2wdBD1L0e8ovsIF6SZozu6nzwlT0ow0J8
t0jP9KjqffAy5n0N3.TX1fdWGDwvAt2vwAXSFqSPGMl1QuN2LTJ0sjoF7IdtBWHC0Hl8Y699k5yp
BvuZWmTtXMcxauWlM7HJ2dH0FSLe2oUO4vtE3g6VoMlIdPcmsOy72SIz8JqQjd6cadML3IpKihlO
f5yGi6OY7ew19PUVjmIK8wKENMaviZKoln3YXkcGJr.s9EZJo2wSLO4G8JKYSJj70nLv3w8R2OJ9
erlUQ49ZtYTWh2uJg6gdbeMB.59bwa.xxmO7HgsbRJBoL62oIq5fO1L6032m6j_aP9bhPka9TYck
NqI3B.gAXvfMHqYZz_5OvGvRb0CAnCkHzFaeJU0WzxF3raix5n16ro2fdgjTDK7aEEyzg2yO4Yg3
Snv2nl8PVGGdMXlPN7sR4zcNDCIL35UW8repwRLyrB0xZqCIjz4tu_Zmh6aRhuaHGOWpGaLyfBOh
1yT2E73GaztBtXppRulLo_96KkDNp6qyw3NPludr5nle.4W8k2Ptyif6JLxRc7SS.07kBqsqWAXk
7t4CMro_Qnn4tTNjEmEiGLB7FfY9U9t2qMCO7ijmEdelLOO3.nlq33VH2aah1DBc2AqDn7n_8FK7
TLx6qtSdAq4xWl.p0xSNH.n4fCNI.KKfS6fTUDpHpVTV6d85fH7h_V1UPLIgl.NjQv8czfNF0HFF
BcCiUv_1l6fqWji1mUd28XDZkNL8MFeXWGy3tqEASays4DYm4Utwlfean7P23SzYwV_NWNK4gcix
wHbxJdqE82gsn75mrWiCJvT29Ybrheb8Zmd_FBdGkEe.XMBr2IxI0E8tl2981VYZ1dai3ZgioqDo
iQHaU649AQvB1i_.XJztzbjZz2oxDdsePN4Wegit41Um4EWI.1ztJkHuiPEj558u9qyo_WpZOr9i
ZB2T0hkjN37Hl_BRr3W_YSol.h6L3DUB1wyVAIuoaFPueWr0a3wB5yN6kBn9KHsDoE_Wt1UxkPIz
W6ySDbfqu2b5FjtjRrhrcPMWlf44xH6hyjCeItMh324.x1di1zXekzLL.RqZQa9z5Uk2CDR6340X
HrQtb5CfqzDS88tgFJ0.kmtzMbJZ.uGtZiEzwWI0l7lnrOrVEFLurPgWGEBmoDVwBsIJr2qnUGjw
xMCews6_1Keuw0Kru1WAruZEi3PR2Sb9nu5FDwXYj_lAjs6lYw95HfwZR2z09rN3uNFwLn0KqDBc
c__XuvUdw_TZyItMkgoEcwu_j8xN.hKexUG9KHHb3k72UQm2VrTmY4knXNxxXeUlLutAPpOYSBBo
1.jOCrWiWT.knvjgI7novtHfykOLP70XLtHHjJuWm8X3woV.DbdRRdx5.FjeEi6tPbxcn8cEQhaN
.rXVYJs8KeCZeCqc2e0WmonPY6apT3xqDAG0CJRzoGR6sMdOndz7HCnbDuLFrcbUh.fTtlPFYKSN
knYh.ex_tNYybVm8OVG8pQQUARaL5AqXcYcCdwrn3ge80BeBFYPVIf7ldhSN_4conRyF39ddrCxX
j7IpOQNTpzJXf2Au0grOvEPcIqjEcNx8QO9Rpj1pGcx9Zkb7BaXwq8g5LX5skvUfnFMEqMHAy4X1
rzWyUEcfTu3VyFPmGQaKxjFoX6cog0DU5gpPHdx9cX7L9Yw.GHV_4a.NPYuOTIssGrE2_MUCduA_
uCyBApLGWZ4txBVHH3fqr1FhCpu8Hx_9Iw9YmUAkl2bXoVaPQIxd5Jp9HaOt9Zk3lr4ZaPqhr_E0
graUE7VxG6TEY0ruKSI7g0nmWlAmAQSwL0c9eCaInyqpwio_.2Fv0Oaj6l_hUE0NAPW.SvEWpNHo
uVJleCKZ2yAvmWs1XnHFMwC1Nqv7dQmDDB5T09JCH2vWs27ut1C1WKitSxJVOZ8rdmojz9KiIoTP
CYbAv5_7z0t1x3ud1MutAl8elasjlyy5WF3T1JCu3Mad_1QNbVw2oXYTvKD6CbZZVGf2LKPhfCzq
TvaX3GdWbmFMhETQmUOqyqOIeyqRmfuZZc87X.uJFIaMpolFe92hJ4FkNOkM91ytXD3RMlXzZ5_J
KAgZZ6_GRTGNIxGMlJVANvHK5916RAiIakVAu5yGgj53vEyg_Q4wfFXt5.wdAu030MidXEti68nY
mdDwyfNZOkqdfkZmaOwNMZhB80TqCESdRvV8J9VonkTKhZgfSNgNnXEHaHW_bNRzXzyxhp37poA1
AHLGZktzNky7OHxuKB0BDRztzo6CjuANQq08cOqZPEgxlhtJqr3AyH_xa3Cbw0xYUH23juKTpotH
BVFPFdYBMyf20GdqA
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 2a795778-1bf0-4b24-8f5f-69fe7fb48c3a
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Feb 2024 03:15:56 +0000
Received: by hermes--production-gq1-5c57879fdf-8lthq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 21fc683c801ff0629383b7f8c993d52c;
Thu, 15 Feb 2024 03:15:54 +0000 (UTC)
Content-Type: text/plain;
charset=utf-8
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re:
files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not
found -- snapshot corrupt.
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <CANCZdfr3pOgs8CUFwheG1JUphXr4huGwTXHudQLapkw-jhmT7Q@mail.gmail.com>
Date: Wed, 14 Feb 2024 19:15:43 -0800
Cc: Mario Marietto <marietto2008@gmail.com>,
freebsd-arm <freebsd-arm@freebsd.org>,
freebsd-hackers <freebsd-hackers@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AA6A6B8-9BAE-4B03-9EF4-4A4D242582B4@yahoo.com>
References: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
<CANCZdfr3pOgs8CUFwheG1JUphXr4huGwTXHudQLapkw-jhmT7Q@mail.gmail.com>
To: Warner Losh <imp@bsdimp.com>
X-Mailer: Apple Mail (2.3774.400.31)
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: 4Tb0ZR4L9lz4vsJ
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
On Feb 14, 2024, at 18:23, Warner Losh <imp@bsdimp.com> wrote:
> You may need to grab the repo. You may have to back up to December's =
ports tree...=20
My understanding was that portsnap was staying installed
on 13.*-RELEASE until the last version is EOL and that
portsnap servers would be kept operational with valid
content until then.
I would have guessed that this would mean that 12.4-RELEASE
or the like would also be able to use the portsnap it
contains over that same time frame.
Am I wrong?
As stands, git use on 12.4-RELEASE would require bootstrapping
git somehow, possibly via portsnap, building git, and then
installing git (and the other stuff required).
(Not that I use portsnap.)
> Warner=20
>=20
> On Wed, Feb 14, 2024, 5:51=E2=80=AFPM Mario Marietto =
<marietto2008@gmail.com> wrote:
> Hello.
>=20
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 =
on my ARM Chromebook. Now I would like to install some ports. This is =
what happens when I try to get a fresh ports tree :
>=20
> marietto@freebsd:/usr # sudo portsnap fetch extract
>=20
> ....
> /usr/ports/databases/py-sqlalchemy10/
> /usr/ports/databases/py-sqlalchemy11/
> /usr/ports/databases/py-sqlalchemy12/
> /usr/ports/databases/py-sqlalchemy13/
> /usr/ports/databases/py-sqlalchemy14/
> /usr/ports/databases/py-sqlalchemy20/
> /usr/ports/databases/py-sqlcipher3/
> =
files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz =
not found -- snapshot corrupt.
>=20
> I repeated the "portsnap fetch extract" command,but I always get the =
same error.
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Thu Feb 15 07:03:36 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 4Tb5dM2t2nz5BQcv
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 07:03:51 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4Tb5dL3mg0z4Q2V
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 07:03:50 +0000 (UTC)
(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=yahoo.com header.s=s2048 header.b=NsqkquhJ;
dmarc=pass (policy=reject) header.from=yahoo.com;
spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707980627; bh=MeXQchCgb8mM0+cCyIy5FPE8IoHKb6gt5mkB4NXtxxs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NsqkquhJVU5CmP+Fly4l9eXMaDLQvtMMwhrJrYFMh6crHyi/p70Z76FWHbbVI/EYElT0+m7PaHvmtGhycTORQlddx0SWWoQvSlF06g+YDlLfRtexil+7Wqo+A28Z+CKLtyrbNi0Lv3UD8cHT67zLgoyPm5jCSEoLbvAq0qwGzmLrkdHI6qU5MVLkf9JazfhP1aZ5fyXGq67yTAma7Ode+Sc7sS6mG79VVIn+uRQS9e3lZMXm34bwAcIGwKiWKOoy01TPGPRtb6uo5LqP3lZr5lY+uAQLncm1QosXQApnlEjEv272NxRC3wzocmVENp87tlkCeP6R3EShc+IWnJ/mvA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707980627; bh=DKVJ13ryK05PfLedGgE/V+R5vZaDlcGlkrhE/o6JJlX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eUJROzSb9PZIrIPGT29fjLSFZdtIVRgH/vHPA/025qAYnKy3o4sPrf7YBpM/wCbMIRlczSQrjw8ESqckmvp6ZYFUo0X5N/DQpDwax2FH9p7ERGDDPavixPmCmSFt9XFu7a9ZZi+OCjiER+dBsA+wrAWLWhY+/MQ2FbAf6z/IsWPnYl1wG1fvT0rXr3dLVjQaZJgMHjx0AmpQXv1xn8VIdxAg7HSE7cQWSc4BSr0cEZ2HLxEzitzEcgM7Qrkwk0NqGTVd4pg7JWlbiHNScqMAiddMl9p05kvs9hbCX1aDEmUcu5rRDhddG4tsf1X6CYbeP5REjnej5ZzkHMmBZD649Q==
X-YMail-OSG: WD4bh98VM1lhGtFTYrjqYk3BNd5Xb24cDq3hmIEmnEU..ouZyjBhhWqr3js3tRt
A2F2wlpleuz0sLv.v5n_7s8ruls_fj65DxOEFSru0FZQLu9MDtAy5vVuJhHvNjq4lkhTBicPHrwd
juxREbdG0GijSTPmM0JCdhh04dCncjxvTbI6aHit29ahzDVSeo44xWyueMz3frLETv6s_DzTLaFE
k92tptPcu1kTeK_vtfUpIcViDfKDIVohUvy9VrvwZn29XnrUWrG.qSi1Bmg4L69BylXwSD9r75Vr
KIcSIBd3LKoxtIJ.f6zGiGH4qPH165GniM3u.RBl0RtPmZWXrhGPzJsS.UttXhGGy5Oi8e5sq8OB
dzyaOloDCZp3gBkqAh5N0UNoDVOamLqfuDdMd85QdZDPLmHLeKs_luIgSwPKDJi26KrfDNkBVZT3
98N6a84dS5PLxFH4zdp02T0QyxkNFl3qBMQGUdaJ_3ea7lZCSG6UjyVrkcUM8IUKnGkitT_O4r_s
E48Ml61TFupbVb.xFUwq8S4tosub1oSDN.FRAoWh.xhV69xF4kpHzxp8Md0mwLiwK0XTwlUowmtg
1BiVMMgdo8jrG0TuFplSfVSl2iyI6LPeoTESN4qrE65IUPOVKU2N_Iqo9VjpmSUm3o3Ccsinfjaz
1aFxJMPV4DDVKHjgGpAc_1q7H46RHG300XvR7wdNoWvWKc1rYL7FWmQD00vc1E6s5b_XK5t0M.g7
PIoRMsHSGI6zMaLdtqyJObBpBn5Wabs0csaQ_NrAKM4Xzx6J0u76u7e70fBT6HTxhAvPrZpMgMIO
DrW7RudWqGOK4yeDI28czWQLBjoHdzlJKkvUyRfIP.EinmJp9v8aqlZ6.76wM.EAJ85roRM3lq9F
8cmKpBF8C9Jp1w4o_CMMCteJGtcrFI9UPeaXRRvbhzCaBRlu.PmqdgL1kv_e6paOu.LMxeo125Y5
It0uPzQYEJWKICEirMYQYwQiFnZW6mqR_FipKno82nBDyINxYryGozx6yobZbe2RkzXeDKP9O3r_
WTRBxjsqOh6Ekktl1UPz7ZIYx6a_lcuzG6iTXKKvjr2OtT4GtZ230J9VZ6cbRzHxUOrZMxOMemJ2
lpvqOjRTXVFlqpdjRg1aPM.BChepyWMKbi7OQKUQngs8NI._7bVI07WC4eRDI2R9P7DOQPXqw5GQ
GNTp0kAqTLG1GMh8uMEr9UjNg9FFDqhIzvOyJmSEX_car5vv27p210k_lO8BFsiFzpm9b9rXfMj5
J.GVv_CJTirzg8e0cvwXKQkE.P3esH6v8cQnsOqvgCMZIG9dCRsuab8Jj.Fp68MloN9.KFlT4C_x
TrntBuOEFjwvmLL9gdaW2ujcAQz_WX9LEFe.1atRmST4fAxCxPgxyfsYSaOiJWhWHJaVRMQLwB63
8AARleU9RGrMyryCAPHtaNlSXbD9m9lBO1aMf0CICASuyptccPea2eCoD3bvcrEXr86XHOWBoLhd
.Ep8U22mKDPlAEmisJFbwlUnHEuiLZLXeb19nmuL1vVXaZeHs2IOZz5DkGsWt6NQm2qg_E3DuE7m
XAxNdCpBgGeGViwZotKtNlo.pY7CdCJsGuYrwNBl1V7ciwMzH2W6gxW8fUMDncsbQuc1ftwdSNlQ
2vkUwBwGMku6UoyThRdlHSZE0p.mr1baUQXa2Frg3htuKdaRhCUGe.hDeaTeo9jIcFsArcC_zzgj
SXl.Hq5Dz5Xx2K7aJE7Y4nQI7YeD7K6Aq.KyBoyUS3i9AWptYochs4rUCw5arNmkF0M_QWeLU3g0
ta4GrwpLLaybRZYt0wCiQAvDBxHBklSPQayVv7GcNUyaNDYGp0Ogt1dJq2LwXR8vA8d13Z8KjXIn
4U5MTnwSRvh_LcdDqvJYhXe2Kuj61A1K40lafxYCBGF_A3GZqK161RHhaHj5SNc0bPwmzHdJ9k7q
RA.A7Nf_nEgV56emBWQysI6emby_kKIX1zsrUJG0O3KSaBrhHiNOdTfUnyIJ5UlbgeRM9KDW1JMx
lcji4grxDozCdw0IsfLXHpG3xHcX9ONSuU.iasKs75ncOIaMnNIsxJ4YNsBZyh8tVOly2khej5d.
mv2dsee_KuhSvtz9OMWtrpqqCQRjMaA9oTNlytWnpBDM9aocwWm5aXzwLUqMALyIUIU8v5WeEhXR
HWAHkRuCMZRk4DotYQFQD7DPYe6dDzUTcWEy1FJIKmluPCvK0.zzPYShhD2rAtmLYBk_PfD7KmaF
uZygKEITxthpgqx.8fMlZQg.iiyT7EhkXdjidmHWFOQ04G_rwnsKHduxPX_roLplyJ67rQU.hLCA
-
X-Sonic-MF: <marklmi@yahoo.com>
X-Sonic-ID: 97c9ac52-1e8c-4137-9c70-4ebbec7897c9
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Feb 2024 07:03:47 +0000
Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f70fe77b7d2b0cd41d033cafece53803;
Thu, 15 Feb 2024 07:03:46 +0000 (UTC)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic [now
fixed]
From: Mark Millard <marklmi@yahoo.com>
In-Reply-To: <23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
Date: Wed, 14 Feb 2024 23:03:36 -0800
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <538577EB-70F0-4921-9CC6-2F12A06E9D45@yahoo.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
<0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
<072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
<23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.3774.400.31)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
MIME_GOOD(-0.10)[text/plain];
DKIM_TRACE(0.00)[yahoo.com:+];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
RCVD_TLS_LAST(0.00)[];
FREEMAIL_FROM(0.00)[yahoo.com];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_THREE(0.00)[4];
ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
FROM_EQ_ENVFROM(0.00)[];
FREEMAIL_ENVFROM(0.00)[yahoo.com];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
APPLE_MAILER_COMMON(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from];
RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]
X-Rspamd-Queue-Id: 4Tb5dL3mg0z4Q2V
On Feb 14, 2024, at 18:19, Mark Millard <marklmi@yahoo.com> wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>=20
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted with each of:
>=20
> /boot/kernel/kernel
> /boot/kernel.GENERIC-NODEBUG/kernel
>=20
> For reference:
>=20
> # uname -apKU
> FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT =
main-n268300-d79b6b8ec267 GENERIC-NODEBUG arm64 aarch64 1500014 1500012
>=20
> Thanks for the fix.
>=20
> Now I'll update the rest of pkg base materials.
Question: Are any of the changes to be MFC'd at some point?
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
From nobody Thu Feb 15 17:34:23 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TbMcw3fLZz59hmf;
Thu, 15 Feb 2024 17:34:24 +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 4TbMcw2Nk9z4ffB;
Thu, 15 Feb 2024 17:34:24 +0000 (UTC)
(envelope-from jamie@catflap.org)
Authentication-Results: mx1.freebsd.org;
none
X-Catflap-Envelope-From: <jamie@donotpassgo.dyslexicfish.net>
X-Catflap-Envelope-To: freebsd-arm@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 41FHYNf1061906;
Thu, 15 Feb 2024 17:34:23 GMT
(envelope-from jamie@donotpassgo.dyslexicfish.net)
Received: (from jamie@localhost)
by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 41FHYNBj061905;
Thu, 15 Feb 2024 17:34:23 GMT
(envelope-from jamie)
From: Jamie Landeg-Jones <jamie@catflap.org>
Message-Id: <202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net>
Date: Thu, 15 Feb 2024 17:34:23 +0000
Organization: Dyslexic Fish
To: marietto2008@gmail.com, freebsd-questions@FreeBSD.org,
freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org,
freebsd-arm@FreeBSD.org
Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt.
References: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
In-Reply-To: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
User-Agent: Heirloom mailx 12.4 7/29/08
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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, 15 Feb 2024 17:34:24 +0000 (GMT)
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: 4TbMcw2Nk9z4ffB
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
module=replies;
Message is reply to one we originated
Mario Marietto <marietto2008@gmail.com> wrote:
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on my
> ARM Chromebook. Now I would like to install some ports. This is what
> happens when I try to get a fresh ports tree :
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
> not found -- snapshot corrupt.
I'm not sure why the file isn't there - maybe because 12.X is EOL or portsnap
is deprecated?
Still, the solution is easy:
Download the ports tree snapshot as a tar from https://cgit.freebsd.org/ports/
Choose a tag, and a format. I suggest 12.4-eol so just fetch
https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz
rm -r /usr/ports
then untar the downloaded tar file into place.
Cheers, Jamie
From nobody Thu Feb 15 17:39: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 4TbMlF09Tkz59jYB;
Thu, 15 Feb 2024 17:39:53 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TbMlD6hqzz4k2f;
Thu, 15 Feb 2024 17:39:52 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1708018792;
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=F/i6e2J+/rZijI0GgJmaVrFspSXcI5JBt68CUkYiILE=;
b=sd0qYIV0ceAn9vQYdMx+cbIertMFLHEM/KxbSywfCiJ3Y0O/DsOwQewNCssPtEnjZBdpS1
14X6pLlG7fHlR1997Co8yGIQXKeG1sfDSGBezHcG+ko6RkNTBZR5DqH3E5q9UWmFejdwZJ
rVYDcQZCf3lWibSQ83EHANQNwCi/OVw6n4d6qvP7lX7rnq/8TxYSURrca3++2/OOCWYIsT
3NsY4sP9oYggpc1jB+VGtrdXhVfwBcPROSJAuGjWVlwVt9Ucn7jcpbld/NFYEjwOAOsZI0
gX2OY6Q0dbzDA0t0ONEPIbIPUBi2OA3dIY0p6jEhNbI/I75bjeyMH0zRVoQ+lQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708018792; a=rsa-sha256; cv=none;
b=cDgxhK+UPtR8RbEb9M0HH9AN7HewyjfPxKsbyhX15ASQU1QxePbbLxXGqfdTZnvAa06cO2
6XvJpd/i2LXY07ioq/NkaVrosZSkLAXnmwsOybDHTmOJ9EVhscjgszmJDUENq5AA4WfTHD
a0VV+nMFaU6zuhVZNv7ed38KlB+yQ3PNIdxO9zs5Aiys4G68s9D8ekMXOcWaemuQ1kMFen
Bdo2Z1oTeN7/y6DANDqGfyKi61WbTeOrHIWImbpeic7/tktAY1ub452WvM6fEWRHlSMRhd
e4Oin3wS4YkkrODyYoc9RnV2turYdEEOcNDXIjIvZqsp/gZyWbm6Uq3tUfgSdQ==
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=1708018792;
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=F/i6e2J+/rZijI0GgJmaVrFspSXcI5JBt68CUkYiILE=;
b=KVi1FpW8RQFh3PNHZWC5xa+ybE8rNj4XhKGrde6AaBr206ITnWt/u4t1a3GxYW2hcWFC6O
gthQRHCdhcjZpIMVrAOAa4LVKomdCVj0Qd3BTGBlk46hpXQIAbwpmgjlrB/+jSGmtx/eM8
s490iKPzKklcA02ezdKj9DLw8f3pralJpiqlfDfZExBlUC3X/0oKJ2vqXdH+JPqOjCAch2
cwDGRE+Gl8z6XpeQeAk1Rcd4YR8KjQn/C19B8Pyz+kkCyrOK4DVx/LORr3tDTvzcylvi5e
kACFI1BNAnTXLAelB7vQxOwUeCaHdXBAvmuPsPeF/3Sk5beJPJ0TiYhLHHobwQ==
Received: from [IPV6:2601:644:937c:5920:581f:5b54:cee8:a782] (unknown [IPv6:2601:644:937c:5920:581f:5b54:cee8:a782])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
(Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TbMlD2RNrz19P3;
Thu, 15 Feb 2024 17:39:51 +0000 (UTC)
(envelope-from jhb@FreeBSD.org)
Message-ID: <ffb3c426-55d8-41e4-9012-1458615d040d@FreeBSD.org>
Date: Thu, 15 Feb 2024 09:39:50 -0800
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic [now
fixed]
Content-Language: en-US
To: Mark Millard <marklmi@yahoo.com>
Cc: FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>
References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com>
<76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com>
<f4326cda-c602-439f-ab03-f66b3bca5ff2@FreeBSD.org>
<1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com>
<9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
<0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
<072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
<23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
<538577EB-70F0-4921-9CC6-2F12A06E9D45@yahoo.com>
From: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <538577EB-70F0-4921-9CC6-2F12A06E9D45@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/14/24 11:03 PM, Mark Millard wrote:
> On Feb 14, 2024, at 18:19, Mark Millard <marklmi@yahoo.com> wrote:
>
>> Your changes have the RPi4B that previously got the
>> panic to boot all the way instead. Details:
>>
>> I have updated my pkg base environment to have the
>> downloaded kernels (and kernel source) with your
>> changes and have booted with each of:
>>
>> /boot/kernel/kernel
>> /boot/kernel.GENERIC-NODEBUG/kernel
>>
>> For reference:
>>
>> # uname -apKU
>> FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT main-n268300-d79b6b8ec267 GENERIC-NODEBUG arm64 aarch64 1500014 1500012
>>
>> Thanks for the fix.
>>
>> Now I'll update the rest of pkg base materials.
>
> Question: Are any of the changes to be MFC'd at some point?
If I do I will merge a large batch at once, and probably adjust
the order. For example, I'll merge the pci_host_generic changes
before pci_pci changes so that stable branches will be bisectable.
--
John Baldwin
From nobody Thu Feb 15 20:32:19 2024
X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TbRb01B8Cz5B7nG;
Thu, 15 Feb 2024 20:33:00 +0000 (UTC)
(envelope-from marietto2008@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
(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 4TbRZz6cZ2z4DBF;
Thu, 15 Feb 2024 20:32:59 +0000 (UTC)
(envelope-from marietto2008@gmail.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a3566c0309fso161739466b.1;
Thu, 15 Feb 2024 12:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1708029177; x=1708633977; 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=CXyYJ+TWAhbtOKbEVx789CYk4pg44FBrve9Yg2bz8Pk=;
b=V4Qsg2GV+teoxrgx2+n4huie0ydGEWoFinW8fu1anG4TQBkSLWz0dk9u18z46lL60y
0QF8IAlUdvZxHfItYrbW19iEJxdx+zNog0jcDFqh70upZKSO8EdZWQ3w2Yv57QHnhzZM
+mqiyABkYhAG8n6NBIN3eX13C+jMt0IMTQe9dYyJXn8SLaCSz9K5G+ly3Uqm7NhEz7et
TGDaVd+x+wwRNiV3EOYvnjLE4F5jzI1Idez5Ti64y9m56ZjUfdWVssRvjsS1K4b4Ovj5
flghYQjrP7PycrxqYbEMzywksGXLKNTt/wOCAfneKpadA1s+VigA5aehlCUOHhLx9mRa
cXfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1708029177; x=1708633977;
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=CXyYJ+TWAhbtOKbEVx789CYk4pg44FBrve9Yg2bz8Pk=;
b=Doart7apug+F+3UOqXupzGHLs3RhCQb00XIBFTcvXX2AQhhluw9VRaiR6gnHodi9sC
zuJt9CCVmJ4rtwKxcWXr/9yVdkwRHwMr1HgexvmFK9lBoKazNjZhkOfW5Gt8sEWYxqOT
NP8z71M/IiOtX7XmB/vlF5xmhIFQ/M7QIvkdgeKNBHEvwtS0dGaYMUvqd5Ghn2hgP3jl
IgaxfOrt8cGS/0doM8wcrQ+JEjQumRPMhvRNFR6fJkYc30WG9h9YHLJ6qJVVCdg3zz6c
GLCbUwBMaaT2MQ5dI9F2+jJk9M+ve7f3I3ojIGBNdzJHuIy0wHAKdVPiPmgmPOIwsijA
RqDQ==
X-Forwarded-Encrypted: i=1; AJvYcCUVA64ABdWQonzx5cGfT5RGClVwqNQNErgXZ2hyNgTFgzofuzbGP6jlzPdqVXAR6ye7z8h5xP3dwJm4/mdUH2IHMZBKHGCg9FoRQezJPagfckXmKLBP/mM/GxnkVCP6qPlRyAdU3fhjfFKRWV3BoLEoTz6BfUj57OifepMNvaIGa6A=
X-Gm-Message-State: AOJu0YygUOUAwG0QAegEZjIF3mQyga1la1oM8LTNjJs0BfPbdl5oKIUc
RnW1kaE84lkk+32fXeqMIFZTeF3FfnJ5DtKNgO5c9kfTWkVRlQ9+byllyhoLSorAdYqtga0KEix
xhmo64q6744WCQPKJtVYqTEcEJm1lTqsgSrNszQ==
X-Google-Smtp-Source: AGHT+IFxVOyOt+MW5cGBcXU2R9bd4/Z1qVS6DdTgArAe5DkmUnC/cyShdLFkXesnlGmw+tdDJPAdrG6T+sEXfPvVJ80=
X-Received: by 2002:a17:906:4c58:b0:a3d:3be6:2a7e with SMTP id
d24-20020a1709064c5800b00a3d3be62a7emr2370672ejw.38.1708029176577; Thu, 15
Feb 2024 12:32:56 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
<202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net>
In-Reply-To: <202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net>
From: Mario Marietto <marietto2008@gmail.com>
Date: Thu, 15 Feb 2024 21:32:19 +0100
Message-ID: <CA+1FSijzd9djZ0z+uwcDwq1bnUaZWr1MDosj5cyLkzRV0L908A@mail.gmail.com>
Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
not found -- snapshot corrupt.
To: Jamie Landeg-Jones <jamie@catflap.org>
Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org,
freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000056059806117188fc"
X-Spamd-Bar: ----
X-Rspamd-Queue-Id: 4TbRZz6cZ2z4DBF
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]
--00000000000056059806117188fc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello.
What's the correct port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?
A) https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz
B) https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz
thanks.
On Thu, Feb 15, 2024 at 6:34=E2=80=AFPM Jamie Landeg-Jones <jamie@catflap.o=
rg>
wrote:
> Mario Marietto <marietto2008@gmail.com> wrote:
>
> > After a lot of work I've been able to install FreeBSD 12.04 for armv7 o=
n
> my
> > ARM Chromebook. Now I would like to install some ports. This is what
> > happens when I try to get a fresh ports tree :
> > files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.=
gz
> > not found -- snapshot corrupt.
>
> I'm not sure why the file isn't there - maybe because 12.X is EOL or
> portsnap
> is deprecated?
>
> Still, the solution is easy:
>
> Download the ports tree snapshot as a tar from
> https://cgit.freebsd.org/ports/
>
> Choose a tag, and a format. I suggest 12.4-eol so just fetch
>
> https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz
>
> rm -r /usr/ports
> then untar the downloaded tar file into place.
>
> Cheers, Jamie
>
>
--=20
Mario.
--00000000000056059806117188fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello.</div><div><br></div><div>What's the correc=
t port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?<br></div><div><br><=
/div><div>A) <a href=3D"https://cgit.freebsd.org/ports/snapshot/ports-12.4-=
eol.tar.gz">https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz</=
a></div><div><br></div><div>B) <a href=3D"https://cgit.freebsd.org/ports/sn=
apshot/ports-release/12.4.0.tar.gz">https://cgit.freebsd.org/ports/snapshot=
/ports-release/12.4.0.tar.gz</a></div><div><br></div><div>thanks.<br></div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu, Feb 15, 2024 at 6:34=E2=80=AFPM Jamie Landeg-Jones <<a href=3D"m=
ailto:jamie@catflap.org">jamie@catflap.org</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">Mario Marietto <<a href=3D"mai=
lto:marietto2008@gmail.com" target=3D"_blank">marietto2008@gmail.com</a>>=
; wrote:<br>
<br>
> After a lot of work I've been able to install FreeBSD 12.04 for ar=
mv7 on my<br>
> ARM Chromebook. Now I would like to install some ports. This is what<b=
r>
> happens when I try to get a fresh ports tree :<br>
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401=
.gz<br>
> not found -- snapshot corrupt.<br>
<br>
I'm not sure why the file isn't there - maybe because 12.X is EOL o=
r portsnap<br>
is deprecated?<br>
<br>
Still, the solution is easy:<br>
<br>
Download the ports tree snapshot as a tar from <a href=3D"https://cgit.free=
bsd.org/ports/" rel=3D"noreferrer" target=3D"_blank">https://cgit.freebsd.o=
rg/ports/</a><br>
<br>
Choose a tag, and a format. I suggest 12.4-eol so just fetch<br>
<br>
<a href=3D"https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz" rel=
=3D"noreferrer" target=3D"_blank">https://cgit.freebsd.org/ports/snapshot/p=
orts-12-eol.tar.gz</a><br>
<br>
rm -r /usr/ports<br>
then untar the downloaded tar file into place.<br>
<br>
Cheers, Jamie<br>
<br>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">Mario.<br></d=
iv>
--00000000000056059806117188fc--
From nobody Thu Feb 15 21:27: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 4TbSnw5Q7zz5BGvY
for <freebsd-current@mlmmj.nyi.freebsd.org>; Thu, 15 Feb 2024 21:27:32 +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 4TbSnv6W1Zz4PFL
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 21:27:31 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
none
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-56394d0ee54so85493a12.3
for <freebsd-current@freebsd.org>; Thu, 15 Feb 2024 13:27:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1708032450; x=1708637250; 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=QMjxRvsl+qiM5W6RWrLajeCn8pHAymIm439C+l12YUA=;
b=rDn/anZ/crL77WZ1kG5f731cIgzIQkN0y2vrjB3UM/gqJhjFTo8wPb5eJpTxnpkZfH
aXsKkKrtoBxCRtOfB4Ax6XpQV2kac8cWgAtY5cvAyPJEYyer9EqFB//B80Q9uYpbn/9W
AE+J0JvXihUpfZ+b82qCoztE7NzK2mCYd6uR8PkxZ/V8Gveg2YdVYKGCvK7EvO87yCl0
ye4oZ1SkSw+zHMGG/kvb4Ndl33Ppx5P54OHQHcoqllFJf54pYWeZ0fOFqdjcxFyBiZEX
xEFxUZvtqWZHjxrhdKnSPeMUjZBbmK9TWzu6KjP8gglK/6/wZA+IVRPe7rNc/fZHWHO8
G3CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1708032450; x=1708637250;
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=QMjxRvsl+qiM5W6RWrLajeCn8pHAymIm439C+l12YUA=;
b=bpi4N34wtitpc8XM48KetADAwsNUp58L9/LhJ4g9bMuwB5UPWHHuBE5BfKI+ngza+w
UuHLscP5J0hDKfBYkDUqHRMJiVb2Yb9eizaK5J6U31plOPZJEV2oGKw0PtbVuVCnoggv
1gfmxYvXQvdR65gbNjAYBwEGt7RetIbARCGZ1njpRZR7+UYji9L2/a3XfU3Hwk7/N7P8
brcd/zF5PqR7pqFKKcbiC5VkWojCJ0mtA8NMETRtVFJRtx/TgT5DoCfoGrPWTbh34CoQ
D1DbCg0iTEp9/sPCe27lD0GhkmH65qIxQUxQz+QmEzFcnAWM8Fd8DLfad3/ZGwCUwRtQ
/c9w==
X-Forwarded-Encrypted: i=1; AJvYcCVewqVSk03SDz075K7R/Y3wZ1ccoQjkQWd3BPyLb0w7QrGrIflXIzdlxad7EHYcpxbhOYv1euzl58eoFs7g4NR9HqIKGhpvY1xN0RQ=
X-Gm-Message-State: AOJu0YzTJCKpix4mWE0u9+DXS5pngxs2v6lzSeDIeKZVWG7WYQGtveuH
jkDVokYsm+6D76m5XnoucwfdeWV6WxS8XjvOpLKU2/e9zsmE5euGQgjDXX47vz5Wy8CTH2D4RVQ
4STUrFQY5UxLYji6B7aGBYq25wgTkX9CAn6sInw==
X-Google-Smtp-Source: AGHT+IGO8LCIpFlEaM9QH4uFjQeU+TEAKF5YAe8f7aSZELnUW7LQ/Foi3IPkJvXCbi27d4s0rxlW1eTLurPZiIIPObk=
X-Received: by 2002:a05:6402:646:b0:560:1652:e7cb with SMTP id
u6-20020a056402064600b005601652e7cbmr2235970edx.16.1708032450496; Thu, 15 Feb
2024 13:27:30 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <CA+1FSiiGqsUip5YSfCQTR2pDt6NBfAxuMYAHy_EMo7onsKx0Sg@mail.gmail.com>
<202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net> <CA+1FSijzd9djZ0z+uwcDwq1bnUaZWr1MDosj5cyLkzRV0L908A@mail.gmail.com>
In-Reply-To: <CA+1FSijzd9djZ0z+uwcDwq1bnUaZWr1MDosj5cyLkzRV0L908A@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Thu, 15 Feb 2024 14:27:18 -0700
Message-ID: <CANCZdfq0-EqZyKaVWibjLaz5r=1r0Js8i16aHuYyPWgX5aG+Lw@mail.gmail.com>
Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
not found -- snapshot corrupt.
To: Mario Marietto <marietto2008@gmail.com>
Cc: Jamie Landeg-Jones <jamie@catflap.org>, FreeBSD questions <freebsd-questions@freebsd.org>,
FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>,
"freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Content-Type: multipart/alternative; boundary="0000000000007a2e2d0611724b4b"
X-Spamd-Bar: ----
X-Rspamd-Queue-Id: 4TbSnv6W1Zz4PFL
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]
--0000000000007a2e2d0611724b4b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Feb 15, 2024, 1:33=E2=80=AFPM Mario Marietto <marietto2008@gmail.co=
m> wrote:
> Hello.
>
> What's the correct port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?
>
> A) https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz
>
> B) https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz
>
A is your best bet.
Warner
thanks.
>
> On Thu, Feb 15, 2024 at 6:34=E2=80=AFPM Jamie Landeg-Jones <jamie@catflap=
.org>
> wrote:
>
>> Mario Marietto <marietto2008@gmail.com> wrote:
>>
>> > After a lot of work I've been able to install FreeBSD 12.04 for armv7
>> on my
>> > ARM Chromebook. Now I would like to install some ports. This is what
>> > happens when I try to get a fresh ports tree :
>> > files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401=
gz
>> > not found -- snapshot corrupt.
>>
>> I'm not sure why the file isn't there - maybe because 12.X is EOL or
>> portsnap
>> is deprecated?
>>
>> Still, the solution is easy:
>>
>> Download the ports tree snapshot as a tar from
>> https://cgit.freebsd.org/ports/
>>
>> Choose a tag, and a format. I suggest 12.4-eol so just fetch
>>
>> https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz
>>
>> rm -r /usr/ports
>> then untar the downloaded tar file into place.
>>
>> Cheers, Jamie
>>
>>
>
> --
> Mario.
>
--0000000000007a2e2d0611724b4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, Feb 15, 2024, 1:33=E2=80=AFPM Mario Marietto &=
lt;<a href=3D"mailto:marietto2008@gmail.com">marietto2008@gmail.com</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hello=
.</div><div><br></div><div>What's the correct port tree for FreeBSD 12.=
04 for arm 32 bit ? A or B ?<br></div><div><br></div><div>A) <a href=3D"htt=
ps://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz" target=3D"_blan=
k" rel=3D"noreferrer">https://cgit.freebsd.org/ports/snapshot/ports-12.4-eo=
l.tar.gz</a></div><div><br></div><div>B) <a href=3D"https://cgit.freebsd.or=
g/ports/snapshot/ports-release/12.4.0.tar.gz" target=3D"_blank" rel=3D"nore=
ferrer">https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz=
</a></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">A is your best bet.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>th=
anks.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, Feb 15, 2024 at 6:34=E2=80=AFPM Jamie Landeg-Jones =
<<a href=3D"mailto:jamie@catflap.org" target=3D"_blank" rel=3D"noreferre=
r">jamie@catflap.org</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Mario Marietto <<a href=3D"mailto:marietto2008@gmail=
.com" target=3D"_blank" rel=3D"noreferrer">marietto2008@gmail.com</a>> w=
rote:<br>
<br>
> After a lot of work I've been able to install FreeBSD 12.04 for ar=
mv7 on my<br>
> ARM Chromebook. Now I would like to install some ports. This is what<b=
r>
> happens when I try to get a fresh ports tree :<br>
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401=
gz<br>
> not found -- snapshot corrupt.<br>
<br>
I'm not sure why the file isn't there - maybe because 12.X is EOL o=
r portsnap<br>
is deprecated?<br>
<br>
Still, the solution is easy:<br>
<br>
Download the ports tree snapshot as a tar from <a href=3D"https://cgit.free=
bsd.org/ports/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://cgi=
t.freebsd.org/ports/</a><br>
<br>
Choose a tag, and a format. I suggest 12.4-eol so just fetch<br>
<br>
<a href=3D"https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://cgit.freebsd.org/ports=
/snapshot/ports-12-eol.tar.gz</a><br>
<br>
rm -r /usr/ports<br>
then untar the downloaded tar file into place.<br>
<br>
Cheers, Jamie<br>
<br>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">Mario.<br></d=
iv>
</blockquote></div></div></div>
--0000000000007a2e2d0611724b4b--
From nobody Thu Feb 15 23:29:36 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 4TbWYw5fpmz50wZR;
Thu, 15 Feb 2024 23:32:20 +0000 (UTC)
(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TbWYw2CBjz4hNd;
Thu, 15 Feb 2024 23:32:20 +0000 (UTC)
(envelope-from warlock@phouka1.phouka.net)
Authentication-Results: mx1.freebsd.org;
none
Received: from phouka1.phouka.net (localhost [127.0.0.1])
by phouka1.phouka.net (8.17.1/8.17.1) with ESMTPS id 41FNTc7P073658
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
Thu, 15 Feb 2024 15:29:39 -0800 (PST)
(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
by phouka1.phouka.net (8.17.1/8.17.1/Submit) id 41FNTbNc073655;
Thu, 15 Feb 2024 15:29:37 -0800 (PST)
(envelope-from warlock)
Date: Thu, 15 Feb 2024 15:29:36 -0800
From: John Kennedy <warlock@phouka.net>
To: Mark Millard <marklmi@yahoo.com>
Cc: John Baldwin <jhb@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org>,
Current FreeBSD <freebsd-current@freebsd.org>,
Warner Losh <imp@bsdimp.com>
Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1
"rman_manage_region: <pcib1 memory window> request" leads to panic [now
fixed]
Message-ID: <Zc6eYGkKOlTWwdIV@phouka1.phouka.net>
References: <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com>
<4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com>
<3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com>
<1298DF9C-0F82-4567-8E81-7332A608C7FC@yahoo.com>
<d7b20565-6aa1-486f-a197-11fbc4d0c8dd@FreeBSD.org>
<36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com>
<CCA368C1-C8D7-4B54-999D-6F709C4E5039@yahoo.com>
<0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org>
<072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com>
<23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com>
X-Spamd-Bar: ----
X-Rspamd-Queue-Id: 4TbWYw2CBjz4hNd
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:14061, ipnet:107.170.192.0/18, country:US]
On Wed, Feb 14, 2024 at 06:19:04PM -0800, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted with each of:
>
> /boot/kernel/kernel
> /boot/kernel.GENERIC-NODEBUG/kernel
>
> For reference:
>
> # uname -apKU
> FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT main-n268300-d79b6b8ec267 GENERIC-NODEBUG arm64 aarch64 1500014 1500012
>
> Thanks for the fix.
>
> Now I'll update the rest of pkg base materials.
The recent changes resolved my boot issues as well.
FreeBSD 15.0-CURRENT #245 main-n268300-d79b6b8ec26 (GENERIC-NODEBUG arm64 1500014)
From nobody Fri Feb 16 17:32: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 4TbzXj2cGNz53sDl;
Fri, 16 Feb 2024 17:32:53 +0000 (UTC)
(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TbzXj0rL2z541d;
Fri, 16 Feb 2024 17:32:53 +0000 (UTC)
(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1708104773;
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;
bh=mYyiew30QBsOHJiZCYMQ0XiocH9JM632w1CzwUJA2A4=;
b=KLYwfe4To68iGrH9ZLH9EcuBeivLB5dnMLMV1wyEfw7A9wD5+i20GvZvhveYf90AwaEg9k
42DYlNB5OF+hxQ1ZEkcilcPapiK5Cf0ipdo/ycpoDnfxJdUdRgMp2IJ7qHPq3QtFCDZpN5
vaTuVGplTL5Dapc1Mggop4uaEb6oFESbLhODBIEADq1DuOXNcTyujyoq4HHO2M/bgc7naj
l/bx1G+fjsC+6yl6Vb0l8cbUsFoKJQMskri1p7kyckKYOfWH9otEH67aF4vk0X1vuvY8xT
ic2CVJUw0pwHPq2y5NquamZgyrOoYS9O1exBSVh8lBoQ2fV/MDUVyNZawkuKCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
s=dkim; t=1708104773;
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;
bh=mYyiew30QBsOHJiZCYMQ0XiocH9JM632w1CzwUJA2A4=;
b=XqagrHikxu9zeGqu0EuS/4vYni8rBt1XxN0mGhCoQuudR9Kdl8SMMPi0cWS9k7T4NXe8Fa
qcfxu0fGWiY9TkVZtzZBD7vuWOZoYRQxJc/wPjTDwV/eDD7OQNCfPwDyHCkvPw8G1Yv8U9
7VB3TS3qhSN0YpJoGg+7snJsSjCr3BueuryI/nvgA2678U/GizKFAS53QrbIocscxzOWNv
Lhc1sTFf8W0NrLDWAZPLmhIJ5IgnarNUczF6PSxUZ43vHxuW9fS7xfx6+/h2OmABrAVvzy
FtqEs325pH/W8XrIljPF3mtU3rGiuJpz058kaDoTHV8xRZJ7xzzRgIm5QuVgwg==
ARC-Authentication-Results: i=1;
mx1.freebsd.org;
none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708104773; a=rsa-sha256; cv=none;
b=mXqD9m2BNfKejvQ+D6IvB0ZQgTsTL6LX8ZTzM3HfNlzC5NvrHzZE6F7Kt/QKoOhRh+F/CL
Shz8dDfr3oi6GYm5K9GUxTF4ps8jt6b1SULDcLyycGLo4h0YVCVsjjuxG8tszD4OdT1yTx
cw2kibafTSJ23bcA0zvHdMERlfb1PWreoZ9cmL6wG/6ARVLvhiVR8rSH1XxHdOo/sjUB0P
pQU2z3Hdjl/6dAK+S4px15eAu2tJ63NfL7q3VODFCK+UUQJiX27cLd4r+FVKzTovwFTRNf
V1dZUkaKcEODD28ytoaLCoN2PIUIcbNCBwiZs3n1JH1+48DGyO0EtE8R+CDUuQ==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
id 0209063B6; Fri, 16 Feb 2024 17:32:52 +0000 (UTC)
Date: Fri, 16 Feb 2024 17:32:52 +0000
From: Lorenzo Salvadore <salvadore@freebsd.org>
To: freebsd-hackers@freebsd.org
Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject: FreeBSD Status Report - Fourth Quater 2023
Message-ID: <Zc-cRDwlV5mIAX46@freefall.freebsd.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
FreeBSD Status Report Fourth Quarter 2023
Here is the fourth 2023 status report, with 18 entries.
This is the last 2023 quarter. As you have probably noticed, this status report
comes later than usual and with fewer reports than the preceding quarter.
Indeed, please keep in mind that the last quarter of every year is for many
members of our community the quarter of the celebrations for Christmas and for
the New Year, which implies that those members will spend more time with their
families and will have less time for their favorite voluntary software
projects. Thus there is less to report and reports tend to arrive later. But
finally, here they are.
Have a nice read.
Lorenzo Salvadore, on behalf of the Status Team.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
A rendered version of this report is available here:
https://www.freebsd.org/status/report-2023-10-2023-12/
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Table of Contents
• FreeBSD Team Reports
â–¡ FreeBSD Core Team
â–¡ FreeBSD Foundation
â–¡ FreeBSD Release Engineering Team
â–¡ Cluster Administration Team
â–¡ Continuous Integration
â–¡ Ports Collection
â–¡ Bugmeister Team and Bugzilla
• Userland
□ Service jails — Automatic jailing of rc.d services
• Kernel
â–¡ Packrat - NFS client caching on non-volatile storage
• Architectures
â–¡ armv7 Ports Quality Assurance
â–¡ SIMD enhancements for amd64
• Cloud
â–¡ OpenStack on FreeBSD
â–¡ FreeBSD on Microsoft HyperV and Azure
â–¡ FreeBSD on EC2
• Documentation
â–¡ Documentation Engineering Team
â–¡ FreeBSD Online Editor and Man Page Editor
â–¡ FreeBSD Wiki
• Ports
â–¡ KDE on FreeBSD
â–¡ State of GNOME 44
â–¡ GCC on FreeBSD
• Third Party Projects
â–¡ Containers and FreeBSD: Pot, Potluck and Potman
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in the
Administration Page.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Core Team
Contact: FreeBSD Core Team <core@FreeBSD.org>
The FreeBSD Core Team is the governing body of FreeBSD.
Along the release engineering team, the project dedicates the 14.0-RELEASE to
the memory of Hans Petter Selasky.
14.0-RELEASE
FreeBSD 14.0 was released at the end of 2023Q4.
The release notes can be found at
https://www.freebsd.org/releases/14.0R/relnotes/
New Release Engineering Team
After years of serving as the release engineer gjb@ stepped down.
cperciva@ took over as the new release engineer. karels@ is serving as the new
deputy release engineer.
Core would like to thank gjb@ for his long tenure and the many timely releases
he created.
FreeBSD 2024 Community Survey
In the end of 2023, Core Team works with the Foundation to do the 2024
community survey.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Foundation
Links:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://freebsdfoundation.org/donate/
Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/
freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Foundation Events URL: https://freebsdfoundation.org/our-work/events/
Contact: Deb Goodkin <deb@FreeBSDFoundation.org>
The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and worldwide community, and
helping to advance the state of FreeBSD. We do this in both technical and
non-technical ways. We are 100% supported by donations from individuals and
corporations and those investments help us fund the:
• Software development projects to implement features and functionality in
FreeBSD
• Sponsor and organize conferences and developer summits to provide
collaborative opportunities and promote FreeBSD
• Purchase and support of hardware to improve and maintain FreeBSD
infrastructure,
• Resources to improve security, quality assurance, and continuous
integration efforts.
• Materials and staff needed to promote, educate, and advocate for FreeBSD,
• Collaboration between commercial vendors and FreeBSD developers,
• Representation of the FreeBSD Project in executing contracts, license
agreements, and other legal arrangements that require a recognized legal
entity.
We supported FreeBSD in the following ways during the last quarter of 2023:
OS Improvements
During the fourth quarter of 2023, 236 src, 47 ports, and 33 doc tree commits
identified The FreeBSD Foundation as a sponsor. Some of this
Foundation-sponsored work is described in separate report entries:
• OpenStack on FreeBSD
• SIMD enhancements for amd64.
Three new contractors started. Cheng Cui began working full-time on wireless
networking. A main goal for Cheng’s project is to assist Bjoern Zeeb with
802.11ac support in iwlwifi. Tom Jones began work to port the Vector Packet
Processor (VPP) to FreeBSD. VPP is an open-source, high-performance user space
networking stack that provides fast packet processing suitable for
software-defined networking and network function virtualization applications.
Olivier Certner joined the FreeBSD Foundation as a general FreeBSD developer.
Some of Olivier’s contributions so far include:
• reviewing, fixing, and hardening several security policies aimed at
limiting process visibility, policies that are based on user identity,
group membership, or sub-jail membership
• committing fixes in the login class code, including one that allowed
unprivileged users to bypass resource limits
• implementing a secure hardware fix for the Zenbleed issue affecting AMD
Zen2 processors.
Here is a sampling of other Foundation-sponsored work completed over the last
quarter of 2023:
• arm64: Add Armv8 rndr random number provider
• net80211, LinuxKPI, and iwlwifi fixes and improvements
• OpenSSL: updates to 3.0.11 and 3.0.12
• Various freebsd-update fixes in preparation for 14.0
• ssh: Update to OpenSSH 9.5p1
• Various iommu fixes
• Various makefs/zfs fixes
Learn more about our software development work for all of 2023 at
https://freebsdfoundation.org/blog/2023-in-review-software-development/.
FreeBSD Infrastructure
We approved over $100,000 for a cluster refresh that began in late 2023 and
will carry over into the new year by purchasing and shipping 15 new servers to
4 racks generously donated by NYI in their new Chicago facility. The systems
specifications were determined by the Cluster Administration team and consist
of:
• 5 package builders
• 3 web servers
• 2 package mirrors
• 2 CI servers
• 2 firewall/router
• 1 admin bastion
More on our 2023 infrastructure support can be found at:
https://freebsdfoundation.org/blog/2023-in-review-infrastructure/.
Continuous Integration and Workflow Improvement
As part of our continued support of the FreeBSD Project, the Foundation
supports a full-time staff member dedicated to improving the Project’s
continuous integration system and the test infrastructure. The full update can
be found within the quarterly status report.
Partnerships and Research
In Q4 I connected with the following people, companies, and organizations: Phil
Shafer, who works at Juniper Networks, and I met at All Things Open. He told me
about the libxo library and his continuing work on related issues, like
rewriting and filtering output to allow richer options that regular expressions
provide. Sticking with Juniper, I also met Simon Gerraty at the Vendor Summit
and heard his talk on SecureBoot. In alphabetical order, I also met with AMD,
Ampere, Center for Internet Security (CIS), Innovate UK, Michael Dexter,
Metify, Microsoft, several people at NetApp when I attended their annual
conference (Thank you for the invitation!!), NetScaler, NIST, Nozomi Networks,
NVIDIA, members of the Open Container Initiative community, OpenSSF, RG Nets,
Doug Rabson.
I greatly appreciated the opportunity to attend NetApp’s annual conference in
October. I heard from and connected with experts at NetApp and their partners
and customers on topics such as AI and seamless AI data pipelines, hybrid
cloud, and green computing. I took the opportunity to hand out some FreeBSD
lapel pins 🙂 and I connected with a FreeBSD user and member of the Enterprise
WG whose company is a NetApp Customer.
In Q4 we announced the new FreeBSD SSDF Attestation program to help commercial
users of FreeBSD comply with new US Government procurement regulations. This
program was informed by valuable feedback from NetApp, Metify, and NIST, and
the genesis of the idea came thanks to my involvement with open source policy
experts, in particular via the OSI’s Open Policy Alliance.
The Open Container Initiative Technical Oversight Board voted in December to
approve Doug Rabson’s proposal to create a Working Group to extend the OCI
runtime specification to support FreeBSD. Huge thanks to all involved! An OCI
runtime extension for FreeBSD is one of the most frequently requested
capabilities and I was happy to play a small role in helping to coordinate this
effort so far.
The Vendor Summit in November was a great event. Huge props to John Baldwin and
Anne Dickison for all the work to organize and orchestrate. I got a lot out of
the event. Personal highlights were conversations with a diversity of users,
the CHERI talk, the end user panel, and Allan’s talk on being an upstream first
company. For a full recap on our efforts to strengthen partnerships and
increase funding in 2023, check out:
https://freebsdfoundation.org/blog/2023-in-review-partnerships-and-research/.
Advocacy
>From organizing and attending events, to creating technical content that
educates, and expanding the coverage of FreeBSD in the media, here is a sample
of what we did last quarter to support FreeBSD.
• Helped organize and sponsor the November 2023 Vendor Summit held at NetApp
in San Jose. Many consider this one of the best summits to date. Be sure to
check out the videos.
• Introduced FreeBSD to new and returning folks at All Things Open in North
Carolina.
• Provided an overview of FreeBSD 14: Security, Performance, and
Interoperability; Introducing FreeBSD 14
• In collaboration with the Core team, released the 2024 FreeBSD Community
Survey
• Participated in an interview about FreeBSD: What the Dev Podcast: The
Evolution of the FreeBSD Project
• Release the September/October 2023 issue of the FreeBSD Journal now with
HTML versions of the articles.
For a full recap of what we did to advocate for FreeBSD in 2023, please check
out the Advocacy Year in Review:
https://freebsdfoundation.org/blog/2023-in-review-advocacy/
or the monthly newsletters:
https://freebsdfoundation.org/our-work/latest-updates/?filter=newsletter.
Fundraising
Thank you to everyone who gave us a financial contribution last quarter to help
fund our work to support the Project. You brought us even closer to our goal
and we are grateful for your investment in FreeBSD! We are still receiving
donations in the mail and will post the final number in mid-February.
Please consider supporting our efforts in 2024 by making a donation here:
https://freebsdfoundation.org/donate/.
Or, check out our Partnership opportunities here:
https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/.
Legal/FreeBSD IP
The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.
Go to https://freebsdfoundation.org to find more about how we support FreeBSD
and how we can help you!
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Release Engineering Team
Links:
FreeBSD 13.3-RELEASE schedule URL: https://www.freebsd.org/releases/13.3R/schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/
Contact: FreeBSD Release Engineering Team, <re@FreeBSD.org>
The FreeBSD Release Engineering Team is responsible for setting and publishing
release schedules for official project releases of FreeBSD, announcing code
freezes and maintaining the respective branches, among other things.
During the fourth quarter of the year, the Team continued work on 14.0-RELEASE,
leading to the final RELEASE build and announcement in November. Planning has
started for the upcoming 13.3-RELEASE and 14.1-RELEASE cycles.
The Release Engineering Team continued providing weekly development snapshot
builds for the main and stable/13 branches, and (after 14.0-RELEASE) started
weekly builds for stable/14.
After over a decade as Release Engineering Lead, Glen Barber has retired from
the role; his Deputy, Colin Percival, has moved into the Lead role, while Mike
Karels has assumed the position of Deputy Release Engineer.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Cluster Administration Team
Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm
Contact: Cluster Administration Team <clusteradm@FreeBSD.org>
FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronize its distributed work and
communications.
In this quarter, the team has worked on the following:
• Regular support for FreeBSD.org user accounts.
• Regular disk and parts support (and replacement) for all physical hosts and
mirrors.
• Enable mirroring of https://www.FreeBSD.org and https://docs.FreeBSD.org in
the FreeBSD project-managed mirrors.
• Cluster refresh, upgrading all hosts and jails to the most recent versions
of 15-CURRENT, 14-STABLE, 13-STABLE, and 12-STABLE.
• Begin sunsetting 12-STABLE infrastructure as the branch approaches its end
of life.
In addition to these projects, with Modirum generously sponsoring Philip’s time
for most of October, we were able to bring pkgbase into "preview" production in
time for 14.0-RELEASE in November.
We also installed a new European mirror site in Sjöbo, Sweden, sponsored by
Teleservice Skåne AB. Traffic in Europe is now directed roughly equally between
our existing mirror in Frankfurt (sponsored by Equinix) and the new mirror in
Sweden. After well over ten years in service, we plan to decommission our
mirror site in the UK during first quarter of 2024. We would like to thank
Bytemark Hosting for supporting this mirror for all this time.
Next quarter, supported by the FreeBSD Foundation, we plan to bring up a new
primary cluster site in Chicago.
FreeBSD Official Mirrors Overview
Current locations are Australia, Brazil, Germany, Japan (two full mirror
sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror
site), United States of America — California, New Jersey (primary site), and
Washington.
The hardware and network connection have been generously provided by:
• Bytemark Hosting (decommissioned during 2024Q1)
• Cloud and SDN Laboratory at BroadBand Tower, Inc
• Department of Computer Science, National Yang Ming Chiao Tung University
• Equinix
• Internet Association of Australia
• Internet Systems Consortium
• INX-ZA
• KDDI Web Communications Inc
• Malaysian Research & Education Network
• Metapeer
• NIC.br
• Your.Org
• 365 Data Centers
• Teleservice Skåne AB (new since 2023Q4)
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Continuous Integration
Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI Tinderbox view URL: https://https://tinderbox.freebsd.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI
3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL:
https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci
Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet
In the fourth quarter of 2023, we worked with the project contributors and
developers to address their testing requirements. Concurrently, we collaborated
with external projects and companies to enhance their products by testing more
on FreeBSD.
Important completed tasks:
• Adding job to build amd64 architecture with GCC 13. (Thanks jhb@)
• Adding powerpc64le jobs config for stable-14 (Thanks alfredo@)
• Updating the build env of jobs of main and stable/14 branches to
14.0-RELEASE
Work in progress tasks:
• Designing and implementing pre-commit CI building and testing and pull/
merged-request based system (to support the workflow working group)
• Proof of concept system is in progress.
• Designing and implementing use of CI cluster to build release artifacts as
release engineering does, starting with snapshot builds
• Simplifying CI/test environment setting up for contributors and developers
• Setting up the CI stage environment and putting the experimental jobs on it
• Redesigning the hardware test lab and adding more hardware for testing
• Merge https://reviews.freebsd.org/D38815
• Merge https://reviews.freebsd.org/D36257
Open or queued tasks:
• Collecting and sorting CI tasks and ideas
• Setting up public network access for the VM guest running tests
• Implementing use of bare-metal hardware to run test suites
• Adding drm ports building tests against -CURRENT
• Planning to run ztest tests
• Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
3rdPartySoftwareCI, HostedCI)
• Working with hosted CI providers to have better FreeBSD support
Please see freebsd-testing@ related tickets for more WIP information, and do
not hesitate to join the effort!
Sponsor: The FreeBSD Foundation
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Ports Collection
Links:
About FreeBSD Ports URL: https://www.FreeBSD.org/ports/
Contributing to Ports URL:
https://docs.freebsd.org/en/articles/contributing/#ports-contributing
+ Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/
Contact: Tobias C. Berner <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>
The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.
• According to INDEX, there are currently 31,942 ports in the Ports
Collection. There are currently ~3,100 open ports PRs. The last quarter saw
9,424 commits by 157 committers on the main branch and 781 commits by 71
committers on the 2023Q4 branch. Compared to last quarter, this means a
hefty decrease in the number of commits on the main branch (down from
11,454) and slightly fewer backports to the quarterly branch (down from
828). The number of ports also fell a bit (down from 34,600).
In Q4 there were around 9424 commits to main. The most active committers where:
sunpoet 2946 yuri 861 bofh 793 jbeich 419 fuz 324 eduardo 168 fernape 160 jhale
153 thierry 146 diizzy 123
During Q4 we welcomed Michael Osipov (michaelo) and Timothy Beyer (beyert) as
new committers, but sadly also had to say goodbye to bland, sbruno, hselasky
and gjb.
We invited arrowd, flo and riggs to be part of portmgr-lurkers for the next
months.
Support for FreeBSD 12.x was removed at the end of the quarter.
The end of Q4 also saw the introduction of subpackages to the ports tree.
Similar to when flavors were introduced, new subpackages will require an
approval by portmgr before being pushed to the tree. With subpackages it is
possible to create multiple packages from a single build of a port.
The following happened on the infrastructure side: * Packages for 14.0-RELEASE
were built * Poudriere was updated to release-3.4
• Support for FreeBSD 12.x was removed.
• The no-longer maintained www/qt5-webkit was removed.
• postgresql11, php80, mysql57, percona57, ghostscript9 were removed.
• The following default versions changed:
• perl to 5.36
• ghostcript to 10
• corosync to 3
• Updates to major ports that happened were:
• ports-mgmt/pkg to 1.20.9
• ports-mgmt/poudriere to 3.4.0 (subpackage support)
• KDE-bits to plasma-5.27.10, frameworks-5.112, gear-23.08.4, and beta-2
• www/chromium to 120.0.6099.129
• www/firefox to 121.0 (rc1)
• lang/rust to 1.74.1
• …​ and many more …​
During the last quarter, pkgmgr@ ran 26 exp-runs to test various ports
upgrades, updates to default versions of ports, subpackage support and base
system changes.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Bugmeister Team and Bugzilla
Links:
Bugmeister team URL: https://www.freebsd.org/administration/#t-bugmeister
FreeBSD Bugzilla URL: https://bugs.freebsd.org/bugzilla/
Contact: Bugmeister <bugmeister@FreeBSD.org>
Some recent maintenance has been done on our Bugzilla instance:
• the weekly reminder emails now include the correct values for mfc-* Flags
queries;
• the Dashboard page has had an obsolete query removed. (We no longer use the
'patch-ready' Keyword; it was too much paperwork. Thus, the query on that
field was useless.);
• the limit that capped the maximum number of reported PRs at 10000 has been
raised to 12500.
In addition, the Wiki documentation on our Bugzilla has been updated:
• the page https://wiki.freebsd.org/Bugzilla/SearchQueries has been
substantially reworked:
â–¡ In particular, documentation about how to search on Flag values has
been added. (This may not have been done before.) Example: search for
PRs with Flag 'mfc-stable14' set;
â–¡ This page may be of interest to all committers and contributors;
• the page https://wiki.freebsd.org/Bugmeister/BugmeisterQA has also been
updated; While similar to the above, it is of more specific interest to
bugmeister and triagers.
As well, PRs that are specific to FreeBSD 12 are being culled, as 12 has gone
out of support as of 20231231.
A further effort is being made to document our setup of Bugzilla itself,
especially with respect to our customizations. This is needed to bring our own
repository up to date with what is running on production.
The number of PRs over the past quarter (and year) has remained consistent.
However, we do seem to be closing incoming PRs more quickly these days. For
reference: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=90
.
The overall number of PRs remains around 11,400.
Bugmeister is also working towards restarting the Bugathons. See the updated
page https://wiki.freebsd.org/Bugathons.
Bugmeister would like to thank a number of people who have assisted with
bugbusting, including Mina Galić, Graham Perrin, Lorenzo Salvadore, and
Fernando Apesteguìa, among others.
In addition, bugmeister would like to thank all the FreeBSD committers who help
process the PRs as they come in. Over the last few months we seem to be much
closer to steady-state.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Userland
Changes affecting the base system and programs in it.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Service jails — Automatic jailing of rc.d services
Links:
D40370: Infrastructure for automatic jailing of rc.d-services URL:
https://reviews.freebsd.org/D40370
D40371: automatic service jails: some setup for full functionality of the
services in automatic service jails URL:
https://reviews.freebsd.org/D40371
D42779: Handbook / rc-article update for Service Jails URL:
https://reviews.freebsd.org/D42779
Contact: Alexander Leidinger <netchild@FreeBSD.org>
Service jails extend the rc(8) system to allow automatic jailing of rc.d
services. A service jail inherits the filesystem of the parent host or jail,
but uses all other limits of the jail (process visibility, restricted network
access, filesystem mounting permissions, sysvipc, …​) by default. Additional
configuration allows inheritance of the IPs of the parent, sysvipc, memory page
locking, and use of the bhyve virtual machine monitor (vmm(4)).
If you want to put e.g. local_unbound into a service jail and allow IPv4 and
IPv6 access, simply change rc.conf(5) to have:
local_unbound_svcj_options=net_basic
local_unbound_svcj=YES
Note: all base system services are covered in the patches with either
name_svcj_options or a hard-coded disabling of the service jails feature where
it does not make sense (e.g. pure services which change the runtime
configuration but do not start daemons, or where things are run which can not
be run in a sensible way inside a jail). As such the local_unbound_svcj_options
line above is superfluous and serves just as an example about the amount of
configuration needed in total.
While this does not have the same security benefits as a manual jail setup with
a separate filesystem and IP/VNET, it is much easier to set up, while providing
some of the security benefits of a jail like hiding other processes of the same
user.
Since the previous service jails status report, the following were added:
• support for NFS inside jails in the service jails framework (untested),
• the possibility of jailing other service commands than start and stop,
• service jails options / config for all base system services in the patch in
D40371,
• a first step at documenting the service jails in the Handbook.
Not all services are tested, but all services are covered with a config.
Any testing and feedback (even as simple as "service X works in a service
jail") is welcome.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and more.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Packrat - NFS client caching on non-volatile storage
Contact: Rick Macklem <rmacklem@FreeBSD.org>
NFSv4.1/4.2 provides support for a feature called delegations. When a NFSv4.1/
4.2 client holds a delegation, the client has certain rights to a file,
including a guarantee that no other client will make changes to the file unless
the delegation is recalled. As such, when a client holds a delegation for a
file, it can aggressively cache the file’s data, knowing that it will not be
modified by other clients until it returns the delegation.
This project is intended to allow the NFSv4.1/4.2 client to aggressively cache
file data on client local non-volatile storage, when the client holds a
delegation for the file. I created a patch long ago to try and do this for
NFSv4.0, but it was never at a stage where it was worth using. This project is
a complete rewrite of the patch, done in part because NFSv4.1/4.2 plus other
recent NFSv4-related changes make doing this more feasible.
I now have code running fairly well and hope to have a patch ready for others
to test this winter. Early testing shows promise. For a test run of "make
buildkernel", the test with and without packrat enabled performed as follows:
Table 1. NFS operation counts
NFS operation counts Getattr Lookup Read Write Total RPCs
with packrats 433506 99254 0 0 371736
without packrats 2359913 97954 10748 0 2318810
Table 2. Elapsed Run Time
Elapsed Run Time (sec) with packrat without packrat
5561 6203
As you can see, the packrat case ran a little faster and with fewer RPCs.
Although this test was run on my little LAN, it is hoped that a NFSv4.1/4.2
mount over a WAN would show a larger difference in performance. I will note
that the packrat cache was primed by unrolling a tarball of FreeBSD’s /usr/src
into the NFSv4.1/4.2 mount.
This will be very much an experimental feature, but it is hoped it will allow
NFS mounts to be used more effectively, particularly in WAN situations, such as
a mobile laptop.
There is still work to be done, particularly with respect to recovery of
delegations after a NFSv4.1/4.2 client restart. Hopefully, the next status
report will include a URL that allows downloading of a patch for user testing.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Architectures
Updating platform-specific features and bringing in support for new hardware
platforms.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
armv7 Ports Quality Assurance
Contact: Robert Clausecker <fuz@FreeBSD.org>
As part of a long term project to improve the quality of the FreeBSD ports
collection for the armv7 architecture, a number of issues in the base system
and in various ports have been fixed. Through this action, the number of binary
packages that could be successfully built from the 2023Q4 branch of the ports
collection was increased from 30018 (as of 2023-10-04) to 31118 (as of
2023-11-24).
Two kernel bugs affecting package builds (PR 267788 and PR 274705) were
identified and addressed, with these two alone being responsible for around 900
failed packages. The most common other causes for build failures include
• lack of FreeBSD-specific armv7 support code
• data alignment issues (armv7 being one of the few architectures for which
we do not support unaligned memory accesses)
• address space exhaustion during the build processes (usually LTO related;
PR 274705 addressed many cases)
• lack of OpenMP support on armv7 FreeBSD
If you are a user of the FreeBSD ports collection on armv7, do not hesitate to
file a bug report on our bug tracker should there be any issues.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
SIMD enhancements for amd64
Links:
FreeBSD Foundation blog post URL:
https://freebsdfoundation.org/blog/a-sneak-peek-simd-enhanced-string-functions-for-amd64/
simd(7) URL:
https://man.freebsd.org/cgi/man.cgi?query=simd&sektion=7&manpath=FreeBSD+15.0-CURRENT
Work currently under acceptance testing URL:
https://github.com/clausecker/freebsd-src/commits/acceptance-testing
Contact: Robert Clausecker <fuz@FreeBSD.org>
The project to enhance the libc with SIMD implementations of string functions
for amd64 has now concluded. In total, SIMD implementations for 17 libc
functions have been written, complemented by scalar implementations where
needed. Through this rewrite, performance of these functions on strings with an
average length of 64 characters was improved by an average factor of 5.54. In
addition, 9 other library functions were rewritten to call into the
SIMD-enhanced routines, conveying benefits without requiring additional
assembly implementations. Please see the FreeBSD Foundation blog post linked
above for more details.
Parts of the SIMD work are already found in the CURRENT branch. The rest is
currently undergoing acceptance testing and will be merged if no problems
emerge. It is planned to back port all improvements to 14-STABLE for inclusion
into FreeBSD 14.1.
Sponsor: The FreeBSD Foundation
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Cloud
Updating cloud-specific features and bringing in support for new cloud
platforms.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
OpenStack on FreeBSD
Links:
OpenStack URL: https://www.openstack.org/
OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd
Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
In the fourth quarter, we successfully migrated the originally virtualized
OpenStack platform to physical machines running FreeBSD 14.0-STABLE. The ported
OpenStack components include Keystone, Glance, Placement, Neutron, and Nova. As
part of this process, we took the opportunity to update the installation
documentation and the list of dependencies.
Moving forward, we encourage users and developers interested in this project to
effortlessly recreate the OpenStack platform in their FreeBSD environments
following this documentation. Any issues or difficulties encountered are
welcome to be reported on the GitHub project page. Your contributions will
contribute to the refinement of our installation documentation and the overall
porting efforts.
In the upcoming quarter, our focus will shift towards incorporating various
patches and workarounds generated during the migration process into the project
in a more structured code form. Additionally, we plan to develop FreeBSD ports
for each OpenStack component, further streamlining the installation process.
Sponsor: The FreeBSD Foundation
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD on Microsoft HyperV and Azure
Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/
MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV
Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
In this quarter, we have solved all the blocking issues and published the
14.0-RELEASE on Azure Marketplace, with complete architecture (amd64, arm64)
and VM generation (gen1, gen2) support, available in both UFS and ZFS as the
root file system.
Work in progress tasks:
• Automating the image building and publishing process and merging to src/
release/.
• Building and publishing snapshot builds to Azure community gallery.
The above tasks are sponsored by The FreeBSD Foundation, with resources
provided by Microsoft.
Open tasks:
• Update FreeBSD related doc at Microsoft Learn
• Support FreeBSD in Azure Pipelines
• Update Azure agent port to the latest version
• Upstream local modifications of Azure agent
• Port Linux Virtual Machine Extensions for Azure
Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD on EC2
Links:
FreeBSD/EC2 Patreon URL: https://www.patreon.com/cperciva
Contact: Colin Percival <cperciva@FreeBSD.org>
FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2
instances. Work continues to ensure that upcoming instance types will be
supported; most recently, changes were needed to support "7th generation" Intel
and AMD instances.
FreeBSD 14.0-RELEASE shipped with experimental ZFS-root AMIs and "cloud-init"
AMIs. Additional "flavored" FreeBSD AMIs are planned, including "AMI Builder"
and "minimal" (no debug symbols).
A bug in the release-building process which resulted in 14.0-RELEASE AMIs
shipping with duplicate lines in /etc/rc.conf has been corrected and future
releases should not be affected.
A bug in the ec2-aws-imdsv2-get utility which resulted in 14.0-RELEASE AMIs not
supporting binary user-data files has been corrected and future releases should
not be affected.
This work is supported by Colin’s FreeBSD/EC2 Patreon.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Documentation
Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Documentation Engineering Team
Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/
Link: FreeBSD Documentation Project Primer for New Contributors URL:
https://docs.freebsd.org/en/books/fdp-primer/
Link: Documentation Engineering Team URL:
https://www.freebsd.org/administration/#t-doceng
Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>
The doceng@ team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.
During the last quarter:
Glen Barber stepped down from doceng. doceng would like to thank gjb@ for his
service.
Ceri Davies' commit bit was taken for safekeeping as per his request. doceng
would like to thank ceri@ for his contributions.
mhorne@ to be mentored by carlavilla@ to obtain a documentation commit bit.
FreeBSD Handbook:
The Handbook was updated to show that FreeBSD 14.0 is the latest release.
FreeBSD Translations on Weblate
Link: Translate FreeBSD on Weblate URL:
https://wiki.freebsd.org/Doc/Translation/Weblate
Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/
Q4 2023 Status
• 17 team languages
• 203 registered users
Languages
• Chinese (Simplified) (zh-cn) (progress: 7%)
• Chinese (Traditional) (zh-tw) (progress: 3%)
• Dutch (nl) (progress: 1%)
• French (fr) (progress: 1%)
• German (de) (progress: 1%)
• Indonesian (id) (progress: 1%)
• Italian (it) (progress: 5%)
• Korean (ko) (progress: 33%)
• Norwegian (nb-no) (progress: 1%)
• Persian (fa-ir) (progress: 2%)
• Polish (progress: 1%)
• Portuguese (progress: 0%)
• Portuguese (pt-br) (progress: 22%)
• Spanish (es) (progress: 35%)
• Turkish (tr) (progress: 2%)
We want to thank everyone that contributed, translating or reviewing documents.
And please, help promote this effort on your local user group, we always need
more volunteers.
FreeBSD Handbook working group
Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>
• The Network chapter has been rewritten
• The Jails chapter has been rewritten
• The next section to work on will be the file systems part: UFS, ZFS, Other
File Systems
FAQ Working Group
Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>
A new FAQ was released alongside FreeBSD 14.0.
FreeBSD Website Revamp - WebApps working group
Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>
Working group in charge of creating the new FreeBSD Documentation Portal and
redesigning the FreeBSD main website and its components. FreeBSD developers can
follow and join the working group on the FreeBSD Slack channel #wg-www21. The
work will be divided into three phases:
1. Redesign of the Manual Pages on web
Scripts to generate the HTML pages using mandoc. (Complete, Approved by
Doceng, Deploy Date Not Decided Yet) Public instance on
https://man-dev.FreeBSD.org
2. Redesign of the FreeBSD main website
New design, responsive and dark theme. (Almost Complete, Presented at
EuroBSDCon)
3. Redesign of the Ports page on web
Ports scripts to create an applications portal. (Work in progress)
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Online Editor and Man Page Editor
Links:
FreeBSD Online Document Editor URL:
https://github.com/Wang-Yan-Hao/FreeBSD-Online-Document-Editor
FreeBSD Online Man Page Editor URL:
https://github.com/Wang-Yan-Hao/man_page_editor
Contact: Yan-Hao Wang <bses30074@gmail.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
This report provides a continued overview of the FreeBSD online editor and man
page editor project, outlining recent efforts to enhance the documentation and
manual page editing processes. In order to optimize the project’s structural
integrity, we enlisted the expertise of a professional front-end programmer. We
plan to release the editor soon and currently have some tasks that require
additional support.
1. We are actively seeking a qualified individual to conduct a comprehensive
front-end security review of the project.
2. A meticulous inspection of the JavaScript code is imperative to ensure its
robustness and efficiency. We are looking for someone with expertise to
thoroughly examine the codebase, identify any issues, and propose
enhancements for optimal performance.
3. Since there is currently no existing JavaScript library for rendering
mandoc, I had to create my own. However, there are still some hidden errors
that emerge during the editing process. We are seeking assistance to fix
these rendering issues.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
FreeBSD Wiki
Links:
Wiki URL: https://wiki.freebsd.org
Contact: Wiki administration <wiki-admin@FreeBSD.org>
Plans are underway to familiarize our audience on Discord with the wiki (there
are too many "silos" in our FreeBSD community). Contact Setesh on the FreeBSD
Discord for more information.
Preliminary work is being done on updating the wiki software itself. Continuing
to run MoinMoin requires a jail with a downrev version of Python. The MoinMoin
project itself seems to have stalled in the middle of a redesign; at a minimum,
a complete upgrade of the backend database would be needed.
Alternatives that are under consideration include MediaWiki and DocuWiki; see
https://wiki.freebsd.org/Wiki/NextGeneration. Most of the discussion is
occurring on Matrix; please contact wiki-admin@FreeBSD.org if you would like to
participate.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Ports
Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
KDE on FreeBSD
Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD
Contact: Adriaan de Groot <kde@FreeBSD.org>
The KDE on FreeBSD project packages CMake, Qt, and software from the KDE
Community, for the FreeBSD ports tree. The software includes a full desktop
environment called KDE Plasma (for both X11 and Wayland) and hundreds of
applications that can be used on any FreeBSD machine.
The KDE team is part of desktop@ and x11@, building the software stack to make
FreeBSD beautiful and usable as a daily-driver graphical desktop workstation.
The notes below describe mostly ports for KDE, but also include items that are
important for the entire desktop stack.
Infrastructure
CMake was updated several times and is now version 3.28.1, the latest upstream
release. FreeBSD ports are once again fully up-to-date.
Qt5 is now on long-term support and updates only rarely. The KDE patch
collection is a community-supported branch of Qt which pulls in upstream
patches and fixes from the KDE community, and updated to 5.15.12. There were
several deprecations (see below) in the Qt5 ports.
Qt6 and KDE’s upcoming megarelease of KDE Plasma 6 (scheduled for 2024q1) are
the next major milestone for the KDE team. Qt6 was updated to version 6.6.1
along with the Python bindings for Qt, PySide. An alpha-release of KDE
Frameworks 6 was added to the ports tree.
KDE Stack
KDE Gear releases happen every quarter, KDE Plasma updates once a month, and
KDE Frameworks have a new release every month as well. These (large) updates
land shortly after their upstream release and are not listed separately.
• KDE Frameworks reached version 5.112. The KDE Frameworks 5 series is
winding down, although it will a few months still until it enters long-term
support upstream.
• KDE Plasma Desktop was updated to version KDE Plasma 5.27.10.
• KDE Gear updated to 23.08.4.
• KDE Frameworks 6 (alpha) 5.247 was updated in the ports tree.
• KDE Plasma Desktop 6 (beta 2) 5.91.0 was updated in the ports tree.
Related Ports
The KDE ecosystem includes a wide range of ports — most maintained by kde@, all
building on a shared base of Qt and KDE Frameworks. The KDE team updates them
all as needed. This quarter the KDE team would like to thank Tobias C. Berner,
Gleb Popov and Jason E. Hale again for keeping things up-to-date.
Many ports have been "flavorized" to support a Qt5 and a Qt6 flavor in the
ports tree.
Special mention to:
• New port x11/xwaylandvideobridge. By design, X11 applications can’t access
window or screen contents for Wayland clients. The video bridge improves
Wayland support for screen sharing tools like Discord, MS Teams, Skype, and
more. Screen sharing is fully under the control of the Wayland user.
• Update for multimedia/mlt7 which was updated to 7.20.0.
• Update for sysutils/bsdisks which was updated to 0.33.
• Bugfix for devel/llvm15 to make devel/kdevelop work again.
• Security fixes for www/qt5-webengine and www/qt6-webengine.
Deprecations
Web browsers are huge, and have a considerable security surface. The venerable
www/qt5-webkit WebKit port was removed on the last day of 2023.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
State of GNOME 44
Links:
GNOME URL: https://www.gnome.org/
Development repository URL: https://codeberg.org/olivierd/freebsd-ports-gnome
Contact: FreeBSD GNOME Team <gnome@FreeBSD.org> Contact: Olivier Duchateau <
duchateau.olivier@gmail.com>
GNOME is a full desktop environment which is mainly based on GLib, GTK3/GTK4,
and libadwaita. It provides two window managers or compositors: x11-wm/mutter
and x11-wm/metacity.
Currently in the ports collection, x11/gnome-shell is not supported by upstream
anymore. As it is a lot of work, in order to have GNOME 44 available for users,
I decided to split this update, because it impacts several ports.
As a maintainer of x11/budgie and Pantheon desktop (a window manager based on
x11-wm/mutter, developed for elementary OS) I need more recent versions of some
GNOME libraries.
Firstly I worked on WebKitGTK. The 4.0 "legacy" API is almost not used by
GNOME’s libraries. The bare minimum is the 4.1 API. I created webkit.mk for the
Mk/Uses framework, in order to flavorize www/webkit2-gtk3. There is an ongoing
effort, but currently it is too unstable. Often applications such as Epiphany,
mail clients (Geary, Evolution), or the online accounts panel in
package:sysutils/gnome-control-center dump core.
Nonetheless, remainder of desktop is usable and the latest release (44.7) of
GNOME Shell is functional. I have begun sending my first patches for review (as
well as those in Bugzilla).
• D43183
• D43230
• D43244
• D40489
I have also ported the GNOME Flashback session module. It depends on x11-wm/
metacity and x11-toolkits/libwnck3.
I also maintain a documentation, and we can see various desktops available.
GNOME 45 is almost finished, except for GNOME Shell extensions. For this
release I will focus on Wayland support (bug #258042 and bug #271836).
Tests and patches are welcomed, especially for WebKitGTK.
Next months I plan to work on:
• Allowing selecting a session in display manager (gdm), it is regression
with our patches.
• Fixing sharing network (VNC, SSH) panel in gnome-control-center and
backport for bug #275900.
• Continuing to update applications and libraries for GNOME 45.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
GCC on FreeBSD
Links:
GCC Project URL: https://gcc.gnu.org/
GCC 10 release series URL: https://gcc.gnu.org/gcc-10/
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/
GCC 12 release series URL: https://gcc.gnu.org/gcc-12/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>
Updating GCC default version to 13 is moving ahead. Thanks to Antoine Brodin
who ran the exp-runs and to all other developers and ports maintainers
involved.
As you might remember from last quarter, additional patches were tested
together with the default version updates. Some of them have already been
merged:
• lang/gcc11 has switched back to STANDARD_BOOTSTRAP and has been updated to
11.4.0;
• lang/gcc13 has been updated to version 13.2.0.
About half of the open bugs have been fixed, but another half remains. If you
maintain any of the affected ports, please try to fix your port(s) and/or get
your port buildable with the compiler in base.
This quarter many bug reports have also been opened about GCC. As soon as the
default GCC version update is finished, all of those bugs will be addressed.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Third Party Projects
Many projects build upon FreeBSD or incorporate components of FreeBSD into
their project. As these projects may be of interest to the broader FreeBSD
community, we sometimes include brief updates submitted by these projects in
our quarterly report. The FreeBSD project makes no representation as to the
accuracy or veracity of any claims in these submissions.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
Containers and FreeBSD: Pot, Potluck and Potman
Links:
Pot organization on GitHub URL: https://github.com/bsdpot
Contact: Luca Pizzamiglio (Pot) <pizzamig@FreeBSD.org>
Contact: Bretton Vine (Potluck) <bv@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>
Pot is a jail management tool that also supports orchestration through Nomad.
During this quarter, Pot 0.16.0 was released containing a number of features
and fixes, including a new setting to prevent direct traffic between VNET pots
and new attributes to configure pot stop behavior. There were also maintenance/
stability releases to potnet (0.5.0) and a nomad-pot-driver (0.10.0).
Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a
repository of Pot flavours and complete container images for usage with Pot and
in many cases Nomad.
One of the new container images that have been added during the last quarter is
Zincsearch, a more light-weight alternative to Elasticsearch written in Go.
The Mastodon container is meanwhile powering the public mastodon.africa
instance.
Also, we got some more publicity: BSD Now Episode 536 is titled "Pot-flavored
Jails".
As always, feedback and patches are welcome.
Sponsors: Nikulipe UAB, Honeyguide Group
From nobody Fri Feb 16 19:07: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 4Tc1fN5c3Jz56LTG
for <freebsd-current@mlmmj.nyi.freebsd.org>; Fri, 16 Feb 2024 19:07:56 +0000 (UTC)
(envelope-from Matthew.L.Dailey@dartmouth.edu)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20700.outbound.protection.outlook.com [IPv6:2a01:111:f403:2418::700])
(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 4Tc1fM6btXz4CMT
for <freebsd-current@freebsd.org>; Fri, 16 Feb 2024 19:07:55 +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=fvpaiSB5;
spf=pass (mx1.freebsd.org: domain of Matthew.L.Dailey@dartmouth.edu designates 2a01:111:f403:2418::700 as permitted sender) smtp.mailfrom=Matthew.L.Dailey@dartmouth.edu;
dmarc=pass (policy=none) header.from=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=mKcMzj7uXNPSR6wP3TOBgDIPStuRJdo47UkFqD14oi3jpOMknReEByiqVxkD9AqOhNlETuAMUM+hpll8WmFZhXbzRrN8/WkoVtgubn/KtSFKw3LMyQe55hgf2ClvlW4PvQ38O5h1ca38FE+kxSOcPlrOb3e+l7coD6wkJ+U6ua9hJjCo85M80rQ4dayxSj0OkHhPIqaLa/otKuuYutoRRxCL/eUCNwTUTm0lo02G8eZxlXXsdFxA5NYwwpyEH6BhLtCbbWmOCDzuy3jZi+wtRPdt9cmGoKfUJe4jQn/AggRGnhgNFgZ60o0EHWl8o7wGIwi6Re9VGa8/yybhqknQNA==
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=bV+BVxmVzPpy7fJbB98Qo0REF4fZ7f/24oGmEQt8me0=;
b=T6nZKcoXnRltjx4YsfW9g7F83vpt91Xz8jKkBJPfPTqONTOiBa2i5n3NOjmSLyj5icbDzXKahZXPfVF0xyNS41X/7ezn+fwG16aVpOU+O62orZsT+tEW72cpQ01ztEtP0zjgeOpaZWHMCvrPyD9D19B2ddTHvVE6kowDcJwjVKbgFHkMwBAYH8Xtprc+BnZ1Qq7wzPEfX1ndW7vUV47HUdIjUIY7XsaQFzsxWLcl4oFlY4UpHJ1eWuds2AJLUs9pl4rwcwPqY8Swip71mkspBmWZMGTDvzW7w+kZ61bm0ZORnJHMFaFVWh70JaZYJI82tCwsA8RP3A9xWnnJEYVEHA==
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=bV+BVxmVzPpy7fJbB98Qo0REF4fZ7f/24oGmEQt8me0=;
b=fvpaiSB59S3P5agf7dnM6SkEIiQ91T626pNIZiiAk1prVk0JvzjbuB707/Wt2489b+vaFh1ed5+Vs64Pay4loBB4mZ7tsCN0QpPo5wkaOvAJeBa4HuzQqch/tDHqhAQpyAloEEyjsjTQgoS4Bs5cCg5iS7jPSiCEIAkOGbONYhg=
Received: from DS7PR03MB5574.namprd03.prod.outlook.com (2603:10b6:5:2c1::16)
by BN8PR03MB5026.namprd03.prod.outlook.com (2603:10b6:408:d6::15) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.31; Fri, 16 Feb
2024 19:07:53 +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.7292.029; Fri, 16 Feb 2024
19:07:53 +0000
From: "Matthew L. Dailey" <Matthew.L.Dailey@dartmouth.edu>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject: Re: FreeBSD panics possibly caused by nfs clients
Thread-Topic: FreeBSD panics possibly caused by nfs clients
Thread-Index: AQHaYQtwEy3CkCGt90qW8Bq/tEdG3g==
Date: Fri, 16 Feb 2024 19:07:52 +0000
Message-ID: <53139ffd-3e42-4aaf-a523-b8f4dc8b29a9@dartmouth.edu>
References: <c5d44484-8660-4b8b-a379-79423cb208f6@dartmouth.edu>
<ZcZNDtN1nNJmo8cS@nuc> <c9eca81a-9eff-4b17-9928-bee2c79cef8f@dartmouth.edu>
<b3243928-4d66-4c5e-9745-254d57f1cc5e@dartmouth.edu> <ZcaWkUwMlBCZCUhg@nuc>
<3ea6d241-b9cc-4294-aef8-ae1c6d9d8161@dartmouth.edu> <ZcanttlCzNFvMM7S@nuc>
In-Reply-To: <ZcanttlCzNFvMM7S@nuc>
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_|BN8PR03MB5026:EE_
x-ms-office365-filtering-correlation-id: 593fd96d-068d-4262-0c8b-08dc2f229384
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
ZnvLUMEBe+ZRiz0P93iwloiFCzT2/pExyCdaji66/0LINqmbnnW8vPivPxC/eKBoBbFtnGPsakkQ69fUU+LQm7dHilw2HCvjN/RhlRl/i9QndmohIwijKS4m+nS0XsB+jQQNDFZCOjdOJePsb0L0NWLiOPSeewCxiAFRJdUUdhdm1ocJEUgRb3W9rlLvjaQC9RRl1F7uNOjPZVNPfvHvaw1cU48BCotR8yo7BugLWJx+d++z40RsNpxuVq7uHnULpKBcks//e7IIAS+pWR+/ANv7HHLxkeSfgF0KubCMnD03L+7HadeRJJ47kxKEp0RH1unI857ApVeoouRIcTAH0epYe7bCisCkldUjxznDQjiqbpXgRWRrqJA1cyrNCmMjSsvZystTbx4Y7VorCHesMM7mUD4cGGs8KYl8BS/V/5ox4XzVCunawun0LCq3RugiMpID/AF80RSV37WM97gjHm/Y6c6oIiHr1eWuhHzqfbUvR7c8mzL8yQv/kMZy3/v6bdQnTGbF3pEs2xoUSACytmYSIZp1i7HWt3BM6GVBGNrwV7Gr4l/y9VdsxDLjLoEXXExaET5GCm5EvAzOKmcyIKVfDSh0Bh+F0vgSu30pZlKZ0qB9jw82KOL26ez2koI3
x-forefront-antispam-report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR03MB5574.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(136003)(396003)(39860400002)(346002)(376002)(230922051799003)(186009)(1800799012)(451199024)(64100799003)(86362001)(31696002)(31686004)(75432002)(71200400001)(786003)(36756003)(316002)(38100700002)(122000001)(91956017)(38070700009)(2906002)(66476007)(66556008)(5660300002)(64756008)(8676002)(6916009)(8936002)(66946007)(66446008)(76116006)(2616005)(6512007)(6486002)(6506007)(83380400001)(478600001)(26005)(41300700001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
=?utf-8?B?bVVkaFUwbDR6QUdxM01aK2hZbTUrRjhjeFBOVlpYVG5zbVFCMTR5bTBEcm9C?=
=?utf-8?B?THdZZGlVSFlXZHBSaGdxT0pScDhDZzMrbXFpYisxZE5iaVdBajVaVkUyQWFN?=
=?utf-8?B?VFRJczI5MkJqdEVCc2tjTnFGekI0NW9tVFJIZEpLQTJhdE9qOGpLQjA2ZHdz?=
=?utf-8?B?QS8zZm5aZDFkZklMOVpOSWY0bVJ5SHBCQnpBd3hNTlFoeEVkVTZ5UThRWEJW?=
=?utf-8?B?eUFvN1Z4QXRSeHNHZldJWm40V2VYT3E4cEt4RmJ5cmJnanNlSU9DNkUyQVB2?=
=?utf-8?B?c055TnEzSzF5SzZacnZEckV4ZzladjFkRmhOUm5rWWFmdmhFay9SM012VUE4?=
=?utf-8?B?SThjVHJ5ZGlIVEpFQzlpVkdnbTdBMlE4Tms1T3ppUzRYdlB2ZXZjUERrWFFC?=
=?utf-8?B?N2JKaHMzTkgzVkZHQjZMWHp1c3NmZmg2YUlFSkFpZFlwaUJTOENSbDMrSkVU?=
=?utf-8?B?YUJBZWRaNHRvWCswYjlRNHp5SU50c1B3SEgxMThJRXlZZUFHRGlpNFZxRENY?=
=?utf-8?B?U2FaTy95cXdXVUhpZFV6WHNuRmlkZ2sxMjMzMzRUdktjNzRzM0k5T1pKdUpN?=
=?utf-8?B?dTNoazNkV0RBQjBhWVdkeDlndnk3dDc5YmJxMlQzSUpSclU2Z0RDOG96K2Uy?=
=?utf-8?B?cDg4ZEVNdWNRdTNEVkxyNnNYM3RoR1VtK1VuV25LbjNwT1RmcFpDSXdLWnd4?=
=?utf-8?B?aThjVmVEdk1MYWQ1ejBJZGJ5R3F3YUxTTTd1QWZGc0xyTUVDdS9UYWpIWHVF?=
=?utf-8?B?TVI2eTd5Y3VYRENFWmJwQWJVY1Y1OHQzMXJ0Z2VjclQ1N1llZHpOWUswU2M2?=
=?utf-8?B?aW9jLzA3NGlZcElmM0ZEQVBzVkc0SEYvV2V0QURVVFJJZnlpWUNtcDlUV2xk?=
=?utf-8?B?dTN5YW5leEhPUDd0N0FkSW9YRzFBWk14a3ZxbCt4L053YUo0UXJwN2RGdmNM?=
=?utf-8?B?NlQ4eXVmcUhIZGVFL0ZPR082TlJZTjcyZU1NajFiaDhMZHoySHdCakE5Ym1y?=
=?utf-8?B?RkFWVzQ4QWN2WmVjTlFOOW9paEt5NFhHNWU4NFJtK2ZIM2ZZRlJ3dWkvN1ky?=
=?utf-8?B?bzY0dW9qR1Njc0RHMm93cVBSWGR5dnBHSzFTWUF5czBvQk03cnR4ZjgyazVu?=
=?utf-8?B?WnNXbXNjMUhyZk1mSVRDcEI0WWthVnp3Y3RCM0V2bjJUMngwbHo4YkdidmVp?=
=?utf-8?B?ZDN6Z2FNY3A0cFdJR3MwZi8wVG90UHFTaXBHb0s2alhhekM2Tll4RFpKZmtR?=
=?utf-8?B?Yk5xeXdIRkNtcm5IaDkvYmxFWmdnbFpuQVY2aUJIQjJLUkpXbEVQcVNvYnlH?=
=?utf-8?B?a3M5SjVSQmZla29FYUw5Umx1bmZjS2RGVTJxZk1hZUJMSy92Smp5aUxzUENw?=
=?utf-8?B?THFaNzZMeXZBQlRDL2Q0NkljcnlEZmdndXpqMDBlSXU3ejBvRjdZUjZWZnJP?=
=?utf-8?B?SndycGUwRFRiSkhPVWV6SitaZDNkWTcrQkV3TmQrclc3aVZFVkl1eGR5NjNh?=
=?utf-8?B?aVJnSWxnc3hHNVVhSUxLSWFpMjlWZjk5blZJMEkzZmVZNXBMbmlCVURDOXhi?=
=?utf-8?B?YmJiT0VUblpxRlFsTXM0MHJEVDJYRFU0Q0pFSmpYUmg3eVJ5bnF6MGdqREZR?=
=?utf-8?B?OWJHemJzNCtlc0hpalRSM1hVTnh2YllVMlFiSDBlb2pZa0RCeERMT3F2WGRV?=
=?utf-8?B?dVB2SklUajY4Yk5FWHd1c1RGR1F4Sk1CdGoza3pRVVlBZnM4MW05clFLYy9B?=
=?utf-8?B?OWl3U2wxN3lRSnNHdUxSVWtySUJlS21mclJqZERURnZJNnQzeEZKU0RId2t3?=
=?utf-8?B?QWlBV1B0SU92KzVMRGM4aklGS1JLOTBMWUppMkRVTi9jUDlrZVNHc1BqTlZm?=
=?utf-8?B?a0F5VEVwTEhlV2dEUEp3NjZXTE84eC95aHZGYlpvWWJVUG1qOXk5UDZXR0lw?=
=?utf-8?B?djAyYVlURXZlMTVOMUdZeVFaek1lUGx5Y3VYVzdEeU9sSW40TFdqUTBkMUtE?=
=?utf-8?B?aEJMM3pHbTRmcEdybmxCbG9XdFhBUlZtWXhkUk9PeUpRcndZdUpCTVpwbTBn?=
=?utf-8?B?SVhoSXNwbnhNQjBxQkd3MjVsdFlVa1R2c0pCb3RFYktsT3Y1Z1J6b1psOW1B?=
=?utf-8?Q?JQaPaWDFoyymfdlpYCYhJ0aNk?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0014D733D4A84C469F8C1BF14B735923@namprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: 593fd96d-068d-4262-0c8b-08dc2f229384
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2024 19:07:52.9812
(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: 7sPqC7m6VkvQEHDQs/zWZF2P2HsIAnBFH5hAUoe7u3hG2cNrpfaE9dP0vWvkij9cvNFRfqqNyN2rAd+gfOWf+Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB5026
X-Rspamd-Queue-Id: 4Tc1fM6btXz4CMT
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.86 / 15.00];
DWL_DNSWL_LOW(-1.00)[dartmouth.edu:dkim];
NEURAL_HAM_LONG(-1.00)[-1.000];
MIME_BASE64_TEXT_BOGUS(1.00)[];
ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.97)[-0.969];
DMARC_POLICY_ALLOW(-0.50)[dartmouth.edu,none];
R_DKIM_ALLOW(-0.20)[dartmouth.edu:s=selector2];
R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f403::/49];
MIME_BASE64_TEXT(0.10)[];
MIME_GOOD(-0.10)[text/plain];
XM_UA_NO_VERSION(0.01)[];
RCPT_COUNT_ONE(0.00)[1];
MIME_TRACE(0.00)[0:+];
ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
RCVD_IN_DNSWL_NONE(0.00)[2a01:111:f403:2418::700:from];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
MID_RHS_MATCH_FROM(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
TO_MATCH_ENVRCPT_ALL(0.00)[];
TO_DN_EQ_ADDR_ALL(0.00)[];
RCVD_TLS_LAST(0.00)[];
DKIM_TRACE(0.00)[dartmouth.edu:+]
SGkgYWxsLA0KDQpCZWZvcmUgdGhlIHdlZWsgd2FzIG91dCwgSSB3YW50ZWQgdG8gcHJvdmlkZSBh
biB1cGRhdGUgb24gdGhpcyBpc3N1ZS4NCg0KTGFzdCB3ZWVrZW5kLCBJIGluc3RhbGxlZCB0d28g
Vk1zIHdpdGggQ1VSUkVOVA0KKDIwMjQwMjA4LTgyYmViYzc5MzY1OC0yNjgxMDUpIC0gb25lIG9u
IHpmcyBhbmQgb25lIG9uIHVmcyAtIGFuZCBidWlsdCBhIA0Ka2VybmVsIHdpdGggdGhpcyBjb25m
aWcgZmlsZToNCmluY2x1ZGUgR0VORVJJQw0KaWRlbnQgICBUSEFZRVItRlVMTERFQlVHDQptYWtl
b3B0aW9ucyAgICAgREVCVUc9LWcNCm9wdGlvbnMgS0FTQU4NCm9wdGlvbnMgRERCDQpvcHRpb25z
IElOVkFSSUFOVF9TVVBQT1JUDQpvcHRpb25zIElOVkFSSUFOVFMNCm9wdGlvbnMgUVVFVUVfTUFD
Uk9fREVCVUdfVFJBU0gNCm9wdGlvbnMgV0lUTkVTUw0Kb3B0aW9ucyBXSVRORVNTX1NLSVBTUElO
DQpvcHRpb25zIEtHU1NBUEkNCg0KSSdtIGFsc28gc2V0dGluZyB0aGVzZSBpbiBsb2FkZXIuY29u
ZjoNCmRlYnVnLndpdG5lc3Mud2F0Y2g9MQ0KZGVidWcud2l0bmVzcy5rZGI9MQ0Ka2Vybi5rc3Rh
Y2tfcGFnZXM9OA0KDQpUaGVzZSB0d28gVk1zIGhhdmUgYmVlbiBydW5uaW5nIG5vbi1zdG9wIHdp
dGggb3VyIGhkZjUgd29ya2xvYWQgd2l0aG91dCANCmEgcGFuaWMgZm9yIDE0NiBob3VycyBhbmQg
MTIyIGhvdXJzLCByZXNwZWN0aXZlbHkuIFRoaXMgbWlnaHQgYmUgZ29vZCANCm5ld3MsIGJ1dCBp
cyB3ZWxsIHdpdGhpbiB0aGUgdGhyZXNob2xkIHdlJ3ZlIHNlZW4gaW4gb3VyIHRlc3Rpbmcgb3Zl
ciANCnRoZSBwYXN0IDYgbW9udGhzLiBHaXZlbiB0aGF0IGFsbCB0aGUgZGVidWcga2VybmVsIG9w
dGlvbnMgc2xvdyB0aGluZ3MgDQpkb3duIHNpZ25pZmljYW50bHksIHRoZXNlIGNvdWxkIGp1c3Qg
YmUgdGFraW5nIGEgbG9uZyB3aGlsZSB0byBwYW5pYy4NCg0KSSBhbHNvIGhhdmUgYSBhbm90aGVy
IFZNIHdpdGggb3VyICJzdGFuZGFyZCIgMTQuMHA1IGtlcm5lbCAoR0VORVJJQyB3aXRoIA0KS0dT
U0FQSSBlbmFibGVkKSBydW5uaW5nIG9uIHVmcyB0byB0cnkgdG8gcnVsZSBpbiBvciBvdXQgemZz
LiBUaGlzIA0KZmFpbGVkIHRoaXMgbW9ybmluZywgYnV0IG5vdCB3aXRoIGEgcGFuaWMuIEluIHRo
aXMgY2FzZSwgbmZzIHN0b3BwZWQgDQpyZXNwb25kaW5nLiBUaGlzIGlzIGEgZmFpbHVyZSBtb2Rl
IHdlIGhhdmUgc2VlbiBpbiBvdXIgdGVzdGluZywgYnV0IGlzIA0KbXVjaCByYXJlciB0aGFuIGEg
ZnVsbCBwYW5pYy4gSSBpbnRlbmQgdG8gY29udGludWUgdGVzdGluZyB0aGlzIHRvIHRyeSANCnRv
IGluZHVjZSBhIHBhbmljLCBhdCB3aGljaCBwb2ludCBJIHRoaW5rIHdlIGNhbiBydWxlIG91dCB6
ZnMgYXMgYSANCnBvdGVudGlhbCBjYXVzZS4NCg0KSnVzdCBzbyBpdCdzIGRvY3VtZW50ZWQsIHNp
bmNlIEkgc3RhcnRlZCBleHBlcmltZW50aW5nIHdpdGgga2VybmVsIGRlYnVnIA0Kb3B0aW9ucyBs
YXN0IHdlZWssIEkgaGF2ZSBzbyBmYXIgaW5kdWNlZCBwYW5pY3Mgd2l0aCB0aGUgZm9sbG93aW5n
Og0KLSAxMy4ycDkga2VybmVsIG9uIGhhcmR3YXJlIChvbmx5IFdJVE5FU1MgZW5hYmxlZCkNCi0g
MTQuMHA0IGtlcm5lbCBvbiBWTSAob25seSBLQVNBTiBlbmFibGVkKQ0KLSAxMy4ycDkga2VybmVs
IG9uIGhhcmR3YXJlIChhbGwgZGVidWcgb3B0aW9ucyBhYm92ZSBleGNlcHQgS0FTQU4pDQoNCk15
IHBsYW4gcmlnaHQgbm93IGlzIHRvIGNvbnRpbnVlIHJ1bm5pbmcgbXkgdHdvIHRlc3QgVk1zIHdp
dGggQ1VSUkVOVCB0byANCnNlZSBpZiBpdCdzIGp1c3QgdGFraW5nIGEgbG9uZyB0aW1lIHRvIHBh
bmljLiBPbmNlIEkgaGF2ZSBmaW5pc2hlZCBteSANCnVmcyB0ZXN0aW5nIG9uIHRoZSB0aGlyZCBW
TSwgSSB3aWxsIGJ1aWxkIGEgR0VORVJJQyBrZXJuZWwgZm9yIENVUlJFTlQgDQoobm8gZGVidWcg
b3B0aW9ucywgb25seSBLR1NTQVBJKSBhbmQgdGVzdCBhZ2FpbnN0IHRoYXQgdG8gc2VlIGlmIHRo
ZSANCmFjdHVhbCBkZWJ1ZyBpbnN0cnVtZW50YXRpb24gaXMgaW50ZXJmZXJpbmcgd2l0aCByZXBy
b2R1Y2luZyB0aGlzIGlzc3VlLg0KDQpQbGVhc2UgcmVhY2ggb3V0IGlmIHlvdSBoYXZlIGlkZWFz
IG9yIHN1Z2dlc3Rpb25zLiBJJ2xsIHByb3ZpZGUgdXBkYXRlcyANCmhlcmUgd2hlbiBJIGhhdmUg
dGhlbS4NCg0KVGhhbmtzLA0KTWF0dA0K
From nobody Fri Feb 16 23:53:33 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 4Tc8036GQbz5B3dP
for <freebsd-current@mlmmj.nyi.freebsd.org>; Fri, 16 Feb 2024 23:53:39 +0000 (UTC)
(envelope-from void@f-m.fm)
Received: from wfhigh4-smtp.messagingengine.com (wfhigh4-smtp.messagingengine.com [64.147.123.155])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4Tc8024Xq0z4mPx
for <freebsd-current@freebsd.org>; Fri, 16 Feb 2024 23:53:38 +0000 (UTC)
(envelope-from void@f-m.fm)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=f-m.fm header.s=fm1 header.b=mVejkwdv;
dkim=pass header.d=messagingengine.com header.s=fm1 header.b=EZX0RDtT;
spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.155 as permitted sender) smtp.mailfrom=void@f-m.fm;
dmarc=pass (policy=none) header.from=f-m.fm
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailfhigh.west.internal (Postfix) with ESMTP id 494251800083
for <freebsd-current@freebsd.org>; Fri, 16 Feb 2024 18:53:36 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Fri, 16 Feb 2024 18:53:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
:content-type:content-type:date:date:from:from:in-reply-to
:message-id:mime-version:reply-to:subject:subject:to:to; s=fm1;
t=1708127615; x=1708214015; bh=zrrkKp0eLSgN5jXD/5eQd0l83i4py/dI
Nh5iIzejY24=; b=mVejkwdvNGCTDfjJTZl6aJRuYO6SesjEuXXYVpWfL4A1EGtz
r3rFxQDNjB7iVGEO9CABBpmDTpA1OKhNd3EAX6g+ornB4BKZq0jHnRrpjRByWOMF
DVDn0UbJ3o2OwHTcD3p2BDH/qyhKbJ35CP3qZdIrkLDuvEDLKrkT7YY1KJV53GZ7
tAGTLyrEZkF9rnt4ACjsfExgDOUf+NzCscddhd7Cm/wrvL9HeNKVZWYv++g0TnrU
2YmmuJ0pA/vusRPKJk62YYOHLw94mR0pZxMB7djSmUJp7LzTRLmBrmnoeatHG78l
7DNe54vd9A4Tn7UxkuxgljhUdNdwyfb+OvlIbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:message-id
:mime-version:reply-to:subject:subject:to:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1708127615; x=1708214015; bh=zrrkKp0eLSgN5jXD/5eQd0l83i4py/dINh5
iIzejY24=; b=EZX0RDtTxOncFad8J32cBo54mEcADBPH119OSgsPrX9w2IUlooi
v4ew0VdLNaeCf69iGzRkb2pwCDEya7htwCeyoYw9v99lP5pPdSJkrBLWTUiypqXH
p561HjFEmyPqCKu4/HXQuzn1FLkZuHxoWzHAth3NQvjALvYhZz/jxdHfm5HUp5Za
QhkLvB75LakwYOckK5hWqASWyEP0ZfQ151WIJg14E9B78QfM8BZ/4TQlDyj8+6qq
r/pN23kFN2xvb8gwGKjJDrK73FmlmzG9U/PxNHkkjn/zXn65vK77sJELUBZZLEy+
AapoPteOmY/g8VuksCoydxPox+hAD/Zfb3Q==
X-ME-Sender: <xms:f_XPZZFCUUHeyZ01neJwEMXBph6VrUmtu7zdrc48WOFukQUneafDRQ>
<xme:f_XPZeW5CTXU-hrVdLwzoa4dkBZ-rjRIRlXsWQHVPt6Yf5hIZ2X8XqWFuBxM5aKu_
yjN_wmmHHo_OqLwrg>
X-ME-Received: <xmr:f_XPZbI8pD4sMlboHotp3C2e0J0Eus0pqBkUJ5qTwwxDhsdfcNDzEu6tA1PwBZgKzYQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdefgdduhecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd
dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv
rhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehgeffue
enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi
ugesfhdqmhdrfhhm
X-ME-Proxy: <xmx:f_XPZfEvcc_RtMTWRDDTWYjCztq1zizKX7X97gl_N7tizZKxbezPZg>
<xmx:f_XPZfWzs3CgL0taCalbxatw1ZHVPx9-tCZgPyhAzXtarRQN0Msy_g>
<xmx:f_XPZaNZ9EzbWwyWPIjR2zUCwY1CWHo1IC1bFXZjgBdvTOpoEAue9w>
<xmx:f_XPZWfoicLgMC_Zl_TE1lyAqiiTmdH9L_7MoTTL17Rd_MP-IEP8JHg5wJU>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Fri, 16 Feb 2024 18:53:35 -0500 (EST)
Date: Fri, 16 Feb 2024 23:53:33 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: new tls-cert-store and cert-bundle methods
Message-ID: <Zc_1fZGq3qoxSeko@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
X-Rspamd-Queue-Id: 4Tc8024Xq0z4mPx
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.92 / 15.00];
DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
MID_RHS_NOT_FQDN(0.50)[];
NEURAL_HAM_SHORT(-0.32)[-0.315];
R_SPF_ALLOW(-0.20)[+ip4:64.147.123.128/27];
R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1];
MIME_GOOD(-0.10)[text/plain];
RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.155:from];
RCVD_COUNT_THREE(0.00)[3];
TO_MATCH_ENVRCPT_ALL(0.00)[];
ARC_NA(0.00)[];
RCVD_TLS_LAST(0.00)[];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_ONE(0.00)[1];
FROM_HAS_DN(0.00)[];
FREEMAIL_FROM(0.00)[f-m.fm];
PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
TO_DN_NONE(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
RCVD_VIA_SMTP_AUTH(0.00)[];
MISSING_XM_UA(0.00)[];
FREEMAIL_ENVFROM(0.00)[f-m.fm]
Hello,
Now that we have system tls-cert-store, if one needs to reference
a tls-cert-bundle like provided by ca_root_nss, do we need
to concatenate all of the certs listed in /usr/share/certs/trusted
into, for example cert.pem then symlink /etc/ssl/cert.pem to
that concatenated file?
thanks in advance for any help/pointers/links
--
From nobody Sat Feb 17 00:02:16 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 4Tc8BC0QX6z5B4RL
for <current@mlmmj.nyi.freebsd.org>; Sat, 17 Feb 2024 00:02:27 +0000 (UTC)
(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 4Tc8B95XCRz4p4P
for <current@freebsd.org>; Sat, 17 Feb 2024 00:02:25 +0000 (UTC)
(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
dkim=none;
spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net;
dmarc=none
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.sbone.de (Postfix) with ESMTPS id 294BB8D4A15D
for <current@freebsd.org>; Sat, 17 Feb 2024 00:02:18 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
(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)
(No client certificate requested)
by mail.sbone.de (Postfix) with ESMTPS id 9B2A82D029D7
for <current@freebsd.org>; Sat, 17 Feb 2024 00:02:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
with ESMTP id 2Dus3pPgUM3n for <current@freebsd.org>;
Sat, 17 Feb 2024 00:02:16 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
(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)
(No client certificate requested)
by mail.sbone.de (Postfix) with ESMTPSA id C01D12D029D2
for <current@freebsd.org>; Sat, 17 Feb 2024 00:02:16 +0000 (UTC)
Date: Sat, 17 Feb 2024 00:02:16 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To: current@freebsd.org
Subject: install: /usr/libexec/kgdb exists but is not a directory
Message-ID: <o1pon055-nnor-2opq-ns13-46802o364445@yvfgf.mnoonqbm.arg>
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Rspamd-Queue-Id: 4Tc8B95XCRz4p4P
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.99 / 15.00];
NEURAL_HAM_LONG(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_SHORT(-0.69)[-0.694];
R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
MIME_GOOD(-0.10)[text/plain];
FROM_HAS_DN(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
MISSING_XM_UA(0.00)[];
ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
MIME_TRACE(0.00)[0:+];
R_DKIM_NA(0.00)[];
MLMMJ_DEST(0.00)[current@freebsd.org];
DMARC_NA(0.00)[zabbadoz.net];
TO_DN_NONE(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
RCVD_COUNT_THREE(0.00)[4];
TO_MATCH_ENVRCPT_ALL(0.00)[];
RCVD_TLS_LAST(0.00)[];
PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
ARC_NA(0.00)[]
Hi,
probably related to the 20201215 UPDATING note:
during an update from last year's main to now I hit the following error:
install: /usr/libexec/kgdb exists but is not a directory
Which is true as the old binary was still lingering around.
-r-xr-xr-x 1 root wheel 2833328 11 Aug. 2020 /usr/libexec/kgdb
UPDATING should probably include that delete-old needs to be run at some
point or the binary needs to be removed manually?
/bz
--
Bjoern A. Zeeb r15:7
From nobody Sat Feb 17 11:15:30 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 4TcR6r0ps2z5B6Kx
for <current@mlmmj.nyi.freebsd.org>; Sat, 17 Feb 2024 11:15:32 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TcR6r0BMqz45DT;
Sat, 17 Feb 2024 11:15:32 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1708168532;
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=989BO4SHfqtCY3/5ykPQwqosR3zIEtcFN8RDe1/3+qU=;
b=c4O7nljnfT7ACdvMTL82tZJZLjK+bA44P3lRQCQwo4tFMveTs1JkUZBN/kVIO4PD40FGqp
yqLGOxoxtndhAxxbwgfgB2ksWpMx9JeqSwQUnvyjkCiV9c5gbQt+RZ5Bp7rN2GqBDJnqAO
Z4z/r137A4L4SqEqVrVwtFlJ8GGP22OoTRD5HKRXJoxTQqAtSrJx6dr1xdaJwvdLtdLktZ
5coVamxasfCv4X2WB3MMsDHf+389IE6HbA7A6XFL9k8VRtebnH5zVRNTwotju7lDxjzkYf
h7HFjPN0Cfm3g0Fg6RINsIUNv9By+YHxuVp0jnTfULiM22cys/otWKkxRM2EYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
s=dkim; t=1708168532;
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=989BO4SHfqtCY3/5ykPQwqosR3zIEtcFN8RDe1/3+qU=;
b=X3kAm34paGYP61UaM48RhIiQ3lT8da0LhCAl22c8pO+jYBN0p2oNbDL0hyx74ZSqqMxpHj
SbeihPDo3zzOs4msNBQKg+2Mhl4UJ/jNBazHqtwhFsbK4Ow09w8JSjOtDantekI7a3N3Hx
ZxWBOvcTEPffq5rjgVByQLWUHdowuB4EwFZr13b01RAr0M2u0f5AA0XWanxpujCEg9RESf
kRofP6Gtmdti5HuOC5YkGuho+gX3E4ohhrrck/+s/HPyVbzBNW/+A6EhfmCSWdZiYQak6S
i0IEkRD/MqheQcXYXlR3M/tk0stTl0w1Wh7WrKa9LRBjelYdJqdi+WyERQVmIQ==
ARC-Authentication-Results: i=1;
mx1.freebsd.org;
none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708168532; a=rsa-sha256; cv=none;
b=VZKs1zR/1GKiOuoCQoVNOc3THJ2MLukXBvk6d6Io2xDfcGnpnrbhauoPyMyIN4JOkAwUnT
wNcacBWQv64RqpCeEPwd2FszX0jVcO+bTVSNU3mioUUIbNhzHPXHHvmk/92Vj2sncRTcZN
A/ff8iBdewm0LHLW84UBXB84eeSJN1tj4WIkF5r8QX1VllBZWhZUyV2yxrbi+6foglRFaZ
KFktCHRdOg9ZyFW1RRXjl6yVlTzOUidod5DFeM1mJvrOiWzGP0DgpGYX7+U1flfAJswtgf
mPdPfYMbWLikiTGE1hvqJUxaAE7xvrXiEGw8jP6f3HlAvGXJqGhCmkxTZ06QkA==
Received: from tensor.andric.com (tensor.andric.com [87.251.56.140])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "tensor.andric.com", Issuer "R3" (verified OK))
(Authenticated sender: dim)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TcR6q5cPmz10q9;
Sat, 17 Feb 2024 11:15:31 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by tensor.andric.com (Postfix) with ESMTPSA id 53CC56944F;
Sat, 17 Feb 2024 12:15:30 +0100 (CET)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: install: /usr/libexec/kgdb exists but is not a directory
From: Dimitry Andric <dim@FreeBSD.org>
In-Reply-To: <o1pon055-nnor-2opq-ns13-46802o364445@yvfgf.mnoonqbm.arg>
Date: Sat, 17 Feb 2024 12:15:30 +0100
Cc: current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <687DC3BC-64FF-4619-93AB-E760FAF5F0CF@FreeBSD.org>
References: <o1pon055-nnor-2opq-ns13-46802o364445@yvfgf.mnoonqbm.arg>
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
On 17 Feb 2024, at 01:02, Bjoern A. Zeeb =
<bzeeb-lists@lists.zabbadoz.net> wrote:
>=20
>=20
> probably related to the 20201215 UPDATING note:
>=20
> during an update from last year's main to now I hit the following =
error:
>=20
> install: /usr/libexec/kgdb exists but is not a directory
>=20
> Which is true as the old binary was still lingering around.
>=20
> -r-xr-xr-x 1 root wheel 2833328 11 Aug. 2020 /usr/libexec/kgdb
>=20
>=20
> UPDATING should probably include that delete-old needs to be run at =
some
> point or the binary needs to be removed manually?
https://cgit.freebsd.org/src/commit/?id=3D1c0ea326aa6d3 (2020-12-15) =
removed the files, https://cgit.freebsd.org/src/commit/?id=3D2524b7dfb0df7=
(2024-01-15) added the directory, so that is a window of 4 years!
That said, it could probably use a workaround like we do for some libc++ =
files-that-became-directories, in etc/Makefile:
diff --git a/etc/Makefile b/etc/Makefile
index 745ca91c60bf..229d9380901d 100644
--- a/etc/Makefile
+++ b/etc/Makefile
@@ -126,6 +126,7 @@ MTREES+=3D ../${mtree} /
# scenario.
DISTRIB_CLEANUP_FILES+=3D ${INCLUDEDIR}/c++/v1/__string
DISTRIB_CLEANUP_FILES+=3D ${INCLUDEDIR}/c++/v1/__tuple
+DISTRIB_CLEANUP_FILES+=3D ${LIBEXECDIR}/kgdb
distrib-cleanup: .PHONY
for file in ${DISTRIB_CLEANUP_FILES}; do \
if [ -f ${DESTDIR}/$${file} ]; then \
-Dimitry
From nobody Sat Feb 17 11:33:04 2024
X-Original-To: current@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TcRW622m6z5B8cD
for <current@mlmmj.nyi.freebsd.org>; Sat, 17 Feb 2024 11:33:06 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (4096 bits) client-digest SHA256)
(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4TcRW61XNhz486T;
Sat, 17 Feb 2024 11:33:06 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
t=1708169586;
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=u/ZnfAVKWGruBDaLu/yGJezcfsDjoO57n+UVjoa4cpE=;
b=DUwJ73oVpWn4HR/Wnyec62+Y3t0qQwkA3imTWsdB+nrAQwLruOte75kAxHwWEOpXeEC8aq
wjZ0Nws75lSkNKwZ52edtzqbcugWI89wg7IzGjRW2NlxYJVjH9gPKyduZ1hqY+RrCNXgUM
W2ViQrTHa3XkAtlWcaa1dsBg209+tWXDo2rHlRhZgflCzk4KCvd6lkn7VDjiQnijN7rC/w
4Z7ExTvFtXZ8UWFahAe0ODdD6X/Nez6ryiPeDJC9Eo0XqRKvh3yn7Dze9GWOWj9knn0ixZ
DDaDQ1X8OHgkuyprCVhtMlrJKRtD8TJb8skNVTmMDq9mVfNDdCenBZDynXGZDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
s=dkim; t=1708169586;
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=u/ZnfAVKWGruBDaLu/yGJezcfsDjoO57n+UVjoa4cpE=;
b=Dh1WWNhd3s+jGIVq1GehWexgO5HDCu/ZE1bBmFhH+SOxg62Ud+Yj0/GII9NBq1q2oyOyUJ
Xlp6HS2gz951wKEF5wmsSBkyiJOefrvWIUO8mvQBgnhgB85ruHYhoyAQkB1K2UokPjh0Ts
k8ZxMPcGgB6tyFtNEaCA2MWIngYgCpQeekWD5iugXXXKN1fz1vvuEQwDyFh/00SFh6lu5m
4FMu7SuMoQ6OBScPePcEnkR7ZG0n8ATn8uw5rreTnOrZ1k9UiHLFg63oBEZe9kFHnfgP1z
1r57Hthbj+VsoqcyWCiu4vwnyY4NSuwyc5FmydtaIYJAqXOLh0knpfp0oZWxZw==
ARC-Authentication-Results: i=1;
mx1.freebsd.org;
none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708169586; a=rsa-sha256; cv=none;
b=NYfBDIvCK4HNDxgmtulJ8+u5B/XEllW3EaWYlfYAwTHbJ611OjAQu6DyQxyZpSYlLenF0y
x3Iv8piREPCPwst9516AcrU13TDH4cqWP+DtQFbsqTNGoyHT3knhHf3CaRg5nipMojh8/P
WicduVOix3TRBlJtpGyM3hVcCHlCVZpZqhvapIpkJ/ScpGvUzkNEl2m4SEWcVAkVvRwb10
/FgSKG5mTj4G/toQovj0QmuDztY/uMx0AMTrRzV/kmLskHT3eYWueYSyGhyRs/gedQFXqA
oDN8JTEEdmUsILv5vMufjcEq2LFfUhucmzbdtrlpfTXS45JEMr9a8C3OpmQh1g==
Received: from tensor.andric.com (tensor.andric.com [87.251.56.140])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "tensor.andric.com", Issuer "R3" (verified OK))
(Authenticated sender: dim)
by smtp.freebsd.org (Postfix) with ESMTPSA id 4TcRW601NXz10fb;
Sat, 17 Feb 2024 11:33:05 +0000 (UTC)
(envelope-from dim@FreeBSD.org)
Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by tensor.andric.com (Postfix) with ESMTPSA id E2ADC69535;
Sat, 17 Feb 2024 12:33:04 +0100 (CET)
Content-Type: text/plain;
charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: install: /usr/libexec/kgdb exists but is not a directory
From: Dimitry Andric <dim@FreeBSD.org>
In-Reply-To: <687DC3BC-64FF-4619-93AB-E760FAF5F0CF@FreeBSD.org>
Date: Sat, 17 Feb 2024 12:33:04 +0100
Cc: current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EC5B88B-133D-4BE9-B982-A4859B7DAB04@FreeBSD.org>
References: <o1pon055-nnor-2opq-ns13-46802o364445@yvfgf.mnoonqbm.arg>
<687DC3BC-64FF-4619-93AB-E760FAF5F0CF@FreeBSD.org>
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
On 17 Feb 2024, at 12:15, Dimitry Andric <dim@FreeBSD.org> wrote:
>=20
> On 17 Feb 2024, at 01:02, Bjoern A. Zeeb =
<bzeeb-lists@lists.zabbadoz.net> wrote:
>>=20
>>=20
>> probably related to the 20201215 UPDATING note:
>>=20
>> during an update from last year's main to now I hit the following =
error:
>>=20
>> install: /usr/libexec/kgdb exists but is not a directory
>>=20
>> Which is true as the old binary was still lingering around.
>>=20
>> -r-xr-xr-x 1 root wheel 2833328 11 Aug. 2020 /usr/libexec/kgdb
>>=20
>>=20
>> UPDATING should probably include that delete-old needs to be run at =
some
>> point or the binary needs to be removed manually?
>=20
> https://cgit.freebsd.org/src/commit/?id=3D1c0ea326aa6d3 (2020-12-15) =
removed the files, https://cgit.freebsd.org/src/commit/?id=3D2524b7dfb0df7=
(2024-01-15) added the directory, so that is a window of 4 years!
>=20
> That said, it could probably use a workaround like we do for some =
libc++ files-that-became-directories, in etc/Makefile:
https://cgit.freebsd.org/src/commit/?id=3De368e9b75677 :)
-Dimitry