From nobody@FreeBSD.org  Mon Aug 26 05:06:24 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D37D137B400
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 26 Aug 2002 05:06:24 -0700 (PDT)
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5C37743E42
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 26 Aug 2002 05:06:24 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g7QC6OOT077792
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 26 Aug 2002 05:06:24 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.4/8.12.4/Submit) id g7QC6Nh8077791;
	Mon, 26 Aug 2002 05:06:24 -0700 (PDT)
Message-Id: <200208261206.g7QC6Nh8077791@www.freebsd.org>
Date: Mon, 26 Aug 2002 05:06:24 -0700 (PDT)
From: "Pawe&#322; Ma&#322;achowski" <pawmal@unia.3lo.lublin.pl>
To: freebsd-gnats-submit@FreeBSD.org
Subject: panic when zebra works on detaching tun interface
X-Send-Pr-Version: www-1.0

>Number:         42030
>Category:       kern
>Synopsis:       panic when zebra works on detaching tun interface
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 26 05:10:01 PDT 2002
>Closed-Date:    Tue Dec 13 00:46:16 GMT 2005
>Last-Modified:  Tue Dec 13 00:46:16 GMT 2005
>Originator:     Pawe&#322; Ma&#322;achowski
>Release:        4.6.2-RELEASE
>Organization:
ZiN
>Environment:
FreeBSD gargantua.zin.git 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #2: Sun Aug 25 17:03:15 CEST 2002     root@gargantua.zin.git:/usr/src/sys/compile/PM-UX-AUTO  i386

>Description:
      System acts as a Zebra-based (net/zebra) OSPF router. Tun interfaces are used with vtund (net/vtun) as virtual, compressed connections to other machines outside LAN.
When the vtund disconnects tunnel, *sometimes* the kernel panic occurs. It happens a couple of times per day.
When Zebra is not running, there is no problem.
The other side of tunnel (FreeBSD 4.6-STABLE) is not running Zebra yet so I don't know are others affected or not.

Kernel sources are up to date. Kernel config is a GENERIC with additional options as shown here:
pseudo-device   ccd     4
device          apm0    # GENERIC apm0 with flags declaration is comment-out
pseudo-device   speaker
pseudo-device   snp     3
options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_FORWARD
options         IPFIREWALL_VERBOSE_LIMIT=100
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPFILTER
options         IPFILTER_LOG
options         IPFILTER_DEFAULT_BLOCK
options QUOTA
options DUMMYNET
options         SHMMAXPGS=65536
options         SEMMNI=40
options         SEMMNS=240
options         SEMUME=40
options         SEMMNU=120

The example vtund.conf section is:
foo-blah {
  pass xxx;
  device tun10;
  up {
        ifconfig "%% 10.61.7.254 10.61.7.253 netmask 255.255.255.255";
  };
  down {
        ifconfig "%% delete 10.61.7.254";
  };
}

Debug output:
# ./gdbmods /sys/compile/PM-UX-AUTO/kernel.debug vmcore.0
please be patient while loaded modules are resolved
gdbmods using kernel: /sys/compile/PM-UX-AUTO/kernel.debug
gdbmods using core:   vmcore.0
GNU gdb 4.18 (FreeBSD)
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 at phsyical address 0x0050e000
initial pcb at physical address 0x0044aec0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0249809
stack pointer           = 0x10:0xcdf81d1c
frame pointer           = 0x10:0xcdf81d28
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         = 342 (zebra)
interrupt mask          =
trap number             = 12
panic: page fault

syncing disks... 16 10 5
done
Uptime: 13m14s

