Date: Tue, 08 Aug 2023 09:15:59 +0000 From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 272908] [14.0 CURRENT] Kernel panic in the pf_find_state_all_exists() Message-ID: <bug-272908-16861-M2Bt7EnGGt@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272908-16861@https.bugs.freebsd.org/bugzilla/> References: <bug-272908-16861@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272908 --- Comment #3 from Kristof Provost <kp@freebsd.org> --- We're going to need to look at a core dump. It's a very odd place for a panic, in the sense that nothing that's changed= in the past several years should affect that, and it's also a relatively straightforward call. It really shouldn't be panicking there. You're using a couple of new-ish features (dummynet, ethernet rules, openvpn DCO), but they don't appear to be involved here, and you're also using them= the way pfsense does and I've not seen any similar reports there. So, when this recurs please do the kgdb dance. We'll want the local variabl= es in pf_find_state_all_exists() and pf_find_state_all() for starters. Do keep that core file around, because we're almost certainly going to want to poke= it more. Also gather the full panic output, not just the backtrace, because it's not quite clear to me if we're running into an assertion failure or a segmentat= ion fault or something else. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272908-16861-M2Bt7EnGGt>