lkml.org 
[lkml]   [2004]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.092 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site