Hi all,

when my device-reset testcase I've come across this:

Jul 28 12:46:08 tyne kernel:  session1: iscsi_eh_device_reset LU Reset [sc 
ffff8800731e9480 lun 6]
Jul 28 12:46:08 tyne kernel:  session1: iscsi_exec_task_mgmt_fn tmf set timeout
Jul 28 12:46:08 tyne kernel:  session1: mgmtpdu [op 0x2 hdr->itt 0x69 datalen 0]
Jul 28 12:46:08 tyne kernel:  connection1:0: mgmtpdu [itt 0x69 task 
ffff88007b022800] xmit
Jul 28 12:46:08 tyne kernel:  connection1:0: tmf rsp [itt 0x69] response 0 
state 1
Jul 28 12:46:08 tyne kernel:  session1: iscsi_suspend_tx suspend Tx
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88006fd20380 itt 0x54 state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88006fd20380 lun 6 itt x54] state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88007119b880 itt 0x5d state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88007119b880 lun 6 itt x5d] state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff88007116ec80 itt 0x60 state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff88007116ec80 lun 6 itt x60] state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_tasks failing sc 
ffff880079dd8180 itt 0x61 state 3
Jul 28 12:46:08 tyne kernel:  session1: fail_scsi_task fail task [sc 
ffff880079dd8180 lun 6 itt x61] state 3
Jul 28 12:46:08 tyne kernel:  connection1:0: invalid itt 0x5d in R2T hdr
Jul 28 12:46:08 tyne kernel:  session1: iscsi_start_tx resume Tx
Jul 28 12:46:08 tyne kernel:  session1: iscsi_eh_device_reset dev reset result 
= SUCCESS
Jul 28 12:46:08 tyne kernel:  connection1:0: invalid itt 0x60 in R2T hdr
Jul 28 12:46:08 tyne kernel:  connection1:0: invalid itt 0x61 in R2T hdr

As you can see, we're receiving R2Ts for tasks we've just aborted :-(

Looking closely, I don't _actually_ think the we've received them out-of-order 
(which would be
a violation of the RFC). The problem seems to be our skb handling (again):

We're reading an skb, and call the handler function once the PDU is ready. 
However, we're _not_
checking if there is more data to be read from the socket.
So it looks to me as if we're first reading the TMF response, aborting all 
tasks, and then
continue reading PDUs for tasks which we just aborted.
Bad.

Currently I don't have any nice idea how to solve this, so this is just as a 
heads up that
something is awry here.

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