Lost CAM Access to DVD Writer - Maybe ATA Related

[Thomas Laus]

> 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