Burning CDs on FreeBSD 7.2
jerrymc at msu.edu
Thu Jun 17 14:46:07 UTC 2010
On Thu, Jun 17, 2010 at 07:24:46AM -0700, Mark Terribile wrote:
> > > 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 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...
> I tried taking the drive out of the 5.4 machine. No difference.
> Also, the ATAPICAM subsystem gets into a state where the eject
> program will report "drive busy" but cdrecord can still operate
> the drive. I think that in doing whatever was needed to
> accomodate DVDs, the subsystem was broken. It looks like cdrecord
> manages to work around it.
Well, the drive will be busy if any process/shell is cd-ed to any
directory on the device or any process/shell has any file on
the device open, no matter what is being done to it. Probably
you already know that, but it makes your statement above easily
a not-surprising situation.
> > 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.
> I'll try it. I am using the correct block size, and the data
> retrieved cmp's correctly against the iso fs image used to
> create the disk. dd was means for exactly such purposes, and if
> it can't work, the OS is doing a bad job.
> > > This is definitely NOT reliable enough to put into a
> > script
> > > (which would make handling the many file names more
> > reliable).
> Under 5.4 I did this by script routinely.
> Question is, under which category do I report this?
> Mark Terribile
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions