Date: Sun, 1 Jul 2001 14:08:18 +0200 (MET DST) From: Joerg Schilling <schilling@fokus.gmd.de> To: ken@kdm.org, mckay@thehub.com.au Cc: freebsd-scsi@freebsd.org, schilling@fokus.gmd.de Subject: Re: Problems reading burned CDs Message-ID: <200107011208.OAA16717@fokus.gmd.de>
next in thread | raw e-mail | index | archive | help
>From ken@panzer.kdm.org Sun Jul 1 06:01:32 2001
>[ CCing Joerg Schilling, since he might have a clue about what's going on
>here. Joerg: look down at the bottom of this message for the question
>addressed to you. The rest of this is primarily background information. ]
>On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote:
>> Some months ago I made vague assertions that one must use a 2 kilobyte
>> block size when reading raw CD data, or risk missing the last part of
>> the CD. Then I couldn't reproduce it, so blamed some mystery past version
>> of FreeBSD.
>>
>> Actually, the difference is pressed vs burned CDs.
...
>> Here is an example from reading a (short) burned CD on a Toshiba
>> XM-5701 SCSI CD-ROM, on a 4.3-R system:
>>
>> # dd if=/dev/cd1c of=/dev/null bs=2k
>> dd: /dev/cd1c: Input/output error
>> 8367+0 records in
>> 8367+0 records out
>> 17135616 bytes transferred in 88.964899 secs (192611 bytes/sec)
>>
>> # dd if=/dev/cd1c of=/dev/null bs=4k
>> dd: /dev/cd1c: Input/output error
>> 4183+0 records in
>> 4183+0 records out
>> 17133568 bytes transferred in 88.895442 secs (192738 bytes/sec)
>>
>> Also, the system logs "Random positioning error" scsi errors, and there
It is really a bad idea to use dd to read a CD.
To read a CD use 'readcd'.
Unfortunately this does not work for ATAPI on FreeBSD. Another reason to see why
uniform SCSI suport is needed....
>> Is there any way around these problems with SCSI CD drives?
Read README.verify & README.copy for a long answer....
>Just out of curiosity, what did you use to burn the CD? cdrecord?
>I spent some time looking into this, and got some interesting results. In
>short, I can reproduce your results with a burned CD versus a pressed CD.
There is no difference between a burned and a pressed CD.
There _is_ a difference between a TAO and a DAO CD.
>The results are the same for both a Plextor CD-RW and a Toshiba DVD-ROM in
>my machine, so I don't think it's a CDROM firmware issue.
>It looks like the problem is a capacity reporting problem, possibly due to
>the way the burned CD was burned.
There is no capacity reporting problem, the capacity is reported as documented
in the CD standards.
>Now we do a read capacity on cd0 (the burned CD-RW):
># camcontrol cmd cd0 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4"
>297518 2048
>So the last address is 297518. We attempt to read that block:
># camcontrol cmd cd0 -v -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>CAM status is 0xb
>Looks like we got a command timeout. (That's what 0xb means. Under
>FreeBSD-current, camcontrol prints out more descriptive messages for
>non-SCSI errors.)
>So let's bump the timeout up to 120 seconds and try to read the same block
>again:
># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0
>(pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0
>(pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred
This makes me believe that you have a bug in the SCSI Transport in the kernel...
>Oh yeah, the BDR sent in response to the timeout will cause a unit
>attention condition. Let's try it again:
># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0
>(pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2e asc:11,5
>(pass2:ahc1:0:4:0): L-EC uncorrectable error
This one or 'illegal mode for this track' is a correct repspose.
You should check why the drivr send a bus reset to the drive without reason.
>Hmm, looks like we can't read the LBA the drive claims is the last one on
>the CD.
>Still can't read that one. Let's try decrementing the LBA again:
># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297516 1 -i 2048 - > /dev/null
>That works fine.
As documented in several standards an in README.copy & README.verify
>So it looks like the CD may have a bogus table of contents on it, since it
>doesn't seem to describe the range of valid data on the disk. The table of
>contents on the drives seems to agree with the read capacity data: (that's
>probably where the drive gets the data in the first place)
The TOC is OK, many OS don't deal correctly with the run-out blocks.
While it is OK for dd to abort, it is not OK when the filesystem does read-ahead
bejond the FS size as noted in the PVD and then believes that the last blocks
(including parts of the last file) are un-readable.
>This is the Plextor CD-RW with the burned CD-RW in it:
># cdrecord dev=1,4,0 -toc
>Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
A really old one.....
>So now the question for Joerg -- do you know of any difference between
>burned CDs and "pressed" CDs (i.e. CDs produced commercially) that would
>account for the reported capacity of the burned CDs apparantly being a
>couple of blocks longer than the actual amount of data that can be read?
>Or could it possibly be a bug in mkisofs or cdrecord that's causing the TOC
>to get written improperly? (I don't know which application writes the TOC,
>or whether the drive is actually doing it.)
>Anyway, I don't have a ready answer for this one. Hopefully Joerg can shed
>some light on the problem.
If you write in TAO, you get 2 run-out blocks (16 ??? on early Yamaha)
that are part of the TOC.
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107011208.OAA16717>