Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1

[Imre Deak]

On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
> Hi
> 
> 2013/2/28 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
> > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> >> > Hi,
> >> >
> >> > I am seeing this also on Linux-Next.
> >> >
> >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [   28.202381]
> >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> >> > (has irq: 1)!
> >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [   28.210588]
> >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> >> > (has irq: 1)!
> >> >
> >> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [   27.408280]
> >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> >> > (has irq: 1)!
> >> >
> >> > This seems to be hard reproducible...
> >> > Laptop-LCD... Sandybridge Mobile-GT2.
> >> >
> >> > Is there a way to force the error?
> >> >
> >> > Possible patch see [1].
> >> >
> >> > - Sedat -
> >> >
> >> > [1] https://patchwork.kernel.org/patch/2192721/
> >
> > That was:
> >
> > +       if (!done) {
> > +               status = I915_READ_NOTRACE(ch_ctl);
> > +               DRM_ERROR("dp aux hw did not signal timeout (has irq:
> > %i), status=%08x!\n",
> > +                         has_aux_irq, status);
> > +       }
> >
> > You applied
> >
> > +       if (!done) {
> > +               status = I915_READ_NOTRACE(ch_ctl);
> > +               DRM_ERROR("dp aux hw did not signal timeout (has irq:
> > %i), status=%08x!\n",
> > +                         has_aux_irq, status);
> > +       {
> 
> In addition to this, after the problem happens can you please dump the
> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
> by running intel-reg-read (from intel-gpu-tools) or by changing the
> DRM_ERROR above to also print the result of I915_READ(0x44008) and
> I915_READ(0xC4008).
> 
> If you conclude that the value of 0x44008 is 0x0 while the value of
> 0xC4008 is not, then this patch should help:
> https://patchwork.kernel.org/patch/2177841/

I can trigger the bug on an ILK consistently by calling udelay(400) just
before 'I915_WRITE(SDEIIR, pch_iir);' in ironlake_irq_handler() until
the first timeout. Afterwards SDEIIR will contain SDE_AUXD and DEIIR
will be 0 and no more AUXD events will be serviced. With Paolo's patch I
can't trigger the bug even with the udelay being in place.

--Imre

> 
> >
> > That second '{' is the source of the compile error.
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/