[patch] CTL should check condition INQUIRY with invalid LUN

[Kenneth D. Merry]

On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote:
> On Mon, Mar 5, 2012 at 4:17 PM, Kenneth D. Merry <ken at freebsd.org> wrote:
> > On Mon, Mar 05, 2012 at 14:46:52 -0800, Chuck Tuffli wrote:
> >> Currently, the CTL responds to INQUIRY commands targeted at invalid
> >> LUNs by returning valid data with the peripheral qualifier set to LU
> >> OFFLINE. This patch instead returns a check condition with LU NOT
> >> READY.
> >>
> >> Linux initiators see the LU OFFLINE and start creating SG devices, but
> >> are not able to finish. The offline also causes them to keep probing
> >> LUNs.
> >
> > Linux used to behave properly. ?What version are you testing with?
> 
> RHEL 6.1
> 
> > Returning a check condition is not correct according to the spec. ?This is
> > from SPC-4 (r31):
> >
> > "In response to an INQUIRY command received by an incorrect logical unit,
> > the SCSI target device shall return the INQUIRY data with the peripheral
> > qualifier set to the value defined in 6.4.2. The INQUIRY command shall
> > return CHECK CONDITION status only when the device server is unable to
> > return the requested INQUIRY data."
> 
> You are correct, so I agree the patch I submitted yesterday is wrong, but :)
> 
> > Since CTL can support a LUN at the requested address, but there isn't one
> > there, it returns OFFLINE status.
> 
> this offline status causes Linux to create 255 sg additional devices.
> While this isn't directly a CTL problem, I'm sure I will end up having
> to explain why this happens more than once and would rather head off
> the problem. Would you be willing to consider changing the returned
> peripheral qualifier from
>     (SID_QUAL_LU_OFFLINE << 5) | T_DIRECT
> to
>     (SID_QUAL_BAD_LU << 5) | T_NODEVICE
> ? Linux seems happier with this FWIW.
> 
> > They should be issuing a REPORT LUNs and then probe the LUNs that are
> > returned...
> 
> Linux does issue REPORT LUNs, but most of the time, this gets
> check-conditioned with illegal request, overlapped commands attempted.

Hmm, that sounds suspicious.  What is the exact ASC/ASCQ reported?

Are you setting the tag_action field in the ATIO that gets sent to CTL?
Only one untagged command is allowed at a time.

If the tag action is getting set to simple, ordered, etc., then we need
to make sure that the same tag IDs aren't in use at the same time.

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG