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 }