// snipped some messages when I've turned on debugging and added dumpdev and rebooted again

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 4.6.2-RELEASE #2: Sun Aug 25 17:03:15 CEST 2002
    root@gargantua.zin.git:/usr/src/sys/compile/PM-UX-AUTO
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (952.17-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 268353536 (262064K bytes)
config> di sn0
config> di lnc0
config> di ie0
config> di fe0
config> di ed0
config> di cs0
config> di bt0
config> di aic0
config> di aha0
config> di adv0
config> q
avail memory = 256073728 (250072K bytes)
Preloaded elf kernel "kernel" at 0xc04ef000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc04ef09c.
ccd0-3: Concatenated disk drivers
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 9 entries at 0xc00f12d0
apm0: <APM BIOS> on motherboard
apm: found APM BIOS v1.2, connected at v1.2
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib2: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib2
pci1: <S3 Trio3D graphics accelerator> at 0.0
isab0: <VIA 82C686 PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 82C686 ATA100 controller> port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: <VIA 83C572 USB controller> port 0xd400-0xd41f irq 11 at device 4.2 on pci0
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0xd000-0xd01f irq 11 at device 4.3 on pci0
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0: <unknown card> (vendor=0x1106, dev=0x3057) at 4.4
rl0: <RealTek 8139 10/100BaseTX> port 0xb800-0xb8ff mem 0xf7800000-0xf78000ff irq 10 at device 7.0 on pci0
rl0: Ethernet address: 00:02:44:23:82:c4
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xb400-0xb47f mem 0xf7000000-0xf700007f irq 11 at device 10.0 on pci0
xl0: Ethernet address: 00:a0:24:aa:1b:95
miibus1: <MII bus> on xl0
xlphy0: <3Com internal media interface> on miibus1
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xb000-0xb07f mem 0xf6800000-0xf680007f irq 10 at device 11.0 on pci0
xl1: Ethernet address: 00:10:5a:f0:96:77
miibus2: <MII bus> on xl1
xlphy1: <3Com internal media interface> on miibus2
xlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcib1: <Host to PCI bridge> on motherboard
pci2: <PCI bus> on pcib1
orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0
fdc0: ready for input in output
fdc0: cmd 3 failed at out byte 1 of 3
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default
DUMMYNET initialized (011031)
IP Filter: v3.4.27 initialized.  Default = block all, Logging = enabled
ata1-slave: ATA identify retries exceeded
ata1-master: ATA identify retries exceeded
ad0: 38166MB <ST340810A> [77545/16/63] at ata0-master UDMA100
Mounting root from ufs:/dev/ad0s1a
xl1: promiscuous mode enabled
xl0: promiscuous mode enabled
xl0: promiscuous mode disabled
rl0: promiscuous mode enabled
rl0: promiscuous mode disabled
xl0: promiscuous mode enabled
rl0: promiscuous mode enabled
tun5: promiscuous mode enabled
tun5: promiscuous mode disabled
tun5: promiscuous mode enabled
tun5: promiscuous mode disabled
tun10: promiscuous mode enabled
tun10: promiscuous mode disabled
tun10: promiscuous mode enabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0249839
stack pointer           = 0x10:0xcdf65d1c
frame pointer           = 0x10:0xcdf65d28
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         = 306 (zebra)
interrupt mask          =
trap number             = 12
panic: page fault

syncing disks... 9 3
done
Uptime: 5h7m18s

dumping to dev #ad/0x30001, offset 1573024
dump ata0: resetting devices .. done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 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
---
#0  dumpsys () at ../../kern/kern_shutdown.c:487
487             if (dumping++) {
(kgdb) bt
#0  dumpsys () at ../../kern/kern_shutdown.c:487
#1  0xc01f9ae3 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2  0xc01f9f08 in poweroff_wait (junk=0xc03da0ec, howto=-1069704177)
    at ../../kern/kern_shutdown.c:595
#3  0xc036a052 in trap_fatal (frame=0xcdf65cdc, eva=4)
    at ../../i386/i386/trap.c:966
#4  0xc0369d25 in trap_pfault (frame=0xcdf65cdc, usermode=0, eva=4)
    at ../../i386/i386/trap.c:859
#5  0xc03698e3 in trap (frame={tf_fs = -839516144, tf_es = -1048379376,
      tf_ds = -1069547504, tf_edi = -1048217856, tf_esi = -1048348944,
      tf_ebp = -839492312, tf_isp = -839492344, tf_ebx = 0, tf_edx = -1048217856,
      tf_ecx = 1, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071343559,
      tf_cs = 8, tf_eflags = 66118, tf_esp = -839492200, tf_ss = -1049736192})
    at ../../i386/i386/trap.c:458
#6  0xc0249839 in arp_rtrequest (req=1, rt=0xc1857700, info=0xcdf65d98)
    at ../../netinet/if_ether.c:188
