Date: Thu, 17 Jun 2010 10:42:14 -0400 From: Jerry McAllister <jerrymc@msu.edu> To: Mark Terribile <materribile@yahoo.com> Cc: Polytropon <freebsd@edvax.de>, freebsd-questions@freebsd.org Subject: Re: Burning CDs on FreeBSD 7.2 Message-ID: <20100617144214.GA26965@gizmo.acns.msu.edu> In-Reply-To: <195845.80526.qm@web110309.mail.gq1.yahoo.com> References: <20100617080121.699a9d7c.freebsd@edvax.de> <195845.80526.qm@web110309.mail.gq1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100617144214.GA26965>