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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> In-Reply-To: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> From: Alexander Leidinger Date: Mon, 12 Feb 2024 10:35:56 +0100 Message-ID: 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, 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=, needed=0x000049a47c2007c8, flags=, lockstate=) 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=, 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=, lockstate=0x00001ded0f98cb80) at rtld.c:4483:9 ---snip--- Bye, Alexander. --000000000000d1c78a06112c01a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

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= .

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).


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 =3D 'imap', stop reason =3D signal= SIGSEGV
=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
=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
=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
=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
=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
=C2=A0 =C2=A0 frame #5: 0x00004d= 3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001ded011502e0, obj=3D0x000049= a47c228008) at rtld.c:4735:6
=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
=C2=A0 =C2=A0 frame #= 7: 0x00004d3dfa2a680b ld-elf.so.1`symlook_global(req=3D0x00001ded01150470, = donelist=3D0x00001ded011504b0) at rtld.c:4541:8
=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
=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
=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
=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
= =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
=C2=A0 =C2=A0 frame #13: 0x00004d3dfa2a223e l= d-elf.so.1`symlook_obj(req=3D0x00001ded01150a80, obj=3D0x000049a47c228008) = at rtld.c:4735:6
=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
=C2=A0 =C2=A0 frame #15: 0x0000= 4d3dfa2a680b ld-elf.so.1`symlook_global(req=3D0x00001ded01150c10, donelist= =3D0x00001ded01150c50) at rtld.c:4541:8
=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
=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
=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
=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
=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
=C2=A0 =C2=A0 frame #21: 0x00004d3dfa2a223e ld-elf.s= o.1`symlook_obj(req=3D0x00001ded01151220, obj=3D0x000049a47c228008) at rtld= c:4735:6
=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
=C2=A0 =C2=A0 frame #23: 0x00004d3dfa2a6= 80b ld-elf.so.1`symlook_global(req=3D0x00001ded011513b0, donelist=3D0x00001= ded011513f0) at rtld.c:4541:8
=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
=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
=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
=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
=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
=C2=A0 =C2=A0 frame #29: 0x00004d3dfa2a223e ld-elf.so.1`symlook= _obj(req=3D0x00001ded011519c0, obj=3D0x000049a47c228008) at rtld.c:4735:6=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
=C2=A0 =C2=A0 frame #31: 0x00004d3dfa2a680b ld-el= f.so.1`symlook_global(req=3D0x00001ded01151b50, donelist=3D0x00001ded01151b= 90) at rtld.c:4541:8
=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
=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
=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
=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
=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
=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
=C2=A0 =C2=A0 frame #39: 0x00004d3dfa2a680b ld-elf.so.1`sy= mlook_global(req=3D0x00001ded011522f0, donelist=3D0x00001ded01152330) at rt= ld.c:4541:8
=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
=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
=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
=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
=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
=C2=A0 = =C2=A0 frame #45: 0x00004d3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001d= ed01152900, obj=3D0x000049a47c228008) at rtld.c:4735:6
=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
=C2=A0 =C2=A0 frame #47: 0x00004d3dfa2a680b ld-elf.so.1`symlook_globa= l(req=3D0x00001ded01152a90, donelist=3D0x00001ded01152ad0) at rtld.c:4541:8=
=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
=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
=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
=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
=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
=C2=A0 =C2=A0 = frame #53: 0x00004d3dfa2a223e ld-elf.so.1`symlook_obj(req=3D0x00001ded01153= 0a0, obj=3D0x000049a47c228008) at rtld.c:4735:6
=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
= =C2=A0 =C2=A0 frame #55: 0x00004d3dfa2a680b ld-elf.so.1`symlook_global(req= =3D0x00001ded01153230, donelist=3D0x00001ded01153270) at rtld.c:4541:8
= =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
---snip---

