Mike Christie wrote:
> Mike Christie wrote:
>> Hannes Reinecke wrote:
>>> Sigh. Why do you have to make is so complicated ...
>>> My patch was easy and simple originally. And now this :-)
>>>
>> This gets really ugly if we do it in libiscsi_tcp. I moved the check to 
>> libiscsi and I changed the abort task test to check for the rtt since 
>> that works for data outs. I think the attached patch will do what you 
>> wanted. It is only compile tested.
>>
> 
> Bah. The lun and itt is not set for scsi cmd pdus. This should fix it.
> 
> For the lu reset and requeue (r2t data-out handling) or scsi cmd case, 
> the task sc lun is always going to be set.
> 
> For the abort and requeue or cmd case, we only need to check the itt/rtt 
> for data outs when doing a abort task (the requeue case), because the 
> cmd has already been sent (iscsi_eh_abort checks for it on the cmd queue 
> before sending) so there is no point to check at that point (also the 
> itt is not set for scsi cmd pdus yet).
> 
> It might be nicer to move the restrictions check after the prep scsi cmd 
> pdu call but you need the cmdsn scsi_prep_scsi_cmd_pdu patch I sent the 
> other day.
> 
Better. Nearly there. I'm running with fast_abort disabled, and occasionally
I'm getting this (this is now the HP MSA2012i, so we can't really blame
NetApp here):

Jul 31 10:51:37 tyne kernel:  session1: iscsi_eh_device_reset LU Reset [sc 
ffff880070920780 lun 9]
Jul 31 10:51:37 tyne kernel:  session1: iscsi_exec_task_mgmt_fn tmf set timeout
Jul 31 10:51:37 tyne kernel:  session1: mgmtpdu [op 0x2 hdr->itt 0x1d datalen 0]
Jul 31 10:51:37 tyne kernel:  connection1:0: mgmtpdu [itt 0x1d task 
ffff88007adb4400] xmit
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x7b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x7d lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x47 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x2b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x6b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: tmf rsp [itt 0x1d] response 0 
state 1
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x6 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x1a lun 9]
Jul 31 10:51:37 tyne kernel:  session1: iscsi_suspend_tx suspend Tx
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x5f lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x7c lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x7c lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x7e lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x7e lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x1f lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x1f lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x66 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x66 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x4 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x4 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x7d lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x7d lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x47 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x47 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x2b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x2b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x6b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x6b lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x6 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x6 lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x1a lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x1a lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 1 itt 0x5f lun 9]
Jul 31 10:51:37 tyne kernel:  connection1:0: xmit pdu [op 5 itt 0x5f lun 9]
Jul 31 10:51:37 tyne kernel:  session1: Tx suspended!
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88007b500580 itt 0x4 state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88007b500580 lun 9 itt x4] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff8800785bc380 itt 0x1a state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff8800785bc380 lun 9 itt x1a] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88007108a480 itt 0x1f state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88007108a480 lun 9 itt x1f] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88007ad5d080 itt 0x49 state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88007ad5d080 lun 9 itt x49] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff880079d48880 itt 0x5f state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff880079d48880 lun 9 itt x5f] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff8800785bc880 itt 0x66 state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff8800785bc880 lun 9 itt x66] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff8800780fa880 itt 0x75 state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff8800780fa880 lun 9 itt x75] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff880072145380 itt 0x7c state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff880072145380 lun 9 itt x7c] state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff880079d53980 itt 0x7e state 3
Jul 31 10:51:37 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff880079d53980 lun 9 itt x7e] state 3
Jul 31 10:51:37 tyne kernel:  session1: iscsi_start_tx resume Tx
Jul 31 10:51:37 tyne kernel:  connection1:0: invalid itt [op 0x21 itt 0x1a]
Jul 31 10:51:37 tyne kernel:  connection1:0: invalid itt [op 0x21 itt 0x5f]
Jul 31 10:51:37 tyne kernel:  session1: iscsi_eh_device_reset dev reset result 
= SUCCESS

and later on:

Jul 31 10:52:02 tyne kernel:  session1: iscsi_eh_device_reset LU Reset [sc 
ffff8800780fab80 lun 2]
Jul 31 10:52:02 tyne kernel:  session1: iscsi_exec_task_mgmt_fn tmf set timeout
Jul 31 10:52:02 tyne kernel:  session1: mgmtpdu [op 0x2 hdr->itt 0x33 datalen 0]
Jul 31 10:52:02 tyne kernel:  connection1:0: mgmtpdu [itt 0x33 task 
ffff88007850dc00] xmit
Jul 31 10:52:02 tyne kernel:  connection1:0: tmf rsp [itt 0x33] response 0 
state 1
Jul 31 10:52:02 tyne kernel:  session1: iscsi_suspend_tx suspend Tx
Jul 31 10:52:02 tyne kernel:  session1: Tx suspended!
Jul 31 10:52:02 tyne kernel:  connection1:0: iscsi_tcp_data_ready: 
TCP_CLOSE|TCP_CLOSE_WAIT
Jul 31 10:52:02 tyne kernel:  session1: iscsi_conn_failure Suspend Tx
Jul 31 10:52:02 tyne kernel:  session1: iscsi_conn_failure Suspend Rx
Jul 31 10:52:02 tyne kernel:  connection1:0: detected conn error (1011)

Again, we continue with R2T transfer even if the TMF is already sent. That's 
okay, if weird.
But we're also continue with R2T transfer even _after_ the TMF response have 
been received.
Which we _really_ shouldn't.
And it looks to me as if we've terminated the PDU transfer from itt 0x1a and 
0x5f, hence
the target sends us some retry R2T later on to coax us into retransmitting. 
Which we can't,
obviously.
So it looks we have to make sure to _not_ transmit partial PDUs here.
I would advocate for _not_ continue with data transfer after we've received a 
TMF response, too.
But this is tricky as we currently can't atomically suspend the Tx queue.

Let's see.

Cheers,

Hannes
-- 
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 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to