From owner-freebsd-current Fri Jun 5 06:56:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25051 for freebsd-current-outgoing; Fri, 5 Jun 1998 06:56:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from luke.pmr.com (luke.pmr.com [207.170.114.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24843; Fri, 5 Jun 1998 06:55:11 -0700 (PDT) (envelope-from bob@luke.pmr.com) Received: (from bob@localhost) by luke.pmr.com (8.8.8/8.8.8) id IAA09892; Fri, 5 Jun 1998 08:54:59 -0500 (CDT) (envelope-from bob) Message-ID: <19980605085459.A9510@pmr.com> Date: Fri, 5 Jun 1998 08:54:59 -0500 From: Bob Willcox To: shimon@simon-shapiro.org, Bob Willcox , Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Mike Smith , Greg Lehey , Stefan Esser Subject: Re: DPT driver fails and panics with Degraded Array Reply-To: Bob Willcox References: <19980603073200.A16652@pmr.com> <19980605000101.27550@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980605000101.27550@mi.uni-koeln.de>; from Stefan Esser on Fri, Jun 05, 1998 at 12:01:01AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jun 05, 1998 at 12:01:01AM +0200, Stefan Esser wrote: > On 1998-06-04 12:12 -0400, Simon Shapiro wrote: > > Many of these problems are actually (arguabbly?) induced by timing problems > > on the PCI bus. Certain PCI-PCI bridges (or even motherboard ``main'' > > chipsets will deliver interrupts, I/O bus transactions and memory > > transactions out of order when hammered very rapidly, under heavy load, or > > both. We proved it clearly with certain ``industrial'' computers, and > > certain motherboards, by making the symptoms go away (or drastically > > change) as you move the DPT, video cards, Ethernet cards, etc. from slot to > > slot. > > This is a design "feature" of PCI, actually, and well documented. > > The interrupt lines are directly connected to the chip-set (or > possibly the CPU in non-Intel PCI systems) and for that reason, > there may for example be as many outstanding memory writes in > write-buffers as their FIFO depths allow, when the end-of-transfer > interrupt is recognized by the CPU. > > There is a documented protocol to flush all write buffers: Just > read some device register at the start of the interrupt handler > (i.e. before trying to access common data structures in memory, > that are used for communication between CPU and an intelligent > device). The read will be blocked until all buffers are flushed. Hmm, well my AIX device driver did this. The first thing it did was to read the HA_AUX_STATUS register on the adapter to see if an interrupt was pending for it (a pretty common thing to do I think). Note that I never saw the problem running on my (Motorola) UP test system. Bull saw it quite regularly on their MP systems, though. -- Bob Willcox While your friend holds you affectionately by both bob@luke.pmr.com your hands you are safe, for you can watch both of Austin, TX his. -- Ambrose Bierce, "The Devil's Dictionary" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message