All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
To: james.bottomley@hansenpartnership.com
Cc: stephenmcameron@gmail.com, mikem@beardog.cce.hp.com,
	thenzl@redhat.com, linux-scsi@vger.kernel.org, scott.teel@hp.com
Subject: [PATCH 09/11] hpsa: prevent stalled i/o
Date: Thu, 07 Nov 2013 10:46:10 -0600	[thread overview]
Message-ID: <20131107164610.3504.12563.stgit@beardog.cce.hp.com> (raw)
In-Reply-To: <20131107164258.3504.5892.stgit@beardog.cce.hp.com>

From: Stephen M. Cameron <scameron@beardog.cce.hp.com>

If a fifo full condition is encountered, i/o requests will stack
up in the h->reqQ queue.  The only thing which empties this queue
is start_io, which only gets called when new i/o requests come in.
If none are forthcoming, i/o in h->reqQ will be stalled.

To fix this, whenever fifo full condition is encountered, this
is recorded, and the interrupt handler examines this to see
if a fifo full condition was recently encountered when a
command completes and will call start_io to prevent i/o's in
h->reqQ from getting stuck.

I've only ever seen this problem occur when running specialized
test programs that pound on the the CCISS_PASSTHRU ioctl.

Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
---
 drivers/scsi/hpsa.c |   32 ++++++++++++++++++++++++++++++--
 drivers/scsi/hpsa.h |    1 +
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ebb7144..7256b29 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3479,9 +3479,11 @@ static void start_io(struct ctlr_info *h)
 		c = list_entry(h->reqQ.next, struct CommandList, list);
 		/* can't do anything if fifo is full */
 		if ((h->access.fifo_full(h))) {
+			h->fifo_recently_full = 1;
 			dev_warn(&h->pdev->dev, "fifo full\n");
 			break;
 		}
+		h->fifo_recently_full = 0;
 
 		/* Get the first entry from the Request Q */
 		removeQ(c);
@@ -3535,15 +3537,41 @@ static inline int bad_tag(struct ctlr_info *h, u32 tag_index,
 static inline void finish_cmd(struct CommandList *c)
 {
 	unsigned long flags;
+	int io_may_be_stalled = 0;
+	struct ctlr_info *h = c->h;
 
-	spin_lock_irqsave(&c->h->lock, flags);
+	spin_lock_irqsave(&h->lock, flags);
 	removeQ(c);
-	spin_unlock_irqrestore(&c->h->lock, flags);
+
+	/*
+	 * Check for possibly stalled i/o.
+	 *
+	 * If a fifo_full condition is encountered, requests will back up
+	 * in h->reqQ.  This queue is only emptied out by start_io which is
+	 * only called when a new i/o request comes in.  If no i/o's are
+	 * forthcoming, the i/o's in h->reqQ can get stuck.  So we call
+	 * start_io from here if we detect such a danger.
+	 *
+	 * Normally, we shouldn't hit this case, but pounding on the
+	 * CCISS_PASSTHRU ioctl can provoke it.  Only call start_io if
+	 * commands_outstanding is low.  We want to avoid calling
+	 * start_io from in here as much as possible, and esp. don't
+	 * want to get in a cycle where we call start_io every time
+	 * through here.
+	 */
+	if (unlikely(h->fifo_recently_full) &&
+		h->commands_outstanding < 5)
+		io_may_be_stalled = 1;
+
+	spin_unlock_irqrestore(&h->lock, flags);
+
 	dial_up_lockup_detection_on_fw_flash_complete(c->h, c);
 	if (likely(c->cmd_type == CMD_SCSI))
 		complete_scsi_command(c);
 	else if (c->cmd_type == CMD_IOCTL_PEND)
 		complete(c->waiting);
+	if (unlikely(io_may_be_stalled))
+		start_io(h);
 }
 
 static inline u32 hpsa_tag_contains_index(u32 tag)
diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/hpsa.h
index fd9910a..01c3283 100644
--- a/drivers/scsi/hpsa.h
+++ b/drivers/scsi/hpsa.h
@@ -137,6 +137,7 @@ struct ctlr_info {
 	u32 lockup_detected;
 	struct delayed_work monitor_ctlr_work;
 	int remove_in_progress;
+	u32 fifo_recently_full;
 	/* Address of h->q[x] is passed to intr handler to know which queue */
 	u8 q[MAX_REPLY_QUEUES];
 	u32 TMFSupportFlags; /* cache what task mgmt funcs are supported. */


  parent reply	other threads:[~2013-11-07 16:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-07 16:45 [PATCH 00/11] hpsa: minor fixes and cleanups Stephen M. Cameron
2013-11-07 16:45 ` [PATCH 01/11] hpsa: use workqueue instead of kernel thread for lockup detection Stephen M. Cameron
2013-12-02 18:00   ` James Bottomley
2013-12-04 16:31     ` scameron
2013-12-04 17:42       ` James Bottomley
2013-11-07 16:45 ` [PATCH 02/11] hpsa: do not attempt to flush the cache on locked up controllers Stephen M. Cameron
2013-11-07 16:45 ` [PATCH 03/11] hpsa: add 5 second delay after doorbell reset Stephen M. Cameron
2013-11-08 13:51   ` Tomas Henzl
2013-11-08 14:44     ` scameron
2013-11-08 15:02       ` Tomas Henzl
2013-11-08 15:31         ` scameron
2013-12-01  0:42           ` James Bottomley
2013-12-02 17:15             ` Mike Miller
2013-12-02 17:23               ` James Bottomley
2013-12-02 17:24                 ` Miller, Mike (OS Dev)
2013-11-07 16:45 ` [PATCH 04/11] hpsa: do not discard scsi status on aborted commands Stephen M. Cameron
2013-11-07 16:45 ` [PATCH 05/11] hpsa: remove unneeded include of seq_file.h Stephen M. Cameron
2013-11-07 16:45 ` [PATCH 06/11] hpsa: fix memory leak in CCISS_BIG_PASSTHRU ioctl Stephen M. Cameron
2013-11-07 16:46 ` [PATCH 07/11] hpsa: add MSA 2040 to list of external target devices Stephen M. Cameron
2013-11-07 16:46 ` [PATCH 08/11] hpsa: cap CCISS_PASSTHRU at 20 concurrent commands Stephen M. Cameron
2013-11-07 16:46 ` Stephen M. Cameron [this message]
2013-11-07 16:46 ` [PATCH 10/11] hpsa: rename scsi prefetch field Stephen M. Cameron
2013-11-07 16:46 ` [PATCH 11/11] hpsa: enable unit attention reporting Stephen M. Cameron

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=20131107164610.3504.12563.stgit@beardog.cce.hp.com \
    --to=scameron@beardog.cce.hp.com \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mikem@beardog.cce.hp.com \
    --cc=scott.teel@hp.com \
    --cc=stephenmcameron@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.