Mike Christie wrote:
> On 07/23/2009 05:20 AM, Boaz Harrosh wrote:
>> On 07/23/2009 12:24 PM, Mike Christie wrote:
>>> But you still might be hitting a problem where the target does not like
>>> data-outs when it closed the window. Maybe they interpreted the RFC
>>> differently. You should ask the HP target guys for more info.
>>>
>>> Also your patch might be working because I think it ends up throttling
>>> the connection, so IO does not timeout because pipes are backed up (the
>>> slow down from the throttling is one of the problems we hit with the
>>> patch I did before which was pretty much the same as you posted).
>>>
>> I think that what Hannes patch is doing is exactly that off-by-one command.
>> So maybe you are right and it is an HP bug where the window check is
>> off-by-one or they do not like data-outs after window close.
>>
>> Try to compare less-one in queuecommand and see if it helps the same?
>>
> 
> Hannes, did you try this?  I am attaching a patch that should give you 
> this behavior. It should do the same as checking the session->cmdsn in 
> iscsi_task_xmit where the cmdsn is already incremented so we end up not 
> sending a task with cmdsn == maxcmdsn.
> 

I talked to the msa2000 target guys and they said they allow a cmdsn 
with maxcmdsn, so that patch should not help. Did it do anything?

One thing they mentioned was that the target can send QUEUE_FULLs. The 
iscsi initiator does not really do anything with these now. Other FC 
drivers use track queue full. I am not sure how the queue fulls would 
cause a IO hang. Maybe because we are hitting too hard, something nasty 
ends up happening. Maybe the requeueing logic is bad in the ml.

I did the attached patch to print out if we get a queue full. If so we 
call the track queue full function like fc. The problem is that it 
starts reducing the queue depth from the queue_depth. If sdev_busy was 
less than queue_depth then it will take some time to ramp down, so I am 
not sure if this will be that helpful. At least we can see if we are 
getting q fulls from the target - let me know at least if we are seeing 
those.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index a751f62..6a21755 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -738,6 +738,25 @@ invalid_datalen:
 		ISCSI_DBG_SESSION(session, "copied %d bytes of sense\n",
 				  min_t(uint16_t, senselen,
 				  SCSI_SENSE_BUFFERSIZE));
+	} else if (rhdr->cmd_status == SAM_STAT_TASK_SET_FULL) {
+		struct scsi_device *tmp_sdev;
+		struct scsi_device *sdev = sc->device;
+
+		iscsi_session_printk(KERN_ERR, session, "Got QUEUE FULL %u %u "
+				    "%u %u\n", session->max_cmdsn,
+				session->exp_cmdsn, session->cmdsn,
+				session->queued_cmdsn);
+
+
+		shost_for_each_device(tmp_sdev, sdev->host) {
+			if (tmp_sdev->id != sdev->id)
+				continue;
+
+			if (tmp_sdev->queue_depth > 1) {
+				scsi_track_queue_full(tmp_sdev,
+						tmp_sdev->queue_depth - 1);
+			}
+		}
 	}
 
 	if (rhdr->flags & (ISCSI_FLAG_CMD_BIDI_UNDERFLOW |

Reply via email to