#7  0xc02472a8 in rtrequest1 (req=1, info=0xcdf65d98, ret_nrt=0xcdf65d94)
    at ../../net/route.c:754
#8  0xc0247cc1 in route_output (m=0xc0ed4b00, so=0xccd21300)
    at ../../net/rtsock.c:333
#9  0xc0246742 in raw_usend (so=0xccd21300, flags=0, m=0xc0ed4b00, nam=0x0,
    control=0x0, p=0xcdf4b920) at ../../net/raw_usrreq.c:258
#10 0xc0247a84 in rts_send (so=0xccd21300, flags=0, m=0xc0ed4b00, nam=0x0,
    control=0x0, p=0xcdf4b920) at ../../net/rtsock.c:236
#11 0xc02181af in sosend (so=0xccd21300, addr=0x0, uio=0xcdf65ed4, top=0xc0ed4b00,
    control=0x0, flags=0, p=0xcdf4b920) at ../../kern/uipc_socket.c:609
#12 0xc020bd68 in soo_write (fp=0xc1832f40, uio=0xcdf65ed4, cred=0xc1810d80,
    flags=0, p=0xcdf4b920) at ../../kern/sys_socket.c:81
#13 0xc0208a1d in dofilewrite (p=0xcdf4b920, fp=0xc1832f40, fd=6, buf=0xbfbfe868,
    nbyte=128, offset=-1, flags=0) at ../../sys/file.h:162
#14 0xc02088d6 in write (p=0xcdf4b920, uap=0xcdf65f80)
    at ../../kern/sys_generic.c:329
#15 0xc036a301 in syscall2 (frame={tf_fs = -1078001617, tf_es = -1078001617,
---Type <return> to continue, or q <return> to quit---
      tf_ds = -1078001617, tf_edi = 128, tf_esi = 134745644, tf_ebp = -1077941520,
      tf_isp = -839491628, tf_ebx = 16, tf_edx = 128, tf_ecx = 0, tf_eax = 4,
      tf_trapno = 7, tf_err = 2, tf_eip = 672392940, tf_cs = 31, tf_eflags = 663,
      tf_esp = -1077942220, tf_ss = 47}) at ../../i386/i386/trap.c:1167
#16 0xc035b3f5 in Xint0x80_syscall ()
#17 0x8064ce1 in ?? ()
#18 0x8064d2d in ?? ()
#19 0x804f542 in ?? ()
#20 0x804f75e in ?? ()
#21 0x804fccb in ?? ()
#22 0x804e12e in ?? ()
#23 0x804e1a2 in ?? ()
#24 0x80656f1 in ?? ()
#25 0x8065edb in ?? ()
#26 0x805f1c2 in ?? ()
#27 0x804c30d in ?? ()
#28 0x804992d in ?? ()
(kgdb) q

Promiscuous mode was enabled because of a diagnostic tcpdump.
>How-To-Repeat:
      As above, try to estabilish and disconnect tunnels when Zebra is running on it.
Note: kernel panic happens only sometimes. But when the panic comes, there is always zebra (not ospfd) process as "current process".
>Fix:
      Don't know.
>Release-Note:
>Audit-Trail:

