well something is screwy, and it's related to the isofs or the cdrom
driver. I'm running 2.1.89 compiled with gcc 2.7.2.3, no extra
patches. I have this some old CDROM which is not mountable under
2.1.89, but which mounts nicely under 2.0.33. Other CDROMs mount
perfectly.
It seems that the magic number is slightly displaced, it's located in
offsets 10-14 of the block returned by bread instead of 2-6 where it's
supposed to be. A 8 byte displacement.
I have no idea how this happens, I would appreciate some suggestions
so I can debug this further. Next step would probably be going into
the generic cdrom driver.
This is what I did: In fs/isofs/inode.c at about line 295, right after
vdp = (struct iso_volume_descriptor *)bh->b_data;
hdp = (struct hs_volume_descriptor *)bh->b_data;
I put in this:
printk("vdp->id = '%c%c%c%c%c', hdp->id = '%c%c%c%c%c'\n",
vdp->id[0],vdp->id[1],vdp->id[2],vdp->id[3],vdp->id[4],
hdp->id[0],hdp->id[1],hdp->id[2],hdp->id[3],hdp->id[4]);
With this particular CD I get this output for the first three blocks
on the CD (it runs in a loop over the 84 first blocks on the cd to
find the magic number...):
vdp->id = '^@^@^@^@^@', hdp->id = 'CD001'
vdp->id = '^@^@^@^@^@', hdp->id = 'CD001'
vdp->id = '^@^@^@^@^@', hdp->id = '^@^@^@^@^@'
...
"CD001" should have been in vdp->id (ISO9660 superblock structure),
not hdp->id (high sierra superblock structure).
Under 2.0.33 the same debugging statement results in this:
vdp->id = 'CD001', hdp->id = 'INUX '
...
Which is what one expects, and so the first block is recognized as a
ISO9660 superblock:
Max size:10944 Log zone size:2048
First datazone:22 Root inode number 45056
ISO9660 Extensions: RRIP_1991A
...
So, any help? A block dump routine? Any other suggestions? I need
it.
Nicolai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu