From owner-freebsd-current@FreeBSD.ORG Fri Dec 3 13:02:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34C41065675; Fri, 3 Dec 2010 13:02:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE2A8FC23; Fri, 3 Dec 2010 13:02:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 37CFC46B82; Fri, 3 Dec 2010 08:02:09 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 20D9E8A029; Fri, 3 Dec 2010 08:02:08 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, obrien@freebsd.org Date: Fri, 3 Dec 2010 07:57:28 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101202194400.GA5003@dragon.NUXI.org> In-Reply-To: <20101202194400.GA5003@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012030757.28675.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 03 Dec 2010 08:02:08 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: [PANIC] after manually issuing 'ifconfig sf0' 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, 03 Dec 2010 13:02:10 -0000 On Thursday, December 02, 2010 2:44:00 pm David O'Brien wrote: > Machine booted, without any mention of sf(4) in rc.conf or loader.conf and > without sf(4) in the core kernel. This is without WITNESS or INVARIANTS. > > >From multi-user, I issued 'ifconfig sf0' and got the below panic. > These are the console messages related to this: > > > FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010 > rootk@dragon:/sys/i386/compile/DRAGON i386 > [..] > Thu Dec 2 09:33:50 PST 2010 > sf0: port 0x5000-0x50ff mem 0xb0400000-0xb047ffff irq 19 at device 4.0 on pci5 > miibus2: on sf0 > ukphy0: PHY 1 on miibus2 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf0: Ethernet address: 00:00:d1:ed:81:95 > sf1: port 0x5400-0x54ff mem 0xb0480000-0xb04fffff irq 16 at device 5.0 on pci5 > miibus3: on sf1 > ukphy1: PHY 1 on miibus3 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf1: Ethernet address: 00:00:d1:ed:81:96 > sf2: port 0x5800-0x58ff mem 0xb0500000-0xb057ffff irq 18 at device 6.0 on pci5 > miibus4: on sf2 > ukphy2: PHY 1 on miibus4 > ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf2: Ethernet address: 00:00:d1:ed:81:97 > sf3: port 0x5c00-0x5cff mem 0xb0580000-0xb05fffff irq 17 at device 7.0 on pci5 > miibus5: on sf3 > ukphy3: PHY 1 on miibus5 > ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf3: Ethernet address: 00:00:d1:ed:81:98 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x238 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc05be315 > stack pointer = 0x28:0xe7a5eab4 > frame pointer = 0x28:0xe7a5eaf4 > 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 = 2590 (mail.local) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c0839222,d31206e,2c66000a,70797420,78302065,...) at 0xc04e9ab6 = db_trace_self_wrapper+0x26 > kdb_backtrace(c0857e2a,0,c0822eb2,e7a5e910,0,...) at 0xc05fa2fa = kdb_backtrace+0x2a > panic(c0822eb2,c0858b68,c59aea18,1,1,...) at 0xc05cd297 = panic+0x117 > trap_fatal(c596d880,0,c0858a20,36b,238,...) at 0xc07dcd65 = trap_fatal+0x325 > trap_pfault(e7a5e9b8,c07fae4d,e7a5e9cc,0,c59ae870,...) at 0xc07dcf40 = trap_pfault+0x1c0 > trap(e7a5ea74) at 0xc07dd5f5 = trap+0x5d5 > calltrap() at 0xc07c8dfc = calltrap+0x6 > --- trap 0xc, eip = 0xc05be315, esp = 0xe7a5eab4, ebp = 0xe7a5eaf4 --- > _mtx_lock_sleep(c51b8be8,c59ae870,0,c08501a2,a43,...) at 0xc05be315 = _mtx_lock_sleep+0xa5 Doing 'l *_mtx_lock_sleep+0xa5' in gdb of your kernel.debug would be useful. x/i of the same address would also be useful. I'm guessing that mtx_lock was set to something bogus. -- John Baldwin