Date: Thu, 28 Nov 2002 17:47:59 +0100 From: Dan Lukes <dan@obluda.cz> To: freebsd-stable@freebsd.org Subject: Re: Mounting a mixed-mode CD Message-ID: <3DE648BF.50007@obluda.cz> In-Reply-To: <1038378879.10876.4.camel@chowder.gsoft.com.au> References: <1038378879.10876.4.camel@chowder.gsoft.com.au> <20021127090013.GA58575@falcon.net.informatik.tu-muench> <1038388486.10876.45.camel@chowder.gsoft.com.au> <3DE515A6.4070403@obluda.cz> <1038450371.19350.36.camel@chowder.gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor wrote, On 11/28/02 03:26:
> See other emails about this where if I use atapicam and mount the device
> through cd0c it Just Works (tm), so I guess it is a shortcoming in the
> acd driver..?
Yes, it seems to be.
> [chowder 12:50] ~ >dd if=/dev/acd0c of=cd.bin bs=2048 count=84
> skip=306588
> dd: /dev/acd0c: Invalid argument
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000318 secs (0 bytes/sec)
>
> Mmm, curious.
Can you try
dd if=/dev/acd0c of=cd.bin bs=2352 count=1 skip=306588
instead ?
> However..
> [chowder 12:52] ~ >dd if=/dev/acd0t17 of=cd.bin bs=2048 count=84
> 84+0 records in
> 84+0 records out
> 172032 bytes transferred in 0.156220 secs (1101217 bytes/sec)
> [chowder 12:52] ~ >hexdump -C cd.bin | less
> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> *
> 00008000 01 43 44 30 30 31 01 00 20 20 20 20 20 20 20 20 |.CD001..
> |
> 00008010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |
> |
> 00008020 20 20 20 20 20 20 20 20 32 30 30 32 5f 31 30 5f |
> 2002_10_|
> 00008030 32 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |27
> |
>
> Hmmm...
>
> Maybe it's blowing up because it looks at the first track and sees data,
> so the block size it uses to check things with is 2352, and when the
> mount code tries to read the disk it wants to use 2048.
It seems to be hit.
The fragment of code from atapi_cd.c:ata_start:
-------------
if (track) {
blocksize = (cdp->toc.tab[track - 1].control & 4) ? 2048 : 2352;
lastlba = ntohl(cdp->toc.tab[track].addr.lba);
if (bp->b_flags & B_PHYS)
lba = bp->b_offset / blocksize;
else
lba = bp->b_blkno / (blocksize / DEV_BSIZE);
lba += ntohl(cdp->toc.tab[track - 1].addr.lba);
}
else {
blocksize = cdp->block_size;
lastlba = cdp->disk_size;
if (bp->b_flags & B_PHYS)
lba = bp->b_offset / blocksize;
else
lba = bp->b_blkno / (blocksize / DEV_BSIZE);
}
--------------
The actual "blocksize" is initialised to 2048 or 2352 according to type
of requested track, or to "general CD blocksize" when no specific track
requested.
The "general CD blocksize" is initialised during acd_toc_read according
to type of first track.
The SCSI cd code use other strategy - the "general CD blocksize" is
2048 despite of type of any track.
A thing it is the way the ATAPI code should do it also. It wouldn't
break the feature "read audio track as data" (it feature isn't present
in SCSI CD code) because when we reading an specific (audio) track - we
open the specific track via acd*t* device, so blocksize is set according
it's type. The only think it broke is you can't read first audio track
using generic /dev/acd0c anymore, but it sems to be acceptable price. I
thing the following patch may help you - but I can't try it now, so I
don't know if it doesn't break an other things.
If you can, try it. If it work, send PR.
*** atapi-cd.c.ORIG Wed Nov 27 04:10:50 2002
--- atapi-cd.c Thu Nov 28 16:42:39 2002
***************
*** 1290,1296 ****
}
cdp->toc.hdr.len = ntohs(cdp->toc.hdr.len);
! cdp->block_size = (cdp->toc.tab[0].control & 4) ? 2048 : 2352;
acd_set_ioparm(cdp);
bzero(ccb, sizeof(ccb));
ccb[0] = ATAPI_READ_CAPACITY;
--- 1290,1296 ----
}
cdp->toc.hdr.len = ntohs(cdp->toc.hdr.len);
! cdp->block_size = 2048;
acd_set_ioparm(cdp);
bzero(ccb, sizeof(ccb));
ccb[0] = ATAPI_READ_CAPACITY;
> Although, in that case I would expect mounting acd0t17 would work, but
> it doesn't.
No, it shouldn't work, IMHO. Unless I'm confused, the ISO refered to
files using absolute adressing from start of CD (e.g. not relative to
current data track). But accesing /dev/acd0t17 device set logical offset
0 to physical sector where track 17 starts - so absolute adressing
points to random places.
Dan
--
Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206
root of FIONet, KolejNET, webmaster of www.freebsd.cz
AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE648BF.50007>