Skip to contentSkip to conversation

mpt2sas: setting SDEV into RUNNING state from Interrupt context

PATCH James Bottomley 2 participants 2 messages Aug 14, 2009 1 message not in the archive SCSI

lore
Share & tools
lore

James Bottomley

author maintainer
#1 lore raw
In reply to a message not in the archive
Quoted 35 lines · Desai

Changing SDEV Running state from interrupt context. Previously It was handle in work queue thread. With this change It will not wait for work queue thread to execute scsih_ublock_io_device to put SDEV into Running state. This will reduce delay for Device becoming RUNNING.

---

Signed-off-by Kashyap Desai <[email protected]>
Signed-off-by Eric Moore <[email protected]>

---

drivers/scsi/mpt2sas/mpt2sas_scsih.c +6 -0
index c0d5d5e..33ba2a4 100644
@@ -2327,6 +2327,7 @@ _scsih_block_io_to_children_attached_directly(struct MPT2SAS_ADAPTER *ioc,
 	u16 handle;
 	u16 reason_code;
 	u8 phy_number;
+	u8 link_rate;
 
 	for (i = 0; i < event_data->NumEntries; i++) {
 		handle = le16_to_cpu(event_data->PHY[i].AttachedDevHandle);

@@ -2337,6 +2338,11 @@ _scsih_block_io_to_children_attached_directly(struct MPT2SAS_ADAPTER *ioc,
 		    MPI2_EVENT_SAS_TOPO_RC_MASK;
 		if (reason_code == MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING)
 			_scsih_block_io_device(ioc, handle);
+		if (reason_code == MPI2_EVENT_SAS_TOPO_RC_PHY_CHANGED) {
+			link_rate = event_data->PHY[i].LinkRate >> 4;
+			if (link_rate >= MPI2_SAS_NEG_LINK_RATE_1_5)
+				_scsih_ublock_io_device(ioc, handle);
+		}
 	}
 }

drivers/scsi/mpt2sas/mpt2sas_scsih.c _scsih_sas_topology_change_event(struct MPT2SAS_ADAPTER *ioc, u8 VF_ID, · line 3877

Quoted 7 lines
drivers/scsi/mpt2sas/mpt2sas_scsih.c +0 -4
@@ -3871,10 +3877,6 @@ _scsih_sas_topology_change_event(struct MPT2SAS_ADAPTER *ioc, u8 VF_ID,
 						link_rate_);
 				}
 			}
-			if (reason_code == MPI2_EVENT_SAS_TOPO_RC_PHY_CHANGED) {
-				if (link_rate_ >= MPI2_SAS_NEG_LINK_RATE_1_5)
-					_scsih_ublock_io_device(ioc, handle);
-			}

OK, so explain these functions _scsih_ublock_io_device and _scsih_block_io_device to me. You're wrongly tampering with device state in them ... it should be using the block/unblock functions in scsi_lib.c if it's a standard usage. If not, it shouldn't be touching the device state, especially SDEV_BLOCK, because that has queue running and plugging implications.

James

#2 lore raw
Quoted 9 lines · James Bottomley

OK, so explain these functions _scsih_ublock_io_device and _scsih_block_io_device to me. You're wrongly tampering with device state in them ... it should be using the block/unblock functions in scsi_lib.c if it's a standard usage. If not, it shouldn't be touching the device state, especially SDEV_BLOCK, because that has queue running
and plugging implications.

This is for failover/fail back. I overlooked using scsi_device_set_state, I assume that is what your refering to. I guess I had been looking at old fc transport code.

Eric