From: Ben Widawsky <ben@bwidawsk.net>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 07/10] drm/i915: print Gen5+ CPU poison interrupts
Date: Thu, 14 Feb 2013 20:05:23 -0800 [thread overview]
Message-ID: <20130214200523.000036e1@unknown> (raw)
In-Reply-To: <CA+gsUGSbvJnVLu2F84mJUk-xT-pb6z8yGjCPpc-k2SaP+cmhJA@mail.gmail.com>
On Thu, 14 Feb 2013 18:35:32 -0200
Paulo Zanoni <przanoni@gmail.com> wrote:
> Hi
>
> 2013/2/9 Ben Widawsky <ben@bwidawsk.net>:
> > On Fri, 8 Feb 2013 11:42:39 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> >> On Fri, 8 Feb 2013 17:35:18 -0200
> >> Paulo Zanoni <przanoni@gmail.com> wrote:
> >>
> >> > From: Paulo Zanoni <paulo.r.zanoni@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@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.
>
I suppose you're right. I'm strongly of the opinion that we won't
ever see this error because the system will crap out before we'd be
able to get that info - of course I cannot prove that, and I don't
know enough about what exactly poison means. I just think it sucks that
we have yet another gen specific thing which has TBD value. I certainly
won't nak it, and of course if it proves useful, I'll be most
apologetic.
As for the WARN being unhelpful, it's the same problem again. You're
getting the notifications via interrupt, so a backtrace is useless on
IVB/HSW. Perhaps it makes sense on ILK/SNB. Reinventing a "do this
once" macro isn't worthwhile either, so I guess WARN_ON with the
assumption that we ignore the backtrace is fine on IVB/HSW.
> >
> > If OTOH, you wanted to save away this information into error state;
> > I could get behind that.
>
>
>
>
next prev parent reply other threads:[~2013-02-15 4:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 19:35 [PATCH 00/10] Display error reporting Paulo Zanoni
2013-02-08 19:35 ` [PATCH 01/10] drm/i915: drm/i915: create macros for the "unclaimed register" checks Paulo Zanoni
2013-02-18 18:11 ` Daniel Vetter
2013-02-08 19:35 ` [PATCH 02/10] drm/i915: use FPGA_DBG " Paulo Zanoni
2013-02-08 19:35 ` [PATCH 03/10] drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver init Paulo Zanoni
2013-02-09 17:19 ` Ben Widawsky
2013-02-14 20:26 ` Paulo Zanoni
2013-02-15 4:07 ` Ben Widawsky
2013-02-08 19:35 ` [PATCH 04/10] drm/i915: add ibx_irq_postinstall Paulo Zanoni
2013-02-09 17:27 ` Ben Widawsky
2013-02-09 19:07 ` Daniel Vetter
2013-02-08 19:35 ` [PATCH 05/10] drm/i915: also disable south interrupts when handling them Paulo Zanoni
2013-02-09 19:29 ` Daniel Vetter
2013-02-20 20:06 ` Paulo Zanoni
2013-02-20 20:24 ` Daniel Vetter
2013-02-08 19:35 ` [PATCH 06/10] drm/i915: print PCH poison interrupts Paulo Zanoni
2013-02-08 19:35 ` [PATCH 07/10] drm/i915: print Gen5+ CPU " Paulo Zanoni
2013-02-08 19:42 ` Jesse Barnes
2013-02-08 19:54 ` Paulo Zanoni
2013-02-08 20:01 ` Jesse Barnes
2013-02-09 17:30 ` Ben Widawsky
2013-02-14 20:35 ` Paulo Zanoni
2013-02-15 4:05 ` Ben Widawsky [this message]
2013-02-08 19:35 ` [PATCH 08/10] drm/i915: print PCH FIFO underrun interrupts Paulo Zanoni
2013-02-09 19:43 ` Daniel Vetter
2013-02-14 20:53 ` Paulo Zanoni
2013-02-14 21:13 ` Daniel Vetter
2013-02-14 21:32 ` Paulo Zanoni
2013-02-08 19:35 ` [PATCH 09/10] drm/i915: print CPU FIFO underruns Paulo Zanoni
2013-02-08 19:35 ` [PATCH 10/10] drm/i915: also POSTING_READ(DEIER) on ivybridge_irq_handler Paulo Zanoni
2013-02-09 17:34 ` Ben Widawsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130214200523.000036e1@unknown \
--to=ben@bwidawsk.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=przanoni@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.