[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200806262021.32140.mb@bu3sch.de>
Date: Thu, 26 Jun 2008 20:21:31 +0200
From: Michael Buesch <mb@...sch.de>
To: Jens Axboe <jens.axboe@...cle.com>
Cc: Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Oops when using growisofs
On Thursday 26 June 2008 20:11:42 Jens Axboe wrote:
> 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.
I agree with the need for a hardware sanity check and I would happily test
any RFC patch :)
--
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists