From owner-freebsd-scsi Sun Jul 1 5: 9:13 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id AB75D37B405 for ; Sun, 1 Jul 2001 05:09:02 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from fokus.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA00450; Sun, 1 Jul 2001 14:08:49 +0200 (MET DST) Received: (from jes@localhost) by fokus.gmd.de (8.8.8+Sun/8.8.8) id OAA16717; Sun, 1 Jul 2001 14:08:18 +0200 (MET DST) Date: Sun, 1 Jul 2001 14:08:18 +0200 (MET DST) From: Joerg Schilling Message-Id: <200107011208.OAA16717@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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >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