lkml.org 
[lkml]   [2013]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Intel-gfx] [git pull] drm merge for 3.9-rc1
From
Date
On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>:
> > 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@gmail.com> 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@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>




\
 
 \ /
  Last update: 2013-03-05 20:02    [W:0.043 / U:5.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site