Date: Sun, 1 Jul 2001 18:09:47 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Joerg Schilling <schilling@fokus.gmd.de> Cc: mckay@thehub.com.au, freebsd-scsi@freebsd.org Subject: Re: Problems reading burned CDs Message-ID: <20010701180947.A26662@panzer.kdm.org> In-Reply-To: <200107011208.OAA16717@fokus.gmd.de>; from schilling@fokus.gmd.de on Sun, Jul 01, 2001 at 02:08:18PM %2B0200 References: <200107011208.OAA16717@fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 01, 2001 at 14:08:18 +0200, Joerg Schilling wrote: > >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: > >> # 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.... That would be nice. Soren does what he wants to, though, so we have separate ATA and SCSI subsystems for now. > >> Is there any way around these problems with SCSI CD drives? > > Read README.verify & README.copy for a long answer.... Ahh, that does explain some things. > >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. Ahh, I see. Is there any way to detect a TAO 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. Well, it's good to know it isn't a bug. :) > >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... Nope, that's the expected behavior. We give the user the option of turning on error recovery, and I didn't use error recovery. If the user turns on error recovery, and specifies enough retries, he won't see any unit attention conditions. > >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. The driver sent a bus device reset because the default timeout of 5 seconds wasn't long enough for the command to complete. > >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. FreeBSD won't read past the specified end of media (as reported by the read capacity command), and shouldn't have any trouble reading files on the CD, since any file won't encompass the last two blocks on a TAO CD. > >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..... It works well enough, although I should upgrade. :) > >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. Thanks for the explanation. I didn't know about the run-out blocks. 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?20010701180947.A26662>