From owner-freebsd-scsi Mon Jun 16 02:47:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA25376 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 02:47:03 -0700 (PDT) Received: from gibson.csa.de (uschmeli@gibson.csa.de [194.162.1.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA25371 for ; Mon, 16 Jun 1997 02:47:00 -0700 (PDT) Received: (from uschmeli@localhost) by gibson.csa.de (8.7.3/8.6.9) id KAA02565; Mon, 16 Jun 1997 10:46:10 +0200 Date: Mon, 16 Jun 1997 10:46:09 +0200 (MET DST) From: Uwe Schmeling To: freebsd-scsi@FreeBSD.ORG Subject: problems with syquest 270M and adaptec2940W Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! I've got a lot of problems with my Syquest 270MB connected to an adaptec2940W. Problably that is not a problem with the controller, but just in case... The cartridge seems to work proper for a while. After a couple of time I get errors like: Wanted at least 12345.. bytes got 12311.. Verifying the disc with adaptec firmware results in a couple of block substitutions. My vendor has exchanged the drive several times with no succes. Does anyone have an idea??? Uwe From owner-freebsd-scsi Mon Jun 16 08:47:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA12548 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 08:47:51 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA12539 for ; Mon, 16 Jun 1997 08:47:47 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id JAA16721; Mon, 16 Jun 1997 09:47:23 -0600 (MDT) Message-Id: <199706161547.JAA16721@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Uwe Schmeling cc: freebsd-scsi@FreeBSD.ORG Subject: Re: problems with syquest 270M and adaptec2940W In-reply-to: Your message of "Mon, 16 Jun 1997 10:46:09 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 1997 10:45:21 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Hi! >I've got a lot of problems with my Syquest 270MB connected to an >adaptec2940W. Problably that is not a problem with the controller, but >just in case... >The cartridge seems to work proper for a while. After a couple of time I >get errors like: Wanted at least 12345.. bytes got 12311.. Verifying >the disc with adaptec firmware results in a couple of block substitutions. >My vendor has exchanged the drive several times with no succes. Does >anyone have an idea??? That sounds like a Linux error message. If you're running Linux, you're asking this on the wrong list. >Uwe > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Mon Jun 16 17:58:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA12319 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 17:58:31 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA12297; Mon, 16 Jun 1997 17:58:19 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wdmYu-0002tH-00; Mon, 16 Jun 1997 17:55:56 -0700 Date: Mon, 16 Jun 1997 17:55:56 -0700 (PDT) From: Tom Samplonius To: Simon Shapiro cc: FreeBSD-hackers@freebsd.org, FreeBSD-SCSI@freebsd.org, "Justin T. Gibbs" Subject: Re: Announcement: New DPT RAID Controller Driver Available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Jun 1997, Simon Shapiro wrote: ... > The driver supports the PM3334{U,W,D} which is a PCI controller > sporting a 68030 processor, up to 3 SCSI ultra-wide-differential > busses. It is also available (I think) as narrow, non-ultra and > definitely single-ended. www.dpt.com says this controller has a 40mhz 68040 ?? ... > I would like you to help me in posting an announcement on the proper > FreeBSD lists and in checking it in. Anyone volunteered for the check-in yet? Has a FreeBSD 2.2.2-RELEASE boot disk been made with the DPT driver? I'm looking at a RAID solution for a freebsd server I'm building. Reliability is important (previous server had an uptime of 209 days before a flaky disk forced a reboot!). Basically, either I use the DPT controller, or a Mylex SCSI-to-SCSI controller connected to a standard PCI controller. The Mylex solution is kinda slow, but since it simply appears as a really big disk connected to your SCSI bus, it is almost guarrenteeed to work with FreeBSD. Anyone else using any kinda of RAID solution with freebsd now? Tom From owner-freebsd-scsi Mon Jun 16 18:20:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA13689 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 18:20:00 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA13677; Mon, 16 Jun 1997 18:19:55 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id TAA15968; Mon, 16 Jun 1997 19:19:42 -0600 (MDT) Message-Id: <199706170119.TAA15968@pluto.plutotech.com> To: Tom Samplonius cc: Simon Shapiro , FreeBSD-hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG, "Justin T. Gibbs" Subject: Re: Announcement: New DPT RAID Controller Driver Available In-reply-to: Your message of "Mon, 16 Jun 1997 17:55:56 PDT." Date: Mon, 16 Jun 1997 20:18:40 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Anyone volunteered for the check-in yet? Has a FreeBSD 2.2.2-RELEASE >boot disk been made with the DPT driver? I will be doing the final review and checkin into current and the 2.2 branch. As for a boot floppy, I'm sure that the releng22.FreeBSD.org will be able to accomodate you once the code is checked into the tree. >Tom -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Mon Jun 16 20:47:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA20481 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 20:47:39 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA20465 for ; Mon, 16 Jun 1997 20:47:34 -0700 (PDT) Received: (qmail 8999 invoked by uid 1000); 17 Jun 1997 03:47:41 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 16 Jun 1997 20:47:41 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: "Justin T. Gibbs" , FreeBSD-SCSI@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 17-Jun-97 you wrote: > > On Fri, 13 Jun 1997, Simon Shapiro wrote: > > ... > > The driver supports the PM3334{U,W,D} which is a PCI controller > > sporting a 68030 processor, up to 3 SCSI ultra-wide-differential > > busses. It is also available (I think) as narrow, non-ultra and > > definitely single-ended. > > www.dpt.com says this controller has a 40mhz 68040 ?? I know it is an abomination to have a Motorola processor in a computer dominated by the holy Intel processor. But, in case you can stomach the idea for a while, it actually works well. Those of you who insist that their computer is maintained purely Intel will be glad to know that (as I am told), the next generation will have an i960 instead. > ... > > I would like you to help me in posting an announcement on the proper > > FreeBSD lists and in checking it in. > > Anyone volunteered for the check-in yet? Has a FreeBSD 2.2.2-RELEASE > boot disk been made with the DPT driver? Yes, Justin Gibbs. He has been very helpful and now even insists that the driver complies with the BSD coding standards. I am indenting and indenting... :-) > I'm looking at a RAID solution for a freebsd server I'm building. > Reliability is important (previous server had an uptime of 209 days > before > a flaky disk forced a reboot!). Basically, either I use the DPT > controller, or a Mylex SCSI-to-SCSI controller connected to a standard > PCI > controller. The Mylex solution is kinda slow, but since it simply > appears > as a really big disk connected to your SCSI bus, it is almost > guarrenteeed > to work with FreeBSD. The DPT controller is doing the same thing. Since 1982. I think you will find the support, the configuration utilities (in native mode!), the perfomance and the complete integration (You will get a beep, console output, syslog, SNMP event and a can of diet soda whacked on the head every time: a. Bus Glitch b. Fan failure in the disk enclosure c. Power supply failure d. Disk failure. If you have a spare disk plugged in, you will also get aotomatic re-build of the array. Oh, did iI mention all power supplies are redundant and all disks are hot pluggable without any software intervention? >From us (the Atlas team), you also get multi initiator support, performance monitoring, Distributed Lock Manager and Distributed I/O. ... The option for 200+ days between boots will only come later. Right now we are delivering 14 days between boots (the anticipated frequency of enhancements posted for the driver). Simon From owner-freebsd-scsi Mon Jun 16 21:12:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA21434 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 21:12:15 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA21422; Mon, 16 Jun 1997 21:12:03 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wdpaP-0002yO-00; Mon, 16 Jun 1997 21:09:41 -0700 Date: Mon, 16 Jun 1997 21:09:41 -0700 (PDT) From: Tom Samplonius To: Simon Shapiro cc: "Justin T. Gibbs" , FreeBSD-SCSI@freebsd.org, FreeBSD-hackers@freebsd.org Subject: Re: Announcement: New DPT RAID Controller Driver Available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Jun 1997, Simon Shapiro wrote: > Hi Tom Samplonius; On 17-Jun-97 you wrote: > > > > On Fri, 13 Jun 1997, Simon Shapiro wrote: > > > > ... > > > The driver supports the PM3334{U,W,D} which is a PCI controller > > > sporting a 68030 processor, up to 3 SCSI ultra-wide-differential > > > busses. It is also available (I think) as narrow, non-ultra and > > > definitely single-ended. > > > > www.dpt.com says this controller has a 40mhz 68040 ?? > > I know it is an abomination to have a Motorola processor in a computer > dominated by the holy Intel processor. But, in case you can stomach the > idea for a while, it actually works well. Nope, the point was making was that you say the board has a 68030, while www.dtp.com says it is a 68040. The 68040 has quite a bit more kick than a 68030. That's a good thing. The 68000 series was always a good line. Plenty of integrated devices use them. > Those of you who insist that their computer is maintained purely Intel will > be glad to know that (as I am told), the next generation will have an i960 > instead. The i960 is not necessarily better. Especially, not the gutless 20mhz version. DPT might be better off with the 68060, as long as the price is right. ... > find the support, the configuration utilities (in native mode!), the > perfomance and the complete integration (You will get a beep, console > output, syslog, SNMP event and a can of diet soda whacked on the head every > time: ... > b. Fan failure in the disk enclosure > c. Power supply failure How does this work? Do you need to buy DPT enclosures for this? I don't have a DPT enclosure :(, and it doesn't seem that DPT makes rack mount enclosures. > If you have a spare disk plugged in, you will also get aotomatic re-build > of the array. Oh, did iI mention all power supplies are redundant and all > disks are hot pluggable without any software intervention? Again these all sound like features in the hardware module? I just use standard hot-swap modules (Dataport VI). FreeBSD gets mighty confused when you pull a drive while it is running, but the modules are mighty handle for any kind of field replacement. Are power supplies a big deal these days? I've never had a good PS2 supply die, but have had 4 drives die, all in last three years. Tom From owner-freebsd-scsi Mon Jun 16 22:59:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA25005 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 22:59:53 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA24992 for ; Mon, 16 Jun 1997 22:59:48 -0700 (PDT) Received: (qmail 17470 invoked by uid 1000); 17 Jun 1997 05:59:42 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 16 Jun 1997 22:59:42 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: FreeBSD-hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG, "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 17-Jun-97 you wrote: ... > Nope, the point was making was that you say the board has a 68030, > while > www.dtp.com says it is a 68040. The 68040 has quite a bit more kick than > a 68030. That's a good thing. This whole thing was atounge in cheek (foot in mouth?) and relates to some past employment experience... ... > The i960 is not necessarily better. Especially, not the gutless 20mhz > version. > > DPT might be better off with the 68060, as long as the price is right. Yes, but the logo on the chip is still wrong. Now take Mylex for example. Here is a quality, mature product that has the right high tech processor on board. Obviously the right choice. (Hint: Check out the Unholy union's benchmarks and performance braggings. Count how many DPT's are described and hoe many politically correct HBA's are listed. Now repeat once the i960 DPT's are out.) ... > How does this work? Do you need to buy DPT enclosures for this? You can. They are actually made by DEC Storage Works division. There is an upcoming SCSI standard for all this. The way it works is simple. They use several ``undefined/unused'' signals on the SCSI bus (cable) to transmit back and forth the necessary data. the DPT's simply comply with the DEC de-facto standard. We are using these enclosues in a HUGE project we are working on. It is amusing to pull a power supply, fan, disk or even a SCSI cable off while doing ls -alR or some nasty RDBMS access and listen to the siren, watch the red lights flash like mad and still have the disks operate as if nothing happened (well, a bit slower on RAID-5). > I don't have a DPT enclosure :(, and it doesn't seem that DPT makes > rack mount enclosures. Well, guess what? Call DPT, ask for Rene norton and tell her to sell you the same rack-mount she shipped me for evaluation. It is a rack mount that has 2 power supplies and 6 3.5" slots, or you can take a P/S out and put a 7th disk in. If you want, she can send you the proper terminator and instructions and then you can split the BUS into 2 busses. The only objection I hear here: a. The P/S are only available in A/C. We need -48VDC b. Both power and signal cables come off the front. this is great for service but our marketing people are complaining. We (Atlas Telecom, my employer) are building an AC-D/C version (using the DEC power supplies (3 in N+1), fans, SCSI backplane, etc. in our own box. It will have eight slots, be differential capable and allow bus daisy-chaining. It is done is cooperation with DPT and DEC so you should be able to enjoy the fruits of this effort. I have evaluated, tested and even participated in the design of more than one I/O subsystem in my short life. The StorageWorks solution is the best I have ever seen. not perfect, Just the BEST. Same goes for DPT. I have worked with them on several projects for over 15 years. Never dissapointed, except for minor things. ... > > disks are hot pluggable without any software intervention? > > Again these all sound like features in the hardware module? The hot-spare capability is a DPT feature. So it will work regardless of the disk cabinetry. Hot-plugging SCSI (especially single-ended is tricky. DPt helps out by allowing the use of 528 byte sectors. Coupled with ECC memory in the controller, they perform ECC across the SCSI bus. This cuts down (drastically) on the complaints at insert/removal. If your SCSI bus is not carefully done, you will still glitch it. I have tested some very reputable solutions and wit hthe exception of the StorageWorks, they all fail. The test is simple; Plug and unplug a drive once per minute and observe the system console. If you get tons of aborts (or the DPT beeps like mad and will not stop you have a bad disk bay. What happens is that either the power supply lines glitch and cause several drives to spin down (The DPT sees it as a multiple-drive fault and refuses to play the effected array), or it glitches some of the handshake signals and causes the bus to hang. The way DEC gets over that is with some fancy circuitry inside the disk module. the bus is totally passive (albeit interesting in design). > I just use standard hot-swap modules (Dataport VI). FreeBSD gets > mighty > confused when you pull a drive while it is running, but the modules are > mighty handle for any kind of field replacement. See above for possible causes. The DPT HBA handles all the recovery. You simply do not see any of it unless it gave up. If you WANT to address devices directly and eliminate the DPT handling (why?), there is a way to do it. The initial version of the FreeBSD driver does not support this ``feature''. > > Are power supplies a big deal these days? I've never had a good PS2 > supply die, but have had 4 drives die, all in last three years. Power supplies are funny business. We were having severe problems with a 250W PS/2 power supply handling insersions/removal of 4 drives in another disk bay. The StorageWorks does fine with one 150W P/S handling 8 drives. Has a lot to do with surge/spike/EMI handling on the OUTPUT side. Also, one may think that a $400 P/S may have some more design and quality put into it than a $35 one. Simon From owner-freebsd-scsi Tue Jun 17 11:31:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA28127 for freebsd-scsi-outgoing; Tue, 17 Jun 1997 11:31:55 -0700 (PDT) Received: from FNAL.FNAL.Gov (SYSTEM@fnal.fnal.gov [131.225.110.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28120 for ; Tue, 17 Jun 1997 11:31:52 -0700 (PDT) Received: from aduxb.fnal.gov ("port 39708"@aduxb.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IK6IT1SUUW000082@FNAL.FNAL.GOV> for freebsd-scsi@FreeBSD.ORG; Tue, 17 Jun 1997 13:31:49 -0600 Received: from localhost by aduxb.fnal.gov (5.x/SMI-SVR4) id AA12394; Tue, 17 Jun 1997 13:31:42 -0500 Date: Tue, 17 Jun 1997 13:31:41 -0500 (CDT) From: Kevin Yacoben Subject: Support for Buslogic's Flashpoint LT SCSI card To: freebsd-scsi@FreeBSD.ORG Reply-to: Kevin Yacoben Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Does anyone know the status of any support for the Buslogic's Flashpoint LT SCSI card??? I have read all of the past posting and have found little to indicate that there is any effort in the FreeBSD community to support these cards. What I did find were suggestions that ranged from upgrading to a supported card to going out and purchasing new supported hardware!!! Hmmmmm, is it just me or does this sound a bit like a Microsoft solution!! Well using that logic I guess I could go out and get an OS that supports these cards, like Linux, Solarisx86, SCO, OS2 or even (ugggggg) NT! Regards, Kevin Yacoben ----------------------------------------------------------------------------- Kevin Yacoben BD/Accelerator Controls Dept. Fermi National Accelerator Laboratory email: yacoben@fnal.gov PO Box 500, MS 347 PGP Key: finger yacoben@aduxb.fnal.gov Batavia, IL 60510-0500 From owner-freebsd-scsi Tue Jun 17 11:42:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29906 for freebsd-scsi-outgoing; Tue, 17 Jun 1997 11:42:34 -0700 (PDT) Received: from grunt.grondar.za (q4MuFFaya+VfVGjx6A78KdD517FIbkfO@grunt.grondar.za [196.7.18.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA29901 for ; Tue, 17 Jun 1997 11:42:27 -0700 (PDT) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by grunt.grondar.za (8.8.5/8.8.4) with ESMTP id UAA07380 for ; Tue, 17 Jun 1997 20:42:18 +0200 (SAT) Received: from greenpeace.grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.5/8.8.5) with ESMTP id UAA02967 for ; Tue, 17 Jun 1997 20:42:11 +0200 (SAT) Message-Id: <199706171842.UAA02967@greenpeace.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: scsi@freebsd.org Subject: CD problems in current? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Jun 1997 20:42:11 +0200 From: Mark Murray Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I have a really recent 3.0 system running on a Brand-New GA586DX Motherboard. This board includes an adaptec 7880 chip, and I have a NEC CDROM drive on this SCSI bus - it probes so: cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 There are no SCSI conflicts. I get the following errors when I try to play audio CDs on it: cd0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 cd0: abort message in message buffer cd0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x94 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 ahc0: Issued Channel A Bus Reset. 2 SCBs aborted Clearing bus reset Clearing 'in-reset' flag cd0: no longer in timeout cd0: UNIT ATTENTION asc:29,0 cd0: Power on, rese sd0: UNIT ATTENTION asc:29,0 sd0: Power on, reset, or bus device reset occurred , retries:3 t, or bus device reset occurred Notice that the errors (Quoted verbatim) are kinda screwed up. The CD plays, but will stop after a random interval (3secs - 3mins?) The drive works with no problems whatsoever if I mount a CD9660 cd on it. Any ideas? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-scsi Tue Jun 17 15:36:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12964 for freebsd-scsi-outgoing; Tue, 17 Jun 1997 15:36:09 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12933 for ; Tue, 17 Jun 1997 15:36:04 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.5) id PAA04056 for FreeBSd-SCSI@FreeBSD.org; Tue, 17 Jun 1997 15:36:08 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 17 Jun 1997 15:36:08 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSd-SCSI@FreeBSD.org Subject: RAID Configuration Notes Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all I am getting several mail messages in regards to the DPT driver and RAID configuration every day. Makes me happy and proud :-) If only I had a penny per request :-)) Anyway, I thought, at the risk of offending some of you with the trivial, to provide some notes on RAID configuration. Especially when it relates to DPT controllers. Bandwidth: * WRITEs are always slower than READS. The ``how much'' depends on the configuration. Details to follow. * A single SCSI-{II,III) disk can perform about 140 disk I/Os per second. This statememt is true for block_size < 8K. (Almost) Regardless of narrow/wide, ultra/fast, etc. The reason being that, according to SCSI specifications, all negotiations and handshakes happen in narrow, async 5MHz. Otherwise slow/old devices will surely hang the bus. * A ribbon-cable SCSI bus (parallel, not FCAL) can support up to 440 or so Tx/Sec. Yes, this means that for very high activity, much more than 4 drives per bus is a waste. * From my observations, FreeBSD does ALL block device I/O (including all filesystem operations) in 4K increments. Regardless of your specified ``block size''. Raw device (character) can be no larger than 64K. * RAID-0 gives you the best performance. The risk is that ANY device failure will take with it the entire array (data/functionality wise). * The MTBS of ANY RAID array is the MTBF of the worst device divided by the number of devices. * The declared MTBF for most modern 3.5" disk drives is around 800,000 hours. If you belive that, I own a bridge in London you should invest in. * RAID-1 gives OK READ performance and write performance similar to a single disk (DPT only, In-kernel RAID-1 writes at 0.5 the speed of a single-disk). The drawback is a mximum size of disk * 2 and 50% space utilization. Perfromance in degraded mode (a failed drive) is similar to a single disk (plus lots of noise (DPT)). * RAID-5 has capacity utilization of disk * (no_of_disks - 1). READ is as fast as a RAID-0 (in optimal state) and WRITE is slowest of the bunch. WRITE performance is about 10MB/Sec on the newest firmware (vs 15-20 for RAID-0. Performance: * With software interrupts disabled, 256 parallel dd reading and writing, with all error checking enabled we see: RAID | READ | WRITE ------+------+------ none | 3-4 | 3-4 0 | 18-20 | 15-18 1 | 10-15 | 8-12 5 | 15-20 | 5-10 RAID-0 is two drives, RAID-5 is 5 drives, across 2 busses (see below). Configuration: * The DPT defaults for cache copnfiguration are fine for general filesystem operation and quite useless for database work. They are easily tunable. They are useless because they allocate 30% of the cache to read-ahead buffers and use 128K stripes. * You can tune the cache as well as the cache that disk drives have on-board. * When you configure RAID arrays across busses on a DPT, stripe the array across. Example: Three busses, bus 0 has targets 1, 2, & 3, bus 1 has 4, 5, & 6 and bus 2 has 8, 9, & 10. When configuring a 5 wide RAID-5 array select the devices, in dptmgr) in this order: 0-1, 1-4, 2-8, 0-2, 1-5, and hot spare on 2-9. The next array will use 0-3, 1-6, and 2-10. This will force the DPT to ``jump'' busses when moving from stipe to stripe and result in HUGE boost in perfromance. * Hot spares apply to the entire controller, not just a particuloar array. In the above example, if you defined a RAID-0 array (which includes 0-3, 1-6, and 2-10), you (can define but) do NOT need another hyot spare. 2-9 will do for either. * To have RAID arrays span controllers and/or have the ability to exapand an existing array, you will have to either wait or integrate these changes yourself (messy). I hope this provides some background and helps. Simon From owner-freebsd-scsi Tue Jun 17 17:59:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19289 for freebsd-scsi-outgoing; Tue, 17 Jun 1997 17:59:59 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19281 for ; Tue, 17 Jun 1997 17:59:56 -0700 (PDT) Received: from pop.cybernex.net (root@mail.cybernex.net [204.141.116.15]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id RAA14936 for ; Tue, 17 Jun 1997 17:59:47 -0700 (PDT) Received: from skippy.grunfelder.com (dliv1-105.cybernex.net [207.198.213.105]) by pop.cybernex.net (Mail-clerk/Homer) with SMTP id VAA19490 for ; Tue, 17 Jun 1997 21:00:04 -0400 Message-Id: <3.0.2.32.19970617205847.007cae70@pop.cyberwar.com> X-Sender: wjgrun@pop.cyberwar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Tue, 17 Jun 1997 20:58:47 -0400 To: freebsd-scsi@freebsd.org From: Bill Grunfelder Subject: SCSI Parity Errors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have recently started getting scsi error messages on our news server which has caused it to lock up. The machine is not heavily hit -- no more than 5 connections at any given time. It is a P5-150, with 128MB RAM, 256MB swap, an Adaptec 3940UW SCSI card, and 4 4GB SCSI drives running FreeBSD 2.2.2. The drive reporting the errors is one of 2 Western Digital Enterprise drives (both are on Channel B of the 3940) which are ccd'd for the alt.binaries groups; /etc/ccd.conf: ccd0 128 none /dev/sd2e /dev/sd3e I do have the following compiled into the kernel, do I want them all? options AHC_TAGENABLE options AHC_ALLOW_MEMIO options AHC_SCBPAGING_ENABLE I have also run Adaptec's "Verify Disk" on the drive, but it reported no errors. BTW, the Enterprise drives are relatively new, 2-3 months. Can someone please give me some insight as to what could be causing these errors and how I can stop them? Thank you, Bill ----errors from /var/log/messages---- Jun 17 10:16:27 abc /kernel: sd3(ahc1:5:0): parity error during Data-In phase. Jun 17 10:16:27 abc /kernel: sd3(ahc1:5:0): ABORTED COMMAND csi:ff,ff,ff,ff asc:48,0 Jun 17 10:16:27 abc /kernel: sd3(ahc1:5:0): Initiator detected error message Jun 17 10:16:27 abc /kernel: sd3(ahc1:5:0): parity error during Message-In phase. Jun 17 10:16:37 abc /kernel: sd3(ahc1:5:0): SCB 0x1 - timed out in message in phase, SCSISIGI == 0x54 Jun 17 10:16:41 abc /kernel: sd2(ahc1:2:0): SCB 0x5 timedout while recovery in progress Jun 17 10:16:41 abc /kernel: sd3(ahc1:5:0): SCB 0x7 timedout while recovery in progress Jun 17 10:16:42 abc /kernel: sd3(ahc1:5:0): SCB 0x1 - timed out in message in phase, SCSISIGI == 0x54 Jun 17 10:16:42 abc /kernel: sd3(ahc1:5:0): abort message in message buffer Jun 17 10:16:42 abc /kernel: sd3(ahc1:5:0): SCB 0x1 - timed out in message in phase, SCSISIGI == 0x54 Jun 17 10:16:42 abc /kernel: ahc1: Issued Channel A Bus Reset. 3 SCBs aborted Jun 17 10:16:42 abc /kernel: sd3(ahc1:5:0): no longer in timeout Jun 17 10:16:42 abc /kernel: sd3(ahc1:5:0): UNIT ATTENTION csi:ff,ff,ff,ff asc:29,2 ....................................................................... Bill Grunfelder System Administrator wjgrun@cyberwar.com Cyber Warrior, Inc. http://www.cyberwar.com/~wjgrun/ (201) 703-1517 From owner-freebsd-scsi Tue Jun 17 19:52:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23909 for freebsd-scsi-outgoing; Tue, 17 Jun 1997 19:52:33 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (ala-ca17-24.ix.netcom.com [204.32.168.184]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23894 for ; Tue, 17 Jun 1997 19:52:29 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id TAA08303; Tue, 17 Jun 1997 19:52:12 -0700 (PDT) Date: Tue, 17 Jun 1997 19:52:12 -0700 (PDT) Message-Id: <199706180252.TAA08303@silvia.HIP.Berkeley.EDU> To: Shimon@i-connect.net CC: FreeBSd-SCSI@FreeBSD.org In-reply-to: (message from Simon Shapiro on Tue, 17 Jun 1997 15:36:08 -0700 (PDT)) Subject: Re: RAID Configuration Notes From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk * I am getting several mail messages in regards to the DPT driver and RAID * configuration every day. Makes me happy and proud :-) If only I had a * penny per request :-)) Glad to hear that. :) * Anyway, I thought, at the risk of offending some of you with the trivial, * to provide some notes on RAID configuration. Especially when it relates to * DPT controllers. Great summary. Let me point out some things that seems to me that contradicts our findings. First, our system. I have -stable and -current running on a few P6-200's at work. They have IBM 9GB U-W disks, although not all of them (like those on 14-disk strings) are running in 20MHz mode. I also have a P6-233 at home, with three drives (Quantam Atlas I & II, Micropolis 3243WT). They are all wide. All machines have Adaptec 2940UW's have 3940UW's. * * A single SCSI-{II,III) disk can perform about 140 disk I/Os per second. * This statememt is true for block_size < 8K. (Almost) Regardless of * narrow/wide, ultra/fast, etc. The reason being that, according to SCSI * specifications, all negotiations and handshakes happen in narrow, async * 5MHz. Otherwise slow/old devices will surely hang the bus. I'm not well versed about SCSI specs (I'll leave that for Justin or Stefan) but this is certainly not true. By doing small reads from a very small area on the raw disk device (like 1K out of 8K), I can get 220 IO/s from the IBM's at work, 100 from the Microp at home (don't they have a cache?!?), 1,500 from the A-I at home and 2,400 from the A-II at home. These are repeated reads with one process. No I'm not reading it from the disk cache, the reads are done from the raw device and I see the disk activity light stay on during the test. (Besides, I get 62,000 if I read from the block device. :) Of course, if you meant "I/Os from the disk surface" and not the cache, the limit is probably a hundred and something, but then the disk type certainly will make a huge difference (not the interface, but seek time and rotational speed). Also, you need to define what kind of I/O's you are talking about. A random read from the outer half of the disk surface will take less time than a random read from all over the disk, for instance. * * A ribbon-cable SCSI bus (parallel, not FCAL) can support up to 440 or so * Tx/Sec. Yes, this means that for very high activity, much more than 4 * drives per bus is a waste. This is not true. As I said above, I can get over 2,400 from a single disk on an 20MHz string. By running many in parallel I could go up to 2,660 with 14 disks (running at 10MHz). Here is how it grows: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 214 425 635 849 1066 1278 1489 1706 1910 2126 2319 2488 2591 2665 This is with the 1K/8K size given above. With a 1K read from all over the drive surface, I get a little over 1,800 with 14 disks (130/disk). These are with one process per disk. * * The declared MTBF for most modern 3.5" disk drives is around 800,000 * hours. If you belive that, I own a bridge in London you should invest * in. :) * * RAID-1 gives OK READ performance and write performance similar to a * single disk (DPT only, In-kernel RAID-1 writes at 0.5 the speed of a * single-disk). The drawback is a mximum size of disk * 2 and 50% space * utilization. Perfromance in degraded mode (a failed drive) is similar to * a single disk (plus lots of noise (DPT)). It's only if you are running RAID-1 with two disks. The write performance is typically a little less than a RAID-0 spanning half the drives. Of course, that depends on the number of disks (the data has to go over the SCSI bus twice, so if you have enough fast disks to saturate the bus, it will hit the ceiling faster). For instance, here with two 20MHz strings, I get 29MB/s for 4 disks striped and 20MB/s for 8 disks striped/mirrored. * * RAID-5 has capacity utilization of disk * (no_of_disks - 1). READ is as * fast as a RAID-0 (in optimal state) and WRITE is slowest of the bunch. * WRITE performance is about 10MB/Sec on the newest firmware (vs 15-20 for * RAID-0. That's very good compared to software parity. (Just another disincentive for implementing parity in ccd.... ;) * * Hot spares apply to the entire controller, not just a particuloar array. * In the above example, if you defined a RAID-0 array (which includes 0-3, * 1-6, and 2-10), you (can define but) do NOT need another hyot spare. * 2-9 will do for either. (I'm not sure what a hot spare will do for your RAID-0 array, but that's ok. :) * * To have RAID arrays span controllers and/or have the ability to exapand * an existing array, you will have to either wait or integrate these * changes yourself (messy). How about having two controllers on two PCs share the same string? That will guard against PC and adapter failures. We are planning to do this with our system. The Adaptecs are happy as long as you don't try to boot both machines at the same time with the boot disks on the shared string (if you have a system disk on an unshared string and disable the BIOS, it will be ok). Do the DPTs allow for the SCSI ID's to be changed? Satoshi From owner-freebsd-scsi Wed Jun 18 00:23:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA03296 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 00:23:05 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA03290 for ; Wed, 18 Jun 1997 00:23:01 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.5) id AAA28113; Wed, 18 Jun 1997 00:23:01 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706180252.TAA08303@silvia.HIP.Berkeley.EDU> Date: Wed, 18 Jun 1997 00:23:01 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Satoshi Asami) Subject: Re: RAID Configuration Notes Cc: FreeBSd-SCSI@FreeBSD.org Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi Satoshi Asami; On 18-Jun-97 you wrote: ... > * * A single SCSI-{II,III) disk can perform about 140 disk I/Os per > second. > * This statememt is true for block_size < 8K. (Almost) Regardless of > * narrow/wide, ultra/fast, etc. The reason being that, according to > SCSI > * specifications, all negotiations and handshakes happen in narrow, > async > * 5MHz. Otherwise slow/old devices will surely hang the bus. > > I'm not well versed about SCSI specs (I'll leave that for Justin or > Stefan) but this is certainly not true. By doing small reads from a > very small area on the raw disk device (like 1K out of 8K), I can get > 220 IO/s from the IBM's at work, 100 from the Microp at home (don't > they have a cache?!?), 1,500 from the A-I at home and 2,400 from the > A-II at home. These are repeated reads with one process. Caching, maybe even at the HBA level. My numbers talk about RANDOM seeks. Check the SCSI specs, it takes almost a full ms to get a command posted on a BUSY bus. Sometimes more. If the drive disconnects, that takes time. When it reconnects it takes time. BTW, I will be delighted to find that SCSI disks can do 1,500 I/Os per second. > No I'm not reading it from the disk cache, the reads are done from the > raw device and I see the disk activity light stay on during the test. > (Besides, I get 62,000 if I read from the block device. :) > > Of course, if you meant "I/Os from the disk surface" and not the > cache, the limit is probably a hundred and something, but then the > disk type certainly will make a huge difference (not the interface, > but seek time and rotational speed). Also, you need to define what > kind of I/O's you are talking about. A random read from the outer > half of the disk surface will take less time than a random read from > all over the disk, for instance. Random read and writes, from all over the disk. My tests are geared towards database work, and particular application at that. We assume the worst conditions as we have to guarantee delivery on random access. I ran these tests on Slowlaris 2.51, Linux 2.0.27 (or whatever it was that week) and FreeBSD. Linux had DPT, FreeBSd had AHA-2940UW, Slowlaris had whatever (I think it is a Qlogic chip). They were all within few percentage points, except that the SPARC had totally FLAT response curve up ti 4K. We could not test larger blocks as it hangs the calling process if you do lockf() on 8K+. > * * A ribbon-cable SCSI bus (parallel, not FCAL) can support up to 440 > or so > * Tx/Sec. Yes, this means that for very high activity, much more > than 4 > * drives per bus is a waste. > > This is not true. As I said above, I can get over 2,400 from a single > disk on an 20MHz string. By running many in parallel I could go up to > 2,660 with 14 disks (running at 10MHz). Here is how it grows: > > 1 2 3 4 5 6 7 8 9 10 11 12 13 14 > 214 425 635 849 1066 1278 1489 1706 1910 2126 2319 2488 2591 2665 > > This is with the 1K/8K size given above. With a 1K read from all over > the drive surface, I get a little over 1,800 with 14 disks > (130/disk). These are with one process per disk. These are very interesting numbers. They are better than the industry recognizes for FCAL! According to your numbers you can sustain almost 15MB/Sec per single bus (4k transfers), which is about the theoretical limit. Maybe with high cache, maybe the drive, upon cache hit does not disconnect (this will double the throughput), maybe, maybe :-) ... > It's only if you are running RAID-1 with two disks. The write > performance is typically a little less than a RAID-0 spanning half the > drives. Of course, that depends on the number of disks (the data has > to go over the SCSI bus twice, so if you have enough fast disks to > saturate the bus, it will hit the ceiling faster). For instance, here > with two 20MHz strings, I get 29MB/s for 4 disks striped and 20MB/s > for 8 disks striped/mirrored. Compound arrays are definitely useful. BTW, how do you measure the performance? RAID-1, by definition is two drives. People will create compound arrays and call them RAID-1. They are not. I heared them being called RAID-10! ... > That's very good compared to software parity. (Just another > disincentive for implementing parity in ccd.... ;) Ccd has two important features for our typical, average uer: A. It works on ANY vlock device B. CHEAP When considerint the DPT (vs. other solutions) I placed high value on administrative ability. The DPT will recover and repair an array on-line and automatically. Virtually all others will not. The environment control (P/S, fans, temperature, etc.) are also critical when your system is literally on a mountaintop hundreds of miles away. CCD does not have these features yet :-) ... > (I'm not sure what a hot spare will do for your RAID-0 array, but > that's ok. :) Cost money :-) Hot spares are for RAID-{1,5}. As tempting as it may be, RAID-0 is useless for critical applications. One disk decides to hickup and many gigabytes get a stroke. I use it for /usr/obj, /var/tmp, etc. /usr/src is on RAID-5. /RCS, /CVS, etc are on RAID-1. ... > How about having two controllers on two PCs share the same string? > That will guard against PC and adapter failures. We are planning to > do this with our system. The Adaptecs are happy as long as you don't > try to boot both machines at the same time with the boot disks on the > shared string (if you have a system disk on an unshared string and > disable the BIOS, it will be ok). Do the DPTs allow for the SCSI ID's > to be changed? This is what the DIO (phase I) does. It allows several hosts to share a disk array. Locking is at arbitrary granuality. you can lock at a sector level, page level, RDBMS block level, partition, disk, whatever. It uses the DLM which allows a superset of semaphores/locks to span Unix instances. Phase II will add the ability to do I/O on remote machines (which do not share a device). Yes, the DPT's allow you to change target ID, on the fly too. The driver does NOT allow dynamic re-assignment at this time. Simon From owner-freebsd-scsi Wed Jun 18 08:13:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21747 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 08:13:55 -0700 (PDT) Received: from tor-adm1.nbc.netcom.ca (taob@tor-adm1.nbc.netcom.ca [207.181.89.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21741; Wed, 18 Jun 1997 08:13:52 -0700 (PDT) Received: from localhost (taob@localhost) by tor-adm1.nbc.netcom.ca (8.8.5/8.8.5) with SMTP id LAA18204; Wed, 18 Jun 1997 11:13:05 -0400 (EDT) Date: Wed, 18 Jun 1997 11:13:05 -0400 (EDT) From: Brian Tao To: Simon Shapiro cc: FREEBSD-HACKERS , FREEBSD-SCSI Subject: Re: Announcement: New DPT RAID Controller Driver Available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Jun 1997, Simon Shapiro wrote: > > I have evaluated, tested and even participated in the design of more > than one I/O subsystem in my short life. The StorageWorks solution > is the best I have ever seen. not perfect, Just the BEST. I should add that NetApp also uses the DEC StorageWorks shelves and canisters for their 2GB and 4GB configurations, and if it's good enough for them, it's good enough for me. ;-) Mounting drives inside the canisters is a little tricky at first, but you get the hang of it pretty quickly. The ones we have are plastic, so I imagine the heat dissipation isn't the best. Netapp went with a Eurologics product (metal extruded cases) for their 9GB shelves. -- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't" From owner-freebsd-scsi Wed Jun 18 10:00:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27530 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 10:00:21 -0700 (PDT) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27525; Wed, 18 Jun 1997 10:00:18 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.5/8.8.5) with SMTP id NAA02008; Wed, 18 Jun 1997 13:00:11 -0400 (EDT) Date: Wed, 18 Jun 1997 13:00:11 -0400 (EDT) From: "Matthew N. Dodd" To: Brian Tao cc: FREEBSD-HACKERS , FREEBSD-SCSI Subject: Re: Announcement: New DPT RAID Controller Driver Available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Jun 1997, Brian Tao wrote: > I should add that NetApp also uses the DEC StorageWorks shelves > and canisters for their 2GB and 4GB configurations, and if it's good > enough for them, it's good enough for me. ;-) Mounting drives FYI NetApp went with the DSW enclosures because DEC had a big surplus of them and gave NetApp a good deal. I've not heard too many good things about DSW. Of course there aren't too many other enclosures that do the same stuff a DSW does. Have a good one. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-scsi Wed Jun 18 11:28:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02025 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 11:28:46 -0700 (PDT) Received: from sabre.goldsword.com (sabre.goldsword.com [199.170.202.32]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01962; Wed, 18 Jun 1997 11:28:09 -0700 (PDT) Received: (from jfarmer@localhost) by sabre.goldsword.com (8.7.5/8.7.3) id NAA07058; Wed, 18 Jun 1997 13:57:56 -0400 (EDT) Date: Wed, 18 Jun 1997 13:57:56 -0400 (EDT) From: "John T. Farmer" Message-Id: <199706181757.NAA07058@sabre.goldsword.com> To: yacoben@FNAL.GOV Subject: Re: Support for Buslogic's Flashpoint LT SCSI card Cc: freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, jfarmer@goldsword.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Jun 1997 13:26:00 -0500 (CDT) Kevin Yacoben said: > >Does anyone know the status of any support for the Buslogic's >Flashpoint LT SCSI card??? >I have read all of the past posting and have found little >to indicate that there is any effort in the FreeBSD community to support >these cards. What I did find were suggestions that ranged from upgrading >to a supported card to going out and purchasing new supported hardware!!! >Hmmmmm, is it just me or does this sound a bit like a Microsoft >solution!! Well using that logic I guess I could go out and get an OS that >supports these cards, like Linux, Solarisx86, SCO, OS2 or even (ugggggg) >NT! Kevin, I can't answer your question, but I would like to point out that there are reasons why certain pieces of hardware don't have drivers for them. It's simply the fact that FreeBSD is a _volunteer_ effort. Outside of a _very_ few devices, drivers are created because someone volunteers to write and has the device in question. If a device isn't supported, it's usually because the _volunteers_ who write device drivers either 1) don't have the device in question, 2) someone who has the card can't/won't write one, 3) no one has loaned one to a driver writer, 4) the manufactuer refues to let technical data out unless you're M$ or Sun$oft, or finally 5) nobody has found the time to do it. By the by, the Micro$oft solution would be to get the manufacturer to let M$ have first scoop on information about the device... John (Who would volunteer, but can't find any free time now...) ------------------------------------------------------------------------- John T. Farmer Proprietor, GoldSword Systems jfarmer@goldsword.com Public Internet Access in East Tennessee dial-in (423)470-9953 for info, e-mail to info@goldsword.com Network Design, Internet Services & Servers, Consulting From owner-freebsd-scsi Wed Jun 18 12:26:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05261 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 12:26:31 -0700 (PDT) Received: from protheus.ravel.ufrj.br (rodolfo@gw-cos1.ravel.ufrj.br [146.164.32.52]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05254 for ; Wed, 18 Jun 1997 12:26:28 -0700 (PDT) Received: (from rodolfo@localhost) by protheus.ravel.ufrj.br (8.8.3/8.6.9) id QAA25090 for freebsd-scsi@freebsd.org; Wed, 18 Jun 1997 16:26:20 -0300 (EST) From: Rodolfo Heitor Gevaerd de Faria Message-Id: <199706181926.QAA25090@protheus.ravel.ufrj.br> Subject: Support for AdvanSys Chipsets To: freebsd-scsi@freebsd.org Date: Wed, 18 Jun 1997 16:26:20 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Is there any drivers working for AdvanSys chipsets (ASC1200 especifically) ? at their website (advansys.com) I found the following: ftp://ftp.advansys.com/pub/freebsd/freebsd.txt > >Last Updated: 1/16/97 > >AdvanSys has provided assistance to FreeBSD to write a driver >for AdvanSys adapters by providing adapters and answering questions. >Also the Linux driver is distributed under terms which allow it to >be used to write a FreeBSD driver. > >The person responsible for the FreeBSD driver is Justin T. Gibbs >. Please contact Justin for specific >with regard to status and availability of the FreeBSD AdvanSys >driver. The last we heard Justin had completed ISA support and >was nearing completion of PCI support. Any news about this ? Rodolfo H G Faria From owner-freebsd-scsi Wed Jun 18 18:15:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA23895 for freebsd-scsi-outgoing; Wed, 18 Jun 1997 18:15:29 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA23886; Wed, 18 Jun 1997 18:15:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id SAA14684; Wed, 18 Jun 1997 18:17:16 -0700 (PDT) Message-Id: <199706190117.SAA14684@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: "John T. Farmer" cc: yacoben@FNAL.GOV, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, jfarmer@goldsword.com Subject: Re: Support for Buslogic's Flashpoint LT SCSI card In-reply-to: Your message of "Wed, 18 Jun 1997 13:57:56 EDT." <199706181757.NAA07058@sabre.goldsword.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 18 Jun 1997 18:17:16 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >or finally 5) nobody has found the time to do it. Just so people know, the reason in this case is #5 above. Mylex has in fact been very interested in doing whatever they can to support the development of a FreeBSD device driver for their Flashpoint products (including providing the hardware). The problem is that noone has yet had the time to write a device driver for them. It's something that will happen eventually - hopefully before the end of the year. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-scsi Thu Jun 19 16:10:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25705 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 16:10:14 -0700 (PDT) Received: from brie.direct.ca (brie.direct.ca [199.60.229.8]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25682; Thu, 19 Jun 1997 16:10:04 -0700 (PDT) Received: from localhost (jaredp@localhost) by brie.direct.ca (8.8.3/8.8.0) with SMTP id QAA13004; Thu, 19 Jun 1997 16:09:57 -0700 (PDT) X-Authentication-Warning: brie.direct.ca: jaredp owned process doing -bs Date: Thu, 19 Jun 1997 16:09:56 -0700 (PDT) From: Jared Proudfoot To: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org Subject: SCSI Problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I've been looking through the mailing list archives and I've noticed that a lot of people have been experiencing the damn SCSI problems that I have been having recently. I'm currently running FreeBSD 2.2.1-RELEASE on a P166 with 128MB RAM, an Adaptec 2940 UW controller, 2 Quantam Atlases, 1 Quantam Grand Prix and an IDE Quantum Sirocco. The machine will lock up periodically, giving SCSI drive errors. Here's the errors I've been getting, the error as reported in /var/log/messages and a copy of my dmesg output: sd1(ahc0:5:0): UNIT ATTENTION asc:29,1 retires: 4 SCB: 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR == 0x4 Queueing an Abort SCB Queueing an Abort SCB no longer in timeout messages: ------------------------------------------------------------------------- Jun 14 06:35:22 havarti /kernel: sd1(ahc0:5:0): SCB 0x0 - timed out while idle, Jun 14 06:35:22 havarti /kernel: SEQADDR == 0x8 Jun 14 06:35:22 havarti /kernel: sd1(ahc0:5:0): Queueing an Abort SCB ------------------------------------------------------------------------- dmesg: ------------------------------------------------------------------------- Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved FreeBSD 2.2.1-RELEASE #0: Fri May 16 22:32:31 PDT 1997 jaredp@havarti:/usr/src/sys/compile/HAVARTI CPU: Pentium (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 134217728 (131072K bytes) avail memory = 127184896 (124204K bytes) Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 ahc0 rev 1 int a irq 12 on pci0:10 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs (ahc0:3:0): "QUANTUM XP34550S LXY1" type 0 fixed SCSI 2 sd0(ahc0:3:0): Direct-Access 4341MB (8890760 512 byte sectors) sd0(ahc0:3:0): with 5899 cyls, 10 heads, and an average 150 sectors/track (ahc0:5:0): "QUANTUM XP34550S LXQ1" type 0 fixed SCSI 2 sd1(ahc0:5:0): Direct-Access 4341MB (8890760 512 byte sectors) sd1(ahc0:5:0): with 5899 cyls, 10 heads, and an average 150 sectors/track (ahc0:6:0): "QUANTUM XP34301 1071" type 0 fixed SCSI 2 sd2(ahc0:6:0): Direct-Access 4106MB (8410200 512 byte sectors) sd2(ahc0:6:0): with 4076 cyls, 20 heads, and an average 103 sectors/track vga0 rev 84 int a irq 11 on pci0:12 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1628MB (3335472 sectors), 3309 cyls, 16 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: utp[*UTP*] address 00:a0:24:39:7e:bb npx0 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers --------------------------------------------------------------------------- I've seen lots of discussion, but not solution on the lists. Has one been found? Any help would be appreciated. Thanks in advance, Jared Proudfoot PS - Please cc: me on this discussion. I'm not currently subscribed the the mailing lists. Thanks. -- Jared Proudfoot jaredp@direct.ca Systems Engineer, Canada Internet Direct Inc. http://www.direct.ca/ Finger jproudfo@footprints.net for PGP public key. From owner-freebsd-scsi Thu Jun 19 16:46:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA27610 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 16:46:57 -0700 (PDT) Received: from sand.sentex.ca (sand.sentex.ca [206.222.77.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA27583; Thu, 19 Jun 1997 16:46:48 -0700 (PDT) Received: from gravel (gravel.sentex.ca [205.211.165.210]) by sand.sentex.ca (8.8.5/8.8.3) with SMTP id TAA04913; Thu, 19 Jun 1997 19:57:23 -0400 (EDT) Message-Id: <3.0.2.32.19970619194829.00c21440@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 19 Jun 1997 19:48:29 -0400 To: Jared Proudfoot , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG From: Mike Tancsa Subject: Re: SCSI Problems In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 04:09 PM 6/19/97 -0700, Jared Proudfoot wrote: >I'm currently running FreeBSD 2.2.1-RELEASE on a P166 with 128MB RAM, an >Adaptec 2940 UW controller, 2 Quantam Atlases, 1 Quantam Grand Prix and an >IDE Quantum Sirocco. Two things I recall a) There has been fixes to the code since 2.2.1-RELEASE b) I also recall specific discussion of Quantum drives and firmware revs... Dunno if its your modle or not thats effected. But I would be concerned far more with a) than b) Have a look at http://www.freebsd.org/handbook/handbook228.html#479 and specifically at http://www.freebsd.org/handbook/handbook240.html#498 for how to use CVSUP to get the latest version of FreeBSD... Also, you may want to check out www.dejanews.com. They archive comp.unix.bsd.free.* and the mailling list in the newsgroup muc.lists.freebsd* ---Mike ********************************************************************** Mike Tancsa (mike@sentex.net) * To do is to be -- Nietzsche Sentex Communications Corp, * To be is to do -- Sartre Cambridge, Ontario * Do be do be do -- Sinatra (http://www.sentex.net/~mdtancsa) * From owner-freebsd-scsi Thu Jun 19 17:50:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA00545 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 17:50:58 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA00540; Thu, 19 Jun 1997 17:50:55 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0werrr-0003js-00; Thu, 19 Jun 1997 17:47:59 -0700 Date: Thu, 19 Jun 1997 17:47:59 -0700 (PDT) From: Tom Samplonius To: Jared Proudfoot cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SCSI Problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Jun 1997, Jared Proudfoot wrote: > > Greetings, > > I've been looking through the mailing list archives and I've noticed that > a lot of people have been experiencing the damn SCSI problems that I have > been having recently. > > I'm currently running FreeBSD 2.2.1-RELEASE on a P166 with 128MB RAM, an > Adaptec 2940 UW controller, 2 Quantam Atlases, 1 Quantam Grand Prix and an > IDE Quantum Sirocco. You should probably upgrade to 2.2.2 The errors, look really familar. Is sd1 the Grand Prix? Is it always sd1? I found the Grand Prix to be very unreliable. So if sd1 is the Grand Prix, and sd1 is always the cause, rip it out. Also, 2.2.2-stable is better able to handle recovery. The drive still times out, and the system will freeze for a couple for seconds, and continue on. Tom From owner-freebsd-scsi Thu Jun 19 18:01:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA00978 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 18:01:28 -0700 (PDT) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA00965 for ; Thu, 19 Jun 1997 18:01:23 -0700 (PDT) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.5/8.7.3) id SAA01078; Thu, 19 Jun 1997 18:01:22 -0700 (PDT) Date: Thu, 19 Jun 1997 18:01:22 -0700 (PDT) Message-Id: <199706200101.SAA01078@vader.cs.berkeley.edu> To: jaredp@direct.ca CC: freebsd-scsi@FreeBSD.ORG In-reply-to: (message from Jared Proudfoot on Thu, 19 Jun 1997 16:09:56 -0700 (PDT)) Subject: Re: SCSI Problems From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * Greetings, Hi. Please don't cross-post a question to more than one list. I only got one but I'm sure people who got all three are quite pissed and won't reply even if they know what to do. :) * FreeBSD 2.2.1-RELEASE #0: Fri May 16 22:32:31 PDT 1997 You should upgrade this to at least 2.2.2R. Many ahc bugs have been fixed by Justin Gibbs. * (ahc0:3:0): "QUANTUM XP34550S LXY1" type 0 fixed SCSI 2 * (ahc0:5:0): "QUANTUM XP34550S LXQ1" type 0 fixed SCSI 2 There has been a bug in earlier versions of the firmware. I got my upgrade (to LXY4) from ftp.quantum.com. At your own risk, of course. * (ahc0:6:0): "QUANTUM XP34301 1071" type 0 fixed SCSI 2 Don't know about Grand Prixes. Never touched one all my life. Satoshi From owner-freebsd-scsi Thu Jun 19 18:46:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA02737 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 18:46:02 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02716; Thu, 19 Jun 1997 18:45:57 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id TAA01010; Thu, 19 Jun 1997 19:45:46 -0600 (MDT) Message-Id: <199706200145.TAA01010@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jared Proudfoot cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI Problems In-reply-to: Your message of "Thu, 19 Jun 1997 16:09:56 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 1997 20:44:15 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >The machine will lock up periodically, giving SCSI drive errors. Here's >the errors I've been getting, the error as reported in /var/log/messages >and a copy of my dmesg output: > >sd1(ahc0:5:0): UNIT ATTENTION asc:29,1 retires: 4 >SCB: 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 >From the sense table of the new SCSI code: /* DTLPWRSOMCAE */{0x29, 0x01, "Power on occurred" } It looks like you either have a bad power supply or the connector to your drive is worn or loose. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jun 19 19:09:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA03749 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 19:09:52 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA03728; Thu, 19 Jun 1997 19:09:39 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.5) id TAA01977; Thu, 19 Jun 1997 19:09:38 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 19 Jun 1997 19:09:38 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Brian Tao Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: FREEBSD-SCSI , FREEBSD-HACKERS Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Brian Tao; On 18-Jun-97 you wrote: > On Mon, 16 Jun 1997, Simon Shapiro wrote: > > > > I have evaluated, tested and even participated in the design of more > > than one I/O subsystem in my short life. The StorageWorks solution > > is the best I have ever seen. not perfect, Just the BEST. > > I should add that NetApp also uses the DEC StorageWorks shelves > and canisters for their 2GB and 4GB configurations, and if it's good > enough for them, it's good enough for me. ;-) Mounting drives > inside the canisters is a little tricky at first, but you get the hang > of it pretty quickly. The ones we have are plastic, so I imagine the > heat dissipation isn't the best. Netapp went with a Eurologics > product (metal extruded cases) for their 9GB shelves. You know, the canister problem is an interesting one. I was once involved in a project where we build a database server with 3,000 (no typo) drives, so canisters and packing density were somewhat important :-). An excellent mechanical engineer designed a wonderful metal system (both canisters and carriers). We had up to 30% perofrmance loss on random seeks with system. It baffled anyone until another engineer decided to test the drives on his desk, outside the box, outside the carriers - Yes, the performance was back. Turns out soft errors were masked and the rigid but ringing-resonating nature of steel and the high packing density caused drives to resonate the cabinets and cause miseeks. For other, unrelated problems, we decided to use the DEC canisters. Smug as a cat with a bird in mouth we loaded 200 drives into a cabinet, smirking and making snide remarks about the silly plastic carriers - No data loss, no perfromance loss. Asking the DEC engineers about why they choose platic, they just smiled and shrugged... Simon BTW, the little flex-circuit between the drive and the canister plug makes you think too. Simon From owner-freebsd-scsi Thu Jun 19 20:04:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA06007 for freebsd-scsi-outgoing; Thu, 19 Jun 1997 20:04:54 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05987; Thu, 19 Jun 1997 20:04:50 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA02058; Thu, 19 Jun 1997 21:04:29 -0600 (MDT) Message-Id: <199706200304.VAA02058@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Simon Shapiro cc: Brian Tao , FREEBSD-SCSI , FREEBSD-HACKERS Subject: Re: Announcement: New DPT RAID Controller Driver Available In-reply-to: Your message of "Thu, 19 Jun 1997 19:09:38 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 1997 22:02:57 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >An excellent mechanical engineer designed a wonderful metal system (both >canisters and carriers). We had up to 30% perofrmance loss on random >seeks with system. It baffled anyone until another engineer decided to >test the drives on his desk, outside the box, outside the carriers - >Yes, the performance was back. Turns out soft errors were masked and >the rigid but ringing-resonating nature of steel and the high packing >density caused drives to resonate the cabinets and cause miseeks. Pluto's drive sled design uses a very simple and cheap suspension design to deal with this very problem. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jun 20 01:39:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA21083 for freebsd-scsi-outgoing; Fri, 20 Jun 1997 01:39:02 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA21077 for ; Fri, 20 Jun 1997 01:38:58 -0700 (PDT) Received: (qmail 7894 invoked by uid 1000); 20 Jun 1997 08:39:05 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706200304.VAA02058@pluto.plutotech.com> Date: Fri, 20 Jun 1997 01:39:04 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: FREEBSD-HACKERS , FREEBSD-SCSI , Brian Tao Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi "Justin T. Gibbs"; On 20-Jun-97 you wrote: > >An excellent mechanical engineer designed a wonderful metal system (both > >canisters and carriers). We had up to 30% perofrmance loss on random > >seeks with system. It baffled anyone until another engineer decided to > >test the drives on his desk, outside the box, outside the carriers - > >Yes, the performance was back. Turns out soft errors were masked and > >the rigid but ringing-resonating nature of steel and the high packing > >density caused drives to resonate the cabinets and cause miseeks. > > Pluto's drive sled design uses a very simple and cheap suspension design > to deal with this very problem. Proof that this problem is not unique. There are several ways of dealing with it. Worse was hanging devices on... springs! Simon From owner-freebsd-scsi Fri Jun 20 02:27:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA23633 for freebsd-scsi-outgoing; Fri, 20 Jun 1997 02:27:53 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA23627; Fri, 20 Jun 1997 02:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id CAA12213; Fri, 20 Jun 1997 02:29:50 -0700 (PDT) Message-Id: <199706200929.CAA12213@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro cc: "Justin T. Gibbs" , FREEBSD-HACKERS , FREEBSD-SCSI , Brian Tao Subject: Re: Announcement: New DPT RAID Controller Driver Available In-reply-to: Your message of "Fri, 20 Jun 1997 01:39:04 PDT." From: David Greenman Reply-To: dg@root.com Date: Fri, 20 Jun 1997 02:29:50 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Hi "Justin T. Gibbs"; On 20-Jun-97 you wrote: >> >An excellent mechanical engineer designed a wonderful metal system (both >> >canisters and carriers). We had up to 30% perofrmance loss on random >> >seeks with system. It baffled anyone until another engineer decided to >> >test the drives on his desk, outside the box, outside the carriers - >> >Yes, the performance was back. Turns out soft errors were masked and >> >the rigid but ringing-resonating nature of steel and the high packing >> >density caused drives to resonate the cabinets and cause miseeks. >> >> Pluto's drive sled design uses a very simple and cheap suspension design >> to deal with this very problem. > >Proof that this problem is not unique. There are several ways of dealing >with it. Worse was hanging devices on... springs! Before everyone throws out their metal drive enclosures in favor of plastic ones, let me say something about my experiance. Wcarchive used to lose a couple of drives a month back when they were housed in plastic enclosures. I noticed that the drives in that box ran hot, and I finally got tired of flying down to the Bay area so often to deal with it and convinced WC to replace the cabinet/enclosures with an all-steel one made by Kingston. This was about a year ago. Result: The drives run almost cold now and we haven't had a single failure in that array since. All of our drives have fairly well balanced spindles and don't vibrate all that much, and I've never seen a reported seek failure or noticed any slowness. In my opinion, the all- metal enclosure is a significant factor in the cooling of the drives and these days I wouldn't consider anything else. YMMV. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-scsi Fri Jun 20 03:37:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA26217 for freebsd-scsi-outgoing; Fri, 20 Jun 1997 03:37:30 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA26212; Fri, 20 Jun 1997 03:37:27 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id DAA27550; Fri, 20 Jun 1997 03:37:07 -0700 (PDT) To: dg@root.com cc: Simon Shapiro , "Justin T. Gibbs" , FREEBSD-HACKERS , FREEBSD-SCSI , Brian Tao Subject: Re: Announcement: New DPT RAID Controller Driver Available In-reply-to: Your message of "Fri, 20 Jun 1997 02:29:50 PDT." <199706200929.CAA12213@implode.root.com> Date: Fri, 20 Jun 1997 03:37:07 -0700 Message-ID: <27545.866803027@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > haven't had a single failure in that array since. All of our drives have > fairly well balanced spindles and don't vibrate all that much, and I've never > seen a reported seek failure or noticed any slowness. In my opinion, the all- Erm, I think the difference we're probably seeing with wcarchive is the fact that each drive bay doesn't hold more than 8 drives (most holding far fewer) and is independantly bolted to the rack. That probably provides pretty good vibration isolation, but undoubtedly also at a drive-to-housing cost ratio which would be unacceptable to the truly big RAID builder. I would also be suspicious of the cooling properties of a plastic drive enclosure (it seems like packing it in a mini-Igloo ice chest would be no worse to me ;-), but given a much different racking scenario, say 80 drives in a single free-standing rack, I'm more than willing to believe that vibration becomes a significant problem requiring creative solutions. If it were my fingers signing the P.O. on a true drive-array-from-hell, I'd probably favor the vendor providing the best combination of all-metal construction, air-flow, power supply quality and vibration isolation. Unless, of course, they had something like the AMES wind tunnel providing forced airflow past the drives, then I suppose the plastic sled construction wouldn't really matter much, would it? :-) Jordan From owner-freebsd-scsi Fri Jun 20 08:46:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA08626 for freebsd-scsi-outgoing; Fri, 20 Jun 1997 08:46:46 -0700 (PDT) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08621 for ; Fri, 20 Jun 1997 08:46:43 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idi.ntnu.no (8.8.5/8.8.5) with ESMTP id RAA11875; Fri, 20 Jun 1997 17:46:38 +0200 (MET DST) Message-Id: <199706201546.RAA11875@pat.idi.ntnu.no> To: Tor.Egge@idi.ntnu.no Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: scsi recovery code causes system freeze In-Reply-To: Your message of "Mon, 09 Jun 1997 21:16:39 +0200" References: <199706091916.VAA16067@pat.idi.ntnu.no> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Jun 1997 17:46:37 +0200 From: Tor Egge Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [I wrote] > I have some problems with heavy write activity on a scsi bus causing > scsi timeouts. Sometimes the machine freezes during the error > recovery. Due to several (>5) freezes I ended up writing a workaround. This workaround is not very well tested (The freezes do not occur *that* often), but I believe it is mostly correct. Jun 20 16:43:13 ikke /kernel: ahc1: Issued Channel A Bus Reset. 11 SCBs aborted Jun 20 16:43:13 ikke /kernel: Clearing bus reset Jun 20 16:43:13 ikke /kernel: sd7: Will resubmit scsi cmd Jun 20 16:43:13 ikke /kernel: Clearing 'in-reset' flag Jun 20 16:43:13 ikke /kernel: sd6: no longer in timeout Jun 20 16:43:13 ikke /kernel: sd8: no longer in timeout Jun 20 16:43:13 ikke /kernel: sd7: UNIT ATTENTION asc:29,2 Jun 20 16:43:13 ikke /kernel: , retries:3 Jun 20 16:43:13 ikke /kernel: sd6: UNIT ATTENTION asc:29,2 Jun 20 16:43:13 ikke /kernel: , retries:3 Jun 20 16:43:13 ikke /kernel: sd8: UNIT ATTENTION asc:29,2 Jun 20 16:43:14 ikke /kernel: , retries:3 Jun 20 16:43:14 ikke /kernel: sd9: UNIT ATTENTION asc:29,2 Jun 20 16:43:14 ikke /kernel: , retries:4 Jun 20 16:43:14 ikke /kernel: sd10: UNIT ATTENTION asc:29,2 Jun 20 16:43:14 ikke /kernel: , retries:4 Jun 20 16:43:14 ikke /kernel: sd7: Resubmitting scsi cmd ---------- Index: aic7xxx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/scsi/aic7xxx.c,v retrieving revision 1.118 diff -u -r1.118 aic7xxx.c --- aic7xxx.c 1997/04/26 05:03:18 1.118 +++ aic7xxx.c 1997/06/20 15:12:35 @@ -2355,6 +2355,56 @@ #endif } +static void ahc_resubmit __P((void *data)); +static void ahc_resubmit(data) + void *data; +{ + struct scsi_xfer *xs; + struct scsi_link *sc_link; + int retval; + int s; + + xs = (struct scsi_xfer *) data; + sc_link = xs->sc_link; + + sc_print_addr(sc_link); + printf("Resubmitting scsi cmd\n"); + s = splbio(); + retval = (*(sc_link->adapter->scsi_cmd)) (xs); + splx(s); + + switch (retval) { + case SUCCESSFULLY_QUEUED: + /* + * Finally queued properly, or a new resubmit has been scheduled + */ + return; + case TRY_AGAIN_LATER: + /* + * Ran out of SCBs. Schedule a new retry in 1 second. + */ + xs->error = XS_NOERROR; + xs->flags &= ~ITSDONE; + timeout(ahc_resubmit,(caddr_t) xs,hz); + return; + case COMPLETE: + /* + * Ran out of DMA segments. (aic7xxx.c specific) + */ + xs->flags |= ITSDONE; + s = splbio(); + scsi_done(xs); + splx(s); + return; + case HAD_ERROR: + default: + /* + * Should not happen (aic7xxx.c specific) + */ + panic("ahc_resubmit: Unexpected return code (%d)",retval); + } +} + /* * start a scsi operation given the command and * the data address, target, and lun all of which @@ -2387,6 +2437,17 @@ && (ahc->in_reset & CHANNEL_B_RESET) != 0) || (!IS_SCSIBUS_B(ahc, xs->sc_link) && (ahc->in_reset & CHANNEL_A_RESET) != 0)) { + if ((flags & SCSI_NOMASK) == 0) { + sc_print_addr(xs->sc_link); + printf("Will resubmit scsi cmd\n"); + timeout(ahc_resubmit,(caddr_t) xs,hz); + return SUCCESSFULLY_QUEUED; + } + /* + * This is broken, since it will cause an infinite loop + * of retries while timeouts are blocked. + */ + printf("Warning: Freeze imminent\n"); /* Ick, but I don't want it to abort this */ xs->retries++; xs->error = XS_BUSY; -------- - Tor Egge From owner-freebsd-scsi Sat Jun 21 10:49:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11476 for freebsd-scsi-outgoing; Sat, 21 Jun 1997 10:49:02 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA11463 for ; Sat, 21 Jun 1997 10:48:55 -0700 (PDT) Received: (qmail 11650 invoked by uid 1000); 21 Jun 1997 17:49:01 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706200929.CAA12213@implode.root.com> Date: Sat, 21 Jun 1997 10:49:01 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: dg@root.com Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: Brian Tao , FREEBSD-SCSI , FREEBSD-HACKERS , "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi David Greenman; On 20-Jun-97 you wrote: ... > Before everyone throws out their metal drive enclosures in favor of > plastic ones, let me say something about my experiance. Wcarchive used to > lose a couple of drives a month back when they were housed in plastic > enclosures. I noticed that the drives in that box ran hot, and I finally > got > tired of flying down to the Bay area so often to deal with it and > convinced > WC to replace the cabinet/enclosures with an all-steel one made by > Kingston. > This was about a year ago. Result: The drives run almost cold now and we > haven't had a single failure in that array since. All of our drives have > fairly well balanced spindles and don't vibrate all that much, and I've > never > seen a reported seek failure or noticed any slowness. In my opinion, the > all- > metal enclosure is a significant factor in the cooling of the drives and > these > days I wouldn't consider anything else. > YMMV. Before this turns into a religious war :-) IMHO; there is nothing inherently bad in platic carriers nor in metal carriers. Either technology can be either well made or poorly made. If David would have examined both the plastic carriers that failed and the metal carriers that are so successful, he would have discovered that one is allowing better air flow than the other. Should David had taped shut all the air passages in the metal carrier, it would have overheater just as nicely, unless the thing was imeresed in coold water. I brought up the platic carriers more as an anecdore to illustrate that platic is not necessarily bad, nor metal necessarily good. Good airflow, vibration isolation, quality drives, and just as important carriers rack and cabinet cooling are just as important. Simon From owner-freebsd-scsi Sat Jun 21 10:49:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11500 for freebsd-scsi-outgoing; Sat, 21 Jun 1997 10:49:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA11467 for ; Sat, 21 Jun 1997 10:48:56 -0700 (PDT) Received: (qmail 11673 invoked by uid 1000); 21 Jun 1997 17:49:01 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 21 Jun 1997 10:49:01 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-Hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG Subject: Mystery of The missing I/O - Help Solicited Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Y'all This message is for all those who are still speaking to me after daring to suggest that plasic (yuck!) disk carriers can be as good as steel ones (imagine that!) :-)) No, really, there is something serious we could be helped with: With the new DPT driver, we were plagued with occasional getting stuck. what happens is that after few minutes of operation, or after few days of operation, under varying loads, any process which goes to a certain disk would just block indefinitely. We verified that we do not miss processing any interrupt. We fixed a minor hole that causes biodone to get confused every million I/O's or so. We traced individual commands to make sure that we do not have any SCSI command which we do not return to sd.c To make these verifications we built all kinds of strange and interesting tools. Nothing helps. Oh, to confuse everyone, we can reproduce this problem only on Pentium Pros. Pentium-100's simply will not fail. We braught the load on test systems all the way up to about 120. Nothing. Next hint set; We can reliably reproduce the problem only on sendero, only when doing make release. So we though. Today we decided to try something else. We quited down ALL networking activity on the system, including disconnecting PPP. We managed to build make release flawlessly. Several times. Connect PPP and SCSI command completions seem to disappear somewhere between sd.c and the driver or higher. Disconnect PPP and all is well. Before someone tells me to shut down the software interrupts, I will be quickly to point out that I can #ifdef it out and still get the same problem. Exactly. Let me point out that the DPT can complete a SCSI READ/WRITE command in about 250 microseconds (on a cache hit). We measured, occasionally, interruptscoming as fast as 4 microseconds apart (like two consecutive cache hits). We are at our wits end to find an explanation for this. Any suggestion will be greatly appreciated. Thamx, Simon Quiz: How many SCSI commands does it take to run make release? Answer: 300,000 reads and 2.1 million writes. From owner-freebsd-scsi Sat Jun 21 10:49:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11503 for freebsd-scsi-outgoing; Sat, 21 Jun 1997 10:49:08 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA11465 for ; Sat, 21 Jun 1997 10:48:55 -0700 (PDT) Received: (qmail 11652 invoked by uid 1000); 21 Jun 1997 17:49:01 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <27545.866803027@time.cdrom.com> Date: Sat, 21 Jun 1997 10:49:01 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Jordan K. Hubbard" Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: Brian Tao , FREEBSD-SCSI , FREEBSD-HACKERS , "Justin T. Gibbs" , dg@root.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi "Jordan K. Hubbard"; On 20-Jun-97 you wrote: ... > I would also be suspicious of the cooling properties of a plastic > drive enclosure (it seems like packing it in a mini-Igloo ice chest > would be no worse to me ;-), but given a much different racking > scenario, say 80 drives in a single free-standing rack, I'm more than > willing to believe that vibration becomes a significant problem > requiring creative solutions. If it were my fingers signing the P.O. > on a true drive-array-from-hell, I'd probably favor the vendor > providing the best combination of all-metal construction, air-flow, > power supply quality and vibration isolation. We needed to put 3,000 drives in an array. We ended up with 200 drives per cabinet and 15 cabinets per system. Made finding the CPU array a bit difficult :-) We snickered at the DEC solution and jibed about it a lot worse than you do :-). The DEc engineers were cool about it and kept on saying ``just try it, will you?'' ``Sure we said'' this thing will be out of here in no time. No way these things will ever work. We put a recording thermometer in every disk, in every tray, in every rack. We put the rack in an oven and cooked at 110 F for a week. Ambient + 10 said the spec, ambient + 10 it was. In all spots. All the time. Ambient + 12 with one fan off. The spec said do not phisically remove a fan for more than 2 minutes. In 5 minutes the drives overheated. Then we pulled our heaviest gun. No way a plastic carrier in plastic rack will pass EMI/RFI. Guess again. I think what happened there was that these kids at DEC, knowing nothing about system engineering, and absolutely nothing about mechanical design nor disk drives just got lucky. > Unless, of course, they had something like the AMES wind tunnel > providing forced airflow past the drives, then I suppose the plastic > sled construction wouldn't really matter much, would it? :-) Actually, of the 5-6 designs weevaluated here, the DEC solution is also the quitest. Just to trigger another round of heated and energetic discussion: Our hardware engineers computed, with great precision, that to run 6 drives, one needs at least 300W. DEC engineers obviusly skipped school that day as their P/S are only 150W each. ~No way will you be able to ever hot plug a P/S or replace a disk. Sure. I took a rack, put one power supply and SEVEN (not 6) drives in it and powered it up, booted FreeBSD, and formatted all the drives at the same time. Then I started random I/O with read-write cycle on all drives. 256 instances in all. Worked fine. Oh, BTW, the in-house design, using TWO 300W power supplies crashes EVERY TIME you unplug or plug a disk. As I said, DEC has no clue how to build a disk system. They make lousy CPU's too. Simon From owner-freebsd-scsi Sat Jun 21 13:18:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA17348 for freebsd-scsi-outgoing; Sat, 21 Jun 1997 13:18:55 -0700 (PDT) Received: from peedub.gj.org (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA17339; Sat, 21 Jun 1997 13:18:48 -0700 (PDT) Received: from peedub.gj.org (localhost [127.0.0.1]) by peedub.gj.org (8.8.5/8.6.9) with ESMTP id WAA07125; Sat, 21 Jun 1997 22:18:33 GMT Message-Id: <199706212218.WAA07125@peedub.gj.org> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-hackers@freefall.FreeBSD.org Cc: FreeBSD-SCSI@FreeBSD.ORG Subject: Re: Mystery of The missing I/O - Help Solicited Reply-To: Gary Jennejohn In-reply-to: Your message of "Sat, 21 Jun 1997 10:49:01 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 1997 22:18:32 +0000 From: Gary Jennejohn Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro writes: [snip] >Today we decided to try something else. We quited down ALL networking >activity on the system, including disconnecting PPP. We managed to build >make release flawlessly. Several times. Connect PPP and SCSI command >completions seem to disappear somewhere between sd.c and the driver or >higher. Disconnect PPP and all is well. > which PPP ? Kernel or user-land ? Seems like this should be important. --- Gary Jennejohn Home - Gary.Jennejohn@munich.netsurf.de Work - gjennejohn@frt.dec.com From owner-freebsd-scsi Sat Jun 21 17:07:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA27330 for freebsd-scsi-outgoing; Sat, 21 Jun 1997 17:07:41 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA27290 for ; Sat, 21 Jun 1997 17:07:28 -0700 (PDT) Received: (qmail 2243 invoked by uid 1000); 22 Jun 1997 00:07:34 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706212218.WAA07125@peedub.gj.org> Date: Sat, 21 Jun 1997 17:07:34 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Gary Jennejohn Subject: Re: Mystery of The missing I/O - Help Solicited Cc: FreeBSD-SCSI@FreeBSD.ORG, freebsd-hackers@freefall.FreeBSD.org Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Gary Jennejohn; On 21-Jun-97 you wrote: > Simon Shapiro writes: > [snip] > >Today we decided to try something else. We quited down ALL networking > >activity on the system, including disconnecting PPP. We managed to > build > >make release flawlessly. Several times. Connect PPP and SCSI command > >completions seem to disappear somewhere between sd.c and the driver or > >higher. Disconnect PPP and all is well. > > > > which PPP ? Kernel or user-land ? Seems like this should be important. Kernel PPP. Source is RELENG_2_2 as of 971619. Existed earlier. We do see an occsional buffer overflow warning on the sio port where PPP is running. Baud rate is either 115,200 (ISDN 64Kb) or 230,400 (128Kb ISDN). One more thing. We get a 1-8 seconds delay in the system every now and then. It manifests itself as a complete freeze that comes suddenly and releases suddenly. It is NOT in the DPT driver. Internal to the driver, we see it as a similar delay in serving software interrupts or in return from scsi_done(). Simon