linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Jens Axboe <axboe@suse.de>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	list linux-ide <linux-ide@vger.kernel.org>
Subject: Re: IDE issues with  "choose_drive"
Date: Thu, 06 Oct 2005 11:02:48 +1000	[thread overview]
Message-ID: <1128560569.22073.25.camel@gaston> (raw)
In-Reply-To: <1128559019.22073.19.camel@gaston>


> The first one is the one I'm trying to fix, it's basically a hang on
> wakeup from sleep. What happens is that both drives are blocked
> (suspended, drive->blocked is set). Their IO queues contains some
> requests that haven't been serviced yet. We receive the resume()
> callback for one of them. We react by inserting a wakeup request at the
> head of the queue and waiting for it to complete. However, when we reach
> ide_do_request(), choose_drive() may return the other drive (the one
> that is still sleeping). In this case, we hit the test for blocked queue
> and just break out of the loop. We end up never servicing the other
> drive queue which is the one we are trying to wakeup, thus we hang.

Oh, and here's the ugly workaround beeing tested by the users who are
having the problem so far. Not really a proper fix though...

--- linux-work.orig/drivers/ide/ide-io.c	2005-09-22 14:06:31.000000000 +1000
+++ linux-work/drivers/ide/ide-io.c	2005-10-06 10:49:53.000000000 +1000
@@ -1101,6 +1101,7 @@
 	ide_hwif_t	*hwif;
 	struct request	*rq;
 	ide_startstop_t	startstop;
+	int             loops = 0;
 
 	/* for atari only: POSSIBLY BROKEN HERE(?) */
 	ide_get_lock(ide_intr, hwgroup);
@@ -1153,6 +1154,7 @@
 			/* no more work for this hwgroup (for now) */
 			return;
 		}
+	again:
 		hwif = HWIF(drive);
 		if (hwgroup->hwif->sharing_irq &&
 		    hwif != hwgroup->hwif &&
@@ -1192,8 +1194,14 @@
 		 * though. I hope that doesn't happen too much, hopefully not
 		 * unless the subdriver triggers such a thing in its own PM
 		 * state machine.
+		 *
+		 * We count how many times we loop here to make sure we service
+		 * all drives in the hwgroup without looping for ever
 		 */
 		if (drive->blocked && !blk_pm_request(rq) && !(rq->flags & REQ_PREEMPT)) {
+			drive = drive->next ? drive->next : hwgroup->drive;
+			if (loops++ < 4 && !blk_queue_plugged(drive->queue))
+				goto again;
 			/* We clear busy, there should be no pending ATA command at this point. */
 			hwgroup->busy = 0;
 			break;



  reply	other threads:[~2005-10-06  1:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-06  0:36 IDE issues with "choose_drive" Benjamin Herrenschmidt
2005-10-06  1:02 ` Benjamin Herrenschmidt [this message]
2005-10-08  1:15   ` Benjamin Herrenschmidt
2005-10-08  8:29     ` Bartlomiej Zolnierkiewicz
2005-10-08 22:18       ` Benjamin Herrenschmidt

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=1128560569.22073.25.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).