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? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
