Messages in this thread | | | Date | Wed, 25 Aug 2004 00:20:45 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFC&PATCH 1/2] PCI Error Recovery (readX_check) |
| |
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.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |