From owner-freebsd-scsi Sun Oct 10 1: 8:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id D354A15252 for ; Sun, 10 Oct 1999 01:08:14 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) for freebsd-scsi@freebsd.org id 11aE1e-00039I-00; Sun, 10 Oct 1999 01:08:14 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id BAA26066; Sun, 10 Oct 1999 01:08:10 -0700 Date: Sun, 10 Oct 1999 01:08:10 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Disktab entry for Seagate ST-19171W (Barracuda 9) To: freebsd-scsi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having some trouble getting a Seagate ST-19171W (Barracuda 9) configured. Does anyone out there have a working disktab entry for these drives? (FreeBSD 3.1R, to be upgraded to 3.3R as soon as I can get this drive on-line and copy some stuff to it.) The symptom I'm getting is parity errors near the end of the newfs on any reasonably large partition. But the drive validation test in the host adapter's ROM BIOS says the disk is fine. (The HA is an Adaptec 2940UW) Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 10 9: 4:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id C3C5415267 for ; Sun, 10 Oct 1999 09:04:32 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11aJyV-00071o-00; Sun, 10 Oct 1999 07:29:23 -0700 Date: Sun, 10 Oct 1999 07:29:21 -0700 (PDT) From: Tom To: David O'Brien Cc: scsi@freebsd.org Subject: Re: CAM hanging and not reseting properly on 2940UW In-Reply-To: <19991009232125.A693@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 9 Oct 1999, David O'Brien wrote: > (cd1:ahc0:0:5:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x110 > (cd1:ahc0:0:5:0): BDR message in message buffer > (cd1:ahc0:0:5:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x10f > (cd1:ahc0:0:5:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 17SCBs aborted ... > Shouldn't CAM reset the SCSI bus and recover from the above errors? I > tried powering down & up the CDROM drive and that didn't change anything. It just did ("Channel A Bus Reset"). It obviously didn't work. Since any process that touches your disk hangs, I would imagine your hard drive is what is actually hung. It could be that your CDROM is screwing up the entire bus though. Either way, a reset is issued, and seems to ignored. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 8:48:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id BAFA7150AF for ; Mon, 11 Oct 1999 08:48:08 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id LAA24324; Mon, 11 Oct 1999 11:43:37 -0400 (EDT) Reply-To: Randell Jesup To: "Matthew N. Dodd" Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: From: Randell Jesup Date: 11 Oct 1999 11:43:29 +0000 In-Reply-To: "Matthew N. Dodd"'s message of "Sat, 9 Oct 1999 23:54:18 -0400 (EDT)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Matthew N. Dodd" writes: >On 9 Oct 1999, Randell Jesup wrote: >> Sure. In this case, if someone had docs on the bus interface for a >> 710-based card, and people had some real use for a driver for them (I >> don't know if that's true), it probably wouldn't be hard to modify an >> '810 driver to support it. I didn't have any real plans to do so when >I've taken a look at the NCR driver and my conclusion, outside of any SIM >issues is that 2 things need to happen. > >1. The NCR driver needs to be converted to bus_space. [snip] >2. The NCR driver needs be converted to use newbus, not the legacy shims > it is currently using. [snip] >If someone wants to start working on this I will make myself available for >newbus related questions and will also provide EISA bus front ends for the >various onboard and expansion 53c7xx based boards I've got laying around. > >Since the 53c[78]xx chips either have onboad PCI interfacing logic, or >make use of fairly standard bus interface logic I don't think that the >actual bus specific bits will be anything more than bus_space and >attention to proper alignment. So, it sounds like it's certainly doable with some (but not major) effort. Here's the question then (Gerard's question): is it worth doing? Would anyone have a use for this? While of limited utility, it would help me understand how a FreeBSD driver/SIM is put together. The other possible thing I'm considering doing (since a couple of the SIM's do have support for target-mode) is to build an IP transport on top of CAM2/3 target mode. I suspect this is more useful, especially for people building high-reliability servers (that was why DEC was so interested in target mode; several of the other people on the target-mode subcommittee were from DEC, and implemented target-mode for this purpose). Very high speed (short-distance) networking. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 8:51:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 1D0ED15128 for ; Mon, 11 Oct 1999 08:51:34 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id JAA33347; Mon, 11 Oct 1999 09:41:08 -0600 (MDT) Date: Mon, 11 Oct 1999 09:41:08 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199910111541.JAA33347@narnia.plutotech.com> To: obrien@NUXI.com Cc: scsi@FreeBSD.org Subject: Re: CAM hanging and not reseting properly on 2940UW X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <19991009232125.A693@dragon.nuxi.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19991009232125.A693@dragon.nuxi.com> you wrote: > My system has hung twice tonight -- running X, and find a rouge process > is stating stuff in / and causes one of the CDROM drives to spin up and > things "hang". I Ctrl-Alt-F1 to get to the real console and see: > > > (cd1:ahc0:0:5:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x110 > (cd1:ahc0:0:5:0): BDR message in message buffer > (cd1:ahc0:0:5:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x10f > (cd1:ahc0:0:5:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 17SCBs aborted > > Then the machine is hung. Most all keyboard input is ignored in the > console. I can "scroll lock" and scroll back to see console messages. > Hit "scroll lock" again, and no input accepted. > > I cannot Ctrl-Alt-ESC to enter the debugger. Nor is Ctrl-Alt-Del > accepted. > > I can how however Alt-Fx to enter other virtual consoles and keyboard > input is accpted -- that is until what is typed causes the a disk access. > > Shouldn't CAM reset the SCSI bus and recover from the above errors? I > tried powering down & up the CDROM drive and that didn't change anything. > > Is this a bug, or just life? It shouldn't cause the system to lock up unless CAM fails to recovery the device you are accessing. This smells like a bug in the reset code, but it is hard to say for sure without reproducing the bug here and analyzing it. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 9:27: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 4194014E5D for ; Mon, 11 Oct 1999 09:27:04 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id MAA10654; Mon, 11 Oct 1999 12:27:00 -0400 (EDT) Date: Mon, 11 Oct 1999 12:26:58 -0400 (EDT) From: "Matthew N. Dodd" To: Randell Jesup Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 11 Oct 1999, Randell Jesup wrote: > Here's the question then (Gerard's question): is it worth doing? Would > anyone have a use for this? While of limited utility, it would help > me understand how a FreeBSD driver/SIM is put together. I'd find it useful. :) As would anyone with a Compaq that has a 53c710 on the baseboard. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 11:51:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 22A7B155E5 for ; Mon, 11 Oct 1999 11:51:24 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id UAA20074; Mon, 11 Oct 1999 20:50:45 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id UAA60269; Mon, 11 Oct 1999 20:41:58 +0200 (MET DST) (envelope-from j) Message-ID: <19991011204158.08819@uriah.heep.sax.de> Date: Mon, 11 Oct 1999 20:41:58 +0200 From: J Wunsch To: patl@phoenix.volant.org Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from patl@phoenix.volant.org on Sun, Oct 10, 1999 at 01:08:10AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As patl@phoenix.volant.org wrote: > The symptom I'm getting is parity errors near the end of the newfs > on any reasonably large partition. That's hardly an error you could expect to be fixed by using another disktab entry. (Btw., disktab should probably completely go away.) Parity errors heavily smell like a cabling problem, which becomes more apparent when you drive the bus at full speed, while the host adapter formatting probably runs at a lower speed. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 11:56:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id E4E2215285 for ; Mon, 11 Oct 1999 11:56:04 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 11akc7-0004OV-00; Mon, 11 Oct 1999 11:56:03 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id LAA27983; Mon, 11 Oct 1999 11:55:53 -0700 Date: Mon, 11 Oct 1999 11:55:53 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <19991011204158.08819@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 12:14:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id E88C314F91 for ; Mon, 11 Oct 1999 12:14:06 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 11aktZ-0004YW-00; Mon, 11 Oct 1999 12:14:05 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id MAA27998; Mon, 11 Oct 1999 12:14:01 -0700 Date: Mon, 11 Oct 1999 12:14:01 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <19991011204158.08819@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Sorry for the null reply - I spazzed while the pointer was passing [ over the Deliver button. On 11-Oct-99 at 11:51, J Wunsch (j@uriah.heep.sax.de) wrote: > As patl@phoenix.volant.org wrote: > > > The symptom I'm getting is parity errors near the end of the newfs > > on any reasonably large partition. > > That's hardly an error you could expect to be fixed by using another > disktab entry. (Btw., disktab should probably completely go away.) True, it isn't the error I would expect if I were attempting to write to a non-existant block. But it passes the ROM BIOS's test; and it seems to be happening consistantly at the end of the newfs. (For a given partition, it always occurs at the same point in the log output. The reported CDB info changes slightly; but I don't know how to interpret that, so I don't know if it is significant.) And even if that isn't the problem, I'd still like a working disktab entry for that drive. > Parity errors heavily smell like a cabling problem, which becomes more > apparent when you drive the bus at full speed, while the host adapter > formatting probably runs at a lower speed. I only have two devices on this HA. The first is an Exabyte EZ17; which has been working without problem for several months. The other is this disk I'm having problems with. I always try to get high-quality cables. I didn't try formatting, just verifying. Can you suggest any good tests to run from within FreeBSD to check this out? Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 13: 2:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id E71A114A2E for ; Mon, 11 Oct 1999 13:00:46 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-109-153.villette.club-internet.fr [194.158.109.153]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA13865; Mon, 11 Oct 1999 22:00:16 +0200 (MET DST) Date: Mon, 11 Oct 1999 22:22:03 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Randell Jesup Cc: "Matthew N. Dodd" , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 11 Oct 1999, Randell Jesup wrote: > "Matthew N. Dodd" writes: > >On 9 Oct 1999, Randell Jesup wrote: > >> Sure. In this case, if someone had docs on the bus interface for a > >> 710-based card, and people had some real use for a driver for them (I > >> don't know if that's true), it probably wouldn't be hard to modify an > >> '810 driver to support it. I didn't have any real plans to do so when >=20 > >I've taken a look at the NCR driver and my conclusion, outside of any SI= M > >issues is that 2 things need to happen. > > > >1. The NCR driver needs to be converted to bus_space. > [snip] > >2. The NCR driver needs be converted to use newbus, not the legacy shims > > it is currently using. > [snip] > >If someone wants to start working on this I will make myself available f= or > >newbus related questions and will also provide EISA bus front ends for t= he > >various onboard and expansion 53c7xx based boards I've got laying around= =2E > > > >Since the 53c[78]xx chips either have onboad PCI interfacing logic, or > >make use of fairly standard bus interface logic I don't think that the > >actual bus specific bits will be anything more than bus_space and > >attention to proper alignment. >=20 > =09So, it sounds like it's certainly doable with some (but not major) > effort. >=20 > =09Here's the question then (Gerard's question): is it worth doing? > Would anyone have a use for this? While of limited utility, it would > help me understand how a FreeBSD driver/SIM is put together. In my opinion, a driver (and driver writers) must be aware of the actual BUS used by devices, since ordering rules and optimization concerns depend on the actual BUS being used. A driver that works for ISA/EISA and PCI without any code difference is likely either sub-optimal or just broken for some of these BUSes. This let me think that too much abstraction-mania for BUSes may lead to bad drivers in the first place.=20 Some BUS abstraction allows to deal with machines that does not implement the flat memory model as suggested by PCI. For these ones you have to ensure that memory you want to DMA is DMAable and allow the system to handle the corresponding resources that are obviously limited. Abstractions for these sort of hacked hardware (generally due to the history of that hardware) lead to useless overhead and code complexity on simple machines that implement the flat memory model for PCI. Having to ask a kernel abstraction for providing me a scatter list and then having to rewalk it for it to conform with the expectations of the hardware (sometimes modulo device errata) is something that makes me pain in the ass to run on my Intel machine. So, even if I ever go with some BUS abstractions for this kind of stuff, I will keep with the legacy _simple_ way to do the same thing, conditionnally compilable for my personnal use (as long as this legacy way will be available, obviously).=20 =20 Same pain in the ass if, when doing MMIO I have to call something that will not only do the memory access, but each time will test for having to do IO or MMIO. This situation may get just ridiculous for example for a device that only allows one of the IO methods (only MMIO for example on PCI). > =09The other possible thing I'm considering doing (since a couple of > the SIM's do have support for target-mode) is to build an IP transport You must distinguish between phase cognizant target mode and host target mode. What I intend to implement in the future is something that avoids stalling the phase engine as possible, thus host target mode. Note that if you just read the messages after selection, accept the command and disconnect prior to signaling the upper layer, then this host target mode will never stall the phase engine in normal situations when implemented with 53c8xx chips. This will allow to use both initiator and target mode on an HBA without wasting uselessly SCSI BUS bandwitch for the target mode part. As seen from SIM the handling of the target mode is in fact much simpler tham initiator mode, since the part that acts as a target has the baton in SCSI. So, a SIM that will only implement target mode should be significantly simpler than common ones that only implement initiator mode= =20 (given appropriate hardware).=20 What is not simple is to provide both modes from a SIM, without the support for the target mode adding too much complexity (making driver less reliable) and wasting too much resources. > on top of CAM2/3 target mode. I suspect this is more useful, especially > for people building high-reliability servers (that was why DEC was so > interested in target mode; several of the other people on the target-mode > subcommittee were from DEC, and implemented target-mode for this purpose)= =2E > Very high speed (short-distance) networking. Probably. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 13:43:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 6897515763 for ; Mon, 11 Oct 1999 13:43:35 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id QAA05483; Mon, 11 Oct 1999 16:39:03 -0400 (EDT) Reply-To: Randell Jesup To: Gerard Roudier Cc: "Matthew N. Dodd" , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: From: Randell Jesup Date: 11 Oct 1999 16:38:55 +0000 In-Reply-To: Gerard Roudier's message of "Mon, 11 Oct 1999 22:22:03 +0200 (MET DST)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier writes: >> The other possible thing I'm considering doing (since a couple of >> the SIM's do have support for target-mode) is to build an IP transport > >You must distinguish between phase cognizant target mode and host target >mode. What I intend to implement in the future is something that avoids >stalling the phase engine as possible, thus host target mode. Note that if >you just read the messages after selection, accept the command and >disconnect prior to signaling the upper layer, then this host target mode >will never stall the phase engine in normal situations when implemented >with 53c8xx chips. This will allow to use both initiator and target mode >on an HBA without wasting uselessly SCSI BUS bandwitch for the target mode >part. The original design of target mode in CAM had efficient operation in both initiator and target mode (as you described) as a primary goal, as well as a reasonably low level of complexity in the SIM (though obviously it must be more complex). >As seen from SIM the handling of the target mode is in fact much simpler >tham initiator mode, since the part that acts as a target has the baton in >SCSI. So, a SIM that will only implement target mode should be >significantly simpler than common ones that only implement initiator mode >(given appropriate hardware). True, though that isn't the goal I'd have. In any case, I'd be writing code (for the CAM IP transport) to talk to the CAM interface, and probably not writing SIMs unless they don't exist or have problems handling both initiation and target-mode at the same time. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 17:22:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id C2BA8156E6 for ; Mon, 11 Oct 1999 17:22:38 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id UAA00112; Mon, 11 Oct 1999 20:21:51 -0400 (EDT) Date: Mon, 11 Oct 1999 20:21:51 -0400 (EDT) From: "Matthew N. Dodd" To: Gerard Roudier Cc: Randell Jesup , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 11 Oct 1999, Gerard Roudier wrote: > In my opinion, a driver (and driver writers) must be aware of the > actual BUS used by devices, since ordering rules and optimization > concerns depend on the actual BUS being used. A driver that works for > ISA/EISA and PCI without any code difference is likely either > sub-optimal or just broken for some of these BUSes. This let me think > that too much abstraction-mania for BUSes may lead to bad drivers in > the first place. In cases where one driver offers a number of bus attachments, the driver is usually constrained by a suboptimal design in the first place. Take the if_ep driver; ISA, EISA, MCA, and PCCARD (and we could probably make it work with 3c59X boards too, and a few of the early 3c9xx boards in compat mode.) Granted this is just a stupid PIO driven chip but the glue logic presents the hardware to us in such a manner that the physical bus isn't really relevant outside of the probe/attach phase. Most performance oriented SCSI devices are going to use a scatter/gather list chain type of interface for reading/writing blocks of data and this is something that bus_dma does well for any physical bus. While it would be nice to use a function pointer or something faster to avoid the per call test of bus_space I somehow doubt that 2 or 3 instructions per port access are going to kill you given that port or memory accesses are so much slower than processor instructions. > Some BUS abstraction allows to deal with machines that does not implement > the flat memory model as suggested by PCI. For these ones you have to > ensure that memory you want to DMA is DMAable and allow the system to > handle the corresponding resources that are obviously limited. > Abstractions for these sort of hacked hardware (generally due to the > history of that hardware) lead to useless overhead and code complexity on > simple machines that implement the flat memory model for PCI. I think your complaint is directed at the opaqueness of bus_dma, not any flaws in its concept. Why not ask for pointers or bitch about the doc instead of taking pot-shots at a code base that exists to help driver writers arrive at code that is easier to maintain and more portable. Remember, we're not just using bus_space/bus_dma to work around ancient hardware; we have to consider the Alpha, the PPC, the MIPS, the ARM, and whatever hacked up busses happen to be hanging off of those systems. > Having to ask a kernel abstraction for providing me a scatter list and > then having to rewalk it for it to conform with the expectations of > the hardware (sometimes modulo device errata) is something that makes > me pain in the ass to run on my Intel machine. So, even if I ever go > with some BUS abstractions for this kind of stuff, I will keep with > the legacy _simple_ way to do the same thing, conditionnally > compilable for my personnal use (as long as this legacy way will be > available, obviously). > > Same pain in the ass if, when doing MMIO I have to call something > that will not only do the memory access, but each time will test for > having to do IO or MMIO. This situation may get just ridiculous for > example for a device that only allows one of the IO methods (only MMIO > for example on PCI). Feel free to keep on avoiding kernel APIs and standardization and bodies of code which lend themselves to multiple consumers. Do it on the Linux side of the fence though; they seem to appreciate that sort of nonsense. (you did say 'for your personal use' though, so maybe Linux isn't as fond of this sort of thing as they used to be.) I would welcome discussion on how to avoid redundant testing in the bus_space/bus_dma code though. I'm sure everyone has a few items on their wishlist that should be added before the code is declared 'mature'. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 11 23:51:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 10ABC14A2F for ; Mon, 11 Oct 1999 23:51:08 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA00888; Tue, 12 Oct 1999 08:50:46 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA63023; Tue, 12 Oct 1999 08:35:09 +0200 (MET DST) (envelope-from j) Message-ID: <19991012083509.43716@uriah.heep.sax.de> Date: Tue, 12 Oct 1999 08:35:09 +0200 From: J Wunsch To: patl@phoenix.volant.org Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) Reply-To: Joerg Wunsch References: <19991011204158.08819@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from patl@phoenix.volant.org on Mon, Oct 11, 1999 at 12:14:01PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As patl@phoenix.volant.org wrote: > (For a given partition, it always occurs at the same point in the > log output. The reported CDB info changes slightly; but I don't > know how to interpret that, so I don't know if it is significant.) Better quote an error message then. > I didn't try formatting, just verifying. Can you suggest any > good tests to run from within FreeBSD to check this out? dd if=/dev/rsa1 of=/dev/null bs=64k -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 0:10: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from lucky.medicusnet.de (ns.medicusnet.de [195.63.222.140]) by hub.freebsd.org (Postfix) with ESMTP id 50C8915285 for ; Tue, 12 Oct 1999 00:10:04 -0700 (PDT) (envelope-from maulwurf@subloch.medicusnet.de) Received: from subloch.medicusnet.de (uucp@localhost) by lucky.medicusnet.de (8.9.3/8.9.3) with UUCP id JAA14049 for freebsd-scsi@freebsd.org; Tue, 12 Oct 1999 09:10:02 +0200 Received: by subloch.medicusnet.de (CrossPoint v3.11 R/C2188); 12 Oct 1999 09:10:53 +0200 Date: 12 Oct 1999 09:10:00 +0200 From: maulwurf@subloch.medicusnet.de (Stefan Huerter) To: freebsd-scsi@freebsd.org Message-ID: <7Qhqy3MEoRB@subloch.medicusnet.de> Subject: panic: vinvalbuf: dirty bufs X-Mailer: CrossPoint v3.11 R/C2188 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: die wahre Antwort: 42 oder 23? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Guckux Running FreeBSD 3.3-STABLE from dmesg: da2 at ahc0 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da2: 1908MB (3907911 512 byte sectors: 64H 32S/T 1908C) I've recognized with FreeBSD 3.1 that this drive has problems with taggings, so I reduced them. I encounterd with FB 3.2 problems with this drive. Upgraded to FB 3.3 I checked it once more and get more problems. It is controlled from a Adaptec 2940, I make a low level format with the Adaptec-Bios and check 3 times via "verify disk media" with no problems. When I make a "newfs -i 8192" (with tagging disabled through camcontrol command) there will be a few superblocks written out, then newfs will stop (no screen-output anymore), the drive scratches a little bit and then I get following: panic: vinvalbuf: dirty bufs any chance to get it working back? or is it really damaged? Bye Stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 9:54: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 83C13157D3 for ; Tue, 12 Oct 1999 09:53:36 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id KAA34505; Tue, 12 Oct 1999 10:42:52 -0600 (MDT) Date: Tue, 12 Oct 1999 10:42:52 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199910121642.KAA34505@narnia.plutotech.com> To: Gerard Roudier Cc: scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Having to ask a kernel abstraction for providing me a scatter list and > then having to rewalk it for it to conform with the expectations of the > hardware (sometimes modulo device errata) is something that makes me pain > in the ass to run on my Intel machine. For the NCR, I would expect that you wouldn't need to rewalk it at all other than to copy it to your own private storage. With bus-dma, you should be able to specify all of the parameters necessary to get an S/G list that avoids all of your hardware bugs. Other than it being created before the transaction comes to the SIM, this seems very similar to Linux. Having every driver create their own S/G list is problematic when kernel interfaces change. What happens when we change our clustering code to pass down a list of I/O requests to be combined? Hopefully this will just result in the drivers calling a slightly different bus_dma method. > So, even if I ever go with some > BUS abstractions for this kind of stuff, I will keep with the legacy > _simple_ way to do the same thing, conditionnally compilable for my > personnal use (as long as this legacy way will be available, obviously). > > Same pain in the ass if, when doing MMIO I have to call something that > will not only do the memory access, but each time will test for having to > do IO or MMIO. This situation may get just ridiculous for example for a > device that only allows one of the IO methods (only MMIO for example on > PCI). FreeBSD does not cause any penalty for devices that only support a single access method. You just need to include the appropriate header files to indicate this and the extra overhead of supporting additional access methods goes away. Unfortunately, in the generic kernel case, you often need to support multiple access types in the same [PCI] driver as not all machines/chipsets handle the most efficient access method [MMIO]. If the abstraction allows you to create a readable piece of code that can be compiled to run generically but can also be compiled to run optimally this seems ideal. There has been some talk on the lists about adding kernel options that would allow you to globally optimize the access methods so even drivers that sometimes need to support mutliple access methods can be easily tuned for specific machines. Since you seem to have an opinion about these things, perhaps you should join in the discussions. >> The other possible thing I'm considering doing (since a couple of >> the SIM's do have support for target-mode) is to build an IP transport > > You must distinguish between phase cognizant target mode and host target > mode. What I intend to implement in the future is something that avoids > stalling the phase engine as possible, thus host target mode. Note that if > you just read the messages after selection, accept the command and > disconnect prior to signaling the upper layer, then this host target mode > will never stall the phase engine in normal situations when implemented > with 53c8xx chips. This will allow to use both initiator and target mode > on an HBA without wasting uselessly SCSI BUS bandwitch for the target mode > part. I agree phase cognizant isn't that interesting. The aic7xxx driver works in the fashion you describe. > As seen from SIM the handling of the target mode is in fact much simpler > tham initiator mode, since the part that acts as a target has the baton in > SCSI. So, a SIM that will only implement target mode should be > significantly simpler than common ones that only implement initiator mode > (given appropriate hardware). > What is not simple is to provide both modes from a SIM, without the > support for the target mode adding too much complexity (making driver less > reliable) and wasting too much resources. Target mode isn't difficult, but I would refrain from calling it simpler than the initiator role. There are several little gotchas mostly having to do with resource deadlocks when running in both roles at the same time and the initiator tells you that you cannot disconnect. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 11:28:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 0911C157BE for ; Tue, 12 Oct 1999 11:28:19 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id OAA05103; Tue, 12 Oct 1999 14:21:25 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910121642.KAA34505@narnia.plutotech.com> From: Randell Jesup Date: 12 Oct 1999 14:23:43 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 12 Oct 1999 10:42:52 -0600 (MDT)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >> You must distinguish between phase cognizant target mode and host target >> mode. What I intend to implement in the future is something that avoids >> stalling the phase engine as possible, thus host target mode. Note that if >I agree phase cognizant isn't that interesting. The aic7xxx driver works >in the fashion you describe. Phase cognizant is mostly useful for making -workalikes, and (primarily) for testing the initiator's SCSI implementation (by feeding it weird shit). I have no real interest in either at this point. >> As seen from SIM the handling of the target mode is in fact much simpler >> tham initiator mode, since the part that acts as a target has the baton in >> SCSI. So, a SIM that will only implement target mode should be >> significantly simpler than common ones that only implement initiator mode >> (given appropriate hardware). >Target mode isn't difficult, but I would refrain from calling it simpler >than the initiator role. There are several little gotchas mostly having >to do with resource deadlocks when running in both roles at the same time >and the initiator tells you that you cannot disconnect. Well, you could always punt and return an error in that case (though it's very not-nice to do so). I assume the problem becomes something like: command comes in with disconnect-disabled. You need to page (or otherwise access a disk) to fufill the request. The disk you need to access is on the same bus. Ooops. I forget if this was explicitly considered in the CAM subcommittee discussions, or if it was just felt that this was something that could not be dealt with. I wouldn't be surprised if we thought about it and agreed that it was not solvable, and that an error return was perfectly reasonable, and that in this sort of situation reselect-enabled was VERY strongly advised. I'm going to dig out my old mail archives from the Section 10 (now renumbered) subcommittee. (A lot happened over conference calls too; we never met in person.) Thanks for the info. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 12:25:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 2F8F514FD7 for ; Tue, 12 Oct 1999 12:25:03 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 11b7Xi-0001in-00; Tue, 12 Oct 1999 12:25:02 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id MAA29251; Tue, 12 Oct 1999 12:24:54 -0700 Date: Tue, 12 Oct 1999 12:24:54 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <19991012083509.43716@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 11-Oct-99 at 23:51, J Wunsch (j@uriah.heep.sax.de) wrote: > As patl@phoenix.volant.org wrote: > > > (For a given partition, it always occurs at the same point in the > > log output. The reported CDB info changes slightly; but I don't > > know how to interpret that, so I don't know if it is significant.) > > Better quote an error message then. Actually, I was wrong, the CDB info only changes if the partition size or offset changes. I've got the machine off now, so I can't report the full text of the errors; but I did write down some of the significant parts. CDB: a 0 8 20 a 0 asc 47,0 write error: 2048 parity error in vendor replacable unit 3 The second and third values in the CDB change if I change the partition size or offset. And I'm not certain about the exact wording of the 'parity error...' message - that part's from memory. Before your previous message I hadn't seriously considered that the cable might be the problem. (My previous experience with occasional SCSI cable problems had led to more frequent or more randomly occurring symptoms.) After reading your message, I thought it was worth checking though, so I removed that cable and the EZ17 and tested with the cable that had been on the tape library. No problems. So at the moment, I'm assuming that either it's a slightly flakey cable or that I've misunderstood which bit of the SCSI spec applies to my situation; and two three-foot segments have placed me over the maximum cable length. In a few minutes I'll be going out to get a new (and if I can find one, shorter) cable. If that doesn't work, I'll report back to the list for more help. > > I didn't try formatting, just verifying. Can you suggest any > > good tests to run from within FreeBSD to check this out? > > dd if=/dev/rsa1 of=/dev/null bs=64k Hmm. I tried dd'ing from /dev/zero to rda0; but not the other way. (I assume you ment rda1, instead of rsa1 there. If not, I'm further behind on the effects of the CAM integration than I thought.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 12:32:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id 2709514E65 for ; Tue, 12 Oct 1999 12:32:09 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-108-130.villette.club-internet.fr [194.158.108.130]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA13907; Tue, 12 Oct 1999 21:31:55 +0200 (MET DST) Date: Tue, 12 Oct 1999 21:53:46 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: <199910121642.KAA34505@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 12 Oct 1999, Justin T. Gibbs wrote: > In article you wrote: > >=20 > > Having to ask a kernel abstraction for providing me a scatter list and > > then having to rewalk it for it to conform with the expectations of the > > hardware (sometimes modulo device errata) is something that makes me pa= in > > in the ass to run on my Intel machine. >=20 > For the NCR, I would expect that you wouldn't need to rewalk it at > all other than to copy it to your own private storage. With bus-dma, > you should be able to specify all of the parameters necessary to get > an S/G list that avoids all of your hardware bugs. Other than it being > created before the transaction comes to the SIM, this seems very similar > to Linux. >=20 > Having every driver create their own S/G list is problematic when kernel > interfaces change. What happens when we change our clustering code to > pass down a list of I/O requests to be combined? Hopefully this will > just result in the drivers calling a slightly different bus_dma method. The bus dma method I have seen requires the caller to wait for a call back for the resources to be available. This moves the burden of having to deal with such resources leakage in the SIM. This should be an option, in my opinion and optionnally handled from the caller (that will provide a scatter list to the SIM). I read that such bus dma method was also intended to deal with host bridge that does not ensure cache consistency or any other weirdnesses that can be encountered with existing bridges.=20 Let me give you an example: Let consider a host bridge (such does exist) that posts both IO and MMIO and MMIO transactions (By the way, the PCI specs allows host bridge to also post IOs). Let this crap also not implement the PCI ordering rules, but wan to be able to interface properly with PCI-2.1/2.2 PCI-to-PCI bridges. Let then this utter crap allow to force flushing of transactions by the host bridge by tampering some specific hardware registers, in order to ensure a consistent view of data when needed.=20 If you want a PCI device driver to really work on such weirdness, then abstractions will not help at all. On the contrary, you must allow the drivers to have a real handle on the hardware (including host bridge), and using normal IOs will not be enough at all. If it was possible for us to look into proprietary PCI device drivers, may-be we will discover how such situation is actually handled the kinds of hardware I am speaking about. There are errata everywhere and one who wants to provide reliable PCI device driver for portable O/S must be aware on the erratas of the PCI device and at least of the functionnal description of existing host bridges when available (erratas will be a plus but aren't always available). The way the CPU handles write buffers must also be considered, especially when using MMIOs. Even a feature can become a bug, given all that mess. Drivers that are actually maintained are generally converted to new O/S requirements very quickly, in my experience.=20 By the way, some constraints as the max size of scatter entries, the clustering of scatter entries, not traversing some address boundary, etc =2E.., when building a scatter list may affect performances and/or trigger erratas. I just wanted not to have to do the work twice, even if this may seem to possibly happen on Linux. In fact under Linux, scatter entries are aligned on some nice address boundaries and you can tell the upper layer not to clusterize entries.=20 Some O/S designed to be portable (but seems no longer to be so) got slow probably due to some infinite of epsilonish design and implementation errors. I would be sad to ever see any free UNIX O/S to get NTified this way. > > So, even if I ever go with some > > BUS abstractions for this kind of stuff, I will keep with the legacy > > _simple_ way to do the same thing, conditionnally compilable for my > > personnal use (as long as this legacy way will be available, obviously)= =2E=20 > > =20 > > Same pain in the ass if, when doing MMIO I have to call something that > > will not only do the memory access, but each time will test for having = to > > do IO or MMIO. This situation may get just ridiculous for example for a > > device that only allows one of the IO methods (only MMIO for example on > > PCI). >=20 > FreeBSD does not cause any penalty for devices that only support a single > access method. You just need to include the appropriate header files > to indicate this and the extra overhead of supporting additional access > methods goes away. Unfortunately, in the generic kernel case, you often > need to support multiple access types in the same [PCI] driver as not > all machines/chipsets handle the most efficient access method [MMIO]. > If the abstraction allows you to create a readable piece of code that > can be compiled to run generically but can also be compiled to run > optimally this seems ideal. There has been some talk on the lists about > adding kernel options that would allow you to globally optimize the > access methods so even drivers that sometimes need to support mutliple > access methods can be easily tuned for specific machines. Since you > seem to have an opinion about these things, perhaps you should join > in the discussions. Sorry and Thanks. I missed that. Will look into the sources. > >> =09The other possible thing I'm considering doing (since a couple of > >> the SIM's do have support for target-mode) is to build an IP transport > >=20 > > You must distinguish between phase cognizant target mode and host targe= t > > mode. What I intend to implement in the future is something that avoids > > stalling the phase engine as possible, thus host target mode. Note that= if > > you just read the messages after selection, accept the command and > > disconnect prior to signaling the upper layer, then this host target mo= de > > will never stall the phase engine in normal situations when implemented > > with 53c8xx chips. This will allow to use both initiator and target mod= e > > on an HBA without wasting uselessly SCSI BUS bandwitch for the target m= ode > > part. >=20 > I agree phase cognizant isn't that interesting. The aic7xxx driver works > in the fashion you describe. I am very glad of that and believe me I ignored it. > > As seen from SIM the handling of the target mode is in fact much simple= r > > tham initiator mode, since the part that acts as a target has the baton= in > > SCSI. So, a SIM that will only implement target mode should be > > significantly simpler than common ones that only implement initiator mo= de=20 > > (given appropriate hardware).=20 > > What is not simple is to provide both modes from a SIM, without the > > support for the target mode adding too much complexity (making driver l= ess > > reliable) and wasting too much resources. >=20 > Target mode isn't difficult, but I would refrain from calling it simpler > than the initiator role. There are several little gotchas mostly having I mean simpler to act as target than as initiator regarding the SCSI protocol and simpler to write a driver that _only_ implements target role than a driver than _only_ implements initiator role. > to do with resource deadlocks when running in both roles at the same time > and the initiator tells you that you cannot disconnect. Move 10 lines above, and you will see that I didn't write that support=20 for both roles was simple. AFAIR, in CAM3, the target peripheral driver can require disconnections to be used. In this situation the initiator must just be refused to be served when it disallows disconnections. And if both target and initiator parts actually want to waste SCSI bandwitch, we just have to 'dont_care' and behave as both parts did agree. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 13: 2:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id C4A871535B for ; Tue, 12 Oct 1999 13:02:20 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id OAA02480; Tue, 12 Oct 1999 14:03:01 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199910122003.OAA02480@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Gerard Roudier Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller In-reply-to: Your message of "Tue, 12 Oct 1999 21:53:46 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 1999 14:03:01 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Having every driver create their own S/G list is problematic when kern= el >> interfaces change. What happens when we change our clustering code to= >> pass down a list of I/O requests to be combined? Hopefully this will >> just result in the drivers calling a slightly different bus_dma method= =2E > >The bus dma method I have seen requires the caller to wait for a call ba= ck >for the resources to be available. This moves the burden of having to de= al >with such resources leakage in the SIM. This should be an option, in my >opinion and optionnally handled from the caller (that will provide a >scatter list to the SIM). How does the caller know all of the proper parameters your driver needs in order to properly perform the I/O? The caller is some generic peripheral driver that doesn't want to know about the different chipset, bridge, device interactions. In fact, CAM doesn't want to know about you= r particular hardware either, only that your SIM honors the expected CAM API. >I read that such bus dma method was also intended to deal with host brid= ge >that does not ensure cache consistency or any other weirdnesses that can= >be encountered with existing bridges. = Yes. >Let me give you an example: >Let consider a host bridge (such does exist) that posts both IO and MMIO= >and MMIO transactions (By the way, the PCI specs allows host bridge to >also post IOs). Let this crap also not implement the PCI ordering rules,= >but wan to be able to interface properly with PCI-2.1/2.2 PCI-to-PCI >bridges. Let then this utter crap allow to force flushing of transaction= s >by the host bridge by tampering some specific hardware registers, in ord= er >to ensure a consistent view of data when needed. = > >If you want a PCI device driver to really work on such weirdness, then >abstractions will not help at all. I beg to differ. When your hardware is probed, a hierarchical bus tag is= created. If any particular bus, chipset, etc. on the way to your device has particular size, alignment, or cache coherency constraints, it has the ability to impose these restrictions on any operation performed by the 'child' or final owner of the tag. In the case of most x86 machines (the ones without bugs), all tag operations becomes no-ops and you get almost identical performance to the non-busdma case (we added two functio= n calls to create the S/G list, but you are now using code shared with othe= r drivers that has a better chance of being in the cache). Before you begin a dma, the bus dma code has the opportunity to intercede. After a dma completes, the bus dma code has the opportunity to intercede. If bus dma must intercede, sure, it will be slower than if it didn't have= to, but your driver need never know. >On the contrary, you must allow the >drivers to have a real handle on the hardware (including host bridge), a= nd >using normal IOs will not be enough at all. The bus_space primitives are not guaranteed to boil down to "normal I/O primitives". The bus_space tag may well be keeping state so it can enforce ordering behind your back. Luckily, for most hardware out there,= nothing special is required. >There are errata everywhere and one who wants to provide reliable PCI >device driver for portable O/S must be aware on the erratas of the PCI >device and at least of the functionnal description of existing host >bridges when available (erratas will be a plus but aren't always >available). The way the CPU handles write buffers must also be considere= d, >especially when using MMIOs. Even a feature can become a bug, given all >that mess. So each driver author must reinvent the wheel here? That seems silly. Provided the OS provides a rich set of primitives and the author understa= nds when those primitives must be used, the end result is the same without duplicated code and complexity. When a new chipset with new bugs comes out, I don't want to touch all of the 100's of drivers in the system agai= n. I want to update one piece of code and have the rest benefit. >By the way, some constraints as the max size of scatter entries, the >clustering of scatter entries, not traversing some address boundary, etc= >..., when building a scatter list may affect performances and/or trigger= >erratas. I just wanted not to have to do the work twice, even if this ma= y >seem to possibly happen on Linux. In fact under Linux, scatter entries a= re >aligned on some nice address boundaries and you can tell the upper layer= >not to clusterize entries. = In FreeBSD, you can pick whatever boundary, alignment and S/G entry size constraints you want and bus dma will comply. If the knobs currently provided by the bus dma interface are not enough, then point them out so the interface can be improved. >Some O/S designed to be portable (but seems no longer to be so) got slow= >probably due to some infinite of epsilonish design and implementation >errors. I would be sad to ever see any free UNIX O/S to get NTified this= >way. Some O/Ses are designed to be large and difficult to maintain an understa= nd. It would be sad to see FreeBSD go in this direction. There are always tradeoffs in any designd... speed, code size, portability, maintainabilit= y, etc. Perhaps the tradeoffs in bus dma are not quite right (seeing as the= interface is still in flux, this wouldn't surprise me), but I'm not willi= ng to implicitly believe that abstractions cannot help in this situation. >AFAIR, in CAM3, the target peripheral driver can require disconnections = to >be used. In this situation the initiator must just be refused to be serv= ed >when it disallows disconnections. And if both target and initiator parts= >actually want to waste SCSI bandwitch, we just have to 'dont_care' and >behave as both parts did agree. In general practice you can't make this restriction. Often you are not in control of the code on the initiator. Many drivers/controllers will perform REQUEST SENSE operations without the disconnection privilege and you can't simply bail every time a REQUEST SENSE is performed. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 13: 6:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id C160F153B8 for ; Tue, 12 Oct 1999 13:06:43 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id OAA02497; Tue, 12 Oct 1999 14:07:03 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199910122007.OAA02497@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Randell Jesup Cc: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-reply-to: Your message of "12 Oct 1999 14:23:43 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Oct 1999 14:07:03 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Well, you could always punt and return an error in that case >(though it's very not-nice to do so). I assume the problem becomes >something like: command comes in with disconnect-disabled. You need >to page (or otherwise access a disk) to fufill the request. The disk >you need to access is on the same bus. Ooops. I forget if this was >explicitly considered in the CAM subcommittee discussions, or if it was >just felt that this was something that could not be dealt with. I wouldn't >be surprised if we thought about it and agreed that it was not solvable, >and that an error return was perfectly reasonable, and that in this >sort of situation reselect-enabled was VERY strongly advised. With resource reservation you can avoid the problem, but you need an interface for passing the resources to the peripheral driver handling the active transfer. In FreeBSD-CAM, where priority information is presented at the time a peripheral driver requests resources, we can simply pull the resources from a small pool for 'highest priority' requests. As neither CAM1 or 3 has the concept of scheduling for controller resources, there really isn't a clean way to deal with this. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 13:33:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 90C4314C0A for ; Tue, 12 Oct 1999 13:33:41 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-142.villette.club-internet.fr [194.158.116.142]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA20849; Tue, 12 Oct 1999 22:33:28 +0200 (MET DST) Date: Tue, 12 Oct 1999 22:55:19 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: <199910122003.OAA02480@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Justin, I cannot follow the entire discussion, since my english is not so fluently and I donnot have much time for that. I thanks you very much for the explanations, even if I am not actually convinced by all your arguments. Will just reply on a few points.=20 =20 On Tue, 12 Oct 1999, Justin T. Gibbs wrote: [ ... ] > >There are errata everywhere and one who wants to provide reliable PCI > >device driver for portable O/S must be aware on the erratas of the PCI > >device and at least of the functionnal description of existing host > >bridges when available (erratas will be a plus but aren't always > >available). The way the CPU handles write buffers must also be considere= d, > >especially when using MMIOs. Even a feature can become a bug, given all > >that mess. >=20 > So each driver author must reinvent the wheel here? That seems silly. > Provided the OS provides a rich set of primitives and the author understa= nds > when those primitives must be used, the end result is the same without > duplicated code and complexity. When a new chipset with new bugs comes > out, I don't want to touch all of the 100's of drivers in the system agai= n. > I want to update one piece of code and have the rest benefit. If the goal is to fix device bugs by generically castrating features and performances when bugs are suspected, then we just aren't on the same planet, and I agree that this can help a little.=20 Communism didn't work for politics, may-be it works for software. Who knows?. ;-) I just hope this will not lead to use truck wheels for bicycles or vice-versa. ;-) [ ... ] > >AFAIR, in CAM3, the target peripheral driver can require disconnections = to > >be used. In this situation the initiator must just be refused to be serv= ed > >when it disallows disconnections. And if both target and initiator parts > >actually want to waste SCSI bandwitch, we just have to 'dont_care' and > >behave as both parts did agree. >=20 > In general practice you can't make this restriction. Often you are not > in control of the code on the initiator. Many drivers/controllers will > perform REQUEST SENSE operations without the disconnection privilege and > you can't simply bail every time a REQUEST SENSE is performed. The disconnect priviledge applies in a per command manner. On a really usable system, REQUEST SENSE should not happen very frequently. So, it is just a no-issue. My concern was about the common case of data transfers not allowing disconnections for the corresponding transactions. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 14:51:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id B3DE514C8D for ; Tue, 12 Oct 1999 14:51:19 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA16124; Tue, 12 Oct 1999 23:51:00 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id XAA65212; Tue, 12 Oct 1999 23:40:14 +0200 (MET DST) (envelope-from j) Message-ID: <19991012234014.04359@uriah.heep.sax.de> Date: Tue, 12 Oct 1999 23:40:14 +0200 From: J Wunsch To: patl@phoenix.volant.org Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) Reply-To: Joerg Wunsch References: <19991012083509.43716@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from patl@phoenix.volant.org on Tue, Oct 12, 1999 at 12:24:54PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As patl@phoenix.volant.org wrote: > CDB: a 0 8 20 a 0 > asc 47,0 > write error: 2048 > parity error in vendor replacable unit 3 Hmm, that's a question to the SCSI experts here. If i read this correctly, it doesn't mean a parity error in the SCSI transport (which would be bad cabling etc., and which should cause a parity error _message_ in response), but rather a parity error inside the target, reported as an error _condition_ by the target. That's probably time to obtain the SCSI reference manual from Seagate and see for which exact condition they're reporting this error condition... Maybe it's easier to try reformatting the device first (which will cause bad block replacement to be performed). > > dd if=/dev/rsa1 of=/dev/null bs=64k > > Hmm. I tried dd'ing from /dev/zero to rda0; but not the other > way. (I assume you ment rda1, instead of rsa1 there. ...) Yes, this was a brain-o. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 15:31:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 24AAD14E7F for ; Tue, 12 Oct 1999 15:31:47 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 11bASP-0003RE-00; Tue, 12 Oct 1999 15:31:45 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id PAA29393; Tue, 12 Oct 1999 15:31:40 -0700 Date: Tue, 12 Oct 1999 15:31:40 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <19991012234014.04359@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Oct-99 at 14:52, J Wunsch (j@uriah.heep.sax.de) wrote: > As patl@phoenix.volant.org wrote: > > > CDB: a 0 8 20 a 0 > > asc 47,0 > > write error: 2048 > > parity error in vendor replacable unit 3 > > Hmm, that's a question to the SCSI experts here. If i read this > correctly, it doesn't mean a parity error in the SCSI transport (which > would be bad cabling etc., and which should cause a parity error > _message_ in response), but rather a parity error inside the target, > reported as an error _condition_ by the target. > > That's probably time to obtain the SCSI reference manual from Seagate > and see for which exact condition they're reporting this error > condition... Maybe it's easier to try reformatting the device first > (which will cause bad block replacement to be performed). It turned out to be cableing after all. The mostly-hidden-by-other- equipment 3' cable that came with the Exabyte turned out on examination to actually be a 2m cable. (Actually 2.05m measured from the tips of the pins) Add in the 3' cable to the disk, and the mandated fraction for each connector/device, and I wind up either right on or just over the maximum allowed cable length. A little creative equipment shuffling to allow the 2m cable to be replaced by another 3' cable; and all is well. I'd still like to find a disktab entry for the Barracuda 9 (ST-19171W). In particular, I'd like advice on the geometry settings. The boot-time probe reports it as: 8683MB (17783112 512 byte sectors: 64H 32 S/T 8683C) But the drive specs indicate 20 heads and only 17773440 sectors. (I won't bother with the track/cylinder count since it appears to vary the number of sectors per track.) I'm guessing that the extra 9672 sectors might be those reserved for bad-block replacement; and that the sector total reported on the Seagate spec page only counted 'user' sectors. (But it would be nice to have that confirmed by someone more knowlegable.) My real question is would I get any performance gain if I change the geometry to 20H to match the drive spec; or should I just leave it at 64H? What would be the potential disadvantages of changing it? Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 15:43:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 2B60C1514B for ; Tue, 12 Oct 1999 15:43:13 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id SAA14141; Tue, 12 Oct 1999 18:36:18 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910122007.OAA02497@caspian.plutotech.com> From: Randell Jesup Date: 12 Oct 1999 18:38:36 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 12 Oct 1999 14:07:03 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >>(though it's very not-nice to do so). I assume the problem becomes >>something like: command comes in with disconnect-disabled. You need >>to page (or otherwise access a disk) to fufill the request. The disk >>you need to access is on the same bus. Ooops. I forget if this was >With resource reservation you can avoid the problem, but you need an >interface for passing the resources to the peripheral driver handling >the active transfer. In FreeBSD-CAM, where priority information is >presented at the time a peripheral driver requests resources, we can >simply pull the resources from a small pool for 'highest priority' >requests. As neither CAM1 or 3 has the concept of scheduling for >controller resources, there really isn't a clean way to deal with this. I don't see how anything can work around selection-with-no- disconnection-allowed, if the data to respond to the command is on the same bus. The only solution would be to lock ALL code and data required to process it into RAM - tricky. Best solution is to not initiate to a processor device with reselect disabled. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 16:44:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id A06D915240 for ; Tue, 12 Oct 1999 16:44:30 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id RAA03158; Tue, 12 Oct 1999 17:45:03 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199910122345.RAA03158@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Randell Jesup Cc: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-reply-to: Your message of "12 Oct 1999 18:38:36 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Oct 1999 17:45:03 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I don't see how anything can work around selection-with-no- >disconnection-allowed, if the data to respond to the command is on >the same bus. The only solution would be to lock ALL code and data >required to process it into RAM - tricky. Best solution is to not >initiate to a processor device with reselect disabled. In this scenario you can return BUSY status. The scenario I want to avoid is that you have run out of controller resources to actually tell the controller to return BUSY status. There are controllers (like the aic7xxx chips) where having pending accept ccbs does not consume any controller resources, but outstanding continue target I/O or scsi I/O operations do. If you expend all of your resources on active, but disconnected, transactions and a selection without disconnect occurs, you are deadlocked if you can't ensure the peripheral driver that will handle the selection has controller resources to play with. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 17: 0: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 6B95614A15 for ; Tue, 12 Oct 1999 16:59:57 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA40430; Wed, 13 Oct 1999 09:29:50 +0930 (CST) Date: Wed, 13 Oct 1999 09:29:50 +0930 From: Greg Lehey To: Stefan Huerter Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: panic: vinvalbuf: dirty bufs Message-ID: <19991013092949.Q78191@freebie.lemis.com> References: <7Qhqy3MEoRB@subloch.medicusnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <7Qhqy3MEoRB@subloch.medicusnet.de> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 12 October 1999 at 9:10:00 +0200, Stefan Huerter wrote: > Guckux > > Running FreeBSD 3.3-STABLE > > from dmesg: > da2 at ahc0 bus 0 target 1 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled > da2: 1908MB (3907911 512 byte sectors: 64H 32S/T 1908C) > > I've recognized with FreeBSD 3.1 that this drive has problems with > taggings, so I reduced them. > > I encounterd with FB 3.2 problems with this drive. Upgraded to FB 3.3 I > checked it once more and get more problems. It is controlled from a > Adaptec 2940, I make a low level format with the Adaptec-Bios and check 3 > times via "verify disk media" with no problems. > When I make a "newfs -i 8192" (with tagging disabled through camcontrol > command) there will be a few superblocks written out, then newfs will stop > (no screen-output anymore), the drive scratches a little bit and then I > get following: > panic: vinvalbuf: dirty bufs > > any chance to get it working back? or is it really damaged? This panic happens when a device is being closed and for some reason the open buffers can't be written to disk. If it happens in the middle of newfs, it suggests that the drive had an I/O error of some kind which prevented data from being written during close. A dump would be really helpful. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 21: 3:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by hub.freebsd.org (Postfix) with ESMTP id B12F314C18 for ; Tue, 12 Oct 1999 21:03:15 -0700 (PDT) (envelope-from igiveup@ix.netcom.com) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id XAA05908 for ; Tue, 12 Oct 1999 23:03:07 -0500 (CDT) Received: from stl-wa42-08.ix.netcom.com(207.220.45.136) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma005587; Tue Oct 12 23:02:20 1999 Message-ID: <38040444.1CE0B1DC@ix.netcom.com> Date: Tue, 12 Oct 1999 21:02:12 -0700 From: Ben Speirs X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Reading on Wide and Narrow channels = wide channel slows down? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been debugging some hardware problems after I got a "unexpected busfree" message. I think I have narrowed it down to my 24X Toshiba CD-ROM. During my debug I noticed that when I do a dd if=/dev/rda0 of=/dev/null bs=40k systat shows a 9MB/s throughput from my 4GB Fujitsu drive (da0). If I add a dd if=/dev/rcd0c of=/dev/null bs=8k to read from my 3X NEC CD-ROM, systat reports that the throughput drops to below 1 MB/s on da0. The CD-ROM has a higher throughput than the fast hard drive. What gives? Is this normal? Thanks for sharing your wisdom. Oh, FYI, I'm using an adaptec 2940UW PCI controller. -- -Ben Speirs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 12 23: 2: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 764E414C3A for ; Tue, 12 Oct 1999 23:01:54 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA21702; Wed, 13 Oct 1999 08:01:44 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id HAA67353; Wed, 13 Oct 1999 07:53:45 +0200 (MET DST) (envelope-from j) Message-ID: <19991013075344.47656@uriah.heep.sax.de> Date: Wed, 13 Oct 1999 07:53:44 +0200 From: J Wunsch To: patl@phoenix.volant.org Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) Reply-To: Joerg Wunsch References: <19991012234014.04359@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from patl@phoenix.volant.org on Tue, Oct 12, 1999 at 03:31:40PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As patl@phoenix.volant.org wrote: > I'd still like to find a disktab entry for the Barracuda 9 (ST-19171W). > In particular, I'd like advice on the geometry settings. The boot-time > probe reports it as: > > 8683MB (17783112 512 byte sectors: 64H 32 S/T 8683C) > > But the drive specs indicate 20 heads and only 17773440 sectors. (I > won't bother with the track/cylinder count since it appears to vary > the number of sectors per track.) You should not bother with either number at all. If you want a disk that's only there for FreeBSD, use "disktab -Bw da1 auto" to get a label that covers all the 17783112 blocks. However, due to the way newfs (and cylindergroups etc.) is working, there'll always be some wasted sectors at the end of a filesystem. OTOH, what's something like wasted 5 MB, compared to 8 GB total capacity? > My real question is would I get any performance gain if I change the > geometry... No. The default setup of newfs ignores geometry data to the best level that is possible, considering the underlying UFS technology that is somewhat aged already, and that's usually the best performance you'd get with a modern drive. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 8:29:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 318C814A28 for ; Wed, 13 Oct 1999 08:29:25 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id LAA09439; Wed, 13 Oct 1999 11:22:32 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910122345.RAA03158@caspian.plutotech.com> From: Randell Jesup Date: 13 Oct 1999 11:22:35 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 12 Oct 1999 17:45:03 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >In this scenario you can return BUSY status. The scenario I want to >avoid is that you have run out of controller resources to actually >tell the controller to return BUSY status. There are controllers >(like the aic7xxx chips) where having pending accept ccbs does >not consume any controller resources, but outstanding continue target >I/O or scsi I/O operations do. Really? > If you expend all of your resources >on active, but disconnected, transactions and a selection without >disconnect occurs, you are deadlocked if you can't ensure the peripheral >driver that will handle the selection has controller resources to play >with. Which resources are those? This seems very strange to me - I can't imagine what resources would be required in order to return BUSY that might not be available. Even if that's true, it sounds like a problem with the driver design. Thanks for the info though; I never would have expected that a driver might _not_ be able to return BUSY... -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 9: 4:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.217.82.22]) by hub.freebsd.org (Postfix) with ESMTP id DF8A715371 for ; Wed, 13 Oct 1999 09:04:28 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id RAA49379 for freebsd-scsi@freebsd.org; Wed, 13 Oct 1999 17:04:26 +0100 (BST) (envelope-from geoffb) Date: Wed, 13 Oct 1999 17:04:26 +0100 From: Geoff Buckingham To: freebsd-scsi@freebsd.org Subject: DPT PM2144W hangs on detection Message-ID: <19991013170426.A49338@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a PM2144W wide controller without the daughter board connected to the PCI like interface at the back of the card when booting FreeBSD from IDE disks on a P90 the system hangs after detecting the card, is this a PCI problem or a result of the missing daugter board? -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 9:42:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4AC73152DF for ; Wed, 13 Oct 1999 09:42:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA26011 for ; Wed, 13 Oct 1999 09:42:11 -0700 Date: Wed, 13 Oct 1999 09:42:10 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org Subject: FW: 99-233r2 - SAM-2 TASK SET FULL Clarifications (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Very appropros of the recent discussions. ---------- Forwarded message ---------- Date: Wed, 13 Oct 1999 09:39:23 -0400 From: "Peterson, Gary" To: "'t10@t10.org'" Subject: FW: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Peterson, Gary" * I agreee with Dan - Although a BUSY respsonse is a catch-all for many situations, it does free the initiator or retry at his convenience (i.e. after a 'short' delay). The TASK SET FULL should be used when the target is unable to accept the command from that initator at that time, where another initiator might be able to get a command through. I would think the initiator would then wait for a current outstanding command to return before attempting it again. Also, I don't follow Tom's comment of noticable overhead -- returning either status is equally as fast, isn't it? ---------------------------------------------------------------------- Gary S. Peterson CLARiiON Storage Systems (An EMC Business Unit) Phone: 508/480-7150 FAX: 508/480-7913 EMail: gpeterson@clariion.com -----Original Message----- From: Coughlan, Tom [mailto:Tom.Coughlan@COMPAQ.com] Sent: Wednesday, October 13, 1999 8:51 AM To: Lewis, Dan; 't10@t10.org' Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Coughlan, Tom" * Dan, I did not intend to equate Task Set Full with Busy. (I was saying that generating either one can require a noticeable amount of overhead in the FC target.) I don't think there is wide-spread agreement with your view that the initiator should delay after receiving Busy status. The reason is because Busy is something of a catch-all status that includes conditions not related to congestion. Examples include contingent allegiance with another initiator, or the device is busy on another port. The initiator can justifiably re-issue the command after a very short delay in these cases. Given the current non-specificity of the standard, I think we have to assume that initiators interpret Busy as "retry with little or no delay", and Task Set Full as "retry after a delay that is adequate for the target to clear the congestion". Eventually I think the standard should specify the Task Set Full backoff policy, and the policy should also require the initiator to reduce the number of commands outstanding to the logical unit, and implement a gradual ramp-up. Tom -----Original Message----- From: Lewis, Dan [mailto:DLewis@clariion.com] Sent: Tuesday, October 12, 1999 6:55 PM To: Coughlan, Tom; 't10@t10.org' Cc: 'ralphoweber@CompuServe.COM'; Elliott, Robert (Hou) Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications * From the T10 Reflector (t10@t10.org), posted by: * "Lewis, Dan" * Tom, regarding this new restriction, I don't believe it weakens the only method we have for congestion control because Task Set Full is not the *only* method. Somewhere in your message, you casually equate Task Set Full with Busy. I think there is a profound difference. The way I see it, an initiator that receives Busy status should recognize this to mean that the target is congested AND should re-issue the operation after some (arbitrary) delay. But when an initiator receives Task Set Full, that means *that initiator* has reached a water mark that the target does not want it to exceed. This judgement by the target can vary from one implementation to another, but the initiator can be sure that re-issuing the operation after one of it's tasks has completed is the right policy. -Dan Lewis- > -----Original Message----- > From: Coughlan, Tom [mailto:Tom.Coughlan@COMPAQ.com] > Sent: Tuesday, October 12, 1999 5:07 PM > To: 't10@t10.org' > Cc: 'ralphoweber@CompuServe.COM'; Elliott, Robert (Hou) > Subject: RE: 99-233r2 - SAM-2 TASK SET FULL Clarifications > > > * From the T10 Reflector (t10@t10.org), posted by: > * "Coughlan, Tom" > * > The latest revision of 99-233 creates a new restriction on > logical units, > allowing them to return Task Set Full to an initiator only if there is > already a task in the task set from that initiator. I believe this > restriction is a bad idea, because it weakens the only method > we have for > congestion control, and congestion control is much more > important for the > operation of large SANs than the goals of this proposal. > > I think there is a consensus that the logical unit sends Task Set Full > status to indicate that it is congested, and that the receipt of any > additional work while it is in this state will be > counter-productive. If > initiators continue to send task requests, the logical unit may become > consumed with returning failure status, and will be unable to make any > progress on its backlog. I've been told that some FC > implementations are > particularly prone to this scenario, because the number of > open exchanges > they support is fairly small, and the amount of processing required to > return a Task Set Full (or Busy) is fairly high. > > We need two things to be able to control congestion: 1) the > logical unit > must return Task Set Full to any initiator that issues a task > while the > logical unit is congested, and 2) all initiators must observe > an adequate > backoff when they receive the Task Set Full status. If we > restrict the > logical unit's ability to return Task Set Full, then we are > likely to create > scenarios where congestion can persist for extended periods of time, > resulting in low efficiency and the possibility of command timeouts. > > A second problem with the proposal is that it can be very difficult to > implement in some designs. In the FC example described > above, for example, > the congestion is in the target, not the logical unit. With > the proposed > behavior, the congested target must conditionalize its > behavior on the state > of the logical unit's task set. This is awkward to implement > and consumes > scarce processing time. > > The original goal of proposal 99-233 was to prevent the Task > Set Full status > from being returned to an initiator that does not implement > tagged queuing. > Along the way, this proposal picked up a second goal, namely, > to encourage > initiators to implement a particular backoff policy. The > favored policy is > "if you get a Task Set Full then wait for at least one of > your tasks to > complete before issuing a new task". > > I do not agree with the original goal, because I think that managing > congestion is much more important than allowing initiator > implementations > that do not understand Task Set Full. As I have said, this > is fundamental > to large multi-initiator SANs. > > I do not agree with the second goal, because 1) I have not > seen evidence > that this backoff policy is the best for controlling congestion while > maintaining fairness, 2) any initiator worth its salt already > knows how many > tasks it has issued to the logical unit, 3) no initiator that > will be used > in the open market can rely on a restriction that has been so > recently added > to the standard, and 4)the difficulty of implementing this in > some initiator > designs is greater than the benefit gained. > > I recommend a change to the original text (contained in the attached > message) as follows: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > be returned when the logical unit receives a task and does not > have enough resources to enter the task in the task set. The logical > unit shall return this status regardless of whether the task > is tagged or untagged. It is strongly recommended that the initiator > perform a delay before issuing or re-issuing a task to this > logical unit. > > Tom Coughlan > OpenVMS SCSI & FC Project Leader > Compaq Computer Corporation > 110 Spit Brook Rd. ZKO3-4/U14 > Nashua, New Hampshire 03062-2698 > Phone: 603-884-0933 > Fax.: 603-884-0189 > Mail: tom.coughlan@compaq.com > > -----Original Message----- > From: Ralph Weber [SMTP:ralphoweber@CompuServe.COM] > Sent: Sunday, September 19, 1999 2:58 PM > To: T10, Reflector > Subject: 99-233r2 - SAM-2 TASK SET FULL Clarifications > > * From the T10 Reflector (t10@t10.org), posted by: > * Ralph Weber > * > A proposal for consideration at the November meetings has > been placed on the T10 FTP site as: > > < ftp://ftp.t10.org/t10/document.99/99-233r2.pdf > > > The text of the proposal is as follows. Underline and strikeout > formatting has been removed for ASCII text compatibility. See the > PDF for a fully formatted presentation of the proposal. > > Doc: T10/99-233r2 > Date: 17 September 1999 > To: T10 Technical Committee > From: Ralph Weber, LSI Logic Alternate Member of T10 > Subj: SAM-2 TASK SET FULL Clarifications > > During the May General SCSI Working Group meeting I was asked to > investigate the SAM-2 definition of the TASK SET FULL status. The > results of this investigation and proposed changes were reviewed and > enhanced by the July Working Group meeting. > > After reviewing the proposal twice at the September General SCSI > Working Group meeting, I believe that the changes shown with > strikeouts and underlines below may be acceptable. Please review and > comment, if sufficient comments are received before the November > meeting, I'll revise the proposal again. Also, discussion of 99-232 > has been removed since that proposal has been approved. > > The problem is that the definition of the TASK SET FULL status (5.2) > does not state whether it can be returned for untagged tasks. The > following proposed changes reflect the majority sentiment of the July > Working Group. > > Old text: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > be returned when the logical unit receives a command and does not > have enough resources to enter the associated task in the task set. > > New text minus strikeouts and underlines: > > TASK SET FULL. This status shall be implemented if the logical unit > supports the creation of tagged tasks (see 4.9). This status shall > not be implemented if the logical unit does not support the creation > of tagged tasks. When the logical unit has at least one tagged task > in the task set from an initiator and that same initiator sends a > task that cannot be entered in the task set due to a lack of task set > resources, TASK SET FULL shall be returned, otherwise BUSY shall be > returned. > > Note: Receipt of a second untagged task from the same initiator is an > error case covered in 5.6.2. > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 11:11:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id B3AD615289 for ; Wed, 13 Oct 1999 11:11:05 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id MAA04294; Wed, 13 Oct 1999 12:11:38 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199910131811.MAA04294@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Randell Jesup Cc: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-reply-to: Your message of "13 Oct 1999 11:22:35 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Oct 1999 12:11:38 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >"Justin T. Gibbs" writes: >>In this scenario you can return BUSY status. The scenario I want to >>avoid is that you have run out of controller resources to actually >>tell the controller to return BUSY status. There are controllers >>(like the aic7xxx chips) where having pending accept ccbs does >>not consume any controller resources, but outstanding continue target >>I/O or scsi I/O operations do. > > Really? Sure. If your target role is idle, why would you want to have it prevent your initiator role from running at full capacity? >> If you expend all of your resources >>on active, but disconnected, transactions and a selection without >>disconnect occurs, you are deadlocked if you can't ensure the peripheral >>driver that will handle the selection has controller resources to play >>with. > > Which resources are those? The equivalent of CCB resources. You usually have a fixed number of transactions you can queue to the card. >This seems very strange to me - I >can't imagine what resources would be required in order to return BUSY >that might not be available. Even if that's true, it sounds like a problem >with the driver design. If the accept occurs when all resources are consumed, sure, you know to return busy. But that need not be the case. It could be that you receive the command from the initiator, ship it off to your peripheral driver, and by the time it can respond, other peripheral drivers have queued work that will take all of your resources. Since FreeBSD-CAM imposes a scheduling for resources, and the XPT knows the total number of resources you have, the peripheral driver you really want to have a resource doesn't happen to get it. The result is deadlock. To avoid this, the peripheral driver needs to understand that it should raise its response to the highest priority level so it is guaranteed to get a resource. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 11:11:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 8ED2915365 for ; Wed, 13 Oct 1999 11:11:17 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA01180; Wed, 13 Oct 1999 20:07:30 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA01067; Wed, 13 Oct 1999 20:07:42 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910131807.UAA01067@yedi.iaf.nl> Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: <19991012234014.04359@uriah.heep.sax.de> from J Wunsch at "Oct 12, 1999 11:40:14 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 13 Oct 1999 20:07:42 +0200 (CEST) Cc: patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As J Wunsch wrote ... > As patl@phoenix.volant.org wrote: > > > CDB: a 0 8 20 a 0 > > asc 47,0 That is the ASC/ASCQ which mean: "SCSI parity error" (hurrah..) > > write error: 2048 > > parity error in vendor replacable unit 3 Sounds like a drive hardware error to me. W/ -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 11:11:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 673BB15372 for ; Wed, 13 Oct 1999 11:11:17 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA01183; Wed, 13 Oct 1999 20:07:36 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00952; Wed, 13 Oct 1999 19:57:04 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910131757.TAA00952@yedi.iaf.nl> Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: <19991013075344.47656@uriah.heep.sax.de> from J Wunsch at "Oct 13, 1999 7:53:44 am" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 13 Oct 1999 19:57:04 +0200 (CEST) Cc: patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As J Wunsch wrote ... > As patl@phoenix.volant.org wrote: ... > > My real question is would I get any performance gain if I change the > > geometry... > > No. The default setup of newfs ignores geometry data to the best > level that is possible, considering the underlying UFS technology that > is somewhat aged already, and that's usually the best performance > you'd get with a modern drive. Modern drives don't have a constant nr sectors/track. The outside cylinders have more sec/track than the inner cylinders. So there is no such things as *the* geometry anymore. UFS is from the days that this concept was not yet used. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 12: 4:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 631E614ECD for ; Wed, 13 Oct 1999 12:04:50 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id PAA02031; Wed, 13 Oct 1999 15:04:43 -0400 (EDT) Date: Wed, 13 Oct 1999 15:04:43 -0400 (EDT) From: "Matthew N. Dodd" To: Geoff Buckingham Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT PM2144W hangs on detection In-Reply-To: <19991013170426.A49338@chuggalug.clues.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Oct 1999, Geoff Buckingham wrote: > I have a PM2144W wide controller without the daughter board connected > to the PCI like interface at the back of the card when booting FreeBSD > from IDE disks on a P90 the system hangs after detecting the card, is > this a PCI problem or a result of the missing daugter board? Can you boot verbose and include the output in your email that describes the system in more detail? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 12:34:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 65B8B14BED for ; Wed, 13 Oct 1999 12:34:52 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA27026; Wed, 13 Oct 1999 12:34:29 -0700 Date: Wed, 13 Oct 1999 12:34:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: joerg_wunsch@uriah.heep.sax.de, patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: <199910131807.UAA01067@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not necessarily. Parity errors are usually cable or termpwr/fuse related issues. On Wed, 13 Oct 1999, Wilko Bulte wrote: > As J Wunsch wrote ... > > As patl@phoenix.volant.org wrote: > > > > > CDB: a 0 8 20 a 0 > > > asc 47,0 > > That is the ASC/ASCQ which mean: "SCSI parity error" (hurrah..) > > > > write error: 2048 > > > parity error in vendor replacable unit 3 > > Sounds like a drive hardware error to me. > > W/ > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 13:10:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id D946B14FCD for ; Wed, 13 Oct 1999 13:10:50 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id QAA21571; Wed, 13 Oct 1999 16:04:01 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910131811.MAA04294@caspian.plutotech.com> From: Randell Jesup Date: 13 Oct 1999 16:06:16 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 13 Oct 1999 12:11:38 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >>> If you expend all of your resources >>>on active, but disconnected, transactions and a selection without >>>disconnect occurs, you are deadlocked if you can't ensure the peripheral >>>driver that will handle the selection has controller resources to play >>>with. >> >> Which resources are those? > >The equivalent of CCB resources. You usually have a fixed number of >transactions you can queue to the card. Aha... >>This seems very strange to me - I >>can't imagine what resources would be required in order to return BUSY >>that might not be available. Even if that's true, it sounds like a problem >>with the driver design. > >If the accept occurs when all resources are consumed, sure, you know to return >busy. But that need not be the case. It could be that you receive the command >from the initiator, ship it off to your peripheral driver, and by the time it >can respond, other peripheral drivers have queued work that will take all of >your resources. Aha. That makes some more sense. > Since FreeBSD-CAM imposes a scheduling for resources, and >the XPT knows the total number of resources you have, the peripheral driver >you really want to have a resource doesn't happen to get it. The result is >deadlock. To avoid this, the peripheral driver needs to understand that >it should raise its response to the highest priority level so it is guaranteed >to get a resource. I'll need to look at the FreeBSD-CAM/XPT. None of the driver designs I've ever done have had any inherent limitations on the number of active requests (other than physical memory). I wonder if the XPT (or SIM) could reserve resources for target-mode driver responses... Part of the problem is not understanding FreeBSD's XPT's resource-allocation code. I think I really need to start looking at the code; perhaps this weekend. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 15:10:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B115D15244 for ; Wed, 13 Oct 1999 15:10:31 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA09129; Wed, 13 Oct 1999 22:53:50 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA10169; Wed, 13 Oct 1999 21:50:11 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910131950.VAA10169@yedi.iaf.nl> Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: from Matthew Jacob at "Oct 13, 1999 12:34:28 pm" To: mjacob@feral.com Date: Wed, 13 Oct 1999 21:50:11 +0200 (CEST) Cc: joerg_wunsch@uriah.heep.sax.de, patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > Not necessarily. Parity errors are usually cable or termpwr/fuse related > issues. But then the drive generally does not mumble around vendor replacable units. > > > > That is the ASC/ASCQ which mean: "SCSI parity error" (hurrah..) > > > > > > write error: 2048 > > > > parity error in vendor replacable unit 3 > > > > Sounds like a drive hardware error to me. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 15:23:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id C0B14150D6 for ; Wed, 13 Oct 1999 15:23:08 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-172-155.villette.club-internet.fr [195.36.172.155]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA29257; Thu, 14 Oct 1999 00:22:55 +0200 (MET DST) Date: Thu, 14 Oct 1999 00:44:50 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Randell Jesup Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Oct 1999, Randell Jesup wrote: > "Justin T. Gibbs" writes: [ ... ] > >If the accept occurs when all resources are consumed, sure, you know to = return > >busy. But that need not be the case. It could be that you receive the = command > >from the initiator, ship it off to your peripheral driver, and by the ti= me it > >can respond, other peripheral drivers have queued work that will take al= l of > >your resources. >=20 > =09Aha. That makes some more sense. >=20 > > Since FreeBSD-CAM imposes a scheduling for resources, and > >the XPT knows the total number of resources you have, the peripheral dri= ver > >you really want to have a resource doesn't happen to get it. The result= is > >deadlock. To avoid this, the peripheral driver needs to understand that > >it should raise its response to the highest priority level so it is guar= anteed > >to get a resource. >=20 > =09I'll need to look at the FreeBSD-CAM/XPT. None of the driver > designs I've ever done have had any inherent limitations on the number of > active requests (other than physical memory). I wonder if the XPT (or SI= M) > could reserve resources for target-mode driver responses... Part of the > problem is not understanding FreeBSD's XPT's resource-allocation code. I > think I really need to start looking at the code; perhaps this weekend. CAM requires SIM to accept any number of requests from peripheral drivers. There is no status SIM can return on internal resource shortage.= =20 For HBAs (or SIM design) that require a limited number of requests queued to the controller (or devices), the SIM has to maintain in memory a queue of not yet actually queued IOs. All the logical device IO=20 queueing/freezing is to be performed by SIM. On this point, FreeBSD-CAM is _very_ different from CAM. Justin preferred to handle all queuing from memory in the XPT. SIMs indicates the maximum number of outstanding IOs they can handle to XPT. This allows SIMs not to have to handle queues in memory and allows peripheral drivers (and/or XPT)= =20 to implement some sophisticated scheduling any SIM will never want to provide. Such an approach has advantages and disadvantages. I have exchanged several mails with Justin about this topic. Being different from CAM does not mean being not as good as CAM (or worse in essence :) ). I noticed the differences, but donnot have any preferences. I just would have designed the sym_hipd driver differently if the logical device queue handling has had to be performed by SIM. Btw, FreeBSD-CAM looks quite fine to me. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 15:42:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CFAF5153C5 for ; Wed, 13 Oct 1999 15:42:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA27380; Wed, 13 Oct 1999 13:55:20 -0700 Date: Wed, 13 Oct 1999 13:55:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randell Jesup Cc: scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'll need to look at the FreeBSD-CAM/XPT. None of the driver > designs I've ever done have had any inherent limitations on the number of > active requests (other than physical memory). I wonder if the XPT (or SIM) > could reserve resources for target-mode driver responses... Part of the > problem is not understanding FreeBSD's XPT's resource-allocation code. I > think I really need to start looking at the code; perhaps this weekend. > The CAM target mode model is in fact also what the Qlogic f/w uses for target mode. You in fact instruct the f/w about the number of both immediate notification as well as command resources to reserve- usually on a per-lun basis. This allows the f/w to handle flow control for you without even being interrupted. But this isn't always enabled- for example the SCCLUN (16 bit first level lun) mode for the Fibre Channel card just punts this all to the driver level- the f/w is not going to attempt to resource manage 65K worth of luns... I may have misunderstood Justin in some email about 2-3 weeks ago- but if I didn't, I don't agree with him. I also feel that for the amount of infrastructure resources (CCBs) you *should* in fact pre-allocate at least for the case of being able to say "no, I'm busy...". I believe that the current CAM implementation for FreeBSD attempts to size the CCB free pool size based upon the HBA's 'max openings' quantity- but this is probably wrong in three respects. First, it can't account for race conditions between being done with a CCB but the CCB isn't yet freed (because the thread that does completions hasn't run yet), so the pool should be a bit larger to account for this. Second, this doesn't account for the non-command specific CCBs that are always being used like PATH_INQUIRY and so on. Third, it also doesn't account for the load imposed by handling *both* target and initiator mode which may have the same 'max openings' limit, or twice that, or something completely different. In any case, there are two major strategic choices for this kind of resource allocation. One is a general pool (which is what is there now) that attempts to (re)size itself based upon expected load based upon the number of HBAs attached. If you support Target Mode as well, then I suppose you could call directly into the XPT framework and ask it to resize itself upwards as needed. The other choice is to make the HBAs (sim layer) responsible for CCB allocation for both initiator and target commands. This is a mechanism akin to streams head or mbuf head allocators that have been used very effectively for years in some platforms- the actual code that drives the device is the one most likely to know the 'right' amount to allocate. On the other hand, this makes it difficult for CAM which does all the queue management and scheduling. For either case, you still cannot entirely guarantee that you won't run out of some kind of system resource at an inconvenient time, so you still have to design for that eventuality. My own choice in these matters (for a Solaris implementation that is now being moved into my *BSD/Linux Qlogic drivers) is reserve enough *local* resource for the driver so that if the requisite platform resources (CCBs for FreeBSD, DDI dma mapping resources in Solaris) aren't available, I can turn around and complete an incoming command right away with QFull. It does make some of the code a bit ugly because a check has to be made as to whether this is a private or a public command, but it means I'll never get caught short. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 15:42:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7360515426 for ; Wed, 13 Oct 1999 15:42:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA27542; Wed, 13 Oct 1999 14:28:20 -0700 Date: Wed, 13 Oct 1999 14:28:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: joerg_wunsch@uriah.heep.sax.de, patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: <199910131950.VAA10169@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unless the FRU is a fuse. or the drive itself. On Wed, 13 Oct 1999, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > > > Not necessarily. Parity errors are usually cable or termpwr/fuse related > > issues. > > But then the drive generally does not mumble around vendor replacable units. > > > > > > > That is the ASC/ASCQ which mean: "SCSI parity error" (hurrah..) > > > > > > > > write error: 2048 > > > > > parity error in vendor replacable unit 3 > > > > > > Sounds like a drive hardware error to me. > > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 13 16:36: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.217.82.22]) by hub.freebsd.org (Postfix) with ESMTP id 3EC4C14ED4 for ; Wed, 13 Oct 1999 16:35:45 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id AAA50170; Thu, 14 Oct 1999 00:35:29 +0100 (BST) (envelope-from geoffb) Date: Thu, 14 Oct 1999 00:35:29 +0100 From: Geoff Buckingham To: "Matthew N. Dodd" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT PM2144W hangs on detection Message-ID: <19991014003529.A49420@chuggalug.clues.com> References: <19991013170426.A49338@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matthew N. Dodd on Wed, Oct 13, 1999 at 03:04:43PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 13, 1999 at 03:04:43PM -0400, Matthew N. Dodd wrote: > On Wed, 13 Oct 1999, Geoff Buckingham wrote: > > I have a PM2144W wide controller without the daughter board connected > > to the PCI like interface at the back of the card when booting FreeBSD > > from IDE disks on a P90 the system hangs after detecting the card, is > > this a PCI problem or a result of the missing daugter board? > > Can you boot verbose and include the output in your email that describes > the system in more detail? > Not ATM as I now have that system running on adaptec card, I will post more info next time I have a system to play with, my question should perhaps have been does anybody have a PM2144W working without the add on board. -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 7:53:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlas.rccn.net (atlas.rccn.net [193.136.7.1]) by hub.freebsd.org (Postfix) with SMTP id 619A614DC0 for ; Thu, 14 Oct 1999 07:53:13 -0700 (PDT) (envelope-from jpsp@rccn.net) Received: (qmail 32089 invoked by uid 1021); 14 Oct 1999 14:53:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Oct 1999 14:53:13 -0000 Date: Thu, 14 Oct 1999 15:53:13 +0100 (WEST) From: Joao Pagaime To: scsi@freebsd.org Subject: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all I have a very slow Pentium III/450 with 512MB RAM because disks tranfers are slow. Simple tests show a transfer rate of +/- 2MB/sec, when a PC with IDE can do easily at least 4 times that value. I think the problem is with the "Common Access Method" in the backplane, because although the controllers are found with no problem : ahc0: rev 0x00 int a irq 11 on pci2.4.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x03 int a irq 11 on pci2.6.0 ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs The backplane is reported as having only 3.3 MB transfer rate : pass2 at ahc0 bus 0 target 6 lun 0 pass2: Fixed Processor SCSI-2 device pass2: 3.300MB/s transfers Did anyone experience the same problem ? Can someone help me ? Any hints ? Any configurarion at the CAM level ? - I configured the kernel to debug CAM but I can only reboot the machine in a few hours... Thanks, Joao Pagaime PS: the disks are also reporter correctly : da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) And here are a few miserable tests : Sparc Entreprise 1000 - very old : time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out real 0m22.640s user 0m0.055s sys 0m16.094s Dell PowerEdge 4300 (http://www.dell.com/products/poweredge/pe4300/index.htm) time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out 100000000 bytes transferred in 53.853144 secs (1856902 bytes/sec) real 0m55.553s user 0m0.001s sys 0m1.562s This makes very unhappy users ! thank again, -- FCCN - Fundacao para a Computacao Cientifica Nacional - Tel: 351-1-8440100 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 7:55:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from europe.std.com (europe-e.std.com [192.74.137.10]) by hub.freebsd.org (Postfix) with ESMTP id BEFAE15075 for ; Thu, 14 Oct 1999 07:55:49 -0700 (PDT) (envelope-from cmascott@world.std.com) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAB19948 for ; Thu, 14 Oct 1999 10:55:46 -0400 (EDT) Received: (from cmascott@localhost) by world.std.com (8.9.3/8.9.3) id KAA01285 for freebsd-scsi@freebsd.org; Thu, 14 Oct 1999 10:53:35 -0400 (EDT) Date: Thu, 14 Oct 1999 10:53:35 -0400 (EDT) From: Carl Mascott Message-Id: <199910141453.KAA01285@world.std.com> To: freebsd-scsi@freebsd.org Subject: Does 3.3-R support Adaptec AVA-2906? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does FreeBSD 3.3-R support the Adaptec AVA-2906 SCSI host adapter? It's not listed in the Release Notes, but it seems to use the same ASPI family manager under DOS/Windows as does the 2940, which is encouraging. Please e-mail me directly. Thanks! -- Carl Mascott cmascott@world.std.com uunet!world!cmascott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 8: 3:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 5422914F6B for ; Thu, 14 Oct 1999 08:03:33 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11bkvT-0002xA-00; Thu, 14 Oct 1999 06:28:11 -0700 Date: Thu, 14 Oct 1999 06:28:09 -0700 (PDT) From: Tom To: Joao Pagaime Cc: scsi@freebsd.org Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Oct 1999, Joao Pagaime wrote: > Hi all > > I have a very slow Pentium III/450 with 512MB RAM > because disks tranfers are slow. > > Simple tests show a transfer rate of +/- 2MB/sec, > when a PC with IDE can do easily at least 4 times > that value. > > I think the problem is with the "Common Access Method" > in the backplane, because although the controllers are > found with no problem : What backplane? > ahc0: rev 0x00 int a irq 11 on > pci2.4.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc1: rev 0x03 int a irq 11 on pci2.6.0 > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > The backplane is reported as having only 3.3 MB transfer rate : > > pass2 at ahc0 bus 0 target 6 lun 0 > pass2: Fixed Processor SCSI-2 device > pass2: 3.300MB/s transfers That isn't a backplane. That looks like some kind of special SCSI device on your chain. Perhaps it is a backplane status reporting device of some sort. But it is not the backplane itself. > Did anyone experience the same problem ? > Can someone help me ? > Any hints ? > Any configurarion at the CAM level ? - I configured the kernel > to debug CAM but I can only reboot the machine in a few > hours... > > Thanks, > Joao Pagaime > > PS: the disks are also reporter correctly : > > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) These wouldn't be Western Digital Enterprise drives would they? They are very poor drives. There are some messages in the archives that you need to disable some features on them in order to get the performance up to a reasonable level. Also, make sure you have a spare. They have a tendency to die too. Usually in the 6months to 1year range. > And here are a few miserable tests : > > > Sparc Entreprise 1000 - very old : ... But they use some rather nice Seagate drives. As I recall. I belive that Sun uses only Seagate in all their higher lines. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 8:35:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlas.rccn.net (atlas.rccn.net [193.136.7.1]) by hub.freebsd.org (Postfix) with SMTP id BE91314C27 for ; Thu, 14 Oct 1999 08:35:45 -0700 (PDT) (envelope-from jpsp@rccn.net) Received: (qmail 33416 invoked by uid 1021); 14 Oct 1999 15:35:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Oct 1999 15:35:44 -0000 Date: Thu, 14 Oct 1999 16:35:44 +0100 (WEST) From: Joao Pagaime To: Tom Cc: scsi@freebsd.org Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the response! Sorry if I read a little strange, but I'm no SCSI specialist. However Dell does refer in the manuals to the board where the disks plug into as "backplane". Probably this isn't the rigth nomenclature. I think the server has a RAID option - with a different "backplane" - that we didn't purchase. In all cases I'm stuck with that board, because the disks draw power from it - signaling/data and power in the same SCSI interface (I'm sure that has a simple name for that...) I'm not even sure if I can connect that "backplane" to a normal SCSI controller (like an SCSI Card 2940U2W) because the architecture seems very proprietary... The disk optimization is a 'must' then... From 2 MB/s to something close to 80 takes a great deal of optimization. Thanks, Joao Pagaime -- FCCN - Fundacao para a Computacao Cientifica Nacional - Tel: 351-1-8440100 On Thu, 14 Oct 1999, Tom wrote: > > On Thu, 14 Oct 1999, Joao Pagaime wrote: > > > Hi all > > > > I have a very slow Pentium III/450 with 512MB RAM > > because disks tranfers are slow. > > > > Simple tests show a transfer rate of +/- 2MB/sec, > > when a PC with IDE can do easily at least 4 times > > that value. > > > > I think the problem is with the "Common Access Method" > > in the backplane, because although the controllers are > > found with no problem : > > What backplane? > > > ahc0: rev 0x00 int a irq 11 on > > pci2.4.0 > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > ahc1: rev 0x03 int a irq 11 on pci2.6.0 > > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > > > The backplane is reported as having only 3.3 MB transfer rate : > > > > pass2 at ahc0 bus 0 target 6 lun 0 > > pass2: Fixed Processor SCSI-2 device > > pass2: 3.300MB/s transfers > > That isn't a backplane. That looks like some kind of special SCSI > device on your chain. Perhaps it is a backplane status reporting device > of some sort. But it is not the backplane itself. > > > Did anyone experience the same problem ? > > Can someone help me ? > > Any hints ? > > Any configurarion at the CAM level ? - I configured the kernel > > to debug CAM but I can only reboot the machine in a few > > hours... > > > > Thanks, > > Joao Pagaime > > > > PS: the disks are also reporter correctly : > > > > da1 at ahc0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > > > da0 at ahc0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > These wouldn't be Western Digital Enterprise drives would they? > > They are very poor drives. There are some messages in the archives that > you need to disable some features on them in order to get the performance > up to a reasonable level. > > Also, make sure you have a spare. They have a tendency to die too. > Usually in the 6months to 1year range. > > > > And here are a few miserable tests : > > > > > > Sparc Entreprise 1000 - very old : > ... > > But they use some rather nice Seagate drives. As I recall. I belive > that Sun uses only Seagate in all their higher lines. > > > Tom > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 9:47: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rz5.rz.fh-wilhelmshaven.de (rz5.rz.fh-wilhelmshaven.de [139.13.57.132]) by hub.freebsd.org (Postfix) with ESMTP id 3AAD114BEC for ; Thu, 14 Oct 1999 09:46:57 -0700 (PDT) (envelope-from ohoyer@fbwi.fh-wilhelmshaven.de) Received: from fettesau.stuwo.fh-wilhelmshaven.de (stuwopc5.stuwo.fh-wilhelmshaven.de [139.13.209.5]) by rz5.rz.fh-wilhelmshaven.de (8.8.7/8.8.5) with SMTP id SAA28373; Thu, 14 Oct 1999 18:46:48 +0200 Message-Id: <4.1.19991014184241.00ba1c40@mailserv.rz.fh-wilhelmshaven.de> X-Sender: ohoyer@mailserv.rz.fh-wilhelmshaven.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Oct 1999 18:46:15 +0200 To: Joao Pagaime From: Olaf Hoyer Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Cc: scsi@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 16:35 14.10.99 +0100, you wrote: > >Thanks for the response! > >Sorry if I read a little strange, but I'm no SCSI specialist. > >In all cases I'm stuck with that board, because the disks draw power >from it - signaling/data and power in the same SCSI interface (I'm >sure that has a simple name for that...) > I'm not even sure if I can connect that "backplane" to a normal >SCSI controller (like an SCSI Card 2940U2W) because the architecture >seems very proprietary... Hi! If that is a 80-pin looking-like Centronics plug,probably it is SCA? This means it could be HVD type SCSI, whereas U2W is the low voltage= version... Sun used a lot of Barracuda drives, if memory serves me right. Regards Olaf Hoyer - - - - - - - -=20 Olaf Hoyer ICQ: 22838075 mailto: Olaf.Hoyer@nightfire.de home: www.nightfire.de (The home of the burning CPU) Wer mit Ungeheuern k=E4mpft, mag zusehn,=20 da=DF er nicht dabei zum Ungeheuer wird. Und wenn du lange in einen Abgrund blickst, blickt der Abgrund=20 auch in dich hinein. (Friedrich Nietzsche, Jenseits von Gut und B=F6se) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 10:40: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id E1A5015384 for ; Thu, 14 Oct 1999 10:40:03 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA01691; Thu, 14 Oct 1999 19:15:10 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id SAA00753; Thu, 14 Oct 1999 18:46:44 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910141646.SAA00753@yedi.iaf.nl> Subject: Re: Disktab entry for Seagate ST-19171W (Barracuda 9) In-Reply-To: from Matthew Jacob at "Oct 13, 1999 2:28:20 pm" To: mjacob@feral.com Date: Thu, 14 Oct 1999 18:46:44 +0200 (CEST) Cc: joerg_wunsch@uriah.heep.sax.de, patl@phoenix.volant.org, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > unless the FRU is a fuse. > or the drive itself. That is what I said: a drive hardware error. Does not have to be a full scale headcrash ;-) > On Wed, 13 Oct 1999, Wilko Bulte wrote: > > > As Matthew Jacob wrote ... > > > > > > Not necessarily. Parity errors are usually cable or termpwr/fuse related > > > issues. > > > > But then the drive generally does not mumble around vendor replacable units. > > > > > > > > > > That is the ASC/ASCQ which mean: "SCSI parity error" (hurrah..) > > > > > > > > > > write error: 2048 > > > > > > parity error in vendor replacable unit 3 > > > > > > > > Sounds like a drive hardware error to me. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 11:48: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from PacHell.TelcoSucks.org (PacHell.TelcoSucks.org [207.90.181.5]) by hub.freebsd.org (Postfix) with ESMTP id B1B1C15075 for ; Thu, 14 Oct 1999 11:47:47 -0700 (PDT) (envelope-from ulf@PacHell.TelcoSucks.org) Received: (from ulf@localhost) by PacHell.TelcoSucks.org (8.9.3/8.9.1) id LAA66267; Thu, 14 Oct 1999 11:46:54 -0700 (PDT) (envelope-from ulf) Message-ID: <19991014114654.J64439@TelcoSucks.org> Date: Thu, 14 Oct 1999 11:46:54 -0700 From: Ulf Zimmermann To: Joao Pagaime , Tom Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Reply-To: ulf@Alameda.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Joao Pagaime on Thu, Oct 14, 1999 at 04:35:44PM +0100 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 3.2-STABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Oct 14, 1999 at 04:35:44PM +0100, Joao Pagaime wrote: > > Thanks for the response! > > Sorry if I read a little strange, but I'm no SCSI specialist. > > However Dell does refer in the manuals to the board where the disks plug > into as "backplane". Probably this isn't the rigth nomenclature. > I think the server has a RAID option - with a different "backplane" - > that we didn't purchase. > > In all cases I'm stuck with that board, because the disks draw power > from it - signaling/data and power in the same SCSI interface (I'm > sure that has a simple name for that...) > I'm not even sure if I can connect that "backplane" to a normal > SCSI controller (like an SCSI Card 2940U2W) because the architecture > seems very proprietary... > That backplane is the hotswap SCA backplane, the 3.3MB/sec for it is only used for reporting. > The disk optimization is a 'must' then... From 2 MB/s to something > close to 80 takes a great deal of optimization. > > Thanks, > Joao Pagaime > > -- > FCCN - Fundacao para a Computacao Cientifica Nacional - Tel: 351-1-8440100 > > On Thu, 14 Oct 1999, Tom wrote: > > > > > On Thu, 14 Oct 1999, Joao Pagaime wrote: > > > > > Hi all > > > > > > I have a very slow Pentium III/450 with 512MB RAM > > > because disks tranfers are slow. > > > > > > Simple tests show a transfer rate of +/- 2MB/sec, > > > when a PC with IDE can do easily at least 4 times > > > that value. > > > > > > I think the problem is with the "Common Access Method" > > > in the backplane, because although the controllers are > > > found with no problem : > > > > What backplane? > > > > > ahc0: rev 0x00 int a irq 11 on > > > pci2.4.0 > > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > > ahc1: rev 0x03 int a irq 11 on pci2.6.0 > > > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > > > > > The backplane is reported as having only 3.3 MB transfer rate : > > > > > > pass2 at ahc0 bus 0 target 6 lun 0 > > > pass2: Fixed Processor SCSI-2 device > > > pass2: 3.300MB/s transfers > > > > That isn't a backplane. That looks like some kind of special SCSI > > device on your chain. Perhaps it is a backplane status reporting device > > of some sort. But it is not the backplane itself. > > > > > Did anyone experience the same problem ? > > > Can someone help me ? > > > Any hints ? > > > Any configurarion at the CAM level ? - I configured the kernel > > > to debug CAM but I can only reboot the machine in a few > > > hours... > > > > > > Thanks, > > > Joao Pagaime > > > > > > PS: the disks are also reporter correctly : > > > > > > da1 at ahc0 bus 0 target 1 lun 0 > > > da1: Fixed Direct Access SCSI-2 device > > > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > > > > > da0 at ahc0 bus 0 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-2 device > > > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > > > These wouldn't be Western Digital Enterprise drives would they? > > > > They are very poor drives. There are some messages in the archives that > > you need to disable some features on them in order to get the performance > > up to a reasonable level. > > > > Also, make sure you have a spare. They have a tendency to die too. > > Usually in the 6months to 1year range. > > > > > > > And here are a few miserable tests : > > > > > > > > > Sparc Entreprise 1000 - very old : > > ... > > > > But they use some rather nice Seagate drives. As I recall. I belive > > that Sun uses only Seagate in all their higher lines. > > > > > > Tom > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 15:41:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 39A2E14BDE for ; Thu, 14 Oct 1999 15:41:14 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id QAA08222 for ; Thu, 14 Oct 1999 16:01:34 -0700 (PDT) Date: Thu, 14 Oct 1999 16:01:34 -0700 (PDT) From: Alfred Perlstein To: scsi@freebsd.org Subject: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FYI, anyone know if thise is fixed or wants to follow up? -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 15:39:42 +0100 (WEST) From: Joao Pagaime To: freebsd-questions@FreeBSD.ORG Subject: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Hi all I have a very slow Pentium III/450 with 512MB RAM because disks tranfers are slow. Simple tests show a transfer rate of +/- 2MB/sec, when a PC with IDE can do easily at least 4 times that value. I think the problem is with the "Common Access Method" in the backplane, because although the controllers are found with no problem : ahc0: rev 0x00 int a irq 11 on pci2.4.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x03 int a irq 11 on pci2.6.0 ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs The backplane is reported as having only 3.3 MB transfer rate : pass2 at ahc0 bus 0 target 6 lun 0 pass2: Fixed Processor SCSI-2 device pass2: 3.300MB/s transfers Did anyone experience the same problem ? Can someone help me ? Any hints ? Any configurarion at the CAM level ? - I configured the kernel to debug CAM but I can only reboot the machine in a few hours... Thanks, Joao Pagaime PS: the disks are also reporter correctly : da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) And here are a few miserable tests : Sparc Entreprise 1000 - very old : time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out real 0m22.640s user 0m0.055s sys 0m16.094s Dell PowerEdge 4300 (http://www.dell.com/products/poweredge/pe4300/index.htm) time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out 100000000 bytes transferred in 53.853144 secs (1856902 bytes/sec) real 0m55.553s user 0m0.001s sys 0m1.562s This makes very unhappy users ! thank again, -- FCCN - Fundacao para a Computacao Cientifica Nacional - Tel: 351-1-8440100 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 15:55:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1AB8815109 for ; Thu, 14 Oct 1999 15:55:50 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA46124; Thu, 14 Oct 1999 16:55:45 -0600 (MDT) (envelope-from ken) Message-Id: <199910142255.QAA46124@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: from Joao Pagaime at "Oct 14, 1999 03:53:13 pm" To: jpsp@rccn.net (Joao Pagaime) Date: Thu, 14 Oct 1999 16:55:45 -0600 (MDT) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM939941744-46065-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM939941744-46065-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Joao Pagaime wrote... > > I have a very slow Pentium III/450 with 512MB RAM > because disks tranfers are slow. > > Simple tests show a transfer rate of +/- 2MB/sec, > when a PC with IDE can do easily at least 4 times > that value. > > I think the problem is with the "Common Access Method" > in the backplane, because although the controllers are > found with no problem : > > ahc0: rev 0x00 int a irq 11 on > pci2.4.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc1: rev 0x03 int a irq 11 on pci2.6.0 > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > The backplane is reported as having only 3.3 MB transfer rate : > > pass2 at ahc0 bus 0 target 6 lun 0 > pass2: Fixed Processor SCSI-2 device > pass2: 3.300MB/s transfers > > Did anyone experience the same problem ? > Can someone help me ? > Any hints ? > Any configurarion at the CAM level ? - I configured the kernel > to debug CAM but I can only reboot the machine in a few > hours... Other folks already explained the 3.3MB/sec transfers on your backplane device, so i won't repeat what they said. > PS: the disks are also reporter correctly : > > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) Western Digital drives generally aren't that great. In fact, we have disabled tagged queueing for most all Western Digital SCSI drives. (including the drives you have, above) [ ... ] > Dell PowerEdge 4300 > (http://www.dell.com/products/poweredge/pe4300/index.htm) > > time dd bs=1000000 count=100 if=/dev/zero of=t > 100+0 records in > 100+0 records out > 100000000 bytes transferred in 53.853144 secs (1856902 bytes/sec) Okay, there are several things to try here: - first, enable write caching on this drive if it isn't already turned on. camcontrol modepage da0 -m 8 -P 3 -e Then change the 'WCE' bit from 0 to 1. Do the same thing for da1. - if your performance doesn't improve after that, try re-enabling tagged queueing. Try the attached patch for src/sys/cam/cam_xpt.c. It is against -current, but I think it'll apply to 3.2. If not, you can probably see what you need to comment out. Hopefully, one of those two things will fix your performance. I'd like to hear what happens. Ken -- Kenneth Merry ken@kdm.org --ELM939941744-46065-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=cam_xpt.c.wde_tag.101499 Content-Description: cam_xpt.c.wde_tag.101499 Content-Transfer-Encoding: 7bit ==== //depot/FreeBSD-ken/src/sys/cam/cam_xpt.c#2 - /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c ==== *** /tmp/tmp.46108.0 Thu Oct 14 16:54:28 1999 --- /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c Thu Oct 14 16:52:13 1999 *************** *** 360,365 **** --- 360,366 ---- { T_DIRECT, SIP_MEDIA_FIXED, samsung, "WN34324U*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, + #if 0 { /* * Slow when tagged queueing is enabled. (1.5MB/sec versus *************** *** 371,376 **** --- 372,378 ---- { T_DIRECT, SIP_MEDIA_FIXED, west_digital, "WDE*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, + #endif { /* * Slow when tagged queueing is enabled. (1.5MB/sec versus --ELM939941744-46065-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 16:15:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 2D68E14EFC for ; Thu, 14 Oct 1999 16:15:31 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA46226; Thu, 14 Oct 1999 17:15:27 -0600 (MDT) (envelope-from ken) Message-Id: <199910142315.RAA46226@panzer.kdm.org> Subject: Re: Does 3.3-R support Adaptec AVA-2906? In-Reply-To: <199910141453.KAA01285@world.std.com> from Carl Mascott at "Oct 14, 1999 10:53:35 am" To: cmascott@world.std.com (Carl Mascott) Date: Thu, 14 Oct 1999 17:15:27 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Carl Mascott wrote... > Does FreeBSD 3.3-R support the Adaptec AVA-2906 SCSI host > adapter? It's not listed in the Release Notes, but it > seems to use the same ASPI family manager under DOS/Windows > as does the 2940, which is encouraging. > > Please e-mail me directly. Thanks! It might be supported, it's hard to say. It appears to be a 7800 family board, so the Adaptec driver is probably capable of supporting it, but if Adaptec has followed their usual pattern, it'll have a unique PCI ID. Therefore the driver may not recognize it, even though the chip on the board is supported. Odds are, you could probably tweak the Adaptec driver probe routine to recognize it, once you figure out what chip is onboard. (Probably a 7855 or 7860.) It doesn't have a BIOS, so you can't boot off it. You'll have to boot off of another SCSI controller or an IDE disk. The easiest way to figure out if it's supported is to stick a 3.3 boot floppy in the machine and see if it probes. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 14 23:16:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154]) by hub.freebsd.org (Postfix) with ESMTP id 9E25B14D75; Thu, 14 Oct 1999 23:16:51 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id XAA00693; Thu, 14 Oct 1999 23:16:50 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: Odd dmesg output or SCSI tagged-queueing problem? X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-URL: http://www.codegen.com X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm Date: Thu, 14 Oct 1999 23:16:50 -0700 Message-ID: <689.939968210@pinhead.parag.codegen.com> From: Parag Patel Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. I just noticed my system's two IBM SCSI disks aren't displaying a "tagged queueing enabled" message. I only noticed it when I added a 3rd disk to the system today. Here's the edited dmesg output (the complete output is appended below): ... ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ... da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) ... da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) ... da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) ... Now I seem to remember that these IBM drives used to be displayed like the Quantum, that is with the string "Tagged Queueing Enabled". I searched all the /var/log/messages files to see if any earlier kernel did display this, but nothing up to 4.0-CURRENT as of May 1999 displayed this string, and I've switched to running STABLE since. A search of the mail archives didn't turn up anything directly related to this, although one other person with the *identical* 7880 and IBM drive *did* have "Tagged Queueing Enabled" in their dmesg output. So it seems that at least I'm not mis-remembering this. I think. Thoughts? Thanks! -- Parag Patel Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #3: Thu Oct 14 15:12:05 PDT 1999 root@pinhead.parag.codegen.com:/usr/src/sys/compile/PINHEAD Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II (686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 268435456 (262144K bytes) avail memory = 258191360 (252140K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02ed000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x01 on pci0.4.0 ide_pci0: rev 0x01 on pci0.4.1 chip3: rev 0x01 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 17 on pci0.11.0 fxp0: Ethernet address 00:a0:c9:da:98:26 Probing for devices on PCI bus 1: vga0: rev 0x00 int a irq 16 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00e4 [0xe4008c0e] Serial 0x08de2f0a Comp ID: PNPb02f [0x2fb0d041] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model MouseMan+, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (atapi): , removable, accel, ovlap, dma, iordis acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (wd2): , DMA, 32-bit, multi-block-16 wd2: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S sb0 at 0x220 irq 10 drq 1 on isa snd0: sbxvi0 at drq 5 on isa snd0: sbmidi0 not found at 0x330 opl0 at 0x388 on isa snd0: joy0 at 0x201 on isa joy0: joystick joy1 not probed due to I/O address conflict with joy0 at 0x201 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 Waiting 3 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! pass4 at ahc0 bus 0 target 6 lun 0 pass4: Fixed Scanner SCSI-2 device pass4: 3.300MB/s transfers da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) changing root device to da0s2a cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable Worm SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) pid 493 (kpilotDaemon), uid 1000: exited on signal 6 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 0:26:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 7F5CE14C83 for ; Fri, 15 Oct 1999 00:26:47 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id KAA57791; Fri, 15 Oct 1999 10:26:41 +0300 (EEST) (envelope-from will) To: parag@cgt.com (Parag Patel) Cc: freebsd-scsi@freebsd.org Subject: Re: Odd dmesg output or SCSI tagged-queueing problem? References: <689.939968210@pinhead.parag.codegen.com> From: Ville-Pertti Keinonen Date: 15 Oct 1999 10:26:41 +0300 In-Reply-To: parag@cgt.com's message of "15 Oct 1999 09:17:39 +0300" Message-ID: <86yad5jd8u.fsf@not.demophon.com> Lines: 42 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org parag@cgt.com (Parag Patel) writes: > Now I seem to remember that these IBM drives used to be displayed like > the Quantum, that is with the string "Tagged Queueing Enabled". I > searched all the /var/log/messages files to see if any earlier kernel > did display this, but nothing up to 4.0-CURRENT as of May 1999 displayed > this string, and I've switched to running STABLE since. There's a comment in sys/cam/cam_xpt.c about the DCAS: { /* * Slow when tagged queueing is enabled. Write performance * steadily drops off with more and more concurrent * transactions. Best sequential write performance with * tagged queueing turned off and write caching turned on. * * PR: kern/10398 * Submitted by: Hideaki Okada * Drive: DCAS-34330 w/ "S65A" firmware. * * The drive with the problem had the "S65A" firmware * revision, and has also been reported (by Stephen J. * Roznowski ) for a drive with the "S61A" * firmware revision. * * Although no one has reported problems with the 2 gig * version of the DCAS drive, the assumption is that it * has the same problems as the 4 gig version. Therefore * this quirk entries disables tagged queueing for all * DCAS drives. */ { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DCAS*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, I didn't notice this until recently, either, even though the quirk entry has been there for a while. I'm not quite convinced that tagged queueing really hurts, but haven't bothered to do any testing. The DCAS isn't *that* fast, in any case (but other than in terms of performance, it seems very good). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 3:21:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlas.rccn.net (atlas.rccn.net [193.136.7.1]) by hub.freebsd.org (Postfix) with SMTP id AA3D41528B for ; Fri, 15 Oct 1999 03:20:29 -0700 (PDT) (envelope-from jpsp@rccn.net) Received: (qmail 71102 invoked by uid 1021); 15 Oct 1999 10:20:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Oct 1999 10:20:19 -0000 Date: Fri, 15 Oct 1999 11:20:19 +0100 (WEST) From: Joao Pagaime To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 - It works! In-Reply-To: <199910142255.QAA46124@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Oct 1999, Kenneth D. Merry wrote: > Joao Pagaime wrote... > > > > I have a very slow Pentium III/450 with 512MB RAM > > because disks tranfers are slow. > > > > Simple tests show a transfer rate of +/- 2MB/sec, > > when a PC with IDE can do easily at least 4 times > > that value. > > > > I think the problem is with the "Common Access Method" > > in the backplane, because although the controllers are > > found with no problem : > > > > ahc0: rev 0x00 int a irq 11 on > > pci2.4.0 > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > ahc1: rev 0x03 int a irq 11 on pci2.6.0 > > ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > > > The backplane is reported as having only 3.3 MB transfer rate : > > > > pass2 at ahc0 bus 0 target 6 lun 0 > > pass2: Fixed Processor SCSI-2 device > > pass2: 3.300MB/s transfers > > > > Did anyone experience the same problem ? > > Can someone help me ? > > Any hints ? > > Any configurarion at the CAM level ? - I configured the kernel > > to debug CAM but I can only reboot the machine in a few > > hours... > > Other folks already explained the 3.3MB/sec transfers on your backplane > device, so i won't repeat what they said. > > > PS: the disks are also reporter correctly : > > > > da1 at ahc0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da1: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > > > da0 at ahc0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > > da0: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > Western Digital drives generally aren't that great. In fact, we have > disabled tagged queueing for most all Western Digital SCSI drives. > (including the drives you have, above) > > [ ... ] > > > Dell PowerEdge 4300 > > (http://www.dell.com/products/poweredge/pe4300/index.htm) > > > > time dd bs=1000000 count=100 if=/dev/zero of=t > > 100+0 records in > > 100+0 records out > > 100000000 bytes transferred in 53.853144 secs (1856902 bytes/sec) > > Okay, there are several things to try here: > > - first, enable write caching on this drive if it isn't already turned on. > > camcontrol modepage da0 -m 8 -P 3 -e > > Then change the 'WCE' bit from 0 to 1. Do the same thing for da1. That did it! Changing the WCE bit made all the difference in writing operations. Now I can get about 17 MB/sec transfers: time dd bs=1000000 count=100 if=/dev/zero of=t 100+0 records in 100+0 records out 100000000 bytes transferred in 5.878631 secs (17010763 bytes/sec) real 0m5.940s user 0m0.999s sys 0m1.570s Is there any way to make these settings permanent ? > > - if your performance doesn't improve after that, try re-enabling tagged > queueing. Try the attached patch for src/sys/cam/cam_xpt.c. It is > against -current, but I think it'll apply to 3.2. If not, you can > probably see what you need to comment out. The patch seems to apply: patch < cam_xpt.c.wde_tag.101499 Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |==== //depot/FreeBSD-ken/src/sys/cam/cam_xpt.c#2 - /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c ==== |*** /tmp/tmp.46108.0 Thu Oct 14 16:54:28 1999 |--- /a/ken/perforce/FreeBSD-ken/src/sys/cam/cam_xpt.c Thu Oct 14 16:52:13 1999 -------------------------- Patching file cam_xpt.c using Plan A... Hunk #1 succeeded at 380 (offset 20 lines). Hunk #2 succeeded at 392 (offset 20 lines). done And the kernel compiles, so I'll try it during the weekend (It's a production machine) - I'll let you know. > > Hopefully, one of those two things will fix your performance. I'd like to > hear what happens. > > Ken > -- > Kenneth Merry > ken@kdm.org > Thank you all, specially to Kenneth Merry. I already spend a few days digging around, opening the machine, calling up suppliers, etc, etc. And nothing worked, except that last bit change... Tkns, Joao Pagaime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 4:51:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.217.82.22]) by hub.freebsd.org (Postfix) with ESMTP id 345AD1531B for ; Fri, 15 Oct 1999 04:51:15 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id MAA56505; Fri, 15 Oct 1999 12:51:07 +0100 (BST) (envelope-from geoffb) Date: Fri, 15 Oct 1999 12:51:07 +0100 From: Geoff Buckingham To: "Kenneth D. Merry" Cc: Joao Pagaime , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <19991015125107.A56477@chuggalug.clues.com> References: <199910142255.QAA46124@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199910142255.QAA46124@panzer.kdm.org>; from Kenneth D. Merry on Thu, Oct 14, 1999 at 04:55:45PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Oct 14, 1999 at 04:55:45PM -0600, Kenneth D. Merry wrote: > > Western Digital drives generally aren't that great. In fact, we have > disabled tagged queueing for most all Western Digital SCSI drives. > (including the drives you have, above) > I have been meaning to post on this subject for some time, while in my last place of employment I bought 8 Dell PowerEdge 2300s each with six drives Dell supplied Western digitals and I had really poor disk performance. I realised tagged queing was disabled for WDE* and removed the quirk from cam_xpt.c this greatly improved the performance. Much exercising of the disks also failed to cause any further problems. SAdly I have no longer work their so cannot produce revision/model numbers for the drives, they were the current 7200RPM 9GB drive. Would it be possible to refine the Western Digital quirk to be a little more specific as it does have quite an impact on performance and Dell seem to be shipping large volumes of Western Digital Drives ATM. -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 7:45:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id B9AB8150D1 for ; Fri, 15 Oct 1999 07:45:21 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA00364; Fri, 15 Oct 1999 10:38:45 -0400 (EDT) Reply-To: Randell Jesup To: Ville-Pertti Keinonen Cc: parag@cgt.com (Parag Patel), freebsd-scsi@FreeBSD.ORG Subject: Re: Odd dmesg output or SCSI tagged-queueing problem? References: <689.939968210@pinhead.parag.codegen.com> <86yad5jd8u.fsf@not.demophon.com> From: Randell Jesup Date: 15 Oct 1999 10:40:53 +0000 In-Reply-To: Ville-Pertti Keinonen's message of "15 Oct 1999 10:26:41 +0300" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ville-Pertti Keinonen writes: >I didn't notice this until recently, either, even though the quirk >entry has been there for a while. I'm not quite convinced that tagged >queueing really hurts, but haven't bothered to do any testing. The >DCAS isn't *that* fast, in any case (but other than in terms of >performance, it seems very good). The PR shows that there's a gradual dropoff in sequential write performance as the number of tags increases. However, single-process sequential-write is not a very real-world load (though for a single-user machine, it's not all that off-base). Having a few tags, however, might allow the drive cache to be much more useful in a multi-process (real-world) environment, without having a great deal of impact on sequential performance (drops 400-600K/s from 1 (no) to 2 tags, but after that it drops far more slowly - 30-60K/s/tag). 4 or 8 tags might be a reasonable quirk setting. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 8: 0:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8297614A05 for ; Fri, 15 Oct 1999 08:00:48 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id LAA22981; Fri, 15 Oct 1999 11:00:47 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id LAA60488; Fri, 15 Oct 1999 11:00:17 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 15 Oct 1999 11:00:16 -0400 (EDT) To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <19991015125107.A56477@chuggalug.clues.com> References: <199910142255.QAA46124@panzer.kdm.org> <19991015125107.A56477@chuggalug.clues.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14343.16009.738375.608477@grasshopper.cs.duke.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Geoff Buckingham writes: > On Thu, Oct 14, 1999 at 04:55:45PM -0600, Kenneth D. Merry wrote: > > > > Western Digital drives generally aren't that great. In fact, we have > > disabled tagged queueing for most all Western Digital SCSI drives. > > (including the drives you have, above) > > > > I have been meaning to post on this subject for some time, while in my last > place of employment I bought 8 Dell PowerEdge 2300s each with six drives > Dell supplied Western digitals and I had really poor disk performance. > > I realised tagged queing was disabled for WDE* and removed the quirk from > cam_xpt.c this greatly improved the performance. Much exercising of the disks > also failed to cause any further problems. I'm the guy to blame for this quirk. My drives (shipped in about 60 older Dell Dimension XPS D300 here) have abysmal sequential write performance with tagged queuing enabled. There are two types of identifiers: pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number WS7010610507 pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number WS7011244369 pass1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) From the reports I've seen, it looks like Western Digital got their act together and their Ultra2 drives are OK. Could we make the quirk entry enable tagged queuing for Ultra2 WDE drives & disable it for non-ultra2 drives? Also, would it be possible to enable/disable tagged queuing from camcontrol? Or to read the quirks from a config file (like Digital UNIX does with its ddr.db file..). Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 8:13:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 358D215245 for ; Fri, 15 Oct 1999 08:12:09 -0700 (PDT) (envelope-from cdf.lists@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1016) id A7DC19B23; Fri, 15 Oct 1999 11:12:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 9E5F3BA1C; Fri, 15 Oct 1999 11:12:01 -0400 (EDT) Date: Fri, 15 Oct 1999 11:12:01 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: cdf.lists@pawn.primelocation.net To: Andrew Gallatin Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <14343.16009.738375.608477@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Andrew Gallatin wrote: > I'm the guy to blame for this quirk. My drives (shipped in about 60 > older Dell Dimension XPS D300 here) have abysmal sequential write > performance with tagged queuing enabled. There are two types of > identifiers: > > pass0: Fixed Direct Access SCSI-2 device > pass0: Serial Number WS7010610507 > pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > pass1: Fixed Direct Access SCSI-2 device > pass1: Serial Number WS7011244369 > pass1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > >From the reports I've seen, it looks like Western Digital got their > act together and their Ultra2 drives are OK. Could we make the quirk > entry enable tagged queuing for Ultra2 WDE drives & disable it for > non-ultra2 drives? > I can agree with this. I have the following: da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 8683MB (17783204 512 byte sectors: 255H 63S/T 1106C) After enabling tagged queuing on this drive (by removing the quirk entry) and found performance about 10% slower. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 8:53: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rz5.rz.fh-wilhelmshaven.de (rz5.rz.fh-wilhelmshaven.de [139.13.57.132]) by hub.freebsd.org (Postfix) with ESMTP id 3756515319 for ; Fri, 15 Oct 1999 08:52:55 -0700 (PDT) (envelope-from ohoyer@fbwi.fh-wilhelmshaven.de) Received: from fettesau.stuwo.fh-wilhelmshaven.de (stuwopc5.stuwo.fh-wilhelmshaven.de [139.13.209.5]) by rz5.rz.fh-wilhelmshaven.de (8.8.7/8.8.5) with SMTP id RAA11677 for ; Fri, 15 Oct 1999 17:15:15 +0200 Message-Id: <4.1.19991015171324.00910d40@mailserv.rz.fh-wilhelmshaven.de> X-Sender: ohoyer@mailserv.rz.fh-wilhelmshaven.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Oct 1999 17:13:41 +0200 To: scsi@FreeBSD.ORG From: Olaf Hoyer Subject: Permanent enabling WCE bit : was Slow SCSI Dell PowerEdge 4300 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > pass2: 3.300MB/s transfers >> >=20 >> > Did anyone experience the same problem ? >> > Can someone help me ?=20 >> > Any hints ? >> > Any configurarion at the CAM level ? - I configured the kernel >> > to debug CAM but I can only reboot the machine in a few >> > hours... >>=20 >> Other folks already explained the 3.3MB/sec transfers on your backplane >> device, so i won't repeat what they said. >> Okay, there are several things to try here: >>=20 >> - first, enable write caching on this drive if it isn't already turned= on. >>=20 >> camcontrol modepage da0 -m 8 -P 3 -e >>=20 >> Then change the 'WCE' bit from 0 to 1. Do the same thing for da1. > >Changing the WCE bit made all the difference in >writing operations. > >Now I can get about 17 MB/sec transfers: >Is there any way to make these settings permanent ? > Hi! Well, there is always the possinility, to store that value in a "user-config area of the HDD" It's a standardized writable area of the firmware, where the drive stores config settings. With some programs, you can manipulate them manually. In my old DOS days, I used a prog from Seagate for that, but there are some others available.=20 Will have to look for it, mail me for that or an URL. Simply boot with a plain old DOS disk, view the config page of the HDD, and set the bits you desire to change. (THere you can also config reconnnect/disconnect behaviour depending on cache usage etc.) For desktop users with M$-OS present, Adaptecs EZ-SCSI offers this possibility, too. And that works with nearly every ASPI-compliant SCSI-card, not only with Adaptecs cards. (I'm a fan of Symbios, for price/power ratio) Regards Olaf Hoyer=20 - - - - - - - -=20 Olaf Hoyer ICQ: 22838075 mailto: Olaf.Hoyer@nightfire.de home: www.nightfire.de (The home of the burning CPU) Wer mit Ungeheuern k=E4mpft, mag zusehn,=20 da=DF er nicht dabei zum Ungeheuer wird. Und wenn du lange in einen Abgrund blickst, blickt der Abgrund=20 auch in dich hinein. (Friedrich Nietzsche, Jenseits von Gut und B=F6se) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9: 1:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 68582152FC for ; Fri, 15 Oct 1999 09:01:53 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA06566; Fri, 15 Oct 1999 09:01:38 -0700 Date: Fri, 15 Oct 1999 09:01:38 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <14343.16009.738375.608477@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Andrew Gallatin wrote: > > Geoff Buckingham writes: > > On Thu, Oct 14, 1999 at 04:55:45PM -0600, Kenneth D. Merry wrote: > > > > > > Western Digital drives generally aren't that great. In fact, we have > > > disabled tagged queueing for most all Western Digital SCSI drives. > > > (including the drives you have, above) > > > > > > > I have been meaning to post on this subject for some time, while in my last > > place of employment I bought 8 Dell PowerEdge 2300s each with six drives > > Dell supplied Western digitals and I had really poor disk performance. > > > > I realised tagged queing was disabled for WDE* and removed the quirk from > > cam_xpt.c this greatly improved the performance. Much exercising of the disks > > also failed to cause any further problems. > > I'm the guy to blame for this quirk. My drives (shipped in about 60 > older Dell Dimension XPS D300 here) have abysmal sequential write > performance with tagged queuing enabled. There are two types of > identifiers: > > pass0: Fixed Direct Access SCSI-2 device > pass0: Serial Number WS7010610507 > pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > pass1: Fixed Direct Access SCSI-2 device > pass1: Serial Number WS7011244369 > pass1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > >From the reports I've seen, it looks like Western Digital got their > act together and their Ultra2 drives are OK. Could we make the quirk > entry enable tagged queuing for Ultra2 WDE drives & disable it for > non-ultra2 drives? > > Also, would it be possible to enable/disable tagged queuing from > camcontrol? Or to read the quirks from a config file (like Digital > UNIX does with its ddr.db file..). > This is on my list to address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9: 6:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 639C6153CA for ; Fri, 15 Oct 1999 09:06:25 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id LAA03602 for ; Fri, 15 Oct 1999 11:59:32 -0400 (EDT) Reply-To: Randell Jesup To: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 References: <199910142255.QAA46124@panzer.kdm.org> <19991015125107.A56477@chuggalug.clues.com> <14343.16009.738375.608477@grasshopper.cs.duke.edu> From: Randell Jesup Date: 15 Oct 1999 12:01:27 +0000 In-Reply-To: Andrew Gallatin's message of "Fri, 15 Oct 1999 11:00:16 -0400 (EDT)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin writes: >Also, would it be possible to enable/disable tagged queuing from >camcontrol? I wouldn't think this would be all that hard. > Or to read the quirks from a config file (like Digital >UNIX does with its ddr.db file..). This would be very nice (though rather a bunch of work I assume - you'd have to boot with generic/safe parameters until the file could be read - or boot with a compiled-in quirks, and then after it can read the (optional) file apply that on top of the built-in quirks - this is probably preferable). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9:44:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154]) by hub.freebsd.org (Postfix) with ESMTP id C7FAE14A18 for ; Fri, 15 Oct 1999 09:44:09 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id JAA03707; Fri, 15 Oct 1999 09:42:48 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) To: Ville-Pertti Keinonen Cc: freebsd-scsi@freebsd.org, Randell Jesup , "David Schwartz" Subject: Re: Odd dmesg output or SCSI tagged-queueing problem? In-Reply-To: Message from Ville-Pertti Keinonen of "15 Oct 1999 10:26:41 +0300." <86yad5jd8u.fsf@not.demophon.com> X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-URL: http://www.codegen.com X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm Date: Fri, 15 Oct 1999 09:42:48 -0700 Message-ID: <3703.940005768@pinhead.parag.codegen.com> From: Parag Patel Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cool - thanks! I'll play around with the smaller tags settings suggested by Randell Jesup and see how the system behaves. Glad to hear my memory wasn't defective after all... -- Parag Patel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9:46:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id F216A14CE5 for ; Fri, 15 Oct 1999 09:46:04 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id SAA12906 for scsi@FreeBSD.ORG; Fri, 15 Oct 1999 18:46:03 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 97DD4878D; Fri, 15 Oct 1999 12:36:17 +0200 (CEST) Date: Fri, 15 Oct 1999 12:36:17 +0200 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 - It works! Message-ID: <19991015123617.A78087@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.ORG References: <199910142255.QAA46124@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Joao Pagaime: > Is there any way to make these settings permanent ? Re-edit the mode page with "-P 3". That way, you modify the "default" page. camcontrol(8) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9:48:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F12014CE5 for ; Fri, 15 Oct 1999 09:48:08 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA07015; Fri, 15 Oct 1999 09:47:53 -0700 Date: Fri, 15 Oct 1999 09:47:53 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randell Jesup Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It will likely be done the same way /boot/loader.conf is done- or may even be part of this. It isn't just for disks- tapes need this too. On 15 Oct 1999, Randell Jesup wrote: > Andrew Gallatin writes: > >Also, would it be possible to enable/disable tagged queuing from > >camcontrol? > > I wouldn't think this would be all that hard. > > > Or to read the quirks from a config file (like Digital > >UNIX does with its ddr.db file..). > > This would be very nice (though rather a bunch of work I assume - > you'd have to boot with generic/safe parameters until the file could > be read - or boot with a compiled-in quirks, and then after it can read the > (optional) file apply that on top of the built-in quirks - this is > probably preferable). > > -- > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > rjesup@wgate.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 9:57:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from exchange.isgcolumbia.com (exchange.computerland.net [207.1.227.179]) by hub.freebsd.org (Postfix) with ESMTP id 1F8EF14D95 for ; Fri, 15 Oct 1999 09:57:35 -0700 (PDT) (envelope-from bkerr@isgcolumbia.com) Received: by exchange.computerland.net with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Oct 1999 11:54:03 -0500 Message-ID: From: Brian Kerr To: scsi@FreeBSD.ORG Subject: ncr0 problem Date: Fri, 15 Oct 1999 11:54:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am having problems with a NCR/Symbios 53c875 controller, configured as ncr0 in my kernel. This is on a 3.3-stable machine. The problem occurs when "large" amounts of data are being written, or deleted from either da0 or da1, my two scsi drives. They are barracuda 4.5gig drives. The system will hang, but keep tcp connections open, however the system will not do anything with them, and the error respawns every 5 seconds or so on ttyv0 and in /var/log/messages, here is the message... /kernel: ncr0 queue is empty It causes the system to become unusable, anyone with any idea how to fix this please let me know. Thanks in advance ---------------------------------------------------------------- Brian Kerr - 573.446.8881 x51 Systems Administrator Midamerica/Computerland Internet Services - www.computerland.net The Digital Missourian - www.digmo.com ---------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 10:15: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CC4EE14D95 for ; Fri, 15 Oct 1999 10:14:58 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA50233; Fri, 15 Oct 1999 11:14:54 -0600 (MDT) (envelope-from ken) Message-Id: <199910151714.LAA50233@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <14343.16009.738375.608477@grasshopper.cs.duke.edu> from Andrew Gallatin at "Oct 15, 1999 11:00:16 am" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Fri, 15 Oct 1999 11:14:54 -0600 (MDT) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin wrote... > >From the reports I've seen, it looks like Western Digital got their > act together and their Ultra2 drives are OK. Could we make the quirk > entry enable tagged queuing for Ultra2 WDE drives & disable it for > non-ultra2 drives? It would be tricky, since they seem have just added "ULTRA2" on the end of the device string. And it isn't worth changing the quirk without a full round of tests from someone with one of these disks. > Also, would it be possible to enable/disable tagged queuing from > camcontrol? Or to read the quirks from a config file (like Digital > UNIX does with its ddr.db file..). camcontrol negotiate allows you to temporarily enable/disable tagged queueing. If you set the DQue bit in mode page 10, it'll make the change permanent. Quirk entries are another matter altogether. In some cases, you'd probably rather have them read by the boot loader than camcontrol. It'll take a reasonable amount of design work to get an implementation that'll work correctly. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 10:16:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9262614A0A for ; Fri, 15 Oct 1999 10:16:47 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA50270; Fri, 15 Oct 1999 11:16:21 -0600 (MDT) (envelope-from ken) Message-Id: <199910151716.LAA50270@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: from Matthew Jacob at "Oct 15, 1999 09:01:38 am" To: mjacob@feral.com Date: Fri, 15 Oct 1999 11:16:20 -0600 (MDT) Cc: gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > On Fri, 15 Oct 1999, Andrew Gallatin wrote: > > >From the reports I've seen, it looks like Western Digital got their > > act together and their Ultra2 drives are OK. Could we make the quirk > > entry enable tagged queuing for Ultra2 WDE drives & disable it for > > non-ultra2 drives? > > > > Also, would it be possible to enable/disable tagged queuing from > > camcontrol? Or to read the quirks from a config file (like Digital > > UNIX does with its ddr.db file..). > > > > This is on my list to address. Which one? camcontrol already handles tagged queueing. I assume you mean quirk entries? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 10:23:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id ACE8F150A1 for ; Fri, 15 Oct 1999 10:23:40 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA07427; Fri, 15 Oct 1999 10:23:25 -0700 Date: Fri, 15 Oct 1999 10:23:25 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <199910151716.LAA50270@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quirk entries, loaded by the loader. I want to use the loader because all that getenv stuff works very very nicely thank you very much. I'm not sure "significant" design work has to go into this- just sensible work to make the table parseable. On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Matthew Jacob wrote... > > On Fri, 15 Oct 1999, Andrew Gallatin wrote: > > > >From the reports I've seen, it looks like Western Digital got their > > > act together and their Ultra2 drives are OK. Could we make the quirk > > > entry enable tagged queuing for Ultra2 WDE drives & disable it for > > > non-ultra2 drives? > > > > > > Also, would it be possible to enable/disable tagged queuing from > > > camcontrol? Or to read the quirks from a config file (like Digital > > > UNIX does with its ddr.db file..). > > > > > > > This is on my list to address. > > Which one? camcontrol already handles tagged queueing. I assume you mean > quirk entries? > > Ken > -- > Kenneth Merry > ken@kdm.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 11:44:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 6B10E15044 for ; Fri, 15 Oct 1999 11:44:21 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-165-218.villette.club-internet.fr [195.36.165.218]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA02047; Fri, 15 Oct 1999 20:44:11 +0200 (MET DST) Date: Fri, 15 Oct 1999 21:06:14 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Chris D. Faulhaber" Cc: Andrew Gallatin , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Chris D. Faulhaber wrote: > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > da0: 8683MB (17783204 512 byte sectors: 255H 63S/T 1106C) >=20 > After enabling tagged queuing on this drive (by removing the quirk entry) > and found performance about 10% slower. What kind of performance are you measuring ? Tagged command queuing is intended to improve _multithreaded IOs that is a lot more realistic IO pattern than single-threaded sequential IO. I also read some decrease of performance for DCAS for single-threaded sequential IO when increasing number of tags. Unless, guys, you just want to eat the cake and to have it, I donnot see any serious problem for these drives. May-be there is some room for improvement in their firmware. They should _not_ have been quirked to 0 tags, in my opinion, if the decrease of performance observed is for sequential IOs. At most, user should be advised to use a reasonnable number of tags or the quirk should have been more soft.=20 For the DCAS, the decrease of performances has been observed for sequential write IOs that is a great stress for a disk when write behing caching is enabled with tags enabled, but still nothing has been reported for read and especially multithreaded read IOs. Castrating a disk model=20 regarding tags due to such unreaslistic results has been unserious in my opinion.=20 When tags are enabled, the drive can overlap writes by disconnecting previous to the data phase and so get rid of part of IO latency. In such a situation, write behind caching can be disabled for some good disks without significant decrease of performances, allowing drives to perform more prefetching for read. Indeed, writing meta-data synchronously does not help, but softupdate may do.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 12:11:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.217.82.22]) by hub.freebsd.org (Postfix) with ESMTP id 46018153A4 for ; Fri, 15 Oct 1999 12:11:17 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id UAA57256; Fri, 15 Oct 1999 20:11:03 +0100 (BST) (envelope-from geoffb) Date: Fri, 15 Oct 1999 20:11:03 +0100 From: Geoff Buckingham To: Matthew Jacob Cc: Andrew Gallatin , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <19991015201103.B56536@chuggalug.clues.com> References: <14343.16009.738375.608477@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matthew Jacob on Fri, Oct 15, 1999 at 09:01:38AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > On Fri, 15 Oct 1999, Andrew Gallatin wrote: > > > > > Geoff Buckingham writes: > > > On Thu, Oct 14, 1999 at 04:55:45PM -0600, Kenneth D. Merry wrote: > > > > > > > > Western Digital drives generally aren't that great. In fact, we have > > > > disabled tagged queueing for most all Western Digital SCSI drives. > > > > (including the drives you have, above) > > > > > > > > > > I have been meaning to post on this subject for some time, while in my last > > > place of employment I bought 8 Dell PowerEdge 2300s each with six drives > > > Dell supplied Western digitals and I had really poor disk performance. > > > > > > I realised tagged queing was disabled for WDE* and removed the quirk from > > > cam_xpt.c this greatly improved the performance. Much exercising of the disks > > > also failed to cause any further problems. > > > > I'm the guy to blame for this quirk. My drives (shipped in about 60 > > older Dell Dimension XPS D300 here) have abysmal sequential write > > performance with tagged queuing enabled. There are two types of > > identifiers: > > > > pass0: Fixed Direct Access SCSI-2 device > > pass0: Serial Number WS7010610507 > > pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > > > pass1: Fixed Direct Access SCSI-2 device > > pass1: Serial Number WS7011244369 > > pass1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > > > >From the reports I've seen, it looks like Western Digital got their > > act together and their Ultra2 drives are OK. Could we make the quirk > > entry enable tagged queuing for Ultra2 WDE drives & disable it for > > non-ultra2 drives? I just got this from a former colleage, details of the drives we had: da4 at ahc0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da4: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) In my opinion these do not require the quirk. (based on bonnie results for individual disks with WCE as shipped (off i think) you get better sequential performance and more importantly for most of us better seeking) -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 12:41:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 88F6A151AF for ; Fri, 15 Oct 1999 12:41:13 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA51114; Fri, 15 Oct 1999 13:40:55 -0600 (MDT) (envelope-from ken) Message-Id: <199910151940.NAA51114@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: from Gerard Roudier at "Oct 15, 1999 09:06:14 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Fri, 15 Oct 1999 13:40:54 -0600 (MDT) Cc: cdf.lists@fxp.org (Chris D. Faulhaber), gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier wrote... > On Fri, 15 Oct 1999, Chris D. Faulhaber wrote: > > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > da0: 8683MB (17783204 512 byte sectors: 255H 63S/T 1106C) > > > > After enabling tagged queuing on this drive (by removing the quirk entry) > > and found performance about 10% slower. > > What kind of performance are you measuring ? Tagged command queuing is > intended to improve _multithreaded IOs that is a lot more realistic IO > pattern than single-threaded sequential IO. I also read some decrease of > performance for DCAS for single-threaded sequential IO when increasing > number of tags. Unless, guys, you just want to eat the cake and to have > it, I donnot see any serious problem for these drives. May-be there is > some room for improvement in their firmware. They should _not_ have been > quirked to 0 tags, in my opinion, if the decrease of performance observed > is for sequential IOs. At most, user should be advised to use a > reasonnable number of tags or the quirk should have been more soft. > > For the DCAS, the decrease of performances has been observed for > sequential write IOs that is a great stress for a disk when write behing > caching is enabled with tags enabled, but still nothing has been reported > for read and especially multithreaded read IOs. Castrating a disk model > regarding tags due to such unreaslistic results has been unserious in my > opinion. In the case of the DCAS drives, the PR author (see kern/10398) did extensive tests with bonnie, and found that both the number of random seeks per second and sequential write throughput decreased as the number of concurrent transactions allowed increased. Sequential read performance did not vary significantly when the number of tags was changed. As for the WD drives, if you'd like to find someone with a drive who is willing to run through a full set of tests at various numbers of transactions, feel free. If you can show that the number of tags should be set to something other than 0, we can change it. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 12:48:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B9896153BD for ; Fri, 15 Oct 1999 12:48:44 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p28-dn01kiryunisiki.gunma.ocn.ne.jp [210.132.6.157]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id EAA13961; Sat, 16 Oct 1999 04:48:25 +0900 (JST) Message-ID: <38077F37.ABD4D78D@newsguy.com> Date: Sat, 16 Oct 1999 04:23:35 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Randell Jesup Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 References: <199910142255.QAA46124@panzer.kdm.org> <19991015125107.A56477@chuggalug.clues.com> <14343.16009.738375.608477@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Randell Jesup wrote: > > > Or to read the quirks from a config file (like Digital > >UNIX does with its ddr.db file..). > > This would be very nice (though rather a bunch of work I assume - > you'd have to boot with generic/safe parameters until the file could > be read - or boot with a compiled-in quirks, and then after it can read the > (optional) file apply that on top of the built-in quirks - this is > probably preferable). Actually, that's not necessary. Loader can load that file before transfering control to kernel. Alas, it is the express desire of some to see a generic facility of this kind, modeled after the stuff X have, so we could have wildcards, varying degrees of specificness, and have all consults into this tables by all parts of the kernel requiring this kind of information (for instance, isa device setup) be handled by common code. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 13:17:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8816B14BC8 for ; Fri, 15 Oct 1999 13:17:49 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA51280; Fri, 15 Oct 1999 14:17:41 -0600 (MDT) (envelope-from ken) Message-Id: <199910152017.OAA51280@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <19991015201103.B56536@chuggalug.clues.com> from Geoff Buckingham at "Oct 15, 1999 08:11:03 pm" To: geoffb@chuggalug.clues.com (Geoff Buckingham) Date: Fri, 15 Oct 1999 14:17:41 -0600 (MDT) Cc: mjacob@feral.com (Matthew Jacob), gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Geoff Buckingham wrote... > > On Fri, 15 Oct 1999, Andrew Gallatin wrote: > > > >From the reports I've seen, it looks like Western Digital got their > > > act together and their Ultra2 drives are OK. Could we make the quirk > > > entry enable tagged queuing for Ultra2 WDE drives & disable it for > > > non-ultra2 drives? > > I just got this from a former colleage, details of the drives we had: > > da4 at ahc0 bus 0 target 4 lun 0 > da4: Fixed Direct Access SCSI-2 device > da4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da4: 8687MB (17793001 512 byte sectors: 255H 63S/T 1107C) > > In my opinion these do not require the quirk. > > (based on bonnie results for individual disks with WCE as shipped (off i think) > you get better sequential performance and more importantly for most of us > better seeking) I'd like to see some hard numbers for these before I change the quirk. (i.e. bonnie numbers at 1, 2, 4, 8, 16, 32, and 64 tags, with and without write caching) camcontrol can be used to change the tags and enable/disable write caching on the fly. If anyone wants to do this, see PR kern/10398 for an example of what sort of tests to run. In any case, it'll be a little tricky to do the quirk so it'll still match the non-Ultra2 WD drives that are apparantly still broken. (A "positive" quirk entry followed by the current quirk entry would probably do the trick, since the first matching quirk entry in the table is used.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 13:25: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mindy.accesscom.com (ns2.accesscom.com [205.226.156.3]) by hub.freebsd.org (Postfix) with ESMTP id 0FC8814BC8; Fri, 15 Oct 1999 13:25:03 -0700 (PDT) (envelope-from sabrina@shell.accesscom.com) Received: from shell.accesscom.com (sabrina@shell.accesscom.com [205.226.156.10]) by mindy.accesscom.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id NAA02578; Fri, 15 Oct 1999 13:25:03 -0700 Received: (from sabrina@localhost) by shell.accesscom.com (8.9.3/8.9.3/Debian/GNU) id NAA12085; Fri, 15 Oct 1999 13:25:01 -0700 From: Sabrina Minshall Message-Id: <199910152025.NAA12085@shell.accesscom.com> Subject: ahc0: Someone reset channel 0 To: questions@freebsd.org, scsi@freebsd.org Date: Fri, 15 Oct 1999 13:25:00 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi guys, I'me getting the following error message and the systems seems to freeze. Any idea what's going on? It's a 2940UW scsi adapter. ahc0: Someone reset channel A (da0:ahc0:0:6:0): SCB 0xc - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x6 (da0:ahc0:0:6:0): Queuing a BDR SCB (da0:ahc0:0:6:0): SCB 0xc - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 (da0:ahc0:0:6:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 1 SCBs aborted (da0:ahc0:0:6:0): WRITE(10). CDB: 2a 0 0 5e 4d 10 0 0 a 0 (da0:ahc0:0:6:0): ILLEGAL REQUEST asc:24,0 (da0:ahc0:0:6:0): Invalid field in CDB sks:cb,1 Here's the system configuration: <(truncated) output from dmesg> Waiting 15 seconds for SCSI devices to settle de1: autosense failed: cable problem? changing root device to da0s3a da1 at ahc0 bus 0 target 8 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Appreciate any help. Sabrina To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 14:47:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 3E4EC14A26 for ; Fri, 15 Oct 1999 14:47:40 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-229.villette.club-internet.fr [194.158.116.229]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA18856; Fri, 15 Oct 1999 23:47:26 +0200 (MET DST) Date: Sat, 16 Oct 1999 00:09:29 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <199910151940.NAA51114@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Gerard Roudier wrote... > > On Fri, 15 Oct 1999, Chris D. Faulhaber wrote: > >=20 > > > da0: Fixed Direct Access SCSI-2 device > > > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > > da0: 8683MB (17783204 512 byte sectors: 255H 63S/T 1106C) > > >=20 > > > After enabling tagged queuing on this drive (by removing the quirk en= try) > > > and found performance about 10% slower. > >=20 > > What kind of performance are you measuring ? Tagged command queuing is > > intended to improve _multithreaded IOs that is a lot more realistic IO > > pattern than single-threaded sequential IO. I also read some decrease o= f > > performance for DCAS for single-threaded sequential IO when increasing > > number of tags. Unless, guys, you just want to eat the cake and to have > > it, I donnot see any serious problem for these drives. May-be there is > > some room for improvement in their firmware. They should _not_ have bee= n > > quirked to 0 tags, in my opinion, if the decrease of performance observ= ed > > is for sequential IOs. At most, user should be advised to use a > > reasonnable number of tags or the quirk should have been more soft.=20 > >=20 > > For the DCAS, the decrease of performances has been observed for > > sequential write IOs that is a great stress for a disk when write behin= g > > caching is enabled with tags enabled, but still nothing has been report= ed > > for read and especially multithreaded read IOs. Castrating a disk model= =20 > > regarding tags due to such unreaslistic results has been unserious in m= y > > opinion.=20 >=20 > In the case of the DCAS drives, the PR author (see kern/10398) did > extensive tests with bonnie, and found that both the number of random see= ks Random IO decrease is surprising given the small number of transactions per second and the small IO bandwidth needed for the test. Anyway, such a testing just makes the drive prefetch data and then makes it have to throw prefetched data away. Using simultaneous sequential IO streams may take advantage of the prefetching (such a testing is more realistic than Bonnie seeks). Some simple combination of usual UNIX commands is sometimes a far better testing than inappropriate benchmarks. > per second and sequential write throughput decreased as the number of > concurrent transactions allowed increased. Sequential read performance > did not vary significantly when the number of tags was changed. > As for the WD drives, if you'd like to find someone with a drive who is > willing to run through a full set of tests at various numbers of transact= ions, > feel free. If you can show that the number of tags should be set to > something other than 0, we can change it. I donnot know of WD drives and will probably never know about :-), but just based on the postings, I just thought that these drives were not proven to deserve a so severe punishment. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 15:14:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 3492D15333 for ; Fri, 15 Oct 1999 15:14:41 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA52284; Fri, 15 Oct 1999 16:14:29 -0600 (MDT) (envelope-from ken) Message-Id: <199910152214.QAA52284@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: from Gerard Roudier at "Oct 16, 1999 00:09:29 am" To: groudier@club-internet.fr (Gerard Roudier) Date: Fri, 15 Oct 1999 16:14:29 -0600 (MDT) Cc: cdf.lists@fxp.org (Chris D. Faulhaber), gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier wrote... > On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > > Gerard Roudier wrote... > > > For the DCAS, the decrease of performances has been observed for > > > sequential write IOs that is a great stress for a disk when write behing > > > caching is enabled with tags enabled, but still nothing has been reported > > > for read and especially multithreaded read IOs. Castrating a disk model > > > regarding tags due to such unreaslistic results has been unserious in my > > > opinion. > > > > In the case of the DCAS drives, the PR author (see kern/10398) did > > extensive tests with bonnie, and found that both the number of random seeks > > Random IO decrease is surprising given the small number of transactions > per second and the small IO bandwidth needed for the test. Anyway, such a > testing just makes the drive prefetch data and then makes it have to throw > prefetched data away. Using simultaneous sequential IO streams may take > advantage of the prefetching (such a testing is more realistic than Bonnie > seeks). Some simple combination of usual UNIX commands is sometimes a far > better testing than inappropriate benchmarks. Well, if you've got ideas for a better benchmark, why not write one, or point people to a better benchmark? Bonnie may not be a "great" benchmark, but it's better than a simple sequential I/O benchmark. And it's more precise than just telling people to run a bunch of random UNIX commands. Greg Lehey's rawio program (ftp://ftp.lemis.com/pub/rawio.tar.gz) seems like it might do a reasonable job (I haven't used it, however), but the only problem with it is that it works on raw devices. (There's not much you can do to get around that if you want to avoid possible buffer cache interactions that come with going through the filesystem.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 16:18:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 2746714BC8 for ; Fri, 15 Oct 1999 16:18:44 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id TAA26553; Fri, 15 Oct 1999 19:12:09 -0400 (EDT) Reply-To: Randell Jesup To: scsi@FreeBSD.ORG, Michael@sinz.org (Mike Sinz) Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 References: <199910152017.OAA51280@panzer.kdm.org> From: Randell Jesup Date: 15 Oct 1999 19:14:15 +0000 In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 15 Oct 1999 14:17:41 -0600 (MDT)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: >> (based on bonnie results for individual disks with WCE as shipped (off i think) >> you get better sequential performance and more importantly for most of us >> better seeking) > >I'd like to see some hard numbers for these before I change the quirk. (i.e. >bonnie numbers at 1, 2, 4, 8, 16, 32, and 64 tags, with and without write >caching) camcontrol can be used to change the tags and enable/disable >write caching on the fly. If anyone wants to do this, see PR kern/10398 >for an example of what sort of tests to run. Knowing SCSI and how drives and FS's work, there might really be a benefit in a multi-tasking OS (especially with multiple filesystems) to running at least a small number of tags even at the cost of 5% on sequential writes (which is the order that we're talking of). There's probably no need for 32 or 64, but 4 or 8, maybe 16 on this drive might be reasonable. Looking at the bonnie results from 10398: write cache enabled -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU Number of Tags NO 100 7222 89.2 6801 21.8 2347 8.5 7330 93.3 7368 14.6 226.5 4.7 2 100 7263 90.3 6357 20.3 2730 9.9 7025 90.5 7321 14.9 209.4 4.6 3 100 7115 88.1 6406 20.8 2289 8.9 7307 93.9 7335 15.0 212.6 4.5 4 100 7281 90.0 6204 20.8 2278 9.1 7267 93.7 7350 15.3 217.6 4.8 8 100 7236 89.7 6007 19.4 2284 8.7 7239 93.1 7374 14.9 213.4 4.5 16 100 6775 83.7 6110 19.5 2283 8.7 7239 93.1 7380 14.8 217.8 4.8 32 100 7265 89.9 4385 13.9 2274 8.7 7302 93.7 7324 14.5 218.9 4.5 64 100 6731 83.3 3038 9.8 2271 8.7 7337 94.6 7356 14.7 213.6 4.4 Character sequential output is basically unaffected by tags (bounces around a lot). Block output goes down; one jump from NO to 2 of 450K (but that's suspect, since it goes up 50K for 3); overall after the initial drop it goes down circa 20K-ish per tag through 16 tags; it gets worse above 16. Rewrite is unaffected. Input is unaffected. Seeks are apparently unaffected (there's a small drop, but it may well be within measurement error - certainly there's no continuing drop). Perhaps a more interesting test would be a wall-time comparison with a make world or some such - lots of writing and reading in a real-world sort of situation. Good multitasking disk benchmarks are hard to come by. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 16:34: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 5A335153F8 for ; Fri, 15 Oct 1999 16:33:48 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-112-57.villette.club-internet.fr [194.158.112.57]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id BAA27009; Sat, 16 Oct 1999 01:33:33 +0200 (MET DST) Date: Sat, 16 Oct 1999 01:55:36 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <199910152214.QAA52284@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > Gerard Roudier wrote... > > On Fri, 15 Oct 1999, Kenneth D. Merry wrote: > > > Gerard Roudier wrote... > > > > For the DCAS, the decrease of performances has been observed for > > > > sequential write IOs that is a great stress for a disk when write b= ehing > > > > caching is enabled with tags enabled, but still nothing has been re= ported > > > > for read and especially multithreaded read IOs. Castrating a disk m= odel=20 > > > > regarding tags due to such unreaslistic results has been unserious = in my > > > > opinion.=20 > > >=20 > > > In the case of the DCAS drives, the PR author (see kern/10398) did > > > extensive tests with bonnie, and found that both the number of random= seeks > >=20 > > Random IO decrease is surprising given the small number of transactions > > per second and the small IO bandwidth needed for the test. Anyway, such= a > > testing just makes the drive prefetch data and then makes it have to th= row > > prefetched data away. Using simultaneous sequential IO streams may take > > advantage of the prefetching (such a testing is more realistic than Bon= nie > > seeks). Some simple combination of usual UNIX commands is sometimes a f= ar > > better testing than inappropriate benchmarks. >=20 > Well, if you've got ideas for a better benchmark, why not write one, or > point people to a better benchmark? The problem is indeed the 'one' benchmark approach for deciding about the average of the infinity of possible situations. I will never write any benchmark program for the reason I may need a different one based on what I want to check or test at any time. There is enough tools under UNIX to build some simple scenarion on need and to perform several runs with different configurations of the parameters you want to test actual effects on your scenario and then compare results. For tagged queueing depth effects, usual benchmarks have proven to be inappropriate. For example, simply running N concurrent file readings (different files)=20 from the same disk gives more relevant results than Bonnie and it takes minutes to set it up. Indeed, this is not enough for the results to have full relevance, this was just the simplest example that comes to mind. > Bonnie may not be a "great" benchmark, but it's better than a simple > sequential I/O benchmark. And it's more precise than just telling people > to run a bunch of random UNIX commands. The ramdom approach looks to me as irrelevant that the single-threaded IO approach regarding effects of tagged commands. > Greg Lehey's rawio program (ftp://ftp.lemis.com/pub/rawio.tar.gz) seems > like it might do a reasonable job (I haven't used it, however), but the > only problem with it is that it works on raw devices. (There's not much > you can do to get around that if you want to avoid possible buffer cache > interactions that come with going through the filesystem.) Thanks for the URL. Will have a look to this program. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 15 16:53:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.217.82.22]) by hub.freebsd.org (Postfix) with ESMTP id AA8A414D4F for ; Fri, 15 Oct 1999 16:53:15 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id AAA57754; Sat, 16 Oct 1999 00:53:11 +0100 (BST) (envelope-from geoffb) Date: Sat, 16 Oct 1999 00:53:11 +0100 From: Geoff Buckingham To: Randell Jesup Cc: scsi@FreeBSD.ORG, Mike Sinz Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <19991016005311.C56536@chuggalug.clues.com> References: <199910152017.OAA51280@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Randell Jesup on Fri, Oct 15, 1999 at 07:14:15PM +0000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Oct 15, 1999 at 07:14:15PM +0000, Randell Jesup wrote: > Looking at the bonnie results from 10398: > > write cache enabled > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > Number of Tags > NO 100 7222 89.2 6801 21.8 2347 8.5 7330 93.3 7368 14.6 226.5 4.7 > 2 100 7263 90.3 6357 20.3 2730 9.9 7025 90.5 7321 14.9 209.4 4.6 > 3 100 7115 88.1 6406 20.8 2289 8.9 7307 93.9 7335 15.0 212.6 4.5 > 4 100 7281 90.0 6204 20.8 2278 9.1 7267 93.7 7350 15.3 217.6 4.8 > 8 100 7236 89.7 6007 19.4 2284 8.7 7239 93.1 7374 14.9 213.4 4.5 > 16 100 6775 83.7 6110 19.5 2283 8.7 7239 93.1 7380 14.8 217.8 4.8 > 32 100 7265 89.9 4385 13.9 2274 8.7 7302 93.7 7324 14.5 218.9 4.5 > 64 100 6731 83.3 3038 9.8 2271 8.7 7337 94.6 7356 14.7 213.6 4.4 Having brough bonnie into this I must offer some words of caution. Bonnie only has three seekers for the random seek test, which is potentialy very different from a heavily loaded qmail/exim/apache box. Most machines nowdays have a lot of RAM so large testfiles need to be used to minimise cacheing effects (I have allways used -s 1024 but this takes some time :-) -- GeoffB> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 2:43:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlas.rccn.net (atlas.rccn.net [193.136.7.1]) by hub.freebsd.org (Postfix) with SMTP id 138861543D for ; Sat, 16 Oct 1999 02:43:08 -0700 (PDT) (envelope-from jpsp@rccn.net) Received: (qmail 3652 invoked by uid 1021); 16 Oct 1999 09:43:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Oct 1999 09:43:08 -0000 Date: Sat, 16 Oct 1999 10:43:08 +0100 (WEST) From: Joao Pagaime To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 - It works! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Oct 1999, Joao Pagaime wrote: > > On Thu, 14 Oct 1999, Kenneth D. Merry wrote: > > > Joao Pagaime wrote... <.....> > > And the kernel compiles, so I'll try it during the > weekend (It's a production machine) - I'll let you know. > Well, I did try the patch you sent. I also did a very simple naive test, that consisted in launching 10 processes concurrently. These processes simply wrote 100MB to the disk (one disk) The average time it took (3 runs & 10 procs) was 58.2 seconds without the patch (with write cache and no tag queueing - I think) With the patch (with write cache and tag queueing), it took 58.5 secs. I guess I'll keep the patch - the difference is negligible. I don't think these tests are representative any way, but I don't have the machine-time to make any further tests. In all cases it's one of the fastests computer on my operation center... Thanks again, Joao Pagaime PS: I have another Dell PowerEdge 4300 with Solaris for Intel that presents poor disk performance also - I guess that machine only works well out of the box with Dell's own drivers... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 4:32:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id C6AD214A25 for ; Sat, 16 Oct 1999 04:32:21 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-99-102.villette.club-internet.fr [194.158.99.102]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id NAA21592; Sat, 16 Oct 1999 13:32:12 +0200 (MET DST) Date: Sat, 16 Oct 1999 13:54:18 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <199910152214.QAA52284@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have run some scenarii using multi-threaded IO streams under FreeBSD and result is that the overall performance results have been significantly better with tagged command queueing disabled. I used a Cheetah LVD and a DRVS LVD. What seems to happen when tagged command queuing is disabled, is that the IO scheduling policy can stay a long time (seconds) on one IO stream and then switch to another one, and so on ... This seem to be due (just guessing) to a side effect of the disksort algorithm that just makes the supposed multi-threaded IO streams become a succession of single-threaded IO streams that may each last seconds. If I am right (fill free to fix me if needed), it is actually the OS that might be inadequate for tagged command queuing benchmarking. Bug or feature ? ;-) G=E9rard.=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 6:38:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 7FC9C14D3A for ; Sat, 16 Oct 1999 06:38:34 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-168-9.villette.club-internet.fr [195.36.168.9]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id PAA09647; Sat, 16 Oct 1999 15:38:28 +0200 (MET DST) Date: Sat, 16 Oct 1999 16:00:33 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Geoff Buckingham Cc: Randell Jesup , scsi@FreeBSD.ORG, Mike Sinz Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: <19991016005311.C56536@chuggalug.clues.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Oct 1999, Geoff Buckingham wrote: > On Fri, Oct 15, 1999 at 07:14:15PM +0000, Randell Jesup wrote: > > =09Looking at the bonnie results from 10398: > >=20 > > write cache enabled > > -------Sequential Output-------- ---Sequential Input-- --= Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --= Seeks--- > > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /= sec %CPU > > Number of Tags > > NO 100 7222 89.2 6801 21.8 2347 8.5 7330 93.3 7368 14.6 22= 6.5 4.7 > > 2 100 7263 90.3 6357 20.3 2730 9.9 7025 90.5 7321 14.9 20= 9.4 4.6 > > 3 100 7115 88.1 6406 20.8 2289 8.9 7307 93.9 7335 15.0 21= 2.6 4.5 > > 4 100 7281 90.0 6204 20.8 2278 9.1 7267 93.7 7350 15.3 21= 7.6 4.8 > > 8 100 7236 89.7 6007 19.4 2284 8.7 7239 93.1 7374 14.9 21= 3.4 4.5 > > 16 100 6775 83.7 6110 19.5 2283 8.7 7239 93.1 7380 14.8 21= 7.8 4.8 > > 32 100 7265 89.9 4385 13.9 2274 8.7 7302 93.7 7324 14.5 21= 8.9 4.5 > > 64 100 6731 83.3 3038 9.8 2271 8.7 7337 94.6 7356 14.7 21= 3.6 4.4 >=20 > Having brough bonnie into this I must offer some words of caution. >=20 > Bonnie only has three seekers for the random seek test, which is potentia= ly > very different from a heavily loaded qmail/exim/apache box. Indeed. As I noted in some other posting, it seems there is some subtle side effect when tags are disabled that makes multithreaded IO-streams replaced by a succession of single-threaded IO-streams that may last seconds. Just thinking to disk IOs sorting + reading ahead at the same time let guess the reasons.=20 I also suggest to measure _interactivity_. No need to be overall faster if a user that download a large file, for example, can take precedence over another user that download a small file due to the IO scheduling policy performing mostly batching instead of multi-threaded IOs.=20 > Most machines nowdays have a lot of RAM so large testfiles need to be use= d > to minimise cacheing effects (I have allways used -s 1024 but this takes > some time :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 10:45: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 95AFB14CE2 for ; Sat, 16 Oct 1999 10:44:53 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA12980; Sat, 16 Oct 1999 10:44:10 -0700 Date: Sat, 16 Oct 1999 10:44:10 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: "Kenneth D. Merry" , "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What seems to happen when tagged command queuing is disabled, is that the > IO scheduling policy can stay a long time (seconds) on one IO stream and > then switch to another one, and so on ... This seem to be due (just > guessing) to a side effect of the disksort algorithm that just makes the > supposed multi-threaded IO streams become a succession of single-threaded > IO streams that may each last seconds. It's conceivable that with tagged queing there *shouldn't* be a disksort function on the processor except with respect to synchronization barriers. > > If I am right (fill free to fix me if needed), it is actually the OS that > might be inadequate for tagged command queuing benchmarking. Bug or > feature ? ;-) Hard to say. Depends on the job mix. The same arguments were advanced (successfully in some cases for the time) to either disable using disconnect/reconnect or also, in one classic case at Sun, to hang out in the interrupt service routine "a bit" when getting status to also get the command complete without having to take another (expensive) interrupt (quite different hardware than the current set). I suspect that the right thing here is to to ultimately do completely adaptive scheduling with hints- this would also solve the arguments I constantly have with Matt Dillon over whether MAXPHYS is too small at 128KB (it most certainly is if you have a job mix that's mainly large sequential writes or reads)- but until that point, document the tools that allow you to tune things and tell users "Knock yerself out... have a great time!" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 12:36:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id 6FAAE15324 for ; Sat, 16 Oct 1999 12:36:08 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-163-105.villette.club-internet.fr [195.36.163.105]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA12749; Sat, 16 Oct 1999 21:16:09 +0200 (MET DST) Date: Sat, 16 Oct 1999 21:38:15 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Matthew Jacob Cc: "Kenneth D. Merry" , "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Oct 1999, Matthew Jacob wrote: > > What seems to happen when tagged command queuing is disabled, is that t= he > > IO scheduling policy can stay a long time (seconds) on one IO stream an= d > > then switch to another one, and so on ... This seem to be due (just > > guessing) to a side effect of the disksort algorithm that just makes th= e > > supposed multi-threaded IO streams become a succession of single-thread= ed > > IO streams that may each last seconds. >=20 > It's conceivable that with tagged queing there *shouldn't* be a disksort > function on the processor except with respect to synchronization=20 > barriers. Just disksort + asynchronous read-ahead and 1 IO at a time seems to make the O/S choose the same IO stream for a too large amount of time. Other IO streams may starve a too long time leading to bad interactivity.=20 A disksort is certainly not a bad thing, but some simple heuristic that avoids the above should be considered.=20 > > If I am right (fill free to fix me if needed), it is actually the OS th= at > > might be inadequate for tagged command queuing benchmarking. Bug or > > feature ? ;-) >=20 >=20 > Hard to say.=20 Not for me, by the way. ;-) > Depends on the job mix. The same arguments were advanced > (successfully in some cases for the time) to either disable > using disconnect/reconnect or also, in one classic case at Sun, to hang > out in the interrupt service routine "a bit" when getting status to also > get the command complete without having to take another (expensive) > interrupt (quite different hardware than the current set). Hmmm... This can only happened with too old or poor designed SCSI controllers. Well designed SCSI controllers do not interrupt uselessly. About disabling SCSI disconnections, I would have been glad not to have read that. Note that I am not going to ever choose a SUN originated system for numerous reasons. ;-) > I suspect that the right thing here is to to ultimately do completely > adaptive scheduling with hints- this would also solve the arguments I May be, a simple but kind bug that add some mess-up to disksort would solve the problem. :-) > constantly have with Matt Dillon over whether MAXPHYS is too small at > 128KB (it most certainly is if you have a job mix that's mainly large > sequential writes or reads)- but until that point, document the tools tha= t > allow you to tune things and tell users "Knock yerself out... have a grea= t > time!" I have measured 35MB/s throughtput on a 80MB/s LVD SCSI BUS using 4K actual IO chunks. This let me think that 64 KB is not that small given not ridiculouly high IO latency. May-be for Ultra-160 (and probably for future Ultra-320), 64KB will be to small. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 12:47:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 050511543D for ; Sat, 16 Oct 1999 12:47:09 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA13390; Sat, 16 Oct 1999 12:46:57 -0700 Date: Sat, 16 Oct 1999 12:46:57 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: "Kenneth D. Merry" , "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hmmm... This can only happened with too old or poor designed SCSI > controllers. Well designed SCSI controllers do not interrupt uselessly. > About disabling SCSI disconnections, I would have been glad not to have > read that. Note that I am not going to ever choose a SUN originated > system for numerous reasons. ;-) I'm talking about 14 years ago, btw... So, before you slam Sun for this, remember it was pretty good for the time and price class. I would buy Suns *now*, but for other reasons and for certain properties that may popular OSS systems have no clue about yet. > > > I suspect that the right thing here is to to ultimately do completely > > adaptive scheduling with hints- this would also solve the arguments I > > May be, a simple but kind bug that add some mess-up to disksort would > solve the problem. :-) > > > constantly have with Matt Dillon over whether MAXPHYS is too small at > > 128KB (it most certainly is if you have a job mix that's mainly large > > sequential writes or reads)- but until that point, document the tools that > > allow you to tune things and tell users "Knock yerself out... have a great > > time!" > > I have measured 35MB/s throughtput on a 80MB/s LVD SCSI BUS using 4K > actual IO chunks. This let me think that 64 KB is not that small given not > ridiculouly high IO latency. May-be for Ultra-160 (and probably for future > Ultra-320), 64KB will be to small. Again- it depends. I doubt that it's the bus speed that makes this a fine thing here- it's very likely the faster microprocessors on the newer LVD disks. Fibre Channel disks have some of the same properties, but even better is the fact that non-data phases pretty much don't exist in fibre channel, so there's no such thing as blowing through a 4k data phase at 40Mhz+ only to sit and pick your nose for hundreds of microseconds for status and message in and bus settle delay and arb delay..... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 12:55:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AA6D114C48 for ; Sat, 16 Oct 1999 12:55:09 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA13415; Sat, 16 Oct 1999 12:54:58 -0700 Date: Sat, 16 Oct 1999 12:54:58 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: "Kenneth D. Merry" , "Chris D. Faulhaber" , Andrew Gallatin , scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I have measured 35MB/s throughtput on a 80MB/s LVD SCSI BUS using 4K > > actual IO chunks. This let me think that 64 KB is not that small given not > > ridiculouly high IO latency. May-be for Ultra-160 (and probably for future > > Ultra-320), 64KB will be to small. Oh, yeah- to be picky about this- it isn't an 80MB/s bus. It's a 40MHz bus that when transferring 16 bits of data is transferring data at 80MB/s. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 16 20:28:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9551B14CD0 for ; Sat, 16 Oct 1999 20:28:00 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA64434; Sat, 16 Oct 1999 21:26:31 -0600 (MDT) (envelope-from ken) Message-Id: <199910170326.VAA64434@panzer.kdm.org> Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 In-Reply-To: from Gerard Roudier at "Oct 16, 1999 01:54:18 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Sat, 16 Oct 1999 21:26:31 -0600 (MDT) Cc: cdf.lists@fxp.org (Chris D. Faulhaber), gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier wrote... > > I have run some scenarii using multi-threaded IO streams under FreeBSD and > result is that the overall performance results have been significantly > better with tagged command queueing disabled. I used a Cheetah LVD and a > DRVS LVD. > > What seems to happen when tagged command queuing is disabled, is that the > IO scheduling policy can stay a long time (seconds) on one IO stream and > then switch to another one, and so on ... This seem to be due (just > guessing) to a side effect of the disksort algorithm that just makes the > supposed multi-threaded IO streams become a succession of single-threaded > IO streams that may each last seconds. Yes, there could be an odd interaction between running multiple streams with tagged queueing and the sorting algorithm. I can certainly see how this could present a problem. > If I am right (fill free to fix me if needed), it is actually the OS that > might be inadequate for tagged command queuing benchmarking. Bug or > feature ? ;-) If you'd like to test your theory about the disksort algorithm, try replacing the bufqdisksort() in dastrategy() (sys/cam/scsi/scsi_da.c) with bufq_insert_tail(). That way, the read/write requests will go through in FIFO order. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message