From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 01:30:35 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DF2B16A4B3 for ; Fri, 3 Oct 2003 01:30:35 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47EC543F85 for ; Fri, 3 Oct 2003 01:30:34 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h938UH1g010625; Fri, 3 Oct 2003 10:30:18 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Dan Nelson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 02 Oct 2003 17:12:18 CDT." <20031002221218.GF2421@dan.emsphone.com> Date: Fri, 03 Oct 2003 10:30:17 +0200 Message-ID: <10624.1065169817@critter.freebsd.dk> cc: Sascha Holzleiter cc: current@freebsd.org Subject: Re: scsi-cd + GEOM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2003 08:30:35 -0000 In message <20031002221218.GF2421@dan.emsphone.com>, Dan Nelson writes: >> >> Seems like it does, if there is a disc present or the tray is open there >> is no delay only with tray closed and no disc inserted. >> Maybe this is only an issue with this drive model or at least my >> drive... > >No, it happens to me too. It looks like cd probing was done >asynchronously until about a week ago, so what used to happen was: I'm not a SCSI device specialist, and I'm somewhat surprised that drives should take that long to figure out if they have a media or not. Comparing to the DA driver, I can see that the CD driver does not even try to do a "TEST UNIT READY" before trying to find the size and that seems like an oversight to me. Can you try this patch ? You may get some weird console messages, but as far as I can tell they're not important. There may be a way to say to CAM "I do expect to get an error so don't whine", but I'm not sure how that is done. And yes, we need to seriously look at how removable devices work now that we have an infrastructure which truly supports this, but it is not high on my priority list. If somebody with SCSI & CAM clue wants to step in, contact me. Poul-Henning Index: scsi_cd.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.84 diff -u -r1.84 scsi_cd.c --- scsi_cd.c 30 Sep 2003 07:52:15 -0000 1.84 +++ scsi_cd.c 3 Oct 2003 08:14:36 -0000 @@ -2852,6 +2852,21 @@ ccb = cdgetccb(periph, /* priority */ 1); + scsi_test_unit_ready(&ccb->csio, 0, cddone, + MSG_SIMPLE_Q_TAG, SSD_FULL_SIZE, 1000); + ccb->ccb_h.ccb_bp = NULL; + error = cam_periph_runccb(ccb, NULL, + /*cam_flags*/0, + /*sense_flags*/SF_RETRY_UA, + softc->disk.d_devstat); + + if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { +printf("CD failed TUR\n"); + xpt_release_ccb(ccb); + return (ENXIO); + } +printf("CD passed TUR\n"); + rcap_buf = malloc(sizeof(struct scsi_read_capacity_data), M_TEMP, M_WAITOK); Index: scsi_da.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.159 diff -u -r1.159 scsi_da.c --- scsi_da.c 4 Sep 2003 01:01:20 -0000 1.159 +++ scsi_da.c 25 Sep 2003 21:49:24 -0000 @@ -367,6 +367,16 @@ {T_DIRECT, SIP_MEDIA_REMOVABLE, "JUNGSOFT", "NEXDISK*", "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE }, + { + /* + * PQI Travel Flash, rev 1.10/2.05, addr 2 + * General Flash Disk Drive 2.05 + * Serial Number ST92163-2000 + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive", + "*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, { /* * Creative Nomad MUVO mp3 player (USB) @@ -1683,13 +1693,34 @@ block_len = 0; maxsector = 0; error = 0; + rcap = NULL; + + ccb = cam_periph_getccb(periph, /*priority*/1); + + scsi_test_unit_ready(&ccb->csio, 0, dadone, + MSG_SIMPLE_Q_TAG, SSD_FULL_SIZE, 1000); + ccb->ccb_h.ccb_bp = NULL; + error = cam_periph_runccb(ccb, NULL, + /*cam_flags*/0, + /*sense_flags*/SF_RETRY_UA, + softc->disk.d_devstat); + + if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { + error = ENXIO; + goto done; + } + + if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) + cam_release_devq(ccb->ccb_h.path, + /*relsim_flags*/0, + /*reduction*/0, + /*timeout*/0, + /*getcount_only*/0); /* Do a read capacity */ rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcaplong), M_TEMP, M_WAITOK); - - ccb = cam_periph_getccb(periph, /*priority*/1); scsi_read_capacity(&ccb->csio, /*retries*/4, /*cbfncp*/dadone, @@ -1758,7 +1789,8 @@ xpt_release_ccb(ccb); - free(rcap, M_TEMP); + if (rcap != NULL) + free(rcap, M_TEMP); return (error); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.