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