On Mon, Dec 25, 2006 at 05:12:04PM +0200, Dmitry Pryanishnikov wrote:
> 
> Hello!
> 
> On Fri, 22 Dec 2006, Sergey N. Voronkov wrote:
> >> just noticed, after upgrading to 6.2RC1, that
> >>
> >>    luigi# burncd -f /dev/acd0 -v blank
> >>    blanking CD, please wait..
> >>
> >> stays there forever. Eventually i gave up and ctrl-C and
> >> the application terminates, and i was able to write to
> >> the disk a valid image, which probably means that the
> >> disk had been blanked.
> 
>    Yes, well known RELENG_4 -> 6 (maybe even 5) regression. Same here with
> 
> acd0: CDRW <CD-W540E/1.0C> at ata1-master UDMA33
> 
> Worked fine under RELENG_4, fails to wait for completion under RELENG_6.

indeed, the two routines are different: in RELENG_4

    static int
    acd_get_progress(struct acd_softc *cdp, int *finished)
    {
        int8_t ccb[16] = { ATAPI_READ_CAPACITY, 0, 0, 0, 0, 0, 0, 0,  
                           0, 0, 0, 0, 0, 0, 0, 0 };
        struct atapi_reqsense *sense = cdp->device->result;
        char tmp[8];

        if (atapi_test_ready(cdp->device) != EBUSY) {
            if (atapi_queue_cmd(cdp->device, ccb, tmp, sizeof(tmp),
                                ATPR_F_READ, 30, NULL, NULL) != EBUSY) {
                *finished = 100;
                return 0;
            }
        }
        if (sense->sksv)
            *finished = 
                ((sense->sk_specific2 | (sense->sk_specific1 << 8)) * 100) / 
65535;
        else
            *finished = 0;
        return 0;
    }

in RELENG_6

    static int
    acd_get_progress(device_t dev, int *finished)
    {
        int8_t ccb[16] = { ATAPI_READ_CAPACITY, 0, 0, 0, 0, 0, 0, 0,
                           0, 0, 0, 0, 0, 0, 0, 0 };
        struct ata_request *request;
        int8_t dummy[8];

        if (!(request = ata_alloc_request()))
            return ENOMEM;

        request->dev = dev;
        bcopy(ccb, request->u.atapi.ccb, 16);
        request->data = dummy;
        request->bytecount = sizeof(dummy);
        request->transfersize = min(request->bytecount, 65534);
        request->flags = ATA_R_ATAPI | ATA_R_READ;
        request->timeout = 30;
        ata_queue_request(request);
        if (!request->error && request->u.atapi.sense.error & ATA_SENSE_VALID)
            *finished = ((request->u.atapi.sense.specific2 |
                         (request->u.atapi.sense.specific1 << 8)) * 100) / 
65535;
        else
            *finished = 0;
        ata_free_request(request);
        return 0;
    }

and the wait routine in usr.sbin/burncd/burncd.c is the following:
in RELENG_4:

            while (1) {
                    sleep(1);
                    error = ioctl(fd, CDRIOCGETPROGRESS, &percent);
                    if (percent > 0 && !quiet)
                            fprintf(stderr, 
                                    "%sing CD - %d %% done     \r",
                                    blank == CDR_B_ALL ? 
                                    "eras" : "blank", percent);
                    if (error || percent == 100)
                            break;
            }

in RELENG_6:

            while (1) {
                    sleep(1);
                    if (ioctl(fd, CDRIOCGETPROGRESS, &pct) == -1)
                            err(EX_IOERR,"ioctl(CDRIOGETPROGRESS)");
                    if (pct > 0 && !quiet)   
                            fprintf(stderr,
                                    "%sing CD - %d %% done     \r",
                                    blank == CDR_B_ALL ?
                                    "eras" : "blank", pct);
                    if (pct == 100 || (pct == 0 && last > 90))
                            break;
                    last = pct;
            }

i think you could try experimenting with the return values of
your drive (with the patched atapi-cd.c)
in order to find a good way to detect completion of
the blank operation

        cheers
        luigi
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to