Re: [Intel-gfx] [PATCH 4/4] drm/i915: ILK + VT-d workaround
Am Montag, den 17.10.2011, 15:51 -0700 schrieb Ben Widawsky: Idle the GPU before doing any unmaps. We know if VT-d is in use through an exported variable from iommu code. This should avoid a known HW issue. Please describe the issue more in detail or provide a link to more information. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/char/agp/intel-gtt.c| 28 drivers/gpu/drm/i915/i915_gem_gtt.c | 30 ++ include/drm/intel-gtt.h |2 ++ 3 files changed, 60 insertions(+), 0 deletions(-) […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: ILK + VT-d workaround
On Mon, Oct 17, 2011 at 03:51:55PM -0700, Ben Widawsky wrote: Idle the GPU before doing any unmaps. We know if VT-d is in use through an exported variable from iommu code. This should avoid a known HW issue. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] frequent x crashes with gen6/sna
Hi Daniel, I've installed your libva patch: libva: libva version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/local/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0 vainfo: VA API version: 0.32 vainfo: Driver version: Intel i965 driver - 1.0.15.pre1 No Changes. With iommu switched off there are less frequent hangs but there still are :-(. dmesg shows: WARNING: at drivers/gpu/drm/i915/i915_drv.c:354 gen6_gt_force_wake_get+0x1f/0x3c [i915]() Hardware name: 4236NGG Modules linked in: snd_hda_codec_conexant fbcon font bitblit softcursor i915 thinkpad_acpi nvram drm_kms_helper drm fb fbdev cfbcopyarea video iwlagn backlight cfbimgblt cfbfillrect e1000e snd_hda_intel snd_hda_codec intel_agp intel_gtt agpgart Pid: 0, comm: swapper Not tainted 3.1.0-rc4+ #1 Call Trace: IRQ [8102fcf2] ? warn_slowpath_common+0x78/0x8c [a0113fd9] ? i915_vblank_swap+0x6/0x6 [i915] [a010c484] ? gen6_gt_force_wake_get+0x1f/0x3c [i915] [a01140e2] ? i915_hangcheck_elapsed+0x109/0x29a [i915] [a0113fd9] ? i915_vblank_swap+0x6/0x6 [i915] [81039799] ? run_timer_softirq+0x195/0x222 [8103466f] ? __do_softirq+0x7f/0x106 [813b4f2c] ? call_softirq+0x1c/0x30 [81003396] ? do_softirq+0x31/0x67 [810348a0] ? irq_exit+0x44/0xa5 [81015cdd] ? smp_apic_timer_interrupt+0x85/0x95 [813b468b] ? apic_timer_interrupt+0x6b/0x70 EOI [811d5022] ? intel_idle+0xcd/0xe9 [811d4ffe] ? intel_idle+0xa9/0xe9 [812ae307] ? cpuidle_idle_call+0xa0/0xdb [81000840] ? cpu_idle+0x52/0x75 [81677b60] ? start_kernel+0x401/0x40c In this special case the gpu was successfully reset and continued normally. Any other ideas? Regards Dieter Original-Nachricht Datum: Mon, 17 Oct 2011 22:46:32 +0200 Von: Daniel Vetter dan...@ffwll.ch An: Dieter Mummenschanz mummensch...@gmx.net CC: Daniel Vetter dan...@ffwll.ch, li...@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] frequent x crashes with gen6/sna On Mon, Oct 17, 2011 at 10:20:09PM +0200, Dieter Mummenschanz wrote: ok now I got your patch from git and will give it a try asap. Meanwhile the intel_iommu=off (with rc6 enabled) switch seems to make the system somehow more stable. the gpu hangs don't appear that often but they still occur! strangely after the hang/resume, the OpenGL game crashes immediately with: intel_do_flush_locked failed: Input/output error and raises the same error when I try to start it up again. mplayer also bails out with: mplayer: dri2_util.c:109: dri2GetRenderingBuffer: Assertion `buffers' failed. MPlayer interrupted by signal 6 in module: flip_page I have to reboot in order to get mplayer / the game running. I've never experienced that before. i915 error state attached. Well, that usually means that the kernel couldn't reset the gpu after a hang. You should see a message to that effect in dmesg. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Check if the bus is valid prior to discovering edid.
On Thu, Oct 13, 2011 at 9:36 PM, Eugeni Dodonov eug...@dodonov.net wrote:
On Thu, Oct 13, 2011 at 17:34, Adam Jackson a...@redhat.com wrote:
On Thu, 2011-10-13 at 15:11 -0300, Eugeni Dodonov wrote:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c
b/drivers/gpu/drm/i915/intel_i2c.c
index d98cee6..b3a6eda 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -470,3 +470,45 @@ void intel_teardown_gmbus(struct drm_device *dev)
kfree(dev_priv-gmbus);
dev_priv-gmbus = NULL;
}
+
+/**
+ * intel_drm_get_valid_edid - gets edid from existent adapters only
+ * @connector: DRM connector device to use
+ * @adapter: i2c adapter
+ *
+ * Verifies if the i2c adapter is responding to our queries before
+ * attempting to do proper communication with it. If it does,
+ * retreive the EDID with help of drm_get_edid
+ */
+struct edid *
+intel_drm_get_valid_edid(struct drm_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ int ret;
+ u8 out_buf[] = { 0x0, 0x0};
+ u8 buf[2];
+ struct i2c_msg msgs[] = {
+ {
+ .addr = 0x50,
+ .flags = 0,
+ .len = 1,
+ .buf = out_buf,
+ },
+ {
+ .addr = 0x50,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = buf,
+ }
+ };
+
+ /* We just check for -ENXIO - drm_get_edid checks if the transfer
+ * works and manages the remaining parts of the EDID */
+ ret = i2c_transfer(adapter, msgs, 2);
This seems like it should be the implementation body of drm_probe_ddc,
and like that function should be EXPORT_SYMBOL()'d. Other people want
to do zero-length reads too, you know.
- ajax
My other patch in the previous series
(http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg05828.html)
did exactly that, but it haven't received any comments, and there was one
report saying that it decreased the detection timing on a radeon card. I
don't have any to test, so I prefer to focus on Intel ones (which I have)
:).
Thats not how we develop in the kernel btw.
You should go around trying to poke developers from other drivers to
test the patch.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: ILK + VT-d workaround
On Tue, 18 Oct 2011 09:24:41 +0200 Paul Menzel paulepan...@users.sourceforge.net wrote: Am Montag, den 17.10.2011, 15:51 -0700 schrieb Ben Widawsky: Idle the GPU before doing any unmaps. We know if VT-d is in use through an exported variable from iommu code. This should avoid a known HW issue. Please describe the issue more in detail or provide a link to more information. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/char/agp/intel-gtt.c| 28 drivers/gpu/drm/i915/i915_gem_gtt.c | 30 ++ include/drm/intel-gtt.h |2 ++ 3 files changed, 60 insertions(+), 0 deletions(-) […] Thanks, Paul Please see patch 1 and 2 in the series for the description. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: don't bail out of intel_wait_ring_buffer too early
On Tue, 11 Oct 2011 19:25:57 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: In the pre-gem days with non-existing hangcheck and gpu reset code, this timeout of 3 seconds was pretty important to avoid stuck processes. But now we have the hangcheck code in gem that goes to great length to ensure that the gpu is really dead before declaring it wedged. So there's no need for this timeout anymore. Actually it's even harmful because we can bail out too early (e.g. with xscreensaver slip) when running giant batchbuffers. And our code isn't robust enough to properly unroll any state-changes, we pretty much rely on the gpu reset code cleaning up the mess (like cache tracking, fencing state, active list/request tracking, ...). With this change intel_begin_ring can only fail when the gpu is wedged, and it will return -EAGAIN (like wait_request in case the gpu reset is still outstanding). v2: Chris Wilson noted that on resume timers aren't running and hence we won't ever get kicked out of this loop by the hangcheck code. Use an insanely large timeout instead for the HAS_GEM case to prevent resume bugs from totally hanging the machine. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Personally I would have done: end = jiffies; if (has_gem) end += infinity; else end += 3s; but that is one nitpick too far ;-) -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
Re: [Intel-gfx] [PATCH] drm/i915: switch ring-id to be a real id
On Tue, 11 Oct 2011 19:29:27 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: ... and add a helpr function for the places where we want a flag. This way we can use ring-id to index into arrays. v2: Resurrect the missing beautification-space Chris Wilson noted. I'm moving this space around because I'll reuse ring_str in the next patch. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch No neater solution presents itself, so Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
Re: [Intel-gfx] frequent x crashes with gen6/sna
On Tue, Oct 18, 2011 at 09:52:32AM +0200, Dieter Mummenschanz wrote: I've installed your libva patch: libva: libva version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/local/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0 vainfo: VA API version: 0.32 vainfo: Driver version: Intel i965 driver - 1.0.15.pre1 No Changes. With iommu switched off there are less frequent hangs but there still are :-(. dmesg shows: WARNING: at drivers/gpu/drm/i915/i915_drv.c:354 gen6_gt_force_wake_get+0x1f/0x3c [i915]() Hardware name: 4236NGG Modules linked in: snd_hda_codec_conexant fbcon font bitblit softcursor i915 thinkpad_acpi nvram drm_kms_helper drm fb fbdev cfbcopyarea video iwlagn backlight cfbimgblt cfbfillrect e1000e snd_hda_intel snd_hda_codec intel_agp intel_gtt agpgart Pid: 0, comm: swapper Not tainted 3.1.0-rc4+ #1 Call Trace: IRQ [8102fcf2] ? warn_slowpath_common+0x78/0x8c [a0113fd9] ? i915_vblank_swap+0x6/0x6 [i915] [a010c484] ? gen6_gt_force_wake_get+0x1f/0x3c [i915] [a01140e2] ? i915_hangcheck_elapsed+0x109/0x29a [i915] [a0113fd9] ? i915_vblank_swap+0x6/0x6 [i915] [81039799] ? run_timer_softirq+0x195/0x222 [8103466f] ? __do_softirq+0x7f/0x106 [813b4f2c] ? call_softirq+0x1c/0x30 [81003396] ? do_softirq+0x31/0x67 [810348a0] ? irq_exit+0x44/0xa5 [81015cdd] ? smp_apic_timer_interrupt+0x85/0x95 [813b468b] ? apic_timer_interrupt+0x6b/0x70 EOI [811d5022] ? intel_idle+0xcd/0xe9 [811d4ffe] ? intel_idle+0xa9/0xe9 [812ae307] ? cpuidle_idle_call+0xa0/0xdb [81000840] ? cpu_idle+0x52/0x75 [81677b60] ? start_kernel+0x401/0x40c We already know about this backtrace. It's a possible sideffect of a overloaded/dying gpu, but unrelated to the bug at hand. In this special case the gpu was successfully reset and continued normally. Any other ideas? Not at the moment, unfortunately. Can you please report a bug against libva with a small summary of all the things we've already discussed here? Also please add a error_state with my patches applied. And don't forget to put me on cc and post the bug # here in this thread. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
