From owner-freebsd-stable Tue Jul 16 12:22:44 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3426E37B400 for ; Tue, 16 Jul 2002 12:22:39 -0700 (PDT) Received: from gx.dnepr.net (gx.dnepr.net [217.198.131.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C2C43E4A for ; Tue, 16 Jul 2002 12:22:37 -0700 (PDT) (envelope-from land@gx.dnepr.net) Received: from gx.dnepr.net (localhost.dnepr.net [127.0.0.1]) by gx.dnepr.net with ESMTP id g6GJMYgj045142 for ; Tue, 16 Jul 2002 22:22:34 +0300 (EEST) (envelope-from land@gx.dnepr.net) Received: (from land@localhost) by gx.dnepr.net id g6GJMYBo045141 for stable@freebsd.org; Tue, 16 Jul 2002 22:22:34 +0300 (EEST) (envelope-from land) Date: Tue, 16 Jul 2002 22:22:34 +0300 From: Andrey Lakhno To: stable@freebsd.org Subject: Re: weird kernel panics Message-ID: <20020716192234.GA44689@gx.dnepr.net> References: <20020716153506.GA41125@gx.dnepr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020716153506.GA41125@gx.dnepr.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi ! On Tue, 16 Jul 2002, Andrey Lakhno wrote: > I use FreeBSD 4.6-R with zebra routing software (zebra-0.93a). > Both ripd and ospfd is running. With non-zero probability, when I kill ripd > or ospfd process, system panics with the following diagnostics: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x6 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01856c7 > stack pointer = 0x10:0xca01bc90 > frame pointer = 0x10:0xca01bca4 > 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 = 629 (ripd) > interrupt mask = net > trap number = 12 > panic: page fault > > syncing disks... 40 2 1 1 1 1 1 1 1 > done > > I found that such panics occurs only on machines with vlan interfaces. > > Here is output from gdb -k: > > (kgdb) where > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > #1 0xc01445bf in boot (howto=256) at ../../kern/kern_shutdown.c:316 > #2 0xc01449e4 in poweroff_wait (junk=0xc0211d6c, howto=-1071572849) > at ../../kern/kern_shutdown.c:595 > #3 0xc01eb71e in trap_fatal (frame=0xca01bc50, eva=6) > at ../../i386/i386/trap.c:966 > #4 0xc01eb3f1 in trap_pfault (frame=0xca01bc50, usermode=0, eva=6) > at ../../i386/i386/trap.c:859 > #5 0xc01eafdb in trap (frame={tf_fs = -1071448048, tf_es = 6422544, > tf_ds = -1066074096, tf_edi = -1066046208, tf_esi = 1, > tf_ebp = -905855836, tf_isp = -905855876, tf_ebx = -1053640192, > tf_edx = 6, tf_ecx = -905855812, tf_eax = 2, tf_trapno = 12, tf_err = 0, > tf_eip = -1072146745, tf_cs = 8, tf_eflags = 66050, > tf_esp = -1053640192, tf_ss = -1052190624}) at ../../i386/i386/trap.c:458 > #6 0xc01856c7 in rt_msg1 (type=16, rtinfo=0xca01bcbc) > at ../../net/rtsock.c:613 > #7 0xc0185b35 in rt_newmaddrmsg (cmd=16, ifma=0xc148d860) > at ../../net/rtsock.c:848 > #8 0xc018020c in if_delmulti (ifp=0xc132ba00, sa=0xca01bd3c) > at ../../net/if.c:1507 > #9 0xc01818f5 in vlan_setmulti (ifp=0xc132b400) at ../../net/if_vlan.c:154 > #10 0xc0182416 in vlan_ioctl (ifp=0xc132b400, cmd=2149607730, data=0x0) > at ../../net/if_vlan.c:704 > #11 0xc01802e6 in if_delmulti (ifp=0xc132b400, sa=0xc0724040) > at ../../net/if.c:1548 > #12 0xc0188b6f in in_delmulti (inm=0xc14c4820) at ../../netinet/in.c:893 > #13 0xc019352c in ip_freemoptions (imo=0xc14fba00) > at ../../netinet/ip_output.c:1886 > #14 0xc01894ad in in_pcbdetach (inp=0xc93dbfc0) at ../../netinet/in_pcb.c:567 > #15 0xc019b418 in udp_detach (so=0xc931e940) at ../../netinet/udp_usrreq.c:871 > #16 0xc0162511 in soclose (so=0xc931e940) at ../../kern/uipc_socket.c:320 > #17 0xc0156a56 in soo_close (fp=0xc14ad600, p=0xc890d6c0) > at ../../kern/sys_socket.c:195 > #18 0xc013a2df in fdrop (fp=0xc14ad600, p=0xc890d6c0) at ../../sys/file.h:217 > #19 0xc013a227 in closef (fp=0xc14ad600, p=0xc890d6c0) > at ../../kern/kern_descrip.c:1277 > #20 0xc0139629 in close (p=0xc890d6c0, uap=0xca01bf80) > at ../../kern/kern_descrip.c:581 > #21 0xc01eb9cd in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > tf_edi = -1077937712, tf_esi = 0, tf_ebp = -1077938364, > tf_isp = -905855020, tf_ebx = 134973184, tf_edx = 134754364, > tf_ecx = 134956992, tf_eax = 6, tf_trapno = 12, tf_err = 2, > tf_eip = 672846696, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938408, > tf_ss = 47}) at ../../i386/i386/trap.c:1167 > #22 0xc01dfe15 in Xint0x80_syscall () > #23 0x8049ab8 in ?? () > #24 0xbfbfffac in ?? () > #25 0x8049d47 in ?? () > #26 0x8049909 in ?? () > > (kgdb) up 5 > #5 0xc01eafdb in trap (frame={tf_fs = -1071448048, tf_es = 6422544, > tf_ds = -1066074096, tf_edi = -1066046208, tf_esi = 1, > tf_ebp = -905855836, tf_isp = -905855876, tf_ebx = -1053640192, > tf_edx = 6, tf_ecx = -905855812, tf_eax = 2, tf_trapno = 12, tf_err = 0, > tf_eip = -1072146745, tf_cs = 8, tf_eflags = 66050, > tf_esp = -1053640192, tf_ss = -1052190624}) at ../../i386/i386/trap.c:458 > 458 (void) trap_pfault(&frame, FALSE, eva); > > (kgdb) frame frame->tf_ebp frame->tf_eip > #0 rt_msg1 (type=16, rtinfo=0xca01bcbc) at ../../net/rtsock.c:614 > 614 dlen = ROUNDUP(sa->sa_len); > > (kgdb) list > 609 bzero((caddr_t)rtm, len); > 610 for (i = 0; i < RTAX_MAX; i++) { > 611 if ((sa = rtinfo->rti_info[i]) == NULL) > 612 continue; > 613 rtinfo->rti_addrs |= (1 << i); > 614 dlen = ROUNDUP(sa->sa_len); > 615 m_copyback(m, len, dlen, (caddr_t)sa); > 616 len += dlen; > 617 } > 618 if (m->m_pkthdr.len != len) { > > (kgdb) print sa > $1 = (struct sockaddr *) 0x0 I do not familiar with kernel internals and kernel debugging. So I just wondering how could sa == (struct sockaddr *) 0x0 ? We explicitly checked that sa != NULL 2 lines higher: if ((sa = rtinfo->rti_info[i]) == NULL) continue; -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message