Date: Sun, 01 Sep 2013 10:47:52 -0400 From: "Thomas Laus" <lausts@acm.org> To: freebsd-stable@freebsd.org Subject: Lost CAM Access to DVD Writer - Maybe ATA Related Message-ID: <52235398.5531.1DE273@lausts.acm.org>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52235398.5531.1DE273>