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

[Paulo Zanoni]

Hi

2013/2/9 Ben Widawsky <ben at bwidawsk.net>:
> On Fri, 8 Feb 2013 11:42:39 -0800
> Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>
>> 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.  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.
>>
>
> I agree with Jesse. I wouldn't bother with these. Even a WARN_ONCE
> isn't helpful since the backtrace wouldn't really be meaningful.

Why isn't it helpful? Right now we don't even know whether this
problem happens or not, we're completely "blind" to a possible problem
that may be affecting us in some specific cases and we don't even
know. Knowing that it happens and how often it happens is IMHO
certainly better than closing our eyes and pretending it doesn't
exist.

>
> If OTOH, you wanted to save away this information into error state; I
> could get behind that.




-- 
Paulo Zanoni