Date: Thu, 17 Jun 2010 08:01:21 +0200 From: Polytropon <freebsd@edvax.de> To: Mark Terribile <materribile@yahoo.com> Cc: freebsd-questions@freebsd.org Subject: Re: Burning CDs on FreeBSD 7.2 Message-ID: <20100617080121.699a9d7c.freebsd@edvax.de> In-Reply-To: <978150.69326.qm@web110311.mail.gq1.yahoo.com> References: <20100615223304.CB69610656ED@hub.freebsd.org> <978150.69326.qm@web110311.mail.gq1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jun 2010 03:03:02 -0700 (PDT), Mark Terribile <materribile@yahoo.com> wrote: > > Thanks to Jerrymc and Polyoptron. Things are working, sort of. > I'm using the atapicam/cdrecord solution. But when I do a dd > read to verify the write, the read ends on an I/O error rather > than an EOF. (I'm not sure that this problem is new.) There > is a very long delay between dd's report and the program end > (delay on close?) And sometimes the eject command after the > dd locks up and eventually fails. There are plenty of console > messages, including READ_BIG retrying, READ_BIG timed out, > TEST_UNIT_READY freeing zombie taskqueue request, and PREVENT_ALLOW > taskqueue timeout - compiing request directly . I start wondering if this may be due to a defective drive, or wrong cable, or even through DMA incompatibilites... Instead of using dd (have you made sure to use the correct block size?) try using readcd (comes with cdrecord); see "man cdrecord" for details and examples. > This is definitely NOT reliable enough to put into a script > (which would make handling the many file names more reliable). True. > cdrecord reports > ----------------------------------- > scsidev: '4,0,0' > scsibus: 4 target: 0 lun: 0 > SCSI buffer size: 64512 > Track 01: Total bytes read/written: 103874560/103874560 (50720 sectors). > Writing time: 41.290s > Average write speed 20.8x. Try to force a lower value, maybe drive and discs are not compatible. With -speed 8 it should be "slow enough" and "fast enough" for a test. You can use -prcap to find out what the drive tells cdrecord about itself. > I would be grateful for any clues about what is still wrong here. I'd slowly expect a defective drive... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100617080121.699a9d7c.freebsd>