On Mon, May 18, 2009 at 6:01 PM, Mike Christie <micha...@cs.wisc.edu> wrote: > > Erez Zilber wrote: >> On Mon, May 18, 2009 at 4:36 PM, Mike Christie <micha...@cs.wisc.edu> 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 > /sys/block/sdX/device/timeout). > > 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. >
I understand. Thanks! Erez --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
