Date: Sat, 30 Jun 2001 22:01:11 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Stephen McKay <mckay@thehub.com.au> Cc: freebsd-scsi@FreeBSD.ORG, schilling@fokus.gmd.de Subject: Re: Problems reading burned CDs Message-ID: <20010630220111.A21825@panzer.kdm.org> In-Reply-To: <200106281225.f5SCPJY13905@dungeon.home>; from mckay@thehub.com.au on Thu, Jun 28, 2001 at 10:25:18PM %2B1000 References: <200106281225.f5SCPJY13905@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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. > > If I read pressed CDs they all seem to end with a very long run of blocks > of zeroes. No problem if I try to read a large block straddling the > logical end of disk. > > But burned CDs appear to end suddenly, and a read request straddling the > end of data will fail, and the partial contents will not be returned. > > 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 > is a 60 second lag between reading the last sector and actually reporting > the error (for retries, I presume). The 60 second delay explains the > abysmal read speed, so don't panic about that. > > Checking on my burner, the error logged is "Illegal mode for this track" > which causes no extra delay. But it still truncates the last block, > losing data. > > My IDE cdrom does not log any sort of error, nor suffer an end-of-media > delay, but it gets the size wrong by one sector. I'm told this has been > fixed in -stable, but I've not checked. Anyway, this indicates to me > that this is a SCSI CD problem, not a general CD problem. > > Is there any way around these problems with SCSI CD drives? 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. 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. In cd1 (Toshiba DVD-ROM), I have a pressed CD. In cd0 (Plextor CD-RW) I have a data CD-RW burned using cdrecord: First, a read capacity on cd1 (the pressed CD): # camcontrol cmd cd1 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 14032 2048 So the address of the last LBA is 14032. Now, we attempt to read that particular block from the drive: # camcontrol cmd cd1 -v -c "28 0 v:i4 0 v:i2 0" 14032 1 -i 2048 - > /dev/null Worked fine, no errors. 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 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 Hmm, looks like we can't read the LBA the drive claims is the last one on the CD. Let's try the previous LBA: # camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297517 1 -i 2048 - > /dev/null camcontrol: error sending command (pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2d 0 0 1 0 (pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2d asc:6,0 (pass2:ahc1:0:4:0): No reference position found 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. 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) 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 scsidev: '1,4,0' scsibus: 1 target: 4 lun: 0 Using libscg version 'schily-0.1' Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'PLEXTOR ' Identifikation : 'CD-R PX-W1210S' Revision : '1.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO first: 1 last 1 track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 track:lout lba: 297519 ( 1190076) 66:08:69 adr: 1 control: 4 mode: -1 This is the Toshiba DVD-ROM with the pressed CD in it: # cdrecord dev=1,5,0 -toc Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling scsidev: '1,5,0' scsibus: 1 target: 5 lun: 0 Using libscg version 'schily-0.1' Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'TOSHIBA ' Identifikation : 'DVD-ROM SD-M1401' Revision : '1007' Device seems to be: Generic mmc CD-ROM. Using generic SCSI-3/mmc CD driver (mmc_cd). Driver flags : SWABAUDIO first: 1 last 1 track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 track:lout lba: 14033 ( 56132) 03:09:08 adr: 1 control: 4 mode: -1 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. Ken -- Kenneth Merry ken@kdm.org 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?20010630220111.A21825>