From owner-freebsd-current@FreeBSD.ORG Wed Aug 8 11:27:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0A671065672 for ; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A5E5D8FC0C for ; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00C90B980; Wed, 8 Aug 2012 07:27:47 -0400 (EDT) From: John Baldwin To: Mike Tancsa Date: Wed, 8 Aug 2012 07:27:45 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net> In-Reply-To: <502121F5.4020705@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208080727.45595.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Aug 2012 07:27:47 -0400 (EDT) Cc: Garrett Cooper , current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant 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: Wed, 08 Aug 2012 11:27:48 -0000 On Tuesday, August 07, 2012 10:11:01 AM Mike Tancsa wrote: > On 8/3/2012 5:26 PM, John Baldwin wrote: > >> If there's a tool for poking at the drives/controller, I would use > >> that, plus camcontrol. Of course you want a data intensive workload > > > > (iometer/iozone/xdd with async and sync mode, random reads and sequential > > reads, etc), and maybe resort to manual testing like pulling drives > > (power, data) if you don't mind creating failures. If you have some > > failed/failing drives kicking around, that would be a good test as well > > (see that all/some of the failure paths are properly stimulated). > > > > 3dm2 testing would be good for the ioctl handling, but the most critical > > tests are basic I/O. > > Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able > to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? 2) If it does, does basic I/O to the drives work? 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Thanks. -- John Baldwin