mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Daniel Pittman <daniel@rimspace.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: IDE-CD issue: total capacity set to 0 incorrectly on some DVD-R discs.
Date: Mon, 15 Sep 2003 17:22:24 +0200	[thread overview]
Message-ID: <20030915152224.GB2928@suse.de> (raw)
In-Reply-To: <873cey6u6e.fsf@enki.rimspace.net>

On Mon, Sep 15 2003, Daniel Pittman wrote:
> Jens, I mentioned a little while ago on the linux-kernel list that I had
> an issue with my DVD drive (Pioneer DVD-ROM ATAPIModel DVD-106S 012)
> incorrectly determining a zero blocks size for some DVD-R discs.
> 
> After a lot of working to track down what the failure was, I found that
> the following code in ide-cd.c, and cdrom.c, was the source of the
> issue.
> 
> When checking the TOC of a disc the first time through, the following
> code at line 2376 in ide-cd.c is executed:
> 
> 	stat = cdrom_get_last_written(cdi, (long *) &toc->capacity);
> 	if (stat)
> 		stat = cdrom_read_capacity(drive, &toc->capacity, sense);
> 	if (stat)
> 		toc->capacity = 0x1fffff;
> 
> 	set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
> 
> On the problematic disc/drive combination, cdrom_get_last_written
> returns 0, and sets toc->capacity to 0.
> 
> At the time, the cdrom_get_last_written code went through, checked the
> 'ti.lra_v' field, which the comment suggests is "last recorded sector",
> then did the "make it up" path.
> 
> The values of ti.track_start, ti.track_size and ti.free_blocks were all
> zero as well, suggesting that the structure returned by
> cdrom_get_track_info was not very well populated at all.
> 
> Obviously, though, from testing the function cdrom_read_capacity does
> get the correct size for the track, but something (the recording
> software, perhaps) is not setting up the "last written" stuff correctly.
> 
> For me, the following trivial patch to ide-cd.c corrects the issue, and
> all my software works just fine afterwards.
> 
> I am happy to continue to work on the issue if you don't think that this
> is the right fix, but I would need some guidance in how to continue --
> or just a patch to test. ;)

Thanks for doing the follow up work, I definitely agree with your
solution. I'll make sure it gets in, thanks.

-- 
Jens Axboe


      reply	other threads:[~2003-09-15 15:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-15 13:46 Daniel Pittman
2003-09-15 15:22 ` Jens Axboe [this message]

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=20030915152224.GB2928@suse.de \
    --to=axboe@suse.de \
    --cc=daniel@rimspace.net \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®