From owner-freebsd-current@FreeBSD.ORG Thu Feb 9 16:03:33 2006 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 3B29416A460 for ; Thu, 9 Feb 2006 16:03:33 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D6843D48 for ; Thu, 9 Feb 2006 16:03:31 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 8093752 for multiple; Thu, 09 Feb 2006 11:02:44 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k19G3NQu067979; Thu, 9 Feb 2006 11:03:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, Matthew Jacob Date: Thu, 9 Feb 2006 10:31:58 -0500 User-Agent: KMail/1.9.1 References: <20060208101308.B28251@ns1.feral.com> In-Reply-To: <20060208101308.B28251@ns1.feral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602091032.00203.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1281/Wed Feb 8 14:59:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Subject: Re: semi-interesting panic when rebooting 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: Thu, 09 Feb 2006 16:03:33 -0000 On Wednesday 08 February 2006 13:15, Matthew Jacob wrote: > I was debugging some stuff with mpt on an HTT i386 with ~today's source > (modified with mpt changes and a MAXPHYS/DFLTPHYS cranked up to 1m/.5m) > > I had a gstriped volume set that was having some, uh, issues, so I > rebooted the system. While rebooting, it panic'd in VFS. > > Just reporting things in case anyone has thoughts on this one. > > Feb 8 10:06:16 colfax reboot: rebooted by root > Feb 8 10:06:16 colfax syslogd: exiting on signal 15 > mpt0: Request 0xc237477c Timed out. > mpt0: Request 0xc2374598 Timed out. > mpt0: Timedout requests already complete. Interrupts may not be > functioning. mpt0: Request 0xc23747d4 Timed out. > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...0 0 0 done > All buffers synced. > Mount point /home had 2 dangling refs > mpt0: Request 0xc23747d4 Timed out. > mpt0: Timedout requests already complete. Interrupts may not be > functioning. mpt0: Request 0xc23747d4 Timed out. > mpt0: Timedout requests already complete. Interrupts may not be > functioning. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06be1fc > stack pointer = 0x28:0xdb9d99c8 > frame pointer = 0x28:0xdb9d99c8 > 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 = 696 (lmdd) > [thread pid 696 tid 100113 ] > Stopped at strlen+0x8: cmpb $0,0(%edx) > db> bt > Tracing pid 696 tid 100113 td 0xc2d0e9c0 > strlen(deadc0de,138,19,0,20d0ea54) at strlen+0x8 > kvprintf(c088646b,c0673244,db9d9aac,a,db9d9af4) at kvprintf+0x64c > vsnprintf(c0953860,100,c088646b,db9d9af0,100) at vsnprintf+0x29 > panic(c088646b,deadc0de,c0890603,1a5,c25ac800) at panic+0xb2 > _mtx_lock_flags(c25ac83c,0,c0890603,1a5,c2ebb410) at _mtx_lock_flags+0x5a > vfs_rel(c25ac800) at vfs_rel+0x1c > vdestroy(c2ebb410,c2ebb410,db9d9b68,c06b0a13,c2ebb410) at vdestroy+0x202 > vdropl(c2ebb410,c2edd010,c2e5a700,c2ebb410,db9d9be4) at vdropl+0x3e > vrele(c2ebb410) at vrele+0x167 > fdfree(c2d0e9c0) at fdfree+0x65a > exit1(c2d0e9c0,9,db9d9c98,c2d0e9c0,c2e4c000) at exit1+0x448 > sigexit(c2d0e9c0,9,c2e4caa8,0,c088772b) at sigexit+0xdf > postsig(9) at postsig+0x155 > ast(db9d9d38) at ast+0x35e > doreti_ast() at doreti_ast+0x17 I bet the mutex is destroyed. Can you do 'l *_mtx_lock_flags+0x5a' in gdb on your kernel.debug? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org