Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Aug 2012 07:27:45 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Mike Tancsa <mike@sentex.net>
Cc:        Garrett Cooper <yanegomi@gmail.com>, current@freebsd.org
Subject:   Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
Message-ID:  <201208080727.45595.jhb@freebsd.org>
In-Reply-To: <502121F5.4020705@sentex.net>
References:  <201208031418.57941.jhb@freebsd.org> <201208031726.03652.jhb@freebsd.org> <502121F5.4020705@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208080727.45595.jhb>