Date: Fri, 5 Jun 1998 00:01:01 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com> Cc: 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: <19980605000101.27550@mi.uni-koeln.de> In-Reply-To: <XFMail.980604121230.shimon@simon-shapiro.org>; from Simon Shapiro on Thu, Jun 04, 1998 at 12:12:30PM -0400 References: <19980603073200.A16652@pmr.com> <XFMail.980604121230.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > DPT_INTR_DELAY: Will cause the interrupt service routine to spin a little > bit, giving the hardware chance to settle a bit before dpt_intr gets all > excited about it. Is this really necessary with certain revisions of the DPT firmware ? Reading a device register should delay just for the minimum time required. Did you try that ? Regards, STefan 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?19980605000101.27550>