public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Jan Kara <jack@suse.cz>
Cc: Michael Buesch <mb@bu3sch.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Oops when using growisofs
Date: Thu, 26 Jun 2008 20:11:42 +0200	[thread overview]
Message-ID: <20080626181142.GH20851@kernel.dk> (raw)
In-Reply-To: <20080626170513.GE23386@duck.suse.cz>

On Thu, Jun 26 2008, Jan Kara wrote:
> On Wed 25-06-08 11:46:29, Michael Buesch wrote:
> > On Wednesday 25 June 2008 11:37:00 Jan Kara wrote:
> > > > Yeah the IO error is the trigger.
> > > > I noticed that it had obvious troubles accessing the DVD that was in the drive.
> > > > It sweeped over it for several seconds, then hung the system for 2 or 3 seconds
> > > > and then oopsed. But after that everything continued to work as usual.
> > > > (Except kded of course)
> > >   Hmm, by "accessing" do you mean that you've mounted the burned DVD and when
> > > browsing it the IO error and the oops occured or that IO error happened
> > > when burning? It is important because in the first case i_blkbits would be
> > > taken from some ISOFS inode desribing some file while in the second case
> > > i_blkbits are from the inode of the device...
> > I don't know. kded, which caused the oops, is always running. It is a KDE daemon
> > that polls device state and so on. So yeah, it might have accessed the drive
> > while growisofs was writing to it.
> > 
> > However with "accessing" I mean the DVD drive motor was spinning up and down
> > and the laser lens was moving like crazy. The sound that happens, if you put
> > a completely scratched DVD into the drive and it is unable to make sense of it.
> > However, this was not scratched. It was a new DVD with one session on it that
> > I just burnt 5 minutes before that. So I wanted to append another session to it
> > and it crashed and resulted in IO errors in growisofs.
>   I've been looking into this problem for some time. The only way how
>   I see blocksize can be set so big is in cdrom_read_capacity() in
>   drivers/ide/ide-cd.c. That basically blindly fills in
>   queue->hardsect_size with what the drive returns and this can
>   propagate in bd_set_size() to i_blkbits.  Jens, do you think that is
>   possible? Shouldn't ide_cd_read_toc() do some sanity checks of the
>   blocksize returned?

It can't hurt, the value should be >= 512b and <= 4kb. Normally it would
be 2kb, but some devices have a 512b switch so that is also seen. Not
sure that 1kb and 4kb are valid, but at least it would still point to
the drive possibly returning valid data and not garbage. So accept all
those, reject (and complain) if it isn't one of those and default to 2kb.

-- 
Jens Axboe


  reply	other threads:[~2008-06-26 18:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-22 16:18 Oops when using growisofs Michael Buesch
2008-06-22 21:22 ` Arnd Bergmann
2008-06-22 21:31   ` Arnd Bergmann
2008-06-22 22:09     ` Michael Buesch
2008-06-22 22:05   ` Michael Buesch
2008-06-22 22:28     ` Michael Buesch
2008-06-23  6:34       ` Andrew Morton
2008-06-23  6:59         ` Nick Piggin
2008-06-24 17:28         ` Jan Kara
2008-06-24 18:39           ` Michael Buesch
2008-06-25  1:42             ` Arnd Bergmann
2008-06-25  9:37             ` Jan Kara
2008-06-25  9:46               ` Michael Buesch
2008-06-26 17:05                 ` Jan Kara
2008-06-26 18:11                   ` Jens Axboe [this message]
2008-06-26 18:21                     ` Michael Buesch
2008-06-26 18:36                       ` Jens Axboe
2008-06-26 18:39                         ` Michael Buesch
2008-06-26 18:41                           ` Jens Axboe
2008-06-29 19:39                         ` Michael Buesch
2008-07-09 18:46                         ` Jan Kara
2008-07-22  9:25                         ` Andrew Morton

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=20080626181142.GH20851@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    /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