From owner-freebsd-scsi@FreeBSD.ORG Tue Apr 7 21:34:02 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4741065675 for ; Tue, 7 Apr 2009 21:34:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E901A8FC21 for ; Tue, 7 Apr 2009 21:34:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.home (pooker.samsco.home [192.168.254.1]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n37LXuCl031429; Tue, 7 Apr 2009 15:33:57 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Tue, 7 Apr 2009 15:33:56 -0600 (MDT) From: Scott Long To: Matt Hempel In-Reply-To: <1239048815.24106.17.camel@localhost> Message-ID: <20090407153121.N22014@pooker.samsco.org> References: <1239048815.24106.17.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol tags output for adaptec raid controller on 7.1-RELEASE X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 21:34:02 -0000 On Mon, 6 Apr 2009, Matt Hempel wrote: > Hello > > I was tipped off to this post: > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-February/003806.html > > I'm running a Supermicro server with an Adaptec 2010S raid controller > with two attached disks in a simple mirrored configuration. raidutil > output follows. > > It didn't make sense to me that I should be affected by that bug, but > when I ran camcontrol tags, it reported 1 for dev_openings. I manually > applied the patched code, recompiled and now I'm getting 128 for > dev_openings. > > matt@h20:~$ sudo camcontrol tags da0 -v > (pass0:asr0:0:0:0): dev_openings 255 > (pass0:asr0:0:0:0): dev_active 0 > (pass0:asr0:0:0:0): devq_openings 255 > (pass0:asr0:0:0:0): devq_queued 0 > (pass0:asr0:0:0:0): held 0 > (pass0:asr0:0:0:0): mintags 2 > (pass0:asr0:0:0:0): maxtags 255 > > > Can anyone explain why that happened? Bugs were fixed =-) > > How is the initial value of dev_openings derived? Should I trust it? > Is it relevant or a best guess? It depends on how many tagged vs untagged openings the driver advertises. The tagged vs untagged setting is then selected based on some criteria of whether CAM things that tagged queueing should be used. Remember, CAM is really geared towards parallel SCSI, when using it as a transport layer for RAID, some concepts don't translate well. > > I can reset the dev_openings value using the -N switch to camcontrol > tags. If I put that in a startup script, does this behavior really > matter? Yes, you can switch it. Scott