On Wed, 16 Jun 2010 03:03:02 -0700 (PDT), Mark Terribile <materrib...@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, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"