help w/panic under heavy load - 5.4

[Giorgos Keramidas]

On 2005-07-20 11:41, Edwin <edwin at verolan.com> wrote:
> I'm trying to understand the particulars about this - I get the null pointer
> part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets
> during switching? and its failing trying to copy data past the end of the
> chain?

ip_fastfwd() thinks that it should fragment the packet because it somehow
calculates a bogus ``mtu'' value.  See the mtu value in frame 12 of the stack
trace below.

> mbsd05# kgdb kernel.debug /tmp/crash/vmcore.3
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> #0  doadump () at pcpu.h:159
> 159             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) where
> #0  doadump () at pcpu.h:159
> #1  0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=-1, dummy4=0xc76bf9f4 "(οΏ½kοΏ½")
>     at /usr/src/sys/ddb/db_command.c:531
> #2  0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, 
>     aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349
> #3  0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #4  0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
> #5  0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468
> #6  0xc07b6394 in trap (frame=
>       {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = -1065
> 197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -10
> 60921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584
> #7  0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140
> #8  0xc76b0018 in ?? ()
> #9  0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461
> #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550
> #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1)
>     at /usr/src/sys/kern/uipc_mbuf.c:385
> #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, 
>     if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967

The ``mtu'' is an extremely small integer value, which is definitely a problem
here.  Somehow, ip_fastforward() calculates a very wrong value for the ``mtu''.

> 6933c1 in ip_fastforward (m=0xc11ab100) at /usr/src/sys/netinet/ip_fastfwd.c:572

If you have this particular crash dump, can you show me a dump of the
``ro.ro_rt->rt_rmx'' and the ``ifp'' structure that ip_fastforward() is using?

One of these two seems to have an invalid mtu value.