On Mon, 2009-03-30 at 19:34 -0500, Mike Christie wrote:
> Nicholas A. Bellinger wrote:
> > Greetings Mike, Hannes and co:
> > 
> > Here is the OOPs that I am seeing with upstream Open-iSCSI on kernel.org
> > v2.6.27.10 with the TASK_ABORTED status getting returned to outstanding
> It looks like you are returning TASK_ABORTED when a R2T has been sent to 
> the initiator and it was responding or do we have InitialR2T=No and are 
> doing that first part of the write.


> If so it might be the following:
> Novell's target sent a check condition when a R2T was being processed 
> and at that time, our reading of "10.4.2. Status":
>     If a SCSI device error is detected while data from the initiator is
>     still expected (the command PDU did not contain all the data and the
>     target has not received a Data PDU with the final bit Set), the
>     target MUST wait until it receives a Data PDU with the F bit set in
>     the last expected sequence before sending the Response PDU.
> We took this to mean that if we were sending data in response to a r2t 
> or with the command pdu as part of InitialR2T=No handling, then the 
> target would not send a scsi command response pdu on us. If it did then 
> that r2t handling is basically dangling around and when the task is 
> reallocated we see it did not get handled in that check.

Good eye, I completely agree with your interpretation of 10.4.2.

> If we read the spec right then the fix for us is simple. Fix your target :)

Ok, I will fix LIO-Target to follow 10.4.2..

> If I goofed then the fix for us might be simple. See the attached patch. 
> I would have to look at the other drivers to make sure it works for them.

Of course, not running into this BUG on the initiator side (even when
targets are being naughty) would be the ideal solution. :-)

I will give our test a run and see what happens.

Many thanks for your most valuable of time,


> > 
> plain text document attachment (force-cleanup.patch)
> --- linux-      2009-03-30 
> 19:32:26.000000000 -0500
> +++ linux-   2009-03-30 19:33:25.000000000 
> -0500
> @@ -332,6 +332,9 @@ static void iscsi_complete_command(struc
>       struct iscsi_session *session = conn->session;
>       struct scsi_cmnd *sc = task->sc;
> +     if (task->state != ISCSI_TASK_PENDING)
> +             conn->session->tt->cleanup_task(conn, task);
> +
>       list_del_init(&task->running);
>       task->state = ISCSI_TASK_COMPLETED;
>       task->sc = NULL;
> @@ -402,8 +405,6 @@ static void fail_command(struct iscsi_co
>                * the cmd in the sequencing
>                */
>               conn->session->queued_cmdsn--;
> -     else
> -             conn->session->tt->cleanup_task(conn, task);
>       /*
>        * Check if cleanup_task dropped the lock and the command completed,
>        */

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to