Date: Sun, 22 Jun 2003 14:10:14 -0700 (PDT) From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/42030: panic when zebra works on detaching tun interface Message-ID: <200306222110.h5MLAEfK040952@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/42030; it has been noted by GNATS.
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ł Małachowski
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306222110.h5MLAEfK040952>