linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sreekanth Reddy <sreekanth.reddy@avagotech.com>
To: jejb@kernel.org, hch@infradead.org
Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	JBottomley@Parallels.com, Sathya.Prakash@avagotech.com,
	kashyap.desai@avagotech.com, linux-kernel@vger.kernel.org,
	thenzl@redhat.com,
	Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Subject: [PATCH 19/20] [SCSI] mpt3sas: When device is blocked followed by unblock fails, unfreeze the I/Os
Date: Mon, 30 Mar 2015 19:25:22 +0530	[thread overview]
Message-ID: <1427723723-12676-20-git-send-email-Sreekanth.Reddy@avagotech.com> (raw)
In-Reply-To: <1427723723-12676-1-git-send-email-Sreekanth.Reddy@avagotech.com>

Issue: When the disks are getting discovered and assigned device handles by the kernel, a device block followed by an unblock (due to broadcast primitives) issued by the driver is interspersed by the kernel changing the state of the device. Therefore the unblock by the driver results in a no operation within the kernel API.

To fix this one, the below patch checks the return of the unblock API and performs a block followed by an unblock to unfreeze the block layer's I/O queue. Sufficient checks and prints are also added in the driver to identify this condition caused by the kernel.

Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 96 +++++++++++++++++++++++++++++-------
 1 file changed, 78 insertions(+), 18 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 0070f78..8e324bc 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2610,6 +2610,75 @@ _scsih_fw_event_cleanup_queue(struct MPT3SAS_ADAPTER *ioc)
 }
 
 /**
+ * _scsih_internal_device_block - block the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ *
+ * make sure device is blocked without error, if not
+ * print an error
+ */
+static void
+_scsih_internal_device_block(struct scsi_device *sdev,
+			struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+	int r = 0;
+
+	sdev_printk(KERN_INFO, sdev, "device_block, handle(0x%04x)\n",
+	    sas_device_priv_data->sas_target->handle);
+	sas_device_priv_data->block = 1;
+
+	r = scsi_internal_device_block(sdev);
+	if (r == -EINVAL)
+		sdev_printk(KERN_WARNING, sdev,
+		    "device_block failed with return(%d) for handle(0x%04x)\n",
+		    sas_device_priv_data->sas_target->handle, r);
+}
+
+/**
+ * _scsih_internal_device_unblock - unblock the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ * make sure device is unblocked without error, if not retry
+ * by blocking and then unblocking
+ */
+
+static void
+_scsih_internal_device_unblock(struct scsi_device *sdev,
+			struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+	int r = 0;
+
+	sdev_printk(KERN_WARNING, sdev, "device_unblock and setting to running, "
+	    "handle(0x%04x)\n", sas_device_priv_data->sas_target->handle);
+	sas_device_priv_data->block = 0;
+	r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+	if (r == -EINVAL) {
+		/* The device has been set to SDEV_RUNNING by SD layer during
+		 * device addition but the request queue is still stopped by
+		 * our earlier block call. We need to perform a block again
+		 * to get the device to SDEV_BLOCK and then to SDEV_RUNNING */
+
+		sdev_printk(KERN_WARNING, sdev,
+		    "device_unblock failed with return(%d) for handle(0x%04x) "
+		    "performing a block followed by an unblock\n",
+		    sas_device_priv_data->sas_target->handle, r);
+		sas_device_priv_data->block = 1;
+		r = scsi_internal_device_block(sdev);
+		if (r)
+			sdev_printk(KERN_WARNING, sdev, "retried device_block "
+			    "failed with return(%d) for handle(0x%04x)\n",
+			    sas_device_priv_data->sas_target->handle, r);
+
+		sas_device_priv_data->block = 0;
+		r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+		if (r)
+			sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
+			    " failed with return(%d) for handle(0x%04x)\n",
+			    sas_device_priv_data->sas_target->handle, r);
+	}
+}
+
+/**
  * _scsih_ublock_io_all_device - unblock every device
  * @ioc: per adapter object
  *
@@ -2628,11 +2697,10 @@ _scsih_ublock_io_all_device(struct MPT3SAS_ADAPTER *ioc)
 		if (!sas_device_priv_data->block)
 			continue;
 
-		sas_device_priv_data->block = 0;
 		dewtprintk(ioc, sdev_printk(KERN_INFO, sdev,
 			"device_running, handle(0x%04x)\n",
 		    sas_device_priv_data->sas_target->handle));
-		scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+		_scsih_internal_device_unblock(sdev, sas_device_priv_data);
 	}
 }
 
@@ -2657,10 +2725,9 @@ _scsih_ublock_io_device(struct MPT3SAS_ADAPTER *ioc, u64 sas_address)
 		if (sas_device_priv_data->sas_target->sas_address
 		    != sas_address)
 			continue;
-		if (sas_device_priv_data->block) {
-			sas_device_priv_data->block = 0;
-			scsi_internal_device_unblock(sdev, SDEV_RUNNING);
-		}
+		if (sas_device_priv_data->block)
+			_scsih_internal_device_unblock(sdev,
+				sas_device_priv_data);
 	}
 }
 
@@ -2685,10 +2752,9 @@ _scsih_ublock_io_device_to_running(struct MPT3SAS_ADAPTER *ioc, u64 sas_address)
 		if (sas_device_priv_data->sas_target->sas_address
 		      != sas_address)
 			continue;
-		if (sas_device_priv_data->block) {
-			sas_device_priv_data->block = 0;
-			scsi_internal_device_unblock(sdev, SDEV_RUNNING);
-		}
+		if (sas_device_priv_data->block)
+			_scsih_internal_device_unblock(sdev,
+					sas_device_priv_data);
 	}
 }
 
@@ -2711,10 +2777,7 @@ _scsih_block_io_all_device(struct MPT3SAS_ADAPTER *ioc)
 			continue;
 		if (sas_device_priv_data->block)
 			continue;
-		sas_device_priv_data->block = 1;
-		scsi_internal_device_block(sdev);
-		sdev_printk(KERN_INFO, sdev, "device_blocked, handle(0x%04x)\n",
-		    sas_device_priv_data->sas_target->handle);
+		_scsih_internal_device_block(sdev, sas_device_priv_data);
 	}
 }
 
@@ -2739,10 +2802,7 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16 handle)
 			continue;
 		if (sas_device_priv_data->block)
 			continue;
-		sas_device_priv_data->block = 1;
-		scsi_internal_device_block(sdev);
-		sdev_printk(KERN_INFO, sdev,
-			"device_blocked, handle(0x%04x)\n", handle);
+		_scsih_internal_device_block(sdev, sas_device_priv_data);
 	}
 }
 
-- 
2.0.2


  parent reply	other threads:[~2015-03-30 13:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 13:55 [PATCH 00/20] mpt3sas: driver update Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 02/20] [SCSI] mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state Sreekanth Reddy
2015-06-18 10:00   ` Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 03/20] [SCSI] mpt3sas: Added module parameter 'unblock_io' to unblock IO's during disk addition Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 04/20] [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 05/20] [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 07/20] [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00 Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 08/20] [SCSI] mpt3sas: Update MPI2 strings to MPI2.5 Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 09/20] [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 11/20] [SCSI] mpt3sas: Add branding string support for OEM custom HBA Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 12/20] [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00 Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 13/20] [SCSI] mpt3sas: MPI 2.5 Rev K (2.5.6) specifications Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 14/20] [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081 Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 15/20] [SCSI] mpt3sas: Return host busy error status to SML when DMA mapping of scatter gather list fails for a SCSI command Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 16/20] [SCSI] mpt3sas: Added support for customer specific branding Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 17/20] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API Sreekanth Reddy
2015-03-30 13:55 ` [PATCH 18/20] [SCSI] mpt3sas: Call dma_mapping_error() API after mapping an address with dma_map_single() API Sreekanth Reddy
2015-03-30 13:55 ` Sreekanth Reddy [this message]
2015-03-30 13:55 ` [PATCH 20/20] [SCSI] mpt3sas : Bump mpt3sas driver version to 9.100.00.00 Sreekanth Reddy
2015-04-05 16:09 ` [PATCH 00/20] mpt3sas: driver update Christoph Hellwig
2015-04-08  5:43   ` Sreekanth Reddy
2015-04-21 12:13     ` Christoph Hellwig
2015-04-24 21:27       ` Sathya Prakash
2015-06-12  9:42 Sreekanth Reddy
2015-06-12  9:42 ` [PATCH 19/20] [SCSI] mpt3sas: When device is blocked followed by unblock fails, unfreeze the I/Os Sreekanth Reddy
2015-06-15  9:58   ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1427723723-12676-20-git-send-email-Sreekanth.Reddy@avagotech.com \
    --to=sreekanth.reddy@avagotech.com \
    --cc=JBottomley@Parallels.com \
    --cc=Sathya.Prakash@avagotech.com \
    --cc=hch@infradead.org \
    --cc=jejb@kernel.org \
    --cc=kashyap.desai@avagotech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=thenzl@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).