24.06.2019 21:32, Larry Rosenman пишет: > Got 2 of these today, and I have cores.... > Ideas? > r349200. > > Unread portion of the kernel message buffer: > panic: ng_snd_item: 42 != 1414 > cpuid = 10 > time = 1561382494 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe012628d400 > vpanic() at vpanic+0x19d/frame 0xfffffe012628d450 > panic() at panic+0x43/frame 0xfffffe012628d4b0 > ng_snd_item() at ng_snd_item+0x477/frame 0xfffffe012628d4f0 > ng_ether_output() at ng_ether_output+0x5e/frame 0xfffffe012628d520 > ether_output() at ether_output+0x473/frame 0xfffffe012628d5c0 > arpintr() at arpintr+0xfe3/frame 0xfffffe012628d780 > netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 0xfffffe012628d7f0 > ether_demux() at ether_demux+0x137/frame 0xfffffe012628d820 > ng_ether_rcv_upper() at ng_ether_rcv_upper+0x95/frame 0xfffffe012628d840 > ng_apply_item() at ng_apply_item+0xf1/frame 0xfffffe012628d8c0 > ng_snd_item() at ng_snd_item+0x2ab/frame 0xfffffe012628d900 > ng_apply_item() at ng_apply_item+0xf1/frame 0xfffffe012628d980 > ng_snd_item() at ng_snd_item+0x2ab/frame 0xfffffe012628d9c0 > ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe012628d9f0 > ether_nh_input() at ether_nh_input+0x2cd/frame 0xfffffe012628da40 > netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 0xfffffe012628dab0 > ether_input() at ether_input+0x48/frame 0xfffffe012628dad0 > bce_intr() at bce_intr+0x697/frame 0xfffffe012628db50 > ithread_loop() at ithread_loop+0x187/frame 0xfffffe012628dbb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe012628dbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe012628dbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 4d18h45m34s > Dumping 24921 out of 131026 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > #5 0xffffffff828ee5b7 in ng_snd_item (item=0xfffff8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2252
It looks like you use some netgraph based ethernet interface. The system got received ARP request and is going to send the reply, but somehow mbuf with this ARP request has initialized m_next pointer, thus it is considered as a chain of mbufs. in_arpinput() reuses received mbuf to construct the reply, but it doesn't check that an mbut is a chain. It just sets m_len and sends it. Then since you have INVARIANTS in your kernel, the netgraph code check the actual length of the chain, and it doesn't match to m_len. It panics. > #6 0xffffffff82900c2e in ng_ether_output (ifp=<optimized out>, > mp=0xfffffe012628d578) at /usr/src/sys/netgraph/ng_ether.c:294 > #7 0xffffffff805b1e43 in ether_output (ifp=<optimized out>, > m=0xfffff81f59eefb00, dst=0xfffffe012628d740, ro=<optimized out>) > at /usr/src/sys/net/if_ethersubr.c:430 > #8 0xffffffff805cb3e3 in in_arpinput (m=<optimized out>) > at /usr/src/sys/netinet/if_ether.c:1152 > #9 arpintr (m=0xfffff81f59eefb00) at /usr/src/sys/netinet/if_ether.c:749 > #10 0xffffffff805bcf89 in netisr_dispatch_src (proto=4, > source=<optimized out>, m=<unavailable>) at /usr/src/sys/net/netisr.c:1123 > #11 0xffffffff805b22d7 in ether_demux (ifp=0xfffff8012c902000, > m=<unavailable>) at /usr/src/sys/net/if_ethersubr.c:913 > #12 0xffffffff82901045 in ng_ether_rcv_upper (hook=<optimized out>, > item=<optimized out>) at /usr/src/sys/netgraph/ng_ether.c:741 > #13 0xffffffff828ee6e1 in ng_apply_item (node=0xfffff81054f43400, > item=0xfffff8021e3b4d80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2403 > #14 0xffffffff828ee3eb in ng_snd_item (item=0xfffff8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2320 > #15 0xffffffff828ee6e1 in ng_apply_item (node=0xfffff8012c2d3e00, > item=0xfffff8021e3b4d80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2403 > #16 0xffffffff828ee3eb in ng_snd_item (item=0xfffff8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2320 > #17 0xffffffff82900cbc in ng_ether_input (ifp=<optimized out>, > mp=0xfffffe012628da18) at /usr/src/sys/netgraph/ng_ether.c:255 > #18 0xffffffff805b34fd in ether_input_internal (ifp=0xfffff8012c902000, > m=0xfffff81f59eefb00) at /usr/src/sys/net/if_ethersubr.c:654 > #19 ether_nh_input (m=<optimized out>) at /usr/src/sys/net/if_ethersubr.c:735 > #20 0xffffffff805bcf89 in netisr_dispatch_src (proto=5, > source=<optimized out>, m=<unavailable>) at /usr/src/sys/net/netisr.c:1123 > #21 0xffffffff805b26f8 in ether_input (ifp=0xfffff8012c902000, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:823 > #22 0xffffffff8273c7f7 in bce_rx_intr (sc=<optimized out>) > at /usr/src/sys/dev/bce/if_bce.c:6848 > #23 bce_intr (xsc=0xfffffe01665c2000) at /usr/src/sys/dev/bce/if_bce.c:8017 > #24 0xffffffff8047e0e7 in intr_event_execute_handlers (p=<optimized out>, > ie=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1148 > #25 ithread_execute_handlers (p=<optimized out>, ie=<optimized out>) > at /usr/src/sys/kern/kern_intr.c:1161 > #26 ithread_loop (arg=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1241 > #27 0xffffffff8047ac74 in fork_exit ( > callout=0xffffffff8047df60 <ithread_loop>, arg=0xfffff8012c883100, > frame=0xfffffe012628dc00) at /usr/src/sys/kern/kern_fork.c:1056 > #28 <signal handler called> > (kgdb) > -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
