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 -
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.dilek@gmail.com wrote:
Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module.
- Sedat -
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
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); + {
That second '{' is the source of the compile error. -Chris
Hi
2013/2/28 Chris Wilson chris@chris-wilson.co.uk:
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/
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przanoni@gmail.com wrote:
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 -
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.dilek@gmail.com wrote:
Installed intel-gpu-tools.
# intel_reg_read Usage: intel_reg_read [-f | addr] -f : read back full range of registers. WARNING! This could be danger to hang the machine! addr : in 0xXXXX format
# intel_reg_read 0x44008 Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining [ 381.521912] intel_reg_read:3658 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining [ 401.136291] intel_reg_read:3659 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with i915 debug enabled?
- Sedat -
Hi
2013/2/28 Sedat Dilek sedat.dilek@gmail.com:
Just build the version from git and it should work (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni przanoni@gmail.com wrote:
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x
$ sudo ./tools/intel_reg_read 0x44008 0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008 0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <--- see attachment
Does this help you?
- Sedat -
On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
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
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson chris@chris-wilson.co.uk wrote:
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Imre Deak -
Paulo Zanoni -
Sedat Dilek