Re: scsipi mid-layer, tagged queueing, and ciss(4)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Aug 29, 2010 at 11:19:44AM -0600, Michael L. Hitch wrote:
> [...]
> 
> Attempting to fix the ciss(4) driver to notify the scsipi(9)
> mid-layer to use tagged queueing failed.  The SmartArray is buggy or
> incomplete.  It does report the CmdQue bit in the flags3 field of
> the inquiry, but leaves the ANSII value in the version field 0 -
> which indicates the flags3 field isn't present.  The scsipi layer
> doesn't check the flags3 value because the ANSII value is < 2, and
> thus doesn't set the tagged queueing capability for the device.
> When the adapter requests tagged queueing, the scsipi layer happily
> ignores the tagged queueing request and continues using untagged
> commands.
> 
> I am able to force the tagged queueing capability, but it involved
> using scsipi_lookup_periph() to lookup the scsipi_periph structure
> and explicitly setting the PERIPH_CAP_TQING in periph_cap.  After
> that,
> ciss(4) can request enabling tagged queueing and I am able to
> multiple command queued.
> 
> My only question would be if using that scsipi(9) function like that
> is "proper" usage of that function.  An alternative method I think I
> had tried prior to that was to check if PERIPH_CAP_TQING was enabled
> in periph_cap each time the ciss(4) driver queued a scsi command
> (since it has the scsipi_periph address available in xs_periph), but
> that involves testing on each command.

there's another option, which is to fix the result of the INQUIRY command
returned to the scsipi layer, in the ciss driver (pathing the ANSII
value to 2). I think this would be the cleanest way.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--