Re: Oops when using growisofs

[Jens Axboe]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/