> 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.
>
This error concerning a blank disk in the drive on the system console is long
standing and I have been ignoring it for a while. It is a 'red herring'
on
this problem. Thank you for this information, it gives me a little more
information.
>> :-( 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.>
I think that this is the root cause of my problem. That is why I am starting
another thread on this topic. I don't have this problem using the dump
utility on my laptop running FreeBSD 9.2-RC3 like I have on the other
computers. The only difference is that the laptop uses AHCI and all of my
other computers use ATA. I had an old drive on the shelf that still had
FreeBSD 9.1 STABLE from last Winter that I was going to install to see if my
problem existed before FreeBSD 9.2 tag was released. That drive sat too long
and won't spin up.
Could someone else try to make a 'dump to DVD' backup using the example
at
the bottom of the DUMP (8) man page to confirm that it works or doesn't for
them?
/sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0'
/u
I will enter a PR if my results are duplicated. It doesn't work for me on 3
ATA based computers using new drives and media. It DOES work on one AHCI
based computer.
Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF