From owner-freebsd-scsi Sun Jan 30 2:55:28 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id 826151556F for ; Sun, 30 Jan 2000 02:55:25 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-170-241.villette.club-internet.fr [195.36.170.241]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id LAA11256 for ; Sun, 30 Jan 2000 11:24:37 +0100 (MET) Date: Sun, 30 Jan 2000 11:53:33 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: scsi@FreeBSD.org Subject: Experimental `sym' driver changes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just made available my current version of the `sym-1.x.y' series driver= =20 for testing purpose (tar file set with full driver files) : ftp://ftp.tux.org/pub/roudier/drivers/freebsd/experimental/sym-1.3.0-freebs= d-20000130.readme ftp://ftp.tux.org/pub/roudier/drivers/freebsd/experimental/sym-1.3.0-freebs= d-20000130.tar.gz (URLs entered by hand and so not fully guaranteed to be correct) The changes seemed to me too large for 4.0 code freeze (40K unified diff), even if they donnot add features and mostly apply to some cases of error handling. People interested in that stuff may just read the `.readme' file or also give a try with this driver version and report comments if any.=20 Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 6:59:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id 252E314EAC for ; Sun, 30 Jan 2000 06:59:42 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-171-57.villette.club-internet.fr [195.36.171.57]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id PAA02388 for ; Sun, 30 Jan 2000 15:59:00 +0100 (MET) Date: Sun, 30 Jan 2000 16:27:56 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: scsi@FreeBSD.org Subject: Re: Experimental `sym' driver changes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry to follow up my posting, but I received a couple of replies that let me think that the 'subject' section of the posting was unclear. 'Experimental' applies to the 'changes' and not to the `sym' driver. =20 Basically, the 'changes' in sym-1.3.0 against driver version in -current are still in 'experimental' status since they are not tested enough, in my opinion. The global status of the driver is just the usual one that applies to softwares since day one: 'seems to work just fine until proven to be broken'. :-) Sorry for the bandwidth waste, G=E9rard. On Sun, 30 Jan 2000, Gerard Roudier wrote: =20 > I just made available my current version of the `sym-1.x.y' series driver= =20 > for testing purpose (tar file set with full driver files) : >=20 > ftp://ftp.tux.org/pub/roudier/drivers/freebsd/experimental/sym-1.3.0-free= bsd-20000130.readme > ftp://ftp.tux.org/pub/roudier/drivers/freebsd/experimental/sym-1.3.0-free= bsd-20000130.tar.gz > (URLs entered by hand and so not fully guaranteed to be correct) >=20 > The changes seemed to me too large for 4.0 code freeze (40K unified diff)= , > even if they donnot add features and mostly apply to some cases of error > handling. People interested in that stuff may just read the `.readme' fil= e > or also give a try with this driver version and report comments if any.= =20 >=20 > Regards, > G=E9rard. =20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 11:25:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pcr.ca (www.pcr.ca [207.139.158.13]) by hub.freebsd.org (Postfix) with ESMTP id DBB9615262 for ; Sun, 30 Jan 2000 11:25:29 -0800 (PST) (envelope-from admin@wtbwts.com) Received: by pcr.ca (Postfix, from userid 1000) id 9DEA21FEC; Sun, 30 Jan 2000 14:24:54 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by pcr.ca (Postfix) with ESMTP id 865001FE9 for ; Sun, 30 Jan 2000 14:24:54 +0000 (GMT) Date: Sun, 30 Jan 2000 14:24:54 +0000 (GMT) From: Marc Tardif X-Sender: admin@server.b0x.com To: freebsd-scsi@freebsd.org Subject: hardware vs software stripping 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've been reading the freebsd-scsi mailing list, the dpt.com website and searching all over the web to find a solution for performing fast reads on an array of disks. The best choice seems to be raid-0 for our database using postgresql. The alternatives are either raid-1 which seems too wasteful on disks or raid-5 which provides fault tolerance. This last option could substituted for a tape backup and the possibility of a few minutes down time in case of disk failure. Problem is: hardware or software? For hardware, I've been looking at the smartraid iv controller from dpt and perhaps their smartstation7 for an array of 7 x (9 or 18 gig drives). Although this solution isn't out of our price range, it seems to be better suited for raid-5. Considering raid-5 does stripping at the byte level, it might not even be as fast as raid-0 which also saves on redundancy. Therfore, for something as simple as stripping, using such hardware could be overkill. Besides, I'll still have to use ccd to do the stripping of the disks for raid-0. For software, I think freebsd's ccd could provide all the services required for very fast i/o on a straight array of disks and at a fraction of the cost of the raid alternative. Unfortunately, I have never witnessed the virtues of raid myself and I am not in a position to make an educated decision. I would therefore appreciate if someone from this mailing list could share their experience to help with my dilemna. Thanks in advance, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 13:32:26 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from kg.ops.uunet.co.za (kg.ops.uunet.co.za [196.31.1.31]) by hub.freebsd.org (Postfix) with ESMTP id C26BB151A9 for ; Sun, 30 Jan 2000 13:32:23 -0800 (PST) (envelope-from khetan@freebsd.os.org.za) Received: from chain.freebsd.os.org.za (chain.freebsd.os.org.za [196.7.162.242]) by kg.ops.uunet.co.za (Postfix) with ESMTP id 0588116E04 for ; Sun, 30 Jan 2000 23:32:16 +0200 (SAST) Received: by chain.freebsd.os.org.za (Postfix, from userid 1000) id 2408535627; Sun, 30 Jan 2000 23:32:12 +0200 (SAST) Received: from localhost (localhost [127.0.0.1]) by chain.freebsd.os.org.za (Postfix) with ESMTP id 181E531924 for ; Sun, 30 Jan 2000 23:32:12 +0200 (SAST) Date: Sun, 30 Jan 2000 23:32:09 +0200 (SAST) From: Khetan Gajjar To: scsi@freebsd.org Subject: Unknown error ? 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. I'm seeing an "Invalidating pack" error on a Fujitsu 1.6GB disk, connected to an Adaptec 2940U card. The disk eventually becomes off-line, and I can't unmount it. Resetting the bus, rescanning, etc don't seem to unwedge it. I rebooted it, and the box comes up fine, and the drive is correctly probed and re-mounted. This is on a -current box from Monday (Jan 24). Any ideas as to what this error means ? /usr/src/sys/cam/scsi/scsi_da.c indicates that this is a catastrophic error. Should I move everything off this disk ASAP ? da0: Fixed Direct Access SCSI-2 device ahc0: port 0xe40 0-0xe4ff mem 0xea102000-0xea102fff irq 11 at device 8.0 on pci0 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs Jan 30 18:34:04 bofh /kernel: (da0:ahc0:0:1:0): Invalidating pack Khetan Gajjar. --- khetan@uunet.co.za * khetan@os.org.za * PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za * http://www.freebsd.org * information at System Administration * http://office.os.org.za * kg+details@os.org.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 16:18:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 8825515262 for ; Sun, 30 Jan 2000 16:18:37 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA62882; Mon, 31 Jan 2000 10:48:29 +1030 (CST) Date: Mon, 31 Jan 2000 10:48:28 +1030 From: Greg Lehey To: Marc Tardif Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000131104827.A62824@freebie.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 30 January 2000 at 14:24:54 +0000, Marc Tardif wrote: > I've been reading the freebsd-scsi mailing list, the dpt.com website and > searching all over the web to find a solution for performing fast reads on > an array of disks. The best choice seems to be raid-0 for our database > using postgresql. The alternatives are either raid-1 which seems too > wasteful on disks or raid-5 which provides fault tolerance. This last > option could substituted for a tape backup and the possibility of a few > minutes down time in case of disk failure. I'm not sure I understand this sentence. Are you planning to forget RAID-5 after all and use a tape backup? For reasonably large disks, your downtime will be measured in hours, not minutes. For a RAID-5 array, you shouldn't get any down time. > roblem is: hardware or software? > > For hardware, I've been looking at the smartraid iv controller from dpt > and perhaps their smartstation7 for an array of 7 x (9 or 18 gig drives). > Although this solution isn't out of our price range, it seems to be better > suited for raid-5. Considering raid-5 does stripping at the byte level, it > might not even be as fast as raid-0 which also saves on redundancy. I suppose you mean striping. RAID-5 doesn't stripe at the byte level, it stripes at the block level. RAID-3 stripes at the byte level. Using RAID-0 "saves" on redundancy: if you lose a disk, you lose the file system. There are also some complex interactions between ufs and striping which can make it more than useless. I haven't done any real life tests, but it's possible that having striping doesn't buy you very much at the best of times when using ufs. > Therfore, for something as simple as stripping, using such hardware > could be overkill. Besides, I'll still have to use ccd to do the > stripping of the disks for raid-0. I don't understand this comment. If you want to do striping, you have the choice of hardware RAID, ccd or vinum. > For software, I think freebsd's ccd could provide all the services > required for very fast i/o on a straight array of disks and at a > fraction of the cost of the raid alternative. Unfortunately, I have > never witnessed the virtues of raid myself and I am not in a > position to make an educated decision. I would therefore appreciate > if someone from this mailing list could share their experience to > help with my dilemna. Why do you want to use ccd and not vinum? In any case, you may find that either are faster than the DPT controller (if you can find one; they're no longer making them). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 17: 4:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pcr.ca (www.pcr.ca [207.139.158.13]) by hub.freebsd.org (Postfix) with ESMTP id DD69B14E8E for ; Sun, 30 Jan 2000 17:04:45 -0800 (PST) (envelope-from admin@wtbwts.com) Received: by pcr.ca (Postfix, from userid 1000) id CB26F1FEC; Sun, 30 Jan 2000 20:04:18 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by pcr.ca (Postfix) with ESMTP id B584F1FE9; Sun, 30 Jan 2000 20:04:18 +0000 (GMT) Date: Sun, 30 Jan 2000 20:04:18 +0000 (GMT) From: Marc Tardif X-Sender: admin@server.b0x.com To: Greg Lehey Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping In-Reply-To: <20000131104827.A62824@freebie.lemis.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 On Mon, 31 Jan 2000, Greg Lehey wrote: > On Sunday, 30 January 2000 at 14:24:54 +0000, Marc Tardif wrote: > > ... > > using postgresql. The alternatives are either raid-1 which seems too > > wasteful on disks or raid-5 which provides fault tolerance. This last > > option could substituted for a tape backup and the possibility of a few > > minutes down time in case of disk failure. > > I'm not sure I understand this sentence. Are you planning to forget > RAID-5 after all and use a tape backup? For reasonably large disks, > your downtime will be measured in hours, not minutes. For a RAID-5 > array, you shouldn't get any down time. You understood correctly, but I guess you're right. From reading the dpt.com website, hardware failures are caused by hard-drives 50% of the time. Also, from one of Simon Shapiro's posting to this mailing list, I could build a raid 0+5 array which would seem to be an optimal solution for a database performing random reads and writes. Therefore, I should probably forget simply using ccd or vinum for a production system. There is another problem though, which is that I can't really have a general idea of the amount of space I'll require. Therefore, from my understanding, if I need to expand an array containing an sql db, I'll need to rebuild the whole thing after recreating a new filesystem on the new array. I'd be very relieved if there was an easier way... > > For software, I think freebsd's ccd could provide all the services > > required for very fast i/o on a straight array of disks and at a > > fraction of the cost of the raid alternative. Unfortunately, I have > > never witnessed the virtues of raid myself and I am not in a > > position to make an educated decision. I would therefore appreciate > > if someone from this mailing list could share their experience to > > help with my dilemna. > > Why do you want to use ccd and not vinum? In any case, you may find > that either are faster than the DPT controller (if you can find one; > they're no longer making them). The more I read about raid, the more I think it could be worthwhile. Although it can be expensive, I want to make sure I get what the server needs. As for getting a DPT controller, what's this about "the DPT controller" not being made anymore? I think I should be looking for something like a PM3334UW which looks like an excellent buy, even though smartraid v will be supported soon by freebsd. Thanks for the advice, much appreciated. Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 17:33:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 2CE4A15274 for ; Sun, 30 Jan 2000 17:33:41 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA63457; Mon, 31 Jan 2000 12:03:26 +1030 (CST) Date: Mon, 31 Jan 2000 12:03:26 +1030 From: Greg Lehey To: Marc Tardif Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000131120326.D62824@freebie.lemis.com> References: <20000131104827.A62824@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 30 January 2000 at 20:04:18 +0000, Marc Tardif wrote: > On Mon, 31 Jan 2000, Greg Lehey wrote: > >> On Sunday, 30 January 2000 at 14:24:54 +0000, Marc Tardif wrote: >>> ... >>> using postgresql. The alternatives are either raid-1 which seems too >>> wasteful on disks or raid-5 which provides fault tolerance. This last >>> option could substituted for a tape backup and the possibility of a few >>> minutes down time in case of disk failure. >> >> I'm not sure I understand this sentence. Are you planning to forget >> RAID-5 after all and use a tape backup? For reasonably large disks, >> your downtime will be measured in hours, not minutes. For a RAID-5 >> array, you shouldn't get any down time. > > You understood correctly, but I guess you're right. From reading the > dpt.com website, hardware failures are caused by hard-drives 50% of the > time. Also, from one of Simon Shapiro's posting to this mailing list, I > could build a raid 0+5 array which would seem to be an optimal solution > for a database performing random reads and writes. Therefore, I should > probably forget simply using ccd or vinum for a production system. I don't know how you conclude that. First, the DPT probably won't buy you anything in terms of performance, and secondly it's out of production. > There is another problem though, which is that I can't really have a > general idea of the amount of space I'll require. Therefore, from my > understanding, if I need to expand an array containing an sql db, I'll > need to rebuild the whole thing after recreating a new filesystem on the > new array. I'd be very relieved if there was an easier way... I can't make qualified statements about SQL. >>> For software, I think freebsd's ccd could provide all the services >>> required for very fast i/o on a straight array of disks and at a >>> fraction of the cost of the raid alternative. Unfortunately, I have >>> never witnessed the virtues of raid myself and I am not in a >>> position to make an educated decision. I would therefore appreciate >>> if someone from this mailing list could share their experience to >>> help with my dilemna. >> >> Why do you want to use ccd and not vinum? In any case, you may find >> that either are faster than the DPT controller (if you can find one; >> they're no longer making them). > > The more I read about raid, the more I think it could be worthwhile. > Although it can be expensive, I want to make sure I get what the server > needs. As for getting a DPT controller, what's this about "the DPT > controller" not being made anymore? That's my understanding. Even if you can get one, the performance is disappointing. In addition, I don't think you can't access the on-board management software from FreeBSD. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 21:19:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 1C699156DC for ; Sun, 30 Jan 2000 21:19:50 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 12F9DG-0001wd-00; Sun, 30 Jan 2000 21:17:22 -0800 Date: Sun, 30 Jan 2000 21:17:10 -0800 (PST) From: Tom To: Greg Lehey Cc: Marc Tardif , freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping In-Reply-To: <20000131120326.D62824@freebie.lemis.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 On Mon, 31 Jan 2000, Greg Lehey wrote: > On Sunday, 30 January 2000 at 20:04:18 +0000, Marc Tardif wrote: > > On Mon, 31 Jan 2000, Greg Lehey wrote: > > > >> On Sunday, 30 January 2000 at 14:24:54 +0000, Marc Tardif wrote: > >>> ... > >>> using postgresql. The alternatives are either raid-1 which seems too > >>> wasteful on disks or raid-5 which provides fault tolerance. This last > >>> option could substituted for a tape backup and the possibility of a few > >>> minutes down time in case of disk failure. > >> > >> I'm not sure I understand this sentence. Are you planning to forget > >> RAID-5 after all and use a tape backup? For reasonably large disks, > >> your downtime will be measured in hours, not minutes. For a RAID-5 > >> array, you shouldn't get any down time. > > > > You understood correctly, but I guess you're right. From reading the > > dpt.com website, hardware failures are caused by hard-drives 50% of the > > time. Also, from one of Simon Shapiro's posting to this mailing list, I > > could build a raid 0+5 array which would seem to be an optimal solution > > for a database performing random reads and writes. Therefore, I should > > probably forget simply using ccd or vinum for a production system. > > I don't know how you conclude that. First, the DPT probably won't buy > you anything in terms of performance, and secondly it's out of > production. Well, since I still can order the DPT 3334, I think its demise is greatly exagerated... as far as performance goes, it is not a new design and can't keep the new disks busy. Second, a DPT can't do RAID 5 + 0. It does the RAID 5 in hardware. The RAID 5 you'll have to do in software. > > There is another problem though, which is that I can't really have a > > general idea of the amount of space I'll require. Therefore, from my > > understanding, if I need to expand an array containing an sql db, I'll > > need to rebuild the whole thing after recreating a new filesystem on the > > new array. I'd be very relieved if there was an easier way... > > I can't make qualified statements about SQL. Depends on the database. Many databases allow the additional of storage on any device, so there shouldn't be a problem. An Infortrend (see below) can do a transparent copy-and-replace array expansion. This however just leaves you with a bigger virtual disk. FreeBSD has no way to grow a filesystem transparently. You can disklabel the addtional space and make a new filesystem though. > >>> For software, I think freebsd's ccd could provide all the services > >>> required for very fast i/o on a straight array of disks and at a > >>> fraction of the cost of the raid alternative. Unfortunately, I have > >>> never witnessed the virtues of raid myself and I am not in a > >>> position to make an educated decision. I would therefore appreciate > >>> if someone from this mailing list could share their experience to > >>> help with my dilemna. > >> > >> Why do you want to use ccd and not vinum? In any case, you may find > >> that either are faster than the DPT controller (if you can find one; > >> they're no longer making them). > > > > The more I read about raid, the more I think it could be worthwhile. > > Although it can be expensive, I want to make sure I get what the server > > needs. As for getting a DPT controller, what's this about "the DPT > > controller" not being made anymore? > > That's my understanding. Even if you can get one, the performance is > disappointing. In addition, I don't think you can't access the > on-board management software from FreeBSD. I don't think you can access the on-board management of any of the HBA RAID cards under FreeBSD. A SCSI-SCSI RAID controller (like a Infortrend or Mylex) is pretty nice. You can manage them. The Infortrend support RAID 5 + 0 in hardware. As far as vinum goes, I don't see how I can use to make a mirrored system disk (root and swap). I don't know if that will even be possible on x86 architecture. > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 21:24:19 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id EB29114E51 for ; Sun, 30 Jan 2000 21:24:13 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id PAA69044; Mon, 31 Jan 2000 15:53:56 +1030 (CST) Date: Mon, 31 Jan 2000 15:53:56 +1030 From: Greg Lehey To: Tom Cc: Marc Tardif , freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000131155356.B68925@freebie.lemis.com> References: <20000131120326.D62824@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 30 January 2000 at 21:17:10 -0800, Tom wrote: > > On Mon, 31 Jan 2000, Greg Lehey wrote: > >> On Sunday, 30 January 2000 at 20:04:18 +0000, Marc Tardif wrote: >>> On Mon, 31 Jan 2000, Greg Lehey wrote: >>> >>>> On Sunday, 30 January 2000 at 14:24:54 +0000, Marc Tardif wrote: >>>>> ... >>>>> using postgresql. The alternatives are either raid-1 which seems too >>>>> wasteful on disks or raid-5 which provides fault tolerance. This last >>>>> option could substituted for a tape backup and the possibility of a few >>>>> minutes down time in case of disk failure. >>>> >>>> I'm not sure I understand this sentence. Are you planning to forget >>>> RAID-5 after all and use a tape backup? For reasonably large disks, >>>> your downtime will be measured in hours, not minutes. For a RAID-5 >>>> array, you shouldn't get any down time. >>> >>> You understood correctly, but I guess you're right. From reading the >>> dpt.com website, hardware failures are caused by hard-drives 50% of the >>> time. Also, from one of Simon Shapiro's posting to this mailing list, I >>> could build a raid 0+5 array which would seem to be an optimal solution >>> for a database performing random reads and writes. Therefore, I should >>> probably forget simply using ccd or vinum for a production system. >> >> I don't know how you conclude that. First, the DPT probably won't buy >> you anything in terms of performance, and secondly it's out of >> production. > > Well, since I still can order the DPT 3334, I think its demise is > greatly exagerated... You can order them. Others have done that, but some have reported non-delivery. > as far as performance goes, it is not a new design and can't keep > the new disks busy. Right. > Second, a DPT can't do RAID 5 + 0. It does the RAID 5 in > hardware. The RAID 5 you'll have to do in software. Hmm. There's obviously a typo here, but I'm not sure how to correct it. I don't know the DPT implementation, but in Vinum RAID-5 implies striping. I'd be interested in hearing how DPT does it. >>> There is another problem though, which is that I can't really have a >>> general idea of the amount of space I'll require. Therefore, from my >>> understanding, if I need to expand an array containing an sql db, I'll >>> need to rebuild the whole thing after recreating a new filesystem on the >>> new array. I'd be very relieved if there was an easier way... >> >> I can't make qualified statements about SQL. > > Depends on the database. Many databases allow the additional of storage > on any device, so there shouldn't be a problem. > > An Infortrend (see below) can do a transparent copy-and-replace array > expansion. This however just leaves you with a bigger virtual disk. > FreeBSD has no way to grow a filesystem transparently. You can disklabel > the addtional space and make a new filesystem though. In a similar way, you can increase the size of a concatenated Vinum plex, or add another, larger plex to a volume. Both would increase the size of a volume. Some people also have tools for increasing the size of a ufs file system, but they still need work. >> That's my understanding. Even if you can get one, the performance is >> disappointing. In addition, I don't think you can't access the >> on-board management software from FreeBSD. > > I don't think you can access the on-board management of any of the HBA > RAID cards under FreeBSD. > > A SCSI-SCSI RAID controller (like a Infortrend or Mylex) is pretty nice. > You can manage them. The Infortrend support RAID 5 + 0 in hardware. > > As far as vinum goes, I don't see how I can use to make a mirrored > system disk (root and swap). I do :-) See http://www.lemis.com/vinum/wishlist.html for a discussion. > I don't know if that will even be possible on x86 architecture. Yes, it's possible. I'm looking at how to do it right now. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 21:38:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 3D29A14E47 for ; Sun, 30 Jan 2000 21:38:49 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 12F9WM-0001xW-00; Sun, 30 Jan 2000 21:37:06 -0800 Date: Sun, 30 Jan 2000 21:37:06 -0800 (PST) From: Tom To: Greg Lehey Cc: Marc Tardif , freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping In-Reply-To: <20000131155356.B68925@freebie.lemis.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 > > Second, a DPT can't do RAID 5 + 0. It does the RAID 5 in > > hardware. The RAID 5 you'll have to do in software. RAID 0 > > Hmm. There's obviously a typo here, but I'm not sure how to correct > it. I don't know the DPT implementation, but in Vinum RAID-5 implies > striping. I'd be interested in hearing how DPT does it. RAID 5 on the DPT. RAID 0 in software. Create two or more RAID 5 volumes on the DPT, then strip all DPT volumes into one big software volume using ccd (a lot of this predates vinum). The RAID 0 can help insuluate you from the generally crummy write performance of RAID 5. ... > > An Infortrend (see below) can do a transparent copy-and-replace array > > expansion. This however just leaves you with a bigger virtual disk. > > FreeBSD has no way to grow a filesystem transparently. You can disklabel > > the addtional space and make a new filesystem though. > > In a similar way, you can increase the size of a concatenated Vinum > plex, or add another, larger plex to a volume. Both would increase > the size of a volume. Some people also have tools for increasing the > size of a ufs file system, but they still need work. These tools are also strictly off-line too. Solaris' growfs is very disapointing in that all process that write just block until growfs is completed. Depending on your application, that may be unacceptable. > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers > > Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 30 22: 3:17 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id BA1DE151AF for ; Sun, 30 Jan 2000 22:02:44 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id QAA69237; Mon, 31 Jan 2000 16:27:31 +1030 (CST) Date: Mon, 31 Jan 2000 16:27:31 +1030 From: Greg Lehey To: Tom Cc: Marc Tardif , freebsd-scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000131162728.C68925@freebie.lemis.com> References: <20000131155356.B68925@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 30 January 2000 at 21:37:06 -0800, Tom wrote: > >>> Second, a DPT can't do RAID 5 + 0. It does the RAID 5 in >>> hardware. The RAID 5 you'll have to do in software. > RAID 0 >> >> Hmm. There's obviously a typo here, but I'm not sure how to correct >> it. I don't know the DPT implementation, but in Vinum RAID-5 implies >> striping. I'd be interested in hearing how DPT does it. > > RAID 5 on the DPT. RAID 0 in software. You misunderstand. RAID-5 in Vinum is implemented as a variant of RAID-0. Check http://www.lemis.com/vinum.html for details. > Create two or more RAID 5 volumes on the DPT, then strip all DPT > volumes into one big software volume using ccd (a lot of this > predates vinum). The RAID 0 can help insuluate you from the > generally crummy write performance of RAID 5. Not much. >>> An Infortrend (see below) can do a transparent copy-and-replace array >>> expansion. This however just leaves you with a bigger virtual disk. >>> FreeBSD has no way to grow a filesystem transparently. You can disklabel >>> the addtional space and make a new filesystem though. >> >> In a similar way, you can increase the size of a concatenated Vinum >> plex, or add another, larger plex to a volume. Both would increase >> the size of a volume. Some people also have tools for increasing the >> size of a ufs file system, but they still need work. > > These tools are also strictly off-line too. Solaris' growfs is very > disapointing in that all process that write just block until growfs is > completed. Depending on your application, that may be unacceptable. I can understand the problem. I don't think we'll get any better than that either. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 5:54:28 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from medicus.medicusnet.de (medicus.medicusnet.de [195.226.123.18]) by hub.freebsd.org (Postfix) with ESMTP id 1D8CF15045 for ; Mon, 31 Jan 2000 05:54:19 -0800 (PST) (envelope-from Stefan_Huerter@LU2.maus.de) Received: from medicus.medicusnet.de (root@medicus.medicusnet.de [192.168.1.1]) by medicus.medicusnet.de (8.8.8/8.8.7) with ESMTP id OAA06758 for ; Mon, 31 Jan 2000 14:54:01 +0100 Message-ID: <200001310445.p54310@lu2.maus.de> Date: Mon, 31 Jan 2000 03:45:00 -0000 From: Stefan_Huerter@LU2.maus.de (Stefan Huerter) Subject: hardware vs software stripping Organization: Quark Ludwigshafen 2 +49-6237-920345 To: freebsd-scsi@FreeBSD.ORG X-Gateway: Mauscon(0.9.4)/medicus.medicusnet.de, MausTausch X-Gateway-Admin: gatelu@medicus.medicusnet.de X-MAUS-X-Line: R+ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Guckux Marc > website and searching all over the web to find a solution for > performing fast reads on an array of disks. The best choice seems > to be raid-0 for our database using postgresql. The alternatives > are either raid-1 which seems too wasteful on disks or raid-5 which > provides fault tolerance. This last option could substituted for a > tape backup and the possibility of a few minutes down time in case > of disk failure. Problem is: hardware or software? My opinion: RAID-5 and databases are two different worlds, it's useful for inexpensive storage and a database with very low-write accesses. The read-performance is so far OK, but the writes brake down the database performance. I recommand for all of my customers only RAID0+1, but there's a waste of storage (but necessary for reliability). And: RAID5 is no substitute for a Backup, these are definitily two worlds. > For hardware, I've been looking at the smartraid iv controller from > dpt There are other hardware-controllers on the market, eg IFT and others, beginning with 3 SCSI-channels, one for the host, 2 for the devices, built- in-Ram and more (supporting RAID0,1,5 and some more...). Or, to go back to the low-cost solution, there is Arena, SCSI-interface to the Host and working with IDE-drive with a few IDE-bus'. Bye Stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 6:46:11 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id DAD0D14D64 for ; Mon, 31 Jan 2000 06:46:08 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id HAA32638; Mon, 31 Jan 2000 07:32:31 -0700 (MST) Date: Mon, 31 Jan 2000 07:32:31 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200001311432.HAA32638@narnia.plutotech.com> To: Greg Lehey Cc: scsi@FreeBSD.org Subject: Re: hardware vs software stripping X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <20000131104827.A62824@freebie.lemis.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <20000131104827.A62824@freebie.lemis.com> you wrote: > > I suppose you mean striping. RAID-5 doesn't stripe at the byte level, > it stripes at the block level. RAID-3 stripes at the byte level. I've heard you say this several times, but it is simply not true. RAID-3 is the same as RAID4 without the optimization for partial stripe writes. In otherwords, in RAID-3, you must read or write a full stripe where RAID-4 adds the ability to perform RMW operations on the parity block of the stripe for sub-stripe updates. Pluto uses a RAID-3 system in its video server products and it is certainly not striped on a byte level. (Just as an aside, given the minimum 512 byte sector size of most magnetic media, striping an a per byte basis would be really wasteful). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 6:50:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 8555214D3F for ; Mon, 31 Jan 2000 06:50:32 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id HAA32648; Mon, 31 Jan 2000 07:36:46 -0700 (MST) Date: Mon, 31 Jan 2000 07:36:46 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200001311436.HAA32648@narnia.plutotech.com> To: Khetan Gajjar Cc: scsi@FreeBSD.org Subject: Re: Unknown error ? X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > Hi. > > I'm seeing an "Invalidating pack" error on a Fujitsu > 1.6GB disk, connected to an Adaptec 2940U card. The disk > eventually becomes off-line, and I can't unmount it. > Resetting the bus, rescanning, etc don't seem to unwedge it. > I rebooted it, and the box comes up fine, and the drive > is correctly probed and re-mounted. The da driver should only invalidate the pack if the device fails to respond to selection multiple times. Often this is caused by the drive getting too hot and going into a failsafe mode. Powercycling the device will "wake it up". Check your cooling. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 7: 3:25 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from kg.ops.uunet.co.za (kg.ops.uunet.co.za [196.31.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 2FD6614C27 for ; Mon, 31 Jan 2000 07:03:14 -0800 (PST) (envelope-from khetan@freebsd.os.org.za) Received: from bofh.ops.uunet.co.za (bofh.ops.uunet.co.za [196.31.1.35]) by kg.ops.uunet.co.za (Postfix) with ESMTP id 9328E16E5A; Mon, 31 Jan 2000 17:03:05 +0200 (SAST) Received: by bofh.ops.uunet.co.za (Postfix, from userid 1000) id 343E25BB7; Mon, 31 Jan 2000 17:02:57 +0200 (SAST) Received: from localhost (localhost [127.0.0.1]) by bofh.ops.uunet.co.za (Postfix) with ESMTP id CCC9B1EBE; Mon, 31 Jan 2000 17:02:57 +0200 (SAST) Date: Mon, 31 Jan 2000 17:02:57 +0200 (SAST) From: Khetan Gajjar X-Sender: khetan@bofh.ops.uunet.co.za To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: Unknown error ? In-Reply-To: <200001311436.HAA32648@narnia.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 Around Today, "Justin T. Gibbs" wrote : JTG> > I'm seeing an "Invalidating pack" error on a Fujitsu JTG> > 1.6GB disk, connected to an Adaptec 2940U card. The disk JTG> > eventually becomes off-line, and I can't unmount it. JTG> > Resetting the bus, rescanning, etc don't seem to unwedge it. JTG> > I rebooted it, and the box comes up fine, and the drive JTG> > is correctly probed and re-mounted. JTG> JTG> The da driver should only invalidate the pack if the device fails JTG> to respond to selection multiple times. Often this is caused by Oh. JTG> the drive getting too hot and going into a failsafe mode. Powercycling JTG> the device will "wake it up". JTG> Check your cooling. Ok, will do :) Thanks! Khetan Gajjar. --- khetan@uunet.co.za * khetan@os.org.za * PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za * http://www.freebsd.org * information at System Administration * http://office.os.org.za * kg+details@uunet.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 13:13:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2103D14C05 for ; Mon, 31 Jan 2000 13:13:52 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA16384; Mon, 31 Jan 2000 22:01:59 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA01190; Mon, 31 Jan 2000 19:19:57 +0100 (CET) (envelope-from wilko) Date: Mon, 31 Jan 2000 19:19:57 +0100 From: Wilko Bulte To: "Justin T. Gibbs" Cc: Greg Lehey , scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000131191957.A906@yedi.iaf.nl> References: <200001311432.HAA32638@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001311432.HAA32638@narnia.plutotech.com>; from gibbs@narnia.plutotech.com on Mon, Jan 31, 2000 at 07:32:31AM -0700 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 31, 2000 at 07:32:31AM -0700, Justin T. Gibbs wrote: > In article <20000131104827.A62824@freebie.lemis.com> you wrote: > > > > I suppose you mean striping. RAID-5 doesn't stripe at the byte level, > > it stripes at the block level. RAID-3 stripes at the byte level. > > I've heard you say this several times, but it is simply not true. > RAID-3 is the same as RAID4 without the optimization for partial > stripe writes. In otherwords, in RAID-3, you must read or write > a full stripe where RAID-4 adds the ability to perform RMW operations > on the parity block of the stripe for sub-stripe updates. Pluto > uses a RAID-3 system in its video server products and it is certainly > not striped on a byte level. (Just as an aside, given the minimum > 512 byte sector size of most magnetic media, striping an a per byte > basis would be really wasteful). FWIW the Compaq HSx arrays try hard to distinguish full stripe writes on RAID5 and switches to RAID3 behaviour. This is as Justin says all on block level (or rather chunk level where a chunk is a number of 512byte blocks). For RAID3 to work well you would like to have synchronised disk spindles too (but try to find disks that can do that these days, they are not too common. And multiple diskvendors in one RAIDset don't mix well with spindle sync). RAID3, I think.., is mostly for specialised use (like video, or loading giant datasets on a numbercruncher) these days Wilko -- Wilko Bulte Arnhem, The Netherlands WWW : http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 13:28:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from richard2.pil.net (richard2.pil.net [207.8.164.9]) by hub.freebsd.org (Postfix) with SMTP id 501CE14F21 for ; Mon, 31 Jan 2000 13:28:52 -0800 (PST) (envelope-from up@3.am) Received: (qmail 17022 invoked by uid 1825); 31 Jan 2000 21:28:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Jan 2000 21:28:41 -0000 Date: Mon, 31 Jan 2000 16:28:41 -0500 (EST) From: X-Sender: up@richard2.pil.net To: Wilko Bulte Cc: scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping In-Reply-To: <20000131191957.A906@yedi.iaf.nl> 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, 31 Jan 2000, Wilko Bulte wrote: > On Mon, Jan 31, 2000 at 07:32:31AM -0700, Justin T. Gibbs wrote: > > In article <20000131104827.A62824@freebie.lemis.com> you wrote: > > > > > > I suppose you mean striping. RAID-5 doesn't stripe at the byte level, > > > it stripes at the block level. RAID-3 stripes at the byte level. > > > > I've heard you say this several times, but it is simply not true. > > RAID-3 is the same as RAID4 without the optimization for partial > > stripe writes. In otherwords, in RAID-3, you must read or write > > a full stripe where RAID-4 adds the ability to perform RMW operations > > on the parity block of the stripe for sub-stripe updates. Pluto > > uses a RAID-3 system in its video server products and it is certainly > > not striped on a byte level. (Just as an aside, given the minimum > > 512 byte sector size of most magnetic media, striping an a per byte > > basis would be really wasteful). > > FWIW the Compaq HSx arrays try hard to distinguish full stripe writes > on RAID5 and switches to RAID3 behaviour. This is as Justin says all on > block level (or rather chunk level where a chunk is a number of 512byte > blocks). > > For RAID3 to work well you would like to have synchronised disk > spindles too (but try to find disks that can do that these days, they > are not too common. And multiple diskvendors in one RAIDset don't mix > well with spindle sync). RAID3, I think.., is mostly for specialised use > (like video, or loading giant datasets on a numbercruncher) these days IIRC, the main difference between 3 and 5 is that 3 puts all of the parity blocks on one spindle, whereas 5 distributes them across all of the spindles. James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am ========================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 13:40:25 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 0B15D15040 for ; Mon, 31 Jan 2000 13:40:23 -0800 (PST) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id OAA13499 for ; Mon, 31 Jan 2000 14:40:52 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200001312140.OAA13499@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: scsi@FreeBSD.org Subject: Support for the Advansys ASC38C0800 U2W chips In-reply-to: Your message of "Mon, 31 Jan 2000 11:03:11 +0100." <00e101bf6bd2$61eba2c0$0201010a@host> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jan 2000 14:40:52 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have completed the changes to the adw driver to support the latest U2W chips from AdvanSys. I have only performed some preliminary validation of these changes, but the driver seems to perform correctly. Since the changes are quite large, I'd appreciate the support of owners of any AdvanSys Wide card (including the products using the Asc3550 Ultra chip) in validating that this driver works correctly. Diffs relative to -current can be had at: http://www.FreeBSD.org/~gibbs/adw.ultra2.20000131.diffs -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 31 23:25:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by builder.freebsd.org (Postfix) with ESMTP id 4AADB3D20 for ; Mon, 31 Jan 2000 23:25:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=in-addr.com) by noop.colo.erols.net with esmtp (Exim 3.12 #1) id 12FTVo-000MsR-00; Mon, 31 Jan 2000 21:57:52 -0500 To: up@3.am Cc: Wilko Bulte , scsi@FreeBSD.ORG From: Gary Palmer Subject: Re: hardware vs software stripping In-Reply-To: Message from of "Mon, 31 Jan 2000 16:28:41 EST." Date: Mon, 31 Jan 2000 21:57:52 -0500 Message-ID: <87942.949373872@in-addr.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org up@3.am wrote in message ID : > IIRC, the main difference between 3 and 5 is that 3 puts all of the parity > blocks on one spindle, whereas 5 distributes them across all of the > spindles. You're confusing RAID3 with RAID4. RAID4 is RAID 0 with parity (on one spindle) and RAID 5 is RAID 0 with striped parity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 0:35:19 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id DEE873D60 for ; Tue, 1 Feb 2000 00:35:11 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id TAA50500; Tue, 1 Feb 2000 19:04:41 +1030 (CST) Date: Tue, 1 Feb 2000 19:04:41 +1030 From: Greg Lehey To: "Justin T. Gibbs" , Gary Palmer Cc: scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping Message-ID: <20000201190440.Q76348@freebie.lemis.com> References: <87942.949373872@in-addr.com> <200001311432.HAA32638@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200001311432.HAA32638@narnia.plutotech.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 31 January 2000 at 7:32:31 -0700, Justin T. Gibbs wrote: > In article <20000131104827.A62824@freebie.lemis.com> you wrote: >> >> I suppose you mean striping. RAID-5 doesn't stripe at the byte level, >> it stripes at the block level. RAID-3 stripes at the byte level. > > I've heard you say this several times, but it is simply not true. It's not simply true, anyway :-) I think one of the problems is that I can't find an authoritative definition of the levels. I was going to buy one of those super-expensive books that you probably have, but in the meantime I've been limited to various web pages. At http://www.fdma.com/info/raidinto.html (now dead), I was told that RAID-3 stripes at the byte level, and RAID-4 stripes at a block level. At http://www.lib.ox.ac.uk/internet/news/faq/archive/arch-storage.part1.html, I read: Raid Level 3 - Data protection disk - mathematical ECC type code calculated from multiple spindles and stored on another spindle. Raid Level 4??? similar to 3, with block striping instead of byte. Raid Level 5 - Striping plus data protection - stripe data across multiple spindles (as in RAID Level 0) and have data protection calculations (as in RAID level 3) but don't put all the calculated figures onto one spindle, but spread it out. That appears to be less than authoritative. At http://www.adaptec.com/technology/whitepapers/raid.html, I read: RAID Level 3 stripes data at a byte level across several drives, with parity stored on one drive. It is otherwise similar to level 4. Byte-level striping requires hardware support for efficient use. RAID Level 4 stripes data at a block level across several drives, with parity stored on one drive. The parity information allows recovery from the failure of any single drive. The performance of a level 4 array is very good for reads (the same as level 0). Writes, however, require that parity data be updated each time. This slows small random writes, in particular, though large writes or sequential writes are fairly fast. Because only one drive in the array stores redundant data, the cost per megabyte of a level 4 array can be fairly low. RAID Level 5 is similar to level 4, but distributes parity among the drives. This can speed small writes in multiprocessing systems, since the parity disk does not become a bottleneck. Because parity data must be skipped on each drive during reads, however, the performance for reads tends to be considerably lower than a level 4 array. The cost per megabyte is the same as for level 4. Later in this page, I read: RAID Level Uses Level 0 (striping) Any application which requires very high speed storage, but does not need redundancy. Photoshop temporary files are a good example. Level 1 (mirroring) Applications which require redundancy with fast random writes; entry-level systems where only two drives are available. Small file servers are an example. Level 4 (parity) Applications which require redundancy at low cost, or with high-speed reads. This is good for archival storage. Larger file servers are an example. Level 5 (distributed parity) Similar to level 4, but may provide higher performance if most I/O is random and in small chunks. Database servers are an example. Note that they don't mention RAID-2 or RAID-3. I'd agree with all this except for RAID-4: there's no real advantage to RAID-4 over RAID-5. At http://www.baydel.com/tutorial.html I read: RAID Levels The 1988 RAID paper proposed 5 levels: 1: mirroring. 3: byte striping with dedicated parity. 4: block striping with dedicated parity. 5: block striping with distributed parity. (RAID2 was superseded by RAID3) RAID3 was considered to be ideally suited to large 'scientific' transfers and RAID5 to OLTP, or Transaction Processing. Inexplicably, the researchers gave a strong implication that RAID3 write performance would be bottlenecked on the parity drive. In fact, RAID3 'parallel' write performance is far better than with RAID5 or 'independent' RAIDs. Also, over the years, OLTP applications have been exhibiting an increasing write load with a small I/O size, resulting in a negation of the benefit of RAID5. Other applications such as NFS fileserving, Novell, Multi-media etc have I/O granularity above a size ideally suited to RAID5. This is an interesting viewpoint. In many cases, it's true, if you always transfer a complete number of blocks, since then the pre-reads of RAID-[45] aren't needed, which nearly doubles the write performance. Most of the other URLs I had have died, but they said much the same sort of thing. Finally, at http://www.whatis.com/raid.htm I read: RAID-3. This type uses striping and dedicates one drive to storing parity information. The embedded error checking (ECC) information is used to detect errors. Data recovery is accomplished by calculating the exclusive OR (XOR) of the information recorded on the other drives. Since an I/O operation addresses all drives at the same time, RAID-3 cannot overlap I/O. For this reason, RAID-3 is best for single-user systems with long record applications. RAID-4. This type uses large stripes, which means you can read records from any single drive. This allows you to take advantage of overlapped I/O for read operations. Since all write operations have to update the parity drive, no I/O overlapping is possible. RAID-4 offers no advantage over RAID-5. RAID-5. This type includes a rotating parity array, thus addressing the write limitation in RAID-4. Thus, all read and write operations can be overlapped. RAID-5 stores parity information but not redundant data (but parity information can be used to reconstruct data). RAID-5 requires at least three and usually five disks for the array. It's best for multi-user systems in which performance is not critical or which do few write operations. This comes closest to your definition by not using the term 'byte' in describing RAID-3, but it doesn't deny the possibility either. In general, it's a bit vague. Theoretically, the RAID-3 unit could be sectors, but in my view that would make it a special case of RAID-4. This page is also inaccurate in its description of RAID-4 and RAID-5: RAID-4 *can* overlap read operations, and RAID-5 can't always overlap write operations. In fact, there's very little difference in the amount of mutual exclusion needed on writes. > RAID-3 is the same as RAID4 without the optimization for partial > stripe writes. In otherwords, in RAID-3, you must read or write a > full stripe where RAID-4 adds the ability to perform RMW operations > on the parity block of the stripe for sub-stripe updates. I'm not sure I follow you here. Are you saying that the data layout is the same and the difference is in the implementation of the software? That doesn't seem to justify a separate level. > Pluto uses a RAID-3 system in its video server products and it is > certainly not striped on a byte level. So how exactly is it striped? > (Just as an aside, given the minimum 512 byte sector size of most > magnetic media, striping an a per byte basis would be really > wasteful). Agreed, unless you use a PLA to split the data. Obviously, the manufacturer of your RAID-3 box uses the term differently from the way it's defined above. There's obviously some confusion, but I don't know who is right, but I would have thought Adaptec knew what they're talking about (especially when they point out the need for hardware support). On Monday, 31 January 2000 at 21:57:52 -0500, Gary Palmer wrote: > up@3.am wrote in message ID > : >> IIRC, the main difference between 3 and 5 is that 3 puts all of the parity >> blocks on one spindle, whereas 5 distributes them across all of the >> spindles. > > You're confusing RAID3 with RAID4. RAID4 is RAID 0 with parity (on > one spindle) and RAID 5 is RAID 0 with striped parity. I'd call RAID-5 rotated parity, not striped. The way I see it, RAID-[3-5] are all striped. Before you reply to these messages telling me where I'm wrong, please check out http://www.lemis.com/vinum/implementation.html and tell me where you disagree with what I say there. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 0:38: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id DA2F13D5B for ; Tue, 1 Feb 2000 00:37:57 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id TAA50542; Tue, 1 Feb 2000 19:07:30 +1030 (CST) Date: Tue, 1 Feb 2000 19:07:30 +1030 From: Greg Lehey To: Wilko Bulte Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000201190730.R76348@freebie.lemis.com> References: <200001311432.HAA32638@narnia.plutotech.com> <20000131191957.A906@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000131191957.A906@yedi.iaf.nl> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 31 January 2000 at 19:19:57 +0100, Wilko Bulte wrote: > On Mon, Jan 31, 2000 at 07:32:31AM -0700, Justin T. Gibbs wrote: >> In article <20000131104827.A62824@freebie.lemis.com> you wrote: >>> >>> I suppose you mean striping. RAID-5 doesn't stripe at the byte level, >>> it stripes at the block level. RAID-3 stripes at the byte level. >> >> I've heard you say this several times, but it is simply not true. >> RAID-3 is the same as RAID4 without the optimization for partial >> stripe writes. In otherwords, in RAID-3, you must read or write >> a full stripe where RAID-4 adds the ability to perform RMW operations >> on the parity block of the stripe for sub-stripe updates. Pluto >> uses a RAID-3 system in its video server products and it is certainly >> not striped on a byte level. (Just as an aside, given the minimum >> 512 byte sector size of most magnetic media, striping an a per byte >> basis would be really wasteful). > > FWIW the Compaq HSx arrays try hard to distinguish full stripe > writes on RAID5 and switches to RAID3 behaviour. This is as Justin > says all on block level (or rather chunk level where a chunk is a > number of 512byte blocks). Well, see my other message. I'd like to call this RAID-4. But it's an interesting optimization, and I have a request to implement it in Vinum. It should work just as well on RAID-5 as on RAID-4. The key is that the write transfers must go exactly across the stripe: then you can just calculate the parity block and write it without having to do pre-reads of the area. > For RAID3 to work well you would like to have synchronised disk > spindles too (but try to find disks that can do that these days, > they are not too common. And multiple diskvendors in one RAIDset > don't mix well with spindle sync). RAID3, I think.., is mostly for > specialised use (like video, or loading giant datasets on a > numbercruncher) these days That's OK, there are plenty of requirements for that, as Justin has shown. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 6:23:49 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id D195D3DD8 for ; Tue, 1 Feb 2000 06:23:42 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id HAA15471; Tue, 1 Feb 2000 07:23:37 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002011423.HAA15471@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Greg Lehey Cc: "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping In-reply-to: Your message of "Tue, 01 Feb 2000 19:04:41 +1030." <20000201190440.Q76348@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Feb 2000 07:23:37 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> RAID-3 is the same as RAID4 without the optimization for partial >> stripe writes. In otherwords, in RAID-3, you must read or write a >> full stripe where RAID-4 adds the ability to perform RMW operations >> on the parity block of the stripe for sub-stripe updates. > >I'm not sure I follow you here. Are you saying that the data layout >is the same and the difference is in the implementation of the >software? That doesn't seem to justify a separate level. In RAID3, there is no restriction on the per-drive blocking factor. In RAID4, it is supposed to be a multiple of your transaction size so you can perform partial read (assuming you don't need parity verification) and RMW operations to update the parity for updating contiguous transactions that are not as large as the stripe. >> Pluto uses a RAID-3 system in its video server products and it is >> certainly not striped on a byte level. > >So how exactly is it striped? Our stripe size is 1-2MB with the per-drive stripe component size varying depend on the number of drives in the system. >> (Just as an aside, given the minimum 512 byte sector size of most >> magnetic media, striping an a per byte basis would be really >> wasteful). > >Agreed, unless you use a PLA to split the data. > >Obviously, the manufacturer of your RAID-3 box uses the term >differently from the way it's defined above. Pluto makes its own RAID hardware. 8-) -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 13: 8:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by builder.freebsd.org (Postfix) with ESMTP id 0A31E3EF5 for ; Tue, 1 Feb 2000 13:08:55 -0800 (PST) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA22567; Tue, 1 Feb 2000 21:55:23 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA10046; Tue, 1 Feb 2000 21:31:09 +0100 (CET) (envelope-from wilko) Date: Tue, 1 Feb 2000 21:31:09 +0100 From: Wilko Bulte To: Greg Lehey Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000201213108.A9984@yedi.iaf.nl> References: <200001311432.HAA32638@narnia.plutotech.com> <20000131191957.A906@yedi.iaf.nl> <20000201190730.R76348@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000201190730.R76348@freebie.lemis.com>; from grog@lemis.com on Tue, Feb 01, 2000 at 07:07:30PM +1030 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 01, 2000 at 07:07:30PM +1030, Greg Lehey wrote: > On Monday, 31 January 2000 at 19:19:57 +0100, Wilko Bulte wrote: > > On Mon, Jan 31, 2000 at 07:32:31AM -0700, Justin T. Gibbs wrote: > >> In article <20000131104827.A62824@freebie.lemis.com> you wrote: ... > > FWIW the Compaq HSx arrays try hard to distinguish full stripe > > writes on RAID5 and switches to RAID3 behaviour. This is as Justin > > says all on block level (or rather chunk level where a chunk is a > > number of 512byte blocks). > > Well, see my other message. I'd like to call this RAID-4. But it's Compaq calls it adaptive RAID3/5. Whatever... -- Wilko Bulte Arnhem, The Netherlands WWW : http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 13:52:32 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id 0790A3F3E; Tue, 1 Feb 2000 13:52:24 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA54531; Wed, 2 Feb 2000 08:22:14 +1030 (CST) Date: Wed, 2 Feb 2000 08:22:14 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping Message-ID: <20000202082214.S76348@freebie.lemis.com> References: <20000201190440.Q76348@freebie.lemis.com> <200002011423.HAA15471@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200002011423.HAA15471@caspian.plutotech.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 1 February 2000 at 7:23:37 -0700, Justin T. Gibbs wrote: >>> RAID-3 is the same as RAID4 without the optimization for partial >>> stripe writes. In otherwords, in RAID-3, you must read or write a >>> full stripe where RAID-4 adds the ability to perform RMW operations >>> on the parity block of the stripe for sub-stripe updates. >> >> I'm not sure I follow you here. Are you saying that the data layout >> is the same and the difference is in the implementation of the >> software? That doesn't seem to justify a separate level. > > In RAID3, there is no restriction on the per-drive blocking factor. That doesn't correspond to any of the definitions I have seen. Where did you get it from? > In RAID4, it is supposed to be a multiple of your transaction size Where do you get the term "transaction" from? I haven't seen it in any RAID documentation. In ufs, there is no fixed size. > so you can perform partial read (assuming you don't need parity > verification) When would you need parity verification for reads? > and RMW operations to update the parity for updating contiguous > transactions that are not as large as the stripe. I'd call both of these RAID-4, considering that RAID doesn't use the term "transaction". >>> Pluto uses a RAID-3 system in its video server products and it is >>> certainly not striped on a byte level. >> >> So how exactly is it striped? > > Our stripe size is 1-2MB with the per-drive stripe component size > varying depend on the number of drives in the system. So what's the difference from RAID-4? I can accept the fact that this is the way you use the term "RAID-3", but it conflicts with all documentation I have seen, and you haven't presented any other evidence. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 13:53:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id C85BB3F60 for ; Tue, 1 Feb 2000 13:53:35 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA54565; Wed, 2 Feb 2000 08:23:07 +1030 (CST) Date: Wed, 2 Feb 2000 08:23:06 +1030 From: Greg Lehey To: Wilko Bulte Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: hardware vs software stripping Message-ID: <20000202082306.T76348@freebie.lemis.com> References: <200001311432.HAA32638@narnia.plutotech.com> <20000131191957.A906@yedi.iaf.nl> <20000201190730.R76348@freebie.lemis.com> <20000201213108.A9984@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000201213108.A9984@yedi.iaf.nl> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 1 February 2000 at 21:31:09 +0100, Wilko Bulte wrote: > On Tue, Feb 01, 2000 at 07:07:30PM +1030, Greg Lehey wrote: >> On Monday, 31 January 2000 at 19:19:57 +0100, Wilko Bulte wrote: >>> On Mon, Jan 31, 2000 at 07:32:31AM -0700, Justin T. Gibbs wrote: >>>> In article <20000131104827.A62824@freebie.lemis.com> you wrote: > > ... > >>> FWIW the Compaq HSx arrays try hard to distinguish full stripe >>> writes on RAID5 and switches to RAID3 behaviour. This is as Justin >>> says all on block level (or rather chunk level where a chunk is a >>> number of 512byte blocks). >> >> Well, see my other message. I'd like to call this RAID-4. But it's > > Compaq calls it adaptive RAID3/5. Whatever... I'm beginning to get the impression that a number of vendors are reinterpreting RAID levels. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 14:20:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id D19903F75; Tue, 1 Feb 2000 14:20:51 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id PAA62239; Tue, 1 Feb 2000 15:21:04 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002012221.PAA62239@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Greg Lehey Cc: "Justin T. Gibbs" , "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping In-reply-to: Your message of "Wed, 02 Feb 2000 08:22:14 +1030." <20000202082214.S76348@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Feb 2000 15:21:04 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >That doesn't correspond to any of the definitions I have seen. Where >did you get it from? This is from the RAID Advisory board's RAID book. Take a look at www.raid-advisory.com for ordering details. >> In RAID4, it is supposed to be a multiple of your transaction size > >Where do you get the term "transaction" from? I haven't seen it in From the dictionary? 8-) The point is that your system is such that you may be able to satisfy a request by only reading one component of the stripe. >any RAID documentation. In ufs, there is no fixed size. Sure there is, the block size (i.e. 8k.) But then again, you wouldn't usually use RAID 3 or 4 for a filesystem. >> so you can perform partial read (assuming you don't need parity >> verification) > >When would you need parity verification for reads? When you are paranoid about the disks or some other portion of your system screwing up the data without telling you. >> and RMW operations to update the parity for updating contiguous >> transactions that are not as large as the stripe. > >I'd call both of these RAID-4, considering that RAID doesn't use the >term "transaction". Sure it does. In RAID-3, your transaction size *is* the stripe size. In RAID-4, it may be less than the stripe size. >>>> Pluto uses a RAID-3 system in its video server products and it is >>>> certainly not striped on a byte level. >>> >>> So how exactly is it striped? >> >> Our stripe size is 1-2MB with the per-drive stripe component size >> varying depend on the number of drives in the system. > >So what's the difference from RAID-4? I can accept the fact that this >is the way you use the term "RAID-3", but it conflicts with all >documentation I have seen, and you haven't presented any other >evidence. Here's what the RAID Advisory's RAID book has to say: RAID Level 3 Raid Level 3 adds redundant information in the form of parity to a parallel access striped array, permitting regeneration and rebuilding in the event of a disk failure. One "strip" of parity protects corresponding strips of data on the remaining disks. Raid Level 3 provides high data transfer rate and high data availability, at an inherently lower cost than mirroring. Its transaction performance is poor, however, because all RAID Level 3 array member disks operate in lockstep. RAID Level 4 Like RAID Level 3, RAID Level 4 uses parity concentrated on a single disk to protect data. Unlike RAID Level 3, however, a RAID Level 4 array's member disks are independently accessible. Its performance is therefore more suited to transaction I/O than large file transfers. Raid Level 4 is seldom implemented without accompanying technology, such as a write-back cache, because the dedicated parity disk represents an inherent write bottleneck. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 16:58:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id 52BBF3FCA; Tue, 1 Feb 2000 16:58:03 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA56256; Wed, 2 Feb 2000 11:27:55 +1030 (CST) Date: Wed, 2 Feb 2000 11:27:55 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping Message-ID: <20000202112755.L55303@freebie.lemis.com> References: <20000202082214.S76348@freebie.lemis.com> <200002012221.PAA62239@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i In-Reply-To: <200002012221.PAA62239@caspian.plutotech.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 1 February 2000 at 15:21:04 -0700, Justin T. Gibbs wrote: >> That doesn't correspond to any of the definitions I have seen. Where >> did you get it from? > > This is from the RAID Advisory board's RAID book. Take a look at > www.raid-advisory.com for ordering details. Hmm. That's cheaper than I remember it. I thought it was in the order of $500. I suppose I should order it. > Here's what the RAID Advisory's RAID book has to say: > > RAID Level 3 > > Raid Level 3 adds redundant information in the form of parity to a parallel > access striped array, permitting regeneration and rebuilding in the event > of a disk failure. One "strip" of parity protects corresponding strips of > data on the remaining disks. Raid Level 3 provides high data transfer > rate and high data availability, at an inherently lower cost than mirroring. > Its transaction performance is poor, however, because all RAID Level 3 array > member disks operate in lockstep. > > RAID Level 4 > > Like RAID Level 3, RAID Level 4 uses parity concentrated on a single disk > to protect data. Unlike RAID Level 3, however, a RAID Level 4 array's > member disks are independently accessible. Its performance is therefore > more suited to transaction I/O than large file transfers. Raid Level 4 is > seldom implemented without accompanying technology, such as a write-back > cache, because the dedicated parity disk represents an inherent write > bottleneck. Is this all they say about it? It begs the question why RAID-3 must access all members of the disk at a time. The only reason I can think of is that the data is interleaved in such a manner that you can't get *any* useful data without reading them all. This rather agrees with the idea that the data is spread in units of less than a sector. It also doesn't say why RAID-4 is less suitable for large file transfers. My understanding is that RAID-3, effectively striping at a sub-sector level, can give much higher data rates without buffering, and that's its raison d'être. >>> In RAID4, it is supposed to be a multiple of your transaction size >> >> Where do you get the term "transaction" from? I haven't seen it in > > From the dictionary? 8-) > > The point is that your system is such that you may be able to > satisfy a request by only reading one component of the stripe. That's one point. My point is that a transaction may be of various sizes, whereas the stripe has a fixed size. >> any RAID documentation. In ufs, there is no fixed size. > > Sure there is, the block size (i.e. 8k.) ufs has a block size, sure, but the transfers are very seldom equal to the block size. > But then again, you wouldn't usually use RAID 3 or 4 for a > filesystem. Agreed. I wouldn't use RAID-4 for anything. >>> and RMW operations to update the parity for updating contiguous >>> transactions that are not as large as the stripe. >> >> I'd call both of these RAID-4, considering that RAID doesn't use the >> term "transaction". > > Sure it does. Is this in The Book as well? How is it defined? > In RAID-3, your transaction size *is* the stripe size. In RAID-4, > it may be less than the stripe size. So what is it in the Pluto implementation that stops you from reading only part of a RAID-3 stripe? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 17:29:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id ECC3E3FD2; Tue, 1 Feb 2000 17:29:23 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id SAA00438; Tue, 1 Feb 2000 18:29:30 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002020129.SAA00438@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Greg Lehey Cc: "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: hardware vs software stripping In-reply-to: Your message of "Wed, 02 Feb 2000 11:27:55 +1030." <20000202112755.L55303@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Tue, 01 Feb 2000 18:29:30 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [summary or raid types] >Is this all they say about it? That's from the summary section. >It begs the question why RAID-3 must >access all members of the disk at a time. The only reason I can think >of is that the data is interleaved in such a manner that you can't get >*any* useful data without reading them all. This rather agrees with >the idea that the data is spread in units of less than a sector. It >also doesn't say why RAID-4 is less suitable for large file >transfers. The point is that the complexity of RAID 4 buys little if all you want to do is write large files. >My understanding is that RAID-3, effectively striping at a sub-sector >level, can give much higher data rates without buffering, and that's >its raison d'=EAtre. If you stripe at the sub-sector level, you must perform RMW. This makes absolutely no sense. >>>> In RAID4, it is supposed to be a multiple of your transaction size >>> >>> Where do you get the term "transaction" from? I haven't seen it in >> >> From the dictionary? 8-) >> >> The point is that your system is such that you may be able to >> satisfy a request by only reading one component of the stripe. > >That's one point. My point is that a transaction may be of various >sizes, whereas the stripe has a fixed size. If your transaction is larger, perhaps you satisfy it by modifying 1 or more full stripes and only partially modifying the border stripes. The point is still the same. >>> any RAID documentation. In ufs, there is no fixed size. >> >> Sure there is, the block size (i.e. 8k.) > >ufs has a block size, sure, but the transfers are very seldom equal to >the block size. Lets say that you do 64k "strips" on each drive. To satisfy an 8k transa= ction, you only need to touch on drive (and the parity disk on a write). To sat= isfy a 128k transaction, you touch at most 4 (3 if your transaction is aligned= ). You don't need to touch all N. That is the difference. >>> I'd call both of these RAID-4, considering that RAID doesn't use the >>> term "transaction". >> >> Sure it does. > >Is this in The Book as well? How is it defined? The same way it is defined in the dictionary. The way you determine which RAID type is appropriate for you is by looking at the number of disks you have, the efficient disk strip size, as well as the transaction= type and size of your application. That's what this is all about. >> In RAID-3, your transaction size *is* the stripe size. In RAID-4, >> it may be less than the stripe size. > >So what is it in the Pluto implementation that stops you from >reading only part of a RAID-3 stripe? We could read part of a RAID-3 stripe if we decided the software complexity warranted it. In our application, it makes more sense to read the entire stripe and cache it rather than read individual chunks. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 1 18: 3:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id 9A0BB3FEA; Tue, 1 Feb 2000 18:03:25 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA56857; Wed, 2 Feb 2000 12:33:17 +1030 (CST) Date: Wed, 2 Feb 2000 12:33:17 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Definitions of RAID levels (was: hardware vs software stripping) Message-ID: <20000202123317.P55303@freebie.lemis.com> References: <20000202112755.L55303@freebie.lemis.com> <200002020129.SAA00438@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i In-Reply-To: <200002020129.SAA00438@caspian.plutotech.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 1 February 2000 at 18:29:30 -0700, Justin T. Gibbs wrote: > [summary or raid types] > >> Is this all they say about it? > > That's from the summary section. Ah. >> It begs the question why RAID-3 must access all members of the disk >> at a time. The only reason I can think of is that the data is >> interleaved in such a manner that you can't get *any* useful data >> without reading them all. This rather agrees with the idea that >> the data is spread in units of less than a sector. It also doesn't >> say why RAID-4 is less suitable for large file transfers. > > The point is that the complexity of RAID 4 buys little if all you > want to do is write large files. Right, but my understanding was that the RAID levels all describe different layouts, not access methods. I'm sure that the various strategies for accessing RAID-5 are very different. >> My understanding is that RAID-3, effectively striping at a sub-sector >> level, can give much higher data rates without buffering, and that's >> its raison d'être. > > If you stripe at the sub-sector level, you must perform RMW. This makes > absolutely no sense. I think you're misunderstanding my use of the term "stripe". I'm not talking about "transactions" here, I'm talking about layout. If I have a 9 disk RAID-[345] set with a stripe size of 64 bytes, I can read one sector from each of the 8 data disks and have a total of 8 sectors. I can do the same thing if each disk contains an individual bit of a byte. Older disk and drum technology used a very similar method (multiple heads) to speed up transfer times. With relatively simple hardware support, this would make a lot of sense, and if RAID-3 is really what you say, it makes me wonder why people haven't thought of this alternative. >>>>> In RAID4, it is supposed to be a multiple of your transaction >>>>> size so you can perform partial read (assuming you don't need >>>>> parity verification) >>>> >>>> Where do you get the term "transaction" from? I haven't seen it in >>> >>> From the dictionary? 8-) >>> >>> The point is that your system is such that you may be able to >>> satisfy a request by only reading one component of the stripe. >> >> That's one point. My point is that a transaction may be of various >> sizes, whereas the stripe has a fixed size. > > If your transaction is larger, perhaps you satisfy it by modifying 1 or > more full stripes and only partially modifying the border stripes. > The point is still the same. Well, I can't see that. You're saying that RAID-4 stripes should be a multiple of the transaction size, and I'm saying the "transaction" size is variable. The "point" seems to be that this is the main difference in your definitions of RAID-3 and RAID-4. >>>> any RAID documentation. In ufs, there is no fixed size. >>> >>> Sure there is, the block size (i.e. 8k.) >> >> ufs has a block size, sure, but the transfers are very seldom equal to >> the block size. > > Lets say that you do 64k "strips" on each drive. To satisfy an 8k > transaction, you only need to touch on drive (or maybe two if it goes off the end of the first strip. > (and the parity disk on a write). To satisfy a 128k transaction, > you touch at most 4 (3 if your transaction is aligned). You don't > need to touch all N. Sure. > That is the difference. From what? This thread was about the differences between RAID-3 and RAID-4. I don't see anything different in these definitions except possibly the software. >>>> I'd call both of these RAID-4, considering that RAID doesn't use the >>>> term "transaction". >>> >>> Sure it does. >> >> Is this in The Book as well? How is it defined? > > The same way it is defined in the dictionary. OK, let me get a dictionary: Transaction: 1. The adjustment of a dispute between parties by mutual concession; compromise. 2. The action of transacting. 3. That which is or has been transacted; a piece of business. 4. The action of passing or making over a thing from one person, thing, or state to another. 5. (pl) The record of it proceedings published by a learned society. I don't really think any of those definitions even come close to what we're talking about. Even in computer science, the term "transaction" normally has a different meaning. We *do* need to define what we're talking about here. > The way you determine which RAID type is appropriate for you is by > looking at the number of disks you have, the efficient disk strip > size, as well as the transaction type and size of your application. > That's what this is all about. Yes, but in order to do that you need to know what the RAID types are, and so far we have no agreement on what RAID-3 *is*. >>> In RAID-3, your transaction size *is* the stripe size. In RAID-4, >>> it may be less than the stripe size. >> >> So what is it in the Pluto implementation that stops you from >> reading only part of a RAID-3 stripe? > > We could read part of a RAID-3 stripe if we decided the software > complexity warranted it. In our application, it makes more sense > to read the entire stripe and cache it rather than read individual > chunks. OK, and you could do this without changing the physical layout? In that case, I'd suggest this is RAID-4, not RAID-3. Note that the text you quote states: Unlike RAID Level 3, however, a RAID Level 4 array's member disks are independently accessible. This still suggests to me that there is something about RAID-3 layout, not the software implementation, which makes it impossible to access drives individually. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 2 7:31:19 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id 96BC7407B; Wed, 2 Feb 2000 07:31:07 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id IAA00607; Wed, 2 Feb 2000 08:31:21 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002021531.IAA00607@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Greg Lehey Cc: "Justin T. Gibbs" , Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: Definitions of RAID levels (was: hardware vs software stripping) In-reply-to: Your message of "Wed, 02 Feb 2000 12:33:17 +1030." <20000202123317.P55303@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Feb 2000 08:31:21 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>> My understanding is that RAID-3, effectively striping at a sub-sector= >>> level, can give much higher data rates without buffering, and that's >>> its raison d'=EAtre. >> >> If you stripe at the sub-sector level, you must perform RMW. This mak= es >> absolutely no sense. > >I think you're misunderstanding my use of the term "stripe". I'm not >talking about "transactions" here, I'm talking about layout. If I >have a 9 disk RAID-[345] set with a stripe size of 64 bytes, I can >read one sector from each of the 8 data disks and have a total of 8 >sectors. I can do the same thing if each disk contains an individual >bit of a byte. Older disk and drum technology used a very similar >method (multiple heads) to speed up transfer times. With relatively >simple hardware support, this would make a lot of sense, and if RAID-3 >is really what you say, it makes me wonder why people haven't thought >of this alternative. Take a look at this diagram: http://sunsite.berkeley.edu/Dienst/UI/2.0/Page/ncstrl.ucb/CSD-87-391/16 They don't use "minimum transaction size", they use "transfer units". Its the same thing. In this example, the "transfer unit" is a sector. In Pluto's system, the effective sector size is 64K (its too inefficient to perform sector I/O) and the "transfer unit" is a block of video frames= =2E If we are recording uncompressed video, a video frame is ~500K. This mea= ns you must read more than one of the drives in a stripe in order to get the= entire frame, but it may be possible to not read them all to get just a single frame. This is what I meant by our system allowing independent access, but my assertion that it didn't buy us anything. Putting all of a particular frame's data on a single drive would yield too much latency for random frame fetches, so we don't use that layout. The main point I've been trying to make in all of this is that the data need not be bit or byte striped. In the example in the Berkeley paper, the disk strip size is 1/4th of a sector. The distinction is all based o= n what your "record" size is and whether you can store records without crossing disk boundaries so it makes sense to allow independent access. >> If your transaction is larger, perhaps you satisfy it by modifying 1 o= r >> more full stripes and only partially modifying the border stripes. >> The point is still the same. > >Well, I can't see that. You're saying that RAID-4 stripes should be a >multiple of the transaction size, and I'm saying the "transaction" >size is variable. The "point" seems to be that this is the main >difference in your definitions of RAID-3 and RAID-4. If a user requests to read 64K of a file on an 8K file system, can you not see that on a system where each block is on an independent spindle and those 64K happen to be contiguous that you are not forced to make more than 10 read transactions even if your stripe covered more disks than that? If, on the other hand, you striped each 8k block across all drives, you'd not have that luxury. That is the difference. >> That is the difference. > >>From what? This thread was about the differences between RAID-3 and >RAID-4. I don't see anything different in these definitions except >possibly the software. I give up then. I don't know how to make it any clearer. >> The same way it is defined in the dictionary. = > >OK, let me get a dictionary: > > 4. The action of passing or making over a thing from > one person, thing, or state to another. This is the correct definition. Add "minimum sized" in front of transaction and you should get the right idea. If you don't like that term, use "unit transfer". >OK, and you could do this without changing the physical layout? In >that case, I'd suggest this is RAID-4, not RAID-3. Note that the text >you quote states: It is only RAID-4 if you can access a single disk and get all of the required data to do something useful. This is not the case in our system. > Unlike RAID Level 3, however, a RAID Level 4 array's member disks > are independently accessible. > >This still suggests to me that there is something about RAID-3 layout, >not the software implementation, which makes it impossible to access >drives individually. I've already covered why this is the case. There was also the assumption= in the past that the spindles would be synchronized. This is no longer the typical case. Anyway, that's all I have to say about RAID levels. I'm sorry I ever brought it up. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 2 18:22: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by builder.freebsd.org (Postfix) with ESMTP id 641814231; Wed, 2 Feb 2000 18:21:49 -0800 (PST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA18871; Thu, 3 Feb 2000 12:20:27 +1030 (CST) Date: Thu, 3 Feb 2000 12:20:27 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: Gary Palmer , scsi@FreeBSD.org, up@3.am, Wilko Bulte Subject: Re: Definitions of RAID levels (was: hardware vs software stripping) Message-ID: <20000203122027.O55303@freebie.lemis.com> References: <20000202123317.P55303@freebie.lemis.com> <200002021531.IAA00607@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i In-Reply-To: <200002021531.IAA00607@caspian.plutotech.com> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wednesday, 2 February 2000 at 8:31:21 -0700, Justin T. Gibbs wrote: >>>> My understanding is that RAID-3, effectively striping at a sub-sector >>>> level, can give much higher data rates without buffering, and that's >>>> its raison d'être. >>> >>> If you stripe at the sub-sector level, you must perform RMW. This makes >>> absolutely no sense. >> >> I think you're misunderstanding my use of the term "stripe". I'm not >> talking about "transactions" here, I'm talking about layout. If I >> have a 9 disk RAID-[345] set with a stripe size of 64 bytes, I can >> read one sector from each of the 8 data disks and have a total of 8 >> sectors. I can do the same thing if each disk contains an individual >> bit of a byte. Older disk and drum technology used a very similar >> method (multiple heads) to speed up transfer times. With relatively >> simple hardware support, this would make a lot of sense, and if RAID-3 >> is really what you say, it makes me wonder why people haven't thought >> of this alternative. > > Take a look at this diagram: > > http://sunsite.berkeley.edu/Dienst/UI/2.0/Page/ncstrl.ucb/CSD-87-391/16 Nice. Thanks for the pointer. > They don't use "minimum transaction size", they use "transfer units". > Its the same thing. In this example, the "transfer unit" is a > sector. I think this is a very important part of the example. > In Pluto's system, the effective sector size is 64K (its too > inefficient to perform sector I/O) and the "transfer unit" is a > block of video frames. OK, but the RAID-3 example shows that individual sectors contain data for all four of the transfer units; effectively it has mapped data in units of 128 bytes, a sub-sector division, which is what I have been saying all the time. > If we are recording uncompressed video, a video frame is ~500K. > This means you must read more than one of the drives in a stripe in > order to get the entire frame, but it may be possible to not read > them all to get just a single frame. This is what I meant by our > system allowing independent access, but my assertion that it didn't > buy us anything. Putting all of a particular frame's data on a > single drive would yield too much latency for random frame fetches, > so we don't use that layout. Sure. I have no issue with the way you're doing things; it makes a lot of sense. > The main point I've been trying to make in all of this is that the > data need not be bit or byte striped. In the example in the > Berkeley paper, the disk strip size is 1/4th of a sector. The > distinction is all based on what your "record" size is and whether > you can store records without crossing disk boundaries so it makes > sense to allow independent access. Now that's the point I've been trying to make. Unfortunately, the example doesn't make it clear how the striping would be if we were transferring, say, 4 sectors. Based on the fact that we can't generally determine the size of the transfer in advance, I'd claim that this mapping would remain if you increase the transfer size to, say, 1 MB. As I said earlier, with appropriate hardware support, this can be a very efficient way of handling large transfers. Without this support, such as in a FreeBSD environment, it doesn't make any sense. >>> If your transaction is larger, perhaps you satisfy it by modifying 1 or >>> more full stripes and only partially modifying the border stripes. >>> The point is still the same. >> >> Well, I can't see that. You're saying that RAID-4 stripes should be a >> multiple of the transaction size, and I'm saying the "transaction" >> size is variable. The "point" seems to be that this is the main >> difference in your definitions of RAID-3 and RAID-4. > > If a user requests to read 64K of a file on an 8K file system, can you > not see that on a system where each block is on an independent spindle > and those 64K happen to be contiguous that you are not forced to make > more than 10 read transactions even if your stripe covered more disks > than that? Indeed I can. That's why I recommend large stripe sizes. > If, on the other hand, you striped each 8k block across all drives, > you'd not have that luxury. That is the difference. I think we've got hung up on this definition of "transaction". I'd prefer to leave the transfer size out of it and look at the mapping to disk. >> OK, and you could do this without changing the physical layout? In >> that case, I'd suggest this is RAID-4, not RAID-3. Note that the text >> you quote states: > > It is only RAID-4 if you can access a single disk and get all of the > required data to do something useful. This is not the case in our > system. If I have a RAID-5 plex with 8 kB stripes, and I make a 32 kB transfer (both nothing exceptional: though I disapprove of such small stripes, it seems some vendors recommend them), I can't get all the required data from one drive. In fact, I may not be able to get it from one stripe. I don't think this makes it any less RAID-5. >> Unlike RAID Level 3, however, a RAID Level 4 array's member disks >> are independently accessible. >> >> This still suggests to me that there is something about RAID-3 layout, >> not the software implementation, which makes it impossible to access >> drives individually. > > I've already covered why this is the case. There was also the > assumption in the past that the spindles would be synchronized. > This is no longer the typical case. Agreed. But there's a difference between being able to read a sector from a disk, and having to read the whole stripe even if you only want a sector. > Anyway, that's all I have to say about RAID levels. I'm sorry I > ever brought it up. Well, sorry if I have to disagree with you, but I do believe it's important to get our definitions correct. I'm not criticizing the Pluto implementation, which makes sense to me, but I still haven't seen any evidence that it's RAID-3. I'd call it RAID-4. As I said before, I don't believe that RAID-3 is much use with modern hardware. The URL you sent is obviously part of something larger. I'll check it out. Thanks again for the pointer. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 4 3:28:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by builder.freebsd.org (Postfix) with ESMTP id 52DC53EF2; Fri, 4 Feb 2000 03:28:49 -0800 (PST) Received: from m4.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX9912-Fujitsu Gateway) id UAA16562; Fri, 4 Feb 2000 20:29:04 +0900 (JST) (envelope-from toyonaga@mail.msd.ts.fujitsu.co.jp) Received: from mail.msd.ts.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id UAA12691; Fri, 4 Feb 2000 20:29:04 +0900 (JST) Received: from mail.msd.ts.fujitsu.co.jp (localhost [127.0.0.1]) by mail.msd.ts.fujitsu.co.jp (8.9.3/8.9.3) with ESMTP id UAA86251; Fri, 4 Feb 2000 20:29:03 +0900 (JST) (envelope-from toyonaga@mail.msd.ts.fujitsu.co.jp) Message-Id: <200002041129.UAA86251@mail.msd.ts.fujitsu.co.jp> To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org, toyonaga@rr.iij4u.or.jp Reply-To: toyonaga@msd.ts.fujitsu.co.jp Subject: First attempt with new adw driver In-reply-to: Your message of "Wed, 02 Feb 2000 13:21:48 MST." <200002022021.NAA01144@caspian.plutotech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <86138.949663283.0@mail.msd.ts.fujitsu.co.jp> Date: Fri, 04 Feb 2000 20:29:03 +0900 From: =?ISO-2022-JP?B?GyRCSy0xSkMjP00bKEI=?= Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86138.949663283.1@mail.msd.ts.fujitsu.co.jp> Content-Transfer-Encoding: 7bit Hi, I'm now running up-to-date current with new adw driver. My machine is an old PentiumPro box with 64M of RAM. There installed was Windows95 and I checked there that the machine recognizes Advansys card successfully. I did the following. [Preparations] * Ensure the Hardware compatibity with Windows95. * Install the system a. install 4.0-20000127-CURRENT to ad0. b. at /usr, "cvs -d [My CTM repo] co src" to get most recent source. c. buildworld, install xinstall, installworld d. rm sys/dev/advansys/*.[ch] and did "cvs update -D 20000131 -Pd" to prepare for the U2W diffs. apply patch. e. strip of unnessecary device entry from kernel config, add DDB stuff, SOFTDEP, ccd and config -g, then make install new kernel f. add disk with /stand/sysinstall's fdisk menu and then newfs. [Tests] 1 The port "rawio" on /dev/rda0c -- ran fine. 2. postgresql version 6.5.3 set database dir to da0c a. regression test suite shipped with distribution -- succeeded. b. wisconsin benchmark suite shipped with distribution -- succeeded. c. pgbench version 1.1 from ftp://ftp.sra.co.jp/pub/cmd/postgres -- crashed 2 times. 3. tar cf - src | ( cd /data1; tar xvBpf -) to copy entire current src from ad0 to da2 -- crashed. I have DDB option in kernel but at this moment no crash dump is extracted since "panic" ddb command has no effect (because of limited RAM/swap?, dumpdev is set to /dev/ad0s1b). I'll switch to another machine with more RAM and CPU power next week. Also with LVD terminater to experience U2W speed. I noticed that the order of device listed at boot time is not in order. (see attachement) In message <200002022021.NAA01144@caspian.plutotech.com>, "Justin T. Gibbs" wri tes: >I don't think you'll need to touch the CAM_DEBUG options unless you >run into an error. I've tested both LVD and SE cards using benchmarks >and they appear to function correctly. I'm mostly concerned with >multi-device configurations or other error scenarios (bad-cable perhaps) >to see how well the error recovery performs. ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="MSD2000"; charset="us-ascii" Content-ID: <86138.949663283.2@mail.msd.ts.fujitsu.co.jp> Content-Description: kernel config file Content-Transfer-Encoding: 7bit # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.240 2000/02/01 09:32:04 n_hibma Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident MSD2000 maxusers 64 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options ICMP_BANDLIM # Rate limit bad replies # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa #device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 #device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Teckram DC-390(T)) #device dpt # DPT Smartcache - See LINT for options! #device isp # Qlogic family #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets) #device adv0 at isa? device adw #device bt0 at isa? #device aha0 at isa? #device aic0 at isa? # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers #device amr # AMI MegaRAID #device mlx # Mylex DAC960 family # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? # Advanced Power Management # PCCARD (PCMCIA) support #device card #device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 #device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 #device sio2 at isa? disable port IO_COM3 irq 5 #device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device tx # SMC 9432TX (83c170 ``EPIC'') device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. #device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. #device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 #device ex #device ep # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. #device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. #device an # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device fe0 at isa? port 0x300 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # requires PCCARD (PCMCIA) support to be activated #device xe0 at isa? # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse # USB Ethernet #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet pseudo-device ccd 4 #Concatenated disk driver options SOFTUPDATES options DDB options DDB_UNATTENDED ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="dmesg.out"; charset="us-ascii" Content-ID: <86138.949663283.3@mail.msd.ts.fujitsu.co.jp> Content-Description: boot messages Content-Transfer-Encoding: 7bit Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #2: Fri Feb 4 15:19:32 JST 2000 toor@msd2000.msd.ts.fujitsu.co.jp:/usr/src/sys/compile/MSD2000 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (143.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x612 Stepping = 2 Features=0xf9ff real memory = 67108864 (65536K bytes) avail memory = 61919232 (60468K bytes) Preloaded elf kernel "kernel" at 0xc02fa000. ccd0-3: Concatenated disk drivers Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.1, connected at v1.1 pcib0: on motherboard pci0: on pcib0 isab0: at device 0.0 on pci0 isa0: on isab0 ata-pci0: port 0xfcf0-0xfcff irq 14 at device 1.0 on pci0 ata-pci0: Busmastering DMA not enabled ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 de0: port 0xfc00-0xfc7f mem 0xfebffc00-0xfebffc7f irq 11 at device 2.0 on pci0 de0: DEC DE500-XA 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:f8:1e:65:52 de0: driver is using old-style compatability shims vga-pci0: mem 0xf8000000-0xf9ffffff irq 9 at device 3.0 on pci0 adw0: port 0xf800-0xf8ff mem 0xfebff800-0xfebff8ff irq 5 at device 4.0 on pci0 adw0: SCSI ID 7, High & Low SE Term Enabled, LVD Term Enabled, Queue Depth 253 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ata-isa0: already registered as ata0 ata-isa1: already registered as ata1 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 Waiting 15 seconds for SCSI devices to settle ad0: 1549MB [3148/16/63] at ata0-master using BIOSPIO ad1: 405MB [989/15/56] at ata0-slave using BIOSPIO ad2: 405MB [989/15/56] at ata1-master using BIOSPIO ad3: 405MB [989/15/56] at ata1-slave using BIOSPIO de0: enabling 10baseT port Mounting root from ufs:/dev/ad0s1a da1 at adw0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da0 at adw0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da2 at adw0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) WARNING: / was not properly dismounted ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="df.out"; charset="us-ascii" Content-ID: <86138.949663283.4@mail.msd.ts.fujitsu.co.jp> Content-Description: disk layouts Content-Transfer-Encoding: 7bit Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 49583 25292 20325 55% / /dev/ad0s1f 1335719 752522 476340 61% /usr /dev/ad0s1e 19815 1116 17114 6% /var /dev/ccd0c 1207775 1 1111152 0% /ccd /dev/da0c 17369075 46677 15932872 0% /data /dev/da2c 17369075 13147 15966402 0% /data1 procfs 4 4 0 100% /proc ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86138.949663283.5@mail.msd.ts.fujitsu.co.jp> Content-Transfer-Encoding: 7bit >INN or Squid results would be very interesting. I started with PostgreSQL because it is more handy to set up and easy to load drives. ------- =_aaaaaaaaaa0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 4 6:20:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id 7E478413B; Fri, 4 Feb 2000 06:20:14 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id HAA06152; Fri, 4 Feb 2000 07:20:54 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002041420.HAA06152@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: toyonaga@msd.ts.fujitsu.co.jp Cc: "Justin T. Gibbs" , scsi@FreeBSD.org, toyonaga@rr.iij4u.or.jp Subject: Re: First attempt with new adw driver In-reply-to: Your message of "Fri, 04 Feb 2000 20:29:03 +0900." <200002041129.UAA86251@mail.msd.ts.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Feb 2000 07:20:54 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >I have DDB option in kernel but at this moment no crash dump is extracted >since"panic" ddb command has no effect (because of limited RAM/swap?, >dumpdev is set to /dev/ad0s1b). Even without the dump, you should be able to get a stack trace and the program counter at the time the panic occurred. This will be very important in determining why the system broke. For instance, it might be interested to see if you can reproduce the panic without softupdates and/or ccd. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 6 11:16:51 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from shemp.palomine.net (shemp.palomine.net [205.198.88.200]) by builder.freebsd.org (Postfix) with SMTP id 933193D1F for ; Sun, 6 Feb 2000 11:16:48 -0800 (PST) Received: (qmail 2606 invoked by uid 1000); 6 Feb 2000 19:17:44 -0000 Date: Sun, 6 Feb 2000 14:17:44 -0500 From: Chris Johnson To: freebsd-scsi@freebsd.org Subject: BT-948 timeouts Message-ID: <20000206141744.A2557@palomine.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just installed 3.4-RELEASE (and subsequently updated it to 3.4-STABLE), and I get lots of this kind of thing: Feb 5 15:49:44 buddy /kernel: bt0: No longer in timeout Feb 5 15:56:40 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4968e40 - timed out Feb 5 15:56:54 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4968e40 - timed out Feb 5 15:56:54 buddy /kernel: bt0: No longer in timeout Feb 5 16:01:41 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4966880 - timed out Feb 5 16:01:55 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4966880 - timed out Feb 5 16:01:55 buddy /kernel: bt0: No longer in timeout Feb 5 16:05:48 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4967680 - timed out Feb 5 16:06:02 buddy /kernel: (da0:bt0:0:6:0): CCB 0xc4967680 - timed out Feb 5 16:06:02 buddy /kernel: bt0: No longer in timeout The SCSI controller is a PCI Buslogic BT-948, with ISA compatibility mode (or whatever it's called) turned on (which was suggested in an archive message). The system seems to recover just fine from this, and I've successfully built world twice. When it does occur, though, the system seems to hang for a bit and then just pick up where it left off. I don't think that there are any hardware problems--this same box recently had an uptime of 460 days running Linux, with no apparent SCSI issues. I found a message in the archives in which someone else posted the same symptoms, but there hasn't been a response to it. Are there any known issues with the bt0 driver? Are there SCSI options I need to enable or disable? Should I just replace the card with another, better supported one? Below are the contents of dmesg.boot. Thanks in advance. Chris Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 232669895 Hz CPU: AMD-K6tm w/ multimedia extensions (232.67-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping = 2 Features=0x8001bf AMD Features=0x400<> real memory = 67108864 (65536K bytes) avail memory = 62857216 (61384K bytes) Bad DMI table checksum! Preloaded elf kernel "kernel" at 0xc0245000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc024509c. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 bt0: rev 0x08 int a irq 12 on pci0.18.0 bt0: BT-948 FW Rev. 5.07B Ultra Narrow SCSI Host Adapter, SCSI ID 7, 192 CCBs vga0: rev 0xd3 int a irq 9 on pci0.19.0 fxp0: rev 0x05 int a irq 10 on pci0.20.0 fxp0: Ethernet address 00:a0:c9:cc:88:02 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode bt: unit number (1) too high bt1 not found at 0x330 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert disabled, rule-based forwarding disabled, logging limite d to 100 packets/entry by default Waiting 10 seconds for SCSI devices to settle changing root device to da0s1a da0 at bt0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 6 23: 2: 7 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fwse.teligent.se (gateway.teligent.se [194.17.198.3]) by builder.freebsd.org (Postfix) with SMTP id 7D8D43DD8 for ; Sun, 6 Feb 2000 23:02:03 -0800 (PST) Date: Mon, 7 Feb 2000 08:02:21 +0100 (CET) To: scsi@freebsd.org Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Message-ID: Reply-To: alvermark@teligent.se From: Jakob Alvermark Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Maybe someone on this list can help me with this problem? There are two different card models, "2940 UW" and "2944 AU". And I know that 2.2.2 is quite old, but we can't just reinstall all the machines in a snap. This is a large and complex telecommunications system with several machines running FreeBSD, and over two million customer, so you see my problem. Thanks for any help. /Jakob On Thu, 3 Feb 2000, Peter Schwenk wrote: > You neglected to tell us the model of Adaptec SCSI card you are using. A= lso, > you do realize that FreeBSD 2.2.2 is a bit old. The last version of the = 2.x > line was 2.2.8. >=20 > Jakob Alvermark wrote: >=20 > > Hi All. > > > > We are having problems with FreeBSD 2.2.2 and some Adaptec SCSI card. > > This is the errors showing on the screen: > > > > "Timed Out in dataout phase. > > SCSISIGI=3D0xe6 > > SEQADDR=3D0x133 > > SCSISEQ=3D0x12 > > Issued Cannel A bus reset. > > 2 SCB's aborted " > > > > "The SCSI bus had locked up or lost connection with the harddrive > > again." > > > > I have only heard a rumor that there might be a problem with FreeBSD 2.= 2.2 > > and the Adaptec SCSI cards and heavy load. Is this true? > > > > This has happened to several machines. It seems to happen about once ev= ery > > week. The machines have quite heavy load at times. > > > > Is this a known problem? How to fix? Change SCSI-card to a different > > brand? Upgrade to a newer release of FreeBSD? > > > > Thanks in advance. > > > > Regards, > > Jakob Alvermark > > > > ------------------------------------------------------- > > Teligent AB, P.O. Box 213, S-149 23 Nyn=E4shamn, Sweden > > Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36 > > Direct +46-(0)8 520 660 32 > > >=20 > -- > PETER SCHWENK | UNIX System Administr= ator > Department of Mathematical Sciences | University of Delawar= e > schwenk@math.udel.edu | (302)831-0437 <-NEW!!= ! >=20 >=20 >=20 >=20 ------------------------------------------------------- Teligent AB, P.O. Box 213, S-149 23 Nyn=E4shamn, Sweden =20 Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36=20 Direct +46-(0)8 520 660 32=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 6 23:34: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from tgn2.tgn.net (tgn2.tgn.net [205.241.85.2]) by builder.freebsd.org (Postfix) with ESMTP id C661A3DFB for ; Sun, 6 Feb 2000 23:33:57 -0800 (PST) Received: from turbo ([63.196.210.178]) by tgn2.tgn.net (8.9.3/8.8.8) with SMTP id BAA05621; Mon, 7 Feb 2000 01:36:59 -0600 (CST) Message-ID: <01cb01bf713b$fcb82940$b2d2c43f@speedtoys.com> From: "Geoff Mohler" To: , References: Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) Date: Sun, 6 Feb 2000 23:21:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.3825.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dont quote me..I belive I was speaking to Rod Grimes a number of years ago when 2.2.x was a relevent OS level, and there was some talk about how Adp. changed the cards enough that they didnt work so well. I swithched to the 3940 cards at that time, (ya costs more, but I could get 2x the storage on the box with more performance) and that fixed me up without an OS upgrade. ----- Original Message ----- From: "Jakob Alvermark" To: Sent: Sunday, February 06, 2000 11:02 PM Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) > Maybe someone on this list can help me with this problem? > > There are two different card models, "2940 UW" and "2944 AU". > And I know that 2.2.2 is quite old, but we can't just reinstall all the > machines in a snap. This is a large and complex telecommunications system > with several machines running FreeBSD, and over two million customer, so > you see my problem. > > Thanks for any help. > > /Jakob > > On Thu, 3 Feb 2000, Peter Schwenk wrote: > > > You neglected to tell us the model of Adaptec SCSI card you are using. Also, > > you do realize that FreeBSD 2.2.2 is a bit old. The last version of the 2.x > > line was 2.2.8. > > > > Jakob Alvermark wrote: > > > > > Hi All. > > > > > > We are having problems with FreeBSD 2.2.2 and some Adaptec SCSI card. > > > This is the errors showing on the screen: > > > > > > "Timed Out in dataout phase. > > > SCSISIGI=0xe6 > > > SEQADDR=0x133 > > > SCSISEQ=0x12 > > > Issued Cannel A bus reset. > > > 2 SCB's aborted " > > > > > > "The SCSI bus had locked up or lost connection with the harddrive > > > again." > > > > > > I have only heard a rumor that there might be a problem with FreeBSD 2.2.2 > > > and the Adaptec SCSI cards and heavy load. Is this true? > > > > > > This has happened to several machines. It seems to happen about once every > > > week. The machines have quite heavy load at times. > > > > > > Is this a known problem? How to fix? Change SCSI-card to a different > > > brand? Upgrade to a newer release of FreeBSD? > > > > > > Thanks in advance. > > > > > > Regards, > > > Jakob Alvermark > > > > > > ------------------------------------------------------- > > > Teligent AB, P.O. Box 213, S-149 23 Nynäshamn, Sweden > > > Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36 > > > Direct +46-(0)8 520 660 32 > > > > > > > -- > > PETER SCHWENK | UNIX System Administrator > > Department of Mathematical Sciences | University of Delaware > > schwenk@math.udel.edu | (302)831-0437 <-NEW!!! > > > > > > > > > > ------------------------------------------------------- > Teligent AB, P.O. Box 213, S-149 23 Nynäshamn, Sweden > Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36 > Direct +46-(0)8 520 660 32 > > > > > 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 Feb 7 6:48:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by builder.freebsd.org (Postfix) with ESMTP id 370F73F45 for ; Mon, 7 Feb 2000 06:48:12 -0800 (PST) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id HAA43271; Mon, 7 Feb 2000 07:35:22 -0700 (MST) Date: Mon, 7 Feb 2000 07:35:22 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200002071435.HAA43271@narnia.plutotech.com> To: Chris Johnson Cc: scsi@FreeBSD.org Subject: Re: BT-948 timeouts X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <20000206141744.A2557@palomine.net> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <20000206141744.A2557@palomine.net> you wrote: > I just installed 3.4-RELEASE (and subsequently updated it to 3.4-STABLE), and I > get lots of this kind of thing: > > da0 at bt0 bus 0 target 6 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > da0: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) The buslogic cards don't give any indication of the "queue full" condition. This means that CAM cannot know when to reduce the number of commands sent to a device if it can only handle a few. My guess is that the buslogic firmware is not gracefully dealing with the queue full condition so we see timeouts. My hunch is that if you forced the number of concurrent transactions down to 8 (what I recall is the limit for this drive), then your timeouts will cease. You can do this with the "camcontrol tags" command. In the case of the Linux driver, the greatest number of tags it will automatically assign to any one device is 31 (typically a range of 10-31 tags). You can manually bump this up to 64, but that is the max. CAM on the other hand, has a round-robin scheduler to maintain tag fairness, so if there is only one device active on the bus, it will be allowed to consume all controller resources unless there is a lower, per-device, limit in place. In the current FreeBSD driver, we don't limit the per-device count at all. My guess is that this difference in algorithms accounts for why Linux seems to work. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 7 7: 1: 0 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from camail2.harvard.edu (camail2.harvard.edu [128.103.26.23]) by builder.freebsd.org (Postfix) with ESMTP id E66983F86 for ; Mon, 7 Feb 2000 07:00:46 -0800 (PST) Received: from apache ([128.103.107.99]) by camail2.harvard.edu (Post.Office MTA v3.5.2 release 221 ID# 0-59487U2000L200S0V35) with SMTP id edu for ; Mon, 7 Feb 2000 10:06:45 -0500 From: "David LaPorte" To: Subject: Installing 3.4 with a AIC-7899 Date: Mon, 7 Feb 2000 09:59:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having some difficulty installing FreeBSD 3.4 on a Dell Precision 420. The motherboard has an on-board AIC7899 Ultra 160 controller that does not get recognized. I tried a quick Mandrake 7.0 install, and it was recognized as a AIC-7899 Ultra 160m. The FreeBSD HCL lists AIC-789X, so I assumed it'd be supported. Any thoughts on how to get this to work? Thanks, Dave LaPorte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 7 7:12:27 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by builder.freebsd.org (Postfix) with ESMTP id 7B0153F93 for ; Mon, 7 Feb 2000 07:12:24 -0800 (PST) Received: from mail.vt.edu (gkar.cc.vt.edu [128.173.16.40]) by sable.cc.vt.edu (8.9.3/8.9.3) with ESMTP id KAA13631 for ; Mon, 7 Feb 2000 10:12:58 -0500 (EST) Received: from gemorga2 ([198.82.100.74]) by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FPK00CL5FLLUN@gkar.cc.vt.edu> for freebsd-scsi@freebsd.org; Mon, 7 Feb 2000 10:12:58 -0500 (EST) Date: Mon, 07 Feb 2000 10:12:57 -0500 From: George Morgan Subject: Rescan for Devices... To: freebsd-scsi@freebsd.org Message-id: <0FPK00CL6FLLUN@gkar.cc.vt.edu> MIME-version: 1.0 X-Mailer: Pegasus Mail for Win32 (v3.12b) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a way to use the *BSD command "scsi" to rescan for devices on a scsi controller? I'm actually trying to do this on an OpenBSD 2.6 (sparc) machine, but I know there are some people that really know SCSI well on this list... Thank you for your time. George Morgan Virginia Tech Electrical Engineering Class of 2000! (Graduating in 2001, Co-op) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 7 7:54:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 6C2EC3F9E for ; Mon, 7 Feb 2000 07:54:09 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id IAA21640; Mon, 7 Feb 2000 08:54:48 -0700 (MST) (envelope-from ken) Date: Mon, 7 Feb 2000 08:54:48 -0700 From: "Kenneth D. Merry" To: David LaPorte Cc: scsi@FreeBSD.ORG Subject: Re: Installing 3.4 with a AIC-7899 Message-ID: <20000207085448.A21613@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from david_laporte@harvard.edu on Mon, Feb 07, 2000 at 09:59:03AM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 09:59:03 -0500, David LaPorte wrote: > I'm having some difficulty installing FreeBSD 3.4 on a Dell Precision 420. > The motherboard has an on-board AIC7899 Ultra 160 controller that does not > get recognized. I tried a quick Mandrake 7.0 install, and it was recognized > as a AIC-7899 Ultra 160m. The FreeBSD HCL lists AIC-789X, so I assumed it'd > be supported. > > Any thoughts on how to get this to work? 3.4 supported all the 789x chips that were out at the time. :) Anyway, 3.4 doesn't support the Ultra160 chips. -current does, and I'm sure Justin will be porting the changes back to -stable before too long. If you want to install now, grab a 4.0-current snapshot from: ftp://current.FreeBSD.org/ and install it. Right now, the Ultra160 chips only run at Ultra2 speed, but that should be fixed before too long as well. 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 Feb 7 10:39:35 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by builder.freebsd.org (Postfix) with ESMTP id 826F542BF for ; Mon, 7 Feb 2000 10:39:17 -0800 (PST) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA31313; Mon, 7 Feb 2000 19:35:02 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00633; Mon, 7 Feb 2000 19:10:37 +0100 (CET) (envelope-from wilko) Date: Mon, 7 Feb 2000 19:10:37 +0100 From: Wilko Bulte To: George Morgan Cc: freebsd-scsi@freebsd.org Subject: Re: Rescan for Devices... Message-ID: <20000207191037.A386@yedi.iaf.nl> References: <0FPK00CL6FLLUN@gkar.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <0FPK00CL6FLLUN@gkar.cc.vt.edu>; from gemorga2@vt.edu on Mon, Feb 07, 2000 at 10:12:57AM -0500 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 10:12:57AM -0500, George Morgan wrote: > Is there a way to use the *BSD command "scsi" to rescan for > devices on a scsi controller? I'm actually trying to do this on an > OpenBSD 2.6 (sparc) machine, but I know there are some people > that really know SCSI well on this list... man camcontrol and then: camcontrol rescan Works just fine. -- Wilko Bulte Arnhem, The Netherlands WWW : http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 7 12:33:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id BB966429F for ; Mon, 7 Feb 2000 12:33:46 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA23381; Mon, 7 Feb 2000 13:34:26 -0700 (MST) (envelope-from ken) Date: Mon, 7 Feb 2000 13:34:26 -0700 From: "Kenneth D. Merry" To: alvermark@teligent.se Cc: scsi@FreeBSD.ORG Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) Message-ID: <20000207133426.A23334@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jakob@teligent.se on Mon, Feb 07, 2000 at 08:02:21AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 08:02:21 +0100, Jakob Alvermark wrote: > Maybe someone on this list can help me with this problem? > > There are two different card models, "2940 UW" and "2944 AU". > And I know that 2.2.2 is quite old, but we can't just reinstall all the > machines in a snap. This is a large and complex telecommunications system > with several machines running FreeBSD, and over two million customer, so > you see my problem. I'll repeat my answer for the benefit of the folks on -scsi: > On Thu, 3 Feb 2000, Peter Schwenk wrote: > > > You neglected to tell us the model of Adaptec SCSI card you are using. Also, > > you do realize that FreeBSD 2.2.2 is a bit old. The last version of the 2.x > > line was 2.2.8. > > > > Jakob Alvermark wrote: > > > > > Hi All. > > > > > > We are having problems with FreeBSD 2.2.2 and some Adaptec SCSI card. > > > This is the errors showing on the screen: > > > > > > "Timed Out in dataout phase. > > > SCSISIGI=0xe6 > > > SEQADDR=0x133 > > > SCSISEQ=0x12 > > > Issued Cannel A bus reset. > > > 2 SCB's aborted " > > > > > > "The SCSI bus had locked up or lost connection with the harddrive > > > again." > > > > > > I have only heard a rumor that there might be a problem with FreeBSD 2.2.2 > > > and the Adaptec SCSI cards and heavy load. Is this true? > > > > > > This has happened to several machines. It seems to happen about once every > > > week. The machines have quite heavy load at times. > > > > > > Is this a known problem? How to fix? Change SCSI-card to a different > > > brand? Upgrade to a newer release of FreeBSD? The "timed out in {datain|dataout|command}" phase messages almost always mean there is a cabling or termination problem on the bus. It means a signal got stuck on the bus somewhere. There were certainly bugs in the old SCSI layer that could get triggered under heavy load, but this isn't one of them. These sorts of problems can be intermittent, so it isn't surprising that you see them once a week under high load. The new Adaptec driver and the CAM SCSI layer handles problems like this a little better, but there are still no guarantees when signals are getting stuck on the bus. So check your cabling and termination. 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 Feb 7 13:26: 7 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by builder.freebsd.org (Postfix) with ESMTP id 1D4784013 for ; Mon, 7 Feb 2000 13:26:04 -0800 (PST) Received: from localhost (ppp-162-184.villette.club-internet.fr [195.36.162.184]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA02195; Mon, 7 Feb 2000 22:26:14 +0100 (MET) Date: Mon, 7 Feb 2000 22:55:33 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... In-Reply-To: <20000207191037.A386@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Feb 2000, Wilko Bulte wrote: > On Mon, Feb 07, 2000 at 10:12:57AM -0500, George Morgan wrote: > > Is there a way to use the *BSD command "scsi" to rescan for=20 > > devices on a scsi controller? I'm actually trying to do this on an=20 > > OpenBSD 2.6 (sparc) machine, but I know there are some people=20 > > that really know SCSI well on this list... >=20 > man camcontrol >=20 > and then: >=20 > camcontrol rescan >=20 > Works just fine. Not really for me, may-be since I donnot want to rescan the bus, but to just scan the bus for devices that haven't been seen by CAM at boot for some reason.=20 First attempt after having switched the box on and booted for the first time: at scbus1 target 0 lun 0 (da3,pass4) at scbus1 target 1 lun 0 (da2,pass3) at scbus1 target 4 lun 0 (da5,pass6) at scbus1 target 5 lun 0 (da4,pass5) Second attempt after having rebooted the machine: at scbus1 target 0 lun 0 (da4,pass5) at scbus1 target 1 lun 0 (da3,pass4) at scbus1 target 4 lun 0 (da2,pass3) at scbus1 target 5 lun 0 (da5,pass6) Problem is that the order of da# devices after first boot + scanbus 1 is different from order after second boot + scanbus 1.=20 I guess the reasons given that xpt_scan_bus() is scanning targets (excepted the initiator obviously) in parallel. I would think that such a concurrent target scanning can be faster than a sequential scanning, only if some devices, that are too long for responding to SCSI commands used for the probe, (probably INQUIRY) disconnect the BUS during the scan. But if this happens, or if some devices are reporting transient problems, then order of devices cannot be guaranteed on successive (reboots) + (re)scan of BUS. In my opinion, an option that will allow to request a sequential BUS (re)scan would be useful, not only for me.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 7 13:38: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 86D3D40C8 for ; Mon, 7 Feb 2000 13:38:04 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA24242; Mon, 7 Feb 2000 14:38:33 -0700 (MST) (envelope-from ken) Date: Mon, 7 Feb 2000 14:38:33 -0700 From: "Kenneth D. Merry" To: Gerard Roudier Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <20000207143833.A24212@panzer.kdm.org> References: <20000207191037.A386@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from groudier@club-internet.fr on Mon, Feb 07, 2000 at 10:55:33PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > On Mon, 7 Feb 2000, Wilko Bulte wrote: > > On Mon, Feb 07, 2000 at 10:12:57AM -0500, George Morgan wrote: > > > Is there a way to use the *BSD command "scsi" to rescan for > > > devices on a scsi controller? I'm actually trying to do this on an > > > OpenBSD 2.6 (sparc) machine, but I know there are some people > > > that really know SCSI well on this list... > > > > man camcontrol > > > > and then: > > > > camcontrol rescan > > > > Works just fine. > > Not really for me, may-be since I donnot want to rescan the bus, but to > just scan the bus for devices that haven't been seen by CAM at boot for > some reason. > > First attempt after having switched the box on and booted for the first > time: > > at scbus1 target 0 lun 0 (da3,pass4) > at scbus1 target 1 lun 0 (da2,pass3) > at scbus1 target 4 lun 0 (da5,pass6) > at scbus1 target 5 lun 0 (da4,pass5) > > Second attempt after having rebooted the machine: > > at scbus1 target 0 lun 0 (da4,pass5) > at scbus1 target 1 lun 0 (da3,pass4) > at scbus1 target 4 lun 0 (da2,pass3) > at scbus1 target 5 lun 0 (da5,pass6) > > Problem is that the order of da# devices after first boot + scanbus 1 is > different from order after second boot + scanbus 1. Which devices appear during the boot, and which ones appear after the rescan? It seems rather odd to me that your disks aren't showing up at boot. Are they not powered on or something? > I guess the reasons given that xpt_scan_bus() is scanning targets > (excepted the initiator obviously) in parallel. I would think that such a > concurrent target scanning can be faster than a sequential scanning, only > if some devices, that are too long for responding to SCSI commands used > for the probe, (probably INQUIRY) disconnect the BUS during the scan. But > if this happens, or if some devices are reporting transient problems, then > order of devices cannot be guaranteed on successive (reboots) + (re)scan > of BUS. > > In my opinion, an option that will allow to request a sequential BUS > (re)scan would be useful, not only for me. Devices are attached sequentially, unless you hard-wire them. If you rescan the bus, though, the disks are given the first available device number. If you want things to turn up in the same place every time, I would suggest hardwiring your disk device numbers to a specific bus/target/lun. 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 Feb 7 13:47:51 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 789623FE8 for ; Mon, 7 Feb 2000 13:47:41 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA24385; Mon, 7 Feb 2000 14:48:04 -0700 (MST) (envelope-from ken) Date: Mon, 7 Feb 2000 14:48:04 -0700 From: "Kenneth D. Merry" To: Gerard Roudier Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <20000207144804.A24368@panzer.kdm.org> References: <20000207191037.A386@yedi.iaf.nl> <20000207143833.A24212@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000207143833.A24212@panzer.kdm.org>; from ken@kdm.org on Mon, Feb 07, 2000 at 02:38:33PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 14:38:33 -0700, Kenneth D. Merry wrote: > On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > > I guess the reasons given that xpt_scan_bus() is scanning targets > > (excepted the initiator obviously) in parallel. I would think that such a > > concurrent target scanning can be faster than a sequential scanning, only > > if some devices, that are too long for responding to SCSI commands used > > for the probe, (probably INQUIRY) disconnect the BUS during the scan. But > > if this happens, or if some devices are reporting transient problems, then > > order of devices cannot be guaranteed on successive (reboots) + (re)scan > > of BUS. > > > > In my opinion, an option that will allow to request a sequential BUS > > (re)scan would be useful, not only for me. > > Devices are attached sequentially, unless you hard-wire them. If you > rescan the bus, though, the disks are given the first available device > number. > > If you want things to turn up in the same place every time, I would suggest > hardwiring your disk device numbers to a specific bus/target/lun. BTW, devices not probing in sequential order during a rescan is a known bug. You might want to file a PR, and then assign it to Justin. (He said it's on his list of things to fix.) Hardwiring should work around the problem, however. Hardwiring might be broken in -current, though, some people on the current list are complaining about it. 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 Feb 7 13:58:46 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from naiad.eclipse.net.uk (naiad.eclipse.net.uk [195.188.32.29]) by builder.freebsd.org (Postfix) with ESMTP id 6D7D84013 for ; Mon, 7 Feb 2000 13:58:44 -0800 (PST) Received: by naiad.eclipse.net.uk (Postfix, from userid 475) id 0E1F013225; Mon, 07 Feb 2000 21:59:29 +0000 (GMT) Date: Mon, 7 Feb 2000 21:59:28 +0000 From: Stuart Henderson To: Gerard Roudier Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <20000207215928.J18501@naiad.eclipse.net.uk> References: <20000207191037.A386@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from groudier@club-internet.fr on Mon, Feb 07, 2000 at 10:55:33PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 10:55:33PM +0100, Gerard Roudier wrote: > Problem is that the order of da# devices after first boot + scanbus 1 is > different from order after second boot + scanbus 1. > > I guess the reasons given that xpt_scan_bus() is scanning targets > (excepted the initiator obviously) in parallel. I would think that such a > concurrent target scanning can be faster than a sequential scanning, only > if some devices, that are too long for responding to SCSI commands used > for the probe, (probably INQUIRY) disconnect the BUS during the scan. But > if this happens, or if some devices are reporting transient problems, then > order of devices cannot be guaranteed on successive (reboots) + (re)scan > of BUS. > > In my opinion, an option that will allow to request a sequential BUS > (re)scan would be useful, not only for me. Would it not be more general (and apply also for unexpected conditions during initial system boot) to wire-down devices in kernel configuration? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 2:10:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fwse.teligent.se (gateway.teligent.se [194.17.198.3]) by builder.freebsd.org (Postfix) with SMTP id 06D26419C for ; Tue, 8 Feb 2000 02:10:05 -0800 (PST) Date: Tue, 8 Feb 2000 11:10:24 +0100 (CET) To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Message-ID: In-Reply-To: <20000207133426.A23334@teligent.se> Reply-To: alvermark@teligent.se From: Jakob Alvermark Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > On Mon, Feb 07, 2000 at 08:02:21 +0100, Jakob Alvermark wrote: > > Maybe someone on this list can help me with this problem? > >=20 > > There are two different card models, "2940 UW" and "2944 AU". > > And I know that 2.2.2 is quite old, but we can't just reinstall all the > > machines in a snap. This is a large and complex telecommunications syst= em > > with several machines running FreeBSD, and over two million customer, s= o > > you see my problem. >=20 > I'll repeat my answer for the benefit of the folks on -scsi: >=20 > > On Thu, 3 Feb 2000, Peter Schwenk wrote: > >=20 > > > You neglected to tell us the model of Adaptec SCSI card you are using= =2E Also, > > > you do realize that FreeBSD 2.2.2 is a bit old. The last version of = the 2.x > > > line was 2.2.8. > > >=20 > > > Jakob Alvermark wrote: > > >=20 > > > > Hi All. > > > > > > > > We are having problems with FreeBSD 2.2.2 and some Adaptec SCSI car= d. > > > > This is the errors showing on the screen: > > > > > > > > "Timed Out in dataout phase. > > > > SCSISIGI=3D0xe6 > > > > SEQADDR=3D0x133 > > > > SCSISEQ=3D0x12 > > > > Issued Cannel A bus reset. > > > > 2 SCB's aborted " > > > > > > > > "The SCSI bus had locked up or lost connection with the harddrive > > > > again." > > > > > > > > I have only heard a rumor that there might be a problem with FreeBS= D 2.2.2 > > > > and the Adaptec SCSI cards and heavy load. Is this true? > > > > > > > > This has happened to several machines. It seems to happen about onc= e every > > > > week. The machines have quite heavy load at times. > > > > > > > > Is this a known problem? How to fix? Change SCSI-card to a differen= t > > > > brand? Upgrade to a newer release of FreeBSD? >=20 > The "timed out in {datain|dataout|command}" phase messages almost always > mean there is a cabling or termination problem on the bus. It means a > signal got stuck on the bus somewhere. >=20 > There were certainly bugs in the old SCSI layer that could get triggered > under heavy load, but this isn't one of them. >=20 > These sorts of problems can be intermittent, so it isn't surprising that > you see them once a week under high load. >=20 > The new Adaptec driver and the CAM SCSI layer handles problems like this = a > little better, but there are still no guarantees when signals are getting > stuck on the bus. >=20 > So check your cabling and termination. I have checked all the cabling and termination on one of the machines (which was sent to me). Everything seems ok, there is only one disk, which is terminated, and one cable. The SCSI-card itself was set to automatic termination, could that be a problem?=20 I was able to reproduce the problem by creating a number of processes that reads and writes a lot on the disk. After a couple of hours the machine froze and showed the above message. I have now changed the termination on the card to "ON", and running the same test. Thanks, =09Jakob Alvermark ------------------------------------------------------- Teligent AB, P.O. Box 213, S-149 23 Nyn=E4shamn, Sweden =20 Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36=20 Direct +46-(0)8 520 660 32=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 9:51:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 046B8436B for ; Tue, 8 Feb 2000 09:51:19 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA31129; Tue, 8 Feb 2000 10:51:50 -0700 (MST) (envelope-from ken) Date: Tue, 8 Feb 2000 10:51:50 -0700 From: "Kenneth D. Merry" To: alvermark@teligent.se Cc: scsi@FreeBSD.ORG Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) Message-ID: <20000208105150.A31083@panzer.kdm.org> References: <20000207133426.A23334@teligent.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jakob@teligent.se on Tue, Feb 08, 2000 at 11:10:24AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 08, 2000 at 11:10:24 +0100, Jakob Alvermark wrote: > On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > > The "timed out in {datain|dataout|command}" phase messages almost always > > mean there is a cabling or termination problem on the bus. It means a > > signal got stuck on the bus somewhere. > > > > There were certainly bugs in the old SCSI layer that could get triggered > > under heavy load, but this isn't one of them. > > > > These sorts of problems can be intermittent, so it isn't surprising that > > you see them once a week under high load. > > > > The new Adaptec driver and the CAM SCSI layer handles problems like this a > > little better, but there are still no guarantees when signals are getting > > stuck on the bus. > > > > So check your cabling and termination. > > I have checked all the cabling and termination on one of the machines > (which was sent to me). Everything seems ok, there is only one disk, which > is terminated, and one cable. The SCSI-card itself was set to automatic > termination, could that be a problem? It would only be a problem if the Adaptec driver isn't dealing with automatic termination properly in FreeBSD 2.2.2. That is certainly a possibility. > I was able to reproduce the problem by creating a number of processes that > reads and writes a lot on the disk. After a couple of hours the machine > froze and showed the above message. > > I have now changed the termination on the card to "ON", and running the > same test. You might also want to check and see if the cable is too close to the power supply. You may also want to just replace the cable with a new one and see what happens. I've got a cable that looks okay, yet it caused sporadic (every few days) SCSI parity errors. Replacing the cable got rid of the errors. 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 Tue Feb 8 10: 7:31 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from phred.org (sense-alexw-189.oz.net [216.39.149.189]) by builder.freebsd.org (Postfix) with ESMTP id 6CAE63E30 for ; Tue, 8 Feb 2000 10:07:05 -0800 (PST) Received: from AWETMOREDEV (root@localhost [127.0.0.1]) by phred.org (8.9.1a/8.9.1) with SMTP id KAA17057 for ; Tue, 8 Feb 2000 10:07:33 -0800 (PST) Message-ID: <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV> From: "alex wetmore" To: Subject: Problem with FreeBSD 2.2.2 and Archive Python 4586 DDS-2 autoloader (changer device not detected) Date: Tue, 8 Feb 2000 10:07:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [sorry if you see two copies of this message. I originally sent it via a news to mail gateway whch doesn't seem to be properly configured, so I'm sending again directly to the list). I'm running FreeBSD 2.2.2 on a server machine and this weekend I added a DDS-2 autoloader to get automated backups. FreeBSD will recognize the drive as a DDS drive, but doesn't see it as a changer, so the ch device and chio programs do not work. Here is the kernel output during probe: (ahc0:5:0): "ARCHIVE Python 29987-XXX 5AB" type 1 removable SCSI 2 st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty My kernel config is at http://www.phred.org/~alex/PHRED. The machine is a Pentium 200MMX on an ASUS SP97-VX motherboard and has an Adaptec 2940 (might be a 2940U) SCSI adapter. Also configured on the SCSI bus are 2 2g disks (ID 0 and 1) and a Sanyo 4x CD-ROM drive (ID 2). Is this a known issue that was fixed in a later release of FreeBSD? If I pass the ch driver a specific target SCSI ID and LUN would it be expected to find the device? My goal is to have 3 tapes + 1 cleaning tape in the autoloader. My backup pattern would be: * Sunday - clean (using tape 4), full backup to tape 1, erase tape 3 * every other weekday - incremental backup to tape 3 * Sunday (week 2) - clean (using tape 4), full backup to tape 2, erase tape 3 * every other weekday - incremental backup to tape 3 * repeat I also make periodic manual full backups to other tapes and bring those offsite. thanks, alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 10:17:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from saturn.tlug.org (cr545978-a.nmkt1.on.wave.home.com [24.112.25.43]) by builder.freebsd.org (Postfix) with ESMTP id 69BCC403F for ; Tue, 8 Feb 2000 10:17:35 -0800 (PST) Received: from localhost (mfrisch@localhost) by saturn.tlug.org (8.9.3/8.9.3) with ESMTP id NAA13911 for ; Tue, 8 Feb 2000 13:18:28 -0500 Date: Tue, 8 Feb 2000 13:18:28 -0500 (EST) From: Mike Frisch To: freebsd-scsi@freebsd.org Subject: Symbios 876 + Symbios 810 support 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 have a Diamond FirePort 40 Dual and a Symbios 810 based SCSI card in the same machine. I am experiencing spontaneous reboot problems when utilizing the hard drive on the FirePort when running under 3.4-STABLE. If I use 4.0-CURRENT, the system is stable. Is this a known problem for which there may be a solution for 3.4-STABLE? Thanks in advance, Mike. ====================================================================== Mike Frisch Email: mfrisch@saturn.tlug.org Northstar Technologies WWW: http://saturn.tlug.org/~mfrisch Newmarket, Ontario, CANADA ====================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 11:14:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fwse.teligent.se (gateway.teligent.se [194.17.198.3]) by builder.freebsd.org (Postfix) with SMTP id C083A3E90 for ; Tue, 8 Feb 2000 11:14:43 -0800 (PST) To: "Kenneth D. Merry" Cc: Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) Date: Mon, 7 Feb 2000 20:15:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 References: <20000207133426.A23334@teligent.se> <20000208105150.A31083@panzer.kdm.org> From: "Jakob Alvermark" Message-ID: <005101bf719f$b8a4a580$d14ea3c3@teligent.se> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Original Message ----- From: Kenneth D. Merry To: Cc: Sent: den 8 februari 2000 18:51 Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) > On Tue, Feb 08, 2000 at 11:10:24 +0100, Jakob Alvermark wrote: > > On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > > > The "timed out in {datain|dataout|command}" phase messages almost always > > > mean there is a cabling or termination problem on the bus. It means a > > > signal got stuck on the bus somewhere. > > > > > > There were certainly bugs in the old SCSI layer that could get triggered > > > under heavy load, but this isn't one of them. > > > > > > These sorts of problems can be intermittent, so it isn't surprising that > > > you see them once a week under high load. > > > > > > The new Adaptec driver and the CAM SCSI layer handles problems like this a > > > little better, but there are still no guarantees when signals are getting > > > stuck on the bus. > > > > > > So check your cabling and termination. > > > > I have checked all the cabling and termination on one of the machines > > (which was sent to me). Everything seems ok, there is only one disk, which > > is terminated, and one cable. The SCSI-card itself was set to automatic > > termination, could that be a problem? > > It would only be a problem if the Adaptec driver isn't dealing with > automatic termination properly in FreeBSD 2.2.2. That is certainly a > possibility. > > > I was able to reproduce the problem by creating a number of processes that > > reads and writes a lot on the disk. After a couple of hours the machine > > froze and showed the above message. > > > > I have now changed the termination on the card to "ON", and running the > > same test. > > You might also want to check and see if the cable is too close to the power > supply. You may also want to just replace the cable with a new one and see > what happens. > > I've got a cable that looks okay, yet it caused sporadic (every few days) > SCSI parity errors. Replacing the cable got rid of the errors. Broken cables seems unlikely, it happens on 4 machines, I don't think all of them could be broken. But the theory about closeness to the power supply is interesting. In the machine i opened, the cable was actually strapped to the power supply. Maybe I should let the cable hang freely? /Jakob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 11:41:21 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id D420342AE for ; Tue, 8 Feb 2000 11:41:17 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA31931; Tue, 8 Feb 2000 12:42:07 -0700 (MST) (envelope-from ken) Date: Tue, 8 Feb 2000 12:42:07 -0700 From: "Kenneth D. Merry" To: Jakob Alvermark Cc: scsi@FreeBSD.ORG Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) Message-ID: <20000208124207.A31905@panzer.kdm.org> References: <20000207133426.A23334@teligent.se> <20000208105150.A31083@panzer.kdm.org> <005101bf719f$b8a4a580$d14ea3c3@teligent.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <005101bf719f$b8a4a580$d14ea3c3@teligent.se>; from alvermark@teligent.se on Mon, Feb 07, 2000 at 08:15:38PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 20:15:38 +0100, Jakob Alvermark wrote: > ----- Original Message ----- > From: Kenneth D. Merry > To: > Cc: > Sent: den 8 februari 2000 18:51 > Subject: Re: Problems with Adaptec card and FreeBSD 2.2.2 (fwd) > > > You might also want to check and see if the cable is too close to the > power > > supply. You may also want to just replace the cable with a new one and > see > > what happens. > > > > I've got a cable that looks okay, yet it caused sporadic (every few days) > > SCSI parity errors. Replacing the cable got rid of the errors. > > Broken cables seems unlikely, it happens on 4 machines, I don't think all of > them could be broken. But the theory about closeness to the power supply is > interesting. In the machine i opened, the cable was actually strapped to the > power supply. > Maybe I should let the cable hang freely? Yes, and try to keep it as far away from the power supply as possible. 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 Tue Feb 8 11:47:24 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by builder.freebsd.org (Postfix) with ESMTP id 54D924118 for ; Tue, 8 Feb 2000 11:47:13 -0800 (PST) Received: from localhost (ppp-173-226.villette.club-internet.fr [195.36.173.226]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA16199; Tue, 8 Feb 2000 20:47:49 +0100 (MET) Date: Tue, 8 Feb 2000 21:17:21 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... In-Reply-To: <20000207143833.A24212@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > > On Mon, 7 Feb 2000, Wilko Bulte wrote: > > > On Mon, Feb 07, 2000 at 10:12:57AM -0500, George Morgan wrote: > > > > Is there a way to use the *BSD command "scsi" to rescan for=20 > > > > devices on a scsi controller? I'm actually trying to do this on an= =20 > > > > OpenBSD 2.6 (sparc) machine, but I know there are some people=20 > > > > that really know SCSI well on this list... > > >=20 > > > man camcontrol > > >=20 > > > and then: > > >=20 > > > camcontrol rescan > > >=20 > > > Works just fine. > >=20 > > Not really for me, may-be since I donnot want to rescan the bus, but to > > just scan the bus for devices that haven't been seen by CAM at boot for > > some reason.=20 > >=20 > > First attempt after having switched the box on and booted for the first > > time: > >=20 > > at scbus1 target 0 lun 0 (da3,pass4) > > at scbus1 target 1 lun 0 (da2,pass3) > > at scbus1 target 4 lun 0 (da5,pass6) > > at scbus1 target 5 lun 0 (da4,pass5) > >=20 > > Second attempt after having rebooted the machine: > >=20 > > at scbus1 target 0 lun 0 (da4,pass5) > > at scbus1 target 1 lun 0 (da3,pass4) > > at scbus1 target 4 lun 0 (da2,pass3) > > at scbus1 target 5 lun 0 (da5,pass6) > >=20 > > Problem is that the order of da# devices after first boot + scanbus 1 i= s > > different from order after second boot + scanbus 1.=20 >=20 > Which devices appear during the boot, and which ones appear after the > rescan? It seems rather odd to me that your disks aren't showing up at > boot. Are they not powered on or something? I wrote `for some reason'. The main reason is due to driver testings and I may want to move BUSES among controllers for any other reason and still want to be able to boot by system without too much complexity. I also may want not to switch some devices on for the first boot, and so on ...=20 In my opinion, It is minimal convenience for a SCSI BUS scan to ensure deterministic device ordering. > > I guess the reasons given that xpt_scan_bus() is scanning targets > > (excepted the initiator obviously) in parallel. I would think that such= a > > concurrent target scanning can be faster than a sequential scanning, on= ly > > if some devices, that are too long for responding to SCSI commands used > > for the probe, (probably INQUIRY) disconnect the BUS during the scan. B= ut > > if this happens, or if some devices are reporting transient problems, t= hen > > order of devices cannot be guaranteed on successive (reboots) + (re)sca= n > > of BUS. > >=20 > > In my opinion, an option that will allow to request a sequential BUS > > (re)scan would be useful, not only for me.=20 >=20 > Devices are attached sequentially, unless you hard-wire them. If you > rescan the bus, though, the disks are given the first available device > number. I donnot want to have to deal with bunches of different kernels with=20 things hardwired. =20 > If you want things to turn up in the same place every time, I would sugge= st > hardwiring your disk device numbers to a specific bus/target/lun. This does not suit at all, since I may elect to move several BUSes. Under Linux, the PCI device scan is performed by low-level drivers and the drivers I maintain get the boot order from the NVRAM of a controller. I just have to change the boot order from NVRAM and everything gets transparent (I mean: all BUSES being numbered as I want them to be).=20 Under FreeBSD, this is not easily possible since the PCI devices scan is performed by a central resource. I have had to find another solution that consists in returning DEV_NOT_THERE to CAM for scsi devices that are flagged as NO SCAN AT BOOT in the NVRAM and to rescan some BUSES after boot. Note that doing a scan LUN per device solves the problem of scan BUS giving undeterministic device ordering, but it requires dozen of manual operations instead of just changing a couple of informations from the SDMS setup and a couple of camcontrol rescan #BUS commands after boot. =20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 11:59:21 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id A2E59419D for ; Tue, 8 Feb 2000 11:59:14 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA32037; Tue, 8 Feb 2000 12:54:56 -0700 (MST) (envelope-from ken) Date: Tue, 8 Feb 2000 12:54:56 -0700 From: "Kenneth D. Merry" To: Gerard Roudier Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <20000208125456.A32007@panzer.kdm.org> References: <20000207143833.A24212@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from groudier@club-internet.fr on Tue, Feb 08, 2000 at 09:17:21PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 08, 2000 at 21:17:21 +0100, Gerard Roudier wrote: > On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > > On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > > > Not really for me, may-be since I donnot want to rescan the bus, but to > > > just scan the bus for devices that haven't been seen by CAM at boot for > > > some reason. > > > > > > First attempt after having switched the box on and booted for the first > > > time: > > > > > > at scbus1 target 0 lun 0 (da3,pass4) > > > at scbus1 target 1 lun 0 (da2,pass3) > > > at scbus1 target 4 lun 0 (da5,pass6) > > > at scbus1 target 5 lun 0 (da4,pass5) > > > > > > Second attempt after having rebooted the machine: > > > > > > at scbus1 target 0 lun 0 (da4,pass5) > > > at scbus1 target 1 lun 0 (da3,pass4) > > > at scbus1 target 4 lun 0 (da2,pass3) > > > at scbus1 target 5 lun 0 (da5,pass6) > > > > > > Problem is that the order of da# devices after first boot + scanbus 1 is > > > different from order after second boot + scanbus 1. > > > > Which devices appear during the boot, and which ones appear after the > > rescan? It seems rather odd to me that your disks aren't showing up at > > boot. Are they not powered on or something? > > I wrote `for some reason'. The main reason is due to driver testings and I > may want to move BUSES among controllers for any other reason and still > want to be able to boot by system without too much complexity. I also may > want not to switch some devices on for the first boot, and so on ... Ahh. > In my opinion, It is minimal convenience for a SCSI BUS scan to ensure > deterministic device ordering. I agree. > > If you want things to turn up in the same place every time, I would suggest > > hardwiring your disk device numbers to a specific bus/target/lun. > > This does not suit at all, since I may elect to move several BUSes. > > Under Linux, the PCI device scan is performed by low-level drivers and the > drivers I maintain get the boot order from the NVRAM of a controller. I > just have to change the boot order from NVRAM and everything gets > transparent (I mean: all BUSES being numbered as I want them to be). > Under FreeBSD, this is not easily possible since the PCI devices scan is > performed by a central resource. I have had to find another solution that > consists in returning DEV_NOT_THERE to CAM for scsi devices that are > flagged as NO SCAN AT BOOT in the NVRAM and to rescan some BUSES after > boot. Note that doing a scan LUN per device solves the problem of scan BUS > giving undeterministic device ordering, but it requires dozen of manual > operations instead of just changing a couple of informations from the SDMS > setup and a couple of camcontrol rescan #BUS commands after boot. As I said in my mail (sent after this one), the behavior you've seen is a bug, and is on Justin's list of things to fix. Ideally, when you rescan a bus, things should be attached in ascending order, just as on boot. 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 Tue Feb 8 11:59:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by builder.freebsd.org (Postfix) with ESMTP id A10164400 for ; Tue, 8 Feb 2000 11:59:18 -0800 (PST) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id MAA44745; Tue, 8 Feb 2000 12:46:30 -0700 (MST) Date: Tue, 8 Feb 2000 12:46:30 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200002081946.MAA44745@narnia.plutotech.com> To: Gerard Roudier Cc: scsi@FreeBSD.org Subject: Re: Rescan for Devices... X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In my opinion, It is minimal convenience for a SCSI BUS scan to ensure > deterministic device ordering. And I would certainly agree with this. It is not too hard to do and will be done. Where's my PR? 8-) >> Devices are attached sequentially, unless you hard-wire them. If you >> rescan the bus, though, the disks are given the first available device >> number. > > I donnot want to have to deal with bunches of different kernels with > things hardwired. The current behavior is a bug. Hardwiring may serve as a temporary work-around but that doesn't change the fact that there is a bug to fix. > Under Linux, the PCI device scan is performed by low-level drivers and the > drivers I maintain get the boot order from the NVRAM of a controller. I > just have to change the boot order from NVRAM and everything gets > transparent (I mean: all BUSES being numbered as I want them to be). > Under FreeBSD, this is not easily possible since the PCI devices scan is > performed by a central resource. I have had to find another solution that > consists in returning DEV_NOT_THERE to CAM for scsi devices that are > flagged as NO SCAN AT BOOT in the NVRAM and to rescan some BUSES after > boot. Note that doing a scan LUN per device solves the problem of scan BUS > giving undeterministic device ordering, but it requires dozen of manual > operations instead of just changing a couple of informations from the SDMS > setup and a couple of camcontrol rescan #BUS commands after boot. Another solution, assuming you have a deterministic method for doing this is to request a particular path-id from the XPT at the time of your attach. Even if the number you request is in use, the XPT should be able to use this information to order the controllers your driver controls in a consistent order relative to each other. I'm not sure that the "request a path-id" code works correctly right now, but it was written with the intent to provide this kind of ordering service at some point down the line. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 12: 1: 7 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by builder.freebsd.org (Postfix) with ESMTP id 83D2E3E4E for ; Tue, 8 Feb 2000 12:01:03 -0800 (PST) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id MAA44751; Tue, 8 Feb 2000 12:48:28 -0700 (MST) Date: Tue, 8 Feb 2000 12:48:28 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200002081948.MAA44751@narnia.plutotech.com> To: "alex wetmore" Cc: scsi@FreeBSD.org Subject: Re: Problem with FreeBSD 2.2.2 and Archive Python 4586 DDS-2 autoloader (changer device not detected) X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV> you wrote: > I'm running FreeBSD 2.2.2 on a server machine and this weekend I added a > DDS-2 autoloader to get automated backups. FreeBSD will recognize the drive > as a DDS drive, but doesn't see it as a changer, so the ch device and chio > programs do not work. > > Here is the kernel output during probe: > (ahc0:5:0): "ARCHIVE Python 29987-XXX 5AB" type 1 removable SCSI 2 > st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty In 2.2.2, we did not probe luns above 0 by default. For this kind of changer device, the manufacturer often advertizes the changer on lun 1. Newer versions of FreeBSD scan higher luns by default and will hopefully pick up the changer. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 8 12: 4:48 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id AA6CB3E58 for ; Tue, 8 Feb 2000 12:04:43 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA32163; Tue, 8 Feb 2000 13:05:34 -0700 (MST) (envelope-from ken) Date: Tue, 8 Feb 2000 13:05:34 -0700 From: "Kenneth D. Merry" To: alex wetmore Cc: scsi@FreeBSD.ORG Subject: Re: Problem with FreeBSD 2.2.2 and Archive Python 4586 DDS-2 autoloader (changer device not detected) Message-ID: <20000208130534.A32091@panzer.kdm.org> References: <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV>; from alex@phred.org on Tue, Feb 08, 2000 at 10:07:35AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 08, 2000 at 10:07:35 -0800, alex wetmore wrote: > [sorry if you see two copies of this message. I originally sent it via a > news to mail gateway whch doesn't seem to be properly configured, so I'm > sending again directly to the list). > > I'm running FreeBSD 2.2.2 on a server machine and this weekend I added a > DDS-2 autoloader to get automated backups. FreeBSD will recognize the drive > as a DDS drive, but doesn't see it as a changer, so the ch device and chio > programs do not work. > > Here is the kernel output during probe: > (ahc0:5:0): "ARCHIVE Python 29987-XXX 5AB" type 1 removable SCSI 2 > st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty > > My kernel config is at http://www.phred.org/~alex/PHRED. > > The machine is a Pentium 200MMX on an ASUS SP97-VX motherboard and has an > Adaptec 2940 (might be a 2940U) SCSI adapter. Also configured on the SCSI > bus are 2 2g disks (ID 0 and 1) and a Sanyo 4x CD-ROM drive (ID 2). > > Is this a known issue that was fixed in a later release of FreeBSD? If I > pass the ch driver a specific target SCSI ID and LUN would it be expected to > find the device? Take a look in sys/scsi/scsiconf.c. It looks like there are a couple of quirk entries for similar Archive autoloaders. You may need to put in a quirk entry in the "st" section and the "ch" section as well. (This wouldn't be a problem in 3.0 or later.) 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 Tue Feb 8 16:50:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by builder.freebsd.org (Postfix) with ESMTP id A05C2440F for ; Tue, 8 Feb 2000 14:21:55 -0800 (PST) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA04912; Tue, 8 Feb 2000 14:18:30 -0800 Date: Tue, 8 Feb 2000 14:18:20 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... In-Reply-To: <200002081946.MAA44745@narnia.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 > > In my opinion, It is minimal convenience for a SCSI BUS scan to ensure > > deterministic device ordering. > > And I would certainly agree with this. It is not too hard to do and will > be done. Where's my PR? 8-) The same place it was when I told *you* about this issue 6 months ago.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 1: 5:16 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by builder.freebsd.org (Postfix) with ESMTP id 5884E3E58 for ; Tue, 8 Feb 2000 19:30:48 -0800 (PST) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA77935 for ; Tue, 8 Feb 2000 19:41:12 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200002090341.TAA77935@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: scsi@freebsd.org Subject: Recovering SCSI disk contents the evil way? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Feb 2000 19:41:12 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We're trying to recover the contents of the CCD array that was in use on hub (yes, this should involve "restore from backup", but certain backup issues are precluding this). The disk in question is an IBM DCAS-34330; it's looking pretty sick in that it's not able to correctly print its version string when probed, _but_, the loader is able to correctly read the first few sectors to get the disklabel off it. Unfortunately, we then lose because the 'da' driver wants to try to read the disk's capacity, and that fails. So before I hack the loader to just duplicate the bits onto another disk, I was wondering if anyone's already written a tool to do this that uses eg. the passthrough device... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 9:27:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id D8DFF4012 for ; Wed, 9 Feb 2000 09:27:42 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id KAA00522; Wed, 9 Feb 2000 10:24:40 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002091724.KAA00522@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: "alex wetmore" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: Problem with FreeBSD 2.2.2 and Archive Python 4586 DDS-2 autoloader (changer device not detected) In-reply-to: Your message of "Wed, 09 Feb 2000 09:15:47 PST." <0aa301bf7321$4f7adbf0$01fa3b9d@AWETMOREDEV> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Feb 2000 10:24:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Was this fixed in 3.x, or higher versions of 2.x? Upgrading to 3.x at this >point is not an option (and I probably won't bother with a painful upgrade >until 4.1 is out). CAM was implemented in 3.0R. >If I describe the device completely, like: > >device ch0 target 5 lun 1 > >should that work with 2.2.2? No. You must add a quirk to sys/scsi/scsiconf.c so it will probe higher luns on that particular device. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 10:13:28 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from phred.org (sense-alexw-189.oz.net [216.39.149.189]) by builder.freebsd.org (Postfix) with ESMTP id 1F24E3E12 for ; Wed, 9 Feb 2000 10:13:23 -0800 (PST) Received: from AWETMOREDEV (root@localhost [127.0.0.1]) by phred.org (8.9.1a/8.9.1) with SMTP id JAA06756; Wed, 9 Feb 2000 09:15:46 -0800 (PST) Message-ID: <0aa301bf7321$4f7adbf0$01fa3b9d@AWETMOREDEV> From: "alex wetmore" To: "Justin T. Gibbs" Cc: References: <200002081948.MAA44751@narnia.plutotech.com> Subject: Re: Problem with FreeBSD 2.2.2 and Archive Python 4586 DDS-2 autoloader (changer device not detected) Date: Wed, 9 Feb 2000 09:15:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: "Justin T. Gibbs" > In article <06a101bf725f$6159adf0$01fa3b9d@AWETMOREDEV> you wrote: > > I'm running FreeBSD 2.2.2 on a server machine and this weekend I added a > > DDS-2 autoloader to get automated backups. FreeBSD will recognize the drive > > as a DDS drive, but doesn't see it as a changer, so the ch device and chio > > programs do not work. > > > > Here is the kernel output during probe: > > (ahc0:5:0): "ARCHIVE Python 29987-XXX 5AB" type 1 removable SCSI 2 > > st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty > > In 2.2.2, we did not probe luns above 0 by default. For this kind > of changer device, the manufacturer often advertizes the changer on > lun 1. Newer versions of FreeBSD scan higher luns by default and > will hopefully pick up the changer. Was this fixed in 3.x, or higher versions of 2.x? Upgrading to 3.x at this point is not an option (and I probably won't bother with a painful upgrade until 4.1 is out). If I describe the device completely, like: device ch0 target 5 lun 1 should that work with 2.2.2? thanks, alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 11:53:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by builder.freebsd.org (Postfix) with ESMTP id 5398F4369; Wed, 9 Feb 2000 11:53:25 -0800 (PST) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA23335; Wed, 9 Feb 2000 20:44:16 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA56296; Wed, 9 Feb 2000 20:13:17 +0100 (CET) (envelope-from wilko) Date: Wed, 9 Feb 2000 20:13:17 +0100 From: Wilko Bulte To: Mike Smith Cc: scsi@FreeBSD.ORG Subject: Re: Recovering SCSI disk contents the evil way? Message-ID: <20000209201317.A56232@yedi.iaf.nl> References: <200002090341.TAA77935@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200002090341.TAA77935@mass.cdrom.com>; from msmith@FreeBSD.ORG on Tue, Feb 08, 2000 at 07:41:12PM -0800 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 08, 2000 at 07:41:12PM -0800, Mike Smith wrote: > > We're trying to recover the contents of the CCD array that was in use on > hub (yes, this should involve "restore from backup", but certain backup > issues are precluding this). > > The disk in question is an IBM DCAS-34330; it's looking pretty sick in > that it's not able to correctly print its version string when probed, > _but_, the loader is able to correctly read the first few sectors to get > the disklabel off it. > > Unfortunately, we then lose because the 'da' driver wants to try to read > the disk's capacity, and that fails. Long shot: this sounds like broken electronics. Any chance you can transplant the PCB from a working drive (identical model) to the HDA of the broken one? This trick once worked for me. If you have bad head amplifiers in the HDA you're toast obviously, but in that case the s/w approach will be doomed too. Alternatively buy the IBM storage guru's in Almeda a beer... (?) Wilko -- Wilko Bulte Arnhem, The Netherlands WWW : http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 13:57:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by builder.freebsd.org (Postfix) with ESMTP id 77FDD426F; Wed, 9 Feb 2000 13:57:07 -0800 (PST) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA00600; Wed, 9 Feb 2000 14:07:21 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200002092207.OAA00600@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Wilko Bulte Cc: Mike Smith , scsi@FreeBSD.ORG Subject: Re: Recovering SCSI disk contents the evil way? In-reply-to: Your message of "Wed, 09 Feb 2000 20:13:17 +0100." <20000209201317.A56232@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Feb 2000 14:07:21 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Long shot: this sounds like broken electronics. Any chance you can > transplant the PCB from a working drive (identical model) to the HDA > of the broken one? This trick once worked for me. If you have bad head > amplifiers in the HDA you're toast obviously, but in that case the > s/w approach will be doomed too. Yeah, I'm working on this took, but all of the DCAS 34330W's I have are currently in use so I need to work one loose. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 16:13:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by builder.freebsd.org (Postfix) with ESMTP id 82BBA3FB0; Wed, 9 Feb 2000 16:13:30 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id SAA96244; Wed, 9 Feb 2000 18:13:03 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 9 Feb 2000 18:13:03 -0600 (CST) From: Chris Dillon To: Mike Smith Cc: scsi@FreeBSD.ORG Subject: Re: Recovering SCSI disk contents the evil way? In-Reply-To: <200002090341.TAA77935@mass.cdrom.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 On Tue, 8 Feb 2000, Mike Smith wrote: > We're trying to recover the contents of the CCD array that was in use on > hub (yes, this should involve "restore from backup", but certain backup > issues are precluding this). > > The disk in question is an IBM DCAS-34330; it's looking pretty sick in > that it's not able to correctly print its version string when probed, > _but_, the loader is able to correctly read the first few sectors to get > the disklabel off it. This is just a datapoint, it probably won't help your situation, though... My DCAS-34330W's don't report their version string for the first time after they've been powered up. Every subsequent inquiry works fine. My SCSI BIOS is the first thing to do an inquiry so it gets the incorrect (missing?) reply, but FreeBSD gets it just fine by the time it asks for it. If I remember correctly, even when I told the BIOS not to probe one of the disks so that FreeBSD had to do it for the first time, things still worked fine, so it didn't seem to be of any consequence. I haven't tried that since 2.2.x though. da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) If either of these were dead, I'd offer you the logic board to see if that would bring hub back to life, assuming my logic board wasn't dead and yours was the source of the problem. I'd do that even if mine weren't dead if someone offered to replace it with a similar drive, if its really that important. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 17: 3: 1 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by builder.freebsd.org (Postfix) with ESMTP id 9E3824290; Wed, 9 Feb 2000 17:02:56 -0800 (PST) Received: from oranje.my.domain (dial3-130.netcologne.de [195.14.250.130]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id CAA04014; Thu, 10 Feb 2000 02:02:29 +0100 (MET) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id CAA00993; Thu, 10 Feb 2000 02:00:39 +0100 (CET) (envelope-from van.woerkom@netcologne.de) Date: Thu, 10 Feb 2000 02:00:39 +0100 (CET) Message-Id: <200002100100.CAA00993@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: freebsd-scsi@freebsd.org Subject: SC200/ncr53c810 problems Reply-To: van.woerkom@netcologne.de Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org More fun: As reported earlier on the multimedia list, I have a ASUS SC200 PCI SCSI controller (ncr53c810) in my system ncr0: irq 11 at device 13.0 on pci0 and an Ensoniq Audio PCI (ES1370) sound card. pcm0: irq 10 at device 15.0 on pci0 The problem was, that heavy activity on the hard disks plus activity on the soundcard at the same time resulted in the ncr going nuts (activity LED stays on) and thus the system to hang sooner or later. So far I believed the ES1370 driver was the culprit. However two weeks ago, I bought an ABIT Hot Rod Ultra DMA 66 IDE controler ata-pci0: irq 0 at device 1.1 on pci0 ata-pci0: Busmastering DMA not enabled ata-pci1: irq 15 at device 11.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0x6300 irq 15 on ata-pci1 ata-pci2: irq 15 at device 11.1 on pci0 ata-pci2: Busmastering DMA supported to connect an IDE hard disk ad0: ATA-5 disk at ata2 as master ad0: 26059MB (53369568 sectors), 52946 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA66 to my system. Now I have a similiar effect: Heavy use of a SCSI disk plus heavy use of the IDE disk (e.g. copy the SCSI disk to the IDE disk) results in a hang up of the ncr controller. Now I believe the SC200 card sucks for some unknown reason. Thus I am considering buying a new SCSI controller (either a DAWICONTROL DC2976UW (SYM53C875) or a NCR 8951 based one. Before I waste the money I would like to ask for help on how to exclude other causes. - Is it possible to have unlucky BIOS settings that could cause that behaviour? - I have one 66 MHz 64 MB SIMM and two 100MHz 64 MB SIMMS in a motherboard that has only tag RAM for 128 MB (Gigaybyte S2) could this lead to memory timing problems? Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 9 20:24:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from infowest.com (ns1.infowest.com [204.17.177.10]) by builder.freebsd.org (Postfix) with ESMTP id 2351943A7 for ; Wed, 9 Feb 2000 20:24:36 -0800 (PST) Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by infowest.com (Postfix) with SMTP id B5E5720F78 for ; Wed, 9 Feb 2000 21:24:24 -0700 (MST) From: "Aaron Gifford" Subject: 4.0 fails to boot - sym troubles To: freebsd-scsi@freebsd.org Message-Id: <20000210042424.B5E5720F78@infowest.com> Date: Wed, 9 Feb 2000 21:24:24 -0700 (MST) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I've got trouble. 4.0-CURRENT won't boot my system because of a problem with the sym driver and my Tekram 390U2W PCI SCSI3 controller card. This system worked fine with 3.4-STABLE and will boot with a 25-Jan-2000 snapshot kernel, but all attempts to boot with a GENERIC kernel built after 3 Feb. 2000 fail miserably. Here are the gory details: HARDWARE: --------- PII-350 2/64MB RAM Number9 Motion 771 PCI video card Tekram 390U2W PCI SCSI3 controller card 1 Seagate Cheetah 4 GB drive 1 IBM UltraStore 36GB 10KRPM drive Kingston EtheRx KNE100TX PCI 10/100 NIC SOFTWARE: --------- 3.4-STABLE - Worked well and booted just fine with my hardware 4.0-CURRENT as of 25 Jan. 2000 - Boots just fine with my hardware 4.0-CURRENT anytime after 3 Feb. 2000 - PROBLEMS! CANNOT BOOT! PROBLEM: -------- During BOOT of the the several different 4.0-GENERIC kernels I've tried (I tried a 3 Feb. 2000 build, and a 9 Feb. 2000 build) the Tekram SCSI controller is detected thus: sym0: <895> port 0xc800-0xc8ff mem 0xe7001000-0xe70010ff,0xe7000000- 0xe70000ff irq 9 at device 15.0 on pci 0 sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking Later during the boot, after the 15 second delay ("Waiting 15 seconds for SCSI devices to settle") the following two lines endlessly repeat scrolling quickly by on my console forever until I CTRL-ALT-DEL to force a reboot: Waiting 15 seconds for SCSI devices to settle sym0: SCSI parity error detected: SCR=1 DBC=72580000 SBCL=af (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. The 25 Jan. 2000 kernel (which I stole from the current.freebsd.org snapshot kernel floppy "kern.flp") works perfectly on this same box: Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:da0s1a da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16 bit), Tagged Queuing Enabled da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4662C) da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16 bit), Tagged Queueing Enabled da0: 4148 MB (8496960 512 byte sectors: 255H 63S/T 528C) QUESTIONS: ---------- I know my hardware setup works, as exhibited by the many successful boots when I was running 3.4-STABLE and the many many hours of useful uptime and error-free operation even under heavly disk usage. Also the successful boot using the 4.0-CURRENT snapshot kernel from 25 Jan. 2000 ("borrowed" from the snapshot kern.flp floppy) as mentioned above seems to lead me to believe this is not a hardware problem. So now I ask: Was there a change in the sym code or the SCSI subsystem between 25 Jan. 2000 and 3 Feb. 2000 that might account for this behavior? OR Is there a significant difference between the kernels built for the installation floppies and the standard -GENERIC kernel that might explain why the 4.0-CURRENT 25-Jan-2000 snapshot kernel taken from the installation floppy boots just fine, but any 4.0-GENERIC kernels I build from source CVSUPed on 3 Feb. 2000 or again on 5 Feb. 2000 and on 9 Feb. 2000 all fail with the identical errors described above? Since my userland is from a 3 Feb. 2000 make world, as long as I'm booting from the older 25 Jan. 2000 floppy, things just don't quite work right (and the differences between an GENERIC kernel and a boot floppy kernel may explain some of the other minor troubles I see). But I cannot get my userland back in synch. until I get a working kernel that will boot with my Tekram controller. Would someone be willing to build a 4.0-GENERIC kernel for me from recent sources (say 9 Feb. 2000 or later) and make it available via FTP or HTTP? That way I could grab a copy and try booting with it and see if perhaps there might be a quirk on my system that is poisoning my own builds of GENERIC kernels (like perhaps something in my /etc/make.conf). If that kernel also fails with the same above described messages, I'll feel more confident that it isn't caused by something insanely stupid I'm doing whenever I build a 4.0 GENERIC kernel. Has anyone else with the Tekram 390U2W controller had any troubles with the sym driver lately? Could the problem be that the newer code isn't handling the fact that I've got an 80MB/s LVD drive connected to the card via one cable, and a 40MB/s UltraWide drive connected via a second separate cable (the card has multiple connectors to permit separation of the LVD and non-LVD drives), each terminated as each is the "end" of the SCSI bus with the controller in the middle. Thanks in advance for any/all tips, pointers, answers, additional information, ideas, thoughts, etc. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 10 0:11:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by builder.freebsd.org (Postfix) with ESMTP id 3A76F437E for ; Thu, 10 Feb 2000 00:11:21 -0800 (PST) Received: from symnt3.Cadence.COM (symnt3.Cadence.COM [194.32.101.100]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id AAA21941 for ; Thu, 10 Feb 2000 00:10:54 -0800 (PST) Received: by symnt3.cadence.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Feb 2000 08:09:43 -0000 Message-ID: <1E485299309FD211A2100090271E27A401AF0531@symnt3.cadence.com> From: Nigel Roles To: freebsd-scsi@FreeBSD.ORG Subject: RE: SC200/ncr53c810 problems Date: Thu, 10 Feb 2000 08:09:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Received: By mailgate.Cadence.COM as AAA21941 at Thu Feb 10 00:10:54 2000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The ncr53c810 is not PCI2.1 compliant, which I have found to matter. Heavy pressure on the bus is more likely to reveal this. I'm sure an 875 based card would improve matters, but hey, I'm not there. -----Original Message----- From: Marc van Woerkom [mailto:van.woerkom@netcologne.de] Sent: 10 February 2000 01:01 To: freebsd-scsi@FreeBSD.ORG Subject: SC200/ncr53c810 problems More fun: As reported earlier on the multimedia list, I have a ASUS SC200 PCI SCSI controller (ncr53c810) in my system ncr0: irq 11 at device 13.0 on pci0 and an Ensoniq Audio PCI (ES1370) sound card. pcm0: irq 10 at device 15.0 on pci0 The problem was, that heavy activity on the hard disks plus activity on the soundcard at the same time resulted in the ncr going nuts (activity LED stays on) and thus the system to hang sooner or later. So far I believed the ES1370 driver was the culprit. However two weeks ago, I bought an ABIT Hot Rod Ultra DMA 66 IDE controler ata-pci0: irq 0 at device 1.1 on pci0 ata-pci0: Busmastering DMA not enabled ata-pci1: irq 15 at device 11.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0x6300 irq 15 on ata-pci1 ata-pci2: irq 15 at device 11.1 on pci0 ata-pci2: Busmastering DMA supported to connect an IDE hard disk ad0: ATA-5 disk at ata2 as master ad0: 26059MB (53369568 sectors), 52946 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA66 to my system. Now I have a similiar effect: Heavy use of a SCSI disk plus heavy use of the IDE disk (e.g. copy the SCSI disk to the IDE disk) results in a hang up of the ncr controller. Now I believe the SC200 card sucks for some unknown reason. Thus I am considering buying a new SCSI controller (either a DAWICONTROL DC2976UW (SYM53C875) or a NCR 8951 based one. Before I waste the money I would like to ask for help on how to exclude other causes. - Is it possible to have unlucky BIOS settings that could cause that behaviour? - I have one 66 MHz 64 MB SIMM and two 100MHz 64 MB SIMMS in a motherboard that has only tag RAM for 128 MB (Gigaybyte S2) could this lead to memory timing problems? Regards, Marc 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 Feb 10 1:55:52 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from shemp.palomine.net (shemp.palomine.net [205.198.88.200]) by builder.freebsd.org (Postfix) with SMTP id F2AC843FC for ; Thu, 10 Feb 2000 01:55:45 -0800 (PST) Received: (qmail 57092 invoked by uid 1000); 10 Feb 2000 09:55:43 -0000 Date: Thu, 10 Feb 2000 04:55:43 -0500 From: Chris Johnson To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org, lamaster@nren.nasa.gov Subject: Re: BT-948 timeouts Message-ID: <20000210045543.A57016@palomine.net> References: <20000206141744.A2557@palomine.net> <200002071435.HAA43271@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200002071435.HAA43271@narnia.plutotech.com>; from gibbs@narnia.plutotech.com on Mon, Feb 07, 2000 at 07:35:22AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 07, 2000 at 07:35:22AM -0700, Justin T. Gibbs wrote: > > da0 at bt0 bus 0 target 6 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > > da0: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) > > The buslogic cards don't give any indication of the "queue full" condition. > This means that CAM cannot know when to reduce the number of commands > sent to a device if it can only handle a few. My guess is that the > buslogic firmware is not gracefully dealing with the queue full > condition so we see timeouts. My hunch is that if you forced the > number of concurrent transactions down to 8 (what I recall is the > limit for this drive), then your timeouts will cease. You can > do this with the "camcontrol tags" command. Thanks very much for your response. Here's what I did: su-2.03# camcontrol tags da0 -N 8 And here's the result: su-2.03# camcontrol tags da0 -v (pass0:bt0:0:6:0): dev_openings 8 (pass0:bt0:0:6:0): dev_active 0 (pass0:bt0:0:6:0): devq_openings 8 (pass0:bt0:0:6:0): devq_queued 0 (pass0:bt0:0:6:0): held 0 (pass0:bt0:0:6:0): mintags 2 (pass0:bt0:0:6:0): maxtags 255 This seems to have done the trick. I built a world without any timeouts, which I hadn't been able to do before I made the change. Is there a fancy way to make this change survive across boots, or should I just shove the camcontrol command in a script that runs at boot time? How would I go about learning what the tags setting should be for a particular drive? Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 10 8:51:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by builder.freebsd.org (Postfix) with ESMTP id 117F844F3 for ; Thu, 10 Feb 2000 08:51:05 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id KAA02392; Thu, 10 Feb 2000 10:49:23 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Thu, 10 Feb 2000 10:49:23 -0600 (CST) From: Chris Dillon To: Aaron Gifford Cc: freebsd-scsi@FreeBSD.ORG, groudier@club-internet.fr Subject: Re: 4.0 fails to boot - sym troubles In-Reply-To: <20000210042424.B5E5720F78@infowest.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 cc'd to Gerard Roudier, the author of the sym driver... On Wed, 9 Feb 2000, Aaron Gifford wrote: > Hello, > > I've got trouble. 4.0-CURRENT won't boot my system because of a > problem with the sym driver and my Tekram 390U2W PCI SCSI3 controller > card. This system worked fine with 3.4-STABLE and will boot with > a 25-Jan-2000 snapshot kernel, but all attempts to boot with a GENERIC > kernel built after 3 Feb. 2000 fail miserably. > > Here are the gory details: > > HARDWARE: > --------- > PII-350 2/64MB RAM > Number9 Motion 771 PCI video card > Tekram 390U2W PCI SCSI3 controller card > 1 Seagate Cheetah 4 GB drive > 1 IBM UltraStore 36GB 10KRPM drive > Kingston EtheRx KNE100TX PCI 10/100 NIC > > SOFTWARE: > --------- > 3.4-STABLE - Worked well and booted just fine with my hardware > 4.0-CURRENT as of 25 Jan. 2000 - Boots just fine with my hardware > 4.0-CURRENT anytime after 3 Feb. 2000 - PROBLEMS! CANNOT BOOT! > > > PROBLEM: > -------- > > During BOOT of the the several different 4.0-GENERIC kernels I've tried > (I tried a 3 Feb. 2000 build, and a 9 Feb. 2000 build) the Tekram SCSI > controller is detected thus: > > sym0: <895> port 0xc800-0xc8ff mem 0xe7001000-0xe70010ff,0xe7000000- > 0xe70000ff irq 9 at device 15.0 on pci 0 > sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking > > Later during the boot, after the 15 second delay ("Waiting 15 seconds > for SCSI devices to settle") the following two lines endlessly repeat > scrolling quickly by on my console forever until I CTRL-ALT-DEL to > force a reboot: > > Waiting 15 seconds for SCSI devices to settle > sym0: SCSI parity error detected: SCR=1 DBC=72580000 SBCL=af > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. [...snip...] Herm. I had the exact same problem recently. I've got two IBM DCAS-34330W's, an NEC SCSI CDROM drive, and a Sony SDT-2000 (I think... its DDS2, anyway) DAT tape drive on a Tekram DC-390F. Everything worked fine under 3.4, but when I upgraded to 4.0-CURRENT recently, the same thing happened and I had to use the ncr driver again temporarily. I disabled Parity for the Sony DAT drive in the SCSI controller BIOS and everything was working with the sym driver again. I wouldn't think either your Cheetah or the IBM drive would have such a problem, but try disabling Parity on each device on the bus in turn until you find the culprit. Any idea whats happening, Gerard? -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 10 11:37:46 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by builder.freebsd.org (Postfix) with ESMTP id 489D945A2 for ; Thu, 10 Feb 2000 11:37:43 -0800 (PST) Received: from networkcomputerz.com (aotwell.iss.net [208.21.3.106]) by loki.iss.net (8.9.3/8.9.3) with ESMTP id OAA30024; Thu, 10 Feb 2000 14:37:23 -0500 Message-ID: <38A313CE.3BC3B767@networkcomputerz.com> Date: Thu, 10 Feb 2000 14:38:54 -0500 From: Andrew Otwell X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Syquest 200MB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone gotten a Syquest 200MB to work on a aha2940UW. I can run a dat drive fine on that controller but the Syquest is not recognized by disklabel of fdisk. Anyone seen this prob. I've got the drive jumpered for ID 4. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Andrew T. Otwell, Network Administrator andrew@networkcomputerz.com, 678.363.8491 http://www.NetworkComputerz.com yank GPG DSS key from hkp://pgpkeys.mit.edu _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 10 12:15:17 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by builder.freebsd.org (Postfix) with ESMTP id 89C3C477D for ; Thu, 10 Feb 2000 12:15:12 -0800 (PST) Received: from localhost (ppp-171-189.villette.club-internet.fr [195.36.171.189]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA02209; Thu, 10 Feb 2000 21:10:11 +0100 (MET) Date: Thu, 10 Feb 2000 21:44:24 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Aaron Gifford Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 4.0 fails to boot - sym troubles In-Reply-To: <20000210042424.B5E5720F78@infowest.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Just quoting the offending messages: On Wed, 9 Feb 2000, Aaron Gifford wrote: > sym0: SCSI parity error detected: SCR=3D1 DBC=3D72580000 SBCL=3Daf > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. The driver gets an SCSI parity error while attempting to snoop the BUS by reading directly the SCSI BUS data line bit 0...7. I have recently discovered experimentally that a spurious SCSI parity error due to the chip checking against parity for bit 8..15 can be triggerred in some special situations, for example when the WSR bit is set. The WSR bit is set when a residual byte didn't fit a previous CHMOV for a scatter entry and the target changes phase at the beginning of the next CHMOV (count) with count > 1. (For count=3D1, the WSR bit isn't set and the residual byte is transferred to memory). Since this issue cannot be cleanly worked-around, I have decided to handle things differently so that it is no longer needed to snoop the BUS by reading directly the SCSI BUS data lines. Result is sym-1.3.2-20000206 that haven't (yet?) been committed due to 4.0 release time.=20 If you could give a try with this driver version, this would help. ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.readme ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.tar.gz (The tar contains full driver files to move to src/sys/dev/sym) You may want to let me know if it fixes or not. Thanks. Regards, G=E9rard. PS: On the other hand, I seem to remember that my last commit for the `sym' driver has been done on January the 12th. So the kernel that fails should just use same `sym' driver as 4.0-CURRENT-25-January that succeeds. Btw, if the `ncr' that just ignores the WSR bit succeeds, then I may well be right. On Wed, 9 Feb 2000, Aaron Gifford wrote: > Hello, >=20 > I've got trouble. 4.0-CURRENT won't boot my system because of a=20 > problem with the sym driver and my Tekram 390U2W PCI SCSI3 controller > card. This system worked fine with 3.4-STABLE and will boot with > a 25-Jan-2000 snapshot kernel, but all attempts to boot with a GENERIC > kernel built after 3 Feb. 2000 fail miserably. >=20 > Here are the gory details: >=20 > HARDWARE: > --------- > PII-350 2/64MB RAM > Number9 Motion 771 PCI video card > Tekram 390U2W PCI SCSI3 controller card > 1 Seagate Cheetah 4 GB drive > 1 IBM UltraStore 36GB 10KRPM drive > Kingston EtheRx KNE100TX PCI 10/100 NIC >=20 > SOFTWARE: > --------- > 3.4-STABLE - Worked well and booted just fine with my hardware > 4.0-CURRENT as of 25 Jan. 2000 - Boots just fine with my hardware > 4.0-CURRENT anytime after 3 Feb. 2000 - PROBLEMS! CANNOT BOOT! >=20 >=20 > PROBLEM: > -------- >=20 > During BOOT of the the several different 4.0-GENERIC kernels I've tried > (I tried a 3 Feb. 2000 build, and a 9 Feb. 2000 build) the Tekram SCSI > controller is detected thus: >=20 > sym0: <895> port 0xc800-0xc8ff mem 0xe7001000-0xe70010ff,0xe7000000- > 0xe70000ff irq 9 at device 15.0 on pci 0 > sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking >=20 > Later during the boot, after the 15 second delay ("Waiting 15 seconds > for SCSI devices to settle") the following two lines endlessly repeat > scrolling quickly by on my console forever until I CTRL-ALT-DEL to > force a reboot: >=20 > Waiting 15 seconds for SCSI devices to settle > sym0: SCSI parity error detected: SCR=3D1 DBC=3D72580000 SBCL=3Daf > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. >=20 > The 25 Jan. 2000 kernel (which I stole from the current.freebsd.org > snapshot kernel floppy "kern.flp") works perfectly on this same box: >=20 > Waiting 15 seconds for SCSI devices to settle > Mounting root from ufs:da0s1a > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16 bit), Tagged > Queuing Enabled > da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4662C) > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16 bit), Tagged > Queueing Enabled > da0: 4148 MB (8496960 512 byte sectors: 255H 63S/T 528C) >=20 >=20 > QUESTIONS: > ---------- >=20 > I know my hardware setup works, as exhibited by the many successful > boots when I was running 3.4-STABLE and the many many hours of useful > uptime and error-free operation even under heavly disk usage. Also > the successful boot using the 4.0-CURRENT snapshot kernel from 25 Jan. > 2000 ("borrowed" from the snapshot kern.flp floppy) as mentioned > above seems to lead me to believe this is not a hardware problem. >=20 > So now I ask: >=20 > Was there a change in the sym code or the SCSI subsystem between > 25 Jan. 2000 and 3 Feb. 2000 that might account for this behavior? >=20 > OR >=20 > Is there a significant difference between the kernels built for the > installation floppies and the standard -GENERIC kernel that might > explain why the 4.0-CURRENT 25-Jan-2000 snapshot kernel taken from > the installation floppy boots just fine, but any 4.0-GENERIC kernels > I build from source CVSUPed on 3 Feb. 2000 or again on 5 Feb. 2000 > and on 9 Feb. 2000 all fail with the identical errors described above? >=20 > Since my userland is from a 3 Feb. 2000 make world, as long as I'm > booting from the older 25 Jan. 2000 floppy, things just don't quite > work right (and the differences between an GENERIC kernel and a boot > floppy kernel may explain some of the other minor troubles I see). > But I cannot get my userland back in synch. until I get a working > kernel that will boot with my Tekram controller. >=20 > Would someone be willing to build a 4.0-GENERIC kernel for me from > recent sources (say 9 Feb. 2000 or later) and make it available via > FTP or HTTP? That way I could grab a copy and try booting with it > and see if perhaps there might be a quirk on my system that is > poisoning my own builds of GENERIC kernels (like perhaps something > in my /etc/make.conf). If that kernel also fails with the same > above described messages, I'll feel more confident that it isn't > caused by something insanely stupid I'm doing whenever I build a > 4.0 GENERIC kernel. >=20 > Has anyone else with the Tekram 390U2W controller had any troubles > with the sym driver lately? >=20 > Could the problem be that the newer code isn't handling the fact > that I've got an 80MB/s LVD drive connected to the card via one > cable, and a 40MB/s UltraWide drive connected via a second separate > cable (the card has multiple connectors to permit separation of > the LVD and non-LVD drives), each terminated as each is the "end" > of the SCSI bus with the controller in the middle. >=20 > Thanks in advance for any/all tips, pointers, answers, additional > information, ideas, thoughts, etc. >=20 > Aaron out. >=20 >=20 >=20 > 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 Feb 10 12:27:52 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by builder.freebsd.org (Postfix) with ESMTP id 432724550 for ; Thu, 10 Feb 2000 12:27:49 -0800 (PST) Received: from networkcomputerz.com (aotwell.iss.net [208.21.3.106]) by loki.iss.net (8.9.3/8.9.3) with ESMTP id PAA03209; Thu, 10 Feb 2000 15:27:28 -0500 Message-ID: <38A31F8A.17E14C42@networkcomputerz.com> Date: Thu, 10 Feb 2000 15:28:58 -0500 From: Andrew Otwell X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Re: Syquest 200MB References: <38A313CE.3BC3B767@networkcomputerz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org nevermind. Apparently FBSD wanted to use the ahc driver instead of the aha driver. GENERIC kernel found the drive. Andrew Otwell wrote: > > Anyone gotten a Syquest 200MB to work on a aha2940UW. I can run a dat > drive fine on that controller but the Syquest is not recognized by > disklabel of fdisk. Anyone seen this prob. I've got the drive jumpered > for ID 4. > > -- > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > Andrew T. Otwell, Network Administrator > andrew@networkcomputerz.com, 678.363.8491 > http://www.NetworkComputerz.com > yank GPG DSS key from hkp://pgpkeys.mit.edu > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > 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 Feb 10 15:21: 1 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from infowest.com (ns1.infowest.com [204.17.177.10]) by builder.freebsd.org (Postfix) with ESMTP id C3DAD45C3 for ; Thu, 10 Feb 2000 15:20:53 -0800 (PST) Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by infowest.com (Postfix) with SMTP id 7F84220F66 for ; Thu, 10 Feb 2000 16:19:49 -0700 (MST) From: "Aaron Gifford" Subject: Re: 4.0 fails to boot - sym troubles To: Cc: Cc: In-Reply-To: Message-Id: <20000210231949.7F84220F66@infowest.com> Date: Thu, 10 Feb 2000 16:19:49 -0700 (MST) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 10 Feb 2000, Gerard Roudier wrote: >Hello, > >Just quoting the offending messages: > >On Wed, 9 Feb 2000, Aaron Gifford wrote: > >> sym0: SCSI parity error detected: SCR=3D1 DBC=3D72580000 SBCL=3Daf >> (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. > >The driver gets an SCSI parity error while attempting to snoop the BUS by >reading directly the SCSI BUS data line bit 0...7. I have recently >discovered experimentally that a spurious SCSI parity error due to the >chip checking against parity for bit 8..15 can be triggerred in some >special situations, for example when the WSR bit is set. The WSR bit is >set when a residual byte didn't fit a previous CHMOV for a scatter entry >and the target changes phase at the beginning of the next CHMOV (count) >with count > 1. (For count=3D1, the WSR bit isn't set and the residual byte >is transferred to memory). Since this issue cannot be cleanly >worked-around, I have decided to handle things differently so that it is >no longer needed to snoop the BUS by reading directly the SCSI BUS data >lines. Result is sym-1.3.2-20000206 that haven't (yet?) been committed due >to 4.0 release time.=20 > >If you could give a try with this driver version, this would help. >ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= >000206.readme >ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= >000206.tar.gz >(The tar contains full driver files to move to src/sys/dev/sym) > >You may want to let me know if it fixes or not. Thanks. > >Regards, > G=E9rard. > >PS: >On the other hand, I seem to remember that my last commit for the `sym' >driver has been done on January the 12th. So the kernel that fails should >just use same `sym' driver as 4.0-CURRENT-25-January that succeeds. >Btw, if the `ncr' that just ignores the WSR bit succeeds, then I may well >be right. > THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU!!!! That fixed the problem! Too bad it didn't make it into the latest 4.0-RC. Other folks with Tekram cards experiencing the problem should give your fix a try too. I rebuilt my 4.0 (as of 10 Feb. 2000 CVSup) kernel using your latest sym files and rebooted. The errors I mentioned in my posts went away completely. I did not make any other changes. Since then, the driver appears to be working find. I'm doing a buildworld right now and have seen nothing unusual at all. Again, let me repeat, many thanks for your work and for the fix! Sincerely, Aaron Gifford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 10 16: 1:33 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by builder.freebsd.org (Postfix) with ESMTP id E2D7145EB for ; Thu, 10 Feb 2000 16:01:21 -0800 (PST) Received: from oranje.my.domain (dial-ra-nc1-85.netcologne.de [195.14.244.85]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id AAA12926; Fri, 11 Feb 2000 00:59:00 +0100 (MET) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id AAA10864; Fri, 11 Feb 2000 00:57:10 +0100 (CET) (envelope-from van.woerkom@netcologne.de) Date: Fri, 11 Feb 2000 00:57:10 +0100 (CET) Message-Id: <200002102357.AAA10864@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: ngr@symbionics.co.uk Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: <1E485299309FD211A2100090271E27A401AF0531@symnt3.cadence.com> (message from Nigel Roles on Thu, 10 Feb 2000 08:09:42 -0000) Subject: Re: SC200/ncr53c810 problems Reply-To: van.woerkom@netcologne.de References: <1E485299309FD211A2100090271E27A401AF0531@symnt3.cadence.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The ncr53c810 is not PCI2.1 compliant, which I have found to matter. > Heavy pressure on the bus is more likely to reveal this. I'm sure > an 875 based card would improve matters, but hey, I'm not there. What worries me is that I have seen very few bug reports regarding 810 cards. So most people seem to have no trouble at all. Heck, guess I will buy a new controller anyway. What is preferable? a) a SYM53C875 based card b) a SYM53C885 based one Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 2:26:41 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5]) by builder.freebsd.org (Postfix) with ESMTP id 675524709; Fri, 11 Feb 2000 02:26:07 -0800 (PST) Received: from henny.webweaving.org (dhcp36.calcaphon.com [10.0.1.36]) by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id KAA10395; Fri, 11 Feb 2000 10:25:42 GMT (envelope-from n_hibma@calcaphon.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id WAA02285; Thu, 10 Feb 2000 22:46:42 GMT (envelope-from n_hibma@calcaphon.com) Date: Thu, 10 Feb 2000 22:46:42 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Warner Losh Cc: mobile@freebsd.org, scsi@freebsd.org Subject: Re: aic pccard attachment patch In-Reply-To: <200001120657.XAA12127@harmony.village.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 Warner, A stupid question: did you try the detach? The detach in umass.c (new version) is exactly the same and it bombs my system, when trying to free the SIM. Nick > I've taken the CAM patches that have been floating around the nomads > list and also written a pccard attachment for the aic driver. The > patches can be found at > http://www.freebsd.org/~imp/aic-patch > > They appear to work for me, but I've not stress tested them beyond > card insertion/extraction. I'll grab a scsi device and do more > testing, but nonetheless am fairly confident that these will work > fairly well. > > You'll also need to add aic to the database of cards in > /etc/pccard.conf. > > card "Adaptec, Inc." "APA-1460 SCSI Host Adapter" > config 0x9 "aic0" ? > is what I'm using. > > Please let me know what you think.... Especially the cam parts of the > patch. > > Warner > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-mobile" in the body of the message > -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 8:14:46 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from moek.pir.net (moek.pir.net [209.192.237.190]) by builder.freebsd.org (Postfix) with ESMTP id 2C5B64734; Fri, 11 Feb 2000 08:14:00 -0800 (PST) Received: from pir by moek.pir.net with local (Exim) id 12JIh8-0003SU-00 ; Fri, 11 Feb 2000 11:13:22 -0500 Date: Fri, 11 Feb 2000 11:13:21 -0500 From: Peter Radcliffe To: Nick Hibma Cc: Warner Losh , mobile@freebsd.org, scsi@freebsd.org Subject: Re: aic pccard attachment patch Message-ID: <20000211111321.A12769@pir.net> Mail-Followup-To: Nick Hibma , Warner Losh , mobile@freebsd.org, scsi@freebsd.org References: <200001120657.XAA12127@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from n_hibma@calcaphon.com on Thu, Feb 10, 2000 at 10:46:42PM +0000 X-fish: < Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Hibma probably said: > A stupid question: did you try the detach? The detach in umass.c (new > version) is exactly the same and it bombs my system, when trying to free > the SIM. Using 3.4-PAO with the recently included aic stuff I don't have any problems with detatch - don't know if this is exactly the same code, though. I just can't mount any scsi cdrom drives :/ Disks work fine, all the scsi kernel entries in place, the scsi cdrom device is seen but doing anything with /dev/cd0* gives me "device not configured" :/ P. > > I've taken the CAM patches that have been floating around the nomads > > list and also written a pccard attachment for the aic driver. The > > patches can be found at > > http://www.freebsd.org/~imp/aic-patch > > > > They appear to work for me, but I've not stress tested them beyond > > card insertion/extraction. I'll grab a scsi device and do more > > testing, but nonetheless am fairly confident that these will work > > fairly well. > > > > You'll also need to add aic to the database of cards in > > /etc/pccard.conf. > > > > card "Adaptec, Inc." "APA-1460 SCSI Host Adapter" > > config 0x9 "aic0" ? > > is what I'm using. > > > > Please let me know what you think.... Especially the cam parts of the > > patch. -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 8:25:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by builder.freebsd.org (Postfix) with ESMTP id 94DAB4720; Fri, 11 Feb 2000 08:25:21 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA50712; Fri, 11 Feb 2000 09:25:03 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA49978; Fri, 11 Feb 2000 09:26:14 -0700 (MST) Message-Id: <200002111626.JAA49978@harmony.village.org> To: Nick Hibma Subject: Re: aic pccard attachment patch Cc: mobile@freebsd.org, scsi@freebsd.org In-reply-to: Your message of "Thu, 10 Feb 2000 22:46:42 GMT." References: Date: Fri, 11 Feb 2000 09:26:14 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Nick Hibma writes: : A stupid question: did you try the detach? The detach in umass.c (new : version) is exactly the same and it bombs my system, when trying to free : the SIM. Worked last time I tried it. However, it seems fragile on camcontrol rescan. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 8:50:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5]) by builder.freebsd.org (Postfix) with ESMTP id 3DEBA4790; Fri, 11 Feb 2000 08:49:55 -0800 (PST) Received: from calcaphon.com (dhcp26.calcaphon.com [10.0.1.26]) by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id QAA14149; Fri, 11 Feb 2000 16:48:49 GMT (envelope-from n_hibma@calcaphon.com) Message-ID: <38A4ADF1.56F1041C@calcaphon.com> Date: Fri, 11 Feb 2000 16:48:49 -0800 From: Nick Hibma Organization: Qube X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: mobile@freebsd.org, scsi@freebsd.org Subject: Re: aic pccard attachment patch References: <200002111626.JAA49978@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Right, that's what I perceived as well. Ok, that means that I haven't made a mistake somewhere. Nick Warner Losh wrote: > > In message Nick Hibma writes: > : A stupid question: did you try the detach? The detach in umass.c (new > : version) is exactly the same and it bombs my system, when trying to free > : the SIM. > > Worked last time I tried it. However, it seems fragile on camcontrol > rescan. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Work: n_hibma@calcaphon.com Personal: n_hibma@webweaving.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 8:54:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by builder.freebsd.org (Postfix) with ESMTP id 383A03D76; Fri, 11 Feb 2000 08:54:28 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA50924; Fri, 11 Feb 2000 09:54:14 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA50147; Fri, 11 Feb 2000 09:55:25 -0700 (MST) Message-Id: <200002111655.JAA50147@harmony.village.org> To: Nick Hibma Subject: Re: aic pccard attachment patch Cc: mobile@freebsd.org, scsi@freebsd.org In-reply-to: Your message of "Fri, 11 Feb 2000 16:48:49 PST." <38A4ADF1.56F1041C@calcaphon.com> References: <38A4ADF1.56F1041C@calcaphon.com> <200002111626.JAA49978@harmony.village.org> Date: Fri, 11 Feb 2000 09:55:25 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <38A4ADF1.56F1041C@calcaphon.com> Nick Hibma writes: : Ok, that means that I haven't made a mistake somewhere. Yes. Justin tells me that this may be due to the devfs stuff not being able to cope with devices arriving and leaving at interrupt level. I haven't had the time to dig into it deeply... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 9:38: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id A24D53D0B; Fri, 11 Feb 2000 09:37:55 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA57052; Fri, 11 Feb 2000 10:37:08 -0700 (MST) (envelope-from ken) Date: Fri, 11 Feb 2000 10:37:08 -0700 From: "Kenneth D. Merry" To: Peter Radcliffe Cc: Nick Hibma , Warner Losh , mobile@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: aic pccard attachment patch Message-ID: <20000211103708.A57034@panzer.kdm.org> References: <200001120657.XAA12127@harmony.village.org> <20000211111321.A12769@pir.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000211111321.A12769@pir.net>; from pir@pir.net on Fri, Feb 11, 2000 at 11:13:21AM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 11, 2000 at 11:13:21 -0500, Peter Radcliffe wrote: > Nick Hibma probably said: > > A stupid question: did you try the detach? The detach in umass.c (new > > version) is exactly the same and it bombs my system, when trying to free > > the SIM. > > Using 3.4-PAO with the recently included aic stuff I don't have any > problems with detatch - don't know if this is exactly the same code, > though. > > I just can't mount any scsi cdrom drives :/ > Disks work fine, all the scsi kernel entries in place, the scsi cdrom > device is seen but doing anything with /dev/cd0* gives me "device > not configured" :/ Is your CD drive probed? Does it show up in the dmesg? Can you send your dmesg output? 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 Fri Feb 11 11:14:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from moek.pir.net (moek.pir.net [209.192.237.190]) by builder.freebsd.org (Postfix) with ESMTP id 88A5D4784; Fri, 11 Feb 2000 11:14:19 -0800 (PST) Received: from pir by moek.pir.net with local (Exim) id 12JLW5-0004VY-00 ; Fri, 11 Feb 2000 14:14:09 -0500 Date: Fri, 11 Feb 2000 14:14:09 -0500 From: Peter Radcliffe To: freebsd-mobile@freebsd.org, scsi@FreeBSD.ORG Subject: Re: Adaptec 1460B, PAO3 and cdrom drive problems. Message-ID: <20000211141408.C14877@pir.net> Mail-Followup-To: freebsd-mobile@freebsd.org, scsi@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-fish: < Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Accidentally sent this to scsi, mobile and freebsd-mobile, so it bounced. P. ----- Forwarded message from Peter Radcliffe ----- "Kenneth D. Merry" probably said: > On Fri, Feb 11, 2000 at 11:13:21 -0500, Peter Radcliffe wrote: > > I just can't mount any scsi cdrom drives :/ > > Disks work fine, all the scsi kernel entries in place, the scsi cdrom > > device is seen but doing anything with /dev/cd0* gives me "device > > not configured" :/ > > Is your CD drive probed? Does it show up in the dmesg? Can you send your > dmesg output? Yes, yes, and yes. Heres what I sent to mobile origionally about this. Thanks, P. Peter Radcliffe probably said: > options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device > controller aic0 at isa? port ? cam irq ? disable > controller scbus0 > device da0 #SCSI direct access devices (aka disks) > device sa0 #SCSI tapes > device pass0 #CAM passthrough driver > device cd0 #Only need one of these, the code dynamically grows > device pt0 at scbus? # SCSI processor type > > > Card inserted, slot 0 > Feb 6 00:00:13 disapp pccardd[81]: Card "Adaptec, Inc."("APA-1460 SCSI > Host Adapter") [Version 0.01] [(null)] matched "Adaptec, Inc\." > ("APA-1460.*") [(null)] [(null)] > card0: assign aic0 iobase 0x340 irq 7 > aic0: aic6360, dma, disconnection, parity check > da0 at aic0 bus 0 target 3 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 5.000MB/s transfers (5.000MHz, offset 8), Tagged Queueing Enabled > da0: 1006MB (2061108 512 byte sectors: 64H 32S/T 1006C) > > pir@disapp# mount /dev/da0s1e /mnt > pir@disapp# df /mnt > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1e 998367 700337 218161 76% /mnt > pir@disapp# ls -aFl /mnt > total 700338 > drwxr-xr-x 2 root wheel 512 Feb 5 18:09 ./ > drwxr-xr-x 22 root wheel 512 Feb 6 00:00 ../ > -rw------- 1 root wheel 39413760 Feb 5 17:48 disapp..dump > -rw------- 1 root wheel 645324800 Feb 5 18:09 disapp.usr.dump > -rw------- 1 root wheel 32010240 Feb 5 18:09 disapp.var.dump > pir@disapp# umount /mnt > > > > > [...] > cd0 at aic0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 5.000MB/s transfers (5.000MHz, offset 8) > cd0: cd present [1318424 x 512 byte records] > > pir@disapp# mount_cd9660 /dev/cd0a /mnt > mount_cd9660: Device not configured > pir@disapp# cdcontrol -f /dev/cd0a eject > cdcontrol: no disc in drive /dev/cd0a > pir@disapp# mount_cd9660 /dev/cd0c /mnt > mount_cd9660: Device not configured > pir@disapp# cdcontrol -f /dev/cd0c eject > cdcontrol: no disc in drive /dev/cd0a ----- End forwarded message ----- -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 11:41:44 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 254643DB4; Fri, 11 Feb 2000 11:41:33 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA57854; Fri, 11 Feb 2000 12:41:18 -0700 (MST) (envelope-from ken) Date: Fri, 11 Feb 2000 12:41:18 -0700 From: "Kenneth D. Merry" To: freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Adaptec 1460B, PAO3 and cdrom drive problems. Message-ID: <20000211124118.A57790@panzer.kdm.org> References: <200001120657.XAA12127@harmony.village.org> <20000211111321.A12769@pir.net> <20000211103708.A57034@panzer.kdm.org> <20000204224930.B44997@cc942873-a.ewndsr1.nj.home.com> <200002052251.OAA12829@ptavv.es.net> <20000207175326.G9141@pir.net> <20000211134533.B14877@pir.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000211134533.B14877@pir.net>; from pir@pir.net on Fri, Feb 11, 2000 at 01:45:33PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 11, 2000 at 13:45:33 -0500, Peter Radcliffe wrote: > "Kenneth D. Merry" probably said: > > On Fri, Feb 11, 2000 at 11:13:21 -0500, Peter Radcliffe wrote: > > > I just can't mount any scsi cdrom drives :/ > > > Disks work fine, all the scsi kernel entries in place, the scsi cdrom > > > device is seen but doing anything with /dev/cd0* gives me "device > > > not configured" :/ > > > > Is your CD drive probed? Does it show up in the dmesg? Can you send your > > dmesg output? > > Yes, yes, and yes. > Heres what I sent to mobile origionally about this. [ ... ] > Peter Radcliffe probably said: > > options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device > > controller aic0 at isa? port ? cam irq ? disable > > controller scbus0 > > device da0 #SCSI direct access devices (aka disks) > > device sa0 #SCSI tapes > > device pass0 #CAM passthrough driver > > device cd0 #Only need one of these, the code dynamically grows > > device pt0 at scbus? # SCSI processor type [ ... ] > > > > > > > > [...] > > cd0 at aic0 bus 0 target 6 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 5.000MB/s transfers (5.000MHz, offset 8) > > cd0: cd present [1318424 x 512 byte records] That's odd -- your CDROM drive is using 512 byte sectors. Try flipping the dip switch or whatever to change it to 2K sectors. > > pir@disapp# mount_cd9660 /dev/cd0a /mnt > > mount_cd9660: Device not configured > > pir@disapp# cdcontrol -f /dev/cd0a eject > > cdcontrol: no disc in drive /dev/cd0a > > pir@disapp# mount_cd9660 /dev/cd0c /mnt > > mount_cd9660: Device not configured > > pir@disapp# cdcontrol -f /dev/cd0c eject > > cdcontrol: no disc in drive /dev/cd0a Okay, try this: camcontrol tur cd0 -v camcontrol inquiry cd0 -v Maybe we can narrow this down to either a SCSI problem or some other sort of problem. Also, try changing your drive to 2K sectors. 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 Fri Feb 11 12: 1:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from moek.pir.net (moek.pir.net [209.192.237.190]) by builder.freebsd.org (Postfix) with ESMTP id 4B97C3DAE; Fri, 11 Feb 2000 12:00:58 -0800 (PST) Received: from pir by moek.pir.net with local (Exim) id 12JMFF-0004m2-00 ; Fri, 11 Feb 2000 15:00:49 -0500 Date: Fri, 11 Feb 2000 15:00:48 -0500 From: Peter Radcliffe To: freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Adaptec 1460B, PAO3 and cdrom drive problems. Message-ID: <20000211150048.J14877@pir.net> Mail-Followup-To: freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG References: <200001120657.XAA12127@harmony.village.org> <20000211111321.A12769@pir.net> <20000211103708.A57034@panzer.kdm.org> <20000204224930.B44997@cc942873-a.ewndsr1.nj.home.com> <200002052251.OAA12829@ptavv.es.net> <20000207175326.G9141@pir.net> <20000211134533.B14877@pir.net> <20000211124118.A57790@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000211124118.A57790@panzer.kdm.org>; from ken@kdm.org on Fri, Feb 11, 2000 at 12:41:18PM -0700 X-fish: < Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" probably said: > That's odd -- your CDROM drive is using 512 byte sectors. Try flipping the > dip switch or whatever to change it to 2K sectors. I can't. It's a Sun cdrom drive, which only does 512 bytes. > camcontrol tur cd0 -v > camcontrol inquiry cd0 -v pir@disapp# camcontrol tur cd0 -v Unit is not ready (pass0:aic0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass0:aic0:0:6:0): UNIT ATTENTION asc:28,0 (pass0:aic0:0:6:0): Not ready to ready change, medium may have changed pir@disapp# camcontrol tur cd0 -v Unit is ready pir@disapp# camcontrol inquiry cd0 -v pass0: Removable CD-ROM SCSI-2 device pass0: Serial Number [ pass0: 3.300MB/s transfers > Maybe we can narrow this down to either a SCSI problem or some other sort > of problem. Also, try changing your drive to 2K sectors. This setup works under windows, so I was assuming it wasn't a SCSI problem. The same drive works on my Adaptec 3940UW in my desktop FreeBSD box. Thanks, P. -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 12: 7:21 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id 6302A4170; Fri, 11 Feb 2000 12:06:49 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA58047; Fri, 11 Feb 2000 13:06:38 -0700 (MST) (envelope-from ken) Date: Fri, 11 Feb 2000 13:06:38 -0700 From: "Kenneth D. Merry" To: Peter Radcliffe Cc: freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Adaptec 1460B, PAO3 and cdrom drive problems. Message-ID: <20000211130638.A58011@panzer.kdm.org> References: <200001120657.XAA12127@harmony.village.org> <20000211111321.A12769@pir.net> <20000211103708.A57034@panzer.kdm.org> <20000204224930.B44997@cc942873-a.ewndsr1.nj.home.com> <200002052251.OAA12829@ptavv.es.net> <20000207175326.G9141@pir.net> <20000211134533.B14877@pir.net> <20000211124118.A57790@panzer.kdm.org> <20000211150048.J14877@pir.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000211150048.J14877@pir.net>; from pir@pir.net on Fri, Feb 11, 2000 at 03:00:48PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 11, 2000 at 15:00:48 -0500, Peter Radcliffe wrote: > "Kenneth D. Merry" probably said: > > That's odd -- your CDROM drive is using 512 byte sectors. Try flipping the > > dip switch or whatever to change it to 2K sectors. > > I can't. It's a Sun cdrom drive, which only does 512 bytes. Ahh. > > camcontrol tur cd0 -v > > camcontrol inquiry cd0 -v > > pir@disapp# camcontrol tur cd0 -v > Unit is not ready > (pass0:aic0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass0:aic0:0:6:0): UNIT ATTENTION asc:28,0 > (pass0:aic0:0:6:0): Not ready to ready change, medium may have changed > pir@disapp# camcontrol tur cd0 -v > Unit is ready > pir@disapp# camcontrol inquiry cd0 -v > pass0: Removable CD-ROM SCSI-2 device > pass0: Serial Number [ > pass0: 3.300MB/s transfers > > > Maybe we can narrow this down to either a SCSI problem or some other sort > > of problem. Also, try changing your drive to 2K sectors. > > This setup works under windows, so I was assuming it wasn't a SCSI > problem. The same drive works on my Adaptec 3940UW in my desktop > FreeBSD box. Hmm. Well, try putting some printfs in cdopen() in src/sys/cam/scsi/scsi_cd.c, and see where it is bailing out. 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 Fri Feb 11 12:43: 6 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from moek.pir.net (moek.pir.net [209.192.237.190]) by builder.freebsd.org (Postfix) with ESMTP id C52133DAD; Fri, 11 Feb 2000 12:42:56 -0800 (PST) Received: from pir by moek.pir.net with local (Exim) id 12JMtn-0004zv-00 ; Fri, 11 Feb 2000 15:42:43 -0500 Date: Fri, 11 Feb 2000 15:42:42 -0500 From: Peter Radcliffe To: "Kenneth D. Merry" Cc: freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Adaptec 1460B, PAO3 and cdrom drive problems. Message-ID: <20000211154242.K14877@pir.net> Mail-Followup-To: "Kenneth D. Merry" , freebsd-mobile@FreeBSD.ORG, scsi@FreeBSD.ORG References: <20000211111321.A12769@pir.net> <20000211103708.A57034@panzer.kdm.org> <20000204224930.B44997@cc942873-a.ewndsr1.nj.home.com> <200002052251.OAA12829@ptavv.es.net> <20000207175326.G9141@pir.net> <20000211134533.B14877@pir.net> <20000211124118.A57790@panzer.kdm.org> <20000211150048.J14877@pir.net> <20000211130638.A58011@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000211130638.A58011@panzer.kdm.org>; from ken@kdm.org on Fri, Feb 11, 2000 at 01:06:38PM -0700 X-fish: < Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" probably said: > Hmm. Well, try putting some printfs in cdopen() in > src/sys/cam/scsi/scsi_cd.c, and see where it is bailing out. I did that (and added CAM_DEBUG), recompiled, rebooted, tested and got ... no printfs. A little more poking showed up some differences between /dev/cd0* on the laptop and /dev/cd0* on another machine. cd /dev; ./MAKEDEV cd0 solved the problem. Mounts fine now :) Thanks for the help - turned out to be my fault. P. -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 13: 8:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by builder.freebsd.org (Postfix) with ESMTP id 31E054014 for ; Fri, 11 Feb 2000 13:08:47 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id NAA06524 for scsi@freebsd.org; Fri, 11 Feb 2000 13:35:54 -0800 (PST) Date: Fri, 11 Feb 2000 13:35:54 -0800 From: Alfred Perlstein To: scsi@freebsd.org Subject: translation of scsi error? Message-ID: <20000211133554.Q17536@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org da1 at ahc0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) (da1:ahc0:0:4:0): READ(10). CDB: 28 0 0 77 b e2 0 0 2 0 (da1:ahc0:0:4:0): MEDIUM ERROR info:770be2 csi:c,3f,0,97 asc:11,fe (da1:ahc0:0:4:0): Vendor Specific ASCQ field replaceable unit: 6e sks:80,0 When it seems that using my bt848 card pretty much coicides with this happening, but I have had this happen without fxtv, vinum then ditches the plex, but if I force it back up the drive seems fine. I can even read the entire drive via dd without a problem. Basically, is there a way for me to check what sort of error this means? What do I tell Quantum if i want them to take this drive back. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 13:24:54 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by builder.freebsd.org (Postfix) with ESMTP id BDD303DC1 for ; Fri, 11 Feb 2000 13:24:42 -0800 (PST) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA16973; Fri, 11 Feb 2000 13:24:03 -0800 Date: Fri, 11 Feb 2000 13:23:43 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: scsi@FreeBSD.ORG Subject: Re: translation of scsi error? In-Reply-To: <20000211133554.Q17536@fw.wintelcom.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 It means 'Replace this drive because media is coming off in big enough flakes to look like dark brown dandruff'... On Fri, 11 Feb 2000, Alfred Perlstein wrote: > da1 at ahc0 bus 0 target 4 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled > da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) > > (da1:ahc0:0:4:0): READ(10). CDB: 28 0 0 77 b e2 0 0 2 0 > (da1:ahc0:0:4:0): MEDIUM ERROR info:770be2 csi:c,3f,0,97 asc:11,fe > (da1:ahc0:0:4:0): Vendor Specific ASCQ field replaceable unit: 6e sks:80,0 > > When it seems that using my bt848 card pretty much coicides with this > happening, but I have had this happen without fxtv, vinum then > ditches the plex, but if I force it back up the drive seems fine. > > I can even read the entire drive via dd without a problem. > > Basically, is there a way for me to check what sort of error this means? > > What do I tell Quantum if i want them to take this drive back. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > 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 Feb 11 13:43:25 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by builder.freebsd.org (Postfix) with ESMTP id 10AB83DC1 for ; Fri, 11 Feb 2000 13:43:23 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id OAA07599; Fri, 11 Feb 2000 14:10:11 -0800 (PST) Date: Fri, 11 Feb 2000 14:10:10 -0800 From: Alfred Perlstein To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: translation of scsi error? Message-ID: <20000211141010.R17536@fw.wintelcom.net> References: <20000211133554.Q17536@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from mjacob@feral.com on Fri, Feb 11, 2000 at 01:23:43PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Jacob [000211 13:51] wrote: > > It means 'Replace this drive because media is coming off in big enough flakes > to look like dark brown dandruff'... *laugh* Point taken, calling quantum asap. thanks, -Alfred > On Fri, 11 Feb 2000, Alfred Perlstein wrote: > > > da1 at ahc0 bus 0 target 4 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled > > da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) > > > > (da1:ahc0:0:4:0): READ(10). CDB: 28 0 0 77 b e2 0 0 2 0 > > (da1:ahc0:0:4:0): MEDIUM ERROR info:770be2 csi:c,3f,0,97 asc:11,fe > > (da1:ahc0:0:4:0): Vendor Specific ASCQ field replaceable unit: 6e sks:80,0 > > > > When it seems that using my bt848 card pretty much coicides with this > > happening, but I have had this happen without fxtv, vinum then > > ditches the plex, but if I force it back up the drive seems fine. > > > > I can even read the entire drive via dd without a problem. > > > > Basically, is there a way for me to check what sort of error this means? > > > > What do I tell Quantum if i want them to take this drive back. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 19:10:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from borg-cube.com (226-193.adsl2.avtel.net [207.71.226.193]) by builder.freebsd.org (Postfix) with ESMTP id 52FC93ED3; Fri, 11 Feb 2000 19:10:40 -0800 (PST) Received: from borg-cube.com (dburr@borg-cube.com [207.71.226.193]) by borg-cube.com (8.9.3/8.9.3) with ESMTP id TAA28526; Fri, 11 Feb 2000 19:06:50 -0800 (PST) (envelope-from dburr@borg-cube.com) Date: Fri, 11 Feb 2000 19:06:46 -0800 (PST) From: Donald Burr To: FreeBSD Hardware Cc: FreeBSD SCSI Subject: Tekram DC-315U: what kind of chipset, and is it FBSD compatible? 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 found a nice SCSI card on ebay that I want to buy: http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=253753162 NEW! Tekram DC315U Ultra SCSI Controller Card This is an UltraSCSI (narrow 50pin, 20MB/sec) card, and the chipset is listed on the spec sheet as "Tekram S1040 Ultra SCSI processor" I thought the Tekram cards used the NCR/Symbios chips on them? Is this chip merely a re-labeled symbios part? And, most importantly, WILL IT WORK IN FREEBSD? Anyone who can provide assisntance, it would be greatly appreciated! Thanks! -- Donald Burr Resistance is Futile | FreeBSD: The WWW: http://www.borg-cube.com/ ICQ: UIN#16997506 | Power to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | Serve! http:// Phone: (805) 957-9666 FAX: (800) 492-5954 | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 11 19:52:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id AD6EE3EA7; Fri, 11 Feb 2000 19:52:43 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id UAA60486; Fri, 11 Feb 2000 20:21:34 -0700 (MST) (envelope-from ken) Date: Fri, 11 Feb 2000 20:21:33 -0700 From: "Kenneth D. Merry" To: Donald Burr Cc: FreeBSD Hardware , FreeBSD SCSI Subject: Re: Tekram DC-315U: what kind of chipset, and is it FBSD compatible? Message-ID: <20000211202133.A60458@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from dburr@borg-cube.com on Fri, Feb 11, 2000 at 07:06:46PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 11, 2000 at 19:06:46 -0800, Donald Burr wrote: > I found a nice SCSI card on ebay that I want to buy: > > http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=253753162 > NEW! Tekram DC315U Ultra SCSI Controller Card > > This is an UltraSCSI (narrow 50pin, 20MB/sec) card, and the chipset is > listed on the spec sheet as "Tekram S1040 Ultra SCSI processor" I thought > the Tekram cards used the NCR/Symbios chips on them? Is this chip merely > a re-labeled symbios part? And, most importantly, WILL IT WORK IN > FREEBSD? The S1040 is Tekram's own Ultra-Wide (i.e. 16 bit, 20Mhz) SCSI chip. The 315 just uses that chip in a narrow configuration, and I think the 395 is an Ultra-Wide board. You can use it for FreeBSD, since Tekram has written a FreeBSD/CAM driver for it. (Tekram is to be commended for supporting FreeBSD! They also wrote their own AMD driver, which is in our tree, and their own NCR driver for FreeBSD.) You'll have to download the driver from Tekram's web or ftp site (not sure where it is), and compile a new kernel. The catch is that at least from the way the driver is written, it doesn't look like the chip has a SCSI phase engine, so it probably won't perform very well. (i.e. several interrupts per transaction) If you want a Tekram board, I would suggest one of their NCR/Symbios/LSI based boards. You can use those with the sym driver, and they will perform pretty well. 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 Sun Feb 13 9: 6:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by builder.freebsd.org (Postfix) with ESMTP id 299DA43F7 for ; Sun, 13 Feb 2000 09:06:42 -0800 (PST) Received: from localhost (ppp-170-232.villette.club-internet.fr [195.36.170.232]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id SAA01315; Sun, 13 Feb 2000 18:04:00 +0100 (MET) Date: Sun, 13 Feb 2000 18:33:52 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Marc van Woerkom Cc: ngr@symbionics.co.uk, freebsd-scsi@FreeBSD.ORG Subject: Re: SC200/ncr53c810 problems In-Reply-To: <200002102357.AAA10864@oranje.my.domain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 11 Feb 2000, Marc van Woerkom wrote: > > The ncr53c810 is not PCI2.1 compliant, which I have found to matter. Early 53C810 are PCI-2.0 compliant. Differences between PCI-2.1 and PCI-2.0 should not explain 53C810 failures, on paper. However hardware has issues as software and may-be some issue can be triggerred when associating recent hardwares with old ones. And given the zero interest in things that donnot give income in our world, such kind of problem will for sure be ignored. On the other hand, the chip or board can be broken in a way that let it=20 work but with a high rate of problems that makes it unusable for real work. Another difference is that old PCI chips require 5 Volt PCI, while recent PCI boards uses 3.3 Volt PCI preferently but can support 5V PCI. I donnot know if this difference can explain problems encountered with 53C810 based controller, but I expect vendors to be more careful about 3.3 Volt PCI than 5 Volt PCI or mixed 3.3 Volt / 5 Volt PCI. I mean that we may not want to mix 3.3V PCI boards with 5V PCI boards on a given PCI BUS, even if this is claimed to be supported. > > Heavy pressure on the bus is more likely to reveal this. I'm sure > > an 875 based card would improve matters, but hey, I'm not there. >=20 > What worries me is that I have seen very few bug reports regarding > 810 cards. So most people seem to have no trouble at all. I still use a 53C810 rev 2 on my personal machine at work. Run Linux and FreeBSD and from time to time has to suffer running NT. No problem. But the machine is indeed not a server. > Heck, guess I will buy a new controller anyway. >=20 > What is preferable? >=20 > a) a SYM53C875 based card > b) a SYM53C885 based one=20 The 885 is a 2 function devices that incorporates a 875-like core and a=20 network chip. Linux has a driver for the network part and I donnot seem=20 to find one in FreeBSD. If FreeBSD hasn't a driver, the Linux one's could= =20 be ported. The source code looks fine. If you didn't want or need LVD (low voltage differential), the 53C875 (or= =20 53C876 dual-channel) will be just fine. For Ultra2/LVD a 53C895 or 53C895A or 53C896 (dual) would be ok. Depends on how much money one wants to pay for one's SCSI controller(s). Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 14 6:37:14 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by builder.freebsd.org (Postfix) with ESMTP id 400944097 for ; Mon, 14 Feb 2000 06:37:09 -0800 (PST) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id HAA00367; Mon, 14 Feb 2000 07:37:47 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200002141437.HAA00367@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Chris Johnson Cc: "Justin T. Gibbs" , scsi@FreeBSD.org, lamaster@nren.nasa.gov Subject: Re: BT-948 timeouts In-reply-to: Your message of "Thu, 10 Feb 2000 04:55:43 EST." <20000210045543.A57016@palomine.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Feb 2000 07:37:47 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Thanks very much for your response. > >Here's what I did: > >su-2.03# camcontrol tags da0 -N 8 > >And here's the result: > >su-2.03# camcontrol tags da0 -v >(pass0:bt0:0:6:0): dev_openings 8 >(pass0:bt0:0:6:0): dev_active 0 >(pass0:bt0:0:6:0): devq_openings 8 >(pass0:bt0:0:6:0): devq_queued 0 >(pass0:bt0:0:6:0): held 0 >(pass0:bt0:0:6:0): mintags 2 >(pass0:bt0:0:6:0): maxtags 255 > >This seems to have done the trick. I built a world without any timeouts, which >I hadn't been able to do before I made the change. > >Is there a fancy way to make this change survive across boots, or should >I just shove the camcontrol command in a script that runs at boot time? You can add a quirk to sys/cam/cam_xpt.c for your drive that will limit the number of tags to use. >How would I go about learning what the tags setting should be for a particular >drive? CAM can determine the maximum number if you attach the drive to a controller that will report the QUEUE FULL status (ahc, sym, ncr, aic). When the system stops reducing the number of tags (while the device is under a heavy transaction load), you know that you've found the device's limit. >Chris > -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 14 16:46:26 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by builder.freebsd.org (Postfix) with ESMTP id 09D6A4E71 for ; Mon, 14 Feb 2000 16:32:12 -0800 (PST) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id QAA19671 for ; Mon, 14 Feb 2000 16:32:28 -0800 (PST) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 14 Feb 2000 16:32:28 -0800 (PST) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: SCSI FreeBSD Subject: Re: SC200/ncr53c810 problems In-Reply-To: <200002100100.CAA00993@oranje.my.domain> 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 Thu, 10 Feb 2000, Marc van Woerkom wrote: > Now I believe the SC200 card sucks for some unknown reason. I've used an early SC200 for years; haven't seen any problem on a system that was pre-CAM (was 3.0-current as of last March or so?), hasn't been updated since. I'm hoping that it will still work fine when I go to 3.4-STABLE ... Anyway, it isn't a bad card, although it doesn't have IRQ flexibility. (That reminds me: can any/all FreeBSD PCI drivers share IRQ's? I'm running out (SCSI controller, EIDE, Audio, Video card, ... ) If so, any pointers to documentation? -- Hugh LaMaster, M/S 233-21, Email: lamaster@nren.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@george.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 15 10: 6:54 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from alpham.uni-mb.si (alpham.uni-mb.si [164.8.1.101]) by builder.freebsd.org (Postfix) with ESMTP id 3941D4A21; Tue, 15 Feb 2000 09:57:03 -0800 (PST) Received: from gea.uni-mb.si by alpham.uni-mb.si (PMDF V5.1-12 #7554) with ESMTP id <01JLY3PUZJZM006OTE@alpham.uni-mb.si>; Tue, 15 Feb 2000 18:57:28 MET Received: from localhost (david@localhost) by gea.uni-mb.si (8.9.3/8.9.3/19990328) with SMTP id SAA44343; Tue, 15 Feb 2000 18:57:27 +0100 (CET) Date: Tue, 15 Feb 2000 18:57:27 +0100 (CET) From: David Vrtin Subject: RAID disks and FreeBSD To: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Reply-To: David Vrtin Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-No-Archive: Yes Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello I have Pentium 200Mhz, 2 processors, Adaptec AHA-2940, ASUS PCI-DA2101 PCI-to-SCSI RAID. I have tryed to install FreeBSD 3.4R and 4.0-20000208-CURRENT without success - FreeBSD cannot find any disks. MS Windows NT 4.0 Server works without any problems. On WinNT I see: - Adaptec AHA-294X/AHA-394X or .... (etc) - ASUS PCI-DA2000 Series RAID Miniport, na njem pa so: - ASUS PCI-DA2101 (to je disk) - ASUS PCI-DA2101 (to je pa se en disk) - MATSHITA CD-ROM CR-506 - ASUS Virtual Target Any idea, why I cannot see disks from FreeBSD ? Best regards, David -- David Vrtin (system manager) # tel: +386 62 220-7129 University of Maribor, Faculty of EE and CS # fax: +386 62 211-178 Smetanova 17, SI-2000 Maribor, Slovenia # www.uni-mb.si/~david/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 15 17: 3:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [195.37.179.254]) by builder.freebsd.org (Postfix) with ESMTP id B79525202 for ; Tue, 15 Feb 2000 16:13:13 -0800 (PST) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id BAA02011; Wed, 16 Feb 2000 01:08:22 +0100 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id BAA97277; Wed, 16 Feb 2000 01:04:50 +0100 (CET) Date: Wed, 16 Feb 2000 01:04:50 +0100 (CET) From: Juergen Lock Message-Id: <200002160004.BAA97277@saturn.kn-bremen.de> To: groudier@club-internet.fr Subject: Re: SC200/ncr53c810 problems X-Newsgroups: local.list.freebsd.scsi In-Reply-To: References: <200002102357.AAA10864@oranje.my.domain> Organization: home Cc: Marc van Woerkom , ngr@symbionics.co.uk, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > > >On Fri, 11 Feb 2000, Marc van Woerkom wrote: > >> > The ncr53c810 is not PCI2.1 compliant, which I have found to matter. > >Early 53C810 are PCI-2.0 compliant. Differences between PCI-2.1 and >PCI-2.0 should not explain 53C810 failures, on paper. However hardware has >issues as software and may-be some issue can be triggerred when >associating recent hardwares with old ones. And given the zero interest >in things that donnot give income in our world, such kind of problem will >for sure be ignored. Didn't the 53C810 have the problem that some of its controller instruction caused io cycles to appear on the bus that were in fact internal, violating the latest PCI standards? and only the later symbios' have replacements for these instructions that no longer do that... or was that something else that i remember? curious, -- Juergen Lock (remove dot foo from address to reply) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 15 20:14:51 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by builder.freebsd.org (Postfix) with ESMTP id C7B574562; Tue, 15 Feb 2000 20:14:46 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA65556; Tue, 15 Feb 2000 21:14:57 -0700 (MST) (envelope-from ken) Date: Tue, 15 Feb 2000 21:14:57 -0700 From: "Kenneth D. Merry" To: David Vrtin Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: RAID disks and FreeBSD Message-ID: <20000215211457.A65314@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from vrtin@uni-mb.si on Tue, Feb 15, 2000 at 06:57:27PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 15, 2000 at 18:57:27 +0100, David Vrtin wrote: > Hello > > > I have Pentium 200Mhz, 2 processors, Adaptec AHA-2940, ASUS PCI-DA2101 > PCI-to-SCSI RAID. I have tryed to install FreeBSD 3.4R and > 4.0-20000208-CURRENT without success - FreeBSD cannot find any disks. > > MS Windows NT 4.0 Server works without any problems. On WinNT I see: > > - Adaptec AHA-294X/AHA-394X or .... (etc) > > - ASUS PCI-DA2000 Series RAID Miniport, na njem pa so: > - ASUS PCI-DA2101 (to je disk) > - ASUS PCI-DA2101 (to je pa se en disk) > - MATSHITA CD-ROM CR-506 > - ASUS Virtual Target > > Any idea, why I cannot see disks from FreeBSD ? The ASUS RAID controller isn't supported under FreeBSD. (Unless it is a clone of a supported Mylex, AMI, DPT or Compaq controller. That is doubtful, since I don't think any of those controllers use 486s.) If you move your drives to the Adaptec controller, you should be able to install FreeBSD. 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 Wed Feb 16 9:24: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id B72B537B54B; Wed, 16 Feb 2000 09:23:58 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (castles549.castles.com [208.214.165.113]) by builder.freebsd.org (Postfix) with ESMTP id 18178132E5; Wed, 16 Feb 2000 09:23:19 -0800 (PST) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id JAA00675; Wed, 16 Feb 2000 09:34:13 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200002161734.JAA00675@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: David Vrtin , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: RAID disks and FreeBSD In-reply-to: Your message of "Tue, 15 Feb 2000 21:14:57 MST." <20000215211457.A65314@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Feb 2000 09:34:13 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, Feb 15, 2000 at 18:57:27 +0100, David Vrtin wrote: > > Hello > > > > > > I have Pentium 200Mhz, 2 processors, Adaptec AHA-2940, ASUS PCI-DA2101 > > PCI-to-SCSI RAID. I have tryed to install FreeBSD 3.4R and > > 4.0-20000208-CURRENT without success - FreeBSD cannot find any disks. > > > > MS Windows NT 4.0 Server works without any problems. On WinNT I see: > > > > - Adaptec AHA-294X/AHA-394X or .... (etc) > > > > - ASUS PCI-DA2000 Series RAID Miniport, na njem pa so: > > - ASUS PCI-DA2101 (to je disk) > > - ASUS PCI-DA2101 (to je pa se en disk) > > - MATSHITA CD-ROM CR-506 > > - ASUS Virtual Target > > > > Any idea, why I cannot see disks from FreeBSD ? > > The ASUS RAID controller isn't supported under FreeBSD. (Unless it is a > clone of a supported Mylex, AMI, DPT or Compaq controller. That is > doubtful, since I don't think any of those controllers use 486s.) It's an Infortrend controller; I've pestered Infortrend about it (no response) and looked at a disassembly of their Linux driver. It looks like a very simple mailbox-based interface like everyone else uses, but given the CPU I expect it to be rather underpowered. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 16 14:58:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id F250D37B505 for ; Wed, 16 Feb 2000 14:58:24 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by builder.freebsd.org (Postfix) with ESMTP id BF014132E2 for ; Wed, 16 Feb 2000 14:57:41 -0800 (PST) Received: from localhost (ppp-98-118.villette.club-internet.fr [194.158.98.118]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA04744; Wed, 16 Feb 2000 23:58:03 +0100 (MET) Date: Thu, 17 Feb 2000 00:28:08 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Juergen Lock Cc: Marc van Woerkom , ngr@symbionics.co.uk, freebsd-scsi@FreeBSD.ORG Subject: Re: SC200/ncr53c810 problems In-Reply-To: <200002160004.BAA97277@saturn.kn-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 16 Feb 2000, Juergen Lock wrote: > In article you write= : > > > > > >On Fri, 11 Feb 2000, Marc van Woerkom wrote: > > > >> > The ncr53c810 is not PCI2.1 compliant, which I have found to matter. > > > >Early 53C810 are PCI-2.0 compliant. Differences between PCI-2.1 and > >PCI-2.0 should not explain 53C810 failures, on paper. However hardware h= as > >issues as software and may-be some issue can be triggerred when > >associating recent hardwares with old ones. And given the zero interest > >in things that donnot give income in our world, such kind of problem wil= l > >for sure be ignored. >=20 > Didn't the 53C810 have the problem that some of its controller > instruction caused io cycles to appear on the bus that were > in fact internal, violating the latest PCI standards? > and only the later symbios' have replacements for these > instructions that no longer do that... Hmmm... According PCI-2.2 / 3.10.9, a PCI device that accesses it target core as a master through the PCI BUS is not PCI-2.2 compliant. Reason is that PCI-2.2 requirement about Tprop considers the worst case of= =20 signal propagation to be when a device drives a signal and this signal =20 settles at the input of all _other_ devices. Due to the design of PCI (signals are driven at half their nominal level and reflection will do the rest of the work), it is longer for a signal=20 to settle at the driving device than at all other devices. In other words, Tprop for the driving device can be longer than the worst= =20 case considered by PCI-2.2. In result, a PCI-2.2 compliant PCI BUS system that does have no timing budget margin at all can lead to a Tprop for the driving device to be outside PCI-2.2 specifications. In real life, it seems that common 33 MHz PCI BUS systems overclocked to something like 37 MHz (even 40 MHz) still work reasonnably well. Such=20 PCI BUSses have enough margin for PCI devices that master them-selves to=20 meet PCI-2.2 Tprop requirement for 33 MHz clock, in my opinion. This let me think that a _real_ 33 MHz PCI device failing Tprop requirement due to mastering itself can only happen on PCI BUSses that have so few margin that a simple fly that would f*rt too loudly inside the box can break any PCI signaling requirement.:-)=20 However, I think that standard compliance is a serious concern and I have addressed the PCI-2.2 / 3.10.9 requirement in the Linux sym53c8xx driver a short time after I heard about this requirement (I hadn't the PCI-2.2 specs at that time but I read the PCI-sig list). Obviously, the FreeBSD `sym' driver is also ok regarding this requirement. However, for this to be achieved, the SCSI SCRIPTS shall not access chip IO registers using MEMORY MOVE SCRIPTS instructions, but should use LOAD/STORE instead or IO register to IO register operations.=20 Old ncr chips donnot support LOAD/STORE. On the other hand, a driver for these old chips that will not use MEMORY MOVE to access IO registers from SCRIPTS would be painful to write and would probably have bad performances (I donnot want to think a single second to such a stuff).=20 My conclusion is the following: 1) If you want your SYM53C8XX PCI-SCSI chip to not perform self-mastering,= =20 you should purchase a controller supported by the `sym' driver. 2) If you encounter problems with a SYM53C8XX PCI-SCSI chip using the `ncr' driver (self-mastering occuring for IO register reads and may-be self-modifying SCRIPTS in on-chip SRAM), these problems are very unlikely to be due to Tprop not meeting PCI-2.2 requirements (because=20 of self-mastering occuring). Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 16 15:52: 6 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id AC02437B513 for ; Wed, 16 Feb 2000 15:52:05 -0800 (PST) (envelope-from bharat@menalto.com) Received: from menalto.com (m206-35.dsl.tsoft.com [198.144.206.35]) by builder.freebsd.org (Postfix) with ESMTP id 432A5132DE for ; Wed, 16 Feb 2000 15:51:23 -0800 (PST) Received: from firebrand (firebrand [10.0.0.7]) by menalto.com (8.9.3/8.9.3) with SMTP id PAA09310 for ; Wed, 16 Feb 2000 15:52:04 -0800 (PST) (envelope-from bharat@menalto.com) From: "Bharat Mediratta" To: Subject: OnStream 30Gb SCSI drive Date: Wed, 16 Feb 2000 15:51:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, guys. It's time to revisit the "are there drivers for the OnStream SCSI drives?" question again. I checked the geocrawler and deja websites (since FreeBSD's search is still down) and didn't see any posts more recent than 8/99. Is anybody still working on this? I'm offering my services in both the driver development and testing arenas, let me know. Thanks, -Bharat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 16 16:29:47 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from builder.freebsd.org (builder.FreeBSD.ORG [204.216.27.24]) by hub.freebsd.org (Postfix) with ESMTP id 345D537B513 for ; Wed, 16 Feb 2000 16:29:46 -0800 (PST) (envelope-from cstaylor@ezln23.thedial.com) Received: from ezln23.thedial.com (ezln23.thedial.com [204.252.162.130]) by builder.freebsd.org (Postfix) with ESMTP id C7BD4132EC for ; Wed, 16 Feb 2000 16:29:06 -0800 (PST) Received: from cstaylor by ezln23.thedial.com with local (Exim 3.12 #1 (Debian)) id 12LEpD-0004vh-00 for ; Wed, 16 Feb 2000 16:29:43 -0800 Date: Wed, 16 Feb 2000 16:29:43 -0800 From: Christopher Taylor To: scsi@freebsd.org Message-ID: <20000216162943.B3956@thedial.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe chris@thedial.com -- Christopher Taylor theDial Director of Research and Development http://www.thedial.com/ 3131 Elliott Ave, Suite 750 phone: (206) 352-8200 x2002 Seattle, WA 98121 cellular: (206) 409-3394 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 17 0:37:47 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from astralblue.com (adsl-209-76-108-39.dsl.snfc21.pacbell.net [209.76.108.39]) by hub.freebsd.org (Postfix) with ESMTP id BC45E37B662 for ; Thu, 17 Feb 2000 00:37:44 -0800 (PST) (envelope-from ab@astralblue.com) Received: from localhost (ab@localhost) by astralblue.com (8.9.3/8.9.3) with ESMTP id AAA05383; Thu, 17 Feb 2000 00:37:42 -0800 (PST) (envelope-from ab@astralblue.com) Date: Thu, 17 Feb 2000 00:37:42 -0800 (PST) From: "Eugene M. Kim" To: Bharat Mediratta Cc: FreeBSD SCSI Mailing List Subject: Re: OnStream 30Gb SCSI drive 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 Actually I was thinking of doing this myself (got hands on all necessary documents and studied them; kudos to OnStream for making the programming information readily available on the website). The problem is that the ADR standard is not a superset of the standard for SCSI sequential access device. It uses the almost same command set, but the way they execute those commands is much different from the standard SCSI way. Given this, I think the best way to support this device is probably some kind of port that uses passthrough interface (much in the same way cdrecord handles CD-Rs). If we can make the port behave like rmt(8), it could be easily integrated into the preexisting backup/restore system. BTW, I have a SC50 drive to play around with. Thanks, Eugene On Wed, 16 Feb 2000, Bharat Mediratta wrote: | | Hi, guys. It's time to revisit the "are there drivers for the | OnStream SCSI drives?" question again. I checked the geocrawler | and deja websites (since FreeBSD's search is still down) and | didn't see any posts more recent than 8/99. Is anybody still | working on this? I'm offering my services in both the driver | development and testing arenas, let me know. | | Thanks, | -Bharat | | | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-scsi" in the body of the message | -- Eugene M. Kim "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 17 21:20:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mailman.cs.ucla.edu (Mailman.CS.UCLA.EDU [131.179.128.30]) by hub.freebsd.org (Postfix) with ESMTP id 7AEFA37B7E7 for ; Thu, 17 Feb 2000 21:20:45 -0800 (PST) (envelope-from scottm@CS.UCLA.EDU) Received: from mordred.cs.ucla.edu (mordred.cs.ucla.edu [131.179.192.128]) by mailman.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id VAA25784 for ; Thu, 17 Feb 2000 21:20:44 -0800 (PST) Received: (from scottm@localhost) by mordred.cs.ucla.edu (8.9.3/UCLACS-5.0) id VAA00409 for freebsd-scsi@freebsd.org; Thu, 17 Feb 2000 21:20:47 -0800 (PST) Date: Thu, 17 Feb 2000 21:20:47 -0800 (PST) From: Scott Michel Message-Id: <200002180520.VAA00409@mordred.cs.ucla.edu> To: freebsd-scsi@freebsd.org Subject: Still got problems with Sony SDT-5000... Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I applied the suggestion NODREAD quirk, but still no joy. flexbackup executes the following sequence of commands: mt -f /dev/nrsa0 blocksize 0 mt -f /dev/nrsa0 comp on mt -f /dev/nrsa0 rewind dd ibs=16k obs=16k conv=noerror,sync count=1 if=/dev/nrsa0 #-- Here's where the driver appears to lose the session #-- following command fails, tape is frozen printf '200002131331.46\nThis is a flexbackup index key\n' | \ dd ibs=16k obs=16k conv=noerror,sync of=/dev/nrsa0 I've changed tapes, no joy. I've double checked bus termination, and everything looks kosher. Any further suggestions? -scooter --- dmesg, with boot -v and CAMDEBUG turned on: Feb 17 20:50:14 mordred /kernel: Copyright (c) 1992-1999 FreeBSD Inc. Feb 17 20:50:14 mordred /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Feb 17 20:50:14 mordred /kernel: The Regents of the University of California. All rights reserved. Feb 17 20:50:14 mordred /kernel: FreeBSD 3.4-STABLE #2: Thu Feb 17 20:36:17 PST 2000 Feb 17 20:50:14 mordred /kernel: root@mordred.cs.ucla.edu:/usr/src/sys/compile/MORDRED Feb 17 20:50:14 mordred /kernel: Calibrating clock(s) ... TSC clock: 233875275 Hz, i8254 clock: 1193241 Hz Feb 17 20:50:14 mordred /kernel: Press a key on the console to abort clock calibration Feb 17 20:50:14 mordred /kernel: Calibrating clock(s) ... TSC clock: 233877552 Hz, i8254 clock: 1193253 Hz Feb 17 20:50:14 mordred /kernel: Calibrating clock(s) ... TSC clock: 233875318 Hz, i8254 clock: 1193242 Hz Feb 17 20:50:14 mordred /kernel: Timecounter "i8254" frequency 1193241 Hz Feb 17 20:50:14 mordred /kernel: Timecounter "TSC" frequency 233875318 Hz Feb 17 20:50:14 mordred /kernel: CPU: AMD-K6tm w/ multimedia extensions (233.88-MHz 586-class CPU) Feb 17 20:50:14 mordred /kernel: Origin = "AuthenticAMD" Id = 0x562 Stepping = 2 Feb 17 20:50:14 mordred /kernel: Features=0x8001bf Feb 17 20:50:14 mordred /kernel: AMD Features=0x400<> Feb 17 20:50:14 mordred /kernel: Data TLB: 128 entries, 2-way associative Feb 17 20:50:14 mordred /kernel: Instruction TLB: 64 entries, 1-way associative Feb 17 20:50:14 mordred /kernel: L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Feb 17 20:50:14 mordred /kernel: L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Feb 17 20:50:14 mordred /kernel: Write Allocate Enable Limit: 64M bytes Feb 17 20:50:14 mordred /kernel: Write Allocate 15-16M bytes: Disable Feb 17 20:50:14 mordred /kernel: Hardware Write Allocate Control: Disable Feb 17 20:50:14 mordred /kernel: real memory = 67108864 (65536K bytes) Feb 17 20:50:14 mordred /kernel: Physical memory chunk(s): Feb 17 20:50:14 mordred /kernel: 0x00001000 - 0x0009efff, 647168 bytes (158 pages) Feb 17 20:50:14 mordred /kernel: 0x002d9000 - 0x03ff5fff, 64081920 bytes (15645 pages) Feb 17 20:50:14 mordred /kernel: avail memory = 62734336 (61264K bytes) Feb 17 20:50:14 mordred /kernel: Found BIOS32 Service Directory header at 0xc00fb0b0 Feb 17 20:50:14 mordred /kernel: Entry = 0xfb530 (0xc00fb530) Rev = 0 Len = 1 Feb 17 20:50:14 mordred /kernel: PCI BIOS entry at 0xb560 Feb 17 20:50:14 mordred /kernel: DMI header at 0xc00f5e80 Feb 17 20:50:14 mordred /kernel: Version 2.0 Feb 17 20:50:14 mordred /kernel: Table at 0xf0800, 25 entries, 574 bytes Feb 17 20:50:14 mordred /kernel: Other BIOS signatures found: Feb 17 20:50:14 mordred /kernel: ACPI: 00000000 Feb 17 20:50:14 mordred /kernel: $PnP: 000fc0e0 Feb 17 20:50:14 mordred /kernel: Preloaded elf kernel "kernel" at 0xc02c0000. Feb 17 20:50:14 mordred /kernel: VESA: information block Feb 17 20:50:14 mordred /kernel: 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 Feb 17 20:50:14 mordred /kernel: 00 01 00 01 02 03 07 01 00 01 0e 01 00 01 17 01 Feb 17 20:50:14 mordred /kernel: 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 Feb 17 20:50:14 mordred /kernel: 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 Feb 17 20:50:14 mordred /kernel: VESA: 44 mode(s) found Feb 17 20:50:14 mordred /kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x80003840 Feb 17 20:50:14 mordred /kernel: pci_open(1a): mode1res=0x80000000 (0x80000000) Feb 17 20:50:14 mordred /kernel: pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=05971106) Feb 17 20:50:14 mordred /kernel: Probing for devices on PCI bus 0: Feb 17 20:50:14 mordred /kernel: found-> vendor=0x1106, dev=0x0597, revid=0x01 Feb 17 20:50:14 mordred /kernel: class=06-00-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:14 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:14 mordred /kernel: map[0]: type 3, range 32, base e0000000, size 26 Feb 17 20:50:14 mordred /kernel: chip0: rev 0x01 on pci0.0.0 Feb 17 20:50:14 mordred /kernel: found-> vendor=0x1106, dev=0x8597, revid=0x00 Feb 17 20:50:14 mordred /kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Feb 17 20:50:14 mordred /kernel: subordinatebus=1 secondarybus=1 Feb 17 20:50:14 mordred /kernel: chip1: rev 0x00 on pci0.1.0 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1106, dev=0x0586, revid=0x41 Feb 17 20:50:15 mordred /kernel: class=06-01-00, hdrtype=0x00, mfdev=1 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: chip2: rev 0x41 on pci0.7.0 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1106, dev=0x0571, revid=0x06 Feb 17 20:50:15 mordred /kernel: class=01-01-8a, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: map[0]: type 4, range 32, base 0000f400, size 4 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1106, dev=0x3038, revid=0x02 Feb 17 20:50:15 mordred /kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: intpin=d, irq=11 Feb 17 20:50:15 mordred /kernel: map[0]: type 4, range 32, base 0000f500, size 5 Feb 17 20:50:15 mordred /kernel: uhci0: rev 0x02 int d irq 11 on pci0.7.2 Feb 17 20:50:15 mordred /kernel: usb0: USB version 1.0, interrupting at 11 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1106, dev=0x3040, revid=0x10 Feb 17 20:50:15 mordred /kernel: class=06-80-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: chip3: rev 0x10 on pci0.7.3 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1000, dev=0x000f, revid=0x03 Feb 17 20:50:15 mordred /kernel: class=01-00-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: intpin=a, irq=9 Feb 17 20:50:15 mordred /kernel: map[0]: type 4, range 32, base 0000f600, size 8 Feb 17 20:50:15 mordred /kernel: map[1]: type 1, range 32, base e4009000, size 8 Feb 17 20:50:15 mordred /kernel: map[2]: type 1, range 32, base e4008000, size 12 Feb 17 20:50:15 mordred /kernel: ncr0: rev 0x03 int a irq 9 on pci0.8.0 Feb 17 20:50:15 mordred /kernel: ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo Feb 17 20:50:15 mordred /kernel: ncr0: single-ended, open drain IRQ driver, using on-chip SRAM Feb 17 20:50:15 mordred /kernel: found-> vendor=0x1073, dev=0x000d, revid=0x03 Feb 17 20:50:15 mordred /kernel: class=04-01-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: intpin=a, irq=11 Feb 17 20:50:15 mordred /kernel: map[0]: type 1, range 32, base e4000000, size 15 Feb 17 20:50:15 mordred /kernel: found-> vendor=0x11ad, dev=0x0002, revid=0x20 Feb 17 20:50:15 mordred /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:15 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:15 mordred /kernel: intpin=a, irq=11 Feb 17 20:50:15 mordred /kernel: map[0]: type 4, range 32, base 0000f700, size 8 Feb 17 20:50:15 mordred /kernel: map[1]: type 1, range 32, base e400a000, size 8 Feb 17 20:50:15 mordred /kernel: pn0: <82c169 PNIC 10/100BaseTX> rev 0x20 int a irq 11 on pci0.11.0 Feb 17 20:50:15 mordred /kernel: using shared irq11. Feb 17 20:50:15 mordred /kernel: pn0: Ethernet address: 00:a0:cc:56:bc:7a Feb 17 20:50:15 mordred /kernel: pn0: probing for a PHY Feb 17 20:50:15 mordred /kernel: pn0: checking address: 0 Feb 17 20:50:15 mordred /kernel: pn0: checking address: 1 Feb 17 20:50:15 mordred /kernel: pn0: found PHY at address 1, vendor id: 40 device id: 6212 Feb 17 20:50:15 mordred /kernel: pn0: PHY type: Feb 17 20:50:15 mordred /kernel: pn0: PHY status word: 7809 Feb 17 20:50:15 mordred /kernel: pn0: 10Mbps half-duplex mode supported Feb 17 20:50:15 mordred /kernel: pn0: 10Mbps full-duplex mode supported Feb 17 20:50:15 mordred /kernel: pn0: 100Mbps half-duplex mode supported Feb 17 20:50:15 mordred /kernel: pn0: 100Mbps full-duplex mode supported Feb 17 20:50:15 mordred /kernel: pn0: autoneg supported Feb 17 20:50:15 mordred /kernel: pn0: autoneg complete, link status good (full-duplex, 100Mbps) Feb 17 20:50:15 mordred /kernel: bpf: pn0 attached Feb 17 20:50:15 mordred /kernel: Probing for devices on PCI bus 1: Feb 17 20:50:15 mordred /kernel: found-> vendor=0x10de, dev=0x0020, revid=0x04 Feb 17 20:50:16 mordred /kernel: class=03-00-00, hdrtype=0x00, mfdev=0 Feb 17 20:50:16 mordred /kernel: subordinatebus=0 secondarybus=0 Feb 17 20:50:16 mordred /kernel: intpin=a, irq=9 Feb 17 20:50:16 mordred /kernel: map[0]: type 1, range 32, base d8000000, size 24 Feb 17 20:50:16 mordred /kernel: map[1]: type 3, range 32, base a8000000, size 24 Feb 17 20:50:16 mordred /kernel: vga0: rev 0x04 int a irq 9 on pci1.5.0 Feb 17 20:50:16 mordred /kernel: Initializing PnP override table Feb 17 20:50:16 mordred /kernel: Probing for PnP devices: Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 203 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 243 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 283 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 2c3 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 303 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 343 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 383 Feb 17 20:50:16 mordred /kernel: Trying Read_Port at 3c3 Feb 17 20:50:16 mordred /kernel: No Plug-n-Play devices were found Feb 17 20:50:16 mordred /kernel: Probing for devices on the ISA bus: Feb 17 20:50:16 mordred /kernel: atkbd: the current kbd controller command byte 0047 Feb 17 20:50:16 mordred /kernel: kbdc: DIAGNOSE status:00aa Feb 17 20:50:16 mordred /kernel: kbdc: TEST_KBD_PORT status:0000 Feb 17 20:50:16 mordred /kernel: atkbd: keyboard ID 0xffffffff (1) Feb 17 20:50:16 mordred /kernel: kbdc: RESET_KBD return code:00fa Feb 17 20:50:16 mordred /kernel: kbdc: RESET_KBD status:00aa Feb 17 20:50:16 mordred /kernel: sc0 on isa Feb 17 20:50:16 mordred /kernel: sc0: fb0 kbd0 Feb 17 20:50:16 mordred /kernel: sc0: VGA color <6 virtual consoles, flags=0x0> Feb 17 20:50:16 mordred /kernel: atkbdc0 at 0x60-0x6f on motherboard Feb 17 20:50:16 mordred /kernel: atkbd0 irq 1 on isa Feb 17 20:50:16 mordred /kernel: kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 Feb 17 20:50:16 mordred /kernel: psm0: current command byte:0047 Feb 17 20:50:16 mordred /kernel: kbdc: TEST_AUX_PORT status:0000 Feb 17 20:50:16 mordred /kernel: kbdc: RESET_AUX return code:00fa Feb 17 20:50:16 mordred /kernel: kbdc: RESET_AUX status:00aa Feb 17 20:50:16 mordred /kernel: kbdc: RESET_AUX ID:0000 Feb 17 20:50:16 mordred /kernel: psm: status 00 02 64 Feb 17 20:50:16 mordred /kernel: psm: status 09 03 c8 Feb 17 20:50:16 mordred last message repeated 2 times Feb 17 20:50:16 mordred /kernel: psm: status 10 00 64 Feb 17 20:50:16 mordred /kernel: psm: data 08 00 00 Feb 17 20:50:16 mordred /kernel: psm: status 00 02 64 Feb 17 20:50:16 mordred /kernel: psm: data 08 00 00 Feb 17 20:50:16 mordred /kernel: psm: status 00 02 64 Feb 17 20:50:16 mordred /kernel: psm0 irq 12 on isa Feb 17 20:50:16 mordred /kernel: psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons Feb 17 20:50:16 mordred /kernel: psm0: config:00000000, flags:00000000, packet size:3 Feb 17 20:50:16 mordred /kernel: psm0: syncmask:c0, syncbits:00 Feb 17 20:50:16 mordred /kernel: sio0: irq maps: 0x1 0x11 0x1 0x1 Feb 17 20:50:16 mordred /kernel: sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa Feb 17 20:50:16 mordred /kernel: sio0: type 16550A Feb 17 20:50:16 mordred /kernel: sio1: irq maps: 0x1 0x9 0x1 0x1 Feb 17 20:50:16 mordred /kernel: sio1 at 0x2f8-0x2ff irq 3 flags 0x10 on isa Feb 17 20:50:16 mordred /kernel: sio1: type 16550A Feb 17 20:50:16 mordred /kernel: ppc0: disabled, not probed. Feb 17 20:50:16 mordred /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Feb 17 20:50:16 mordred /kernel: fdc0: FIFO enabled, 8 bytes threshold Feb 17 20:50:16 mordred /kernel: fd0: 1.44MB 3.5in Feb 17 20:50:16 mordred /kernel: vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa Feb 17 20:50:16 mordred /kernel: fb0: vga0, vga, type:VGA (5), flags:0x700ff Feb 17 20:50:17 mordred /kernel: fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 Feb 17 20:50:17 mordred /kernel: fb0: init mode:24, bios mode:3, current mode:24 Feb 17 20:50:17 mordred /kernel: fb0: window:0xc00b8000 size:32k gran:32k, buf:0x0 size:0k Feb 17 20:50:17 mordred /kernel: VGA parameters upon power-up Feb 17 20:50:17 mordred /kernel: 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 Feb 17 20:50:17 mordred /kernel: bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 Feb 17 20:50:17 mordred /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Feb 17 20:50:17 mordred /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Feb 17 20:50:17 mordred /kernel: VGA parameters in BIOS for mode 24 Feb 17 20:50:17 mordred /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Feb 17 20:50:17 mordred /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Feb 17 20:50:17 mordred /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Feb 17 20:50:17 mordred /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Feb 17 20:50:17 mordred /kernel: EGA/VGA parameters to be used for mode 24 Feb 17 20:50:17 mordred /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Feb 17 20:50:17 mordred /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Feb 17 20:50:17 mordred /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Feb 17 20:50:17 mordred /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Feb 17 20:50:17 mordred /kernel: VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc027271e (1000022) Feb 17 20:50:17 mordred /kernel: VESA: NVidia Feb 17 20:50:17 mordred /kernel: VESA: NVidia Feb 17 20:50:17 mordred /kernel: VESA: Riva TNT Feb 17 20:50:17 mordred /kernel: VESA: A0 Feb 17 20:50:17 mordred /kernel: npx0 on motherboard Feb 17 20:50:17 mordred /kernel: npx0: INT 16 interface Feb 17 20:50:17 mordred /kernel: i586_bzero() bandwidth = 62928701 bytes/sec Feb 17 20:50:17 mordred /kernel: bzero() bandwidth = 130633572 bytes/sec Feb 17 20:50:17 mordred /kernel: imasks: bio c0080840, tty c003101a, net c0060800 Feb 17 20:50:17 mordred /kernel: usb0: Feb 17 20:50:17 mordred /kernel: uhub0 at usb0 Feb 17 20:50:17 mordred /kernel: uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Feb 17 20:50:17 mordred /kernel: uhub0: 2 ports with 2 removable, self powered Feb 17 20:50:17 mordred /kernel: BIOS Geometries: Feb 17 20:50:17 mordred /kernel: 0:0228fe3f 0..552=553 cylinders, 0..254=255 heads, 1..63=63 sectors Feb 17 20:50:17 mordred /kernel: 0 accounted for Feb 17 20:50:17 mordred /kernel: Device configuration finished. Feb 17 20:50:17 mordred /kernel: IP packet filtering initialized, divert disabled, rule-based forwarding disabled, logging limited to 100 packets/entry by default Feb 17 20:50:17 mordred /kernel: bpf: lo0 attached Feb 17 20:50:17 mordred /kernel: bpf: ds0 attached Feb 17 20:50:17 mordred /kernel: Waiting 8 seconds for SCSI devices to settle Feb 17 20:50:17 mordred /kernel: ncr0: restart (scsi reset). Feb 17 20:50:17 mordred /kernel: (probe4:ncr0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 Feb 17 20:50:17 mordred /kernel: (probe4:ncr0:0:4:0): ILLEGAL REQUEST asc:24,0 Feb 17 20:50:17 mordred /kernel: (probe4:ncr0:0:4:0): Invalid field in CDB Feb 17 20:50:17 mordred /kernel: (probe6:ncr0:0:6:0): INQUIRY. CDB: 12 1 80 0 ff 0 Feb 17 20:50:17 mordred /kernel: (probe6:ncr0:0:6:0): ILLEGAL REQUEST asc:24,0 Feb 17 20:50:17 mordred /kernel: (probe6:ncr0:0:6:0): Invalid field in CDB Feb 17 20:50:17 mordred /kernel: (probe3:ncr0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 Feb 17 20:50:17 mordred /kernel: (probe3:ncr0:0:3:0): ILLEGAL REQUEST asc:24,0 Feb 17 20:50:17 mordred /kernel: (probe3:ncr0:0:3:0): Invalid field in CDB sks:c8,1 Feb 17 20:50:17 mordred /kernel: (sa0:ncr0:0:3:0): found quirk entry 18 Feb 17 20:50:17 mordred /kernel: sa0 at ncr0 bus 0 target 3 lun 0 Feb 17 20:50:17 mordred /kernel: sa0: Removable Sequential Access SCSI-2 device Feb 17 20:50:17 mordred /kernel: sa0: 5.000MB/s transfers (5.000MHz, offset 8) Feb 17 20:50:17 mordred /kernel: pass0 at ncr0 bus 0 target 0 lun 0 Feb 17 20:50:17 mordred /kernel: pass0: Fixed Direct Access SCSI-2 device Feb 17 20:50:17 mordred /kernel: pass0: Serial Number 174712339400 Feb 17 20:50:17 mordred /kernel: pass0: 20.000MB/s transfers (20.000MHz, offset 16), Tagged Queueing Enabled Feb 17 20:50:17 mordred /kernel: pass1 at ncr0 bus 0 target 3 lun 0 Feb 17 20:50:17 mordred /kernel: pass1: Removable Sequential Access SCSI-2 device Feb 17 20:50:17 mordred /kernel: pass1: 5.000MB/s transfers (5.000MHz, offset 8) Feb 17 20:50:17 mordred /kernel: pass2 at ncr0 bus 0 target 4 lun 0 Feb 17 20:50:17 mordred /kernel: pass2: Removable CD-ROM SCSI-2 device Feb 17 20:50:17 mordred /kernel: pass2: 10.000MB/s transfers (10.000MHz, offset 15) Feb 17 20:50:17 mordred /kernel: pass3 at ncr0 bus 0 target 6 lun 0 Feb 17 20:50:17 mordred /kernel: pass3: Removable Direct Access SCSI-2 device Feb 17 20:50:17 mordred /kernel: pass3: 3.300MB/s transfers Feb 17 20:50:17 mordred /kernel: da0 at ncr0 bus 0 target 0 lun 0 Feb 17 20:50:17 mordred /kernel: da0: Fixed Direct Access SCSI-2 device Feb 17 20:50:17 mordred /kernel: da0: Serial Number 174712339400 Feb 17 20:50:17 mordred /kernel: da0: 20.000MB/s transfers (20.000MHz, offset 16), Tagged Queueing Enabled Feb 17 20:50:17 mordred /kernel: da0: 4345MB (8899737 512 byte sectors: 255H 63S/T 553C) Feb 17 20:50:17 mordred /kernel: Considering FFS root f/s. Feb 17 20:50:17 mordred /kernel: (cd0:ncr0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Feb 17 20:50:17 mordred /kernel: (cd0:ncr0:0:4:0): NOT READY asc:3a,0 Feb 17 20:50:17 mordred /kernel: (cd0:ncr0:0:4:0): Medium not present Feb 17 20:50:17 mordred /kernel: cd0 at ncr0 bus 0 target 4 lun 0 Feb 17 20:50:17 mordred /kernel: cd0: Removable CD-ROM SCSI-2 device Feb 17 20:50:17 mordred /kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 15) Feb 17 20:50:17 mordred /kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Feb 17 20:50:17 mordred /kernel: (da1:ncr0:0:6:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Feb 17 20:50:17 mordred /kernel: (da1:ncr0:0:6:0): NOT READY asc:3a,0 Feb 17 20:50:17 mordred /kernel: (da1:ncr0:0:6:0): Medium not present Feb 17 20:50:17 mordred /kernel: da1 at ncr0 bus 0 target 6 lun 0 Feb 17 20:50:18 mordred /kernel: da1: Removable Direct Access SCSI-2 device Feb 17 20:50:18 mordred /kernel: da1: 3.300MB/s transfers Feb 17 20:50:18 mordred /kernel: da1: Attempt to query device size failed: NOT READY, Medium not present Feb 17 20:50:18 mordred /kernel: da0s1: type 0x6, start 63, end = 2104514, size 2104452 : OK Feb 17 20:50:18 mordred /kernel: da0s2: type 0xa5, start 4192965, end = 8883944, size 4690980 : OK Feb 17 20:50:18 mordred /kernel: da0s3: type 0x5, start 2104515, end = 4192964, size 2088450 : OK Feb 17 20:50:18 mordred /kernel: da0s5: type 0x6, start 2104578, end = 4192964, size 2088387 : OK Feb 17 20:50:18 mordred /kernel: start_init: trying /sbin/init Feb 17 20:50:18 mordred /kernel: pn0: selecting MII, 100Mbps, half duplex Feb 17 20:50:18 mordred /kernel: pn0: selecting MII, 100Mbps, full duplex Feb 17 21:02:44 mordred /kernel: (sa0:ncr0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. Feb 17 21:02:44 mordred /kernel: (sa0:ncr0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message