[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Subject: Re: Question about SCSI IMMED flag in cdrecord!



<snip>

Greg took time out to write!

> I think what the cdrecord info means is do not put a hard drive &
> Cd/burner on the same cable. In some notebooks there are only on IDE
> controller so this happens, though I haven't actually seen a noebook
> configure this way. AFAIk having a cd reader & cd-recorder on the > 
> same
> bus and copying from one & burning to the other can cause the issue 
> you
> mention. If this is the case, DMA  or scsi emulation need to be  
used.
> --
> Greg Madden
> Debian GNU/Linux

When I set up my system I have a cdrw, and a dvdrom on the same 
channel.  Then I have my harddrives on another channel.  When I was 
burning the ISO it was from my harddrive to my cdrw drive, also it 
only locks up at the end of the burn when fixating.

Also it leaves the question why does it not lock up in cdrdao?  
Not to mention that is why I thought drives had buffers, to protect 
from data error, when the drive receives too much data.  When I use 
driveropts=burnfree, at the end after it finishes, when using the 
-immed flag it gives me that burnfree was not used.

I thought that in order to use cdrdao, or cdrecord you had to have 
scsi emulation enabled.  Maybe it was my fault because I didn't 
specify what devices I had, maybe you thought I had real scsi 
devices.  

Since this happens when fixating at the end of a burn, it seems that 
cdrecord could use a better method to finalize a disk.  To me it 
looks like a problem with the code of cdrecord, since other programs, 
ie cdrdao, do not have this problem.  It seems to be a case where a 
software problem is blamed on the hardware.  I wonder how many bug 
reports where filled out before they came out with the -immed flag?  

Since the Man page states that it might not work even if someone uses 
the -immed flag.  Does not figure verywell in my book, I understand 
that this program is one of the corner stone applications of linux, 
but maybe we need to question some of these programs to make sure 
they become even better.

Thanks;

Rthoreau



Reply to: