camcontrol tags output for adaptec raid controller on 7.1-RELEASE

[Scott Long]

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 at 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