On 2005-07-20 11:41, Edwin <[EMAIL PROTECTED]> 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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
