From owner-freebsd-current Thu Jun 4 15:31:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24158 for freebsd-current-outgoing; Thu, 4 Jun 1998 15:31:08 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23915; Thu, 4 Jun 1998 15:30:14 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id AAA29556; Fri, 5 Jun 1998 00:29:41 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id AAA01002; Fri, 5 Jun 1998 00:01:02 +0200 (CEST) X-Face: " Date: Fri, 5 Jun 1998 00:01:01 +0200 From: Stefan Esser To: shimon@simon-shapiro.org, Bob Willcox Cc: 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 Mail-Followup-To: shimon@simon-shapiro.org, Bob Willcox , Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Mike Smith , Greg Lehey , Stefan Esser References: <19980603073200.A16652@pmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Simon Shapiro on Thu, Jun 04, 1998 at 12:12:30PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. > 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