--- Comment #41 from Thomas Schmitt <> ---

the growisofs log is very sparse. Are you sure it burned the whole session ?
If i do
  dd if=/dev/zero bs=1M count=734 | growisofs -Z /dev/null=/dev/fd/0
i get at least a final message
  builtin_dd: 375808*2KB out @ average 555.9x1352KBps

As for the cdrskin run: It still operated on the CDEmu drive because
it got the address "/dev/sr1" and not a path to a (possibly not yet existing)
regular file prepended by "stdio:".

It is interesting to see that both cdrskin burn attempts fail at 71 MB with 
the same Linux-to-drive connection problem. But currently i have no idea
how to find out what goes wrong down there.

When cdrskin gets the failure reply from ioctl(SG_IO) it is just sending
data by SCSI commands WRITE10 and inquiring the drive buffer fill by
SCSI commands READ BUFFER CAPACITY. One can hardly do anything wrong in
this moment. It is up to the drive and Linux to negociate when data can
be transmitted to the drive and when Linux has to wait because the drive
buffer is full. The job of libburn is to keep the timespan small between
the end of a WRITE10 command and the start of the next one.

Have a nice day :)


You are receiving this mail because:
You are watching all bug changes.

Reply via email to