From owner-freebsd-scsi Sun May 10 06:23:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA22619 for freebsd-scsi-outgoing; Sun, 10 May 1998 06:23:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA22608 for ; Sun, 10 May 1998 06:23:19 -0700 (PDT) (envelope-from son@cezanne.prism.uvsq.fr) Received: from cezanne.prism.uvsq.fr (rtc101.reseau.uvsq.fr [193.51.24.17]) by soleil.uvsq.fr (8.8.8/jtpda-5.3) with ESMTP id PAA15059 for ; Sun, 10 May 1998 15:23:09 +0200 (METDST) Received: (from son@localhost) by cezanne.prism.uvsq.fr (8.8.5/8.8.5) id PAA00580; Sun, 10 May 1998 15:24:34 GMT Message-ID: <19980510152433.56484@coreff.prism.uvsq.fr> Date: Sun, 10 May 1998 15:24:33 +0000 From: Nicolas Souchu To: freebsd-scsi@FreeBSD.ORG Subject: parallel ZIP port to CAM, done! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" X-Mailer: Mutt 0.81e X-Operating-System: FreeBSD coreff 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Hi there, The parallel ZIP drive has an parallel<->scsi converter named VP0. vpo is the driver for the ZIP-embeded aic7110 SCSI controller. ** vpo is now CAM compliant ** I've ported vpo with -current 980413 patched with cam diffs. Justin or anybody else may want to commit/review the code. See attachment. Few notes: - #ifdef VP0_DEBUG lines will be removed when the entire ppbus system will be released - the ZIP speed is 93kB/s. I've setup transfer_speed field with 93 but the reported speed is 0.9Mb/s. The ZIP is certainly to slow for CAM :) - the ZIP is polled only, should I insert splcam() calls anyway? - see attachment for dmesg-vpo output - my aic7880 onboard chipset works fine with CAM. Great work! Regards. -- Nicolas.Souchu@prism.uvsq.fr FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vpo-980413.diffs" Index: src/sys/dev/ppbus/vpo.c diff -c src/sys/dev/ppbus/vpo.c:1.1.1.1 src/sys/dev/ppbus/vpo.c:1.1.1.1.4.1 *** src/sys/dev/ppbus/vpo.c:1.1.1.1 Mon Sep 1 00:51:52 1997 --- src/sys/dev/ppbus/vpo.c Sun May 10 13:52:58 1998 *************** *** 36,50 **** #include #endif /* KERNEL */ - #include - #include #ifdef KERNEL #include #endif /*KERNEL */ #include - #include /* -------------------------------------------------------------------- * HERE ARE THINGS YOU MAY HAVE/WANT TO CHANGE --- 36,57 ---- #include #endif /* KERNEL */ + #include + #include + #include + #include + #include + + #include + #include + #include + #ifdef KERNEL #include #endif /*KERNEL */ #include /* -------------------------------------------------------------------- * HERE ARE THINGS YOU MAY HAVE/WANT TO CHANGE *************** *** 62,108 **** * DO NOT MODIFY ANYTHING UNDER THIS LINE * -------------------------------------------------------------------- */ ! static inline int vpoio_do_scsi(struct vpo_data *, int, int, char *, int, ! char *, int, int *, int *); ! static int32_t vpo_scsi_cmd(struct scsi_xfer *); ! static void vpominphys(struct buf *); ! static u_int32_t vpo_adapter_info(int); static int vpo_detect(struct vpo_data *vpo); static int nvpo = 0; #define MAXVP0 8 /* XXX not much better! */ static struct vpo_data *vpodata[MAXVP0]; #ifdef KERNEL - static struct scsi_adapter vpo_switch = - { - vpo_scsi_cmd, - vpominphys, - 0, - 0, - vpo_adapter_info, - "vpo", - { 0, 0 } - }; - - /* - * The below structure is so we have a default dev struct - * for out link struct. - */ - static struct scsi_device vpo_dev = - { - NULL, /* Use default error handler */ - NULL, /* have a queue, served by this */ - NULL, /* have no async handler */ - NULL, /* Use default 'done' routine */ - "vpo", - 0, - { 0, 0 } - }; - /* * Make ourselves visible as a ppbus driver --- 69,169 ---- * DO NOT MODIFY ANYTHING UNDER THIS LINE * -------------------------------------------------------------------- */ + + #define VP0_INITIATOR 0x7 + + #define VP0_SECTOR_SIZE 512 + #define VP0_BUFFER_SIZE 0x12000 + + #define VP0_ESELECT_TIMEOUT 1 + #define VP0_ECMD_TIMEOUT 2 + #define VP0_ECONNECT 3 + #define VP0_ESTATUS_TIMEOUT 4 + #define VP0_EDATA_OVERFLOW 5 + #define VP0_EDISCONNECT 6 + #define VP0_EPPDATA_TIMEOUT 7 + #define VP0_ENOPORT 9 + #define VP0_EINITFAILED 10 + #define VP0_EINTR 12 + + #define VP0_EOTHER 13 + + #define VP0_OPENNINGS 1 + + #define n(flags) (~(flags) & (flags)) + + /* + * VP0 timings. + */ + #define MHZ_16_IO_DURATION 62 + + #define VP0_SPP_WRITE_PULSE 253 + #define VP0_NIBBLE_READ_PULSE 486 + + /* + * VP0 connections. + */ + #define H_AUTO n(AUTOFEED) + #define H_nAUTO AUTOFEED + #define H_STROBE n(STROBE) + #define H_nSTROBE STROBE + #define H_BSY n(nBUSY) + #define H_nBSY n_BUSY + #define H_SEL SELECT + #define H_nSEL n(SELECT) + #define H_ERR ERROR + #define H_nERR n(ERROR) + #define H_ACK nACK + #define H_nACK n(nACK) + #define H_FLT nFAULT + #define H_nFLT n(nFAULT) + #define H_SELIN n(SELECTIN) + #define H_nSELIN SELECTIN + #define H_INIT nINIT + #define H_nINIT n(nINIT) + + struct vpo_sense { + struct scsi_sense cmd; + unsigned int stat; + unsigned int count; + }; + + struct vpo_data { + unsigned short vpo_unit; ! int vpo_stat; ! int vpo_count; ! int vpo_error; ! struct cam_sim *sim; ! struct cam_path *path; + struct vpo_sense vpo_sense; + + unsigned char vpo_buffer[VP0_BUFFER_SIZE]; + + struct ppb_device vpo_dev; + }; + + /* vpo control operations */ + static int vpoio_do_scsi(struct vpo_data *, int, int, char *, int, + char *, int, int *, int *); + static int vpoio_disconnect(struct vpo_data *vpo); + static int vpoio_connect(struct vpo_data *vpo, int how); + static int vpoio_in_disk_mode(struct vpo_data *vpo); + static void vpoio_reset(struct vpo_data *vpo); + static int vpo_detect(struct vpo_data *vpo); + /* cam related functions */ + static void vpo_action(struct cam_sim *sim, union ccb *ccb); + static void vpo_poll(struct cam_sim *sim); + static int nvpo = 0; #define MAXVP0 8 /* XXX not much better! */ static struct vpo_data *vpodata[MAXVP0]; #ifdef KERNEL /* * Make ourselves visible as a ppbus driver *************** *** 116,122 **** }; DATA_SET(ppbdriver_set, vpodriver); - #endif /* KERNEL */ static u_int32_t --- 177,182 ---- *************** *** 183,194 **** struct scsibus_data *scbus; struct vpo_data *vpo = vpodata[dev->id_unit]; - vpo->sc_link.adapter_unit = vpo->vpo_unit; - vpo->sc_link.adapter_targ = VP0_INITIATOR; - vpo->sc_link.adapter = &vpo_switch; - vpo->sc_link.device = &vpo_dev; - vpo->sc_link.opennings = VP0_OPENNINGS; - /* * Report ourselves */ --- 243,248 ---- *************** *** 196,226 **** dev->id_unit, dev->ppb->ppb_link->adapter_unit); /* ! * Prepare the scsibus_data area for the upperlevel ! * scsi code. ! */ ! scbus = scsi_alloc_bus(); ! if(!scbus) return (0); - scbus->adapter_link = &vpo->sc_link; - - scsi_attachdevs(scbus); - - return (1); - } ! static void ! vpominphys(struct buf *bp) ! { ! if (bp->b_bcount > VP0_BUFFER_SIZE) ! bp->b_bcount = VP0_BUFFER_SIZE; ! return; } #ifdef VP0_WARNING ! static inline void vpo_warning(struct vpo_data *vpo, struct scsi_xfer *xs, int timeout) { --- 250,297 ---- dev->id_unit, dev->ppb->ppb_link->adapter_unit); /* ! ** Now tell the generic SCSI layer ! ** about our bus. ! */ ! vpo->sim = cam_alloc_sim(); ! if (vpo->sim == 0) return (0); ! vpo->sim->sim_action = vpo_action; ! vpo->sim->sim_poll = vpo_poll; ! vpo->sim->sim_name = "vpo"; ! vpo->sim->softc = vpo; ! /* ! ** Don't care what our path id is - If we were the boot ! ** device we'd set it to 0???? ! */ ! vpo->sim->path_id = (u_int32_t)-1; ! vpo->sim->unit_number = vpo->vpo_unit; ! vpo->sim->bus_id = 0; ! vpo->sim->base_transfer_speed = 93; /* Async transfer rate in kB/s */ ! vpo->sim->max_tagged_dev_openings = 0; ! vpo->sim->max_dev_openings = 1; ! vpo->sim->max_openings = 1; ! ! if (xpt_bus_register(vpo->sim) != CAM_SUCCESS) { ! free(vpo->sim, M_DEVBUF); ! return (0); ! } ! ! if (xpt_create_path(&vpo->path, /*periph*/NULL, ! vpo->sim->path_id, CAM_TARGET_WILDCARD, ! CAM_LUN_WILDCARD) != CAM_REQ_CMP) { ! xpt_bus_deregister(vpo->sim->path_id); ! free(vpo->sim, M_DEVBUF); ! return (0); ! } ! return (1); } #ifdef VP0_WARNING ! static void vpo_warning(struct vpo_data *vpo, struct scsi_xfer *xs, int timeout) { *************** *** 267,290 **** #endif /* VP0_WARNING */ /* ! * vpointr() */ ! static inline void ! vpointr(struct vpo_data *vpo, struct scsi_xfer *xs) { ! int errno; /* error in errno.h */ ! if (xs->datalen && !(xs->flags & SCSI_DATA_IN)) ! bcopy(xs->data, vpo->vpo_buffer, xs->datalen); ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, ! xs->sc_link->target, (char *)xs->cmd, xs->cmdlen, ! vpo->vpo_buffer, xs->datalen, &vpo->vpo_stat, &vpo->vpo_count); #ifdef VP0_DEBUG printf("vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\n", errno, vpo->vpo_stat, vpo->vpo_count, vpo->vpo_error); #endif if (errno) { --- 338,368 ---- #endif /* VP0_WARNING */ /* ! * vpo_intr() */ ! static void ! vpo_intr(struct vpo_data *vpo, struct ccb_scsiio *csio) { ! int i, errno; /* error in errno.h */ ! int s; ! s = splcam(); ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, csio->ccb_h.target_id, ! (char *)&csio->cdb_io.cdb_bytes, csio->cdb_len, ! (char *)csio->data_ptr, csio->dxfer_len, ! &vpo->vpo_stat, &vpo->vpo_count); #ifdef VP0_DEBUG printf("vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\n", errno, vpo->vpo_stat, vpo->vpo_count, vpo->vpo_error); + + /* dump of command */ + for (i=0; icdb_len; i++) + printf("%x ", ((char *)&csio->cdb_io.cdb_bytes)[i]); + + printf("\n"); #endif if (errno) { *************** *** 292,298 **** log(LOG_WARNING, "vpo%d: errno = %d\n", vpo->vpo_unit, errno); #endif /* connection to ppbus interrupted */ ! xs->error = XS_DRIVER_STUFFUP; goto error; } --- 370,376 ---- log(LOG_WARNING, "vpo%d: errno = %d\n", vpo->vpo_unit, errno); #endif /* connection to ppbus interrupted */ ! csio->ccb_h.status = CAM_CMD_TIMEOUT; goto error; } *************** *** 301,391 **** #ifdef VP0_WARNING vpo_warning(vpo, xs, vpo->vpo_error); #endif ! xs->error = XS_TIMEOUT; goto error; } ! #define RESERVED_BITS_MASK 0x3e /* 00111110b */ ! #define NO_SENSE 0x0 ! #define CHECK_CONDITION 0x02 ! switch (vpo->vpo_stat & RESERVED_BITS_MASK) { ! case NO_SENSE: ! break; ! case CHECK_CONDITION: ! vpo->vpo_sense.cmd.op_code = REQUEST_SENSE; ! vpo->vpo_sense.cmd.length = sizeof(xs->sense); vpo->vpo_sense.cmd.control = 0; ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, ! xs->sc_link->target, (char *)&vpo->vpo_sense.cmd, ! sizeof(vpo->vpo_sense.cmd), ! (char *)&xs->sense, sizeof(xs->sense), &vpo->vpo_sense.stat, &vpo->vpo_sense.count); ! if (errno) ! /* connection to ppbus interrupted */ ! xs->error = XS_DRIVER_STUFFUP; ! else ! xs->error = XS_SENSE; ! goto error; ! default: /* BUSY or RESERVATION_CONFLICT */ ! xs->error = XS_TIMEOUT; ! goto error; ! } ! if (xs->datalen && (xs->flags & SCSI_DATA_IN)) ! bcopy(vpo->vpo_buffer, xs->data, xs->datalen); ! done: ! xs->resid = 0; ! xs->error = XS_NOERROR; error: ! xs->flags |= ITSDONE; ! scsi_done(xs); return; } ! static int32_t ! vpo_scsi_cmd(struct scsi_xfer *xs) { ! int s; ! if (xs->sc_link->lun > 0) { ! xs->error = XS_DRIVER_STUFFUP; ! return TRY_AGAIN_LATER; } ! if (xs->flags & SCSI_DATA_UIO) { ! printf("UIO not supported by vpo_driver !\n"); ! xs->error = XS_DRIVER_STUFFUP; ! return TRY_AGAIN_LATER; } #ifdef VP0_DEBUG ! printf("vpo_scsi_cmd(): xs->flags = 0x%x, "\ ! "xs->data = 0x%x, xs->datalen = %d\ncommand : %*D\n", ! xs->flags, xs->data, xs->datalen, ! xs->cmdlen, xs->cmd, " " ); #endif ! if (xs->flags & SCSI_NOMASK) { ! vpointr(vpodata[xs->sc_link->adapter_unit], xs); ! return COMPLETE; } ! s = VP0_SPL(); ! vpointr(vpodata[xs->sc_link->adapter_unit], xs); ! splx(s); ! return SUCCESSFULLY_QUEUED; } #define vpoio_d_pulse(vpo,b) { \ --- 379,566 ---- #ifdef VP0_WARNING vpo_warning(vpo, xs, vpo->vpo_error); #endif ! csio->ccb_h.status = CAM_CMD_TIMEOUT; goto error; } ! /* check scsi status */ ! if (vpo->vpo_stat != SCSI_STATUS_OK) { ! csio->scsi_status = vpo->vpo_stat; ! /* check if we have to sense the drive */ ! if ((vpo->vpo_stat & SCSI_STATUS_CHECK_COND) != 0) { ! ! vpo->vpo_sense.cmd.opcode = REQUEST_SENSE; ! vpo->vpo_sense.cmd.length = csio->sense_len; vpo->vpo_sense.cmd.control = 0; ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, csio->ccb_h.target_id, ! (char *)&vpo->vpo_sense.cmd, sizeof(vpo->vpo_sense.cmd), ! (char *)&csio->sense_data, csio->sense_len, &vpo->vpo_sense.stat, &vpo->vpo_sense.count); + + #ifdef VP0_DEBUG + printf("(sense) vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\n", + errno, vpo->vpo_sense.stat, vpo->vpo_sense.count, vpo->vpo_error); + #endif ! /* check sense return status */ ! if (errno == 0 && vpo->vpo_sense.stat == SCSI_STATUS_OK) { ! /* sense ok */ ! csio->ccb_h.status = CAM_AUTOSNS_VALID | CAM_SCSI_STATUS_ERROR; ! csio->sense_resid = csio->sense_len - vpo->vpo_sense.count; ! #ifdef VP0_DEBUG ! /* dump of sense info */ ! printf("(sense) "); ! for (i=0; ivpo_sense.count; i++) ! printf("%x ", ((char *)&csio->sense_data)[i]); ! printf("\n"); ! #endif ! } else { ! /* sense failed */ ! csio->ccb_h.status = CAM_AUTOSENSE_FAIL; + } + } else { + + /* no sense */ + csio->ccb_h.status = CAM_SCSI_STATUS_ERROR; + } + + goto error; + } + + csio->resid = csio->dxfer_len - vpo->vpo_count; + csio->ccb_h.status = CAM_REQ_CMP; + error: ! splx(s); return; } ! static void ! vpo_action(struct cam_sim *sim, union ccb *ccb) { ! struct vpo_data *vpo = (struct vpo_data *)sim->softc; ! ! switch (ccb->ccb_h.func_code) { ! case XPT_SCSI_IO: ! { ! struct ccb_scsiio *csio; ! ! csio = &ccb->csio; ! ! #ifdef VP0_DEBUG ! printf("vpo%d: XPT_SCSI_IO (0x%x) request\n", ! vpo->vpo_unit, csio->cdb_io.cdb_bytes[0]); ! #endif ! ! vpo_intr(vpo, csio); ! ! xpt_done(ccb); ! break; } + case XPT_CALC_GEOMETRY: + { + struct ccb_calc_geometry *ccg; + u_int32_t size_mb; + u_int32_t secs_per_cylinder; + + ccg = &ccb->ccg; + size_mb = ccg->volume_size + / ((1024L * 1024L) / ccg->block_size); + + #ifdef VP0_DEBUG + printf("vpo%d: XPT_CALC_GEOMETRY (%d, %d) request\n", + vpo->vpo_unit, ccg->volume_size, ccg->block_size); + #endif + + ccg->heads = 64; + ccg->secs_per_track = 32; + + secs_per_cylinder = ccg->heads * ccg->secs_per_track; + ccg->cylinders = ccg->volume_size / secs_per_cylinder; ! ccb->ccb_h.status = CAM_REQ_CMP; ! xpt_done(ccb); ! break; } + case XPT_RESET_BUS: /* Reset the specified SCSI bus */ + { + + #ifdef VP0_DEBUG + printf("vpo%d: XPT_RESET_BUS request\n", vpo->vpo_unit); + #endif + /* first, connect to the drive */ + if (vpoio_connect(vpo, PPB_WAIT|PPB_INTR) || + (vpoio_in_disk_mode(vpo) == 0)) { + + /* release ppbus */ + vpoio_disconnect(vpo); + + ccb->ccb_h.status = CAM_REQ_CMP_ERR; + xpt_done(ccb); + return; + } + + /* reset the SCSI bus */ + vpoio_reset(vpo); + + /* then disconnect */ + vpoio_disconnect(vpo); + ccb->ccb_h.status = CAM_REQ_CMP; + xpt_done(ccb); + break; + } + case XPT_PATH_INQ: /* Path routing inquiry */ + { + struct ccb_pathinq *cpi = &ccb->cpi; + #ifdef VP0_DEBUG ! printf("vpo%d: XPT_PATH_INQ request\n", vpo->vpo_unit); #endif + cpi->version_num = 1; /* XXX??? */ + cpi->max_target = 7; + cpi->max_lun = 0; + cpi->initiator_id = VP0_INITIATOR; + cpi->bus_id = sim->bus_id; + strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); + strncpy(cpi->hba_vid, "Iomega", HBA_IDLEN); + strncpy(cpi->dev_name, sim->sim_name, DEV_IDLEN); + cpi->unit_number = sim->unit_number; ! cpi->ccb_h.status = CAM_REQ_CMP; ! xpt_done(ccb); ! break; ! } ! default: ! ccb->ccb_h.status = CAM_REQ_INVALID; ! xpt_done(ccb); ! break; } + + return; + } ! static void ! vpo_poll(struct cam_sim *sim) ! { ! /* The ZIP is actually always polled throw vpo_action() */ ! #ifdef VP0_DEBUG ! printf("vpo%d: entering vpo_poll()\n", sim->unit_number); ! #endif ! return; } #define vpoio_d_pulse(vpo,b) { \ *************** *** 516,522 **** } /* send SCSI reset signal */ ! vpoio_reset (vpo); vpoio_disconnect(vpo); --- 691,697 ---- } /* send SCSI reset signal */ ! vpoio_reset(vpo); vpoio_disconnect(vpo); *************** *** 694,700 **** return (error); } ! static inline char vpoio_select(struct vpo_data *vpo, int initiator, int target) { --- 869,875 ---- return (error); } ! static char vpoio_select(struct vpo_data *vpo, int initiator, int target) { *************** *** 708,714 **** k = 0; while (!(ppb_rstr(&vpo->vpo_dev) & 0x40) && (k++ < VP0_SELTMO)) ! barrier(); if (k >= VP0_SELTMO) return (VP0_ESELECT_TIMEOUT); --- 883,889 ---- k = 0; while (!(ppb_rstr(&vpo->vpo_dev) & 0x40) && (k++ < VP0_SELTMO)) ! ; if (k >= VP0_SELTMO) return (VP0_ESELECT_TIMEOUT); *************** *** 721,727 **** * * H_SELIN must be low. */ ! static inline char vpoio_wait(struct vpo_data *vpo, int tmo) { --- 896,902 ---- * * H_SELIN must be low. */ ! static char vpoio_wait(struct vpo_data *vpo, int tmo) { *************** *** 737,743 **** k = 0; while (!((r = ppb_rstr(&vpo->vpo_dev)) & nBUSY) && (k++ < tmo)) ! barrier(); /* * Return some status information. --- 912,918 ---- k = 0; while (!((r = ppb_rstr(&vpo->vpo_dev)) & nBUSY) && (k++ < tmo)) ! ; /* * Return some status information. *************** *** 752,758 **** return (0); /* command timed out */ } ! static inline int vpoio_do_scsi(struct vpo_data *vpo, int host, int target, char *command, int clen, char *buffer, int blen, int *result, int *count) { --- 927,933 ---- return (0); /* command timed out */ } ! static int vpoio_do_scsi(struct vpo_data *vpo, int host, int target, char *command, int clen, char *buffer, int blen, int *result, int *count) { *************** *** 787,797 **** */ ppb_wctr(&vpo->vpo_dev, H_AUTO | H_nSELIN | H_INIT | H_STROBE); - #ifdef VP0_DEBUG - printf("vpo%d: drive selected, now sending the command...\n", - vpo->vpo_unit); - #endif - for (k = 0; k < clen; k++) { if (vpoio_wait(vpo, VP0_FAST_SPINTMO) != (char)0xe0) { vpo->vpo_error = VP0_ECMD_TIMEOUT; --- 962,967 ---- *************** *** 803,818 **** } } - #ifdef VP0_DEBUG - printf("vpo%d: command sent, now completing the request...\n", - vpo->vpo_unit); - #endif - /* * Completion ... */ ! rw = ((command[0] == READ_COMMAND) || (command[0] == READ_BIG) || ! (command[0] == WRITE_COMMAND) || (command[0] == WRITE_BIG)); *count = 0; for (;;) { --- 973,983 ---- } } /* * Completion ... */ ! rw = ((command[0] == READ_6) || (command[0] == READ_10) || ! (command[0] == WRITE_6) || (command[0] == WRITE_10)); *count = 0; for (;;) { Index: src/sys/dev/ppbus/vpo.h diff -c src/sys/dev/ppbus/vpo.h:1.1.1.1 src/sys/dev/ppbus/vpo.h:removed *** src/sys/dev/ppbus/vpo.h:1.1.1.1 Sat Aug 16 14:05:38 1997 --- src/sys/dev/ppbus/vpo.h Sun May 10 13:56:27 1998 *************** *** 1,110 **** - /*- - * Copyright (c) 1997 Nicolas Souchu - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * $Id: vpo.h,v 1.2 1997/08/16 14:05:38 msmith Exp $ - * - */ - #ifndef __VP03_H - #define __VP03_H - - #define barrier() __asm__("": : :"memory") - - #define VP0_INITIATOR 0x7 - - #define VP0_SECTOR_SIZE 512 - #define VP0_BUFFER_SIZE 0x12000 - - #define VP0_SPL() splbio() - - #define VP0_ESELECT_TIMEOUT 1 - #define VP0_ECMD_TIMEOUT 2 - #define VP0_ECONNECT 3 - #define VP0_ESTATUS_TIMEOUT 4 - #define VP0_EDATA_OVERFLOW 5 - #define VP0_EDISCONNECT 6 - #define VP0_EPPDATA_TIMEOUT 7 - #define VP0_ENOPORT 9 - #define VP0_EINITFAILED 10 - #define VP0_EINTR 12 - - #define VP0_EOTHER 13 - - #define VP0_OPENNINGS 1 - - #define n(flags) (~(flags) & (flags)) - - /* - * VP0 timings. - */ - #define MHZ_16_IO_DURATION 62 - - #define VP0_SPP_WRITE_PULSE 253 - #define VP0_NIBBLE_READ_PULSE 486 - - /* - * VP0 connections. - */ - #define H_AUTO n(AUTOFEED) - #define H_nAUTO AUTOFEED - #define H_STROBE n(STROBE) - #define H_nSTROBE STROBE - #define H_BSY n(nBUSY) - #define H_nBSY n_BUSY - #define H_SEL SELECT - #define H_nSEL n(SELECT) - #define H_ERR ERROR - #define H_nERR n(ERROR) - #define H_ACK nACK - #define H_nACK n(nACK) - #define H_FLT nFAULT - #define H_nFLT n(nFAULT) - #define H_SELIN n(SELECTIN) - #define H_nSELIN SELECTIN - #define H_INIT nINIT - #define H_nINIT n(nINIT) - - struct vpo_sense { - struct scsi_sense cmd; - unsigned int stat; - unsigned int count; - }; - - struct vpo_data { - unsigned short vpo_unit; - - int vpo_stat; - int vpo_count; - int vpo_error; - - struct ppb_status vpo_status; - struct vpo_sense vpo_sense; - - unsigned char vpo_buffer[VP0_BUFFER_SIZE]; - - struct ppb_device vpo_dev; - struct scsi_link sc_link; - }; - - #endif --- 0 ---- --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.vpo" Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #21: Sun May 10 13:25:32 GMT 1998 toor@breizh:/usr/local/src/sys/compile/CAM Timecounter "i8254" frequency 1193182 Hz cost 2527 ns Timecounter "TSC" frequency 166586877 Hz cost 212 ns CPU: Pentium (166.59-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping=3 Features=0x8001bf real memory = 33554432 (32768K bytes) avail memory = 30044160 (29340K bytes) Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 ahc0: rev 0x00 int a irq 11 on pci0.9.0 ahc0: Using left over BIOS settings ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 3 maddr 0xd0000 msize 16384 on isa ed0: address 00:00:c0:37:f2:d0, type SMC8216/SMC8216C (16 bit) ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset in EPP mode (EPP 1.9) ppbus0: nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 vpo0: on ppbus 0 ppc: port not present at 0x278. ppc1 not found at 0x278 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console psm0 not found at 0x60 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, intr, iordy wcd0: 344Kb/sec, 256Kb cache, audio play, 121 volume levels, ejectable tray wcd0: no disc inside, unlocked, lock protected npx0 on motherboard npx0: INT 16 interface Intel Pentium F00F detected, installing workaround (da1:vpo0:0:6:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:vpo0:0:6:0): NOT READY asc:3a,0 (da1:vpo0:0:6:0): Medium not present da1 at vpo0 bus 0 target 6 lun 0 da1: Removable Direct Access SCSI2 device da1: 0.9MB/s transfers da1: Attempt to query device size, failed da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number F27G5830 da0: 10.0MB/s transfers (5.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 64H 32S/T 2063C) --k1lZvvs/B4yU6o8G-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 10 16:36:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27469 for freebsd-scsi-outgoing; Sun, 10 May 1998 16:36:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.artcom.de ([192.76.129.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27464 for ; Sun, 10 May 1998 16:36:43 -0700 (PDT) (envelope-from hans@artcom.de) Received: from transrapid.artcom.de by mail.artcom.de with smtp id m0yYfe0-00001gC; Mon, 11 May 1998 01:36:36 +0200 (MEST) Date: Mon, 11 May 1998 01:36:36 +0200 (MEST) From: Hans Huebner To: freebsd-scsi@FreeBSD.ORG Subject: Is anybody working on the tape driver? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello there, I'm currently working at the SCSI tape driver (under 2.2.6-RELEASE) because it seems to lack many features other systems already have. In particular, I need better fast-locate support and a better device statistics interface. The current progress state of the tape driver seems to be hibernating, similar to the changer driver nobody seems to have cared adding functionality for quite a while. On the other hand, recent discussions on this list indicate that people seem to use FreeBSD for backups, so there should be some interest in better tape support. I would want to integrate some of the functionality I currently access with perl/scsi(8) scripts into the tape driver. This would involve some structural changes to make MTIOCGET fully work, and also the addition of one or more additional ioctl's. This leaves me with the following questions: Is there anybody else working on the tape driver who would want to share code and/or information? Are there any features in the queue waiting to be commited? Replies solicited, Hans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 10 16:54:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29601 for freebsd-scsi-outgoing; Sun, 10 May 1998 16:54:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29536 for ; Sun, 10 May 1998 16:54:04 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id QAA01303; Sun, 10 May 1998 16:53:54 -0700 Date: Sun, 10 May 1998 16:53:54 -0700 From: Matthew Jacob Message-Id: <199805102353.QAA01303@feral.com> To: freebsd-scsi@FreeBSD.ORG, hans@artcom.de Subject: Re: Is anybody working on the tape driver? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I believe the CAM folks are working on it, and yes, fast locate support would be necessary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 10 17:40:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06063 for freebsd-scsi-outgoing; Sun, 10 May 1998 17:40:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA05957 for ; Sun, 10 May 1998 17:39:59 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yYgDS-0003VC-00; Sun, 10 May 1998 17:13:14 -0700 Date: Sun, 10 May 1998 17:13:01 -0700 (PDT) From: Tom To: Hans Huebner cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Is anybody working on the tape driver? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 11 May 1998, Hans Huebner wrote: > The current progress state of the tape driver seems to be hibernating, > similar to the changer driver nobody seems to have cared adding Both of these things are going to be retired, and replaced with the new CAM stuff. You should look over the CAM docs in regards to the new tape and changer stuff. If it doesn't do what you want, you should develop from the CAM SCSI code, not the 2.2.6-stable SCSI code. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 10 18:45:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14295 for freebsd-scsi-outgoing; Sun, 10 May 1998 18:45:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14100 for ; Sun, 10 May 1998 18:43:58 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id TAA15207; Sun, 10 May 1998 19:43:36 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199805110143.TAA15207@panzer.plutotech.com> Subject: Re: Is anybody working on the tape driver? In-Reply-To: from Hans Huebner at "May 11, 98 01:36:36 am" To: hans@artcom.de (Hans Huebner) Date: Sun, 10 May 1998 19:43:36 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hans Huebner wrote... > I'm currently working at the SCSI tape driver (under 2.2.6-RELEASE) > because it seems to lack many features other systems already have. In > particular, I need better fast-locate support and a better device > statistics interface. CAM already has better (well, I think it is) device statistics support. CAM doesn't yet have support for read position/locate, though. > The current progress state of the tape driver seems to be hibernating, > similar to the changer driver nobody seems to have cared adding > functionality for quite a while. On the other hand, recent discussions on > this list indicate that people seem to use FreeBSD for backups, so there > should be some interest in better tape support. The reason the current tape driver has been "hibernating" is because most new work/features have been going into the CAM code that will eventually replace the current SCSI code. > I would want to integrate some of the functionality I currently access > with perl/scsi(8) scripts into the tape driver. This would involve some > structural changes to make MTIOCGET fully work, and also the addition of > one or more additional ioctl's. > > This leaves me with the following questions: Is there anybody else > working on the tape driver who would want to share code and/or > information? Are there any features in the queue waiting to be commited? It would probably be better if you did your work under CAM, if possible. The statistics code is already there, and I just finished porting the last of the userland statistics utilities to the new devstat interface today. Fast locate support would be handy, though. I am also interested to hear your ideas on changing the mt interface. I have made some minor changes in CAM, mostly for better compression support, but I think that code could definitely use a cleanup. In fact, I think mt(1) could really stand to be cleaned up a bit. One place to look for ideas might be the NetBSD tape driver/mt command. They have implemented fast locate support, I think, and their mt doesn't look like the #ifdef mess that ours is. If developing under -current is a problem for you, there will be a 2.2-stable port of CAM coming out shortly. I'm not sure if it'll be exactly concurrent with the next CAM snapshot, but I think it should be close behind. Justin has already committed some code to the 2.2-stable branch that is necessary/helpful for CAM support, and I believe he intends to do both a -current and a -stable snapshot in the next couple of days. If have a machine to spare to run -current and CAM on, feel free to send me private email and I can give you access to the CAM source repository. In any case, I'm certainly interested in your changes, even if you do them under the old SCSI code. (I can port them to CAM...) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 10 23:07:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17531 for freebsd-scsi-outgoing; Sun, 10 May 1998 23:07:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (mothra.kralizec.net.au [203.15.68.22] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17509 for ; Sun, 10 May 1998 23:07:04 -0700 (PDT) (envelope-from andrew@zeta.org.au) Received: from gurney.reilly.home (d84.syd2.zeta.org.au [203.26.11.84]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id QAA10981 for ; Mon, 11 May 1998 16:00:41 +1000 Received: (from andrew@localhost) by gurney.reilly.home (8.8.8/8.8.5) id PAA01593 for freebsd-scsi@FreeBSD.org; Mon, 11 May 1998 15:27:03 +1000 (EST) From: Andrew Reilly Message-Id: <199805110527.PAA01593@gurney.reilly.home> Date: Mon, 11 May 1998 15:27:03 +1000 (EST) Subject: Do 2k sectors work on od in 2.2-STABLE? To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've noticed a bit of ctm traffic updating the SCSI subsystem in 2.2-STABLE recently, so I thought I'd give the 640M media another go in my Fujitsu MO drive. The boot scan says: (FreeBSD 2.2.6-STABLE #0: Mon May 11 09:52:07 EST 1998 root@gurney.reilly.home:/usr/src/sys/compile/GURNEY : ahc0:6:0): "FUJITSU M2513A 1300" type 7 removable SCSI 2 od0(ahc0:6:0): Optical 606MB (310352 2048 byte sectors) od0(ahc0:6:0): with approximate 151 cyls, 64 heads, and 32 sectors/track fdisk od0 says: ******* Working on device /dev/rod0 ******* parameters extracted from in-core disklabel are: cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=151 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 2048 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 1, size 309247 (603 Meg), flag 80 beg: cyl 0/ sector 2/ head 0; end: cyl 150/ sector 32/ head 63 So seemingly something is going on, but disklabel is still my stumbling block: disklabel od0 disklabel: ioctl DIOCGDINFO: Invalid argument disklabel -w -r od0 auto disklabel: ioctl DIOCSDINFO: No space left on device I'm still not 100% clear about slices, so I thought I'd try: disklabel -w -r od0s4 auto disklabel: ioctl DIOCGDINFO: Invalid argument The latter is at least a different error message than I had received earlier, but it still doesn't look like things will fly. ---> Having failed to create a file system, my fall-back position was always going to be to just use these as a SCSI sack of blocks, for backup programs. To my dismay, though, even dd can't talk to it properly. It's pretty obvioius that only 2k transactions work: dd if=/dev/rod0s4 of=/devnull bs=512 count=1 dd: /dev/rod0s4: Input/output error dd if=/dev/rod0s4 of=/devnull bs=1024 count=1 dd: /dev/rod0s4: Input/output error dd if=/dev/rod0s4 of=/devnull bs=2048 count=1 1+0 records in 1+0 records out 2048 bytes transferred in 0.015324 secs (133647 bytes/sec) however dd seems to calculate the device capacity by multiplying the number of blocks available by DEV_BSIZE, and then dividing this by secsiz. Consequently, it seems to only be able to talk to about 150M of the drive: dd if=/dev/rod0s4 of=/dev/null bs=2048 dd: /dev/rod0s4: Input/output error 77311+0 records in 77311+0 records out 158332928 bytes transferred in 207.976010 secs (761304 bytes/sec) Does anyone know why dd is doing this, and what I can do about it? Shouldn't it have been able to read a little over 600000 2k blocks? Thanks in advance for suggestions, -- Andrew "The steady state of disks is full." -- Ken Thompson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon May 11 02:21:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09988 for freebsd-scsi-outgoing; Mon, 11 May 1998 02:21:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA09980 for ; Mon, 11 May 1998 02:21:17 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id CAA27511; Mon, 11 May 1998 02:17:29 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd027508; Mon May 11 09:17:18 1998 Date: Mon, 11 May 1998 02:17:16 -0700 (PDT) From: Julian Elischer To: Tom cc: Hans Huebner , freebsd-scsi@FreeBSD.ORG Subject: Re: Is anybody working on the tape driver? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org However until then you shoud get some milage under the belts of these changes by submitting them... I can review them (I wrote st.c) but I can't test them as i presently don't have a tape drive. julian On Sun, 10 May 1998, Tom wrote: > > On Mon, 11 May 1998, Hans Huebner wrote: > > > The current progress state of the tape driver seems to be hibernating, > > similar to the changer driver nobody seems to have cared adding > > Both of these things are going to be retired, and replaced with the new > CAM stuff. > > You should look over the CAM docs in regards to the new tape and changer > stuff. If it doesn't do what you want, you should develop from the CAM > SCSI code, not the 2.2.6-stable SCSI code. > > Tom > > > 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 May 11 04:16:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA23162 for freebsd-scsi-outgoing; Mon, 11 May 1998 04:16:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA23157 for ; Mon, 11 May 1998 04:16:50 -0700 (PDT) (envelope-from geoffb@demon.net) Received: from office.demon.net (office.demon.net [193.195.224.1]) by internal.mail.demon.net with SMTP id MAA12968; Mon, 11 May 1998 12:18:19 +0100 (BST) Subject: DPT storage manager To: freebsd-scsi@FreeBSD.ORG Date: Mon, 11 May 1998 12:16:50 +0100 (BST) From: Geoff Buckingham X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <894885411.0013755.0@office.demon.net> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Having noticed the beta version of the DPT storage management software for BSDI is infact the SCO binary running under emulation. I was wondering if anyone had tried to get this working under FreeBSD? -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon May 11 09:59:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07853 for freebsd-scsi-outgoing; Mon, 11 May 1998 09:59:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA07839 for ; Mon, 11 May 1998 09:59:47 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yYvVp-00047o-00; Mon, 11 May 1998 09:33:13 -0700 Date: Mon, 11 May 1998 09:33:12 -0700 (PDT) From: Tom To: Geoff Buckingham cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT storage manager In-Reply-To: <894885411.0013755.0@office.demon.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 11 May 1998, Geoff Buckingham wrote: > Having noticed the beta version of the DPT storage management software > for BSDI is infact the SCO binary running under emulation. I was wondering if > anyone had tried to get this working under FreeBSD? Well, the Unix Storage Manager apparently works by reading and writing commands to /dev/dpt If you check the archives, Simon posted a way you could send a command to /dev/dtp, and then use cat to display the result. I don't know if the driver has a complete command interface though. I understand that Simon is working on a native FreeBSD storage manager. DPT has apparently given him the code to do the port. > -- > GeoffB Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon May 11 14:01:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19450 for freebsd-scsi-outgoing; Mon, 11 May 1998 14:01:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from bb.cc.wa.us (bb.cc.wa.us [134.39.181.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19421 for ; Mon, 11 May 1998 14:00:56 -0700 (PDT) (envelope-from chris@bb.cc.wa.us) Received: from localhost (chris@localhost) by bb.cc.wa.us (8.8.7/8.6.9) with SMTP id NAA00393 for ; Mon, 11 May 1998 13:53:34 -0700 (PDT) Date: Mon, 11 May 1998 13:53:33 -0700 (PDT) From: Chris Coleman To: scsi@FreeBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I got a bunch of errors relating to this one, and then when I re-booted, this was the error I got: May 5 11:08:33 aries /kernel: sd0(ahc0:0:0): RECOVERED ERROR info:0x101ea asc:12,1 field replaceable unit: e6 sks:80,21 May 5 11:08:33 aries /kernel: , retries:4 Any ideas what it means. Is this a hardware failure, or a FreeBSD thing. I can dig up more info and send it if need be. I run FreeBSD 2.2-stable, pentium 100, Adaptec 2940W, (Not Ultra) 2 Seagate barracuda drives. 2.1 /4.? G Christopher J. Coleman (whyareyou@lookingforme.com) Computer Support Analyst I (509)-762-6341 FreeBSD Book Project: http://www.vmunix.com/fbsd-book/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon May 11 14:30:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24445 for freebsd-scsi-outgoing; Mon, 11 May 1998 14:30:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24432 for ; Mon, 11 May 1998 14:30:44 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@[209.54.254.2]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id OAA02917; Mon, 11 May 1998 14:32:49 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id OAA04293; Mon, 11 May 1998 14:30:41 -0700 Message-ID: <35576E01.6C2108F1@feral.com> Date: Mon, 11 May 1998 14:30:41 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Chris Coleman CC: scsi@FreeBSD.ORG Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org bird > /etc/LGTOuscsi/ascdcode 12 1 ASC/ASCQ(0x0C/0x01)= If it's happening more than once or twice, you have a disk that may be slowly failing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 07:55:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15075 for freebsd-scsi-outgoing; Tue, 12 May 1998 07:55:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA15066 for ; Tue, 12 May 1998 07:55:47 -0700 (PDT) (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Tue, 12 May 1998 09:54:39 -0500 Message-ID: From: Raul Zighelboim To: "'scsi@freebsd.org'" Subject: DPT driver on 2.2-releng broken Date: Tue, 12 May 1998 09:54:37 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello there; I cvsup-ed from 2.2.6-RELEASE to 2.2-stable.... Before CVSUP-ing, DPT controller was working and stable. After new kernel would not load. I am reinstaling now. Let me know what else will be needed to track the problem. Thanks, ================================================== Raul Zighelboim rzig@verio.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 08:34:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA21115 for freebsd-scsi-outgoing; Tue, 12 May 1998 08:34:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA21109 for ; Tue, 12 May 1998 08:34:34 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id JAA02056; Tue, 12 May 1998 09:30:47 -0600 (MDT) Date: Tue, 12 May 1998 09:30:47 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805121530.JAA02056@narnia.plutotech.com> To: Raul Zighelboim cc: scsi@FreeBSD.ORG Subject: Re: DPT driver on 2.2-releng broken Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Hello there; > > I cvsup-ed from 2.2.6-RELEASE to 2.2-stable.... > Before CVSUP-ing, DPT controller was working and stable. After > new kernel would not load. Would not build? Would not detect the DPT? Would not detect any disk devices? You're being pretty vague here, so it's hard to know which questions to ask. > Let me know what else will be needed to track the problem. You're being pretty vague here, so it's hard to know which questions to ask. My first guess would be that the kernel would not build because you did not rebuild config and reconfig your kernel. > Raul Zighelboim rzig@verio.net -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 09:31:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01334 for freebsd-scsi-outgoing; Tue, 12 May 1998 09:31:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from interlock2.lexmark.com (interlock2.lexmark.com [192.146.101.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA01328 for ; Tue, 12 May 1998 09:31:42 -0700 (PDT) (envelope-from fireston@lexmark.com) Received: by interlock2.lexmark.com id AA24888 (InterLock SMTP Gateway 3.0 for freebsd-scsi@freebsd.org); Tue, 12 May 1998 12:31:30 -0400 Message-Id: <199805121631.AA24888@interlock2.lexmark.com> Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1); Tue, 12 May 1998 12:31:30 -0400 From: Mik Firestone Subject: SCSI timeouts in dataout mode To: freebsd-scsi@FreeBSD.ORG Date: Tue, 12 May 1998 12:31:31 -0400 (EDT) Reply-To: fireston@lexmark.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We are attempting to get an HP Autoraid device running on a FreeBSD 3.0- current box, 31198 snapshot. The HP unit is attached to the machine via an Adaptec 2944 ( that is no typo - it is differential ). There are currently 6 drives in the HP. The HP is further set up such that there are 8 LUNs defined ( the actual sizes do not matter - we have tried many configurations ). The HP unit has two controllers, but the problem appears to be independant of that. On boot, all the LUNs are probed and return the correct information - ie size. fsck works ( trust us, we have done that *many* times ). We can mount the drives, we can delete files, move small files around without problem. As soon as we try writing large ( > 25 Mb ) sequential files ( via bonnie ), we get this: May 12 10:01:28 rocky /kernel: (da3:ahc1:0:0:1): SCB 0x1a - timed out in dataout phase, SCSISIGI == 0xe6 May 12 10:01:28 rocky /kernel: SEQADDR == 0x115 May 12 10:01:28 rocky /kernel: SSTAT1 == 0x13 May 12 10:01:28 rocky /kernel: (da3:ahc1:0:0:1): BDR message in message buffer May 12 10:01:30 rocky /kernel: (da3:ahc1:0:0:1): SCB 0x38 - timed out in dataout phase, SCSISIGI == 0xf6 May 12 10:01:30 rocky /kernel: SEQADDR == 0x115 May 12 10:01:30 rocky /kernel: SSTAT1 == 0x13 May 12 10:01:30 rocky /kernel: (da3:ahc1:0:0:1): no longer in timeout May 12 10:01:30 rocky /kernel: ahc1: Issued Channel A Bus Reset. 67 SCBs aborted May 12 10:01:44 rocky /kernel: (da2:ahc1:0:0:0): SCB 0x1a - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 12 10:01:44 rocky /kernel: SEQADDR == 0x18b May 12 10:01:44 rocky /kernel: SSTAT1 == 0x0 May 12 10:01:44 rocky /kernel: (da2:ahc1:0:0:0): Queuing a BDR SCB May 12 10:01:46 rocky /kernel: (da2:ahc1:0:0:0): SCB 0x1a - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 12 10:01:46 rocky /kernel: SEQADDR == 0x18b May 12 10:01:46 rocky /kernel: SSTAT1 == 0x0 May 12 10:01:46 rocky /kernel: (da2:ahc1:0:0:0): no longer in timeout May 12 10:01:46 rocky /kernel: ahc1: Issued Channel A Bus Reset. 65 SCBs aborted May 12 10:01:50 rocky /kernel: (da2:ahc1:0:0:0): Sending SDTR!! May 12 10:01:50 rocky /kernel: ahc1:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET May 12 10:01:50 rocky /kernel: SAVED_TCL == 0x1, ARG_1 == 0xff, SEQ_FLAGS == 0x20 May 12 10:01:50 rocky /kernel: Bus Device Reset Completed. May 12 10:01:50 rocky /kernel: ahc1: Bus Device Reset delivered. 67 SCBs aborted May 12 10:01:54 rocky /kernel: (da2:ahc1:0:0:0): Sending SDTR!! and so on until either we reboot ( if using CAM code ) or bonnie dies ( using the old SCSI ). We have played with the file size and know that a 10Mb file hasn't caused a problem while a 25Mb file always has. While a valid answer would be to stop running bonnie, the main intended use of this RAID widget will be to write/read large, sequential files. Under the old code, we have not enabled any of the AHC_* options - no tag queuing, no mem io, etc. Under CAM, we have tried adding the device as a rogue with tag queuing disabled and that didn't fix it. The Adaptec card probes as rev 1 so we slowed the data transfer rate down to 10 Mb/sec, but that did not help. Does anybody have an idea as to what we missed? We would really like to get this functional before our boss tells us to use a Sun. Of course, the full dmesg output is available if anybody is that interested as well as our config files. -- Mik Firestone fireston@lexmark.com If ever I become an Evil Overlord: I will not have a daughter. She would be as beautiful as she was evil, but one look at the hero's rugged countenance and she'd betray her own father. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 10:00:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05737 for freebsd-scsi-outgoing; Tue, 12 May 1998 10:00:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05726 for ; Tue, 12 May 1998 10:00:13 -0700 (PDT) (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Tue, 12 May 1998 12:00:05 -0500 Message-ID: From: Raul Zighelboim To: "'Justin T. Gibbs'" Cc: scsi@FreeBSD.ORG Subject: RE: DPT driver on 2.2-releng broken Date: Tue, 12 May 1998 12:00:02 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks; those are the questions I needed ;-) I saved the broken kernel, so... The kernel will compile and install clean. at reboot, it would detect the DPT controller, but would not detect the RAID array. At this point (looking for devices) it will display something similar to: (dpt0:0:0): "UNKNOWN UNKNOWN" type 0 fixed SCSI 2 for every device on the conencted to the controller. ================================================== Raul Zighelboim rzig@verio.net > -----Original Message----- > From: Justin T. Gibbs [SMTP:gibbs@narnia.plutotech.com] > Sent: Tuesday, May 12, 1998 10:31 AM > To: Raul Zighelboim > Cc: scsi@FreeBSD.org > Subject: Re: DPT driver on 2.2-releng broken > > In article > you > wrote: > > > > Hello there; > > > > I cvsup-ed from 2.2.6-RELEASE to 2.2-stable.... > > Before CVSUP-ing, DPT controller was working and stable. After > > new kernel would not load. > > Would not build? Would not detect the DPT? Would not detect any > disk devices? You're being pretty vague here, so it's hard to know > which questions to ask. > > > Let me know what else will be needed to track the problem. > > You're being pretty vague here, so it's hard to know which questions > to ask. My first guess would be that the kernel would not build > because > you did not rebuild config and reconfig your kernel. > > > Raul Zighelboim rzig@verio.net > > -- > Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 10:29:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10802 for freebsd-scsi-outgoing; Tue, 12 May 1998 10:29:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10797 for ; Tue, 12 May 1998 10:29:46 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id LAA02342; Tue, 12 May 1998 11:25:57 -0600 (MDT) Date: Tue, 12 May 1998 11:25:57 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805121725.LAA02342@narnia.plutotech.com> To: fireston@lexmark.com cc: scsi@FreeBSD.ORG Subject: Re: SCSI timeouts in dataout mode Newsgroups: pluto.freebsd.scsi In-Reply-To: <199805121631.AA24888@interlock2.lexmark.com> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199805121631.AA24888@interlock2.lexmark.com> you wrote: > We are attempting to get an HP Autoraid device running on a FreeBSD 3.0- > current box, 31198 snapshot. Okay. > The HP unit is attached to the machine via an Adaptec 2944 ( that is no typo - > it is differential ). There are currently 6 drives in the HP. The HP is > further set up such that there are 8 LUNs defined ( the actual sizes do not > matter - we have tried many configurations ). The HP unit has two > controllers, but the problem appears to be independant of that. > > On boot, all the LUNs are probed and return the correct information - ie > size. fsck works ( trust us, we have done that *many* times ). We > can mount the drives, we can delete files, move small files around > without problem. > > As soon as we try writing large ( > 25 Mb ) sequential files ( via bonnie ), > we get this: > May 12 10:01:28 rocky /kernel: (da3:ahc1:0:0:1): SCB 0x1a - timed out in dataout phase, SCSISIGI == 0xe6 Is this only with multi-lun I/O, or can you make this happen just by touching one lun? Does the HP have a status monitor? If so, what does it say? Do you have access to a SCSI bus analyzer? What does a boot -v tell you about the termination of the card? Does it appear to be correct? Does the behavior change if you use a manual terimination setting in SCSI-Select? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 12 13:08:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14798 for freebsd-scsi-outgoing; Tue, 12 May 1998 13:08:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA14774; Tue, 12 May 1998 13:08:22 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id OAA13153; Tue, 12 May 1998 14:08:15 -0600 (MDT) Message-Id: <199805122008.OAA13153@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Raul Zighelboim cc: scsi@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: DPT driver on 2.2-releng broken In-reply-to: Your message of "Tue, 12 May 1998 12:00:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 May 1998 14:04:29 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Thanks; those are the questions I needed ;-) > > I saved the broken kernel, so... > > The kernel will compile and install clean. at reboot, it would >detect the DPT controller, but would not detect the RAID array. At this >point (looking for devices) it will display something similar to: > >(dpt0:0:0): "UNKNOWN UNKNOWN" type 0 fixed SCSI 2 I just stuck a PM3224 in my machine and saw the same behavior. The easiest way I found to fix the problem was to upgrade -stable to use the driver from -current. This seems to work for me, but I would appreciate it if other would test this out also. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 06:53:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02984 for freebsd-scsi-outgoing; Wed, 13 May 1998 06:53:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from interlock2.lexmark.com (interlock2.lexmark.com [192.146.101.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA02977 for ; Wed, 13 May 1998 06:53:44 -0700 (PDT) (envelope-from fireston@lexmark.com) Received: by interlock2.lexmark.com id AA11660 (InterLock SMTP Gateway 3.0 for freebsd-scsi@freebsd.org); Wed, 13 May 1998 09:53:45 -0400 Message-Id: <199805131353.AA11660@interlock2.lexmark.com> Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1); Wed, 13 May 1998 09:53:45 -0400 From: Mik Firestone Subject: Re: SCSI timeouts in dataout mode In-Reply-To: <199805121725.LAA02342@narnia.plutotech.com> from "Justin T. Gibbs" at "May 12, 98 11:25:57 am" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Wed, 13 May 1998 09:53:45 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG Reply-To: fireston@lexmark.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In a fit of madness, Justin T. Gibbs wrote > > Is this only with multi-lun I/O, or can you make this happen just by > touching one lun? Does the HP have a status monitor? If so, what does > it say? The problem occurs with only one LUN or many. The HP does not have a status monitor that we can access, although the blinky lights on the front of the unit are quite hypnotic. > > Do you have access to a SCSI bus analyzer? Yes, and we will be using that tomorrow (our normal duties have gone ignored a bit too long ). I have no clue how to read the output from such a beast - what should we be looking for? > What does a boot -v tell you about the termination of the card? Does it > appear to be correct? Does the behavior change if you use a manual > terimination setting in SCSI-Select? boot -v was difficult. CAM in verbose mode spits a lot of data out and we kept blowing the 8K buffer. We tweaked the buffer to 16K ( shouldn't that be a config option w/ necessary sysctl parameter? ) and the card is terminated correctly. Changing those parameters seemed to have no effect. I will make the observation that this error is somehow related to the amount of time it takes to write the file. If it takes more then 10 seconds to write, we see this error. We have not yet tried to read a large file to see what problems that can cause. To hazard a guess, I really think this is some strange interaction between the scsi code and the cache on the HP. Either the HP is doing the right kind of handshaking or the FreeBSD box is missing it. But this is only a guess. -- Mik Firestone fireston@lexmark.com If ever I become an Evil Overlord: All naive, busty tavern wenches in my realm will be replaced with surly, world-weary waitresses who will provide no unexpected reinforcement and/or romantic subplot for the hero or his sidekick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 09:00:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA20303 for freebsd-scsi-outgoing; Wed, 13 May 1998 09:00:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from carpe.net (news.carpe.net [194.162.243.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA20298 for ; Wed, 13 May 1998 09:00:18 -0700 (PDT) (envelope-from grefen@carpe.net) Received: from helva.grefen.carpe.net (root@helva.grefen.carpe.net [194.162.243.129]) by carpe.net (8.8.6/8.8.6) with ESMTP id RAA00992; Wed, 13 May 1998 17:59:56 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id RAA04981; Wed, 13 May 1998 17:56:31 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id RAA23011; Wed, 13 May 1998 17:56:28 +0200 (MET DST) To: fireston@lexmark.com Cc: gibbs@narnia.plutotech.com (Justin T. Gibbs), freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI timeouts in dataout mode Reply-To: grefen@carpe.net In-reply-to: Mik Firestone's message <199805131353.AA11660@interlock2.lexmark.com> of Wed, 13 May 98 09:53:45 EDT. References: <199805131353.AA11660@interlock2.lexmark.com> Date: Wed, 13 May 1998 17:56:27 +0200 Message-ID: <23007.895074987@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199805131353.AA11660@interlock2.lexmark.com> Mik Firestone wrote: [...] > > I will make the observation that this error is somehow related to the amount > of time it takes to write the file. If it takes more then 10 seconds to > write, we see this error. We have not yet tried to read a large file to see > what problems that can cause. > > To hazard a guess, I really think this is some strange interaction between th > e > scsi code and the cache on the HP. Either the HP is doing the right kind of > handshaking or the FreeBSD box is missing it. But this is only a guess. If I remember correctly some of those RAID arrays report good-status even if the data is not on disk yet (either assuing or providing UPS for the array). If the Cache is full you have to wait until some space is freeed, so the command 'hangs' and times out. The SCSI analyser would just see an initial transfer and no reconnection. Try increasing the timeout by a factor of 2 or 4 (or 8) and see if it still happens. Or you could try configure the RAID for write-through instead of write-back. But than you should turn on tags ... (I think you can configure some HP-arrays with a terminal over a serial line) > > -- > Mik Firestone fireston@lexmark.com > If ever I become an Evil Overlord: > All naive, busty tavern wenches in my realm will be replaced with surly, > world-weary waitresses who will provide no unexpected reinforcement and/or > romantic subplot for the hero or his sidekick. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Stefan Grefen Am Hummertal 4, 55283 Nierstein, Germany grefen@carpe.net +49 6133 927484 Fax:+49 6133 927486 Idiot, n.: A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. -- Ambrose Bierce, "The Devil's Dictionary" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 09:31:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25291 for freebsd-scsi-outgoing; Wed, 13 May 1998 09:31:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA25253 for ; Wed, 13 May 1998 09:30:58 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA09877; Wed, 13 May 1998 10:30:52 -0600 (MDT) Message-Id: <199805131630.KAA09877@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: fireston@lexmark.com cc: gibbs@plutotech.com (Justin T. Gibbs), freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI timeouts in dataout mode In-reply-to: Your message of "Wed, 13 May 1998 09:53:45 EDT." <199805131416.IAA28579@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 10:27:06 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The problem occurs with only one LUN or many. The HP does not have a status >monitor that we can access, although the blinky lights on the front of the >unit are quite hypnotic. Does it go "ping!"?? 8-) >> Do you have access to a SCSI bus analyzer? > >Yes, and we will be using that tomorrow (our normal duties have gone ignored >a bit too long ). I have no clue how to read the output from such a beast - >what should we be looking for? A transaction that doesn't reconnect, as well as the mean time between request and completions. >I will make the observation that this error is somehow related to the amount >of time it takes to write the file. If it takes more then 10 seconds to >write, we see this error. We have not yet tried to read a large file to see >what problems that can cause. Ahh. This is a big clue. Depending on how the array performs write caching, it may well be that we are hitting it with so many transactions that the cache isn't draining fast enough for them to complete within the 10 second window. 10 seconds seem like an eternity to me, but I suppose if you hit the array with 64 64k transactions to a RAID5 array, it performs write back caching meaning that you can have 64 "completed transactions" waiting in cache flush at the same time you have 64 "pending transactions" it could be awhile before there is cache space to service the new guys. You might want to bump up the timeout. Look for DA_DEFAULT_TIMEOUT in sys/cam/scsi/scsi_da.c. You may also want to increase the frequency of ordered tagged transactions as this will impose a touch of write ordering so the array doesn't starve "expensive writes" into causing a timeout. See DA_ORDEREDTAG_INTERVAL in scsi_da.c. >To hazard a guess, I really think this is some strange interaction between the >scsi code and the cache on the HP. Either the HP is doing the right kind of >handshaking or the FreeBSD box is missing it. But this is only a guess. It's probably not a protocol error at all. The timeout is somewhat arbitrary, but as it is difficult to ask the device "hey are you still working on this?" you have to draw the line somewhere. Perhaps we should choose a larger timeout value by default? >-- >Mik Firestone fireston@lexmark.com >If ever I become an Evil Overlord: >All naive, busty tavern wenches in my realm will be replaced with surly, >world-weary waitresses who will provide no unexpected reinforcement and/or >romantic subplot for the hero or his sidekick. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 12:37:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29581 for freebsd-scsi-outgoing; Wed, 13 May 1998 12:37:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from interlock2.lexmark.com (interlock2.lexmark.com [192.146.101.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA29560 for ; Wed, 13 May 1998 12:37:34 -0700 (PDT) (envelope-from fireston@lexmark.com) Received: by interlock2.lexmark.com id AA01770 (InterLock SMTP Gateway 3.0 for freebsd-scsi@freebsd.org); Wed, 13 May 1998 15:37:30 -0400 Message-Id: <199805131937.AA01770@interlock2.lexmark.com> Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1); Wed, 13 May 1998 15:37:30 -0400 From: Mik Firestone Subject: Re: SCSI timeouts in dataout mode In-Reply-To: <199805131630.KAA09877@pluto.plutotech.com> from "Justin T. Gibbs" at "May 13, 98 10:27:06 am" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Wed, 13 May 1998 15:37:30 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG (SCSI FreeBSD) Reply-To: fireston@lexmark.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How bizarre, how bizarre. We tried many things, including the hacks to scsi_da.c as suggested. No help there. Having reached the point of pure perversity, we by chance turned the Disconnect option off in the Adaptec BIOS. And things started working and working well - we bonnie'd a 512MB file without a problem. Why? -- Mik Firestone fireston@lexmark.com If ever I become an Evil Overlord: My legions of terror will have helmets with clear plexiglass visors, not face-concealing ones. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 12:40:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00258 for freebsd-scsi-outgoing; Wed, 13 May 1998 12:40:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA00253 for ; Wed, 13 May 1998 12:40:25 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA19928; Wed, 13 May 1998 13:40:20 -0600 (MDT) Message-Id: <199805131940.NAA19928@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: fireston@lexmark.com cc: gibbs@plutotech.com (Justin T. Gibbs), freebsd-scsi@FreeBSD.ORG (SCSI FreeBSD) Subject: Re: SCSI timeouts in dataout mode In-reply-to: Your message of "Wed, 13 May 1998 15:37:30 EDT." <199805131937.AA01770@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 13:36:34 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >How bizarre, how bizarre. > >We tried many things, including the hacks to scsi_da.c as suggested. No help >there. > >Having reached the point of pure perversity, we by chance turned the >Disconnect option off in the Adaptec BIOS. And things started working and >working well - we bonnie'd a 512MB file without a problem. > >Why? Because you effectively prevented the Adaptec from using tagged queuing. Look at your dmesg output. It won't report "Tagged Queuing Device" for your array. Can you send me a SCSI bus trace? CAM will really pound that array, and it wouldn't be the first time that FreeBSD exposed bugs in an array. >-- >Mik Firestone fireston@lexmark.com >If ever I become an Evil Overlord: >My legions of terror will have helmets with clear plexiglass visors, not >face-concealing ones. > -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 22:12:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA08208 for freebsd-scsi-outgoing; Wed, 13 May 1998 22:12:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA08193 for ; Wed, 13 May 1998 22:12:51 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id XAA13306 for ; Wed, 13 May 1998 23:12:53 -0600 (MDT) Message-Id: <199805140512.XAA13306@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: scsi@FreeBSD.ORG Subject: Quantum Atlas II warning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 23:08:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you happen to be running any Atlas II drives with a frimware level below LYK8, you'd be well advised to upgrade your firmware. We saw some really nasty behavior on one of our machines here where, after a QUEUE FULL condition, the drive would simply never reconnect for any pending transactions. In CAM, the recovery code was able to bring the drive back to life by issuing a BUS DEVICE RESET, but I don't know that the older aic7xxx and NCR drivers would fair as well. After upgrading to LYK8 (from LXY4), this particular QUEUE FULL issue was resolved. Supposedly LYK8 was released specificly to deal with QUEUE FULL problems. The drive will still return QUEUE FULL for temporary write cache full conditions, but at least now it doesn't occasionally lose it's brain after doing so. YYMV. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 22:48:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12336 for freebsd-scsi-outgoing; Wed, 13 May 1998 22:48:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from thing.dyn.ml.org (dyn2-tnt2-171.detroit.mi.ameritech.net [206.141.229.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12324 for ; Wed, 13 May 1998 22:48:50 -0700 (PDT) (envelope-from mcdougall@ameritech.net) Received: from ameritech.net (user1@bsdx [192.168.1.2]) by thing.dyn.ml.org (8.8.8/8.8.7) with ESMTP id BAA03653; Thu, 14 May 1998 01:48:35 -0400 (EDT) (envelope-from mcdougall@ameritech.net) Message-ID: <355A85B1.D154423D@ameritech.net> Date: Thu, 14 May 1998 01:48:33 -0400 From: Adam McDougall Reply-To: mcdougall@ameritech.net X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: scsi@FreeBSD.ORG Subject: Re: Quantum Atlas II warning References: <199805140512.XAA13306@pluto.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin T. Gibbs wrote: > If you happen to be running any Atlas II drives with a frimware level below > LYK8, you'd be well advised to upgrade your firmware. We saw some really > nasty behavior on one of our machines here where, after a QUEUE FULL > condition, the drive would simply never reconnect for any pending > transactions. In CAM, the recovery code was able to bring the drive back > to life by issuing a BUS DEVICE RESET, but I don't know that the older > aic7xxx and NCR drivers would fair as well. After upgrading to LYK8 (from > LXY4), this particular QUEUE FULL issue was resolved. Supposedly LYK8 was > released specificly to deal with QUEUE FULL problems. The drive will > still return QUEUE FULL for temporary write cache full conditions, but at > least now it doesn't occasionally lose it's brain after doing so. YYMV. > > -- > Justin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message *concerned atlas II owner voice* Hi, I have one, any idea if mine is in need of update? and if so, how would I? Thanks. sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 8682MB (17781008 512 byte sectors) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 13 22:59:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13735 for freebsd-scsi-outgoing; Wed, 13 May 1998 22:59:48 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13728 for ; Wed, 13 May 1998 22:59:46 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id XAA14762; Wed, 13 May 1998 23:59:47 -0600 (MDT) Message-Id: <199805140559.XAA14762@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: mcdougall@ameritech.net cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Quantum Atlas II warning In-reply-to: Your message of "Thu, 14 May 1998 01:48:33 EDT." <355A85B1.D154423D@ameritech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 23:55:33 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > *concerned atlas II owner voice* Hi, I have one, any idea if mine is in need >of update? and if so, how would I? Thanks. >sd0 at scbus0 target 0 lun 0 >sd0: type 0 fixed SCSI 2 >sd0: Direct-Access 8682MB (17781008 512 byte sectors) My understanding is that LY** firmware is of a later revision than LX** firmware, so you should probably see if your drive will accept the LYK8 firmware. If the electronics are too old, the drive will reject the new firmware without any consequence. The LYK8 firmware can be obtained from quantum's ftp site: ftp://ftp.quantum.com/Firmware/Atlas-II/LYK8/QSHR_LDR.EXE #Upgrade utility ftp://ftp.quantum.com/Firmware/Atlas-II/LYK8/D5GNLYK8.FUP #2gig drives ftp://ftp.quantum.com/Firmware/Atlas-II/LYK8/DAGNLYK8.FUP #4gig drives ftp://ftp.quantum.com/Firmware/Atlas-II/LYK8/DKGNLYK8.FUP #9gig drives I know the DAGNLYK8.FUP is for the 4 gigs, but I'm going off of memory for the other two. The update utility can extract the model number information from the FUP file with the appropriate command. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 14 00:01:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA21744 for freebsd-scsi-outgoing; Thu, 14 May 1998 00:01:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA21730 for ; Thu, 14 May 1998 00:01:11 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA20131; Thu, 14 May 1998 00:00:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd020128; Thu May 14 07:00:21 1998 Date: Thu, 14 May 1998 00:00:18 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: Quantum Atlas II warning In-Reply-To: <199805140512.XAA13306@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org how old are these drives/firmware revisions? are we talking about new or old drives? On Wed, 13 May 1998, Justin T. Gibbs wrote: > If you happen to be running any Atlas II drives with a frimware level below > LYK8, you'd be well advised to upgrade your firmware. We saw some really > nasty behavior on one of our machines here where, after a QUEUE FULL > condition, the drive would simply never reconnect for any pending > transactions. In CAM, the recovery code was able to bring the drive back > to life by issuing a BUS DEVICE RESET, but I don't know that the older > aic7xxx and NCR drivers would fair as well. After upgrading to LYK8 (from > LXY4), this particular QUEUE FULL issue was resolved. Supposedly LYK8 was > released specificly to deal with QUEUE FULL problems. The drive will > still return QUEUE FULL for temporary write cache full conditions, but at > least now it doesn't occasionally lose it's brain after doing so. YYMV. > > -- > Justin > > > > 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 May 14 11:12:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15650 for freebsd-scsi-outgoing; Thu, 14 May 1998 11:12:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from TomQNX.tomqnx.com (ott-pm6-22.comnet.ca [206.75.140.182]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15475 for ; Thu, 14 May 1998 11:12:02 -0700 (PDT) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0ya2T5-00087bC; Thu, 14 May 1998 14:10:59 -0400 (EDT) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: SCSI probe failed (fwd) To: scsi@FreeBSD.ORG Date: Thu, 14 May 1998 14:10:59 -0400 (EDT) Cc: tom@tomqnx.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Forwarded message from Tom Torrance at home Root ----- >From 'FreeBSD.ORG!owner-freebsd-hackers' Thu May 14 14:06:10 1998 Return-Path: Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0ya2OP-00087cC; Thu, 14 May 1998 14:06:09 -0400 (EDT) Sender: FreeBSD.ORG!owner-freebsd-hackers Received: from sarip.sol.net (mail@sarip.sol.net [169.207.30.120]) by deathstar.comnet.ca (8.8.7/8.8.7) with ESMTP id MAA05368 for ; Thu, 14 May 1998 12:58:16 -0400 (EDT) Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by sarip.sol.net (8.8.8/8.8.8/SNNS-1.02) with ESMTP id LAA28837; Thu, 14 May 1998 11:55:33 -0500 (CDT) Received: from localhost (daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA11707; Thu, 14 May 1998 07:51:26 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: by hub.freebsd.org (bulk_mailer v1.6); Thu, 14 May 1998 07:49:48 -0700 Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA11252 for freebsd-hackers-outgoing; Thu, 14 May 1998 07:49:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TomQNX.tomqnx.com (ott-pm6-01.comnet.ca [206.75.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA11222 for ; Thu, 14 May 1998 07:49:40 -0700 (PDT) (envelope-from root@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0yZzJH-00087aC; Thu, 14 May 1998 10:48:39 -0400 (EDT) Message-Id: From: root@tomqnx.com (Tom Torrance at home Root) Subject: SCSI probe failed To: hackers@FreeBSD.ORG Date: Thu, 14 May 1998 10:48:39 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.ORG I did a cvsup, make world, then compiled a new kernel yesterday. This is the result: Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.6-STABLE #0: Thu May 14 08:28:47 EDT 1998 tom@tomqnx.tomqnx.com:/ccd/src/sys/compile/TOMQNX CPU: i486 DX2 (486-class CPU) Origin = "GenuineIntel" Id = 0x435 Stepping=5 Features=0x3 real memory = 83886080 (81920K bytes) avail memory = 79577088 (77712K bytes) eisa0: Probing for devices on the EISA bus ahc0: at 0x2c00-0x2cff eisa0:2 attach failed ------------- added comment----------------- This should have read: eisa0: Probing for devices on the EISA bus ahc0: at 0x2c00-0x2cff irq 15 on eisa0 slot 2 ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=7, 4 SCBs ahc0 waiting for scsi devices to settle ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "QUANTUM FIREBALL_TM3200S 300N" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 3067MB (6281856 512 byte sectors) sd0(ahc0:0:0): with 6810 cyls, 5 heads, and an average 184 sectors/track (ahc0:1:0): "HP 2213A C938" type 0 fixed SCSI 1 sd1(ahc0:1:0): Direct-Access 633MB (1296512 512 byte sectors) sd1(ahc0:1:0): with 1457 cyls, 16 heads, and an average 55 sectors/track (ahc0:2:0): "HP 2213A C938" type 0 fixed SCSI 1 sd2(ahc0:2:0): Direct-Access 633MB (1296512 512 byte sectors) sd2(ahc0:2:0): with 1457 cyls, 16 heads, and an average 55 sectors/track (ahc0:3:0): "HP 2213A C938" type 0 fixed SCSI 1 sd3(ahc0:3:0): Direct-Access 633MB (1296512 512 byte sectors) sd3(ahc0:3:0): with 1457 cyls, 16 heads, and an average 55 sectors/track (ahc0:6:0): "HP T4000s 1.07" type 1 removable SCSI 2 st0(ahc0:6:0): Sequential-Access density code 0x0, drive empty --------------End of added comment--------------- Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> pca0 on motherboard pca0: PC speaker audio driver sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 at 0x278-0x27f on isa psm0 at 0x60-0x64 irq 12 on motherboard psm0: model Generic PS/2 mouse, device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff on isa wdc0: unit 0 (wd0): , multi-block-64 wd0: 504MB (1032192 sectors), 1024 cyls, 16 heads, 63 S/T, 512 B/S wt0 at 0x300-0x301 irq 5 drq 1 on isa wt0: type 1 3C5x9 board(s) on ISA found at 0x210 ep0 at 0x210-0x21f irq 11 on isa ep0: aui/bnc[*BNC*] address 00:60:8c:de:bf:e1 joy0 at 0x201 on isa joy0: joystick npx0 msize 81920 on motherboard npx0: INT 16 interface ccd0: Concatenated disk driver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ----- End of forwarded message from Tom Torrance at home Root ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 14 12:47:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29471 for freebsd-scsi-outgoing; Thu, 14 May 1998 12:47:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29463 for ; Thu, 14 May 1998 12:47:40 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id NAA19612; Thu, 14 May 1998 13:42:05 -0600 (MDT) Date: Thu, 14 May 1998 13:42:05 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805141942.NAA19612@narnia.plutotech.com> To: freebsd@tomqnx.com (Tom Torrance) cc: scsi@FreeBSD.ORG Subject: Re: SCSI probe failed (fwd) Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > I did a cvsup, make world, then compiled a new kernel yesterday. > This is the result: > > Copyright (c) 1992-1998 FreeBSD Inc. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > > FreeBSD 2.2.6-STABLE #0: Thu May 14 08:28:47 EDT 1998 > tom@tomqnx.tomqnx.com:/ccd/src/sys/compile/TOMQNX > CPU: i486 DX2 (486-class CPU) > Origin = "GenuineIntel" Id = 0x435 Stepping=5 > Features=0x3 > real memory = 83886080 (81920K bytes) > avail memory = 79577088 (77712K bytes) > eisa0: > Probing for devices on the EISA bus > ahc0: at 0x2c00-0x2cff > eisa0:2 attach failed Can you try this patch? -- Justin Index: eisaconf.c =================================================================== RCS file: /usr/cvs/src/sys/i386/eisa/eisaconf.c,v retrieving revision 1.23.2.3 diff -c -r1.23.2.3 eisaconf.c *** eisaconf.c 1998/05/06 18:58:49 1.23.2.3 --- eisaconf.c 1998/05/14 19:39:51 *************** *** 429,434 **** --- 429,435 ---- return (result); } update_intr_masks(); + cur_irq->idesc = (void *)1; splx(s); break; } *************** *** 460,465 **** --- 461,469 ---- cur_irq = TAILQ_FIRST(&e_dev->ioconf.irqs); while (cur_irq != NULL) { if (cur_irq->irq_no == irq) { + struct irq_node *next_irq; + + next_irq = TAILQ_NEXT(cur_irq, links); if (cur_irq->idesc != NULL) { int s; *************** *** 467,476 **** INTRDIS ((1ul<ioconf.irqs, cur_irq, links); result = 0; } else { cur_irq = TAILQ_NEXT(cur_irq, links); --- 471,482 ---- INTRDIS ((1ul<idesc = NULL; splx(s); } TAILQ_REMOVE(&e_dev->ioconf.irqs, cur_irq, links); + free(cur_irq, M_DEVBUF); + cur_irq = next_irq; result = 0; } else { cur_irq = TAILQ_NEXT(cur_irq, links); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 14 13:08:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03102 for freebsd-scsi-outgoing; Thu, 14 May 1998 13:08:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03084 for ; Thu, 14 May 1998 13:08:27 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id OAA17028 for ; Thu, 14 May 1998 14:08:27 -0600 (MDT) Message-Id: <199805142008.OAA17028@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: scsi@FreeBSD.ORG Subject: 980513 CAM snapshot available. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 May 1998 14:04:14 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The snapshot is available from: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam or ftp://ftp.kdm.org/pub/FreeBSD/cam Please read the README before attempting to install. The device statistics portion of the 2.2-stable snapshot has not been thoroughly tested yet, so I would appreciate feedback on iostat/systat/ vmstat functionality under 2.2. Changes for the 980513 Snapshot: - Added support for -stable, funded by the HotMail folks. - The systat and vmstat programs have been converted to use the device stat code. - The wd, scd, wfd, and fd drivers have been converted to the devstat system so they properly show up in iostat/systat/vmstat displays, thanks to Mike Smith. - The Media Changer driver (ch) has been added. - CD Changer support now ensures that all transactions, even the read capacity performed during the probe stage, go through the changer scheduler. In the past, read capacity commands would go out to all disks at once causing many changes to get very upset. - Fixed a few bugs in the Adaptec, BusLogic, and AdvanSys drivers having to do with error recovery. Memory mapped I/O is now disabled in teh BusLogic driver as it doesn't seem to be properly supported in the hardware. - If a device is spun up, it's inquiry and serial number data are now refreshed. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 06:02:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19401 for freebsd-scsi-outgoing; Fri, 15 May 1998 06:02:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA19394 for ; Fri, 15 May 1998 06:02:50 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id JAA11307 for ; Fri, 15 May 1998 09:02:52 -0400 (EDT) Date: Fri, 15 May 1998 09:02:52 -0400 (EDT) From: The Hermit Hacker To: scsi@FreeBSD.ORG Subject: CAM driver confirmations... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Morning... I'm just working on getting my server upgraded to CAM, and just want to confirm a couple of things. First off, the server I'm working on is 2500km away, and I've got a 'serial console' working on it, but I'd like to try and avoid as many problems as possible :) I seem to recall someone mentioning that I don't *have* to change my 'sd' devices to 'da' devices right off to use this? Mainly, I'd like to be able to backtrack very quickly if I have to, so changing /etc/fstab makes me a little nervous until I know this isn't going to cause smoke to come pouring out of the system :( Is this, in fact, safe to do? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 08:03:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09094 for freebsd-scsi-outgoing; Fri, 15 May 1998 08:03:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA09089 for ; Fri, 15 May 1998 08:03:13 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id IAA22953; Fri, 15 May 1998 08:58:52 -0600 (MDT) Date: Fri, 15 May 1998 08:58:52 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805151458.IAA22953@narnia.plutotech.com> To: The Hermit Hacker cc: scsi@FreeBSD.ORG Subject: Re: CAM driver confirmations... Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Morning... > > I'm just working on getting my server upgraded to CAM, and just > want to confirm a couple of things. > > First off, the server I'm working on is 2500km away, and I've got > a 'serial console' working on it, but I'd like to try and avoid as many > problems as possible :) > > I seem to recall someone mentioning that I don't *have* to change > my 'sd' devices to 'da' devices right off to use this? Mainly, I'd like > to be able to backtrack very quickly if I have to, so changing /etc/fstab > makes me a little nervous until I know this isn't going to cause smoke to > come pouring out of the system :( > > Is this, in fact, safe to do? The major and minor numbers for the sd and da devices are the same. By changing the fstab entries, all you are doing is making the system consistent in referencing devices named "da" by /dev entries named "da". To the kernel, everything is just major and minor number, so it doesn't care what you name your device entries. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 08:11:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10146 for freebsd-scsi-outgoing; Fri, 15 May 1998 08:11:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from burka.carrier.kiev.ua (archer@burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA09925; Fri, 15 May 1998 08:10:12 -0700 (PDT) (envelope-from archer@burka.carrier.kiev.ua) Received: (from archer@localhost) by burka.carrier.kiev.ua (8.8.8/8.Who.Cares) id SAA26970 for ; Fri, 15 May 1998 18:08:54 +0300 (EEST) Message-ID: <19980515180853.H4812@burka.carrier.kiev.ua> Date: Fri, 15 May 1998 18:08:54 +0300 From: Alexander Litvin To: gibbs@plutotech.com Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: 980513 CAM snapshot available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.11i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199805142008.OAA17031@pluto.plutotech.com> you wrote: > ------- Blind-Carbon-Copy > X-Mailer: exmh version 2.0.1 12/23/97 > To: scsi@FreeBSD.org > Subject: 980513 CAM snapshot available. > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Date: Thu, 14 May 1998 14:04:14 -0600 > From: "Justin T. Gibbs" > The snapshot is available from: > ftp://ftp.FreeBSD.org/pub/FreeBSD/cam > or > ftp://ftp.kdm.org/pub/FreeBSD/cam > Please read the README before attempting to install. > The device statistics portion of the 2.2-stable snapshot has not been > thoroughly tested yet, so I would appreciate feedback on iostat/systat/ > vmstat functionality under 2.2. > Changes for the 980513 Snapshot: > > - Added support for -stable, funded by the HotMail folks. Sorry for bothering you, but during attempt to make a CAM kernel on STABLE I got (when doing 'make depend' in /sys/compile/${MYKERNEL}): cc: ../../pci/ahc_pci.c: No such file or directory There isn't really /usr/src/sys/pci/ahc_pci.c neither in STABLE nor in CAM patch for stable, though it is mentioned in /usr/src/sys/conf/files (added there by CAM patch). > - -- > Justin Alexander Litvin --- If today is the first day of the rest of your life, what the hell was yesterday? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 09:41:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24174 for freebsd-scsi-outgoing; Fri, 15 May 1998 09:41:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24155 for ; Fri, 15 May 1998 09:41:15 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA06267; Fri, 15 May 1998 10:40:41 -0600 (MDT) Message-Id: <199805151640.KAA06267@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Alexander Litvin cc: gibbs@plutotech.com, scsi@FreeBSD.ORG Subject: Re: 980513 CAM snapshot available In-reply-to: Your message of "Fri, 15 May 1998 18:08:54 +0300." <19980515180853.H4812@burka.carrier.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 1998 10:36:28 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Sorry for bothering you, but during attempt to make a CAM kernel on >STABLE I got (when doing 'make depend' in /sys/compile/${MYKERNEL}): > >cc: ../../pci/ahc_pci.c: No such file or directory > >There isn't really /usr/src/sys/pci/ahc_pci.c neither in STABLE nor in >CAM patch for stable, though it is mentioned in /usr/src/sys/conf/files >(added there by CAM patch). Sorry about that. I seem to have missed it in my patch. I've uploaded the missing file as well as a corrected diff set to ftp.FreeBSD.org and ftp.kdm.org. The diffs for current should not have this problem. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 10:47:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05747 for freebsd-scsi-outgoing; Fri, 15 May 1998 10:47:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05742 for ; Fri, 15 May 1998 10:47:51 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id NAA01208 for ; Fri, 15 May 1998 13:47:49 -0400 (EDT) Date: Fri, 15 May 1998 13:47:49 -0400 (EDT) From: The Hermit Hacker To: scsi@FreeBSD.ORG Subject: Atrocious transfer rates... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi... Well, just plugged in the newest CAM snapshot, got everything compiled and installed, and am getting terrible transfer rates, as far as I can tell...granted, I just might be missing something in my kernel config, but I swear my pre-CAM kernel had better performance, with pretty much no change in settings. By slower, I mean that the VIKING II below, that I ran IOZONE on several times with the older driver, was reporting closer to 11Meg/s... ==================================================================== hub> dmesg | grep da2 da2 at ahc1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI2 device da2: Serial Number PCB=JF60324939 U; HDA=MP62542171 da2: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) (da2:ahc1:0:1:0): tagged openings now 37 (da2:ahc1:0:1:0): tagged openings now 36 Writing the 69 Megabyte file, 'iozone.tmp'...34.046875 seconds Reading the file...39.593750 seconds IOZONE performance measurements: 2125062 bytes/second for writing the file 1827352 bytes/second for reading the file hub# df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da2s1a 992751 461077 452254 50% /usr/local/httpd ====================================================================== da1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number PCB=JF60539596 U; HDA=MP61750113 da1: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) (da1:ahc1:0:0:0): tagged openings now 36 (da1:ahc1:0:0:0): tagged openings now 33 Writing the 62 Megabyte file, 'iozone.tmp'...34.695312 seconds Reading the file...27.132812 seconds IOZONE performance measurements: 1873789 bytes/second for writing the file 2396055 bytes/second for reading the filehub # df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1s1a 992751 572953 340378 63% /news ====================================================================== hub# dmesg | grep da0 da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number 194805310043 da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) (da0:ahc0:0:0:0): tagged openings now 63 Writing the 82 Megabyte file, 'iozone.tmp'...13.632812 seconds Reading the file...15.726562 seconds IOZONE performance measurements: 6307079 bytes/second for writing the file 5467388 bytes/second for reading the filehub # df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1d 1477506 927430 431876 68% /var ======================================================================= hub# dmesg | grep ahc ahc0: rev 0x00 int a irq 10 on pci0.11.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x01 int a irq 11 on pci0.12.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 11:11:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09479 for freebsd-scsi-outgoing; Fri, 15 May 1998 11:11:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09474 for ; Fri, 15 May 1998 11:11:38 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id MAA23536; Fri, 15 May 1998 12:07:21 -0600 (MDT) Date: Fri, 15 May 1998 12:07:21 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805151807.MAA23536@narnia.plutotech.com> To: The Hermit Hacker cc: scsi@FreeBSD.ORG Subject: Re: Atrocious transfer rates... Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi... > > Well, just plugged in the newest CAM snapshot, got everything > compiled and installed, and am getting terrible transfer rates, as far as > I can tell...granted, I just might be missing something in my kernel > config, but I swear my pre-CAM kernel had better performance, with pretty > much no change in settings. > > By slower, I mean that the VIKING II below, that I ran IOZONE on > several times with the older driver, was reporting closer to 11Meg/s... > > ==================================================================== > hub> dmesg | grep da2 > da2 at ahc1 bus 0 target 1 lun 0 > da2: Fixed Direct Access SCSI2 device > da2: Serial Number PCB=JF60324939 U; HDA=MP62542171 > da2: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing First off, upgrade both of your Atlas I drives L915 firmware. It fixes quite a few problems with tagged queuing. > hub# dmesg | grep da0 > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI2 device > da0: Serial Number 194805310043 > da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) > (da0:ahc0:0:0:0): tagged openings now 63 > > Writing the 82 Megabyte file, 'iozone.tmp'...13.632812 seconds > Reading the file...15.726562 seconds > > IOZONE performance measurements: > 6307079 bytes/second for writing the file > 5467388 bytes/second for reading the filehub Hmm. It could be one of a few things. Some drives do not perform well for sequential I/O if the tag count is too high. It seems that they are somehow pre-empted when the new command comes in even though most devices have a separate protocol engine and I/O processor. So, you could try going into sys/cam/cam_xpt.c and lowering the default high tag count to something less than 64. This will likely decrease your non-sequential I/O performance, so be careful how you tune the parameter. Your Viking appears to max out at 63 and the system is saturating the drive with that many transactions active. iostat may give you some interesting information in this area too. The old SCSI driver defaulted to either 4 or 8 tags, whereas CAM will use up to 64 depending on what the drive supports. The other possible cause for a degradation in performance is the CPU cost of performing the bufq_disksort in scsi_da.c. You can easily check this by going into sys/cam/scsi/scsi_da.c and replacing the bufq_disksort call with a call to bufq_insert_tail. It may be that we should only perform the disksort if tagged queuing isn't supported or the tagged count is too low, but I do believe that the additional elevator sort does increase performance for non-sequential I/O when lots of buffers are queued. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 15:31:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA16066 for freebsd-scsi-outgoing; Fri, 15 May 1998 15:31:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA16061 for ; Fri, 15 May 1998 15:31:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@[209.54.254.2]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id PAA07393; Fri, 15 May 1998 15:33:50 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id PAA16794; Fri, 15 May 1998 15:31:52 -0700 Message-ID: <355CC257.4F4AE38D@feral.com> Date: Fri, 15 May 1998 15:31:51 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: scsi@FreeBSD.ORG CC: snively@eng.sun.com Subject: CAM flags && tagging... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I notice there's a flag in the CCB header that enables tag action. I haven't got the SCSI-3 CAM2 spec in front of me, but would it specify (or could we extend) to specify what *kind* of tagging is preferred? I'm sewing up the ISP driver for the FreeBSD/CAM, and now that I'm going to really depend upon CAM_TAG_ACTION_ENABLE as a flag, I'd also like to know whether the caller prefers HEAD OF QUEUE, SIMPLE, or ORDERED. BTW- as a side note- for the Qlogic 2100 and FCP-SCSI, you cannot disable tags (you always have to have *some* tag is what I read in the spec), so that defaults to SIMPLE when tagging is otherwise disabled (Bob- do you want to comment)? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 16:21:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21904 for freebsd-scsi-outgoing; Fri, 15 May 1998 16:21:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21899 for ; Fri, 15 May 1998 16:21:22 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@[209.54.254.2]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id QAA07427; Fri, 15 May 1998 16:23:21 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id QAA16926; Fri, 15 May 1998 16:21:23 -0700 Message-ID: <355CCDF2.7D7AB16F@feral.com> Date: Fri, 15 May 1998 16:21:22 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: scsi@FreeBSD.ORG, snively@eng.sun.com Subject: Re: CAM flags && tagging...-- never mind... References: <355CC257.4F4AE38D@feral.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I found that it already is being defined by drivers (duh...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 16:42:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA25620 for freebsd-scsi-outgoing; Fri, 15 May 1998 16:42:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA25615 for ; Fri, 15 May 1998 16:42:40 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.8/8.8.8) with SMTP id QAA10830; Fri, 15 May 1998 16:42:35 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Date: Fri, 15 May 1998 16:42:35 -0700 (PDT) From: Chris Timmons To: The Hermit Hacker cc: scsi@FreeBSD.ORG Subject: Re: Atrocious transfer rates... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You'll also want to be careful with the L912 firmware on the XP34300W; there are known problems which are fixed in L915 firmware. cvsup.freebsd.org couldn't keep running on those disks until we upgraded the firmware. Search the archives - Justin figured out the problem some time ago. Probably CAM will treat you better than the old code did when the drives flake on you... -Chris On Fri, 15 May 1998, The Hermit Hacker wrote: > > Hi... > > Well, just plugged in the newest CAM snapshot, got everything > compiled and installed, and am getting terrible transfer rates, as far as > I can tell...granted, I just might be missing something in my kernel > config, but I swear my pre-CAM kernel had better performance, with pretty > much no change in settings. > > By slower, I mean that the VIKING II below, that I ran IOZONE on > several times with the older driver, was reporting closer to 11Meg/s... > > ==================================================================== > hub> dmesg | grep da2 > da2 at ahc1 bus 0 target 1 lun 0 > da2: Fixed Direct Access SCSI2 device > da2: Serial Number PCB=JF60324939 U; HDA=MP62542171 > da2: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing > Enabled > da2: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) > (da2:ahc1:0:1:0): tagged openings now 37 > (da2:ahc1:0:1:0): tagged openings now 36 > > Writing the 69 Megabyte file, 'iozone.tmp'...34.046875 seconds > Reading the file...39.593750 seconds > > IOZONE performance measurements: > 2125062 bytes/second for writing the file > 1827352 bytes/second for reading the file > hub# df . > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da2s1a 992751 461077 452254 50% /usr/local/httpd > ====================================================================== > > da1 at ahc1 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI2 device > da1: Serial Number PCB=JF60539596 U; HDA=MP61750113 > da1: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing > Enabled > da1: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) > (da1:ahc1:0:0:0): tagged openings now 36 > (da1:ahc1:0:0:0): tagged openings now 33 > > Writing the 62 Megabyte file, 'iozone.tmp'...34.695312 seconds > Reading the file...27.132812 seconds > > IOZONE performance measurements: > 1873789 bytes/second for writing the file > 2396055 bytes/second for reading the filehub > # df . > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da1s1a 992751 572953 340378 63% /news > ====================================================================== > > hub# dmesg | grep da0 > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI2 device > da0: Serial Number 194805310043 > da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) > (da0:ahc0:0:0:0): tagged openings now 63 > > Writing the 82 Megabyte file, 'iozone.tmp'...13.632812 seconds > Reading the file...15.726562 seconds > > IOZONE performance measurements: > 6307079 bytes/second for writing the file > 5467388 bytes/second for reading the filehub > # df . > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1d 1477506 927430 431876 68% /var > ======================================================================= > > hub# dmesg | grep ahc > ahc0: rev 0x00 int a irq 10 on pci0.11.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc1: rev 0x01 int a irq 11 on pci0.12.0 > ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > > > 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 Fri May 15 17:14:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA02104 for freebsd-scsi-outgoing; Fri, 15 May 1998 17:14:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02099 for ; Fri, 15 May 1998 17:14:18 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id SAA24354; Fri, 15 May 1998 18:10:06 -0600 (MDT) Date: Fri, 15 May 1998 18:10:06 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805160010.SAA24354@narnia.plutotech.com> To: Matthew Jacob cc: scsi@FreeBSD.ORG Subject: Re: CAM flags && tagging... Newsgroups: pluto.freebsd.scsi In-Reply-To: <355CC257.4F4AE38D@feral.com> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <355CC257.4F4AE38D@feral.com> you wrote: > I notice there's a flag in the CCB header that enables tag > action. I haven't got the SCSI-3 CAM2 spec in front of me, > but would it specify (or could we extend) to specify what > *kind* of tagging is preferred? I'm sewing up the ISP driver > for the FreeBSD/CAM, and now that I'm going to really depend > upon CAM_TAG_ACTION_ENABLE as a flag, I'd also like to know > whether the caller prefers HEAD OF QUEUE, SIMPLE, or ORDERED. If the CAM_TAG_ACTION_VALID flag is set, then the tag_action field of the CCB is valid. This field indicates the type of tag to send. tag_action will be set to one of the SCSI-II specified tag message values (0x20, 0x21, 0x22). The da driver makes use of this feature to prevent tag starvation and also to convert buffers set with the B_ORDERED flag into ordered tagged transactions. > BTW- as a side note- for the Qlogic 2100 and FCP-SCSI, you > cannot disable tags (you always have to have *some* tag is what > I read in the spec), so that defaults to SIMPLE when tagging > is otherwise disabled (Bob- do you want to comment)? Hmm. I didn't think that tags were mandatory for any SCSI transport. The CAM code currently leaves tags disabled (won't set CAM_TAG_ACTION_VAlID bit) unless the controller indicates that it supports it, we have completed our inquiry fetch and it indicates the end device supports tagged queuing, and the device control page either is not supported or does not have the DQUE bit set. > -matt -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 17:18:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA02450 for freebsd-scsi-outgoing; Fri, 15 May 1998 17:18:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from elvis.mu.org (elvis.mu.org [206.156.231.253]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02445 for ; Fri, 15 May 1998 17:18:31 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: (from paul@localhost) by elvis.mu.org (8.8.8/8.8.8) id TAA02575; Fri, 15 May 1998 19:18:32 -0500 (CDT) (envelope-from paul) Message-ID: <19980515191832.A2506@mu.org> Date: Fri, 15 May 1998 19:18:32 -0500 From: Paul Saab To: freebsd-scsi@FreeBSD.ORG Subject: aborted commands Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, recently I have been having problems with my scsi bus resetting and aborting commands. I have 2 DACS-34330W drives connected internally anda tape connected externally to a 2940UW. The error I got today was this: May 15 19:01:37 elvis /kernel: sd3(ahc1:0:0): ABORTED COMMAND asc:1b,0 Synchronous data transfer error May 15 19:01:37 elvis /kernel: , retries:4 It the disk dying or do I need to look closely at cable length and termination? I have checked termination over and over and it it correct. On the controller I have the bios set for termination automatic if that helps in tracking the problem down. Thanks, paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 17:54:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA07692 for freebsd-scsi-outgoing; Fri, 15 May 1998 17:54:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA07584 for ; Fri, 15 May 1998 17:54:07 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id SAA24446; Fri, 15 May 1998 18:49:54 -0600 (MDT) Date: Fri, 15 May 1998 18:49:54 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805160049.SAA24446@narnia.plutotech.com> To: Paul Saab cc: scsi@FreeBSD.ORG Subject: Re: aborted commands Newsgroups: pluto.freebsd.scsi In-Reply-To: <19980515191832.A2506@mu.org> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980515191832.A2506@mu.org> you wrote: > Hi, > > recently I have been having problems with my scsi bus resetting > and aborting commands. I have 2 DACS-34330W drives connected > internally anda tape connected externally to a 2940UW. > > The error I got today was this: > May 15 19:01:37 elvis /kernel: sd3(ahc1:0:0): ABORTED COMMAND > asc:1b,0 Synchronous data transfer error > May 15 19:01:37 elvis /kernel: , retries:4 This usually means that the req/ack offset was overflowed. This typically happens due to noise on the req/ack line causing either the initiator or target to believe that a byte was acked when it wasn't. > It the disk dying or do I need to look closely at cable length and > termination? I have checked termination over and over and it it > correct. On the controller I have the bios set for termination > automatic if that helps in tracking the problem down. It may be that the automatic termination code is not working properly. Try using a manual termination setting. > Thanks, > > paul -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 15 21:15:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA27291 for freebsd-scsi-outgoing; Fri, 15 May 1998 21:15:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from lupo.thebarn.com (lupo.lcse.umn.edu [128.101.182.105]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA27259 for ; Fri, 15 May 1998 21:15:07 -0700 (PDT) (envelope-from cattelan@lupo.thebarn.com) Received: (from cattelan@localhost) by lupo.thebarn.com (8.8.8/8.8.8) id XAA00396; Fri, 15 May 1998 23:15:17 -0500 (CDT) (envelope-from cattelan) Date: Fri, 15 May 1998 23:15:17 -0500 (CDT) Message-Id: <199805160415.XAA00396@lupo.thebarn.com> From: Russell Cattelan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@FreeBSD.ORG Subject: cam0513 panic at boot. X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org panic: ahc_intr: AWAITING_MSG for an SCB that does not a waiting message mp_lock = 01000001; cpuid = 1; lapic.id = 0100000 Debugger("panic") stoped at _Debugger+0x35: movb $0,_in_Debugger.96 ahc_handle_seqint ahc_intr Xresume16 I haven't spent much time trying to track the problem down, but I thought I would mention it. I'm guessing that it has something to do with the dual processors. Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #2: Thu May 14 14:09:41 CDT 1998 cattelan@lupo:/export/purple/SRC-3.0/sys/compile/LUPO Timecounter "i8254" frequency 1193182 Hz cost 2520 ns CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 62156800 (60700K bytes) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 -- Russell Cattelan cattelan@thebarn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 16 18:34:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA09267 for freebsd-scsi-outgoing; Sat, 16 May 1998 18:34:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from thelab.hub.org (tc-64.acadiau.ca [131.162.2.164]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09259; Sat, 16 May 1998 18:34:53 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.8.8/8.8.2) with SMTP id SAA00664; Sat, 16 May 1998 18:34:49 -0300 (ADT) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 16 May 1998 18:34:49 -0300 (ADT) From: The Hermit Hacker To: freebsd-current@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: Bad shutdown... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is based on a 0515 kernel, with the CAM snapshot applied to it... hub# halt syncing disks... 3 3 done panic: lockmgr: pid 318, not exclusive lock holder 1 unlocking dumping to dev 20401, offset 262144 dump Aborting dump due to I/O error. status == 0x200, scsi status == 0x0 i/o error Automatic reboot in 15 seconds - press a key on the console to abort Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 16 19:34:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA15907 for freebsd-scsi-outgoing; Sat, 16 May 1998 19:34:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from thelab.hub.org (tc-19.acadiau.ca [131.162.2.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA15888 for ; Sat, 16 May 1998 19:34:05 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.8.8/8.8.2) with SMTP id TAA01443; Sat, 16 May 1998 19:33:06 -0300 (ADT) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 16 May 1998 19:33:06 -0300 (ADT) From: The Hermit Hacker To: Chris Timmons cc: scsi@FreeBSD.ORG Subject: Re: Atrocious transfer rates... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 May 1998, Chris Timmons wrote: > > You'll also want to be careful with the L912 firmware on the XP34300W; > there are known problems which are fixed in L915 firmware. > cvsup.freebsd.org couldn't keep running on those disks until we upgraded > the firmware. Search the archives - Justin figured out the problem some > time ago. > > Probably CAM will treat you better than the old code did when the drives > flake on you... Well, got hit by a system hang again tonight :( Running a 0514/15 kernel, with the latest CAM snapshot... I hit AltaVista and did a search for XP34300W, and am curious about one of the threads I found in the aic7xxx mailing list that was found in the search. Basically, it describes the problem (under Linux, at least) as: "The LED-light indicating SCSI activity on the computer front shines constantly for about 30 secs, goes out for about 10 secs after which the SCSI bus appears to be reset (my CD ROM-drive is activated momentarily) and I can use the system again. " - http://confused.ume.maine.edu/~aic7xxx/aic7xxx/4988.html Now, I'm curious, but assuming that this is a bus hang (even with the CAM drivers in place), why isn't the system able to recover? The report is based on the same drive as mine, including Rev... Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: Quantum Model: XP34300W Rev: L912 Type: Direct-Access ANSI SCSI revision: 02 One of the answers in this thread talks about 'SCSI bus reset-requests' (http://confused.ume.maine.edu/~aic7xxx/aic7xxx/5000.html) ... assuming we do this, why doesn't it work? Hell, I'd rather have my system timeout and reboot when this happens then to just sit there doing nothing :( Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 16 23:56:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13659 for freebsd-scsi-outgoing; Sat, 16 May 1998 23:56:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13653 for ; Sat, 16 May 1998 23:56:38 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id AAA01616; Sun, 17 May 1998 00:52:14 -0600 (MDT) Date: Sun, 17 May 1998 00:52:14 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199805170652.AAA01616@narnia.plutotech.com> To: The Hermit Hacker cc: scsi@FreeBSD.ORG Subject: Re: Atrocious transfer rates... Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Basically, it describes the problem (under Linux, at least) as: > > "The LED-light indicating SCSI activity on the computer front shines > constantly for about 30 secs, goes out for about 10 secs after which the > SCSI bus appears to be reset (my CD ROM-drive is activated momentarily) > and I can use the system again. " > - http://confused.ume.maine.edu/~aic7xxx/aic7xxx/4988.html > > Now, I'm curious, but assuming that this is a bus hang (even with > the CAM drivers in place), why isn't the system able to recover? > > The report is based on the same drive as mine, including Rev... The bug in the L912 firmware causes the drive to spaz and never release the bus. If the drive wedges and fails to respond to a bus reset, there isn't anything that the OS can do other than possibly ask the operator to power cycle the device. Upgrade your firmware already... -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message