From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/42030: panic when zebra works on detaching tun interface
Date: Sun, 22 Jun 2003 23:02:58 +0200

 This bug is still present in fresh 4.8-STABLE.
 Kernel is GENERIC with IPFILTER and debug symbols added:
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x4
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0285d75
 stack pointer           = 0x10:0xd56bbd1c
 frame pointer           = 0x10:0xd56bbd28
 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         = 480 (zebra)
 interrupt mask          =
 trap number             = 12
 panic: page fault
 
 syncing disks... 41 36 32 28 24 21 18 14 12 8 7 4 3 1
 done
 Uptime: 26m28s
 
 dumping to dev #ad/0x30001, offset 1573024
 dump ata0: resetting devices .. done
 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 
 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 
 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 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
 ---
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 487             if (dumping++) {
 (kgdb) bt
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 #1  0xc0234db7 in boot (howto=256) at ../../kern/kern_shutdown.c:316
 #2  0xc02351dc in poweroff_wait (junk=0xc042b00c, howto=-1069372657)
     at ../../kern/kern_shutdown.c:595
 #3  0xc03a876e in trap_fatal (frame=0xd56bbcdc, eva=4)
     at ../../i386/i386/trap.c:974
 #4  0xc03a8441 in trap_pfault (frame=0xd56bbcdc, usermode=0, eva=4)
     at ../../i386/i386/trap.c:867
 #5  0xc03a7fff in trap (frame={tf_fs = -714407920, tf_es = -955777008,
       tf_ds = -955187184, tf_edi = -955124992, tf_esi = -955741136,
       tf_ebp = -714359512, tf_isp = -714359544, tf_ebx = 0, tf_edx = -955124992,
       tf_ecx = 1, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071096459,
       tf_cs = 8, tf_eflags = 66118, tf_esp = -714359400, tf_ss = -956732672})
     at ../../i386/i386/trap.c:466
 #6  0xc0285d75 in arp_rtrequest (req=1, rt=0xc711f300, info=0xd56bbd98)
     at ../../netinet/if_ether.c:186
 #7  0xc02837d6 in rtrequest1 (req=1, info=0xd56bbd98, ret_nrt=0xd56bbd94)
     at ../../net/route.c:750
 #8  0xc0284219 in route_output (m=0xc0eddf00, so=0xd2983ec0)
     at ../../net/rtsock.c:341
 #9  0xc0282c5a in raw_usend (so=0xd2983ec0, flags=0, m=0xc0eddf00, nam=0x0,
     control=0x0, p=0xd569c440) at ../../net/raw_usrreq.c:258
 #10 0xc0283fb0 in rts_send (so=0xd2983ec0, flags=0, m=0xc0eddf00, nam=0x0,
     control=0x0, p=0xd569c440) at ../../net/rtsock.c:236
 #11 0xc0253d3b in sosend (so=0xd2983ec0, addr=0x0, uio=0xd56bbed4, top=0xc0eddf00,
     control=0x0, flags=0, p=0xd569c440) at ../../kern/uipc_socket.c:609
 #12 0xc024740c in soo_write (fp=0xc70fc880, uio=0xd56bbed4, cred=0xc6feb300,
     flags=0, p=0xd569c440) at ../../kern/sys_socket.c:81
 #13 0xc0243f31 in dofilewrite (p=0xd569c440, fp=0xc70fc880, fd=6, buf=0xbfbff210,
     nbyte=128, offset=-1, flags=0) at ../../sys/file.h:163
 #14 0xc0243dea in write (p=0xd569c440, uap=0xd56bbf80)
     at ../../kern/sys_generic.c:329
 #15 0xc03a8a1d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
       tf_edi = 128, tf_esi = 134749996, tf_ebp = -1077939048, tf_isp = -714358828,
       tf_ebx = 16, tf_edx = 128, tf_ecx = 0, tf_eax = 4, tf_trapno = 7,
       tf_err = 2, tf_eip = 672812008, tf_cs = 31, tf_eflags = 643,
       tf_esp = -1077939748, tf_ss = 47}) at ../../i386/i386/trap.c:1175
 #16 0xc03998d5 in Xint0x80_syscall ()
 #17 0x80650c5 in ?? ()
 #18 0x8065111 in ?? ()
 #19 0x804f5e6 in ?? ()
 #20 0x804f802 in ?? ()
 #21 0x804fae2 in ?? ()
 #22 0x804af2d in ?? ()
 #23 0x804b821 in ?? ()
 #24 0x805f5a6 in ?? ()
 #25 0x804c395 in ?? ()
 #26 0x80499b5 in ?? ()
 (kgdb) up 6
 #6  0xc0285d75 in arp_rtrequest (req=1, rt=0xc711f300, info=0xd56bbd98)
     at ../../netinet/if_ether.c:186
 186                     if ((rt->rt_flags & RTF_HOST) == 0 &&
 (kgdb) list
 181                     /*
 182                      * XXX: If this is a manually added route to interface
 183                      * such as older version of routed or gated might provide,
 184                      * restore cloning bit.
 185                      */
 186                     if ((rt->rt_flags & RTF_HOST) == 0 &&
 187                         SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff)
 188                             rt->rt_flags |= RTF_CLONING;
 189                     if (rt->rt_flags & RTF_CLONING) {
 190                             /*
 (kgdb) print rt
 $1 = (struct rtentry *) 0xc711f300
 (kgdb) x rt->rt_flags
 0x18001:        Cannot access memory at address 0x18001.
 (kgdb) x rt
 0xc711f300:     0x00000000
 
 > >How-To-Repeat:
 >       As above, try to estabilish and disconnect tunnels when Zebra is running on it.
 > Note: kernel panic happens only sometimes. But when the panic comes, there is always zebra (not ospfd) process as "current process".
 
 There's no need to run vtund, I can reproduce it this way:
 # zebra -d -A 127.0.0.1
 # ospfd -d -A 127.0.0.1
 # ifconfig tun4
 ifconfig: interface tun4 does not exist
 # echo ''>/dev/tun4
 # ifconfig tun4
 tun4: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
 # ifconfig tun4 inet 192.168.0.1 192.168.0.2 netmask 255.255.255.255
 [panic]
 
 
 zebra.conf:
 
 hostname gz
 password xxx
 enable password xxx
 log file /var/log/zebra.log
 line vty
 exec-timeout 0 0
 
 
 
 ospfd.conf:
 
 hostname go
 password xxx
 enable password xxx
 log file /var/log/zebra-ospfd.log
 router ospf
  ospf router-id 1.2.3.4
  network 192.168.0.2/32 area 0
 line vty
 exec-timeout 0 0
 
 
 
 -- 
 Pawe Maachowski
 
 

From: "Ted Mittelstaedt" <tedm@toybox.placo.com>
To: <freebsd-gnats-submit@FreeBSD.org>, <pawmal@unia.3lo.lublin.pl>
Cc:  
Subject: Re: kern/42030: panic when zebra works on detaching tun interface
Date: Thu, 11 Sep 2003 00:18:44 -0700

 The following was posted to the quagga-users mailing list on 9/9/2003
 regarding this bug.  (quagga is the sucessor to Zebra and uses zebra as it's
 codebase)  Recommend this PR be closed and the submitter be referred to
 the Zebra/Quagga author, as this bug is obviously an application problem,
 not a kernel problem.
 
 Ted
 
 Subject: [quagga-users 417] bug with vtun and ospf
 
 Hello,
 
 Well, all is in this post :
 http://lists.freebsd.org/pipermail/freebsd-bugs/2003-June/001382.html
 
 I have the same problem, with a linux 2.4.21 (a debian) with vtund and
 ospfd running. Sometimes, when I shutdown a tunnel, ospfd crashes.
 
 If you need more details, just ask me.
 
 Thank you by advance for you help,
 --
 Guillaume Rousseau
 
 _______________________________________________
 Quagga-users mailing list
 Quagga-users@lists.quagga.net
 http://lists.quagga.net/mailman/listinfo/quagga-users
 

From: "Pawel Malachowski" <pawmal-posting@freebsd.lublin.pl>
To: "Ted Mittelstaedt" <tedm@toybox.placo.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/42030: panic when zebra works on detaching tun interface
Date: Fri, 19 Sep 2003 00:26:17 +0200

 On 11 Sep 2003 at 0:18, Ted Mittelstaedt wrote:
 
 Hello,
 
 > The following was posted to the quagga-users mailing list on 9/9/2003
 > regarding this bug.  (quagga is the sucessor to Zebra and uses zebra as it's
 > codebase)  Recommend this PR be closed and the submitter be referred to
 > the Zebra/Quagga author, as this bug is obviously an application problem,
 > not a kernel problem.
 
 When my kernel panics, it is a kernel o problem. Note, my PR provides
 kernel backtrace.
 I don't say ospfd has no bugs of course. Maybe some bug in ospfd triggers
 some other bug in FreeBSD kernel? I can be wrong cause it was a long time
 ago, but I had a feeling that kernel tries to deal with host route as if
 it was net route (inconsistent rt_flags). Unfortunetly, there is no kernel
 hacker interested in looking closer at this.
 
 > http://lists.freebsd.org/pipermail/freebsd-bugs/2003-June/001382.html
 
 
 -- 
 Pawe Maachowski
 

From: "Ted Mittelstaedt" <tedm@toybox.placo.com>
To: "Pawel Malachowski" <pawmal-posting@freebsd.lublin.pl>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Subject: RE: kern/42030: panic when zebra works on detaching tun interface
Date: Thu, 18 Sep 2003 21:42:52 -0700

 OK, your right, I was being too simplistic.
 
 It is a kernel problem - but only insofar that what the FreeBSD kernel
 _should_
 be doing is be smart enough to recognize that Zebra is doing something
 wrong and make it dump core.  Same with Linux - the Linux kernel
 (which also panics with Zebra doing the same thing) should be doing
 this too.
 
 Basically your going about this backwards - your trying to get a FreeBSD
 kernel hacker to fix FreeBSD and tell you exactly what the Zebra program
 is doing wrong, so you can go to the Zebra people and the work of chasing
 the bug is done for them.  This is understandable given the total lack of
 response of Kunihiro to fixing bugs in Zebra unless they are handed to
 him on a silver platter.  But morally, since Zebra makes both Linux and
 FreeBSD kernels panic (totally different kernels, mind) when doing this,
 the Zebra maintainer should be the one to do the work fixing the Zebra code
 first, don't you think?
 
 Setting aside that, even if a FreeBSD kernel hacker does look into this, the
 result is not going to help you - the only thing that's going to happen is
 that perhaps
 the FreeBSD kernel won't panic anymore.  But the Zebra program will
 still be broken.  Since the goal of most people is to get a working
 application,
 it seems that the speedier way to this goal is to get the Zebra
 (ie: Quagga) people to fix it.  Then once they do, they can tell you exactly
 what causes the panic - then you can write a nice little test code fragment
 and retitle the PR something such as "FreeBSD kernel doesen't
 handle this XYZ condition properly"
 
 Ted
 
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Wed 1 Oct 2003 02:15:51 PDT 
Responsible-Changed-Why:  
I have a good working relationship with the Quagga people, so I'll 
endeavour to follow this up with them. (Quagga is a fork of Zebra 
where people are actually fixing bugs. This looks like one.) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 
State-Changed-From-To: open->feedback 
State-Changed-By: bms 
State-Changed-When: Tue 25 Nov 2003 07:08:14 PST 
State-Changed-Why:  
I was unable to reproduce the bug on the following:- 

kimchi# uname -a 
FreeBSD go 5.2-BETA FreeBSD 5.2-BETA #4: Sun Nov 23 01:52:10 GMT 2003     bms@kimchi.dek.spc.org:/usr/src/sys/i386/compile/KIMCHI  i386 
kimchi# zebra -v 
zebra version 0.96.4 (i386-portbld-freebsd5.2) 
Copyright 1996-2001, Kunihiro Ishiguro 

This is in fact the port quagga-0.96.4_3. 

Note that zebra has changed the hostname. I tried a variety of ifconfig 
activities, deleting, upping, downing, and unloading the if_tun.ko module 
from the kernel whilst ospfd and zebra were running. 

Can submitter attempt to reproduce the bug on 4.9-RELEASE and if possible a 
recent -CURRENT snapshot? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 
State-Changed-From-To: feedback->suspended 
State-Changed-By: bms 
State-Changed-When: Wed Jun 16 02:27:15 GMT 2004 
State-Changed-Why:  
Timeout on feedback 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 

From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: Bruce M Simpson <bms@FreeBSD.org>
Cc:  
Subject: Re: kern/42030: panic when zebra works on detaching tun interface
Date: Sat, 19 Jun 2004 21:56:54 +0200

 On Wed, Jun 16, 2004 at 02:27:29AM +0000, Bruce M Simpson wrote:
 
 Hello,
 
 > Synopsis: panic when zebra works on detaching tun interface
 > 
 > State-Changed-From-To: feedback->suspended
 > State-Changed-By: bms
 > State-Changed-When: Wed Jun 16 02:27:15 GMT 2004
 > State-Changed-Why: 
 > Timeout on feedback
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=42030
 
 You asked me about feedback at:
 	Date sent:	Tue, 25 Nov 2003 07:11:24 -0800 (PST)
 I replied to bms@FreeBSD.org at:
 	Date sent:	Tue, 25 Nov 2003 23:35:52 +0100
 
 I can paste it here once again, since it is not in audit trail. :)
 
 BTW, thanks for dealing with all these old PRs! (I browse freebsd-bugs@
 and cvs-src@ from time to time.)
 
 
 #v+
 
 > Can submitter attempt to reproduce the bug on 4.9-RELEASE and if possible a
 > recent -CURRENT snapshot?
 
 I can reproduce it with RELENG_4.
 Currently I have no chance to test it with -CURRENT.
 
 % uname -a
 FreeBSD gargantua.zin.ask 4.9-STABLE FreeBSD 4.9-STABLE #0: Sun Nov 23 19:10:16 CET 2003     root@gargantua.zin.ask:/mnt/j1/src/sys/compile/PM-GENERIC  i386
 % cat /usr/local/etc/quagga/zebra.conf
  hostname gz
  password xxx
  enable password xxx
  log file /tmp/test-zebra.log
  line vty
  exec-timeout 0 0
 % cat /usr/local/etc/quagga/ospfd.conf
  hostname go
  password xxx
  enable password xxx
  log file /tmp/test-zebra-ospfd.log
  router ospf
   ospf router-id 1.2.3.4
   network 192.168.0.2/32 area 0
  line vty
  exec-timeout 0 0
 % zebra -v
 zebra version 0.96.4 (i386-portbld-freebsd4.9)
 Copyright 1996-2001, Kunihiro Ishiguro
 % zebra -d -A 127.0.0.1
 % ospfd -d -A 127.0.0.1
 % ifconfig tun0
 ifconfig: interface tun0 does not exist
 % echo ''>/dev/tun0
 % ifconfig tun0
 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
 % ifconfig tun0 inet 192.168.0.1 192.168.0.2 netmask 255.255.255.255
 %
 % [enter pressed twice very fast before panic ;)]
 
 Exactly the same with gif(4) interface:
 % ifconfig gif0 inet 192.168.0.1 192.168.0.2 netmask 255.255.255.255
 [panic]
 
 
 Backtrace is the same as usual:
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x4
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc028ad71
 stack pointer           = 0x10:0xce38ad1c
 frame pointer           = 0x10:0xce38ad28
 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         = 27617 (zebra)
 interrupt mask          =
 trap number             = 12
 panic: page fault
 
 syncing disks... 1
 done
 Uptime: 1d22h6m26s
 
 dumping to dev #ad/0x30001, offset 1573024
 dump ata0: resetting devices .. done
 [...]
 (kgdb) bt
 #0  dumpsys () at ../../kern/kern_shutdown.c:487
 #1  0xc023988b in boot (howto=256) at ../../kern/kern_shutdown.c:316
 #2  0xc0239cb0 in poweroff_wait (junk=0xc043962c, howto=-1069313745)
     at ../../kern/kern_shutdown.c:595
 #3  0xc03b42ea in trap_fatal (frame=0xce38acdc, eva=4)
     at ../../i386/i386/trap.c:974
 #4  0xc03b3fbd in trap_pfault (frame=0xce38acdc, usermode=0, eva=4)
     at ../../i386/i386/trap.c:867
 #5  0xc03b3b7b in trap (frame={tf_fs = -835190768, tf_es = -
 1037697008,
       tf_ds = -1044840432, tf_edi = -1044793344, tf_esi = -
 1037634768,
       tf_ebp = -835146456, tf_isp = -835146488, tf_ebx = 0, tf_edx = -
 1044793344,
       tf_ecx = 1, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -
 1071075983,
       tf_cs = 8, tf_eflags = 66118, tf_esp = -835146344, tf_ss = -
 1048661504})
     at ../../i386/i386/trap.c:466
 #6  0xc028ad71 in arp_rtrequest (req=1, rt=0xc1b9b800, 
 info=0xce38ad98)
     at ../../netinet/if_ether.c:186
 #7  0xc02887d2 in rtrequest1 (req=1, info=0xce38ad98, 
 ret_nrt=0xce38ad94)
     at ../../net/route.c:750
 #8  0xc0289215 in route_output (m=0xc0eb7000, so=0xcd11f180)
     at ../../net/rtsock.c:341
 #9  0xc0287c56 in raw_usend (so=0xcd11f180, flags=0, m=0xc0eb7000, 
 nam=0x0,
     control=0x0, p=0xcdf740c0) at ../../net/raw_usrreq.c:258
 #10 0xc0288fac in rts_send (so=0xcd11f180, flags=0, m=0xc0eb7000, 
 nam=0x0,
     control=0x0, p=0xcdf740c0) at ../../net/rtsock.c:236
 #11 0xc0258c8b in sosend (so=0xcd11f180, addr=0x0, uio=0xce38aed4, 
 top=0xc0eb7000,
     control=0x0, flags=0, p=0xcdf740c0) at 
 ../../kern/uipc_socket.c:613
 #12 0xc024c10c in soo_write (fp=0xc1e75000, uio=0xce38aed4, 
 cred=0xc223b700,
     flags=0, p=0xcdf740c0) at ../../kern/sys_socket.c:81
 #13 0xc0248c59 in dofilewrite (p=0xcdf740c0, fp=0xc1e75000, fd=5, 
 buf=0xbfbff1d8,
     nbyte=128, offset=-1, flags=0) at ../../sys/file.h:163
 #14 0xc0248b12 in write (p=0xcdf740c0, uap=0xce38af80)
     at ../../kern/sys_generic.c:329
 #15 0xc03b4599 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 
 47,
       tf_edi = 128, tf_esi = 134912044, tf_ebp = -1077939104, tf_isp 
 = -835145772,
       tf_ebx = 16, tf_edx = 128, tf_ecx = 0, tf_eax = 4, tf_trapno = 
 7,
       tf_err = 2, tf_eip = 672824364, tf_cs = 31, tf_eflags = 663,
       tf_esp = -1077939804, tf_ss = 47}) at 
 ../../i386/i386/trap.c:1175
 #16 0xc03a5645 in Xint0x80_syscall ()
 #17 0x80669b1 in ?? ()
 #18 0x8066a25 in ?? ()
 #19 0x804fa9e in ?? ()
 #20 0x804fd0a in ?? ()
 #21 0x804fff2 in ?? ()
 #22 0x804af33 in ?? ()
 #23 0x804b825 in ?? ()
 #24 0x80606ff in ?? ()
 #25 0x804c515 in ?? ()
 #26 0x8049b72 in ?? ()
 (kgdb) up 6
 #6  0xc028ad71 in arp_rtrequest (req=1, rt=0xc1b9b800, 
 info=0xce38ad98)
     at ../../netinet/if_ether.c:186
 186                     if ((rt->rt_flags & RTF_HOST) == 0 &&
 (kgdb) list
 181                     /*
 182                      * XXX: If this is a manually added route to 
 interface
 183                      * such as older version of routed or gated 
 might provide,
 184                      * restore cloning bit.
 185                      */
 186                     if ((rt->rt_flags & RTF_HOST) == 0 &&
 187                         SIN(rt_mask(rt))->sin_addr.s_addr != 
 0xffffffff)
 188                             rt->rt_flags |= RTF_CLONING;
 189                     if (rt->rt_flags & RTF_CLONING) {
 190                             /*
 
 #v-
 
 
 cheers,
 -- 
 Pawe Maachowski
 
State-Changed-From-To: suspended->open 
State-Changed-By: bms 
State-Changed-When: Sun Jun 20 19:34:03 GMT 2004 
State-Changed-Why:  
Reopened at submitter's request 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 
State-Changed-From-To: open->patched 
State-Changed-By: bms 
State-Changed-When: Tue Oct 26 03:34:22 GMT 2004 
State-Changed-Why:  
Band-aid committed to HEAD. It isn't clear if the root problem is one 
of user routing applications passing something the kernel doesn't 
expect, or if more sanity checking of arguments is required in 
arp_rtrequest(). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 
State-Changed-From-To: patched->closed 
State-Changed-By: bms 
State-Changed-When: Tue Dec 13 00:45:56 UTC 2005 
State-Changed-Why:  
No similar reports since release 
-CURRENT is now -STABLE 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42030 
>Unformatted:
