From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 15:54:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9514B16A41F for ; Fri, 2 Sep 2005 15:54:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A22B343D45 for ; Fri, 2 Sep 2005 15:54:09 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j82Fs73g047495; Fri, 2 Sep 2005 19:54:07 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j82Fs6Uk047490; Fri, 2 Sep 2005 19:54:06 +0400 (MSD) (envelope-from yar) Date: Fri, 2 Sep 2005 19:54:06 +0400 From: Yar Tikhiy To: Gavin Atkinson Message-ID: <20050902155406.GA44959@comp.chem.msu.su> References: <1125487485.34476.6.camel@buffy.york.ac.uk> <20050831134927.GA20529@comp.chem.msu.su> <1125594635.63101.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1125594635.63101.3.camel@buffy.york.ac.uk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 15:54:10 -0000 On Thu, Sep 01, 2005 at 06:10:35PM +0100, Gavin Atkinson wrote: > > wiggum# reboot > Sep 1 18:05:05 > wiggum reboot: r > Faooted by root > Sep 1 18:05:05 wiggum syslogd: exiting on signal 15 > tal trap 9: general protection fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x8:0xffffffff80429420 > stack pointer = 0x10:0xffffffffb49c4590 > frame pointer = 0x10:0xffffffffb49c46a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 244 (routed) > [thread pid 244 tid 100101 ] > Stopped at strlen: cmpb $0,0(%rdi) > db> tr > Tracing pid 244 tid 100101 td 0xffffff0061d1b980 > strlen() at strlen > vsnprintf() at vsnprintf+0x2e > panic() at panic+0x14b > _mtx_lock_flags() at _mtx_lock_flags+0xd6 > if_delmulti() at if_delmulti+0x3f > in_delmulti() at in_delmulti+0x4b > ip_freemoptions() at ip_freemoptions+0x30 > in_pcbdetach() at in_pcbdetach+0x182 > udp_detach() at udp_detach+0x51 > soclose() at soclose+0x1a0 > soo_close() at soo_close+0x3f > fdrop_locked() at fdrop_locked+0xa1 > closef() at closef+0x31 > fdfree() at fdfree+0x48a > exit1() at exit1+0x302 > sys_exit() at sys_exit+0xe > syscall() at syscall+0x4b2 > Xfast_syscall() at Xfast_syscall+0xa8 > > Given I've accidentally been able to panic this machine twice in two > days, is there any chance a fix or at least a band-aid will be in place > before the release? It's a shame, but I can't tell for sure. The problem in the IP multicast code is really easy to hit, but it will be rather hard to fix it without major changes to the code. The workaround is to avoid destroying interfaces with multicast groups still joined on them. Both panics you saw seemed to result from the code trying to use memory structures of a now-deceased interface. -- Yar