Hannes Reinecke wrote:
> Hi Mike,
> finally I've managed to track down the lost TTT issue.
> We're continuing to get responses from the target
> even after we have send the TMF PDU (no surprise there).
> However, the target considers all R2Ts send _before_
> the tmf response is sent as valid, requiring us
> to finish off the R2T sequence by sending a Data-Out
> PDU even _after_ we have received the TMF response.
> So I've implemented a (rather hackish) 'flush data out'
> function, which flushes all outstanding Data out
> PDUs for a given LUN. Using this things are much
> better to the point that the 'dropped R2T' messages
> disappeared.
Well, I've been to fast. I'm having a rather unfavourable
(non-)interaction between the xmit thread and the recv
side; as the recv side runs effectively asynchronous
to the xmit thread there is a change that wealready
received the R2T PDU but haven't had a chance to
process it as it's waiting on the session spinlock.
Maybe it's an idea to have a per-task spinlock to
ease the lock contention on the per-session spinlock.

And of course the whole this would have been far
easier if I had a chance to detect a pending r2t
by the time fail_scsi_task() is called; then
I could just call the xmit thread until the
Data-out pdu is sent.

Mike, any idea here?


Dr. Hannes Reinecke                   zSeries & Storage
h...@suse.de                          +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

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