Erez Zilber wrote:
> On Mon, May 18, 2009 at 4:36 PM, Mike Christie <> wrote:
>> Erez Zilber wrote:
>>> I enabled open-iscsi logging + added some printk calls when the abort
>>> handler returns.
>>> Here's the log. I see that iscsi_eh_cmd_timed_out gets called, but
>>> there's no abort.
>>> May 17 11:00:06 kpc36 kernel:  session1: iscsi_eh_cmd_timed_out scsi
>>> cmd ffff8101e30efe40 timedout
>>> May 17 11:00:06 kpc36 kernel:  session1: iscsi_eh_cmd_timed_out return
>>> timer reset
>> As you can see in iscsi_eh_cmd_timed_out, if the sesison is down then
>> there is no point in letting the scsi eh run since we have to relogin
>> and restart commands so we would return reset timer which prevents the
>> scsi eh from running.
> Makes sense. There's only one thing that I don't understand - when
> does scsi-ml call  iscsi_eh_cmd_timed_out? I thought that if a cmd
> times out, scsi-ml sends an abort.

scsi-ml calls scsi_times_out (which calls iscsi_eh_cmd_timed_out) when 
the scsi command timer expires (timeout is value in 

If the eh_timed_out callout returns BLK_EH_NOT_HANDLED then the scsi eh 
will run and call the abort function.

The transportt->eh_timed_out allows the class/lld to override the scsi 
eh if for example it is a transport problem. In that case an abort or 
lun reset would not help, because you cannot send the TMF since there is 
no access to the target/disk.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to