Re: [Ksummit-discuss] [CORE TOPIC] Device error handling / reporting / isolation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2014-05-09 at 13:31 +0200, Laurent Pinchart wrote:
> 
> The latter will likely require a mix of generic code for device isolation 
> and/or reset (when possible) and driver-specific code for proper recovery.

We already have some amount of hooks that drivers can implement for that
but most of the core and policy are a mixture of HW facilities and
platform specific code, at least for PowerPC EEH. But ACPI/AER somewhat
biggy-backs in the same hooks today so I think the driver side interface
is a good start.

We do want to improve reporting if possible (ie, some IOMMUs will tell
us more about the actual error than others).
>  A
> fast reaction to prevent more faults from being generated should be coupled 
> with a slower reaction to fix the actual cause of the problem. I expect the 
> problem to be fatal in most cases, and, for IOMMUs again, usually caused by a 
> software bug rather than a hardware misbehaviour (although the latter can of 
> course happen). From an overall system point of view preventing the denial of 
> service that follows such errors (caused by kernel log flooding for instance, 
> or by the IOMMU being unable to serve other bus masters) could be our first 
> priority.

Don't discount HW issues and the effect of random bit flips on crappy HW
using cheap latches and no ECC or even parity on its internal busses inside
very noisy environments such as ... your computer :-)

Cheers,
Ben.