From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 05:27:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA98106568A for ; Fri, 3 Oct 2008 05:27:49 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0107A8FC1C for ; Fri, 3 Oct 2008 05:27:48 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 1C3C3173B0; Fri, 3 Oct 2008 15:27:46 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-151-43.lns10.syd7.internode.on.net [121.44.151.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 25E791722A for ; Fri, 3 Oct 2008 15:27:42 +1000 (EST) Message-ID: <48E5AD16.5000101@modulus.org> Date: Fri, 03 Oct 2008 15:26:46 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: trying to track down UFS "dup alloc" message on iSCSI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 05:27:49 -0000 I am playing with an iSCSI device on FreeBSD client running UFS2 on the device over a LAN. Everything works well until I reboot the iSCSI server - the client pauses for a minute or so then continues working after iSCSI server comes back. No I/O errors are reported. Everything seems to work fine for a little while! But shortly afterwards, I get a panic with the message panic: ffs_valloc: dup alloc It seems related to the length of the delay the iSCSI device is paused - restarting the iSCSI target daemon process doesn't cause the problem but rebooting the whole target box does cause it. 1. Could this be related to the patch Matt Dillon created years ago which I found here? http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html 2. Can anyone think of any other reason this might happen? I know I am stretching UFS to the limits here, expecting it to pause and restart after more than a minute of locked disk :-) However, since all I/O eventually complete successfully and no errors are reported, I find it suspicious. Cheers - Andrew ps. running latest iSCSI code 2.1 on latest 7-STABLE box.