[Debburn-devel] CD-Extra issues

[Thomas Schmitt]

Hi,

>  Knowing that the audio tracks are not readiable I was somehow assuming
> the audio tracks to be ignored

Not knowing exactly what the driver does, i assume it
issues an SCSI command READ(10) and gets an error like
  5 64 00 ILLEGAL MODE FOR THIS TRACK


> Mounting still doesn't work.  The mount man page documents the block size
> to default to 1024 so I tried to add block=2048.

The default block size for sbsector= is supposed to be 2048,
because it is an option of filesystem type "iso9660" and
to be applied before the Primary Volume Descriptor of the
filesystem can tell an non-standard block size.


>   mount -t iso9660 -o session=17 /dev/sr0 /mnt
> yields:
> [238634.103799] ISOFS: Session 18 start 291114 type 4

We got the right block address here. "type" might refer to
the control nibble of the track: 0=audio, 4=data.
It seems that session= actually addresses tracks and not sessions.
Further it seems to start counting by 0, which is unusual with
MMC sessions (or tracks).

> [238413.898930] ISO 9660 Extensions: Microsoft Joliet Level 3

It sees the Volume Descriptor which indicates Joliet.
We are at or very near to the right read position.

> [238413.898940] ISOFS: Interleaved files not (yet) supported.
> [238413.898942] ISOFS: File unit size != 0 for ISO file (18642688).
> [238413.898947] ISOFS: changing to secondary root

And tries to use it after inspection of the Primary Volume
Descriptor and/or the ISO 9660 root directory yielded bad vaues.


> http://ubuntuforums.org/archive/index.php/t-1088919.html
>> Mar 6 13:28:25 ubuntu-desktop kernel: [51021.405047] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 

This is something different: A problem between drive and medium.


> Time to dive into the kernel code?

Try the following to make sure it really is the fault of mount
operating on a real CD drive:

  # Create a pedestal of 291114 blocks of 2048 bytes
  dd if=/dev/zero bs=2048 count=291114 of=iso_mockup.iso

  # Append the ISO session from CD
  dd if=/dev/sr0 bs=2048 skip=291114 count=$((89114624/2048)) >>iso_mockup.iso

  # (As superuser) mount the copied ISO session
  mount -t iso9660 -o loop,sbsector=291114 iso_mockup.iso /mnt/iso

If this works properly, then the next step is to find out
what might cause the two complaints with the CD.
I see in my very old kernel source fs/isofs/inode.c 
        struct iso_directory_record * de;
        ...
        if (de->interleave[0]) {
                printk("Interleaved files not (yet) supported.\n");
        ...
        if (de->file_unit_size[0] != 0) {
                printk("File unit size != 0 for ISO file (%ld).\n",
                       inode->i_ino);

File include/linux/iso_fs.h declares struct iso_directory_record
as an analogon oc ECMA-119, 9.1 "Format of a Directory Record".
  struct iso_directory_record {
        ...
        char file_unit_size             [ISODCL (27, 27)]; /* 711 */
        char interleave                 [ISODCL (28, 28)]; /* 711 */
        ...
about which ECMA-119 says:
  "9.1.7 File Unit Size (BP 27)
   This field shall contain an 8-bit number. This number shall specify
   the assigned File Unit size for the File Section if the File Section
   is recorded in interleaved mode. Otherwise this number shall be zero.
   This field shall be recorded according to 7.1.1.
   9.1.8 Interleave Gap Size (BP 28)
   This field shall contain an 8-bit number. This number shall specify
   the assigned Interleave Gap size for the File Section if the File
   Section is recorded in interleaved mode. Otherwise this number shall
   be zero.
   This field shall be recorded according to 7.1.1."

"File Section" essentially means file data content.
"File Unit" is a chunk size with an obscure feature "Interleaved Mode"
of ECMA-119, 6.4.3.
Both unsigned 8-bit numbers are supposed to be 0.
Your kernel sees non-zero values, obviously.

The number given in the complaint
> [238413.898942] ISOFS: File unit size != 0 for ISO file (18642688).
is supposed to be the inode number, which is supposed to be
the byte address of the directory record divided by 32.
This means the directory record is located in block 291292,
probably at its very beginning. (The block address is plausible.
So Linux did not give up this inode numbering scheme up to now.)

What do you get from this ?

  dd if=/dev/sr0 bs=2048 skip=291292 | dd bs=286 count=1 | od -x
  
The record cannot be larger than 255 bytes and starts at latest
at byte 31 of block 291292. Thus it must be within the first 286
bytes.
(od -x shows little-endian 16-bit integers. Better would be a
 display of 8-bit values in hex.)


Have a nice day :)

Thomas