https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #102 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=44af4103e422029026e9bb1a5784550365831cf3
commit 44af4103e422029026e9bb1a5784550365831cf3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #101 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1d6ece4351a01179e3a5ebbdb3fa2e6053a2d7aa
commit 1d6ece4351a01179e3a5ebbdb3fa2e6053a2d7aa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #100 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=09b7cab88f652e3a3682749e38c043d25dd7d0ed
commit 09b7cab88f652e3a3682749e38c043d25dd7d0ed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #99 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3eb2341caaa307a8d067333c8aebe3e269ade2fd
commit 3eb2341caaa307a8d067333c8aebe3e269ade2fd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #98 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=6b916bc91d76a4e91629074779a89b22207ea053
commit 6b916bc91d76a4e91629074779a89b22207ea053
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #97 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5d6b503ed097733af83003cf675f3d55c2b90756
commit 5d6b503ed097733af83003cf675f3d55c2b90756
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #96 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=844ad2828a35c434b893af4274b1f6c50332dd70
commit 844ad2828a35c434b893af4274b1f6c50332dd70
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #95 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=a6719858a48019aa54e1ea3be57d17fa88b080c6
commit a6719858a48019aa54e1ea3be57d17fa88b080c6
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #94 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=53247cdf12449e90f6736ae563e4cce8315c923f
commit 53247cdf12449e90f6736ae563e4cce8315c923f
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #93 from Kristof Provost ---
(In reply to mikael.le-bohec from comment #92)
You're tripping over a different panic. (And it would have been helpful to
actually include the backtrace in your report.)
> panic: _mtx_lock_sleep:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
mikael.le-bo...@univ-ubs.fr changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Kristof Provost changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #91 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3dec62eded04eaf431bf0948f4e6412deede87d5
commit 3dec62eded04eaf431bf0948f4e6412deede87d5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #90 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1
commit dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Thomas Steen Rasmussen / Tykling changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #88 from jja...@gmail.com ---
(In reply to jjasen from comment #87)
So far, we held together overnight without any issue!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #87 from jja...@gmail.com ---
(In reply to jjasen from comment #86)
iterative tests started. Fingers crossed!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #86 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #84)
Compiling now.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #85 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b
commit 9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #84 from Kristof Provost ---
Ah, that's the same issue, but in the tmo function now.
Try this:
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 47c3217f399c..fd5be82367aa 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #83 from jja...@gmail.com ---
BT:
#0 __curthread () at /root/usr/src/sys/amd64/include/pcpu_aux.h:55
#1 dump_savectx () at /root/usr/src/sys/kern/kern_shutdown.c:394
#2 0x80c38ae8 in dumpsys (di=0x0) at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #82 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #81)
I'm using this:
https://cgit.freebsd.org/src/commit/?id=8edf0b52c40762d64b3d4318235b58ae5d4eff58
Other stuff up shortly.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #81 from Kristof Provost ---
Yes. Also show me what code you have for that function, so we’re sure we’re
looking at the same thing.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #80 from jja...@gmail.com ---
Good news. We may have fixed pfsyncintr.
Bad news. I don't think we defeated pfsync_defer_tmo
Want the usual bt, frame and prints?
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #79 from jja...@gmail.com ---
(In reply to jjasen from comment #78)
defer_tmo patch added as well, started test bombardment.
So far, no issues.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #78 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #77)
OK. I compiled a kernel with this in. I need to add the pfsync_defer_tmo patch
as well.
On the upside, I was able to generate traffic on this system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #77 from Kristof Provost ---
(In reply to jjasen from comment #76)
Yeah, that's against stable/13.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #76 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #75)
No. I stuffed it in manually.
Was this against clean -stable or against what we were working on?
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #75 from Kristof Provost ---
(In reply to jjasen from comment #74)
Did the patch apply fully? The ip6_output() prototype should be in `#include
`.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #74 from jja...@gmail.com ---
Ooopsie! Did I goof up?
mno-avx -std=iso9899:1999 -c /root/usr/src/sys/netpfil/pf/if_pfsync.c -o
if_pfsync.o
/root/usr/src/sys/netpfil/pf/if_pfsync.c:2368:48: error: implicit declaration
of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #73 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #72)
I speculate cooking up a case where an IPv4 attempt from the firewall fails, it
reverts to IPv6, and attempts to insert that state.
I am able to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #72 from Kristof Provost ---
I'm still failing to reproduce, but this should be close to a real fix:
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 47c3217f399c..4ebd304b1c13 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #71 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #70)
Yeah, according to the EOL schedule, 13.1 has maybe six months to live. Thanks
for reminding me.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #70 from Kristof Provost ---
(In reply to jjasen from comment #68)
Okay, excellent. I think we've figured out what's going on here.
I also think I see why I can't reproduce it yet. It's interpreting the IPv6
header as an IPv4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #69 from jja...@gmail.com ---
OK, that's weird
I just got nailed by a pfsync_defer_tmo while I was typing this up.
It should be fixed in 13.1-STABLE source?
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #68 from jja...@gmail.com ---
Yes, it's crashing on ip6 traffic.
2023-02-09T12:56:35.997491-05:00 extgw2 kernel: pfsyncintr() skipping !IPv4
traffic
2023-02-09T12:56:38.320484-05:00 extgw2 kernel: pfsyncintr() skipping !IPv4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #67 from Kristof Provost ---
That destination address is a bit odd... Do you have IPv6 traffic? pfsync
always uses ip_output() for deferred traffic, which might perhaps explain the
panic if we're shoving IPv6 packets through
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #66 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #65)
a -- I went to explore frame 12 a bit:
frame 12
#12 0x80dfe1d2 in ip_output (m=0xf802d9447a00, opt=,
opt@entry=0x0,
ro=,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #65 from Kristof Provost ---
(In reply to jjasen from comment #64)
Try 'p *mhip' and 'p/x *mhip'.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #64 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #63)
Depressing.
(kgdb) frame 11
#11 0x80dfe81f in ip_fragment (ip=,
ip@entry=0xf802d9447a68,
m_frag=m_frag@entry=0xfe020478fd80,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #63 from Kristof Provost ---
(In reply to jjasen from comment #62)
So that's still the same backtrace, and with the patch from comment #54 we can
assume that the mbuf length and IP length actually match.
'info locals' in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #62 from jja...@gmail.com ---
fresh from the dump --
What do you need from it?
Fatal trap 12: page fault while in kernel mode
cpuid = 10; apic id = 24
fault virtual address = 0x18
fault code = supervisor read
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #61 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #54)
Compiling now. Also upgraded to STABLE src versus RELEASE for this one.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #60 from Nick Hilliard ---
(In reply to Kristof Provost from comment #57)
no panics since that patch, so that seems to have resolved things. I'm not
seeing jjasen@'s panic.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #59 from jja...@gmail.com ---
(In reply to Nick Hilliard from comment #58)
I've found outbound traffic from the secondary firewall will trigger the
pfsyncintr issue, versus the pfsync_defer_tmo issue you posted.
You may want
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #58 from Nick Hilliard ---
> That one's already fixed. See Comment #22 or
> https://cgit.freebsd.org/src/commit/?id=fd02192c3acaefeb62db11e0c10ab36240b79ba2
ok, i've committed that and enabled pfsync. Will let you know if it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #57 from Kristof Provost ---
(In reply to Nick Hilliard from comment #55)
That one's already fixed. See Comment #22 or
https://cgit.freebsd.org/src/commit/?id=fd02192c3acaefeb62db11e0c10ab36240b79ba2
The debug patch is against
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #56 from Nick Hilliard ---
btw which source version is that patch committed to? I manually patched it
against releng/13.1.
# git branch -l
main
* releng/13.1
#
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #55 from Nick Hilliard ---
I've pasted the output for #comment54 into http://p.ip.fi/FE7p
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #54 from Kristof Provost ---
(In reply to jjasen from comment #53)
I really need to be able to reproduce this, or at least poke at a machine that
can trigger this somewhat reliably.
Until then we're stuck doing test-kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #53 from jja...@gmail.com ---
But now we at least have someone else potentially seeing the same thing. It's a
relief to not be the only crazy one.
How can I continue to help?
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #52 from jja...@gmail.com ---
This is new:
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #51 from Kristof Provost ---
(In reply to jjasen from comment #50)
That's still the same backtrace. If that's running with the patch from comment
#47 I am perplexed. That would mean the mbuf is fine going into the queue, and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #50 from jja...@gmail.com ---
kernel panic hot off the presses
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe020479e980
vpanic() at vpanic+0x17f/frame 0xfe020479e9d0
panic() at panic+0x43/frame
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #49 from Nick Hilliard ---
> Do you have other non-1500 byte MTU interfaces on that machine?
not in service, no. xn4 is up and also has mtu 1504, but there is nothing
configured on the interface (i.e. no vlans, no ip
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #48 from Kristof Provost ---
(In reply to Nick Hilliard from comment #47)
Do you have other non-1500 byte MTU interfaces on that machine?
I'm still unable to reproduce this panic. We do know it's related to defer mode
(which
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #47 from Nick Hilliard ---
primary upgraded to 13.1-RELEASE-p3 and now it's crashing too, within seconds
of enabling pfsync (i.e. panic with kernel uptime 25s)
rc config variables:
--
ifconfig_xn3="mtu 1504 up"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #46 from Nick Hilliard ---
am seeing this panic verbatim on 13.1-RELEASE-p3 (backup) with 12.3-RELEASE-p1
primary. Both instances running as xen VMs, xn driver.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #45 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #44)
I ran memory tests, disk tests, and even completely rebuilt the machine before
opening a bug report.
I'll drop this patch in today, and get back to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #44 from Kristof Provost ---
(In reply to jjasen from comment #43)
That .. that doesn't make a whole lot of sense. With that patch the system
should have panicked before that point. We don't modify mbufs while they're
deferred,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #43 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #42)
bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=1) at
/usr/src/sys/kern/kern_shutdown.c:399
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Graham Perrin changed:
What|Removed |Added
CC||grahamper...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Graham Perrin changed:
What|Removed |Added
Status|Open|In Progress
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #42 from Kristof Provost ---
(In reply to jjasen from comment #39)
Let's be a bit less subtle then:
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 61308a35a7e1..d0bc699e4d29 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #41 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=76e1ec4e10fa9a85bb8090cdf61e54c7a19508ee
commit 76e1ec4e10fa9a85bb8090cdf61e54c7a19508ee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #40 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8edf0b52c40762d64b3d4318235b58ae5d4eff58
commit 8edf0b52c40762d64b3d4318235b58ae5d4eff58
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #39 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #38)
Sorry, no such file. Nothing in core.txt either.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #38 from Kristof Provost ---
(In reply to jjasen from comment #37)
No, that's not what I'm looking for. I need the kernel's log messages. They
should be in /var/crash/msgbuf.txt
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #37 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #36)
any of this help?
#8 0x80cc3a40 in m_copym (m=0x0, m@entry=0xf8062624c500,
off0=8268, len=8192, wait=wait@entry=1)
at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #36 from Kristof Provost ---
(In reply to jjasen from comment #35)
Mostly just the kernel output just before the panic. I'd expect to see
'pfsync_defer(): defer len ...' lines, and those are the ones I'm interested
in.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #35 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #34)
I have a core dump with this patch installed. What do you want out of it?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #34 from Kristof Provost ---
(In reply to jjasen from comment #33)
Can you try this patch?
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 61308a35a7e1..54824227da57 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #33 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #32)
Of the other 6, yes. If they were any more identical, they'd have sequential
serial numbers.
-lro -tso4 -tso6 had no effect.
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #32 from Kristof Provost ---
(In reply to jjasen from comment #31)
Do all machines use the same NIC hardware for the pfsync interfaces?
It may also be interesting to experiment with LRO/TSO flags, on the off chance
that they
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #31 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #30)
p *ip
$1 = {ip_hl = 5 '\005', ip_v = 4 '\004', ip_tos = 1 '\001', ip_len = 8011,
ip_id = 42943, ip_off = 16390,
ip_ttl = 32 ' ', ip_p = 1 '\001',
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #30 from Kristof Provost ---
(In reply to jjasen from comment #29)
We're looking at a deferred packet here, that's being allowed through,
presumably after the pfsync peer ack'd the state.
That should all just work, and I can't
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #29 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #28)
These help?
bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=1) at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #28 from Kristof Provost ---
(In reply to jjasen from comment #27)
Yes. This is progress already, because now we know to look at the defer code
paths but the other information will be useful too.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #27 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #26)
With -defer set on the pfsync interface, I can't get it to crash trying to
tickle pfsyncintr.
With defer toggled back on, it crashed almost
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #26 from Kristof Provost ---
I remain confused about the pfsyncintr() panic.
Can you take another crash dump, with the above patch built-in, and the MTU set
to 1500, and deferred mode disabled? Also get the same information
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #25 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=fd02192c3acaefeb62db11e0c10ab36240b79ba2
commit fd02192c3acaefeb62db11e0c10ab36240b79ba2
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
82 matches
Mail list logo
