Re: linux kernel error reading end of cd/dvd
On Tue 14 October 2003 12:30, Andy Polyakov wrote:
> Meet the players in the field:
>
> - block buffer which provides for read-ahead, I/O requests'
> slicing and coalescing;
> - value returned by READ CAPACITY command, hereafter simply READ
> CAPACITY;
> - actual lead-out position;
>
> Rules of the game (please note that I'm not claiming that I know
> all the rules in detail:-):
>
> - block buffer rearranges I/O depending on *momentary*
> availability of spare memory, e.g. even if you ask for bs=2k, it
> may coalesce them to e.g. 126KB chunks, or it may break larger
> requests to a number of 4KB ones;
> - no requests are posed beyond the READ CAPACITY;
> - READ CAPACITY coincides with lead-out position most of the
> time, *but not always*;
> - CD lead-out position is documented to be inaccurate [with 75
> blocks inaccuracy?], DVD lead-out position is believed to be
> accurate; - CD lead-out is preceded by few unaccesible blocks
> (unless disk is recorded in DAO mode?), lead-out itself is
> unaccesible;
Thanks for the explanation! That sheds some more light on the case.
I've dug up the ECMA-130 spec (== Yellow Book for all practical
purposes) from www.ecma-international.org and after a bit of
searching I found this (from section 22.3.4.2):
"If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the
beginning of the Lead-out Track, thus the address of the first
Section of the Lead-out Track."
The TOC basically consists of a list of records, each of which
specifies a track number and a start address in min:sec:frac format
(with a fraction being 1/75th of a second). The last element in the
list describes the start of the Lead-out, as quoted above.
Now the interesting bit is that this is actually section-accurate,
and that each section holds one block (ie 2k) of data. Also note
that the last readable block before the Lead-out is at
address_of_lead_out - 1. At any rate, unless I missed something,
the amount of readable blocks is actually stored on the CD, and the
number is accurate.
Okay, so that's how the information is stored on the disc
physically. A bit of Googling got me to
http://www.t10.org/ftp/t10/document.01/01-246r0.pdf, which states
that the READ CAPACITY SCSI bus command returns a logical block
address (LBA) and a block length in bytes. The LBA is the address
of the last logical block on the disc, so the number of blocks in
total before the Lead-out is actually LBA + 1.
From /usr/src/linux-2.4.21/drivers/ide/ide-cd.c,
cdrom_read_capacity:
pc.c[0] = GPCMD_READ_CDVD_CAPACITY;
pc.buffer = (char *)&capbuf;
pc.buflen = sizeof(capbuf);
stat = cdrom_queue_packet_command(drive, &pc);
if (stat == 0)
*capacity = 1 + be32_to_cpu(capbuf.lba);
return stat;
So it seems that as long as the drive gives the correct LBA number
(should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as
above), ide-cd will report the correct media size.
Readcd from cdrecord uses the exact same way to get the capacity
from the drive, and displays the amount of blocks correctly.
According to it, my Nero CD has 169825 blocks.
Unfortunately the -fulltoc option of readcd isn't implemented, so I
can't verify that this matches the information on the disc. Does
anyone know of another way to get to the raw TOC data on a CD?
Now, as I said ide-cd.c reads the amount of blocks the same way, so
it will get the same value. I'm not sure what happens with this
value though, presumably it ends up with the block driver as Andy
described, but I haven't found out how yet.
Looking at the Linux SCSI stuff, I found this in drivers/scsi/sr.c:
/*
* The SCSI specification allows for the value returned
* by READ CAPACITY to be up to 75 2K sectors past the
* last readable block. Therefore, if we hit a medium
* error within the last 75 2K sectors, we decrease the
* saved size value.
*/
if ((error_sector >> 1) < sr_sizes[device_nr] &&
scsi_CDs[device_nr].capacity - error_sector < 4 *75)
sr_sizes[device_nr] = error_sector >> 1;
So it seems that you were correct about that.
<snip>
>
> Relevant question is when READ CAPACITY is not equal to lead-out
> offset? I don't know about CD, but in DVD case most units would
> report full media capacity for READ CAPACITY under following
> circumstances:
Well, it looks like that's up to the drive's firmware. READ CAPACITY
is pretty much useless, since it's allowed to give wrong
information.
<snip>
>
> case. One can wonder if the common block buffer could do better
> job spotting the last addressible sector? Well, yes, but do keep
> in mind that it's a *common* block buffer, which is not aware of
> CD technicalities... So that I'd say that it's perfectly
> legitimate to advice as following. If you really have to checksum
> the whole image, then make sure to bypass the block buffer *and*
> provide sane block count value. A.
Well, it seems to me that the block driver gets the capacity from
the underlying device driver. So if that driver gives the correct
capacity to the block layer, things should actually work fine. The
question is how to get the device driver to give the correct
capacity, if READ CAPACITY doesn't work well enough.
I can see two options:
1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to
read the 75 2k sectors before that. Catch the IO error, and adjust
the capacity based on the number of succesfully read sectors.
2) Modify ide-cd.c and sr.c to read the TOC and get the capacity
directly from the disc, thus completely circumventing the READ
CAPACITY command.
Comments?
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Reply to: