Oh yeah, Erez,

This will fix the issue we saw yesterday. Did you want me to port this 
for you to test? I think we will end up with the same result, because I 
am still making sure the transport is good before letting the scsi eh 
run. So if the nop still times out, we end up dropping the session and 
it command gets cleaned up that way.

Mike Christie wrote:
> Hey Hannes,
> This will not fix any hangs after the scsi eh or iscsi eh has fired, but 
> I think this patch will help prevent the scsi eh from firing when we do 
> not need it to like you have seen in some bugzillas. The patch was made 
> over the my iscsi tree. It should also apply to scsi-rc-fixes with the 
> patches I sent the other day.
> I modified our command timedout handler so if a command has made some 
> progress since the last timeout or if it is just getting started (it has 
> been put on the wire but we have not yet got anything for it), then we 
> will ask for some more time to run it.
> This is helping here for these problems:
> 1. sending more IO than the disk/target can handle
> 2. using a shorter scsi cmd timeout with a slower link
> I am going to combine this with those change_queue_depth patches if they 
> are ok upstream, and in the end also add lpfc/qla2xxx's rampup/rampdown 
> code to scsi-ml. So basically if we determine if we are sending too many 
> IOs, then we can call some helper rampdown code to drop the queue depth 
> for the user. If however it was a transient problem, the common ramp up 
> code will detect it and increase it again.
> I think with the combo rampup/rampdown and the modified 
> iscsi_eh_cmd_timed_out in this patch, it should fix a lot of problems we 
> see where the scsi-eh runs when it should not.

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