Nicholas A. Bellinger wrote:
> 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
>>> 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.
> <nod>
>> 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. :-)

Yeah, I sort of agree. I am just worried about adding regressions. I 
have some patches that fix up that code's locking and while doing the 
patches I was thinking about Hannes's target and they do handle this 
now. So I am not sure I want to fix this now, test it out, then do the 
locking patches and test them out again - just not enough time.

> I will give our test a run and see what happens.
> Many thanks for your most valuable of time,

No problem. Thanks for the bug reports.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to