Date: Mon, 2 Jul 2001 21:47:47 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: schilling@fokus.gmd.de Cc: freebsd-scsi@freebsd.org, mckay@thehub.com.au Subject: Re: Problems reading burned CDs Message-ID: <20010702214746.A34195@panzer.kdm.org> In-Reply-To: <200107021341.PAA16435@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Mon, Jul 02, 2001 at 03:41:40PM %2B0200 References: <200107021341.PAA16435@burner.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 02, 2001 at 15:41:40 +0200, schilling@fokus.gmd.de wrote: > >From ken@panzer.kdm.org Mon Jul 2 02:09:50 2001 > > >> 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. > > The more features cdrecord gives you the more sense is in having a unique > interface. > > The latest cdrecord e.g. introduces RAW writing which is thew only way > of doing DAO on Philips drives. Note that Philips OEM drives are dominating > the drive market now. > > Also 99 minutes CD may only be written in RAW mode as firmware does not > handle anything > 79 minutes as you expect. I'm not the one you have to sell on the idea. :) > >> 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? > > If you have a MMC writer, you could send a read disk info and check the disk status. > In general it does not work :-( > So you could say that in general you cannot distinguish a CD with bad sectors > from one written on TAO. Ahh, okay. So I suppose the solution is just to leave it as-is, and missing a few blocks at the end is expected behavior for TAO. > >> 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. :) > > It definitely _is_ a bug. > > There is no reason why a host should send a SCSI bus device reset except when > the drive does not respond to a unit reset and even that is not necessary in out case. We're talking about two different things here. I was talking about capacity reporting for TAO CDs. It looks like you're talking about sending a BDR versus a logical unit reset when a device doesn't respond. My guess is that the ahc driver (aic7xxx) sends a BDR since most devices understand that. A logical unit reset is a post SCSI-2 development I believe. > >> >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 you connect one storage unit to more than one computer for availability, > bad things may happen if you send SCSI bus resets without rerason. > Even when you only have a local SCSI bus but a tape drive it will rewind! > > Sending SCSI bus resets is the quick and dirty way SCSI drivers on UNIX have been > in the mid 80's. This time has gone.... The driver didn't send a bus reset, but rather a bus *device* reset. That shouldn't hose up other devices on the bus. > >The driver sent a bus device reset because the default timeout of 5 > >seconds wasn't long enough for the command to complete. > > 5 seconds is definitely too short. > > Anything < 20 seconds makes no sense. The 5 second timeout is just a default timeout for a generic SCSI command facility, not the timeout for a particular command. camcontrol(8) doesn't look at the command the user is attempting to send and then have some default timeout for it. That would be too cumbersome. Instead, if the user is composing his own CDB (as opposed to using a predefined camcontrol operation, like 'camcontrol format'), he is expected to also know what sort of timeout he should set. In this case I didn't set the timeout, and the 5 second default was too short. > >> 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. > > So did you tests with a TAO ISO-9660 CD where the last file's last block is in the > first fraction of a FS buffer block and the rest would take the run-out sectors? Nope, I didn't test it. FreeBSD doesn't chunk things into arbitrary block sizes inside the kernel like Linux. The FreeBSD ISO9660 filesystem code operates with the blocksize reported by the underlying device. (i.e. 2K) > >> ># 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. :) > > If you have a drive that does not support SAO, you would like to use RAW writing. Ahh. 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?20010702214746.A34195>