public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: mh@nadir.org, linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: oops w/ 2.6.2-mm1 on ppc32
Date: Sun, 15 Feb 2004 00:10:19 -0800	[thread overview]
Message-ID: <20040215001019.33e4089b.akpm@osdl.org> (raw)
In-Reply-To: <1076831383.6958.38.camel@gaston>

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2004-02-15 at 18:41, Marc Heckmann wrote:
> > It happened while the machine was waking up from sleep. There were no
> > UDF or ISO filesystems mounted at the time, in fact, there wasn't even
> > a cd in the drive. The "autorun" process was running though (polls the
> > cdrom drive, to see if a disc has been inserted...). There were some
> > request timeouts on the cdrom drive (hdc) just before, it went to
> > sleep (system was idle at the time, I wasn't even at home).
> > 
> > Here is the kernel output before and after the machine went to sleep. The Oops
> > is at the bottom.
> 
> Looks like CD went berserk, and something didn't deal with the
> error correctly... I don't know those code path in there
> very well... Can you paste more of the ide-cd errors,
> those are weird.

Note that isofs_fill_super() calls sb_bread() before setting the blocksize.
For this it is relying on blockdev.bd_block_size being set up
appropriately.

Which all tends to imply that the underlying queue's ->hardsect_size is
very wrong.

The code which is responsible for setting up the queue's hardsect_size
appears to live in cdrom_read_toc():

	/* Check to see if the existing data is still valid.
	   If it is, just return. */
	(void) cdrom_check_status(drive, sense);

	if (CDROM_STATE_FLAGS(drive)->toc_valid)
		return 0;

	/* Try to get the total cdrom capacity and sector size. */
	stat = cdrom_read_capacity(drive, &toc->capacity, &sectors_per_frame,
				   sense);
	if (stat)
		toc->capacity = 0x1fffff;

	set_capacity(drive->disk, toc->capacity * sectors_per_frame);
	blk_queue_hardsect_size(drive->queue,
				sectors_per_frame << SECTOR_BITS);

I'm wondering about that `return 0;' in there.  That will return "success"
even though we haven't set up half the things which should have been set
up.

Jens, should we be returning some sort of error code there?

  reply	other threads:[~2004-02-15  8:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-15  7:41 oops w/ 2.6.2-mm1 on ppc32 Marc Heckmann
2004-02-15  7:49 ` Benjamin Herrenschmidt
2004-02-15  8:10   ` Andrew Morton [this message]
2004-02-15  9:42     ` Jens Axboe
2004-02-15  9:49     ` Benjamin Herrenschmidt
2004-02-15  8:24   ` Marc Heckmann

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=20040215001019.33e4089b.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mh@nadir.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