From owner-freebsd-scsi Thu Feb 6 17:45:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA21852 for freebsd-scsi-outgoing; Thu, 6 Feb 1997 17:45:14 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21826 for ; Thu, 6 Feb 1997 17:45:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id RAA19592 for ; Thu, 6 Feb 1997 17:21:04 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id CAA14570; Fri, 7 Feb 1997 02:20:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id CAA13445; Fri, 7 Feb 1997 02:06:55 +0100 (MET) Message-ID: Date: Fri, 7 Feb 1997 02:06:55 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: amor@geop.ubc.ca (John Amor) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: HP6020i CDR fails on fixation References: <199702061921.LAA01863@moho.ubc.ca> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702061921.LAA01863@moho.ubc.ca>; from John Amor on Feb 6, 1997 11:21:48 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John Amor wrote: > I have burned a successfull CD! I moved the CDR down in the box to give > it more cooling it was right under an IDE cdrom. I guess the added air > flow may have made the difference?? Glad to hear. Btw., my today's commit should also cleanup the hassles in the wormclose() code some people used to have. > Is the burning of the fixation as time dependent? Last time I ran the > commands by hand, this time I used the script. All the ioctl's are not time-critical. Time-critical actions are deferred until they actually could be done, and are in tight sequence. The only time-critical operation apart from the successive calls to write(2) itself is to send a SYNCHRONIZE CACHE in time once the write data stream is supposed to be finished. Therefore, this is done from inside wormclose(), so you only need to care to close the device in time after doing all the writes. I figured this was a simple and natural condition. You could also burn multiple tracks before fixating. The fixation only recalculates and writes the new TOC for this session. If you spcifiy the flag (``open next program area''), you can write further sessions later, although that's of little use by now. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)