On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@xxxxxxxxx> 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). > Do I need a specific version of intel-gpu-tools? Ubuntu/precise has v1.2 in its archives - sufficient? Note: The error was twice after dozenz of Linux-Next kernel builds. - Sedat - [1] http://packages.ubuntu.com/precise/intel-gpu-tools > 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/ > >> >> 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 > > > > -- > Paulo Zanoni _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
