Date: Tue, 15 Apr 2014 13:34:34 -0700 From: "R. Tyler Croy" <tyler@monkeypox.org> To: freebsd-current@freebsd.org Subject: Re: ZFS panic in -CURRENT Message-ID: <534D97DA.80003@monkeypox.org> In-Reply-To: <20140401065721.5317b538@monkeypox.org> References: <20140328170021.7BE88D6@hub.freebsd.org> <20140331162232.45e300e7@monkeypox.org> <533A5FA9.7030705@FreeBSD.org> <20140401065721.5317b538@monkeypox.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(follow up below) On 04/01/2014 06:57, R. Tyler Croy wrote: > On Tue, 01 Apr 2014 09:41:45 +0300 > Andriy Gapon <avg@FreeBSD.org> wrote: > >> on 01/04/2014 02:22 R. Tyler Croy said the following: >>> Bumping this with more details >>> >>> On Fri, 28 Mar 2014 09:53:32 -0700 >>> R Tyler Croy <tyler@monkeypox.org> wrote: >>> >>>> Apologies for the rough format here, I had to take a picture of >>>> this failure because I didn't know what else to do. >>>> >>>> <http://www.flickr.com/photos/agentdero/13469355463/>; >>>> >>>> I'm building off of the GitHub freebsd.git mirror here, and the >>>> latest commit in the tree is neel@'s "Add an ioctl to suspend.." >>>> >>>> My dmesg/pciconf are here: >>>> https://gist.github.com/rtyler/1faa854dff7c4396d9e8 >>> As linked before, the dmesg and `pciconf -lv` output can be found >>> here: <https://gist.github.com/rtyler/1faa854dff7c4396d9e8>; >>> >>> Also in addition to the photo from before of the panic, here's >>> another reproduction photo: >>> <https://www.flickr.com/photos/agentdero/13472248423/>; >> Are you or have you even been running with any ZFS-related kernel >> patches? > Negative, I've never run any specific ZFS patches on this machine (or > any machine for that matter!) > > One other unique clue might be that I'm running with an encrypted > zpool, other than that, nothing fancy here. I've upgraded my machine to r264387 and I still experience the issue, here's the latest pretty picture of my panicked laptop :) <https://secure.flickr.com/photos/agentdero/13880032704/>; The issue still seems to stem from a failed assertion in zap_leaf_lookup_closest() (http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c?revision=249195&view=markup#l446) but I'm not sure which assertion might be failing. This is somewhat problematic because I cannot perform *any* FS operations with the tainted directory tree, not even a `du -hcs *` to find out how much space I can never access again :P I can reproduce this consistently, if anybody has the time to get onto IRC (rtyler on Freenode and EFNet) and debug this, I can certainly act as remote hands with kdb to help ascertain more information about the panic. Cheers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?534D97DA.80003>