From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 02:55:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F66F492; Mon, 21 Jul 2014 02:55:03 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id AE05D2916; Mon, 21 Jul 2014 02:55:02 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id F3F8A20E7088C; Mon, 21 Jul 2014 02:55:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 4849C20E7088A; Mon, 21 Jul 2014 02:54:57 +0000 (UTC) Message-ID: <24B81F5E7779408AAA0F2D6CA3B16CED@multiplay.co.uk> From: "Steven Hartland" To: "Dan Mack" References: <20140720140350.GA8498@borg.lerctr.org> <8D84B82C674B495DBF4951E0EE0D7117@multiplay.co.uk> <21dbecad27074fe34610bc587e6d0764@thebighonker.lerctr.org> <05c8bccf4faf5005881fbd2b22f35428@thebighonker.lerctr.org> <4A0B8A1798484B3DB4DCD924A2DFEF22@multiplay.co.uk> Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 Date: Mon, 21 Jul 2014 03:54:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 21 Jul 2014 02:55:03 -0000 ----- Original Message ----- From: "Dan Mack" To: "Steven Hartland" Cc: ; ; "Larry Rosenman" Sent: Monday, July 21, 2014 2:29 AM Subject: Re: [ZFS][PANIC] Solaris Assert/zio.c:2548 > On Mon, 21 Jul 2014, Steven Hartland wrote: > >>> I just updated to I think 268921 earlier today and this is the first >>> time I've had a panic (HEAD-268921 that is) >>> >>> I'll try to get some more data if I can get it back up and running. >> >> That doesn't look like a related trace tbh. >> >> Regards >> Steve > > After rebooting with a dumpdev; I got this : > > kbd2 at ukbd0 > Trying to mount root from zfs:tank []... > panic: deadlkres: possible deadlock detected for 0xfffff8000e089000, blocked for 1801216 ticks > > cpuid = 6 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085ef1d8d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085ef1d980 > vpanic() at vpanic+0x126/frame 0xfffffe085ef1d9c0 > panic() at panic+0x43/frame 0xfffffe085ef1da20 > deadlkres() at deadlkres+0x35c/frame 0xfffffe085ef1da70 > fork_exit() at fork_exit+0x84/frame 0xfffffe085ef1dab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe085ef1dab0 > --- trap 0, rip = 0, rsp = 0xfffffe085ef1db70, rbp = 0 --- > KDB: enter: panic > [ thread pid 0 tid 100070 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > I cannot seem to get past this yet so I'm open to suggestions. I'm > still at the db> prompt if you'd like me to attempt to collect more > info. Just spotted an interesting message on a recent commit which may be relavent: > URL: http://svnweb.freebsd.org/changeset/base/268855 > This specific commit makes boot hang just before mounting the root > dataset for me when vfs.zfs.vdev.cache.size tunable is set. Unsetting > this tunable or reverting this commit (currently running r268933 minus > r268855) fixes the boot for me. > > Please let me know if I can provide any more information. > > - Nikolai Lifanov The current code disables vdev caching by default so this will only occur if manually enabled. The code details the reason for this as:- * TODO: Note that with the current ZFS code, it turns out that the * vdev cache is not helpful, and in some cases actually harmful. It * is better if we disable this. Once some time has passed, we should * actually remove this to simplify the code. For now we just disable * it by setting the zfs_vdev_cache_size to zero. Note that Solaris 11 * has made these same changes. Regards Steve