From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
mh@nadir.org, linux-kernel@vger.kernel.org
Subject: Re: oops w/ 2.6.2-mm1 on ppc32
Date: Sun, 15 Feb 2004 10:42:24 +0100 [thread overview]
Message-ID: <20040215094224.GY26397@suse.de> (raw)
In-Reply-To: <20040215001019.33e4089b.akpm@osdl.org>
On Sun, Feb 15 2004, Andrew Morton wrote:
> 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, §ors_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?
I'll have a look to see if it can go wrong, but ->toc_valid should never
be set if the hardsector stuff etc hasn't been set up yet.
--
Jens Axboe
next prev parent reply other threads:[~2004-02-15 9:42 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
2004-02-15 9:42 ` Jens Axboe [this message]
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=20040215094224.GY26397@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--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