[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dead CD-R burn...
On Thu, 3 Sep 1998, Yaniv Kimchi wrote:
> > -----Original Message-----
> > From: Yaniv Kimchi <yaniv@zvia.org.il>
> > To: Ze'ev Maor <gmaor@techunix.technion.ac.il>
> > Cc: linux ILUG <linux-il@cs.huji.ac.il>; ILUG Mailing List
> > <linux-il@linux.org.il>
> > Date: יום חמישי 03 ספטמבר 1998 07:41
> > Subject: Re: Dead CD-R burn...
--snip--
> > >> Here's what I did, maybe someone can help:
--snip--
> > >> I'm using the HP-SureSture7100e, I've compiled paride+epat+pg as
> > >> modules, loaded them, and the pg driver successfuly identified my
> > >> CD-R. I've patched 'cdrecorder' with the scsi-linux-pg.c support and
--snip--
> > >> mkisofs -r /cdrom | cdrecord -v -multi fs=15m speed=2 dev=0 -
--snip--
> > >> the process started and seemed to work fine...following are the last log
> > >> lines of the burning:
> > >>
> > >> 87.68% done, estimate finish Thu Sep 3 04:16:01 1998
> > >> 92.05% done, estimate finish Thu Sep 3 04:16:03 1998
> > >> 96.44% done, estimate finish Thu Sep 3 04:16:04 1998
> > >> Total extents actually written = 114066
> > >> Total translation table size: 0
> > >> Total rockridge attributes bytes: 1325
> > >> Total directory bytes: 4096
> > >> Path table size(bytes): 44
> > >> Max brk space used 4000
> > >> 114066 extents written (222 Mb)
> > >> Track 01: 222 MB written (fifo 100%).
> > >> Track 01: Total bytes read/written: 233607168/233607168
> > >> (114066 sectors).
> > >> Writing time: 771.631s
> > >> Fixating...
> > >> Fixating time: 137.099s
> > >> cdrecord: fifo had 7131 puts and 7131 gets.
> > >> cdrecord: fifo was 0 times empty and 6618 times full, min fill was
> > >> 95%.
As far as I know a correctly operating fifo is NEVER empty and NEVER full.
Your log says it was full a couple of times. Usually there is a high
water mark and a low water mark and the top and the bottom are never
reached. Compare this data with data from others who use the same command.
It is possible that a bug causes the fifo to miss some data when
re-filling after it was full. The bug may be anywhere, including in your
particular version of Linux. Check with others on uname -a and versions
(including libc/glibc).
> > >> I've also tried creating small images with 'mkisofs' and burning them,
> > >> but the result was the same.
Did you try to mount that image on the loop device ? Did it work ?
Your last resort could be to take the writer (external) and a hard disk to
another computer and try it there. There are certain things that keep
going wrong with parallel ports for everyone who does serious things with
them (such as EPROM programmers... hint, hint).
just my 2 bits,
Peter
PS: Check the BIOS setting for the parallel port (EPP...). Having this on
'AUTO' is a bad idea with Linux.