kern/107431: Regular kernel panics related to ipv6 interface management/manipulation

Tue Jan 2 06:00:36 PST 2007

>Number:         107431
>Category:       kern
>Synopsis:       Regular kernel panics related to ipv6 interface management/manipulation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 02 14:00:35 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Michael Nottebrock
>Release:        6.1-RELEASE-p10
>Organization:
>Environment:
FreeBSD lofi.dyndns.org 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #8: Sun Nov 19 05:15:03 CET 2006     lofi at lofi.dyndns.org:/usr/obj/usr/src/sys/LOFI.ULE  i386
>Description:
I have been getting this and similar kernel panics on a regular, but overall rare basis for a very long time, in FreeBSD 6.0-RELEASE and 6.1-RELEASE. However, I've only recently been able to turn on crashdumps and thus submit this bug report.

The machine has an ipv6 tunnel connection via freenet6, managed by freenet6's tunnel setup utility, tspc (in FreeBSD ports under net/freenet6). It is connected to the internet over a DSL line, with an automatic disconnect every 24 hours. The ipv6 tunnel interface is destroyed before the ipv4 connection goes down and re-setup once the ipv4 connection is back up. The panics however do not always occur around that time, this last one which I pasted below for instance occurred about five hours after the DSL "redial". Traffic on the ipv6 tunnel is very moderate, but constant (ntp).

Panic message and backtrace, gathered from crashdump with kgdb:

[lofi at lofi]:0:/home/lofi # kgdb /usr/obj/usr/src/sys/LOFI.ULE/kernel.debug /usr/crash/vmcore.79
[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".

Unread portion of the kernel message buffer:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x6c6983fc
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc0567a63
stack pointer           = 0x28:0xdac3ab70
frame pointer           = 0x28:0xdac3ab80
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         = 2842 (ifconfig)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 11d23h49m19s
Dumping 511 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15

#0  doadump () at pcpu.h:165
165     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc04f8558 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2  0xc04f8881 in panic (fmt=0xc06b993e "%s") at /usr/src/sys/kern/kern_shutdown.c:558
#3  0xc068f140 in trap_fatal (frame=0xdac3ab30, eva=1818854396) at /usr/src/sys/i386/i386/trap.c:836
#4  0xc068ee7f in trap_pfault (frame=0xdac3ab30, usermode=0, eva=1818854396) at /usr/src/sys/i386/i386/trap.c:744
#5  0xc068ead9 in trap (frame=
      {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1818853760, tf_esi = 1920169263, tf_ebp = -624710784, tf_isp = -624710820, tf_ebx = -999521920, tf_edx = -1008841600, tf_ecx = 4, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1068074397, tf_cs = 32, tf_eflags = 66178, tf_esp = -1067635198, tf_ss = -999521920}) at /usr/src/sys/i386/i386/trap.c:434
#6  0xc067c3da in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0567a63 in if_delmulti (ifp=0x6c698180, sa=0x7273752f) at atomic.h:146
#8  0xc05cd1fb in in6_delmulti (in6m=0xc472a280) at /usr/src/sys/netinet6/mld6.c:649
#9  0xc05c09f8 in in6_ifdetach (ifp=0xc37bd400) at /usr/src/sys/netinet6/in6_ifattach.c:806
#10 0xc0565485 in if_detach (ifp=0xc37bd400) at /usr/src/sys/net/if.c:658
#11 0xc056a7e4 in gif_destroy (sc=0xc5737780) at /usr/src/sys/net/if_gif.c:209
#12 0xc056a896 in gif_clone_destroy (ifp=0x4) at /usr/src/sys/net/if_gif.c:226
#13 0xc0568d9e in ifc_simple_destroy (ifc=0xc070adc0, ifp=0x4) at /usr/src/sys/net/if_clone.c:478
#14 0xc05683c9 in if_clone_destroy (name=0xc3e21940 "gif0") at /usr/src/sys/net/if_clone.c:172
#15 0xc0566f5c in ifioctl (so=0xc4fae6f4, cmd=2149607801, data=0xc3e21940 "gif0", td=0xc3de4c80) at /usr/src/sys/net/if.c:1508
#16 0xc05225c3 in soo_ioctl (fp=0x4, cmd=2149607801, data=0xc3e21940, active_cred=0xc3989900, td=0xc3de4c80) at /usr/src/sys/kern/sys_socket.c:214
#17 0xc051ca2d in ioctl (td=0xc3de4c80, uap=0xdac3ad04) at file.h:258
#18 0xc068f487 in syscall (frame=
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077941088, tf_esi = -1077940864, tf_ebp = -1077943304, tf_isp = -624710300, tf_ebx = 134570752, tf_edx = 134581885, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 672368511, tf_cs = 51, tf_eflags = 642, tf_esp = -1077943332, tf_ss = 59})
    at /usr/src/sys/i386/i386/trap.c:981
#19 0xc067c42f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#20 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

>How-To-Repeat:
Not easily - I haven't found a way to trigger the problem at will. Given that freenet6's tunnel is not very stable, and thus assuming that the gif0 interface probably goes up and down twice a day on average (counting once for the cronjob on DSL-redial and counting once for random service outage), my guess is that roundabout every 30-40 'ifconfig gif0 up/down' (not sure what tspc really does with it) invocations, the machine will panic.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: