Hi,
sorry for breaking this message thread. I was not subscribed
when i found it and so i have no Message Id to refer to.
I am only a casual user of CAM for DVD burning (once per release
cycle of libburn). But i can analyse some of the relation between
growisofs and the error messages.
> when a blank is inserted:
> Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status
Error
> Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check
Condition
> Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST
asc:64,0 (Illegal mode for this track)
> ...
> Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00
00
00 00 00 01 00
I doubt that his is caused by growisofs, which knows how to
recognize a blank DVD.
It is not overly smart to try reading from a blank medium.
Whatever process or driver did this, it should have checked
the reply of READ DISC INFORMATION for Disc Status first.
The reaction of the drive is plausible in this case.
Especially the caller was able to bring a READ command to
the drive and to get an answer. So there is, at least partly,
access to the drive.
> :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device.
The message with the frown comes from growisofs.c.
union ccb ccb;
...
ccb.ccb_h.func_code = XPT_GDEVLIST;
if (ioctl (in_fd,CAMGETPASSTHRU,&ccb) < 0)
There are also two occasions in transport.hxx.
All three are associated with function code XPT_GDEVLIST.
Both identifiers bring me to
http://www.unix.com/man-page/FreeBSD/4/pass/
If the call in growisofs.c had succeeded, then growisofs.c
would have used the result for
sprintf
(pass,"/dev/%.15s%u",ccb.cgdl.periph_name,ccb.cgdl.unit_number);
cam = cam_open_pass (pass,O_RDWR,NULL);
...
ioctl_handle = (void *)cam;
In transport.hxx, a private variable cam is set by a similar
gesture and later used to send SCSI commands:
if ((ret = cam_send_ccb(cam, &ccb)) < 0)
So i assume the failed ioctl is essential for growisofs to get
a connection to the drive.
--------------------------------------------------------------
My own software libburn does not use ioctl CAMGETPASSTHRU in
its FreeBSD adapter. It opens e.g. d->devname = "/dev/cd0" by:
cam = cam_open_device(d->devname, O_RDWR);
...
d->cam = cam;
and then sends SCSI commands via
err = cam_send_ccb(d->cam, ccb);
See also libburn/sg-freebsd.c of:
http://www.freshports.org/devel/libburn
(Ping: The stable release is 1.3.2 meanwhile, not 1.2.4.)
> /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z
/dev/cd0=/dev/fd/0' /u
The equivalent with program cdrskin out of the libburn port would be
... -P 'cdrskin -v dev=/dev/cd0 -eject -' ...
I am not sure whether growisofs does the auto-eject/auto-reload
dance on FreeBSD. One should eject after burning to force the
device drivers into forgetting their cached medium status.
If you want to keep DVD-R or DVD+R writable for further sessions,
then add option -multi (won't work with DVD+RW and alike).
--------------------------------------------------------------
> The actual program, cdrecord, works when invoked from the command line.
growisofs does not depend on cdrecord, but rather on mkisofs.
It does all its burning activities on its own. To my opinion,
it handles the various media types more properly than cdrecord.
--------------------------------------------------------------
About the "/dev/fd/0" discussion:
The growisofs command
growisofs -Z /dev/cd0=/dev/fd/0
surely pipes the standard input of growisofs into a burn run
on /dev/cd0.
The pseudo-path "/dev/fd/0" is not used with open(2) or alike,
but interpreted in growisofs.c main():
if (sscanf(in_image,"/dev/fd/%u",&imgfd)
== 1)
imgfd = dup (imgfd); /* validate descriptor */
I.e. growisofs uses "/dev/fd/" as keyword to obtain the number
of an open file descriptor. In this case: 0 = standard input.
--------------------------------------------------------------
Have a nice day :)
Thomas