From owner-freebsd-hackers Sat Nov 14 15:19:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25272 for freebsd-hackers-outgoing; Sat, 14 Nov 1998 15:19:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25267 for ; Sat, 14 Nov 1998 15:19:39 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA25287; Sat, 14 Nov 1998 16:19:13 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd025276; Sat Nov 14 16:19:12 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA26572; Sat, 14 Nov 1998 16:19:06 -0700 (MST) From: Terry Lambert Message-Id: <199811142319.QAA26572@usr02.primenet.com> Subject: Re: SCSI vs. DMA33.. To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 14 Nov 1998 23:19:05 +0000 (GMT) Cc: grog@lemis.com, gibbs@narnia.plutotech.com, hackers@FreeBSD.ORG In-Reply-To: <199811130529.VAA01053@apollo.backplane.com> from "Matthew Dillon" at Nov 12, 98 09:29:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think where overlapping commands have their greatest > advantage is when a command to a drive has a certain > latency associated with it that prevents you from issuing > another command to the drive that might be completed more > efficiently by the drive You mean like "write" or "read"? 8-). PS: I think your Promise two channel concurrent access problems may be because of the way you compiled your kernel; make sure you are not using the CMD640B workaround (where we intentionally do not access the second channel while the first is active, and vice-versa because the IDE controller chip will silently interrupt transfers in progress). Also make sure that the workaround is not being triggered by onboard Intel or other IDE chips known to have the same problem (this may occur silently because we can detect buggy Intel chips, but we can't detect CMD640B's relaibly). Probably you want to put in a printf. See the relevent CMD640B code. PS: Your SCSI drives appear to suck; it is not fair for you to blame this on SCSI instead of on the drive manufacturer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message