From owner-freebsd-scsi Wed Sep 15 1:39: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 5C79E14BD7 for ; Wed, 15 Sep 1999 01:39: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 BAA17274; Wed, 15 Sep 1999 01:38:13 -0700 Date: Wed, 15 Sep 1999 01:39:48 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Don Lewis Cc: Andrew Gallatin , "Justin T. Gibbs" , scsi@FreeBSD.ORG, anderson@cs.duke.edu Subject: Re: data corruption when using aic7890 In-Reply-To: <199909150836.BAA17105@salsa.gv.tsc.tdk.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 Sep 15, 1:21am, Matthew Jacob wrote: > } Subject: Re: data corruption when using aic7890 > } > } > I wonder if it might be botching PCI MWI transactions. Is there a way > } > to get this beast to just use plain PCI Memory Write transactions (with > } > the obvious performance penalty)? > } > } Umm- can't you clear the INVAL bit in the PCI command register? See > } ahc_pci_attach where it enables BUS mastering.. > > Yeah, I forgot that this was a standard bit in the PCI command register. > According to the PCI spec it should already default to being off after > reset (unless the BIOS is enabling it). It looks like the driver > currently doesn't touch it. > > It would be an interesting experiment to see what this bit is set to > and to turn it off it is on. Maybe this can even be done from the BIOS > setup ... Or do it in the driver. Now that I think about it, I could easily imagine massive breakage for unaligned transfers if Adaptec pooched it by assuming MWI would be always enabled by drivers . -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message