public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Michael Buesch <mb@bu3sch.de>, Jan Kara <jack@suse.cz>,
	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: Wed, 9 Jul 2008 20:46:12 +0200	[thread overview]
Message-ID: <20080709184612.GA3529@duck.suse.cz> (raw)
In-Reply-To: <20080626183610.GI20851@kernel.dk>

On Thu 26-06-08 20:36:11, Jens Axboe wrote:
> On Thu, Jun 26 2008, Michael Buesch wrote:
> > 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 :)
> 
> Something like this, totally untested...
  BTW, just to confirm some positive result: On one of my machines I was
able to trigger the warning message in this patch. So it definitely fixes
some problem.

									Honza

> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 68e7f19..5c1e663 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1308,13 +1308,29 @@ static int cdrom_read_capacity(ide_drive_t *drive, unsigned long *capacity,
>  	req.cmd_flags |= REQ_QUIET;
>  
>  	stat = ide_cd_queue_pc(drive, &req);
> -	if (stat == 0) {
> -		*capacity = 1 + be32_to_cpu(capbuf.lba);
> -		*sectors_per_frame =
> -			be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
> +	if (stat)
> +		return stat;
> +
> +	/*
> +	 * Sanity check the given block size
> +	 */
> +	switch (capbuf.blocklen) {
> +	case 512:
> +	case 1024:
> +	case 2048:
> +	case 4096:
> +		break;
> +	default:
> +		printk(KERN_ERR "ide-cd: weird block size %u\n",
> +							capbuf.blocklen);
> +		printk(KERN_ERR "ide-cd: default to 2kb block size\n");
> +		capbuf.blocklen = 2048;
> +		break;
>  	}
>  
> -	return stat;
> +	*capacity = 1 + be32_to_cpu(capbuf.lba);
> +	*sectors_per_frame = be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
> +	return 0;
>  }
>  
>  static int cdrom_read_tocentry(ide_drive_t *drive, int trackno, int msf_flag,
> 
> -- 
> Jens Axboe
> 

  parent reply	other threads:[~2008-07-09 18:46 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
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 [this message]
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=20080709184612.GA3529@duck.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=jens.axboe@oracle.com \
    --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