On Fri, Oct 23, 2015 at 04:33:52PM +0300, Ville Syrjälä wrote: > On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote: > > On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote: > > > On Fri, 23 Oct 2015, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote: > > > >> We get tons of cases where the master interrupt handler apparently set > > > >> a bit, with the SDEIIR agreeing. No idea what's going on there, but > > > >> it's consistent on gen8+, no one seems to care about it and it's > > > >> making CI results flaky. > > > > > > > > Just delete the message and delete them all. There isn't anything we can > > > > do and if anybody actually cared (which apparently they didn't in the > > > > first place), they could just trace the mmio. > > > > > > Except this one is a regression, introduced by a bisected commit, and > > > suspiciously the errors pop up during aux transfers. > > > > dp aux is a red herring very likely, since it's just the source of a _lot_ > > of sde interrupts. > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=92084 > > > > No one demonstrated any bad side-effects of this, let's shut it up (but > > keep the breadcrumb in debug logs in case) and move on to other bugs. We > > have enough. > > I was still waiting for an answer to my latest idea how to avoid the > error. Would have been a very simple thing to test for anyone with the > hardware. Presumably, --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2345,6 +2345,7 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg) u32 pch_iir = I915_READ(SDEIIR); if (pch_iir) { I915_WRITE(SDEIIR, pch_iir); + POSTING_READ(SDEIIR); ret = IRQ_HANDLED; ? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
