4.8-stable kernel panic

Maxim Konovalov maxim at macomnet.ru
Tue Sep 16 00:00:16 PDT 2003


On Mon, 15 Sep 2003, 18:55-0400, sysadmin at wvths.com wrote:

> 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

Do you use any klds?  What does kldstat say?

> --- 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

I can't.

-- 
Maxim Konovalov, maxim at macomnet.ru, maxim at FreeBSD.org


More information about the freebsd-hackers mailing list