On Thu, Jun 17, 2010 at 07:24:46AM -0700, Mark Terribile wrote: > > Polytropon, > > > > 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. ////jerry > > > 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 > > > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"
