Date: Sun, 29 Oct 2000 22:00:03 -0800 (PST) From: "Lachlan O'Dea" <lodea@vet.com.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/22224: ipfw pipe command causes kernel panic Message-ID: <200010300600.WAA84682@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/22224; it has been noted by GNATS.
From: "Lachlan O'Dea" <lodea@vet.com.au>
To: freebsd-gnats-submit@FreeBSD.org
Cc: jeff+freebsd@spotlife.com
Subject: Re: kern/22224: ipfw pipe command causes kernel panic
Date: Mon, 30 Oct 2000 16:53:13 +1100
I've got exactly the same problem. The troublesome dummynet code is only
included when using bridging. I have one_pass set to 1.
morannon /sys/netinet % uname -a
FreeBSD morannon.mel.vet.com.au 4.1-STABLE FreeBSD 4.1-STABLE #0: Thu Sep 21 13:19:08 EST 2000 lodea@morannon.mel.vet.com.au:/usr/site/freebsdsrc/src/sys/compile/MORANNON i386
Script started on Mon Oct 30 16:22:43 2000
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 3059712
initial pcb at 26c340
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc055064a
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01545af
stack pointer = 0x10:0xc024cdfc
frame pointer = 0x10:0xc024ce08
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net
trap number = 12
panic: page fault
syncing disks... 2 1
done
Uptime: 37d14h24m2s
dumping to dev #ad/0x20001, offset 76272
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:302
302 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:302
#1 0xc013ae0c in poweroff_wait (junk=0xc02441cf, howto=0)
at ../../kern/kern_shutdown.c:552
#2 0xc020ec61 in trap_fatal (frame=0xc024cdbc, eva=3226797642)
at ../../i386/i386/trap.c:951
#3 0xc020e939 in trap_pfault (frame=0xc024cdbc, usermode=0, eva=3226797642)
at ../../i386/i386/trap.c:844
#4 0xc020e4f3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 6422528, tf_esi = 0, tf_ebp = -1071329784,
tf_isp = -1071329816, tf_ebx = -1063740608, tf_edx = 521802, tf_ecx = 0,
tf_eax = -1068691456, tf_trapno = 12, tf_err = 2, tf_eip = -1072347729,
tf_cs = 8, tf_eflags = 66066, tf_esp = -1063740608, tf_ss = 0})
at ../../i386/i386/trap.c:443
#5 0xc01545af in m_free (m=0xc0989b40) at ../../kern/uipc_mbuf.c:515
#6 0xc015537e in m_pullup (n=0xc0989b40, len=14) at ../../kern/uipc_mbuf.c:981
#7 0xc018588d in transmit_event (pipe=0xc0aad800)
at ../../netinet/ip_dummynet.c:407
#8 0xc0185ac7 in ready_event (q=0xc0a03580) at ../../netinet/ip_dummynet.c:525
#9 0xc0185eff in dummynet (unused=0x0) at ../../netinet/ip_dummynet.c:660
#10 0xc01401f1 in softclock () at ../../kern/kern_timeout.c:131
(kgdb) up 7
#7 0xc018588d in transmit_event (pipe=0xc0aad800)
at ../../netinet/ip_dummynet.c:407
407 if (m->m_len < ETHER_HDR_LEN
(kgdb) print *m
$1 = {m_hdr = {mh_next = 0xc04e2700, mh_nextpkt = 0x0,
mh_data = 0xc0842cc0 "ðtMÀ", mh_len = 0, mh_type = 14, mh_flags = 1},
M_dat = {MH = {MH_pkthdr = {rcvif = 0x135d1406, len = 0,
header = 0xc07db800 "", csum_flags = 0, csum_data = 0, aux = 0x0},
MH_dat = {MH_ext = {ext_buf = 0x0, ext_free = 0, ext_size = 0,
ext_ref = 0},
MH_databuf = '\000' <repeats 20 times>, "@O\212À\000ù À\200É\237ÀÈã\224À\000\000\000\000À$ûÃ@\031éÃ@$ûÃ\000\021es_ES.DIS_8859-15ep.co.gz\000\000\000\000\000\000Ò\235ÀP\232~À\000.\225ÀH\022¢À\000\000\000\000@ÔêÃ\200|ûÃÀÓêÃ\000\typ_main.ccay.tzanywhere.al\000\000\000\000\000¾\234À\000Ó\226À\200Ô¢À\210¿\227À\200Ô¢À\200µìÃ\000qõÃ\000µìÃ\000\tlog2.3.gz.gz\000\000\\ã}Àgz\000\000.3.gz\000"...}}, M_databuf = "\006\024]\023\000\000\000\000\000¸}À", '\000' <repeats 32 times>, "@O\212À\000ù À\200É\237ÀÈã\224À \000\000\000\000À$ûÃ@\031éÃ@$ûÃ\000\021es_ES.DIS_8859-15ep.co.gz\000\000\000\000\000\000Ò\235ÀP\232~À\000.\225ÀH\022¢À\000\000\000\000@ÔêÃ\200|ûÃÀÓêÃ\000\typ_main.ccay.tzanywhere.al\000\000\000\000\000¾\234À\000Ó\226À\200Ô¢À\210¿\227À\200Ô¢À\200µìÃ\000qõÃ\000µìÃ\000\tlog2.3.gz.gz\000\000\\ã"...}}
(kgdb)
Script done on Mon Oct 30 16:23:03 2000
In transmit_event, the bridging code passes pkt to m_pullup as if it was
an mbuf. I think pkt is not a valid mbuf, so m_pullup is panicing. The
only thing I could see that looked odd is that the M_EXT flag is set,
but m_ext.ext_buf is NULL.
I'm going to continue to investigate, but I don't know enough about the
kernel's networking code to make much sense of this. Hopefully Luigi can
find time to have a look at this and save us.
--
Lachlan O'Dea <mailto:lodea@vet.com.au> Computer Associates Pty Ltd
Webmaster Vet - Anti-Virus Software
http://www.vet.com.au/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010300600.WAA84682>