4.8-stable kernel panic

[sysadmin at wvths.com]

It appears that pr-55886 is entirely different bug. After applying the
above patch, I can still get a kernel panic due to mbufs exhaustion.

Mike "Silby" Silbersack wrote:
> 1.  Can you compile INVARIANTS and INVARIANT_SUPPORT into your kernel?

After compiling INVARIANTS* into the kernel, here's what the backtrace
looks like:
 --- bt ---

# gdb -k kernel.debug vmcore.11
GNU gdb 4.18 (FreeBSD)
<snip gdb mesg>

IdlePTD at phsyical address 0x00405000 initial pcb at physical address
0x003548a0 panicstr: m_copydata, offset > size of mbuf chain panic
messages:
---
panic: m_copydata, offset > size of mbuf chain

syncing disks...
done
Uptime: 1h12m27s

dumping to dev #ad/0x50001, offset 1048608 dump ata0: resetting devices ..
done
<snip memcount>
---
#0  dumpsys () at ../../kern/kern_shutdown.c:487
487             if (dumping++) {
(kgdb) bt
#0  dumpsys () at ../../kern/kern_shutdown.c:487
#1  0xc0168237 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2  0xc0168675 in panic (fmt=0xc02db260 "m_copydata, offset > size of mbuf chain") at ../../kern/kern_shutdown.c:595
#3  0xc018576e in m_copydata (m=0xc155ec00, off=6144, len=2048, cp=0xc1558000 "") at ../../kern/uipc_mbuf.c:979
#4  0xc0186776 in m_defrag (m0=0xc155ec00, how=1) at ../../kern/uipc_mbuf.c:1572
#5  0xc021de70 in dc_encap (sc=0xc21c3000, m_head=0xc155ec00, txidx=0xd72dede4) at ../../pci/if_dc.c:3006
#6  0xc021e0bb in dc_start (ifp=0xc21c3000) at ../../pci/if_dc.c:3105
#7  0xc021de09 in dc_intr (arg=0xc21c3000) at ../../pci/if_dc.c:2970
#8  0xc02b419d in intr_mux (arg=0xc144e3a0) at ../../i386/isa/intr_machdep.c:601
#9  0xc02aa0f2 in generic_bcopy ()
#10 0xc023be35 in vm_fault (map=0xd4a9afc0, vaddr=134705152, fault_type=2 '\002', fault_flags=8) at ../../vm/vm_page.h:495
#11 0xc02abb1e in trap_pfault (frame=0xd72defa8, usermode=1, eva=134708896) at ../../i386/i386/trap.c:847
#12 0xc02ab5af in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134740690, tf_esi = 134740672, tf_ebp = -1078004340, 
      tf_isp = -684855340, tf_ebx = 18, tf_edx = 134696192, tf_ecx = 134740672, tf_eax = 134708863, tf_trapno = 12, tf_err = 7, 
      tf_eip = 134614425, tf_cs = 31, tf_eflags = 66118, tf_esp = -1078004348, tf_ss = 47}) at ../../i386/i386/trap.c:377
#13 0x8060d99 in ?? ()
#14 0x8062111 in ?? ()
#15 0x8061c2a in ?? ()
#16 0x8060047 in ?? ()
#17 0x805ffeb in ?? ()
#18 0x805e3f5 in ?? ()
#19 0x8048e29 in ?? ()
#20 0x804813e in ?? ()
(kgdb)q

--- bt ---

> 2.  What does your network setup look like?  Are you using divert
> sockets, is there ppp in action, etc.

Nothing special, Accton EN2242 10/100BaseTX NIC using dc driver, ipwf
compiled in, but no rules a set ATM.

Can anyone else reproduce the panic using this script:
--
#!/bin/sh
while :; do
 ping -f -s 65467 ip_addr &
done
--
Thanks,