Date: Fri, 5 Jun 1998 08:54:59 -0500 From: Bob Willcox <bob@pmr.com> To: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com>, Michael Hancock <michaelh@cet.co.jp>, "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>, tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>, Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>, Stefan Esser <se@FreeBSD.ORG> Subject: Re: DPT driver fails and panics with Degraded Array Message-ID: <19980605085459.A9510@pmr.com> In-Reply-To: <19980605000101.27550@mi.uni-koeln.de>; from Stefan Esser on Fri, Jun 05, 1998 at 12:01:01AM %2B0200 References: <19980603073200.A16652@pmr.com> <XFMail.980604121230.shimon@simon-shapiro.org> <19980605000101.27550@mi.uni-koeln.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 05, 1998 at 12:01:01AM +0200, Stefan Esser wrote: > On 1998-06-04 12:12 -0400, Simon Shapiro <shimon@simon-shapiro.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980605085459.A9510>