All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Giacomo Catenazzi <cate@cateee.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	akpm@linux-foundation.org
Subject: Re: regression: disk error loop (panic?) ide_do_rw_disk-bad:
Date: Wed, 18 Jul 2007 22:08:36 +0200	[thread overview]
Message-ID: <20070718200835.GK11657@kernel.dk> (raw)
In-Reply-To: <alpine.LFD.0.999.0707181238500.27353@woody.linux-foundation.org>

On Wed, Jul 18 2007, Linus Torvalds wrote:
> 
> 
> On Tue, 17 Jul 2007, Bartlomiej Zolnierkiewicz wrote:
> > 
> > On Tuesday 17 July 2007, Giacomo Catenazzi wrote:
> > > 
> > > last git changes to git give me the following error (repead very quickly):
> > > 
> > > sector 14657019, nr/cmr 0/0
> > > bio f7b59280, biotail f7b59280, buffer 0000000, date 0000000, len 36
> > > ide_do_rw_disk-bad command: dev hda: type 2, flags 104c8
> > 
> > ide-disk driver and type 2 (REQ_TYPE_BLOCK_PC) requests don't mix well
> 
> Hmm. I started wondering about this. 
> 
> Sure, ide-disk doesn't like non-fs requests, but I'm wondering why the 
> error apparently keeps repeating? We should error out once, and that 
> should be it.
> 
> So I'm wondering whether the
> 
> 	ide_end_request(drive, 0, 0);
> 	return ide_stopped;
> 
> is the real bug.
> 
> The thing is, non-fs requests won't have nr_sectors set, so the 0 will 
> stay as a zero (the IDE layer has some "turn zero into current sector 
> number", but that doesn't work for commands that aren't sector-based!), 
> and as a result, we'll "complete" zero bytes, and the bio will stay 
> active!
> 
> So the code should probably at the _least_ say that it's finished one 
> whole sector, and it would probably be much better to make it be based on 
> "rq->data_len", which should be reliable.
> 
> Of course, since the "ide_end_request()" takes the data in sectors, but 
> the request layer does it in bytes, we have to round the thing up and the 
> ide_end_request() thing will turn it into too many bytes, but that's ok - 
> "end_that_request_first()" doesn't care if we complete "too many" bytes.
> 
> So a diff something like this is, I think, the right thing to do, and 
> should make the IDE disk driver handle non-fs requests gracefully (it will 
> *fail* them, of course, but that's another issue).
> 
> Bartlomiej? Am I missing soemthing?

I think your analysis is pretty good, however you'd probably want to
incorporate that direct in ide_end_request(). Passing in 0 means end the
first chunk of the request, for pc type requests that should just be the
full thing as we cannot just move forward like in a read/write request.

Better still would be to make __ide_end_request() take a byte count
instead and use end_that_request_chunk(). Then you can get rid of the
rounding as well.

diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index c5b5011..71b317a 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -114,8 +114,12 @@ int ide_end_request (ide_drive_t *drive, int uptodate, int nr_sectors)
 	spin_lock_irqsave(&ide_lock, flags);
 	rq = HWGROUP(drive)->rq;
 
-	if (!nr_sectors)
-		nr_sectors = rq->hard_cur_sectors;
+	if (!nr_sectors) {
+		if (!blk_fs_request(rq))
+			nr_sectors = (rq->data_len + 511) >> 9;
+		else
+			nr_sectors = rq->hard_cur_sectors;
+	}
 
 	ret = __ide_end_request(drive, rq, uptodate, nr_sectors);
 

-- 
Jens Axboe


  reply	other threads:[~2007-07-18 20:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-17 19:49 regression: disk error loop (panic?) ide_do_rw_disk-bad: Giacomo Catenazzi
2007-07-17 20:47 ` Michal Piotrowski
2007-07-17 21:20 ` Bartlomiej Zolnierkiewicz
2007-07-17 21:24   ` Linus Torvalds
2007-07-17 22:45     ` Bartlomiej Zolnierkiewicz
2007-07-17 22:38       ` Linus Torvalds
2007-07-17 23:14         ` Bartlomiej Zolnierkiewicz
2007-07-17 23:18           ` Jeff Garzik
2007-07-18  8:09         ` Jens Axboe
2007-07-17 22:57       ` Linus Torvalds
2007-07-18  6:31     ` Giacomo Catenazzi
2007-07-18 19:57   ` Linus Torvalds
2007-07-18 20:08     ` Jens Axboe [this message]
2007-07-18 20:11       ` Jens Axboe
2007-07-18 20:14       ` Linus Torvalds
2007-07-18 20:27         ` Jens Axboe
2007-07-18 22:53           ` Bartlomiej Zolnierkiewicz
2007-07-18 23:20             ` Linus Torvalds
2007-07-19  6:13               ` Jens Axboe
2007-07-19  6:40               ` Giacomo Catenazzi
2007-07-19  6:47                 ` Jens Axboe

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=20070718200835.GK11657@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bzolnier@gmail.com \
    --cc=cate@cateee.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 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.