From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Grundler Date: Wed, 25 Aug 2004 15:42:37 +0000 Subject: Re: [RFC&PATCH 1/2] PCI Error Recovery (readX_check) Message-Id: <20040825154237.GA19447@cup.hp.com> List-Id: References: <412AD123.8050605@jp.fujitsu.com> <1093417267.2170.47.camel@gaston> In-Reply-To: <1093417267.2170.47.camel@gaston> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: Linus Torvalds , Hidetoshi Seto , Linux Kernel list , linux-ia64@vger.kernel.org On Wed, Aug 25, 2004 at 05:01:08PM +1000, Benjamin Herrenschmidt wrote: ... > Most drivers already have such a low level lock though, so we may end > up replacing it with a bridge-based lock... but depending on the architecture, > that would end up sync'ing lots of drivers on the same lock, which may not > be good especially if we have no checking to do... multiple drivers acquiring the same bridge lock? ugh. Which bridge sees an error may be a parent (or child) of the PCI bridge we are monitoring. I suspect we will have to live with multiple devices being impacted by errors on a bus and the error recovery notify/resyncronize with all impacted devices. Does anyone expect to recover from devices attempting unmapped DMA? Ie an IOMMU which services multiple PCI busses getting a bad DMA address will cause the next MMIO read by any of the (grandchildren) PCI devices to see an error (MCA on IA64). I'm asking only to determine if this is outside the scope of what the PCI error recovery is trying to support. > I don't know what is the best thing to do here... The arch is the one to > know what is the granularity of the error management (per slot ? per segment > or per domain ?) and so to know what kind of lock is needed... Yeah...I guess my comments are along the same vein. grant