Re: [RFC&PATCH 1/2] PCI Error Recovery (readX_check)

From: Linus Torvalds <>
Date: 2004-08-25 17:20:45
On Wed, 25 Aug 2004, Benjamin Herrenschmidt wrote:
> Well, I'm not sure about all this... part of the problem is that drivers
> commonly need to also do IOs from interrupts. And another driver may
> "pollute" us too, depending on how the HW & bridge are designed. So we
> really also want to disable interrupts, we may need a "flags" around (could
> be burried into the cookie stuff though as an arch specific thing)

Good point. I believe you _do_ end up having to do that, like it or not.

Because if you don't lock the bridge (or whatever the entity is that keeps 
track of errors), the whole exercise is kind of pointless. If two drivers 
try to do error checking at the same time, and will potentially clear the 
errors of each other, causing the errors to get lost, the whole recovery 
infrastructure is clearly worthless.

> 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... 

Some serialization will happen. Inevitable. See above.

The "good news" is that I doubt very many drivers will care enough to do
this. I suspect you'll only have a few very specific drivers used in 
fault-tolerant circumstances, where you care more about the errors than 
about the inevitable serialization.

> 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...

It will have to depend on the bus setup. Not arch-specific per se, but 
clearly specific to the bus controllers in question. 

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Wed Aug 25 03:21:06 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:30 EST