public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox