From owner-freebsd-questions@FreeBSD.ORG Thu Jun 17 14:46:07 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C935A1065673 for ; Thu, 17 Jun 2010 14:46:07 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (gizmo.acns.msu.edu [35.8.1.43]) by mx1.freebsd.org (Postfix) with ESMTP id 74E3E8FC08 for ; Thu, 17 Jun 2010 14:46:07 +0000 (UTC) Received: from gizmo.acns.msu.edu (localhost [127.0.0.1]) by gizmo.acns.msu.edu (8.13.6/8.13.6) with ESMTP id o5HEgEGb026988; Thu, 17 Jun 2010 10:42:14 -0400 (EDT) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: (from jerrymc@localhost) by gizmo.acns.msu.edu (8.13.6/8.13.6/Submit) id o5HEgE2H026987; Thu, 17 Jun 2010 10:42:14 -0400 (EDT) (envelope-from jerrymc) Date: Thu, 17 Jun 2010 10:42:14 -0400 From: Jerry McAllister To: Mark Terribile Message-ID: <20100617144214.GA26965@gizmo.acns.msu.edu> References: <20100617080121.699a9d7c.freebsd@edvax.de> <195845.80526.qm@web110309.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <195845.80526.qm@web110309.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.2i Cc: Polytropon , freebsd-questions@freebsd.org Subject: Re: Burning CDs on FreeBSD 7.2 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 14:46:07 -0000 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" >