Bye,
Alexander.=
--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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org> In-Reply-To: <1707730255-92643-mlmmj-52dbb05a@FreeBSD.org> From: Alexander Leidinger Date: Mon, 12 Feb 2024 10:36:32 +0100 Message-ID: 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 = #1 doadump (textdump=textdump@entry=1) at /space/system/usr_src/sys/kern/kern_shutdown.c:403 error = 0 coredump = #2 0xffffffff8052fe85 in kern_reboot (howto=260) at /space/system/usr_src/sys/kern/kern_shutdown.c:521 once = 0 __pc = #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' __pc = __pc = __pc = other_cpus = {__bits = {14680063, 0 }} td = 0xfffff8068ef99740 bootopt = newpanic = #4 0xffffffff805301d3 in panic (fmt=) 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 = isipv6 = #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 #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 = listening = #10 0xffffffff804ccbd1 in fo_close (fp=0xfffff805f2dfc500, td=) at /space/system/usr_src/sys/sys/file.h:390 No locals. #11 _fdrop (fp=fp@entry=0xfffff805f2dfc500, td=, td@entry=0xfffff8068ef99740) at /space/system/usr_src/sys/kern/kern_descrip.c:3666 count = error = #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 = fdtol = fdp = #13 0xffffffff804cd50c in closefp_impl (fdp=0xfffffe07afebf860, fd=19, fp=0xfffff805f2dfc500, td=0xfffff8068ef99740, audit=) at /space/system/usr_src/sys/kern/kern_descrip.c:1315 error = #14 closefp (fdp=0xfffffe07afebf860, fd=19, fp=0xfffff805f2dfc500, td=0xfffff8068ef99740, holdleaders=true, audit=) 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 p = 0xfffffe07f29995c0 sa = 0xfffff8068ef99b30 error = sy_thr_static = traced = #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 }, 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 } #17 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
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 =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,(kgdb) #0 =C2=A0__curthread () at /space/system/usr_src/sys/amd64/include= /pcpu_aux.h:57
=C2=A0 =C2=A0 =C2=A0 =C2=A0 td =3D <optimized out><= br>#1 =C2=A0doadump (textdump=3Dtextdump@entry=3D1)
=C2=A0 =C2=A0 at /sp= ace/system/usr_src/sys/kern/kern_shutdown.c:403
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 error =3D 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 coredump =3D <optimized o= ut>
#2 =C2=A00xffffffff8052fe85 in kern_reboot (howto=3D260)
=C2= =A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_shutdown.c:521
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 once =3D 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <= ;optimized out>
#3 =C2=A00xffffffff80530382 in vpanic (
=C2=A0 =C2= =A0 fmt=3D0xffffffff808df476 "Assertion %s failed at %s:%d",
= =C2=A0 =C2=A0 ap=3Dap@entry=3D0xfffffe08a079ebf0)
=C2=A0 =C2=A0 at /spac= e/system/usr_src/sys/kern/kern_shutdownc:973
=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>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized= out>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized out>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 __pc =3D <optimized out>
=C2=A0 =C2=A0= =C2=A0 =C2=A0 other_cpus =3D {__bits =3D {14680063, 0 <repeats 15 times= >}}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 td =3D 0xfffff8068ef99740
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 bootopt =3D <unavailable>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 newpanic =3D <optimized out>
#4 =C2=A00xffffffff805301d= 3 in panic (fmt=3D<unavailable>)
=C2=A0 =C2=A0 at /space/system/us= r_src/sys/kern/kern_shutdown.c:889
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ap =3D {{= gp_offset =3D 32, fp_offset =3D 48,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 overflow_arg_area =3D 0xfffffe08a079ec20,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 reg_save_area =3D 0xfffffe08a079ebc0}}
#5 =C2=A00xf= fffffff806c9d8c in tcp_discardcb (tp=3Dtp@entry=3D0xfffff80af441ba80)
= =C2=A0 =C2=A0 at /space/system/usr_src/sys/netinet/tcp_subr.c:2386
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 inp =3D 0xfffff80af441ba80
=C2=A0 =C2=A0 =C2=A0= =C2=A0 so =3D 0xfffff804d23d2780
=C2=A0 =C2=A0 =C2=A0 =C2=A0 m =3D <= optimized out>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 isipv6 =3D <optimized o= ut>
#6 =C2=A00xffffffff806d6291 in tcp_usr_detach (so=3D0xfffff804d23= d2780)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/netinet/tcp_usrreq.c:2= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inp =3D 0xfffff80af441ba80
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 tp =3D 0xfffff80af441ba80
#7 =C2=A00xffffffff805dba57 = in sofree (so=3D0xfffff804d23d2780)
=C2=A0 =C2=A0 at /space/system/usr_s= rc/sys/kern/uipc_socket.c:1205
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pr =3D 0xffff= ffff80a8bd18 <tcp_protosw>
#8 =C2=A0sorele_locked (so=3Dso@entry= =3D0xfffff804d23d2780)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/u= ipc_socket.c:1232
No locals.
#9 =C2=A00xffffffff805dc8c0 in soclose (= so=3D0xfffff804d23d2780)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern= /uipc_socket.c:1302
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lqueue =3D {tqh_first = =3D 0xfffff8068ef99740,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tqh_last =3D = 0xfffffe08a079ed40}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D 0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 saved_vnet =3D 0x0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 last= =3D <optimized out>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 listening =3D <= ;optimized out>
#10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2= dfc500, td=3D<unavailable>)
=C2=A0 =C2=A0 at /space/system/usr_src= /sys/sys/file.h:390
No locals.
#11 _fdrop (fp=3Dfp@entry=3D0xfffff805= f2dfc500, td=3D<unavailable>,
=C2=A0 =C2=A0 td@entry=3D0xfffff8068= ef99740)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:= 3666
=C2=A0 =C2=A0 =C2=A0 =C2=A0 count =3D <unavailable>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 error =3D <optimized out>
#12 0xffffffff804d= 02f3 in closef (fp=3Dfp@entry=3D0xfffff805f2dfc500,
=C2=A0 =C2=A0 td=3Dt= d@entry=3D0xfffff8068ef99740)
=C2=A0 =C2=A0 at /space/system/usr_src/sys= /kern/kern_descrip.c:2839
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _error =3D 0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 _fp =3D 0xfffff805f2dfc500
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 lf =3D {l_start =3D -8791759350504, l_len =3D -8791759350528, l_= pid =3D 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l_type =3D 0, l_whence =3D= 0, l_sysid =3D 0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vp =3D <optimized out&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fdtol =3D <optimized out>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 fdp =3D <optimized out>
#13 0xffffffff804= cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, fd=3D19,
=C2=A0 =C2=A0 = fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D<optimized out= >)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:131= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D <optimized out>
#14 clo= sefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,
=C2=A0= =C2=A0 td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D<optimized = out>)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/kern/kern_descrip.c:= 1372
No locals.
#15 0xffffffff808597d6 in syscallenter (td=3D0xfffff8= 068ef99740)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/amd64/amd64/../..= /kern/subr_syscall.c:186
=C2=A0 =C2=A0 =C2=A0 =C2=A0 se =3D 0xffffffff80= a48330 <sysent+192>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 p =3D 0xfffffe07f2= 9995c0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sa =3D 0xfffff8068ef99b30
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 error =3D <optimized out>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 sy_thr_static =3D <optimized out>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 traced =3D <optimized out>
#16 amd64_syscall (td=3D0xfffff8= 068ef99740, traced=3D0)
=C2=A0 =C2=A0 at /space/system/usr_src/sys/amd64= /amd64/trap.c:1192
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ksi =3D {ksi_link =3D {tq= e_next =3D 0xfffffe08a079ef30,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= tqe_prev =3D 0xffffffff808588af <trap+2351>}, ksi_info =3D {
=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,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 si_uid =3D 2398721856, si_status =3D -2042,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 si_addr =3D 0xfffffe08a079ef40, si_value =3D {sival_in= t =3D -1602621824,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 siva= l_ptr =3D 0xfffffe08a079ee80, sigval_int =3D -1602621824,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sigval_ptr =3D 0xfffffe08a079ee80}, _rea= son =3D {_fault =3D {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 _trapno =3D 1489045984}, _timer =3D {_timerid =3D 1489045984,
=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 {
=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},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _= _spare__ =3D {__spare1__ =3D 77306605406688, __spare2__ =3D {
=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}}}},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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---

Any ideas?
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= .

Bye,
Alexander.
--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 ; 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 ; 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 To: Alexander Leidinger Cc: current@freebsd.org Subject: Re: segfault in ld-elf.so.1 Message-ID: References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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=, needed=0x000049a47c2007c8, > flags=, lockstate=) 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=, > 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=, > 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: kernel crash in tcp_subr.c:2386 From: tuexen@freebsd.org In-Reply-To: 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> To: Alexander Leidinger 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 = 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 > #1 doadump (textdump=3Dtextdump@entry=3D1) > at /space/system/usr_src/sys/kern/kern_shutdown.c:403 > error =3D 0 > coredump =3D > #2 0xffffffff8052fe85 in kern_reboot (howto=3D260) > at /space/system/usr_src/sys/kern/kern_shutdown.c:521 > once =3D 0 > __pc =3D > #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' > __pc =3D > __pc =3D > __pc =3D > other_cpus =3D {__bits =3D {14680063, 0 }} > td =3D 0xfffff8068ef99740 > bootopt =3D > newpanic =3D > #4 0xffffffff805301d3 in panic (fmt=3D) > 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 > isipv6 =3D > #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 > #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 > listening =3D > #10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2dfc500, = td=3D) > at /space/system/usr_src/sys/sys/file.h:390 > No locals. > #11 _fdrop (fp=3Dfp@entry=3D0xfffff805f2dfc500, td=3D, > td@entry=3D0xfffff8068ef99740) > at /space/system/usr_src/sys/kern/kern_descrip.c:3666 > count =3D > error =3D > #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 > fdtol =3D > fdp =3D > #13 0xffffffff804cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, = fd=3D19, > fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D) > at /space/system/usr_src/sys/kern/kern_descrip.c:1315 > error =3D > #14 closefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,= > td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D) > 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 > p =3D 0xfffffe07f29995c0 > sa =3D 0xfffff8068ef99b30 > error =3D > sy_thr_static =3D > traced =3D > #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 }, 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 = } > #17 > 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Wolfram Schneider Date: Mon, 12 Feb 2024 13:46:25 +0100 Message-ID: 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 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: Date: Mon, 12 Feb 2024 09:32:34 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> From: John Baldwin 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: 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: 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: 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: irq 91 at device 0.0 on pci0 > rman_manage_region: request: start 0x1, end 0x1 > pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000 > rman_reserve_resource_bound: 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: 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: Date: Mon, 12 Feb 2024 09:36:46 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Michael Butler , Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh , Bakul Shah 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> From: John Baldwin In-Reply-To: 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 *', 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: Date: Mon, 12 Feb 2024 12:45:27 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic To: John Baldwin , Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh , Bakul Shah 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> Content-Language: en-NZ From: Michael Butler 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: 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 *', 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 To: John Baldwin Cc: Michael Butler , Mark Millard , FreeBSD ARM List , Current FreeBSD , Warner Losh , Bakul Shah Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Message-ID: 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> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-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 *', 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: Date: Mon, 12 Feb 2024 10:41:55 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> To: John Baldwin 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 wrote: > On 2/9/24 8:13 PM, Mark Millard wrote: >> Summary: >> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >> rman_manage_region: request: start 0x1, end 0x1 >> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >> rman_reserve_resource_bound: 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic To: John Baldwin , Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh , Bakul Shah 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> Content-Language: en-NZ From: Michael Butler 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: 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 *', > 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 ; 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 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: tuexen@freebsd.org cc: Alexander Leidinger , 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> <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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 = > 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 > > #1 doadump (textdump=3Dtextdump@entry=3D1) > > at /space/system/usr_src/sys/kern/kern_shutdown.c:403 > > error =3D 0 > > coredump =3D > > #2 0xffffffff8052fe85 in kern_reboot (howto=3D260) > > at /space/system/usr_src/sys/kern/kern_shutdown.c:521 > > once =3D 0 > > __pc =3D > > #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' times> > > __pc =3D > > __pc =3D > > __pc =3D > > other_cpus =3D {__bits =3D {14680063, 0 }} > > td =3D 0xfffff8068ef99740 > > bootopt =3D > > newpanic =3D > > #4 0xffffffff805301d3 in panic (fmt=3D) > > 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 > > isipv6 =3D > > #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 > > #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 > > listening =3D > > #10 0xffffffff804ccbd1 in fo_close (fp=3D0xfffff805f2dfc500, = > td=3D) > > at /space/system/usr_src/sys/sys/file.h:390 > > No locals. > > #11 _fdrop (fp=3Dfp@entry=3D0xfffff805f2dfc500, td=3D, > > td@entry=3D0xfffff8068ef99740) > > at /space/system/usr_src/sys/kern/kern_descrip.c:3666 > > count =3D > > error =3D > > #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 > > fdtol =3D > > fdp =3D > > #13 0xffffffff804cd50c in closefp_impl (fdp=3D0xfffffe07afebf860, = > fd=3D19, > > fp=3D0xfffff805f2dfc500, td=3D0xfffff8068ef99740, audit=3D out>) > > at /space/system/usr_src/sys/kern/kern_descrip.c:1315 > > error =3D > > #14 closefp (fdp=3D0xfffffe07afebf860, fd=3D19, fp=3D0xfffff805f2dfc500,= > > > td=3D0xfffff8068ef99740, holdleaders=3Dtrue, audit=3D 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 > > p =3D 0xfffffe07f29995c0 > > sa =3D 0xfffff8068ef99b30 > > error =3D > > sy_thr_static =3D > > traced =3D > > #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 }, 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 = > } > > #17 > > 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 FreeBSD UNIX: Web: https://FreeBSD.org NTP: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-NZ From: Michael Butler To: John Baldwin , Mark Millard , FreeBSD ARM List , Current FreeBSD Cc: Warner Losh , Bakul Shah 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> <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 *', >> 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 ; 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 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: tuexen@freebsd.org, Alexander Leidinger , 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> <625E0EA4-9413-45AD-B05C-500833A1D527@freebsd.org> <20240212193044.E089D185@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Mon, 12 Feb 2024 11:30:44 -0800." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 = > > 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 FreeBSD UNIX: Web: https://FreeBSD.org NTP: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> Date: Mon, 12 Feb 2024 12:00:16 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> To: John Baldwin 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 wrote: > On Feb 12, 2024, at 09:32, John Baldwin wrote: >=20 >> On 2/9/24 8:13 PM, Mark Millard wrote: >>> Summary: >>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>> rman_manage_region: request: start 0x1, end 0x1 >>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >>> rman_reserve_resource_bound: 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: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: Date: Mon, 12 Feb 2024 12:21:27 -0800 Cc: John Baldwin , Michael Butler , FreeBSD ARM List , Current FreeBSD , Warner Losh , Bakul Shah 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> To: John Kennedy 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 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 *', 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 ; 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 ; 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 ; 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 ; 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 ; Mon, 12 Feb 2024 23:23:19 +0100 (CET) Date: Mon, 12 Feb 2024 23:22:51 +0100 From: FreeBSD User To: FreeBSD CURRENT 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com> Date: Mon, 12 Feb 2024 16:10:38 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com> To: John Baldwin 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 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 wrote: >=20 >> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>=20 >>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>> Summary: >>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>> rman_manage_region: request: start 0x1, end 0x1 >>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >>>> rman_reserve_resource_bound: 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: 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: 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: 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: 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: 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: 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: on pcib0 rman_manage_region: range 0..0xff : request: = start 0, end 0xff rman_reserve_resource_bound: 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: 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: irq 91 at device 0.0 on pci0 rman_manage_region: range 0..0xff : request: start = 0x1, end 0x1 pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 rman_reserve_resource_bound: 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: 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 ; 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 ; 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 ; 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 Subject: nvme controller reset failures on recent -CURRENT To: FreeBSD current , John Baldwin Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com> Date: Mon, 12 Feb 2024 16:36:28 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <1F704317-FDB8-4BDA-8A67-61CF48794DFE@yahoo.com> <9AFDF067-96E4-4E67-90D2-F40DAF3F138F@yahoo.com> <4C279710-5F88-4295-B1A4-7C395F3587E5@yahoo.com> To: John Baldwin 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 wrote: > On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>=20 >>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>=20 >>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>> Summary: >>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>> rman_manage_region: request: start 0x1, end = 0x1 >>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >>>>> rman_reserve_resource_bound: 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: 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: 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: 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: 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: 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: 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: on pcib0 > rman_manage_region: range 0..0xff : = request: start 0, end 0xff > rman_reserve_resource_bound: 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: 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: irq 91 at device 0.0 on pci0 > rman_manage_region: range 0..0xff : request: start = 0x1, end 0x1 > pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 > rman_reserve_resource_bound: 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: 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 ; 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 ; 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 To: Alexander Leidinger Cc: current@freebsd.org Subject: Re: segfault in ld-elf.so.1 Message-ID: References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 ; 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 ; 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 To: Alexander Leidinger Cc: current@freebsd.org Subject: Re: segfault in ld-elf.so.1 Message-ID: References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <3A145420-399D-4EBD-9FF4-18924908AB1D@yahoo.com> Date: Mon, 12 Feb 2024 17:57:54 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <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 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 wrote: > On Feb 12, 2024, at 16:10, Mark Millard wrote: >=20 >> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>>=20 >>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>=20 >>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>> Summary: >>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>> rman_manage_region: request: start 0x1, end = 0x1 >>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff,= count=3D0x100000 >>>>>> rman_reserve_resource_bound: 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: 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: 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: 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: 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: 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: 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: on pcib0 >> rman_manage_region: range 0..0xff : = request: start 0, end 0xff >> rman_reserve_resource_bound: 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: 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: irq 91 at device 0.0 on pci0 >> rman_manage_region: range 0..0xff : request: = start 0x1, end 0x1 >> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, = count=3D0x100000 >> rman_reserve_resource_bound: 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: 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Maxim Sobolev Date: Mon, 12 Feb 2024 18:56:34 -0800 Message-ID: Subject: Re: nvme controller reset failures on recent -CURRENT To: Don Lewis Cc: FreeBSD current , John Baldwin 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 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
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

-Max
=


On Mon, Feb 12, 2024, 4:28=E2= =80=AFPM Don Lewis <truckman@fre= ebsd.org> wrote:
I just upgr= aded my package build machine to:
=C2=A0 FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
from:
=C2=A0 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.=C2=A0 I'm not able to get a cras= h
dump, probably because the nvme device has gone away and I get an error
about not having a dump device.=C2=A0 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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00
=C2=A0Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A00
=C2=A0Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A00
=C2=A0Device reliability:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
=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
=C2=A0Volatile memory backup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 0
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
Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 100=
Available spare threshold:=C2=A0 =C2=A0 =C2=A0 10
Percentage used:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 Data units (512,000 byte) read: 5761183
Data units written:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A029911502=
Host read commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A047192118= 8
Host write commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 605394753
Controller busy time (minutes): 32359
Power cycles:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0110
Power on hours:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A019297
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
No. error info log entries:=C2=A0 =C2=A0 =C2=A00
Warning Temp Composite Time:=C2=A0 =C2=A0 0
Error Temp Composite Time:=C2=A0 =C2=A0 =C2=A0 0
Temperature 1 Transition Count: 5231
Temperature 2 Transition Count: 0
Total Time For Temperature 1:=C2=A0 =C2=A041213
Total Time For Temperature 2:=C2=A0 =C2=A00


--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 ; 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 To: Don Lewis Cc: FreeBSD current , John Baldwin Subject: Re: nvme controller reset failures on recent -CURRENT Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-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 ; 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 ; 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 ; 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 Subject: Re: nvme controller reset failures on recent -CURRENT To: Mark Johnston cc: FreeBSD current , John Baldwin In-Reply-To: Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE 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: 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 ; 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 ; 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 ; 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 Subject: Re: nvme controller reset failures on recent -CURRENT To: Maxim Sobolev cc: FreeBSD current , John Baldwin Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=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 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 12 Feb 2024 22:31:46 -0700 Message-ID: Subject: Re: nvme controller reset failures on recent -CURRENT To: Don Lewis Cc: Maxim Sobolev , FreeBSD current , John Baldwin 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 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 = 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


=
On Mon, Feb 12, 2024 at 9:15=E2=80=AF= PM Don Lewis <truckman@freebsd.o= rg> wrote:
> On Mon, Feb 12, 2024, 4:28=E2=80=AFPM Don Lewis <truckman@freebsd.org> wrote:=
>
>> I just upgraded my package build machine to:
>>=C2=A0 =C2=A0FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e >> from:
>>=C2=A0 =C2=A0FreeBSD 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.=C2=A0 I'm not able to g= et a crash
>> dump, probably because the nvme device has gone away and I get an = error
>> about not having a dump device.=C2=A0 It looks like a low-memory p= anic
>> 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 complet= e
>> 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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00
>>=C2=A0 Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A00
>>=C2=A0 Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A00
>>=C2=A0 Device reliability:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 0
>>=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
>>=C2=A0 Volatile memory backup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 0
>> 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
>> Available spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 100
>> Available spare threshold:=C2=A0 =C2=A0 =C2=A0 10
>> Percentage used:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 3
>> Data units (512,000 byte) read: 5761183
>> Data units written:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A029911502
>> Host read commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0471921188
>> Host write commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6053= 94753
>> Controller busy time (minutes): 32359
>> Power cycles:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0110
>> Power on hours:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A019297
>> Unsafe shutdowns:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A014
>> Media errors:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00
>> No. error info log entries:=C2=A0 =C2=A0 =C2=A00
>> Warning Temp Composite Time:=C2=A0 =C2=A0 0
>> Error Temp Composite Time:=C2=A0 =C2=A0 =C2=A0 0
>> Temperature 1 Transition Count: 5231
>> Temperature 2 Transition Count: 0
>> Total Time For Temperature 1:=C2=A0 =C2=A041213
>> Total Time For Temperature 2:=C2=A0 =C2=A00
>>
>>
>>


--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 ; 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 ; 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 ; 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 Subject: Re: nvme controller reset failures on recent -CURRENT To: Warner Losh cc: Maxim Sobolev , FreeBSD current , John Baldwin Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=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 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 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=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 To: Konstantin Belousov Cc: Alexander Leidinger , current@freebsd.org Subject: Re: segfault in ld-elf.so.1 In-Reply-To: References: <1707730081-90734-mlmmj-4d88f1fd@FreeBSD.org> Message-ID: 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 ; 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] ( [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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: nvme controller reset failures on recent -CURRENT Content-Language: en-US To: Don Lewis , Warner Losh Cc: Maxim Sobolev , FreeBSD current , John Baldwin References: From: Pete Wright In-Reply-To: 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 ; 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: Date: Tue, 13 Feb 2024 12:39:47 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: nvme controller reset failures on recent -CURRENT Content-Language: en-US To: Pete Wright , Don Lewis , Warner Losh Cc: Maxim Sobolev , FreeBSD current , John Baldwin References: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org> From: Craig Leres 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 ; 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 ; 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" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: nvme controller reset failures on recent -CURRENT Date: Tue, 13 Feb 2024 21:45:57 +0100 References: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org> To: FreeBSD current In-Reply-To: <65cddfff-84ab-45e4-bcc5-84fc8f5784cb@nomadlogic.org> Message-Id: 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 : > 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 ; 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <8c42cc06-d3de-432e-82ab-7fe040197223@app.fastmail.com> <71141.1706406125@kaos.jnpr.net> In-Reply-To: <71141.1706406125@kaos.jnpr.net> From: Nuno Teixeira Date: Wed, 14 Feb 2024 11:46:56 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: meta mode To: "Simon J. Gerraty" Cc: void , 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 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: Date: Wed, 14 Feb 2024 08:08:37 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Mark Millard Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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 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 wrote: > >> On Feb 12, 2024, at 16:10, Mark Millard wrote: >> >>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>>> >>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>> >>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>> Summary: >>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>>> rman_manage_region: request: start 0x1, end 0x1 >>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000 >>>>>>> rman_reserve_resource_bound: 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: 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> In-Reply-To: From: Warner Losh Date: Wed, 14 Feb 2024 09:42:36 -0700 Message-ID: Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic To: John Baldwin Cc: Mark Millard , FreeBSD ARM List , Current FreeBSD 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 wrot= e: > On 2/12/24 5:57 PM, Mark Millard wrote: > > On Feb 12, 2024, at 16:36, Mark Millard wrote: > > > >> On Feb 12, 2024, at 16:10, Mark Millard wrote: > >> > >>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: > >>>> > >>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: > >>>>> > >>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: > >>>>>>> Summary: > >>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 > >>>>>>> rman_manage_region: request: start 0x1, end 0= x1 > >>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00ffff= f, > count=3D0x100000 > >>>>>>> rman_reserve_resource_bound: 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: 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


=
On Wed, Feb 14, 2024 at 9:08=E2=80=AF= AM John Baldwin <jhb@freebsd.org&= gt; 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 cont= roller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>> pcib0:=C2=A0 PCI addr: 0xc0000000, CPU addr: 0= x600000000, 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_tr= anslate_resource works which is
>>>>>> fundamentally broken.=C2=A0 It rewrites the start = address of a resource in-situ instead
>>>>>> of keeping downstream resources separate from the = upstream resources.=C2=A0 =C2=A0For example,
>>>>>> I don't see how you could ever release a resou= rce in this design without completely
>>>>>> screwing up your rman.=C2=A0 That is, I expect try= ing 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 pan= ic.=C2=A0 Hmm, the panic might be because
>>>>>> for PCI bridge windows the driver now passes RF_AC= TIVE and the bus_translate_resource
>>>>>> hack only kicks in the activate_resource method of= pci_host_generic.c.
>>>>>>
>>>>>>> Detail:
>>>>>>> . . .
>>>>>>> pcib0: <BCM2838-compatible PCI-express cont= roller> mem 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>> pcib0: PCI addr: 0xc0000000, CPU addr: 0x60000= 0000, 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=3D0xc00000= 00, end=3D0xc00fffff, count=3D0x100000
>>>>>>> rman_reserve_resource_bound: <PCIe Memory&g= t; request: [0xc0000000, 0xc00fffff], length 0x100000, flags 102, device pc= ib1
>>>>>>> rman_reserve_resource_bound: trying 0xffffffff= <0xc0000000,0xfffff>
>>>>>>> considering [0xc0000000, 0xffffffff]
>>>>>>> truncated region: [0xc0000000, 0xc00fffff]; si= ze 0x100000 (requested 0x100000)
>>>>>>> candidate region: [0xc0000000, 0xc00fffff], si= ze 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 add= resses in the rman is because
>>>>>> bus_translate_resource rewrote the start address i= n the resource after it was allocated.
>>>>>>
>>>>>> That said, I can't see why rman_manage_region = would actually fail.=C2=A0 At this point the
>>>>>> rman is empty (this is the first call to rman_mana= ge_region for "pcib1 memory window"),
>>>>>> so only the check that should be failing are the c= hecks against rm_start and
>>>>>> rm_end.=C2=A0 For the memory window, rm_start is a= lways 0, and rm_end is always
>>>>>> 0xffffffff, so both the old (0xc00000000 - 0xc00ff= fff) 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 abo= ve 4G.=C2=A0 I have
access to an emag I'm currently using to test fixes to pci_host_generic= .c to
avoid corrupting struct resource objects.=C2=A0 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)
> {
> . . .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pcib_alloc_window(sc, &sc->me= m, 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.=C2=A0 Only th= e
prefetchable BAR supports 64-bit addresses.=C2=A0 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-bit
address range.=C2=A0 It's also true that many PCI devices only support = 32-bit
addresses in memory BARs.=C2=A0 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.=C2=A0 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 t= he time, they made sense. Removing it, though may take some doing
since we use it in about 284 places=C2=A0 in sys/dev today... Somewhat mor= e
pervasive than I'd have thought they'd be...
=
Warner=C2=A0
--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: Date: Wed, 14 Feb 2024 09:30:46 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Warner Losh Cc: Mark Millard , FreeBSD ARM List , Current FreeBSD References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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 In-Reply-To: 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 wrote: > >> On 2/12/24 5:57 PM, Mark Millard wrote: >>> On Feb 12, 2024, at 16:36, Mark Millard wrote: >>> >>>> On Feb 12, 2024, at 16:10, Mark Millard wrote: >>>> >>>>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>>>>> >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>>>> >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>>> Summary: >>>>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>>>>> rman_manage_region: request: start 0x1, end 0x1 >>>>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, >> count=0x100000 >>>>>>>>> rman_reserve_resource_bound: 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: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: Date: Wed, 14 Feb 2024 09:57:33 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <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> To: John Baldwin 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 wrote: > On 2/12/24 5:57 PM, Mark Millard wrote: >> On Feb 12, 2024, at 16:36, Mark Millard wrote: >>> On Feb 12, 2024, at 16:10, Mark Millard wrote: >>>=20 >>>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>>>>=20 >>>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>>>=20 >>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>> Summary: >>>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>>>> rman_manage_region: request: start 0x1, end = 0x1 >>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, = end=3D0xc00fffff, count=3D0x100000 >>>>>>>> rman_reserve_resource_bound: 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: 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> Date: Wed, 14 Feb 2024 10:16:02 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> To: John Baldwin 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 wrote: > On Feb 14, 2024, at 08:08, John Baldwin wrote: >=20 >> On 2/12/24 5:57 PM, Mark Millard wrote: >>> On Feb 12, 2024, at 16:36, Mark Millard wrote: >>>> On Feb 12, 2024, at 16:10, Mark Millard wrote: >>>>=20 >>>>> On Feb 12, 2024, at 12:00, Mark Millard 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 = wrote: >>>>>>=20 >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>>>>=20 >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>>> Summary: >>>>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>>>>> rman_manage_region: request: start 0x1, = end 0x1 >>>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, = end=3D0xc00fffff, count=3D0x100000 >>>>>>>>> rman_reserve_resource_bound: 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: 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: Date: Wed, 14 Feb 2024 10:17:43 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Mark Millard Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> From: John Baldwin 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 wrote: > >> On 2/12/24 5:57 PM, Mark Millard wrote: >>> On Feb 12, 2024, at 16:36, Mark Millard wrote: >>>> On Feb 12, 2024, at 16:10, Mark Millard wrote: >>>> >>>>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: >>>>>> >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: >>>>>>> >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: >>>>>>>>> Summary: >>>>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 >>>>>>>>> rman_manage_region: request: start 0x1, end 0x1 >>>>>>>>> pcib0: rman_reserve_resource: start=0xc0000000, end=0xc00fffff, count=0x100000 >>>>>>>>> rman_reserve_resource_bound: 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic Content-Language: en-US To: Mark Millard Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> From: John Baldwin In-Reply-To: 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> In-Reply-To: From: Warner Losh Date: Wed, 14 Feb 2024 11:45:45 -0700 Message-ID: Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic To: John Baldwin Cc: Mark Millard , FreeBSD ARM List , Current FreeBSD 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 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 = wrote: > > > >> On 2/12/24 5:57 PM, Mark Millard wrote: > >>> On Feb 12, 2024, at 16:36, Mark Millard wrote: > >>> > >>>> On Feb 12, 2024, at 16:10, Mark Millard wrote: > >>>> > >>>>> On Feb 12, 2024, at 12:00, Mark Millard 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 wrote: > >>>>>> > >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin wrote: > >>>>>>> > >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote: > >>>>>>>>> Summary: > >>>>>>>>> pcib0: 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: 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: 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: irq 91 at device 0.0 on pci0 > >>>>>>>>> rman_manage_region: request: start 0x1, end > 0x1 > >>>>>>>>> pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00ff= fff, > >> count=3D0x100000 > >>>>>>>>> rman_reserve_resource_bound: 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: 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
Hey John,

On Wed, Feb 14, 2024 at 10:3= 0=E2=80=AFAM John Baldwin <jhb@freebs= d.org> wrote:
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> wrot= e:
>>>>>
>>>>>> [Gack: I was looking at the wrong vintage of sourc= e 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-expr= ess controller> mem
>> 0x7d500000-0x7d50930f irq 80,81 on simplebus2
>>>>>>>>> pcib0: parsing FDT for ECAM0:
>>>>>>>>> pcib0:=C2=A0 PCI addr: 0xc0000000, CPU= addr: 0x600000000, Size:
>> 0x40000000
>>>>>>>>> . . .
>>>>>>>>> rman_manage_region: <pcib1 memory w= indow> request: start
>> 0x600000000, end 0x6000fffff
>>>>>>>>> panic: Failed to add resource to rman<= br> >>>>>>>>
>>>>>>>> Hmmm, I suspect this is due to the way tha= t bus_translate_resource
>> works which is
>>>>>>>> fundamentally broken.=C2=A0 It rewrites th= e start address of a resource
>> in-situ instead
>>>>>>>> of keeping downstream resources separate f= rom the upstream
>> resources.=C2=A0 =C2=A0For example,
>>>>>>>> I don't see how you could ever release= a resource in this design
>> without completely
>>>>>>>> screwing up your rman.=C2=A0 That is, I ex= pect trying to detach a PCI
>> device behind a
>>>>>>>> translating bridge that uses the current a= pproach should corrupt
>> the allocated
>>>>>>>> resource ranges in an rman long before my = changes.
>>>>>>>>
>>>>>>>> That said, that doesn't really explain= the panic.=C2=A0 Hmm, the panic
>> might be because
>>>>>>>> for PCI bridge windows the driver now pass= es RF_ACTIVE and the
>> bus_translate_resource
>>>>>>>> hack only kicks in the activate_resource m= ethod of
>> pci_host_generic.c.
>>>>>>>>
>>>>>>>>> Detail:
>>>>>>>>> . . .
>>>>>>>>> pcib0: <BCM2838-compatible PCI-expr= ess 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.<= br> >>>>>>>>
>>>>>>>>> pcib1: <PCI-PCI bridge> irq 91 a= t device 0.0 on pci0
>>>>>>>>> rman_manage_region: <pcib1 bus numb= ers> request: start 0x1, end 0x1
>>>>>>>>> pcib0: rman_reserve_resource: start=3D= 0xc0000000, end=3D0xc00fffff,
>> count=3D0x100000
>>>>>>>>> rman_reserve_resource_bound: <PCIe = Memory> request: [0xc0000000,
>> 0xc00fffff], length 0x100000, flags 102, device pcib1
>>>>>>>>> rman_reserve_resource_bound: trying 0x= ffffffff <0xc0000000,0xfffff>
>>>>>>>>> considering [0xc0000000, 0xffffffff] >>>>>>>>> truncated region: [0xc0000000, 0xc00ff= fff]; size 0x100000
>> (requested 0x100000)
>>>>>>>>> candidate region: [0xc0000000, 0xc00ff= fff], size 0x100000
>>>>>>>>> allocating from the beginning
>>>>>>>>> rman_manage_region: <pcib1 memory w= indow> 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 t= he
>>>>> 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 a= ddress 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 r= man_manage_region for
>> "pcib1 memory window"),
>>>>>>>> so only the check that should be failing a= re the checks against
>> rm_start and
>>>>>>>> rm_end.=C2=A0 For the memory window, rm_st= art 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" addresse= s are above 4G.=C2=A0 I
>> have
>> access to an emag I'm currently using to test fixes to pci_hos= t_generic.c
>> to
>> avoid corrupting struct resource objects.=C2=A0 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)
>>> {
>>> . . .
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pcib_alloc_window(sc, = &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
>>> . . .
>>>
>>> is just inappropriately restrictive about where in the system<= br> >>> 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.=C2= =A0 Only the
>> prefetchable BAR supports 64-bit addresses.=C2=A0 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 3= 2-bit
>> address range.=C2=A0 It's also true that many PCI devices only= support 32-bit
>> addresses in memory BARs.=C2=A0 64-bit BARs are an optional extens= ion not
>> universally supported.
>>
>> The translation here is somewhat akin to a type of MMU where the C= PU
>> addresses are mapped to PCI addresses.=C2=A0 The problem here is t= hat 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 th= e fallout
>> that the rman.rm_list linked-list is no longer sorted by address o= nce
>> some addresses get rewritten, etc.
>>
>
> 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
> 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=C2=A0 =C2=A0 =C2=A0rman_set_end(struct resource *_r, rm= an_res_t _end);
sys/sys/rman.h:void=C2=A0 =C2=A0 =C2=A0rman_set_start(struct resource *_r, = rman_res_t _start);

Also, I managed to boot the emag I have access to this morning.=C2=A0 I had= to
fix a few other bugs in acpi(4) for my changes in pci_host_generic to work<= br> 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-- 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic From: Mark Millard In-Reply-To: <0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org> Date: Wed, 14 Feb 2024 12:04:22 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> <0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org> To: John Baldwin 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 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 ; 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 CC: void , , Subject: Re: meta mode In-Reply-To: References: <8c42cc06-d3de-432e-82ab-7fe040197223@app.fastmail.com> <71141.1706406125@kaos.jnpr.net> Comments: In-reply-to: Nuno Teixeira message dated "Wed, 14 Feb 2024 11:46:56 +0000." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 29.1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-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 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Thu, 15 Feb 2024 01:50:46 +0100 Message-ID: Subject: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt. To: freebsd-arm , freebsd-hackers , FreeBSD Mailing List , FreeBSD Current 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"
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-- 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic [now fixed] From: Mark Millard In-Reply-To: <072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com> Date: Wed, 14 Feb 2024 18:19:04 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@yahoo.com> <0b0ba1b0-dee5-47e2-bb93-b44a24492abd@FreeBSD.org> <072C1A6A-85AA-4B26-9598-E5A586F9A4C2@yahoo.com> To: John Baldwin 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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 14 Feb 2024 19:23:52 -0700 Message-ID: Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt. To: Mario Marietto Cc: freebsd-arm , freebsd-hackers , FreeBSD Mailing List , FreeBSD Current 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 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
You may need to grab the repo. You may have to back up to= December's ports tree...=C2=A0

Warner=C2=A0

On Wed, Feb 14, 2024, 5:51=E2=80=AFPM Mario Mariett= o <marietto2008@gmail.com&= gt; wrote:
Hello.<= 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 :

=09 =09 
marietto@freebsd:/usr # sudo portsnap fetch extrac=
t

.....
/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.

I repeated the "portsnap fetch extract" command,but I always get = the same error.

--
Mario.
--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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt. From: Mark Millard In-Reply-To: Date: Wed, 14 Feb 2024 19:15:43 -0800 Cc: Mario Marietto , freebsd-arm , freebsd-hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <7AA6A6B8-9BAE-4B03-9EF4-4A4D242582B4@yahoo.com> References: To: Warner Losh 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 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 = 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 ; 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 ; 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: 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic [now fixed] From: Mark Millard In-Reply-To: <23365E1F-FB27-49C7-A691-5DE3FDE40940@yahoo.com> Date: Wed, 14 Feb 2024 23:03:36 -0800 Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh 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> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@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 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 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: 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 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: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 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 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: Date: Thu, 15 Feb 2024 09:39:50 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic [now fixed] Content-Language: en-US To: Mark Millard Cc: FreeBSD ARM List , Current FreeBSD , Warner Losh References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@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 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 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net> In-Reply-To: <202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net> From: Mario Marietto Date: Thu, 15 Feb 2024 21:32:19 +0100 Message-ID: Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt. To: Jamie Landeg-Jones 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 wrote: > Mario Marietto 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
Hello.

What's the correc= t port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?

= 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 ar= mv7 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 o= r portsnap
is deprecated?

Still, the solution is easy:

Download the ports tree snapshot as a tar from https://cgit.freebsd.o= rg/ports/

Choose a tag, and a format. I suggest 12.4-eol so just fetch

https://cgit.freebsd.org/ports/snapshot/p= orts-12-eol.tar.gz

rm -r /usr/ports
then untar the downloaded tar file into place.

Cheers, Jamie



--
Mario.
--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 ; 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 ; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <202402151734.41FHYNBj061905@donotpassgo.dyslexicfish.net> In-Reply-To: From: Warner Losh Date: Thu, 15 Feb 2024 14:27:18 -0700 Message-ID: Subject: Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt. To: Mario Marietto Cc: Jamie Landeg-Jones , FreeBSD questions , FreeBSD Hackers , FreeBSD Current , "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 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 > wrote: > >> Mario Marietto 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


On Thu, Feb 15, 2024, 1:33=E2=80=AFPM Mario Marietto &= lt;marietto2008@gmail.com>= wrote:
Hello= .

What's the correct port tree for FreeBSD 12.= 04 for arm 32 bit ? A or B ?



A is your best bet.

Warner

th= anks.

On Thu, Feb 15, 2024 at 6:34=E2=80=AFPM Jamie Landeg-Jones = <jamie@catflap.org> wrote:
Mario Marietto <marietto2008@gmail.com> w= rote:

> After a lot of work I've been able to install FreeBSD 12.04 for ar= mv7 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 o= r portsnap
is deprecated?

Still, the solution is easy:

Download the ports tree snapshot as a tar from https://cgi= t.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-- 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 To: Mark Millard Cc: John Baldwin , FreeBSD ARM List , Current FreeBSD , Warner Losh Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic [now fixed] Message-ID: 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> <36ECB040-7E09-47A9-AF71-DE546A78E9CA@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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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 To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Fourth Quater 2023 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=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 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 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, 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 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 Contact: Li-Wen Hsu 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 Contact: FreeBSD Ports Management Team 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 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 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 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 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 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 Contact: Li-Wen Hsu 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 Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Souradeep Chakrabarti Contact: Li-Wen Hsu 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 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 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 • 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 A new FAQ was released alongside FreeBSD 14.0. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla 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 Contact: Li-Wen Hsu 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 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 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 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 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) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) 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 ; 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 ; 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" To: "freebsd-current@freebsd.org" Subject: Re: FreeBSD panics possibly caused by nfs clients Thread-Topic: FreeBSD panics possibly caused by nfs clients Thread-Index: AQHaYQtwEy3CkCGt90qW8Bq/tEdG3g== Date: Fri, 16 Feb 2024 19:07:52 +0000 Message-ID: <53139ffd-3e42-4aaf-a523-b8f4dc8b29a9@dartmouth.edu> References: <3ea6d241-b9cc-4294-aef8-ae1c6d9d8161@dartmouth.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla Thunderbird x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR03MB5574:EE_|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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: dartmouth.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR03MB5574.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdefgdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehgeffue enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi ugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 16 Feb 2024 18:53:35 -0500 (EST) Date: Fri, 16 Feb 2024 23:53:33 +0000 From: void To: freebsd-current@freebsd.org Subject: new tls-cert-store and cert-bundle methods Message-ID: Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Sat, 17 Feb 2024 00:02:16 +0000 (UTC) Date: Sat, 17 Feb 2024 00:02:16 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@freebsd.org Subject: install: /usr/libexec/kgdb exists but is not a directory Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: install: /usr/libexec/kgdb exists but is not a directory From: Dimitry Andric In-Reply-To: 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: To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3731.700.6.1.1) On 17 Feb 2024, at 01:02, Bjoern A. Zeeb = 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 ; 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 List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: install: /usr/libexec/kgdb exists but is not a directory From: Dimitry Andric 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: <687DC3BC-64FF-4619-93AB-E760FAF5F0CF@FreeBSD.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3731.700.6.1.1) On 17 Feb 2024, at 12:15, Dimitry Andric wrote: >=20 > On 17 Feb 2024, at 01:02, Bjoern A. Zeeb = 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