From owner-freebsd-scsi Sun Oct 13 22:48:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B441037B401; Sun, 13 Oct 2002 22:48:23 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21CE743EB1; Sun, 13 Oct 2002 22:48:22 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g9E5lxKD075219; Sun, 13 Oct 2002 23:47:59 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g9E5lwxc075218; Sun, 13 Oct 2002 23:47:58 -0600 (MDT) (envelope-from ken) Date: Sun, 13 Oct 2002 23:47:58 -0600 From: "Kenneth D. Merry" To: Bruce Evans Cc: "M. Warner Losh" , johan@FreeBSD.ORG, nsayer@quack.kfu.com, freebsd-scsi@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open() Message-ID: <20021013234758.A75169@panzer.kdm.org> References: <20020829223429.A62384@panzer.kdm.org> <20021001142616.M354-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021001142616.M354-100000@gamplex.bde.org>; from bde@zeta.org.au on Tue, Oct 01, 2002 at 03:06:21PM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 01, 2002 at 15:06:21 +1000, Bruce Evans wrote: > [Lot's quoted since this is a reply to old mail] > > Long ago, on Thu, 29 Aug 2002, Kenneth D. Merry wrote: > > > On Thu, Aug 29, 2002 at 21:52:27 +1000, Bruce Evans wrote: > > > On Mon, 26 Aug 2002, Kenneth D. Merry wrote: > > > > On Sun, Aug 25, 2002 at 17:07:32 +1000, Bruce Evans wrote: > > > > > > > > [...] > > > > > There is a CDIOCCLOSE which seems to be supported by acd and by some > > > > > unmaintained cdrom drivers by not by the scsi cdrom driver. > > > > > > > > Ahh, I missed that. > > > > > [...] > > > > Well, here is a first pass at it. Let me know what you think. > > I finally configured atapicam so that I could test this, but I seem to have > deleted the mail with the patch. Please resend the patch. Sorry for the delay on this end, lots going on. I've attached the patch. I think it still works as before, but I've discovered that Poul-Henning broke disklabel support in the cd(4) driver. I need to talk to him about that. (It isn't directly related to whether this patch is the right thing to do.) > > > > > dsopen() has similar issues. It attempts to read MBRs and disk labels > > > > > and can probably return EIO for read errors when there is no media or > > > > > bad media. One reason why the fd driver doesn't use the slice layer > > > > > is that I never got this working well enough for floppies. It is hard > > > > > to issue formatting ioctls when the open fails because the MBR is > > > > > unreadable. > > > > > > > > FWIW, if the slice code is setup to attempt to read labels off the disk, but > > > > there is no media in the drive (i.e. sector size and sectors per unit are > > > > 0, or it could be because p_size for the first partition is 0), it panics. > > > > (DSO_COMPATLABEL is set, and DSO_NOLABELS is cleared) > > > > > > > > If the slice code is setup not to attempt to read labels off the disk, it > > > > doesn't panic at least. > > > > > > Hmm. I never committed the patch that makes dsopen() return EINVAL > > > if the sector size is 0. (We added an early return if the sector size > > > is not a multiple of DEV_BSIZE some time ago.) But these early returns > > > of an error are not quite right, since they cause the whole open() to > > > fail, but dsopen() is really only about the slice+label parts of opening > > > disks. > > This is now "fixed" in diskopen() by dividing by the sector size before > dsopen() can validate it. When the drive tray is open, division by 0 > only happens if there have been no previous successful opens, so something > is apparently remembering the label for too long. These are some of the > bugs introduced in subr_disk.c rev.1.59 (the others are lossage of passing > the d_type, d_typename, d_packname and d_flags fields from the driver). Yeah, it's unfortunate we can't pass that information now. > > > > Behavior of things like dd(1) is different, obviously, because it no longer > > > > fails in open() with an empty drive. e.g., new behavior is: > > > > > > > > ================ > > > > {nargothrond:/usr/home/ken:2:0} dd if=/dev/cd0c of=/dev/null bs=2k > > > > dd: /dev/cd0c: Device not configured > > > > 0+0 records in > > > > 0+0 records out > > > > 0 bytes transferred in 0.004522 secs (0 bytes/sec) > > > > ================ > > > > > > Shouldn't the error be EIO now? Hmm, POSIX just made ENXIO standard for > > > read(). From POSIX.1-2001-draft7: > > > > > > % 36723 [ENXIO] A request was made of a nonexistent device, or the request was outside the > > > % 36724 capabilities of the device. > > > % ... > > > % 36845 * The [ENXIO] optional error condition is added. > > > > > > Similarly for write(). ENXIO is very reasonable for i/o an open device that > > > went away. > > > > Cool. The error returned will be whatever the error recovery code decides > > is appropriate. In the case of "medium not present" errors, that means > > ENXIO. (see asc_table[] in sys/cam/scsi/scsi_all.c ) > > So this thread is now about errors in read(): acd gives EIO but cd will give > ENXIO. (cd still gives ENXIO in open() in -current.) I suppose so. The cd(4) driver will give varying errors, depending on what the drive tells it. If it's a "medium not present" type error, it'll return ENXIO. Otherwise, it could be most anything. > > > > cdcontrol seems to get a better idea of what is going on when open() fails: > > > > > > > > ================ > > > > {gondolin:/usr/home/ken:7:1} cdcontrol > > > > cdcontrol: no CD device name specified, defaulting to /dev/cd0c > > > > Compact Disc Control utility, version 2.0 > > > > Type `?' for command list > > > > > > > > cdcontrol> info > > > > cdcontrol: no disc in drive /dev/cd0c > > > > cdcontrol> quit > > > > ================ > > > > > > It also prints this if there is no cd0 device but there is a cd0c inode :-). > > > The comment before it prints this says that ENXIO is overloaded, but here > > > it is too overloaded to work. > > > > Ahh. > > > > > > When the ioctl fails instead of the open, it isn't quite as clear about > > > > what is going on: > > > > > > > > ================ > > > > {nargothrond:/usr/home/ken:3:1} cdcontrol > > > > cdcontrol: no CD device name specified, defaulting to /dev/cd0c > > > > Compact Disc Control utility, version 2.0 > > > > Type `?' for command list > > > > > > > > cdcontrol> info > > > > cdcontrol: getting toc header: Device not configured > > > > cdcontrol: Device not configured > > > > cdcontrol> quit > > > > ================ > > > > > > Here it could more reasonably say that there is no disc in the drive, since > > > there must at least have been a drive to get that far. Similarly for ENXIO > > > in read(). > > > > Does the acd(4) driver produce the same behavior? > > acd gives almost the second behaviour: a read error "getting toc header". > The read error is EIO instead of ENXIO. Ahh. > > > I didn't try the patch or look closely at it. My only SCSI cdrom is 8 years > > > old hasn't been able to read disks for 2-3 years. > > > > Bummer. I think you should be able to try it out with an ATAPI CDROM > > drive if you turn on options ATAPICAM. (FWIW, I don't have any ATA or > > ATAPI peripherals at home, except for two disk drives that are mostly dead > > and haven't been turned on in 7 or 8 years. :) > > Thanks for the hint. BTW, atapicam has the interesting property of living > alongside atapi. I get devices afd0/da0, cd0/acd0 and cd1/acd1 here. They > all work, at least non-concurrently. I haven't tried concurrent opens and > expect they would cause problems, especially for writable devices. Yeah, we don't have locking there. There also isn't any locking to prevent concurrent access via multiple CAM peripheral drivers. (e.g. you can talk to your CDROM drive via pass(4) and cd(4) at the same time. Many time this is a feature.) Ken -- Kenneth Merry ken@kdm.org --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scsi_cd.c.20021013" ==== //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c#27 - /usr/home/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c ==== --- /tmp/tmp.291.0 Sun Oct 13 23:30:46 2002 +++ /usr/home/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c Sun Oct 13 23:29:48 2002 @@ -1,6 +1,6 @@ /* * Copyright (c) 1997 Justin T. Gibbs. - * Copyright (c) 1997, 1998, 1999, 2000, 2001 Kenneth D. Merry. + * Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002 Kenneth D. Merry. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -94,7 +94,8 @@ CD_FLAG_CHANGER = 0x040, CD_FLAG_ACTIVE = 0x080, CD_FLAG_SCHED_ON_COMP = 0x100, - CD_FLAG_RETRY_UA = 0x200 + CD_FLAG_RETRY_UA = 0x200, + CD_FLAG_VALID_MEDIA = 0x400 } cd_flags; typedef enum { @@ -205,7 +206,8 @@ static int cderror(union ccb *ccb, u_int32_t cam_flags, u_int32_t sense_flags); static void cdprevent(struct cam_periph *periph, int action); -static int cdsize(dev_t dev, u_int32_t *size); +static int cdcheckmedia(struct cam_periph *periph); +static int cdsize(struct cam_periph *periph, u_int32_t *size); static int cdreadtoc(struct cam_periph *periph, u_int32_t mode, u_int32_t start, struct cd_toc_entry *data, u_int32_t len); @@ -229,7 +231,7 @@ u_int32_t etrack, u_int32_t eindex); static int cdpause(struct cam_periph *periph, u_int32_t go); static int cdstopunit(struct cam_periph *periph, u_int32_t eject); -static int cdstartunit(struct cam_periph *periph); +static int cdstartunit(struct cam_periph *periph, int load); static int cdreportkey(struct cam_periph *periph, struct dvd_authinfo *authinfo); static int cdsendkey(struct cam_periph *periph, @@ -874,7 +876,6 @@ { struct cam_periph *periph; struct cd_softc *softc; - u_int32_t size; int error; int s; @@ -903,26 +904,12 @@ if (cam_periph_acquire(periph) != CAM_REQ_CMP) return(ENXIO); - cdprevent(periph, PR_PREVENT); - - /* find out the size */ - if ((error = cdsize(dev, &size)) != 0) { - cdprevent(periph, PR_ALLOW); - cam_periph_unlock(periph); - cam_periph_release(periph); - return(error); - } - /* - * We unconditionally (re)set the blocksize each time the - * CD device is opened. This is because the CD can change, - * and therefore the blocksize might change. - * XXX problems here if some slice or partition is still - * open with the old size? + * Check for media, and set the appropriate flags. We don't bail + * if we don't have media, but then we don't allow anything but the + * CDIOCEJECT/CDIOCCLOSE ioctls if there is no media. */ - if ((softc->device_stats.flags & DEVSTAT_BS_UNAVAILABLE) != 0) - softc->device_stats.flags &= ~DEVSTAT_BS_UNAVAILABLE; - softc->device_stats.block_size = softc->params.blksize; + cdcheckmedia(periph); cam_periph_unlock(periph); @@ -1332,6 +1319,21 @@ } /* + * If we don't have valid media, look for it before trying to + * schedule the I/O. + */ + if ((softc->flags & CD_FLAG_VALID_MEDIA) == 0) { + int error; + + error = cdcheckmedia(periph); + if (error != 0) { + splx(s); + biofinish(bp, NULL, error); + return; + } + } + + /* * Place it in the queue of disk activities for this disk */ bioqdisksort(&softc->bio_queue, bp); @@ -1768,6 +1770,20 @@ if (error != 0) return(error); + /* + * If we don't have media loaded, check for it. If we still don't + * have media loaded, we can only do a load or eject. + */ + if (((softc->flags & CD_FLAG_VALID_MEDIA) == 0) + && ((cmd != CDIOCCLOSE) + && (cmd != CDIOCEJECT))) { + error = cdcheckmedia(periph); + if (error != 0) { + cam_periph_unlock(periph); + return (error); + } + } + switch (cmd) { case DIOCGMEDIASIZE: @@ -2353,7 +2369,10 @@ error = cdpause(periph, 0); break; case CDIOCSTART: - error = cdstartunit(periph); + error = cdstartunit(periph, 0); + break; + case CDIOCCLOSE: + error = cdstartunit(periph, 1); break; case CDIOCSTOP: error = cdstopunit(periph, 0); @@ -2457,18 +2476,49 @@ } static int -cdsize(dev_t dev, u_int32_t *size) +cdcheckmedia(struct cam_periph *periph) +{ + struct cd_softc *softc; + u_int32_t size; + int error; + + softc = (struct cd_softc *)periph->softc; + + cdprevent(periph, PR_PREVENT); + + /* + * Get the disc size and block size. If we can't get it, we don't + * have media, most likely. So we clear the valid media flag. + */ + if ((error = cdsize(periph, &size)) != 0) { + softc->flags &= ~CD_FLAG_VALID_MEDIA; + cdprevent(periph, PR_ALLOW); + return (error); + } else + softc->flags |= CD_FLAG_VALID_MEDIA; + + /* + * We unconditionally (re)set the blocksize each time the + * CD device is opened. This is because the CD can change, + * and therefore the blocksize might change. + * XXX problems here if some slice or partition is still + * open with the old size? + */ + if ((softc->device_stats.flags & DEVSTAT_BS_UNAVAILABLE) != 0) + softc->device_stats.flags &= ~DEVSTAT_BS_UNAVAILABLE; + softc->device_stats.block_size = softc->params.blksize; + + return (error); +} + +static int +cdsize(struct cam_periph *periph, u_int32_t *size) { - struct cam_periph *periph; struct cd_softc *softc; union ccb *ccb; struct scsi_read_capacity_data *rcap_buf; int error; - periph = (struct cam_periph *)dev->si_drv1; - if (periph == NULL) - return (ENXIO); - CAM_DEBUG(periph->path, CAM_DEBUG_TRACE, ("entering cdsize\n")); softc = (struct cd_softc *)periph->softc; @@ -2900,7 +2950,7 @@ } static int -cdstartunit(struct cam_periph *periph) +cdstartunit(struct cam_periph *periph, int load) { union ccb *ccb; int error; @@ -2914,7 +2964,7 @@ /* cbfcnp */ cddone, /* tag_action */ MSG_SIMPLE_Q_TAG, /* start */ TRUE, - /* load_eject */ FALSE, + /* load_eject */ load, /* immediate */ FALSE, /* sense_len */ SSD_FULL_SIZE, /* timeout */ 50000); --mYCpIKhGyMATD0i+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 13 23:25:44 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C018737B401 for ; Sun, 13 Oct 2002 23:25:43 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E25043EB7 for ; Sun, 13 Oct 2002 23:25:43 -0700 (PDT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 68717AE1EE; Sun, 13 Oct 2002 23:25:43 -0700 (PDT) Date: Sun, 13 Oct 2002 23:25:43 -0700 From: Paul Saab To: Jimmy Olgeni Cc: freebsd-scsi@FreeBSD.org Subject: Re: ciss driver & external devices Message-ID: <20021014062543.GA34874@elvis.mu.org> References: <20021011221215.N5811-100000@olgeni.olgeni> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011221215.N5811-100000@olgeni.olgeni> User-Agent: Mutt/1.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jimmy Olgeni (olgeni@uli.it) wrote: > Does anybody know if the ciss driver supports the internal DAT / CDRW > devices, on a SmartRaid 5i (DL380G2)? I'm stuck with some devices that > are seen by the scsi bios but ignored by the driver :( It does not support it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 14 11: 2: 7 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A6B537B401 for ; Mon, 14 Oct 2002 11:02:06 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3BD43EAF for ; Mon, 14 Oct 2002 11:02:05 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9EI25Co093986 for ; Mon, 14 Oct 2002 11:02:05 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9EI25Wv093980 for scsi@freebsd.org; Mon, 14 Oct 2002 11:02:05 -0700 (PDT) Date: Mon, 14 Oct 2002 11:02:05 -0700 (PDT) Message-Id: <200210141802.g9EI25Wv093980@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: scsi@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2002/02/18] kern/35082 scsi IBM Intellistation will not reboot with S 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/10/31] misc/31670 scsi Wide-Ultra 10k SCSI 3 drive is not recogn 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1999/12/21] kern/15608 scsi acd0 / cd0 give inconsistent errors on em a [2002/04/07] kern/36845 scsi Add ioctls CDRIOCREADSPEED/WRITESPEED to 2 problems total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 14 11:32: 7 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BB437B401 for ; Mon, 14 Oct 2002 11:32:07 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EF4A543EB2 for ; Mon, 14 Oct 2002 11:32:06 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 33561 invoked by uid 1000); 14 Oct 2002 18:32:07 -0000 Date: Mon, 14 Oct 2002 11:32:07 -0700 (PDT) From: Nate Lawson To: scsi@freebsd.org Subject: kern/36845: Add ioctls CDRIOCREADSPEED/WRITESPEED Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Does anyone have problems with these patches? I'm willing to do a little cleanup on them and commit if not. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 14 12: 1: 4 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDF737B401 for ; Mon, 14 Oct 2002 12:01:03 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6A5343E65 for ; Mon, 14 Oct 2002 12:01:02 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g9EJ11KD078973; Mon, 14 Oct 2002 13:01:01 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g9EJ11Pu078972; Mon, 14 Oct 2002 13:01:01 -0600 (MDT) (envelope-from ken) Date: Mon, 14 Oct 2002 13:01:01 -0600 From: "Kenneth D. Merry" To: Nate Lawson Cc: scsi@FreeBSD.ORG Subject: Re: kern/36845: Add ioctls CDRIOCREADSPEED/WRITESPEED Message-ID: <20021014130101.A78944@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nate@root.org on Mon, Oct 14, 2002 at 11:32:07AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Oct 14, 2002 at 11:32:07 -0700, Nate Lawson wrote: > Does anyone have problems with these patches? I'm willing to do a little > cleanup on them and commit if not. They seem okay, but there are several problems with the patches that need to be fixed before this can be committed. I'll send you separate mail with a list of problems. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 14 12:45:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29D6637B401 for ; Mon, 14 Oct 2002 12:45:29 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C07543E97 for ; Mon, 14 Oct 2002 12:45:23 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.6/8.12.6) with ESMTP id g9EJjKFu028841; Mon, 14 Oct 2002 21:45:20 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.6/8.12.6/Submit) id g9EJjJtM028840; Mon, 14 Oct 2002 21:45:19 +0200 (CEST) Date: Mon, 14 Oct 2002 21:45:19 +0200 From: Wilko Bulte To: "Kenneth D. Merry" Cc: Kurt Seel , freebsd-scsi Subject: Re: pioneer DRM-600 problem Message-ID: <20021014214519.F28379@freebie.xs4all.nl> References: <3D5B17A4.D2862CA6@utcorp.com> <3DA5CF94.6260EC18@utcorp.com> <20021010133409.A50349@panzer.kdm.org> <3DA60E3F.BA8A597A@utcorp.com> <20021010223418.A53347@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021010223418.A53347@panzer.kdm.org>; from ken@kdm.org on Thu, Oct 10, 2002 at 10:34:18PM -0600 X-OS: FreeBSD 4.7-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Oct 10, 2002 at 10:34:18PM -0600, Kenneth D. Merry wrote: > On Thu, Oct 10, 2002 at 19:33:19 -0400, Kurt Seel wrote: > > "Kenneth D. Merry" wrote: > > > On Thu, Oct 10, 2002 at 15:05:56 -0400, Kurt Seel wrote: > > > > Kurt Seel wrote: > > > > > > > > > > I am using FBSD 4.5-stable. > > > > > I have a Pioneer DRM-600. I passes the self diagnostic, > > > > > where to de-cable the unit, power off, flip switches 6 & > > > > > 8, then power on. It goes through loading each disc, then > > > > > ejects. Just like it should. > > > > > When the machine boots, scans the unis and finds 6 cd devs, > > > > > dmesg output at the end of this message. > > > > > But when I type : > > > > > chio status > > > > > I get this : > > > > > chio: /dev/ch0: open: Device not configured > > > > > So I made sure the devices were make, e.g. > > > > > cd /dev; ./MAKEDEV cd5; ./MAKEDEV ch0 > > > > > And : > > > > > mount -t cd9660 /dev/cd0c /conf/tmpmnt > > > > > Gives me : > > > > > cd9660: /dev/cd0c: Device busy > > > > > > > > > > I have tried it with evey permutation of option switches, > > > > > e.g. parity on, parity off ... no dice. > > > > > Is there any hope for this unit? I'de really like to put > > > > > 6 CD's of mp3'ed music on a (atapi) cdrom booted (if you > > > > > look at the dmesg you'll see root is cd9660:acd0c - could > > > > > this be causing the problem?) network music server. > > > > > > > > > > > > > I could not get this machine rebuilt, so I moved the device > > > > to another machine. Which 'sees' the device : > > > > > > > > New /dev > camcontrol devlist > > > > at scbus0 target 0 lun 0 (cd2,pass2) > > > > at scbus0 target 1 lun 0 (pass0,cd0) > > > > at scbus0 target 6 lun 0 (cd1,pass1) > > > > at scbus0 target 6 lun 1 (cd3,pass3) > > > > at scbus0 target 6 lun 2 (cd4,pass4) > > > > at scbus0 target 6 lun 3 (cd5,pass5) > > > > at scbus0 target 6 lun 4 (cd6,pass6) > > > > at scbus0 target 6 lun 5 (cd7,pass7) > > > > at scbus0 target 6 lun 6 (pass8) > > > > at scbus0 target 6 lun 7 (pass9) > > > > > > > > I have gotten musid CD's to play via xmcd (from ports) but I get > > > > the same 'device busy' when I try to mount (a data cd, storebought > > > > or home brew): > > > > > > > > New /root > mount -t cd9660 /dev/cd1c /cdrom1 > > > > cd9660: /dev/cd1c: Device busy > > > > > > Does anything show up in the dmesg? If nothing shows up in the dmesg, try > > > booting with -v. > > > > A hell of alot, actually. I am not really sure what caused > > what so I'll include the whole mess: > > > > cd1 at ahc0 bus 0 target 6 lun 0 > > cd1: Removable CD-ROM SCSI-CCS device > > cd1: 3.300MB/s transfers > > cd1: cd present [321646 x 2048 byte records] > > cd2 at ahc0 bus 0 target 0 lun 0 > > cd2: Removable CD-ROM SCSI-2 device > > cd2: 10.000MB/s transfers (10.000MHz, offset 15) > > cd2: cd present [261209 x 2048 byte records] > > cd3 at ahc0 bus 0 target 6 lun 1 > > cd3: Removable CD-ROM SCSI-CCS device > > cd3: 3.300MB/s transfers > > cd3: cd present [91407 x 2048 byte records] > > cd4 at ahc0 bus 0 target 6 lun 2 > > cd4: Removable CD-ROM SCSI-CCS device > > cd4: 3.300MB/s transfers > > cd4: cd present [332253 x 2048 byte records] > > cd5 at ahc0 bus 0 target 6 lun 3 > > cd5: Removable CD-ROM SCSI-CCS device > > cd5: 3.300MB/s transfers > > cd5: cd present [214998 x 2048 byte records] > > cd6 at ahc0 bus 0 target 6 lun 4 > > cd6: Removable CD-ROM SCSI-CCS device > > cd6: 3.300MB/s transfers > > cd6: cd present [331220 x 2048 byte records] > > cd7 at ahc0 bus 0 target 6 lun 5 > > cd7: Removable CD-ROM SCSI-CCS device > > cd7: 3.300MB/s transfers > > cd7: cd present [326103 x 2048 byte records] > > (cd8:ahc0:0:6:6): READ CD RECORDED CAPACITY. CDB: 25 c0 0 0 0 0 0 0 0 0 > > (cd8:ahc0:0:6:6): ILLEGAL REQUEST asc:25,0 > > (cd8:ahc0:0:6:6): Logical unit not supported > > (cd8:ahc0:0:6:6): fatal error, failed to attach to device > > (cd8:ahc0:0:6:6): lost device > > (cd8:ahc0:0:6:6): removing device entry > > (cd9:ahc0:0:6:7): READ CD RECORDED CAPACITY. CDB: 25 e0 0 0 0 0 0 0 0 0 > > (cd9:ahc0:0:6:7): ILLEGAL REQUEST asc:25,0 > > (cd9:ahc0:0:6:7): Logical unit not supported > > (cd9:ahc0:0:6:7): fatal error, failed to attach to device > > (cd9:ahc0:0:6:7): lost device > > (cd9:ahc0:0:6:7): removing device entry > > Even though the device only has 6 LUNs, it looks like it is responding on > two more for some reason, and then rightly complaining when we try to > issue a read capacity to those LUNs. IIRC I had such a drive some EONs ago. You might want to check the mailing list archives, as I've been having some fun using it. At some point I got a newer firmware ROM, flipped a dipswitch and things worked a lot better afterwards. As I said, IIRC, and I no longer own this beast. -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte wilko@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 14 14:59:12 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1F3A37B401 for ; Mon, 14 Oct 2002 14:59:11 -0700 (PDT) Received: from volcano.planet.it (volcano.planet.it [212.110.160.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8327743E97 for ; Mon, 14 Oct 2002 14:59:10 -0700 (PDT) (envelope-from olgeni@uli.it) Received: from olgeni.olgeni (ppp-141.dial6.ctonet.it [212.110.181.141]) by volcano.planet.it (Postfix) with ESMTP id 4490811F9CF; Mon, 14 Oct 2002 23:59:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by olgeni.olgeni (8.12.6/8.12.5) with ESMTP id g9ELwIK3005540; Mon, 14 Oct 2002 23:58:18 +0200 (CEST) (envelope-from olgeni@uli.it) Date: Mon, 14 Oct 2002 23:58:18 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Paul Saab Cc: freebsd-scsi@FreeBSD.org Subject: Re: ciss driver & external devices In-Reply-To: <20021014062543.GA34874@elvis.mu.org> Message-ID: <20021014234818.G2698-100000@olgeni.olgeni> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 13 Oct 2002, Paul Saab wrote: > It does not support it. It looks like the "Hardware Notes" need a yellow sticky note then :o( (obviously these expensive DL380s do not have a spare scsi port with a proper controller... at least the xSeries had an adaptec so you could bypass the bogus serveraid card :)) -- jimmy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 15 8:44: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5A5F37B401 for ; Tue, 15 Oct 2002 08:43:59 -0700 (PDT) Received: from mail0.lsil.com (mail0.lsil.com [147.145.40.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5210A43EA3 for ; Tue, 15 Oct 2002 08:43:59 -0700 (PDT) (envelope-from vanis@lsil.com) Received: from mhbs.lsil.com (mhbs.lsil.com [147.145.31.100]) by mail0.lsil.com (8.12.4/8.12.4) with ESMTP id g9FFKmLZ018481 for ; Tue, 15 Oct 2002 08:43:55 -0700 (PDT) Received: from atl1.se.lsil.com by mhbs.lsil.com with ESMTP for freebsd-scsi@FreeBSD.ORG; Tue, 15 Oct 2002 08:43:53 -0700 Received: by EXA-ATLANTA.se.lsil.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 11:43:52 -0400 Message-Id: <0E3FA95632D6D047BA649F95DAB60E57015291DC@EXA-ATLANTA.se.lsil.com> From: "Sabapathi, Vanishree" To: freebsd-scsi@FreeBSD.ORG Subject: How To invoke device_shutdown/ device_resume method for testing Date: Tue, 15 Oct 2002 11:43:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, In my driver the device_shutdown/device_resume methods need to be tested. What should I do to get these methods invoked. Is there any utility like camcontrol which would allow me to test these methods. I understand that the device suspends and resumes for power saving(correct me if I am wrong)..but how do i get to invoke these methods for testing purpose. I tried using the KDE preferences to set the Energy option. There I set the time to suspend to 5 minutes. But KDE gives an error saying "KLibrary: The library kcm_energy does not offer an init_kcm_energy function".. -Vani. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 16 16: 3:52 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A398437B401 for ; Wed, 16 Oct 2002 16:03:51 -0700 (PDT) Received: from boromir.vpop.net (dns1.vpop.net [207.178.248.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6502343E6A for ; Wed, 16 Oct 2002 16:03:51 -0700 (PDT) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [65.103.33.41]) by boromir.vpop.net (Postfix) with ESMTP id EDB8D3A5E1D for ; Wed, 16 Oct 2002 16:03:42 -0700 (PDT) Message-ID: <3DADF082.4050809@vpop.net> Date: Wed, 16 Oct 2002 18:04:34 -0500 From: Matthew Reimer Organization: VPOP Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 To: scsi@freebsd.org Subject: Do Adaptec 2110S/2120S/2200S work on -stable? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Subject says it all: do Adaptec 2110S/2120S/2200S work on -stable? And does raidutil work with it? Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 16 17:17:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D41AB37B401 for ; Wed, 16 Oct 2002 17:17:30 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 731EF43E4A for ; Wed, 16 Oct 2002 17:17:19 -0700 (PDT) (envelope-from Scott_Long@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11] (may be forged)) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g9H0H0w08072; Wed, 16 Oct 2002 17:17:00 -0700 (PDT) Received: from OTCEXC01.otc.adaptec.com (otcexc01.otc.adaptec.com [10.12.1.27]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08039; Wed, 16 Oct 2002 17:16:59 -0700 (PDT) Received: by otcexc01.otc.adaptec.com with Internet Mail Service (5.5.2653.19) id <4TQCW8RR>; Wed, 16 Oct 2002 20:16:58 -0400 Message-ID: <6100BCEB85F8E244959C756C04E0EDD161CAC7@otcexc01.otc.adaptec.com> From: "Long, Scott" To: "'Matthew Reimer'" , scsi@FreeBSD.ORG Subject: RE: Do Adaptec 2110S/2120S/2200S work on -stable? Date: Wed, 16 Oct 2002 20:16:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Subject says it all: do Adaptec 2110S/2120S/2200S work on > -stable? And > does raidutil work with it? > > Matt Answers: yes yes yes depends The 2110S works with the asr driver. raidutil will work with it (I haven't tried raidutil in a couple of years, YMMV). You might even be able to dig up Storage Manager, Storage Manager Classic, and/or Storage Manager Pro for it. Of the three, I recommend the last one, but then I was the one who wrote all of the Unix/FreeBSD support for it. The 2120S and 2200S will work with the aac driver. None of the apps I mentioned earlier will work with these. However, you can download 'aaccli' for FreeBSD which will work. I have no idea if it will be shipped in box with these cards, but you can download the version that shipped with the 5400S adapter from the Adaptec website. However, there are some compatibility issues with using the older aaccli and the newer cards. Until I get a chance to do the required engineering on it, I'd recommend trying the Linux version of this. You'll need to make sure that the AAC_COMPAT_LINUX option is defined when you build the driver in order for this to work. Out of the choices, I'd highly recommend the 2120 or 2200. They both support Ultra320, and the firmware/raid architecture is far superior to the asr group of cards. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 16 19: 3:48 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68D5937B401 for ; Wed, 16 Oct 2002 19:03:47 -0700 (PDT) Received: from boromir.vpop.net (dns1.vpop.net [207.178.248.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 275FC43E75 for ; Wed, 16 Oct 2002 19:03:47 -0700 (PDT) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [65.103.33.41]) by boromir.vpop.net (Postfix) with ESMTP id A10D93A600B; Wed, 16 Oct 2002 19:03:38 -0700 (PDT) Message-ID: <3DAE1AB1.9060508@vpop.net> Date: Wed, 16 Oct 2002 21:04:33 -0500 From: Matthew Reimer Organization: VPOP Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Long, Scott" Cc: scsi@FreeBSD.ORG Subject: Re: Do Adaptec 2110S/2120S/2200S work on -stable? References: <6100BCEB85F8E244959C756C04E0EDD161CAC7@otcexc01.otc.adaptec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Long, Scott wrote: >>Subject says it all: do Adaptec 2110S/2120S/2200S work on >>-stable? And >>does raidutil work with it? >> >>Matt > > > Answers: > yes > yes > yes > depends [snip] Thanks Scott, that's exactly what I needed to know. I'm recommending the 2120 to my boss. Thanks too for all your work maintaining these drivers! Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 17 21:55:44 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B350137B401 for ; Thu, 17 Oct 2002 21:55:42 -0700 (PDT) Received: from mail.atomz.com (MAIL.ATOMZ.COM [64.41.153.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CA2043EA3 for ; Thu, 17 Oct 2002 21:55:42 -0700 (PDT) (envelope-from mike@atomz.com) Received: from mthompson.atomz.com (12-236-204-132.client.attbi.com [12.236.204.132]) by mail.atomz.com (Postfix) with ESMTP id 6ECD03073B for ; Thu, 17 Oct 2002 22:03:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20021017212517.00aede00@pop.atomz.com> X-Sender: mike@pop.atomz.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Oct 2002 21:55:40 -0700 To: freebsd-scsi@FreeBSD.ORG From: Mike Thompson Subject: Multiple FreeBSD SCSI Hosts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm interested in setting up two FreeBSD systems in a very simple clustering type configuration around centralized external SCSI storage devices for hardware redundancy. The specific configuration I'm thinking about is shown in the simple diagram below: +-----------+ +----------+ +-----------+ | FreeBSD | | | | FreeBSD | | Host 1 | | External | | Host 2 | | (primary) | | SCSI | |(secondary)| | | |RAID/DRIVE| | | | SCSI r/w | | | | SCSI r/o | +-----+-----+ +---+--+---+ +-----+-----+ | | | | +---------------+ +---------------+ There would be two FreeBSD systems with the primary server mounting the external SCSI storage read-write and the secondary server mounting the external SCSI storage read-only. Each server would have non-shared /, /usr and /var partitions on local drives. In a fail over situation, I would manually power down the primary server and re-mount the SCSI storage read-write on the secondary server to continue operation. My questions about this are as follows: 1. Do the FreeBSD SCSI drivers support such a configuration by implementing the SCSI RESERVE/RELEASE commands to lock access to the SCSI bus? If so, which drivers for which specific SCSI adapters? 2. Many external raid controllers describe themselves as host dual capability. Is the type of configuration they are describing? 3. Will the secondary server still experience a corrupted file system because of write caching by the primary server? If so, would it be possible to configure the primary server to write through the cache? 4. Are there any FreeBSD specific projects or ports that would make such a dual host SCSI configuration easier to configure or maintain? 5. What am I overlooking in such a configuration? 6. Are there alternatives to this type of scenario that may work better for FreeBSD? 7. Finally, are there resources already on the web that would answer these questions for me? I would be very much interested in hearing if other people have attempted such a configuration with FreeBSD servers and their experience. Also, specific hardware recommendations would be helpful. Thanks, Mike Thompson mike@atomz.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 12:58:11 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6956E37B642 for ; Fri, 18 Oct 2002 12:58:06 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 98B6E43E77 for ; Fri, 18 Oct 2002 12:58:05 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 46857 invoked by uid 1000); 18 Oct 2002 19:58:06 -0000 Date: Fri, 18 Oct 2002 12:58:06 -0700 (PDT) From: Nate Lawson To: Fred Clift Cc: scsi@freebsd.org Subject: Re: umass bus scanning (or perhaps just a general prob with CAM?) In-Reply-To: <20021017153542.I86982-100000@vespa.dmz.orem.verio.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 17 Oct 2002, Fred Clift wrote: > I have a usb mass storage device that supports multiple LUNs. It has two > (mmc) 'drives' that can be mounted. When I insert the device, the usb > subsystem finds the base device, and assigns da1 (da0 exists already) to > the lun0 drive in the device. After a bit of experimentation, it turns > out that if I manually 'camcontrol rescan 1:0:1" that the second drive is > found and I can use it. > > Does the CAM system normally just assume one LUN and not bother looking > for more? is this a problem with just usb devices? I have no > multiple-lun scsi devices to test with... > > It is really not much of an issue now that I know to manually scan for the > device after insertion, but well, enquiring minds want to know! > > Fred > > -- > Fred Clift - fclift@verio.net -- Remember: If brute > force doesn't work, you're just not using enough. This may be a problem with the umass driver or your particular hardware. CAM can and does scan multi-lun hardware. You should try the USB list: --- Mailing list: You can subscribe to the usb-bsd@eleetbsd.org mailing list at the info page at http://lists.inteltec.com/wws/info/usb-bsd The usb-bsd mailing list at eGroups is no longer in use. --- -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 13:20:10 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6D6837B406 for ; Fri, 18 Oct 2002 13:20:07 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23E1F43E9C for ; Fri, 18 Oct 2002 13:20:06 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id WAA15151 for freebsd-scsi@freebsd.org; Fri, 18 Oct 2002 22:20:04 +0200 (CEST) Received: from uriah.heep.sax.de (localhost.heep.sax.de [127.0.0.1]) by uriah.heep.sax.de (8.12.5/8.12.5) with ESMTP id g9IKCHWc059996 for ; Fri, 18 Oct 2002 22:12:17 +0200 (MET DST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.12.5/8.12.5/Submit) id g9IKCHoI059995; Fri, 18 Oct 2002 22:12:17 +0200 (MET DST) (envelope-from j) Date: Fri, 18 Oct 2002 22:12:17 +0200 (MET DST) Message-Id: <200210182012.g9IKCHoI059995@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <4.3.2.7.2.20021017212517.00aede00@pop.atomz.com> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Multiple FreeBSD SCSI Hosts X-Original-Newsgroups: local.freebsd.scsi To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Thompson wrote: > I'm interested in setting up two FreeBSD systems in a very simple > clustering type configuration around centralized external SCSI storage > devices for hardware redundancy. The specific configuration I'm thinking > about is shown in the simple diagram below: > > +-----------+ +----------+ +-----------+ > | FreeBSD | | | | FreeBSD | > | Host 1 | | External | | Host 2 | > | (primary) | | SCSI | |(secondary)| > | | |RAID/DRIVE| | | > | SCSI r/w | | | | SCSI r/o | > +-----+-----+ +---+--+---+ +-----+-----+ > | | | | > +---------------+ +---------------+ Btw., we run it at a customer's site with two Sun servers, and experience shows this is fairly fragile. It frequently causes SCSI bus problems, like bus resets and lockups. We did it for that customer because they didn't want to spend the money on a full-featured cluster solution. We wouldn't do it again, at least not with parallel SCSI. (SCSI over fibre channel presumably doesn't cause the class of problems we're seeing there.) > 1. Do the FreeBSD SCSI drivers support such a configuration by > implementing the SCSI RESERVE/RELEASE commands to lock access to the > SCSI bus? If so, which drivers for which specific SCSI adapters? If you grep for RESERVE through /sys/cam/scsi/*, you'll see that apparently only sa(4) uses it. Btw., tape drivers (and CD recorders) are basically forbidden in such a situation, since the possibility of a bus reset induced by the other host is fatal for them. (It'll cause the tape to rewind, even in the middle of e. g. a write operation.) > 3. Will the secondary server still experience a corrupted file > system because of write caching by the primary server? Yes. > If so, would it be possible to configure the primary server to write > through the cache? Only by mounting with -o sync, which has a huge performance penalty. > 6. Are there alternatives to this type of scenario that may work > better for FreeBSD? The most interesting idea in this context is `Global Filesystem', a distributed filesystem that deals with cache coherency and proper resource locking. This project started out some day in the past on SGI Irix, then they went to Linux, then they went away from open-source and got commercial. :( I remember rumours that someone here was going to consider a FreeBSD port (a commercial one, i assume). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 15: 6:47 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82E8E37B404; Fri, 18 Oct 2002 15:06:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DE2643E9C; Fri, 18 Oct 2002 15:06:46 -0700 (PDT) (envelope-from njl@FreeBSD.org) Received: from freefall.freebsd.org (njl@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9IM6kx3075289; Fri, 18 Oct 2002 15:06:46 -0700 (PDT) (envelope-from njl@freefall.freebsd.org) Received: (from njl@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9IM6j1G075285; Fri, 18 Oct 2002 15:06:45 -0700 (PDT) Date: Fri, 18 Oct 2002 15:06:45 -0700 (PDT) From: Nate Lawson Message-Id: <200210182206.g9IM6j1G075285@freefall.freebsd.org> To: p@i609a.hadiko.de, njl@FreeBSD.org, scsi@FreeBSD.org, njl@FreeBSD.org Subject: Re: kern/36845: Add ioctls CDRIOCREADSPEED/WRITESPEED to the scsi cd driver Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: Add ioctls CDRIOCREADSPEED/WRITESPEED to the scsi cd driver State-Changed-From-To: analyzed->closed State-Changed-By: njl State-Changed-When: Fri Oct 18 15:04:58 PDT 2002 State-Changed-Why: Modified patch was committed in scsi_cd.c v1.67 along with various changes to unify the API with atapi-cd. The userland utils burncd and cdcontrol were also updated. Responsible-Changed-From-To: scsi->njl Responsible-Changed-By: njl Responsible-Changed-When: Fri Oct 18 15:04:58 PDT 2002 Responsible-Changed-Why: I wrote the new changes based on Philipp's patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=36845 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 15:41:24 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11E6437B401 for ; Fri, 18 Oct 2002 15:41:23 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A73F443EA9 for ; Fri, 18 Oct 2002 15:41:22 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 47510 invoked by uid 1000); 18 Oct 2002 22:41:24 -0000 Date: Fri, 18 Oct 2002 15:41:24 -0700 (PDT) From: Nate Lawson To: Joerg Wunsch Cc: freebsd-scsi@freebsd.org Subject: Re: Multiple FreeBSD SCSI Hosts In-Reply-To: <200210182012.g9IKCHoI059995@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 18 Oct 2002, Joerg Wunsch wrote: > Mike Thompson wrote: > > > I'm interested in setting up two FreeBSD systems in a very simple > > clustering type configuration around centralized external SCSI storage > > devices for hardware redundancy. The specific configuration I'm thinking > > about is shown in the simple diagram below: > > > > +-----------+ +----------+ +-----------+ > > | FreeBSD | | | | FreeBSD | > > | Host 1 | | External | | Host 2 | > > | (primary) | | SCSI | |(secondary)| > > | | |RAID/DRIVE| | | > > | SCSI r/w | | | | SCSI r/o | > > +-----+-----+ +---+--+---+ +-----+-----+ > > | | | | > > +---------------+ +---------------+ > > Btw., we run it at a customer's site with two Sun servers, and > experience shows this is fairly fragile. It frequently causes > SCSI bus problems, like bus resets and lockups. > > We did it for that customer because they didn't want to spend the > money on a full-featured cluster solution. We wouldn't do it again, > at least not with parallel SCSI. (SCSI over fibre channel presumably > doesn't cause the class of problems we're seeing there.) What are you trying to achieve? If you are trying to have apps on two boxes sharing data via this method (say a webserver cluster), you're going to end up with consistency problems from the FILE SYSTEM. SCSI is not the problem -- multiple initiators have been around forever. The only way this would work is if both mounted the drive R/O or you use a filesystem that is aware of this type of scenario (i.e. joerg mentioning GFS). -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 16:34:45 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43B2937B401 for ; Fri, 18 Oct 2002 16:34:44 -0700 (PDT) Received: from mail.atomz.com (MAIL.ATOMZ.COM [64.41.153.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0178143E97 for ; Fri, 18 Oct 2002 16:34:44 -0700 (PDT) (envelope-from mike@atomz.com) Received: from mthompson.atomz.com (unknown [208.131.120.194]) by mail.atomz.com (Postfix) with ESMTP id 84FB93075B; Fri, 18 Oct 2002 16:42:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20021018162828.00b0b4d0@pop.atomz.com> X-Sender: mike@pop.atomz.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Oct 2002 16:34:39 -0700 To: Nate Lawson , Joerg Wunsch From: Mike Thompson Subject: Re: Multiple FreeBSD SCSI Hosts Cc: freebsd-scsi@freebsd.org In-Reply-To: References: <200210182012.g9IKCHoI059995@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 03:41 PM 10/18/02 -0700, Nate Lawson wrote: >What are you trying to achieve? If you are trying to have apps on two >boxes sharing data via this method (say a webserver cluster), you're going >to end up with consistency problems from the FILE SYSTEM. SCSI is not the >problem -- multiple initiators have been around forever. I'm trying to essentially keep a live hot spare that can be manually configured to take over for the primary server should it fail for some reason. The secondary really doesn't need access to the shared SCSI volume until such time. Considering the problems mentioned regarding the file system it would probably be best for the secondary to not mount the shared SCSI volume until the primary has unmounted it (or been turned off). Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 17:23:45 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76DCB37B404 for ; Fri, 18 Oct 2002 17:23:44 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ED0D643E6E for ; Fri, 18 Oct 2002 17:23:38 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 47811 invoked by uid 1000); 19 Oct 2002 00:23:40 -0000 Date: Fri, 18 Oct 2002 17:23:40 -0700 (PDT) From: Nate Lawson To: Mike Thompson Cc: freebsd-scsi@freebsd.org Subject: Re: Multiple FreeBSD SCSI Hosts In-Reply-To: <4.3.2.7.2.20021018162828.00b0b4d0@pop.atomz.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 18 Oct 2002, Mike Thompson wrote: > At 03:41 PM 10/18/02 -0700, Nate Lawson wrote: > >What are you trying to achieve? If you are trying to have apps on two > >boxes sharing data via this method (say a webserver cluster), you're going > >to end up with consistency problems from the FILE SYSTEM. SCSI is not the > >problem -- multiple initiators have been around forever. > > I'm trying to essentially keep a live hot spare that can be manually > configured to take over for the primary server should it fail for some > reason. The secondary really doesn't need access to the shared SCSI volume > until such time. Considering the problems mentioned regarding the file > system it would probably be best for the secondary to not mount the shared > SCSI volume until the primary has unmounted it (or been turned off). > > Mike Excellent choice and that should work fine. You could even not have the drive detected until the main box crashes: if (heartbeat_dead) { camcontrol rescan 0 fsck /dev/daX mount /dev/daX /recovery/mnt notify_admin() } -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 23:10: 9 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3432E37B401 for ; Fri, 18 Oct 2002 23:10:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAA4343E9C for ; Fri, 18 Oct 2002 23:10:06 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id IAA22343; Sat, 19 Oct 2002 08:10:04 +0200 (CEST) Received: from uriah.heep.sax.de (localhost.heep.sax.de [127.0.0.1]) by uriah.heep.sax.de (8.12.5/8.12.5) with ESMTP id g9J64gWc072634; Sat, 19 Oct 2002 08:04:42 +0200 (MET DST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.12.5/8.12.5/Submit) id g9J64g51072633; Sat, 19 Oct 2002 08:04:42 +0200 (MET DST) (envelope-from j) Date: Sat, 19 Oct 2002 08:04:42 +0200 From: Joerg Wunsch To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: Multiple FreeBSD SCSI Hosts Message-ID: <20021019080442.A59572@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , Nate Lawson , freebsd-scsi@freebsd.org References: <200210182012.g9IKCHoI059995@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Fri, Oct 18, 2002 at 03:41:24PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Nate Lawson wrote: > > Btw., we run it at a customer's site with two Sun servers, and > > experience shows this is fairly fragile. It frequently causes > > SCSI bus problems, like bus resets and lockups. > What are you trying to achieve? The exact same thing as Mike wants: a (manual) failover scenario. > If you are trying to have apps on two boxes sharing data via this > method (say a webserver cluster), you're going to end up with > consistency problems from the FILE SYSTEM. Sure. If you've read my message completely, that's what i wrote to Mike (and a little more). ;-) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 18 23:27:36 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6D3237B401; Fri, 18 Oct 2002 23:27:20 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF4F43E8A; Fri, 18 Oct 2002 23:27:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA27729; Sat, 19 Oct 2002 16:26:52 +1000 Date: Sat, 19 Oct 2002 16:37:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Kenneth D. Merry" Cc: "M. Warner Losh" , , , , Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open() In-Reply-To: <20021013234758.A75169@panzer.kdm.org> Message-ID: <20021019152522.T1864-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 13 Oct 2002, Kenneth D. Merry wrote: > On Tue, Oct 01, 2002 at 15:06:21 +1000, Bruce Evans wrote: > > [Lot's quoted since this is a reply to old mail] [Lots not quoted since the context was so deep it was getting in the way] > > I finally configured atapicam so that I could test this, but I seem to have > > deleted the mail with the patch. Please resend the patch. > > Sorry for the delay on this end, lots going on. I've attached the patch. > I think it still works as before, but I've discovered that Poul-Henning > broke disklabel support in the cd(4) driver. I need to talk to him about > that. (It isn't directly related to whether this patch is the right thing > to do.) I noticed this too, and fixed it here (except in the GEOM case of course). Patches at the end. > > This is now "fixed" in diskopen() by dividing by the sector size before > > dsopen() can validate it. When the drive tray is open, division by 0 This is just a bug (using the sector size initialized by the device open without checking that the open succeeded. A nominal, garbage or previous size is used. The cd driver doesn't initialize the size (except to 0) until an open succeeds). > > only happens if there have been no previous successful opens, so something > > is apparently remembering the label for too long. These are some of the > > bugs introduced in subr_disk.c rev.1.59 (the others are lossage of passing > > the d_type, d_typename, d_packname and d_flags fields from the driver). > > Yeah, it's unfortunate we can't pass that information now. Actually, we can pass it, except in the GEOM case of course. The label is still there in the !GEOM case and is slightly easier to initialize than before (since the media size and sector size, which are the only non-constant things, are passed in another way). > > So this thread is now about errors in read(): acd gives EIO but cd will give > > ENXIO. (cd still gives ENXIO in open() in -current.) > > I suppose so. The cd(4) driver will give varying errors, depending on what > the drive tells it. If it's a "medium not present" type error, it'll > return ENXIO. Otherwise, it could be most anything. OK. I tried your patches a bit, but not very carefully. The most noticeable difference was that CAM is much more verbose than acd about missing media (it barfs 5 lines on the console). Another interesting error turned up: one of my drives (a cheap cdrom drive) mishandles a blank cd-rw blanked in the other drive (a not so cheap cd-rw drive). At boot time, the drive keeps searching the cd-rw and FreeBSD keeps tring to probe the drive ... until the disk is manually ejected; this usually causes a null pointer panic. The kernel has acd and cd and the misbehaviour is with and without GEOM. Both acd and cd seem to be confused. acd seems to print more messages about resetting, but one of the null pointer panics was in CAM. --- The following patches mostly restore scsi_cd.c to the unaxed version rev.1.59. Changes since then not related to axing are preserved. I first tried to do this by calling the slice layer directly so that the disk-mini layer is not involved. This mostly worked, but it was too hard to get all the details right since some of them have moved from the slice layer to the disk mini-layer. These patches make the !GEOM case work like it used to provided you also fix diskopen() to not divide by zero (a similar fix for dsopen() is not needed provided the driver is careful not to pass a sector size of 0 when open is succeeding). With GEOM, the only problm aprt from missing support for labels seems to be that the 'a' and 'c' devices don't exist. Some of the less obvious bugs fixed by this patch (at least in the !GEOM case) are: - bp->b_pblkno was always 0, so bioq_disksort() couldn't sort. - device stats didn't show cd*. I'm not sure why and guess it was due to missing infrastructure. Device stats showed acd* despite acd* not being in `sysctl kern.disks`. acd of course sets up everything itself since it doesn't use the disk mini-layer. %%% Index: scsi_cd.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.67 diff -u -2 -r1.67 scsi_cd.c --- scsi_cd.c 18 Oct 2002 22:03:38 -0000 1.67 +++ scsi_cd.c 19 Oct 2002 03:07:43 -0000 @@ -55,4 +55,6 @@ #include #include +#include +#include #include #include @@ -129,4 +131,5 @@ LIST_HEAD(, ccb_hdr) pending_ccbs; struct cd_params params; + struct disk disk; union ccb saved_ccb; cd_quirks quirks; @@ -136,6 +139,4 @@ int bufs_left; struct cam_periph *periph; - dev_t dev; - eventhandler_tag clonetag; }; @@ -208,4 +209,5 @@ static void cdprevent(struct cam_periph *periph, int action); static int cdsize(dev_t dev, u_int32_t *size); +static int cdfirsttrackisdata(struct cam_periph *periph); static int cdreadtoc(struct cam_periph *periph, u_int32_t mode, u_int32_t start, struct cd_toc_entry *data, @@ -264,4 +266,5 @@ /* flags */ D_DISK, }; +static struct cdevsw cddisk_cdevsw; static int num_changers; @@ -301,24 +304,4 @@ static void -cdclone(void *arg, char *name, int namelen, dev_t *dev) -{ - struct cd_softc *softc; - const char *p; - int l; - - softc = arg; - p = devtoname(softc->dev); - l = strlen(p); - if (bcmp(name, p, l)) - return; - if (name[l] != 'a' && name[l] != 'c') - return; - if (name[l + 1] != '\0') - return; - *dev = softc->dev; - return; -} - -static void cdinit(void) { @@ -489,6 +472,7 @@ } devstat_remove_entry(&softc->device_stats); - destroy_dev(softc->dev); - EVENTHANDLER_DEREGISTER(dev_clone, softc->clonetag); + if (softc->disk.d_dev) { + disk_destroy(softc->disk.d_dev); + } free(softc, M_DEVBUF); splx(s); @@ -566,4 +550,5 @@ struct ccb_getdev *cgd; caddr_t match; + dev_t disk_dev; cgd = (struct ccb_getdev *)arg; @@ -627,9 +612,11 @@ DEVSTAT_TYPE_CDROM | DEVSTAT_TYPE_IF_SCSI, DEVSTAT_PRIORITY_CD); - softc->dev = make_dev(&cd_cdevsw, periph->unit_number, - UID_ROOT, GID_OPERATOR, 0640, "cd%d", periph->unit_number); - softc->dev->si_drv1 = periph; - softc->clonetag = - EVENTHANDLER_REGISTER(dev_clone, cdclone, softc, 1000); + disk_dev = disk_create(periph->unit_number, &softc->disk, + DSO_ONESLICE | DSO_COMPATLABEL, + &cd_cdevsw, &cddisk_cdevsw); + disk_dev->si_drv1 = periph; + disk_dev->si_iosize_max = DFLTPHYS; /* XXX */ + disk_dev->si_bsize_phys = 2048; /* XXX */ + disk_dev->si_bsize_best = DFLTPHYS; /* XXX */ /* @@ -876,6 +863,8 @@ cdopen(dev_t dev, int flags, int fmt, struct thread *td) { + struct disklabel *label; struct cam_periph *periph; struct cd_softc *softc; + struct ccb_getdev cgd; u_int32_t size; int error; @@ -912,10 +901,70 @@ if ((error = cdsize(dev, &size)) != 0) { cdprevent(periph, PR_ALLOW); - cam_periph_unlock(periph); cam_periph_release(periph); + cam_periph_unlock(periph); return(error); } /* + * If we get a non-zero return, revert back to not reading the + * label off the disk. The first track is likely audio, which + * won't have a disklabel. + */ + if ((error = cdfirsttrackisdata(periph)) != 0) { + softc->disk.d_dsflags &= ~DSO_COMPATLABEL; + softc->disk.d_dsflags |= DSO_NOLABELS; + error = 0; + } + + /* + * Build prototype label for whole disk if necessary. Be warrantedly + * chummy with the implementation because the implementation has been + * broken to not take all our label info as a parameter. + * Should take information about different data tracks from the + * TOC and put it in the partition table. + */ + label = softc->disk.d_label; + if (label == NULL) + goto over; /* XXX no label -- GEOM lossage */ + if (label->d_type) + goto over; /* XXX ugly goto to minimize diffs */ + label->d_type = DTYPE_SCSI; + + /* + * Grab the inquiry data to get the vendor and product names. + * Put them in the typename and packname for the label. + */ + xpt_setup_ccb(&cgd.ccb_h, periph->path, /*priority*/ 1); + cgd.ccb_h.func_code = XPT_GDEV_TYPE; + xpt_action((union ccb *)&cgd); + + strncpy(label->d_typename, cgd.inq_data.vendor, + min(SID_VENDOR_SIZE, sizeof(label->d_typename))); + strncpy(label->d_packname, cgd.inq_data.product, + min(SID_PRODUCT_SIZE, sizeof(label->d_packname))); + +#if 0 /* These are now passed as disk.d_sectorsize and disk.d_mediasize. */ + label->d_secsize = softc->params.blksize; + label->d_secperunit = softc->params.disksize; +#endif + label->d_flags = D_REMOVABLE; + /* + * Make partition 'a' cover the whole disk. This is a temporary + * compatibility hack. The 'a' partition should not exist, so + * the slice code won't create it. The slice code will make + * partition (RAW_PART + 'a') cover the whole disk and fill in + * some more defaults. + */ + label->d_partitions[0].p_size = softc->params.disksize; + label->d_partitions[0].p_fstype = FS_OTHER; +over: + + softc->disk.d_sectorsize = softc->params.blksize; + softc->disk.d_mediasize = softc->params.blksize * + (off_t)softc->params.disksize; + softc->disk.d_fwsectors = 0; + softc->disk.d_fwheads = 0; + + /* * We unconditionally (re)set the blocksize each time the * CD device is opened. This is because the CD can change, @@ -955,4 +1004,11 @@ /* + * Unconditionally set the dsopen() flags back to their default + * state. + */ + softc->disk.d_dsflags &= ~DSO_NOLABELS; + softc->disk.d_dsflags |= DSO_COMPATLABEL; + + /* * Since we're closing this CD, mark the blocksize as unavailable. * It will be marked as available whence the CD is opened again. @@ -960,6 +1016,6 @@ softc->device_stats.flags |= DEVSTAT_BS_UNAVAILABLE; - cam_periph_unlock(periph); cam_periph_release(periph); + cam_periph_unlock(periph); return (0); @@ -1350,6 +1406,4 @@ else cdschedule(periph, /* priority */ 1); - - return; } @@ -1397,6 +1451,5 @@ /* byte2 */ 0, /* minimum_cmd_size */ 10, - /* lba */ bp->bio_blkno / - (softc->params.blksize / DEV_BSIZE), + /* lba */ bp->bio_pblkno, bp->bio_bcount / softc->params.blksize, /* data_ptr */ bp->bio_data, @@ -1527,9 +1580,5 @@ bp->bio_error = 0; if (bp->bio_resid != 0) { - /* - * Short transfer ??? - * XXX: not sure this is correct for partial - * transfers at EOM - */ + /* Short transfer ??? */ bp->bio_flags |= BIO_ERROR; } @@ -1774,12 +1823,4 @@ switch (cmd) { - case DIOCGMEDIASIZE: - *(off_t *)addr = - (off_t)softc->params.blksize * softc->params.disksize; - break; - case DIOCGSECTORSIZE: - *(u_int *)addr = softc->params.blksize; - break; - case CDIOCPLAYTRACKS: { @@ -2400,5 +2441,5 @@ error = cdsendkey(periph, authinfo); break; - } + } case DVDIOCREADSTRUCTURE: { struct dvd_struct *dvdstruct; @@ -2418,7 +2459,6 @@ CAM_DEBUG(periph->path, CAM_DEBUG_TRACE, ("leaving cdioctl\n")); - if (error && bootverbose) { + if (error != 0 && bootverbose) printf("scsi_cd.c::ioctl cmd=%08lx error=%d\n", cmd, error); - } return (error); @@ -2519,4 +2559,78 @@ return (error); +} + +/* + * The idea here is to try to figure out whether the first track is data or + * audio. If it is data, we can at least attempt to read a disklabel off + * the first sector of the disk. If it is audio, there won't be a + * disklabel. + * + * This routine returns 0 if the first track is data, and non-zero if there + * is an error or the first track is audio. (If either non-zero case, we + * should not attempt to read the disklabel.) + */ +static int +cdfirsttrackisdata(struct cam_periph *periph) +{ + struct cdtocdata { + struct ioc_toc_header header; + struct cd_toc_entry entries[100]; + }; + struct cd_softc *softc; + struct ioc_toc_header *th; + struct cdtocdata *data; + int num_entries, i; + int error, first_track_audio; + + error = 0; + first_track_audio = -1; + + softc = (struct cd_softc *)periph->softc; + + data = malloc(sizeof(struct cdtocdata), M_TEMP, M_WAITOK); + + th = &data->header; + error = cdreadtoc(periph, 0, 0, (struct cd_toc_entry *)data, + sizeof(*data)); + + if (error) + goto bailout; + + if (softc->quirks & CD_Q_BCD_TRACKS) { + /* we are going to have to convert the BCD + * encoding on the cd to what is expected + */ + th->starting_track = + bcd2bin(th->starting_track); + th->ending_track = bcd2bin(th->ending_track); + } + th->len = scsi_2btoul((u_int8_t *)&th->len); + + if ((th->len - 2) > 0) + num_entries = (th->len - 2) / sizeof(struct cd_toc_entry); + else + num_entries = 0; + + for (i = 0; i < num_entries; i++) { + if (data->entries[i].track == th->starting_track) { + if (data->entries[i].control & 0x4) + first_track_audio = 0; + else + first_track_audio = 1; + break; + } + } + + if (first_track_audio == -1) + error = ENOENT; + else if (first_track_audio == 1) + error = EINVAL; + else + error = 0; +bailout: + free(data, M_TEMP); + + return(error); } %%% The patches are most easy to describe relative to rev.1.59: % Index: scsi_cd.c % =================================================================== % RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v % retrieving revision 1.59 % diff -u -2 -r1.59 scsi_cd.c % --- scsi_cd.c 15 Aug 2002 20:54:02 -0000 1.59 % +++ scsi_cd.c 19 Oct 2002 03:07:43 -0000 % @@ -25,5 +25,5 @@ % * SUCH DAMAGE. % * % - * $FreeBSD: src/sys/cam/scsi/scsi_cd.c,v 1.59 2002/08/15 20:54:02 njl Exp $ % + * $FreeBSD: src/sys/cam/scsi/scsi_cd.c,v 1.67 2002/10/18 22:03:38 njl Exp $ % */ % /* % @@ -55,6 +55,9 @@ % #include % #include % +#include % +#include Needed now since has been depolluted. % #include % #include % +#include Part of the recent patch for speeds. Not related to axing. % #include % #include % @@ -231,4 +234,6 @@ % static int cdstopunit(struct cam_periph *periph, u_int32_t eject); % static int cdstartunit(struct cam_periph *periph); % +static int cdsetspeed(struct cam_periph *periph, % + u_int32_t rdspeed, u_int32_t wrspeed); Part of the recent patch for speeds. % static int cdreportkey(struct cam_periph *periph, % struct dvd_authinfo *authinfo); % @@ -246,8 +251,4 @@ % PERIPHDRIVER_DECLARE(cd, cddriver); % % -/* For 2.2-stable support */ % -#ifndef D_DISK % -#define D_DISK 0 % -#endif Approved axing :-). % static struct cdevsw cd_cdevsw = { % /* open */ cdopen, % @@ -302,5 +303,5 @@ % static STAILQ_HEAD(changerlist, cdchanger) changerq; % % -void % +static void % cdinit(void) % { Lint fix. % @@ -615,4 +616,7 @@ % &cd_cdevsw, &cddisk_cdevsw); % disk_dev->si_drv1 = periph; % + disk_dev->si_iosize_max = DFLTPHYS; /* XXX */ % + disk_dev->si_bsize_phys = 2048; /* XXX */ % + disk_dev->si_bsize_best = DFLTPHYS; /* XXX */ % % /* I want drivers to set these parameters instead of letting other parts of the kernel default them. The XXX's are because the values are no better than the defaults. % @@ -897,6 +901,6 @@ % if ((error = cdsize(dev, &size)) != 0) { % cdprevent(periph, PR_ALLOW); % - cam_periph_unlock(periph); % cam_periph_release(periph); % + cam_periph_unlock(periph); % return(error); % } Half of a cosmetic patch I've been maintaining for 4 years. I like locks to be released in the reverse order to which they are acquired. % @@ -914,10 +918,15 @@ % % /* % - * Build prototype label for whole disk. % + * Build prototype label for whole disk if necessary. Be warrantedly % + * chummy with the implementation because the implementation has been % + * broken to not take all our label info as a parameter. % * Should take information about different data tracks from the % * TOC and put it in the partition table. % */ % - label = &softc->disk.d_label; % - bzero(label, sizeof(*label)); % + label = softc->disk.d_label; % + if (label == NULL) % + goto over; /* XXX no label -- GEOM lossage */ This avoids following a null pointer in the GEOM case. % + if (label->d_type) % + goto over; /* XXX ugly goto to minimize diffs */ This is just an optimization. % label->d_type = DTYPE_SCSI; % % @@ -935,6 +944,8 @@ % min(SID_PRODUCT_SIZE, sizeof(label->d_packname))); % % +#if 0 /* These are now passed as disk.d_sectorsize and disk.d_mediasize. */ % label->d_secsize = softc->params.blksize; % label->d_secperunit = softc->params.disksize; % +#endif Left the code just to show that not much is being changed. % label->d_flags = D_REMOVABLE; % /* % @@ -945,7 +956,14 @@ % * some more defaults. % */ % - label->d_partitions[0].p_size = label->d_secperunit; % + label->d_partitions[0].p_size = softc->params.disksize; Have to change this since d_secperunit is now not initialized until later. % label->d_partitions[0].p_fstype = FS_OTHER; % +over: % % + softc->disk.d_sectorsize = softc->params.blksize; % + softc->disk.d_mediasize = softc->params.blksize * % + (off_t)softc->params.disksize; % + softc->disk.d_fwsectors = 0; % + softc->disk.d_fwheads = 0; % + This is the only part of rev.1.59 that was really necessary. % /* % * We unconditionally (re)set the blocksize each time the % @@ -998,6 +1016,6 @@ % softc->device_stats.flags |= DEVSTAT_BS_UNAVAILABLE; % % - cam_periph_unlock(periph); % cam_periph_release(periph); % + cam_periph_unlock(periph); Other half of the cosmetic patch (see above). % % return (0); % @@ -1388,6 +1406,4 @@ % else % cdschedule(periph, /* priority */ 1); % - % - return; % } % I tried not to see style bugs while writing this patch but saw this. % @@ -2408,4 +2424,10 @@ % error = ENOTTY; % break; % + case CDRIOCREADSPEED: % + error = cdsetspeed(periph, *(u_int32_t *)addr, CDR_MAX_SPEED); % + break; % + case CDRIOCWRITESPEED: % + error = cdsetspeed(periph, CDR_MAX_SPEED, *(u_int32_t *)addr); % + break; % case DVDIOCSENDKEY: % case DVDIOCREPORTKEY: { Part of the recent patch for speeds. % @@ -2437,4 +2459,6 @@ % % CAM_DEBUG(periph->path, CAM_DEBUG_TRACE, ("leaving cdioctl\n")); % + if (error != 0 && bootverbose) % + printf("scsi_cd.c::ioctl cmd=%08lx error=%d\n", cmd, error); % % return (error); Some debugging code (not mine) less some style bugs (excessive {}). % @@ -3046,4 +3070,42 @@ % /* sense_len */ SSD_FULL_SIZE, % /* timeout */ 50000); % + % + error = cdrunccb(ccb, cderror, /*cam_flags*/CAM_RETRY_SELTO, % + /*sense_flags*/SF_RETRY_UA); % + % + xpt_release_ccb(ccb); % + % + return(error); % +} % + % +static int % +cdsetspeed(struct cam_periph *periph, u_int32_t rdspeed, u_int32_t wrspeed) % +{ % + struct scsi_set_speed *scsi_cmd; % + struct ccb_scsiio *csio; % + union ccb *ccb; % + int error; % + % + error = 0; % + ccb = cdgetccb(periph, /* priority */ 1); % + csio = &ccb->csio; % + % + cam_fill_csio(csio, % + /* retries */ 1, % + /* cbfcnp */ cddone, % + /* flags */ CAM_DIR_NONE, % + /* tag_action */ MSG_SIMPLE_Q_TAG, % + /* data_ptr */ NULL, % + /* dxfer_len */ 0, % + /* sense_len */ SSD_FULL_SIZE, % + sizeof(struct scsi_set_speed), % + /* timeout */ 50000); % + % + scsi_cmd = (struct scsi_set_speed *)&csio->cdb_io.cdb_bytes; % + bzero(scsi_cmd, sizeof(*scsi_cmd)); % + % + scsi_cmd->opcode = SET_CD_SPEED; % + scsi_ulto2b(rdspeed, scsi_cmd->readspeed); % + scsi_ulto2b(wrspeed, scsi_cmd->writespeed); % % error = cdrunccb(ccb, cderror, /*cam_flags*/CAM_RETRY_SELTO, Part of the recent patch for speeds. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 19 3:59:21 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8063137B401 for ; Sat, 19 Oct 2002 03:59:19 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517DA43E75 for ; Sat, 19 Oct 2002 03:59:18 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.6/8.12.6) with ESMTP id g9JAxGFu052408 for ; Sat, 19 Oct 2002 12:59:16 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.6/8.12.6/Submit) id g9JAxGBu052407 for scsi@freebsd.org; Sat, 19 Oct 2002 12:59:16 +0200 (CEST) Date: Sat, 19 Oct 2002 12:59:16 +0200 From: Wilko Bulte To: scsi@freebsd.org Subject: FW: alpha tinderbox failure Message-ID: <20021019125916.A52382@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: FreeBSD 4.7-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org can ahd_pci please be fixed? Wilko ----- Forwarded message from Dag-Erling Smorgrav ----- Date: Sat, 19 Oct 2002 03:40:09 -0700 (PDT) From: Dag-Erling Smorgrav Subject: alpha tinderbox failure To: current@FreeBSD.ORG -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- >>> stage 1: bootstrap tools -------------------------------------------------------------- >>> stage 2: cleaning up the object tree -------------------------------------------------------------- >>> stage 2: rebuilding the object tree -------------------------------------------------------------- >>> stage 2: build tools -------------------------------------------------------------- >>> stage 3: cross tools -------------------------------------------------------------- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -------------------------------------------------------------- >>> stage 4: building libraries -------------------------------------------------------------- >>> stage 4: make dependencies -------------------------------------------------------------- >>> stage 4: building everything.. -------------------------------------------------------------- >>> Kernel build for GENERIC started on Sat Oct 19 03:07:29 PDT 2002 -------------------------------------------------------------- >>> Kernel build for GENERIC completed on Sat Oct 19 03:35:21 PDT 2002 -------------------------------------------------------------- >>> Kernel build for LINT started on Sat Oct 19 03:35:22 PDT 2002 -------------------------------------------------------------- ===> vinum "Makefile", line 4247: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/ahd_pci.c: In function `ahd_pci_map_registers': /h/des/src/sys/dev/aic7xxx/ahd_pci.c:173: warning: implicit declaration of function `bus_space_subregion' *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ----- End forwarded message ----- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 19 7:23:19 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA32537B401 for ; Sat, 19 Oct 2002 07:23:18 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 256C843E65 for ; Sat, 19 Oct 2002 07:23:18 -0700 (PDT) (envelope-from scottl@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11] (may be forged)) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g9JENC524752; Sat, 19 Oct 2002 07:23:12 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id HAA04435; Sat, 19 Oct 2002 07:23:11 -0700 (PDT) Received: from hollin.btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id IAA11893; Sat, 19 Oct 2002 08:23:08 -0600 (MDT) Received: from hollin.btc.adaptec.com (localhost [127.0.0.1]) by hollin.btc.adaptec.com (8.12.6/8.12.5) with ESMTP id g9JEKZ5v076713; Sat, 19 Oct 2002 08:20:35 -0600 (MDT) (envelope-from scottl@hollin.btc.adaptec.com) Received: (from scottl@localhost) by hollin.btc.adaptec.com (8.12.6/8.12.5/Submit) id g9JEKY8I076712; Sat, 19 Oct 2002 08:20:34 -0600 (MDT) Date: Sat, 19 Oct 2002 08:20:34 -0600 From: Scott Long To: Wilko Bulte Cc: scsi@freebsd.org Subject: Re: FW: alpha tinderbox failure Message-ID: <20021019142034.GA76694@hollin.btc.adaptec.com> References: <20021019125916.A52382@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021019125916.A52382@freebie.xs4all.nl> User-Agent: Mutt/1.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 19, 2002 at 12:59:16PM +0200, Wilko Bulte wrote: > can ahd_pci please be fixed? > > Wilko Alpha is missing several bus.h functions that exist on every other platform. If nobody is willing to fix that then ahd should probably be removed from the alpha configs. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message