[PATCH 2/5] - fusion - target reset when drive is being removed

[PATCH 2/5] - fusion - target reset when drive is being removed

[Moore, Eric]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

The issuing of the target reset 
used in device hot removal case so the
firmware queue is flushed out off outstanding
commands.

Signed-off-by: Eric Moore <Eric.Moore@lsil.com>

[-- Attachment #2: 3-tid.patch --]
[-- Type: application/octet-stream, Size: 1123 bytes --]

diff -uarN b/drivers/message/fusion/mptsas.c a/drivers/message/fusion/mptsas.c
--- b/drivers/message/fusion/mptsas.c	2006-01-25 16:21:44.000000000 -0700
+++ a/drivers/message/fusion/mptsas.c	2006-01-25 16:36:30.000000000 -0700
@@ -324,6 +324,7 @@
 	struct sas_rphy *rphy;
 	struct mptsas_portinfo *p;
 	int i;
+	VirtDevice *vdev;
 
 	/*
 	 * Handle hotplug removal case.
@@ -347,8 +348,29 @@
  out:
 	mutex_unlock(&hd->ioc->sas_topology_mutex);
 	/*
-	 * TODO: Issue target reset to flush firmware outstanding commands.
+	 * Issue target reset to flush firmware outstanding commands.
 	 */
+	vdev = sdev->hostdata;
+	if (vdev->configured_lun){
+		if (mptscsih_TMHandler(hd,
+		     MPI_SCSITASKMGMT_TASKTYPE_TARGET_RESET,
+		     vdev->bus_id,
+		     vdev->target_id,
+		     0, 0, 5 /* 5 second timeout */)
+		     < 0){
+
+			/* The TM request failed!
+			 * Fatal error case.
+			 */
+			printk(MYIOC_s_WARN_FMT
+		       "Error processing TaskMgmt id=%d TARGET_RESET\n",
+				hd->ioc->name,
+				vdev->target_id);
+
+			hd->tmPending = 0;
+			hd->tmState = TM_STATE_NONE;
+		}
+	}
 	mptscsih_slave_destroy(sdev);
 }
 

Re: [PATCH 2/5] - fusion - target reset when drive is being removed

[James Smart]

Interesting that you took this path.  I'm working on something similar
for the FC transport. When we finally decide the device is gone, we
want to kill the outstanding i/o. First thought in my mind was to use
a TMF - but this implies that you can contact the device to do the TMF.
Are you sending this before the device has actually gone away ?  If it's
after, I assume this then is a firmware function that handles things
accordingly at the link layer (e.g. may not send the TMF, will internally
abort the outstanding io's, may note the TR request and do it when the
device is later detected.... and so on).

Can you comment ?

-- james

Moore, Eric wrote:
> The issuing of the target reset 
> used in device hot removal case so the
> firmware queue is flushed out off outstanding
> commands.
> 
> Signed-off-by: Eric Moore <Eric.Moore@lsil.com>

Re: [PATCH 2/5] - fusion - target reset when drive is being removed

[Christoph Hellwig]

On Wed, Jan 25, 2006 at 06:05:12PM -0700, Moore, Eric wrote:
> The issuing of the target reset 
> used in device hot removal case so the
> firmware queue is flushed out off outstanding
> commands.

looks good to me.

RE: [PATCH 2/5] - fusion - target reset when drive is being removed

[Moore, Eric]

On Thursday, January 26, 2006 7:40 AM, James Smart wrote:
> Interesting that you took this path.  I'm working on something similar
> for the FC transport. When we finally decide the device is gone, we
> want to kill the outstanding i/o. First thought in my mind was to use
> a TMF - but this implies that you can contact the device to 
> do the TMF.
> Are you sending this before the device has actually gone away 
> ?  If it's
> after, I assume this then is a firmware function that handles things
> accordingly at the link layer (e.g. may not send the TMF, 
> will internally
> abort the outstanding io's, may note the TR request and do it when the
> device is later detected.... and so on).
> 

The target reset is issued from the device driver slave_destroy entry
point.

This occurs after the device has been removed.   Meaning the driver
receives a firmware event saying a device was deleted, then the driver
calls the sas_transport layer to report the deleted device.  Then
the scsi mid-layer calls the slave_destroy entry point, then the
target reset is called.

This sole purpose is merely telling the firmware to complete the
outstanding 
commands back to the driver, so the mid-layer is getting all completed
io
for the device, thus preventing any future driver eh_threads from being
called.

This was implemented in the LSI internal drivers some time ago, at that
time
when the driver received the "device delete" event, the device could
still be
getting io from above, and/or still have io pending in its queue.  The
target
reset will flush the queue, and thus return all the io's with abort'd
status back
to the driver.  That is why I had the target reset from the
slave_destroy. 

Eric

Re: [PATCH 2/5] - fusion - target reset when drive is being removed

[James Smart]

Yep - makes sense.

So, where I was driving to, Target Reset is a f/w command, not the actual
Task Management Function "Target Reset". No need to follow up..

Thanks.

-- james

Moore, Eric wrote:
> On Thursday, January 26, 2006 7:40 AM, James Smart wrote:
>> Interesting that you took this path.  I'm working on something similar
>> for the FC transport. When we finally decide the device is gone, we
>> want to kill the outstanding i/o. First thought in my mind was to use
>> a TMF - but this implies that you can contact the device to 
>> do the TMF.
>> Are you sending this before the device has actually gone away 
>> ?  If it's
>> after, I assume this then is a firmware function that handles things
>> accordingly at the link layer (e.g. may not send the TMF, 
>> will internally
>> abort the outstanding io's, may note the TR request and do it when the
>> device is later detected.... and so on).
>>
> 
> The target reset is issued from the device driver slave_destroy entry
> point.
> 
> This occurs after the device has been removed.   Meaning the driver
> receives a firmware event saying a device was deleted, then the driver
> calls the sas_transport layer to report the deleted device.  Then
> the scsi mid-layer calls the slave_destroy entry point, then the
> target reset is called.
> 
> This sole purpose is merely telling the firmware to complete the
> outstanding 
> commands back to the driver, so the mid-layer is getting all completed
> io
> for the device, thus preventing any future driver eh_threads from being
> called.
> 
> This was implemented in the LSI internal drivers some time ago, at that
> time
> when the driver received the "device delete" event, the device could
> still be
> getting io from above, and/or still have io pending in its queue.  The
> target
> reset will flush the queue, and thus return all the io's with abort'd
> status back
> to the driver.  That is why I had the target reset from the
> slave_destroy. 
> 
> Eric
>