From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 15:29:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8127C674 for ; Fri, 14 Dec 2012 15:29:19 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0D08FC13 for ; Fri, 14 Dec 2012 15:29:19 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2242974pbc.13 for ; Fri, 14 Dec 2012 07:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zy3VVPzj01Nv0K+ET0GEKel7VUOCU/iYy75AkOXBJy4=; b=LgvYXgBjitIvRn/d19jJ3vsLvoZItWaK0SzSQuE9fYjy6ZpHy+PRIRh2Nl7j2L6jRr XU04LweNB/r1XeZCBTnnnCZJzreUC1LfOs1V4XVQGaJxaJqeHCbG6ssO3NNRMzEuxmbd m+LeosHtGmYqEUwgPTdZ3RmD1aBA84xfY35RzBa4YWgIFMFv0R0AcisEQQqjKbwsTm4w V1fRseVIoAWBxRTw+i+e5MLMcLDUDGBBV1x1l9jZ0WXFsyNm3xulH6nL4jgr8RZAeobV ZvY9XmTguA2ASjhVSPQCaB7NwK10ncXf1ko1QYRSeTXgM9ZVdEkhpiQj1I9as1l3z2YE qCNg== MIME-Version: 1.0 Received: by 10.66.73.132 with SMTP id l4mr16730057pav.48.1355498958874; Fri, 14 Dec 2012 07:29:18 -0800 (PST) Received: by 10.66.148.136 with HTTP; Fri, 14 Dec 2012 07:29:18 -0800 (PST) In-Reply-To: <50CB2B33.6000103@cse.yorku.ca> References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> <50CB2B33.6000103@cse.yorku.ca> Date: Fri, 14 Dec 2012 07:29:18 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: Jason Keltz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:29:19 -0000 Unfortunately I don't have a single piece of code that triggers this. This happens on a server than a bunch of other machines can access simultaneously. My impression is that perhaps sustained concurrent reads or writes are what causes the problem. So maybe run a bunch of dd if=/dev/random of=temp bs=xx in parallel, or use something like bonnie++? Olivier On Fri, Dec 14, 2012 at 5:35 AM, Jason Keltz wrote: > Hi Olivier, > > I'm running a system using the mps driver under 9.1. The system has two > 9205-8e cards and one 9207-8i. Can you give me the code that you're > running that might eventually cause the lockup, and I'll try to see if I > can make it happen here? If it happens in multiple mps installations, > maybe someone can look at the driver to see what the issue might be. Since > my system isn't yet in production, I'm more than happy to leave it running > a test.... > > Jason. > > > On 12/14/2012 01:14 AM, olivier wrote: > >> For what it's worth, I think I might have solved my problem by reverting >> to >> an older version of the mps driver. I checked out a recent version of >> 9-STABLE and reversed the changes in >> http://svnweb.freebsd.org/**base?view=revision&revision=**230592(perhaps there >> was a simpler way of reverting to the older mps driver). So far so good, >> no >> hang even when hammering the file system. >> >> This does not conclusively prove that the new LSI mps driver is at fault, >> but that seems to be a likely explanation. >> >> Thanks to everybody who pointed me in the right direction. Hope this helps >> others who run into similar problems with 9.1 >> Olivier >> >> On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: >> >> >>> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >>> >>> Google for "zfs deadman". This is already committed upstream and I >>>> think >>>> that it >>>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>>> into the >>>> vendor area and is not merged yet. >>>> >>>> Yes, that's exactly what I had in mind. The logic for panicking makes >>> sense. >>> As far as I can tell you're correct that deadman is in the vendor area >>> but >>> not merged. Any idea when it might make it into 9-STABLE? >>> Thanks >>> Olivier >>> >>> >>> >>> >>> So, when enabled this logic would panic a system as a way of letting >>>> know >>>> that >>>> something is wrong. You can read in the links why panic was selected >>>> for >>>> this job. >>>> >>>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>>> perfect place >>>> to detect such issues in non-ZFS-specific way. >>>> >>>> -- >>>> Andriy Gapon >>>> >>>> >>> ______________________________**_________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org >> " >> > >