From owner-freebsd-scsi Sun Jun 24 11:46:12 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 8453337B401; Sun, 24 Jun 2001 11:46:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5OIk7g82070; Sun, 24 Jun 2001 11:46:07 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sun, 24 Jun 2001 11:46:06 -0700 (PDT) From: Matthew Jacob Reply-To: To: Cc: Subject: scsi_low changes for CAM_NEW_TRAN_CODE Message-ID: <20010624114453.L627-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can't test, but these do compile. Let me know if you can commit them soon. Index: scsi_low.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_low.c,v retrieving revision 1.9 diff -u -r1.9 scsi_low.c --- scsi_low.c 2001/06/15 00:07:27 1.9 +++ scsi_low.c 2001/06/24 18:44:14 @@ -700,6 +700,41 @@ while ((li = LIST_NEXT(li, lun_chain)) != NULL) if (li->li_lun == lun) break; +#ifdef CAM_NEW_TRAN_CODE + if (li != NULL && cts->type == CTS_TYPE_CURRENT_SETTINGS) { + struct ccb_trans_settings_scsi *scsi = + &cts->proto_specific.scsi; + struct ccb_trans_settings_spi *spi = + &cts->xport_specific.spi; + cts->protocol = PROTO_SCSI; + cts->protocol_version = SCSI_REV_2; + cts->transport = XPORT_SPI; + cts->transport_version = 2; + + scsi->flags &= ~CTS_SCSI_FLAGS_TAG_ENB; + spi->flags &= ~CTS_SPI_FLAGS_DISC_ENB; + + if (li->li_cfgflags & SCSI_LOW_DISC) + spi->flags |= CTS_SPI_FLAGS_DISC_ENB; + if (li->li_cfgflags & SCSI_LOW_QTAG) + scsi->flags |= CTS_SCSI_FLAGS_TAG_ENB; + + spi->sync_period = ti->ti_maxsynch.period; + spi->valid |= CTS_SPI_VALID_SYNC_RATE; + spi->sync_offset = ti->ti_maxsynch.offset; + spi->valid |= CTS_SPI_VALID_SYNC_OFFSET; + + spi->valid |= CTS_SPI_VALID_BUS_WIDTH; + spi->bus_width = MSG_EXT_WDTR_BUS_8_BIT; + + if (cts->ccb_h.target_lun != CAM_LUN_WILDCARD) { + scsi->valid = CTS_SCSI_VALID_TQ; + spi->valid |= CTS_SPI_VALID_DISC; + } else + scsi->valid = 0; + } else + ccb->ccb_h.status = CAM_FUNC_NOTAVAIL; +#else if (li != NULL && (cts->flags & CCB_TRANS_USER_SETTINGS) != 0) { if (li->li_cfgflags & SCSI_LOW_DISC) cts->flags = CCB_TRANS_DISC_ENB; @@ -720,6 +755,7 @@ ccb->ccb_h.status = CAM_REQ_CMP; } else ccb->ccb_h.status = CAM_FUNC_NOTAVAIL; +#endif splx(s); xpt_done(ccb); @@ -774,6 +810,12 @@ cpi->initiator_id = 7; /* HOST_SCSI_ID */ cpi->bus_id = cam_sim_bus(sim); cpi->base_transfer_speed = 3300; +#ifdef CAM_NEW_TRAN_CODE + cpi->transport = XPORT_SPI; + cpi->transport_version = 2; + cpi->protocol = PROTO_SCSI; + cpi->protocol_version = SCSI_REV_2; +#endif strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); strncpy(cpi->hba_vid, "SCSI_LOW", HBA_IDLEN); strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 24 19: 6: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id D2C0C37B401 for ; Sun, 24 Jun 2001 19:05:53 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5P25og82727; Sun, 24 Jun 2001 19:05:50 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sun, 24 Jun 2001 19:05:50 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: scsi@freebsd.org Subject: BusLogic patches for NEW_TRAN_CODE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Index: bt.c =================================================================== RCS file: /home/ncvs/src/sys/dev/buslogic/bt.c,v retrieving revision 1.30 diff -u -r1.30 bt.c --- bt.c 2001/03/01 17:09:00 1.30 +++ bt.c 2001/06/25 02:02:01 @@ -1268,6 +1268,53 @@ cts = &ccb->cts; target_mask = 0x01 << ccb->ccb_h.target_id; +#ifdef CAM_NEW_TRAN_CODE + if (cts->type == CTS_TYPE_CURRENT_SETTINGS) { + struct ccb_trans_settings_scsi *scsi = + &cts->proto_specific.scsi; + struct ccb_trans_settings_spi *spi = + &cts->xport_specific.spi; + cts->protocol = PROTO_SCSI; + cts->protocol_version = SCSI_REV_2; + cts->transport = XPORT_SPI; + cts->transport_version = 2; + + scsi->flags &= ~CTS_SCSI_FLAGS_TAG_ENB; + spi->flags &= ~CTS_SPI_FLAGS_DISC_ENB; + + if ((bt->disc_permitted & target_mask) != 0) + spi->flags |= CTS_SPI_FLAGS_DISC_ENB; + if ((bt->tags_permitted & target_mask) != 0) + scsi->flags |= CTS_SCSI_FLAGS_TAG_ENB; + + if ((bt->ultra_permitted & target_mask) != 0) + spi->sync_period = 12; + else if ((bt->fast_permitted & target_mask) != 0) + spi->sync_period = 25; + else if ((bt->sync_permitted & target_mask) != 0) + spi->sync_period = 50; + else + spi->sync_period = 0; + + if (spi->sync_period != 0) + spi->sync_offset = 15; + + spi->valid |= CTS_SPI_VALID_SYNC_RATE; + spi->valid |= CTS_SPI_VALID_SYNC_OFFSET; + + spi->valid |= CTS_SPI_VALID_BUS_WIDTH; + if ((bt->wide_permitted & target_mask) != 0) + spi->bus_width = MSG_EXT_WDTR_BUS_16_BIT; + else + spi->bus_width = MSG_EXT_WDTR_BUS_8_BIT; + + if (cts->ccb_h.target_lun != CAM_LUN_WILDCARD) { + scsi->valid = CTS_SCSI_VALID_TQ; + spi->valid |= CTS_SPI_VALID_DISC; + } else + scsi->valid = 0; + } else { +#else if ((cts->flags & CCB_TRANS_USER_SETTINGS) != 0) { cts->flags = 0; if ((bt->disc_permitted & target_mask) != 0) @@ -1296,6 +1343,7 @@ | CCB_TRANS_DISC_VALID | CCB_TRANS_TQ_VALID; } else { +#endif btfetchtransinfo(bt, cts); } @@ -1366,6 +1414,12 @@ strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); cpi->unit_number = cam_sim_unit(sim); cpi->ccb_h.status = CAM_REQ_CMP; +#ifdef CAM_NEW_TRAN_CODE + cpi->transport = XPORT_SPI; + cpi->transport_version = 2; + cpi->protocol = PROTO_SCSI; + cpi->protocol_version = SCSI_REV_2; +#endif xpt_done(ccb); break; } @@ -1681,12 +1735,24 @@ case BTSTAT_TAGGED_MSG_REJECTED: { struct ccb_trans_settings neg; - +#ifdef CAM_NEW_TRAN_CODE + struct ccb_trans_settings_scsi *scsi = + &neg.proto_specific.scsi; + + neg.protocol = PROTO_SCSI; + neg.protocol_version = SCSI_REV_2; + neg.transport = XPORT_SPI; + neg.transport_version = 2; + scsi->valid = CTS_SCSI_VALID_TQ; + scsi->flags = 0; +#else + + neg.flags = 0; + neg.valid = CCB_TRANS_TQ_VALID; +#endif xpt_print_path(csio->ccb_h.path); printf("refuses tagged commands. Performing " "non-tagged I/O\n"); - neg.flags = 0; - neg.valid = CCB_TRANS_TQ_VALID; xpt_setup_ccb(&neg.ccb_h, csio->ccb_h.path, /*priority*/1); xpt_async(AC_TRANSFER_NEG, csio->ccb_h.path, &neg); @@ -2114,17 +2180,31 @@ * parameters for a particular target. */ static void -btfetchtransinfo(struct bt_softc *bt, struct ccb_trans_settings* cts) +btfetchtransinfo(struct bt_softc *bt, struct ccb_trans_settings *cts) { setup_data_t setup_info; u_int target; u_int targ_offset; u_int targ_mask; u_int sync_period; + u_int sync_offset; + u_int bus_width; int error; u_int8_t param; targ_syncinfo_t sync_info; +#ifdef CAM_NEW_TRAN_CODE + struct ccb_trans_settings_scsi *scsi = + &cts->proto_specific.scsi; + struct ccb_trans_settings_spi *spi = + &cts->xport_specific.spi; + + spi->valid = 0; + scsi->valid = 0; +#else + cts->valid = 0; +#endif + target = cts->ccb_h.target_id; targ_offset = (target & 0x7); targ_mask = (0x01 << targ_offset); @@ -2142,7 +2222,6 @@ if (error != 0) { printf("%s: btfetchtransinfo - Inquire Setup Info Failed %x\n", bt_name(bt), error); - cts->valid = 0; return; } @@ -2150,11 +2229,12 @@ : setup_info.high_syncinfo[targ_offset]; if (sync_info.sync == 0) - cts->sync_offset = 0; + sync_offset = 0; else - cts->sync_offset = sync_info.offset; + sync_offset = sync_info.offset; - cts->bus_width = MSG_EXT_WDTR_BUS_8_BIT; + + bus_width = MSG_EXT_WDTR_BUS_8_BIT; if (strcmp(bt->firmware_ver, "5.06L") >= 0) { u_int wide_active; @@ -2163,7 +2243,7 @@ : (setup_info.high_wide_active & targ_mask); if (wide_active) - cts->bus_width = MSG_EXT_WDTR_BUS_16_BIT; + bus_width = MSG_EXT_WDTR_BUS_16_BIT; } else if ((bt->wide_permitted & targ_mask) != 0) { struct ccb_getdev cgd; @@ -2179,7 +2259,7 @@ xpt_action((union ccb *)&cgd); if ((cgd.ccb_h.status & CAM_STATUS_MASK) == CAM_REQ_CMP && (cgd.inq_data.flags & SID_WBus16) != 0) - cts->bus_width = MSG_EXT_WDTR_BUS_16_BIT; + bus_width = MSG_EXT_WDTR_BUS_16_BIT; } if (bt->firmware_ver[0] >= '3') { @@ -2197,7 +2277,6 @@ if (error != 0) { printf("%s: btfetchtransinfo - Inquire Sync " "Info Failed 0x%x\n", bt_name(bt), error); - cts->valid = 0; return; } sync_period = sync_info.sync_rate[target] * 100; @@ -2205,15 +2284,40 @@ sync_period = 2000 + (500 * sync_info.period); } +#ifdef CAM_NEW_TRAN_CODE + cts->protocol = PROTO_SCSI; + cts->protocol_version = SCSI_REV_2; + cts->transport = XPORT_SPI; + cts->transport_version = 2; + + spi->sync_period = sync_period; + spi->valid |= CTS_SPI_VALID_SYNC_RATE; + spi->sync_offset = sync_offset; + spi->valid |= CTS_SPI_VALID_SYNC_OFFSET; + + spi->valid |= CTS_SPI_VALID_BUS_WIDTH; + spi->bus_width = bus_width; + + if (cts->ccb_h.target_lun != CAM_LUN_WILDCARD) { + scsi->valid = CTS_SCSI_VALID_TQ; + spi->valid |= CTS_SPI_VALID_DISC; + } else + scsi->valid = 0; + +#else /* Convert ns value to standard SCSI sync rate */ if (cts->sync_offset != 0) cts->sync_period = scsi_calc_syncparam(sync_period); else cts->sync_period = 0; + cts->sync_offset = sync_offset; + cts->bus_width = MSG_EXT_WDTR_BUS_8_BIT; cts->valid = CCB_TRANS_SYNC_RATE_VALID | CCB_TRANS_SYNC_OFFSET_VALID | CCB_TRANS_BUS_WIDTH_VALID; + +#endif xpt_async(AC_TRANSFER_NEG, cts->ccb_h.path, cts); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 24 20:49:18 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 3E79237B401; Sun, 24 Jun 2001 20:49:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5P3n5g82841; Sun, 24 Jun 2001 20:49:05 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sun, 24 Jun 2001 20:49:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: bishop@rr.iij4u.or.jp, Nick Hibma Cc: scsi@freebsd.org Subject: umass changes for CAM_NEW_TRAN_CODE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org FWIW... I can't test it (no h/w). Index: umass.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v retrieving revision 1.41 diff -u -r1.41 umass.c --- umass.c 2001/01/08 00:25:52 1.41 +++ umass.c 2001/06/25 03:47:54 @@ -2328,7 +2328,10 @@ cpi->bus_id = UMASS_SCSI_BUS; if (sc) cpi->base_transfer_speed = sc->transfer_speed; - +#ifdef CAM_NEW_TRAN_CODE + cpi->transport = XPORT_SPI; + cpi->transport_version = 2; +#endif cpi->ccb_h.status = CAM_REQ_CMP; xpt_done(ccb); break; @@ -2347,13 +2350,22 @@ { struct ccb_trans_settings *cts = &ccb->cts; - DPRINTF(UDMASS_SCSI, ("%s:%d:%d:%d:XPT_GET_TRAN_SETTINGS:.\n", - USBDEVNAME(sc->sc_dev), cam_sim_path(umass_sim), - ccb->ccb_h.target_id, ccb->ccb_h.target_lun)); +#ifdef CAM_NEW_TRAN_CODE + cts->protocol = PROTO_SCSI; + cts->protocol_version = SCSI_REV_2; + cts->transport = XPORT_SPI; + cts->transport_version = 2; + cts->proto_specific.scsi.valid = 0; + cts->xport_specific.spi.valid = 0; +#else cts->valid = 0; cts->flags = 0; /* no disconnection, tagging */ +#endif + DPRINTF(UDMASS_SCSI, ("%s:%d:%d:%d:XPT_GET_TRAN_SETTINGS:.\n", + USBDEVNAME(sc->sc_dev), cam_sim_path(umass_sim), + ccb->ccb_h.target_id, ccb->ccb_h.target_lun)); ccb->ccb_h.status = CAM_REQ_CMP; xpt_done(ccb); break; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 25 4:57:37 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id 227E037B406 for ; Mon, 25 Jun 2001 04:57:34 -0700 (PDT) (envelope-from non@ever.sanda.gr.jp) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id UAA19260; Mon, 25 Jun 2001 20:57:32 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id UAA02635; Mon, 25 Jun 2001 20:57:31 +0900 (JST) To: mjacob@feral.com Cc: scsi@freebsd.org Subject: Re: scsi_low changes for CAM_NEW_TRAN_CODE In-Reply-To: <20010624114453.L627-100000@wonky.feral.com> References: <20010624114453.L627-100000@wonky.feral.com> X-Mailer: Mew version 1.94 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010625205731E.non@ever.sanda.gr.jp> Date: Mon, 25 Jun 2001 20:57:31 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Matthew Jacob Date: Sun, 24 Jun 2001 11:46:06 -0700 (PDT) > I can't test, but these do compile. Let me know if you can commit them soon. Hmm, I should have posted below to scsi (I only posted to mobile and bsd-nomads). I would like to do after changes below. And could you make patches for scsi_low 2.12.1 (below) ? The ncv, nsp and stg drivers have been updated to catch up with NetBSD/pc98 thanks to Honda-san, the author. Patches for -current and -stable are placed at, http://home.jp.freebsd.org/~non/current.2.12.1.diff.gz http://home.jp.freebsd.org/~non/stable.2.12.1.diff.gz If you don't have latest current, you may need to update or copy src/sys/dev/ic/wd33c93reg.h from http://home.jp.freebsd.org/~non/wd33c93reg.h Most of the changes are, o Much separate NetBSD(XS) / FreeBSD(CAM) codes o Full support of QTag (tagged queing) o SCSI messages such as ABORT, RESET, TERMIO can be sent from uppeer layer o Improve parity error retry o Work around for KME UJDCD450 portable CD-ROM (nsp, stg) o Re-implementation of transfer settings thanks // Noriaki Mitsunaga // To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 25 5:52:36 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.qubesoft.com (gate.qubesoft.com [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id D36E437B405 for ; Mon, 25 Jun 2001 05:52:31 -0700 (PDT) (envelope-from n_hibma@FreeBSD.ORG) Received: from bluebottle.qubesoft.com (bluebottle [192.168.1.2]) by gate.qubesoft.com (8.11.3/8.11.3) with ESMTP id f5PCqTl91935; Mon, 25 Jun 2001 13:52:30 +0100 (BST) (envelope-from n_hibma@FreeBSD.ORG) Received: from localhost (localhost [127.0.0.1]) by bluebottle.qubesoft.com (8.11.4/8.11.4) with ESMTP id f5PCqSW36781; Mon, 25 Jun 2001 13:52:28 +0100 (BST) (envelope-from n_hibma@FreeBSD.ORG) Date: Mon, 25 Jun 2001 13:52:28 +0100 (BST) From: X-X-Sender: To: Matthew Jacob Cc: , Subject: Re: umass changes for CAM_NEW_TRAN_CODE In-Reply-To: Message-ID: <20010625135102.P53103-100000@bluebottle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org cts->protocol_version should be SCSI_REV_0 or something along those lines. The implementation of the *_transform functions and the implementations of the hardware don't allow for much else. Why doesn't CAM fish those values out of the Inquiry data like it does now (or doesn't it, if SCSI level is 0)? Feel free to commit. Nick > FWIW... I can't test it (no h/w). > > Index: umass.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v > retrieving revision 1.41 > diff -u -r1.41 umass.c > --- umass.c 2001/01/08 00:25:52 1.41 > +++ umass.c 2001/06/25 03:47:54 > @@ -2328,7 +2328,10 @@ > cpi->bus_id = UMASS_SCSI_BUS; > if (sc) > cpi->base_transfer_speed = sc->transfer_speed; > - > +#ifdef CAM_NEW_TRAN_CODE > + cpi->transport = XPORT_SPI; > + cpi->transport_version = 2; > +#endif > cpi->ccb_h.status = CAM_REQ_CMP; > xpt_done(ccb); > break; > @@ -2347,13 +2350,22 @@ > { > struct ccb_trans_settings *cts = &ccb->cts; > > - DPRINTF(UDMASS_SCSI, ("%s:%d:%d:%d:XPT_GET_TRAN_SETTINGS:.\n", > - USBDEVNAME(sc->sc_dev), cam_sim_path(umass_sim), > - ccb->ccb_h.target_id, ccb->ccb_h.target_lun)); > +#ifdef CAM_NEW_TRAN_CODE > + cts->protocol = PROTO_SCSI; > + cts->protocol_version = SCSI_REV_2; > + cts->transport = XPORT_SPI; > + cts->transport_version = 2; > > + cts->proto_specific.scsi.valid = 0; > + cts->xport_specific.spi.valid = 0; > +#else > cts->valid = 0; > cts->flags = 0; /* no disconnection, tagging */ > +#endif > > + DPRINTF(UDMASS_SCSI, ("%s:%d:%d:%d:XPT_GET_TRAN_SETTINGS:.\n", > + USBDEVNAME(sc->sc_dev), cam_sim_path(umass_sim), > + ccb->ccb_h.target_id, ccb->ccb_h.target_lun)); > ccb->ccb_h.status = CAM_REQ_CMP; > xpt_done(ccb); > break; > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 25 14:15: 9 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id A7CB537B407 for ; Mon, 25 Jun 2001 14:15:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5PLErg84757; Mon, 25 Jun 2001 14:14:54 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 25 Jun 2001 14:14:50 -0700 (PDT) From: Matthew Jacob Reply-To: To: Cc: Subject: Re: scsi_low changes for CAM_NEW_TRAN_CODE In-Reply-To: <20010625205731E.non@ever.sanda.gr.jp> Message-ID: <20010625141353.I3157-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm not really following this. Are you saying that you have the changes to accomodate the CAM_NEW_TRAN_CODE all ready to go? If so, can you check them in? There *will* be a switch to CAM_NEW_TRAN_CODE within 2 months at the outside. -matt On Mon, 25 Jun 2001 non@ever.sanda.gr.jp wrote: > From: Matthew Jacob > Date: Sun, 24 Jun 2001 11:46:06 -0700 (PDT) > > I can't test, but these do compile. Let me know if you can commit them soon. > > Hmm, I should have posted below to scsi (I only posted to mobile and > bsd-nomads). I would like to do after changes below. And could you > make patches for scsi_low 2.12.1 (below) ? > > The ncv, nsp and stg drivers have been updated to catch up with > NetBSD/pc98 thanks to Honda-san, the author. Patches for -current and > -stable are placed at, > > http://home.jp.freebsd.org/~non/current.2.12.1.diff.gz > http://home.jp.freebsd.org/~non/stable.2.12.1.diff.gz > > If you don't have latest current, you may need to update or copy > src/sys/dev/ic/wd33c93reg.h from > http://home.jp.freebsd.org/~non/wd33c93reg.h > > Most of the changes are, > o Much separate NetBSD(XS) / FreeBSD(CAM) codes > o Full support of QTag (tagged queing) > o SCSI messages such as ABORT, RESET, TERMIO can be sent from uppeer > layer > o Improve parity error retry > o Work around for KME UJDCD450 portable CD-ROM (nsp, stg) > o Re-implementation of transfer settings thanks > > // Noriaki Mitsunaga // > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 25 16:56:25 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id 7432E37B401 for ; Mon, 25 Jun 2001 16:56:21 -0700 (PDT) (envelope-from non@ever.sanda.gr.jp) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id IAA40739; Tue, 26 Jun 2001 08:56:19 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id IAA26751; Tue, 26 Jun 2001 08:56:19 +0900 (JST) To: mjacob@feral.com Cc: scsi@FreeBSD.ORG Subject: Re: scsi_low changes for CAM_NEW_TRAN_CODE In-Reply-To: <20010625141353.I3157-100000@wonky.feral.com> References: <20010625205731E.non@ever.sanda.gr.jp> <20010625141353.I3157-100000@wonky.feral.com> X-Mailer: Mew version 1.94 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010626085618N.non@ever.sanda.gr.jp> Date: Tue, 26 Jun 2001 08:56:18 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Matthew Jacob Date: Mon, 25 Jun 2001 14:14:50 -0700 (PDT) > I'm not really following this. Are you saying that you have the changes to > accomodate the CAM_NEW_TRAN_CODE all ready to go? If so, can you check them > in? No. I mean scsi_low.c will change shortly. The part of your patch will be little different in new scsi_low.c. // Noriaki Mitsunaga // To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 25 18: 9:50 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 943FF37B406 for ; Mon, 25 Jun 2001 18:09:48 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f5Q19hg87993; Mon, 25 Jun 2001 18:09:43 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 25 Jun 2001 18:09:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: non@ever.sanda.gr.jp Cc: scsi@FreeBSD.ORG Subject: Re: scsi_low changes for CAM_NEW_TRAN_CODE In-Reply-To: <20010626085618N.non@ever.sanda.gr.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Okay! Thanks! On Tue, 26 Jun 2001 non@ever.sanda.gr.jp wrote: > From: Matthew Jacob > Date: Mon, 25 Jun 2001 14:14:50 -0700 (PDT) > > I'm not really following this. Are you saying that you have the changes to > > accomodate the CAM_NEW_TRAN_CODE all ready to go? If so, can you check them > > in? > > No. I mean scsi_low.c will change shortly. The part of your patch > will be little different in new scsi_low.c. > > // Noriaki Mitsunaga // > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 28 5:22: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id C637737B401 for ; Thu, 28 Jun 2001 05:22:01 -0700 (PDT) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp153.dyn248.pacific.net.au [203.143.248.153]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id WAA28076; Thu, 28 Jun 2001 22:21:57 +1000 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.3/8.11.1) with ESMTP id f5SCPJY13905; Thu, 28 Jun 2001 22:25:19 +1000 (EST) (envelope-from mckay) Message-Id: <200106281225.f5SCPJY13905@dungeon.home> To: freebsd-scsi@freebsd.org Cc: mckay@thehub.com.au Subject: Problems reading burned CDs Date: Thu, 28 Jun 2001 22:25:18 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Some months ago I made vague assertions that one must use a 2 kilobyte block size when reading raw CD data, or risk missing the last part of the CD. Then I couldn't reproduce it, so blamed some mystery past version of FreeBSD. Actually, the difference is pressed vs burned CDs. If I read pressed CDs they all seem to end with a very long run of blocks of zeroes. No problem if I try to read a large block straddling the logical end of disk. But burned CDs appear to end suddenly, and a read request straddling the end of data will fail, and the partial contents will not be returned. Here is an example from reading a (short) burned CD on a Toshiba XM-5701 SCSI CD-ROM, on a 4.3-R system: # dd if=/dev/cd1c of=/dev/null bs=2k dd: /dev/cd1c: Input/output error 8367+0 records in 8367+0 records out 17135616 bytes transferred in 88.964899 secs (192611 bytes/sec) # dd if=/dev/cd1c of=/dev/null bs=4k dd: /dev/cd1c: Input/output error 4183+0 records in 4183+0 records out 17133568 bytes transferred in 88.895442 secs (192738 bytes/sec) Also, the system logs "Random positioning error" scsi errors, and there is a 60 second lag between reading the last sector and actually reporting the error (for retries, I presume). The 60 second delay explains the abysmal read speed, so don't panic about that. Checking on my burner, the error logged is "Illegal mode for this track" which causes no extra delay. But it still truncates the last block, losing data. My IDE cdrom does not log any sort of error, nor suffer an end-of-media delay, but it gets the size wrong by one sector. I'm told this has been fixed in -stable, but I've not checked. Anyway, this indicates to me that this is a SCSI CD problem, not a general CD problem. Is there any way around these problems with SCSI CD drives? Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 30 21: 1:29 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1651937B403 for ; Sat, 30 Jun 2001 21:01:20 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA22259; Sat, 30 Jun 2001 22:01:11 -0600 (MDT) (envelope-from ken) Date: Sat, 30 Jun 2001 22:01:11 -0600 From: "Kenneth D. Merry" To: Stephen McKay Cc: freebsd-scsi@FreeBSD.ORG, schilling@fokus.gmd.de Subject: Re: Problems reading burned CDs Message-ID: <20010630220111.A21825@panzer.kdm.org> References: <200106281225.f5SCPJY13905@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <200106281225.f5SCPJY13905@dungeon.home>; from mckay@thehub.com.au on Thu, Jun 28, 2001 at 10:25:18PM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ CCing Joerg Schilling, since he might have a clue about what's going on here. Joerg: look down at the bottom of this message for the question addressed to you. The rest of this is primarily background information. ] On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote: > Some months ago I made vague assertions that one must use a 2 kilobyte > block size when reading raw CD data, or risk missing the last part of > the CD. Then I couldn't reproduce it, so blamed some mystery past version > of FreeBSD. > > Actually, the difference is pressed vs burned CDs. > > If I read pressed CDs they all seem to end with a very long run of blocks > of zeroes. No problem if I try to read a large block straddling the > logical end of disk. > > But burned CDs appear to end suddenly, and a read request straddling the > end of data will fail, and the partial contents will not be returned. > > Here is an example from reading a (short) burned CD on a Toshiba > XM-5701 SCSI CD-ROM, on a 4.3-R system: > > # dd if=/dev/cd1c of=/dev/null bs=2k > dd: /dev/cd1c: Input/output error > 8367+0 records in > 8367+0 records out > 17135616 bytes transferred in 88.964899 secs (192611 bytes/sec) > > # dd if=/dev/cd1c of=/dev/null bs=4k > dd: /dev/cd1c: Input/output error > 4183+0 records in > 4183+0 records out > 17133568 bytes transferred in 88.895442 secs (192738 bytes/sec) > > Also, the system logs "Random positioning error" scsi errors, and there > is a 60 second lag between reading the last sector and actually reporting > the error (for retries, I presume). The 60 second delay explains the > abysmal read speed, so don't panic about that. > > Checking on my burner, the error logged is "Illegal mode for this track" > which causes no extra delay. But it still truncates the last block, > losing data. > > My IDE cdrom does not log any sort of error, nor suffer an end-of-media > delay, but it gets the size wrong by one sector. I'm told this has been > fixed in -stable, but I've not checked. Anyway, this indicates to me > that this is a SCSI CD problem, not a general CD problem. > > Is there any way around these problems with SCSI CD drives? Just out of curiosity, what did you use to burn the CD? cdrecord? I spent some time looking into this, and got some interesting results. In short, I can reproduce your results with a burned CD versus a pressed CD. The results are the same for both a Plextor CD-RW and a Toshiba DVD-ROM in my machine, so I don't think it's a CDROM firmware issue. It looks like the problem is a capacity reporting problem, possibly due to the way the burned CD was burned. In cd1 (Toshiba DVD-ROM), I have a pressed CD. In cd0 (Plextor CD-RW) I have a data CD-RW burned using cdrecord: First, a read capacity on cd1 (the pressed CD): # camcontrol cmd cd1 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 14032 2048 So the address of the last LBA is 14032. Now, we attempt to read that particular block from the drive: # camcontrol cmd cd1 -v -c "28 0 v:i4 0 v:i2 0" 14032 1 -i 2048 - > /dev/null Worked fine, no errors. Now we do a read capacity on cd0 (the burned CD-RW): # camcontrol cmd cd0 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 297518 2048 So the last address is 297518. We attempt to read that block: # camcontrol cmd cd0 -v -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null camcontrol: error sending command CAM status is 0xb Looks like we got a command timeout. (That's what 0xb means. Under FreeBSD-current, camcontrol prints out more descriptive messages for non-SCSI errors.) So let's bump the timeout up to 120 seconds and try to read the same block again: # camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null camcontrol: error sending command (pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 (pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0 (pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred Oh yeah, the BDR sent in response to the timeout will cause a unit attention condition. Let's try it again: # camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null camcontrol: error sending command (pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 (pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2e asc:11,5 (pass2:ahc1:0:4:0): L-EC uncorrectable error Hmm, looks like we can't read the LBA the drive claims is the last one on the CD. Let's try the previous LBA: # camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297517 1 -i 2048 - > /dev/null camcontrol: error sending command (pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2d 0 0 1 0 (pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2d asc:6,0 (pass2:ahc1:0:4:0): No reference position found Still can't read that one. Let's try decrementing the LBA again: # camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297516 1 -i 2048 - > /dev/null That works fine. So it looks like the CD may have a bogus table of contents on it, since it doesn't seem to describe the range of valid data on the disk. The table of contents on the drives seems to agree with the read capacity data: (that's probably where the drive gets the data in the first place) This is the Plextor CD-RW with the burned CD-RW in it: # cdrecord dev=1,4,0 -toc Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling scsidev: '1,4,0' scsibus: 1 target: 4 lun: 0 Using libscg version 'schily-0.1' Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'PLEXTOR ' Identifikation : 'CD-R PX-W1210S' Revision : '1.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO first: 1 last 1 track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 track:lout lba: 297519 ( 1190076) 66:08:69 adr: 1 control: 4 mode: -1 This is the Toshiba DVD-ROM with the pressed CD in it: # cdrecord dev=1,5,0 -toc Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling scsidev: '1,5,0' scsibus: 1 target: 5 lun: 0 Using libscg version 'schily-0.1' Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'TOSHIBA ' Identifikation : 'DVD-ROM SD-M1401' Revision : '1007' Device seems to be: Generic mmc CD-ROM. Using generic SCSI-3/mmc CD driver (mmc_cd). Driver flags : SWABAUDIO first: 1 last 1 track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 track:lout lba: 14033 ( 56132) 03:09:08 adr: 1 control: 4 mode: -1 So now the question for Joerg -- do you know of any difference between burned CDs and "pressed" CDs (i.e. CDs produced commercially) that would account for the reported capacity of the burned CDs apparantly being a couple of blocks longer than the actual amount of data that can be read? Or could it possibly be a bug in mkisofs or cdrecord that's causing the TOC to get written improperly? (I don't know which application writes the TOC, or whether the drive is actually doing it.) Anyway, I don't have a ready answer for this one. Hopefully Joerg can shed some light on the problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message