[Intel-gfx] [PATCH 07/10] drm/i915: print Gen5+ CPU poison interrupts

[Jesse Barnes]

On Fri, 8 Feb 2013 17:54:23 -0200
Paulo Zanoni <przanoni at gmail.com> wrote:

> Hi
> 
> 2013/2/8 Jesse Barnes <jbarnes at virtuousgeek.org>:
> > On Fri,  8 Feb 2013 17:35:18 -0200
> > Paulo Zanoni <przanoni at gmail.com> wrote:
> >
> >> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
> >>
> >> On ILK/SNB all we need to do is to enable the "poison" bit, but on
> >> IVB/HSW we need to enable the CPU error interrupt register, which is
> >> responsible not only for poison interrupts, but also other things.
> >> This includes the "unclaimed register" interrupt, so on the IVB irq
> >> handler we now need to: (i) check whether the interrupt was triggered by an
> >> unclaimed register and (ii) mask the error interrupt bit so we don't
> >> risk generating "unclaimed register" interrupts form inside the
> >> interrupt handler.
> >>
> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> >> ---
> >
> > OTOH there's nothing the user can do about it... so we might do a
> > WARN_ONCE or something here instead.
> 
> Well, so far I haven't seen the message. If we conclude it happens
> *too much*, then we can use WARN_ONCE.
> 
> > But even then, I'm not sure
> > there's much *we* can do about these, as they indicate a corruption in
> > the communication between the CPU and PCH.
> 
> At least if we get the message we may be able to understand and/or
> reproduce the problems. So far we don't even know whether the problem
> is happening or not... And when there's a display bug, we don't know
> if it's caused by "poison".

Ok I guess the DRM_ERROR won't hurt if/until we see reports.  Then we
can dig in and see if keeping the message makes sense or not.

-- 
Jesse Barnes, Intel Open Source Technology Center