[Intel-gfx] [QA 03/29] Testing report for `drm-intel-testing` (was: Updated -next)
Summary We finished a new round of kernel testing. Generally, in this circle, 1 new bugs are filed, 25 bugs are still opened, 1 bugs are closed. Test Environment Kernel: (drm-intel-testing)69a06a0f43ca41c0600f0172e34d3e251e92aad1 Some additional commit info: Merge: e3dff58 838b97f Author: Daniel Vetter daniel.vet...@ffwll.chmailto:daniel.vet...@ffwll.ch Date: Sat Mar 23 12:27:23 2013 +0100 Hardware We covered the platform: Haswell, IvyBridge, SandyBridge, IronLake Finding New Bugs: Bug 62791https://bugs.freedesktop.org/show_bug.cgi?id=62791 - [ILK regression] Change from X-window to text terminal causes Call Trace Opened Bugs: Bug 62275https://bugs.freedesktop.org/show_bug.cgi?id=62275 - [HSW 3.8.2 regression] After running testdisplay with only eDP, screen turn to black and can't light up again Bug 61929https://bugs.freedesktop.org/show_bug.cgi?id=61929 - [HSW eDP regression 3.8] eDP blank until xrandr is re-run Bug 61542https://bugs.freedesktop.org/show_bug.cgi?id=61542 - [HSW bisected] Desktop-EDP can not work Bug 55121https://bugzilla.kernel.org/show_bug.cgi?id=55121 - Limited color range on screen that is connected via HDMI [SandyBridge] (https://bugzilla.kernel.org/show_bug.cgi?id=55121) Bug 61041https://bugs.freedesktop.org/show_bug.cgi?id=61041 - [Pineview]I-G-T/testdisplay VGA 1600x1200 65Hz messing the screen Bug 61158https://bugs.freedesktop.org/show_bug.cgi?id=61158 - [ILK] System hang while running testdisplay to mode 1280x800 Bug 60002https://bugs.freedesktop.org/show_bug.cgi?id=60002 - [PNV]I-G-T/kms_flip subtest：'blocking-absolute-wf_vblank' fail Bug 6https://bugs.freedesktop.org/show_bug.cgi?id=6 - [IVB]kms_flip error: inter-vblank ts jitter Bug 5https://bugs.freedesktop.org/show_bug.cgi?id=5 - [ILK,IVB]kms_flip error: inter-flip ts jitter Bug 59834https://bugs.freedesktop.org/show_bug.cgi?id=59834 - [ILK]I-G-T/kms_flip subtest: 'wf_vblank-vs-modeset' fail Bug 59836https://bugs.freedesktop.org/show_bug.cgi?id=59836 - [PNV]igt/kms_flip/absolute-wf_vblank fail Bug 58897https://bugs.freedesktop.org/show_bug.cgi?id=58897 - [HSW CRW]*ERROR* Unknown unclaimed register Bug 59229https://bugs.freedesktop.org/show_bug.cgi?id=59229 - I-G-T/ prime_self_import fail Bug 59339https://bugs.freedesktop.org/show_bug.cgi?id=59339 - [ILK] I-G-T/kms_flip subtest: 'flip-vs-panning' fail Bug 36997https://bugs.freedesktop.org/show_bug.cgi?id=36997 - [G45 SDVO] TV can't display Bug 42194https://bugs.freedesktop.org/show_bug.cgi?id=42194 - [IVB/SNB] coldplug new monitors for fbcon on lastclose() Bug 51975https://bugs.freedesktop.org/show_bug.cgi?id=51975 - [IVB]can't find the HDMI audio device Bug 54111https://bugs.freedesktop.org/show_bug.cgi?id=54111 - [IVB]I-G-T prime test/module_reload fail with *ERROR* “Memory manager not clean. Delaying takedown” Bug 57441https://bugs.freedesktop.org/show_bug.cgi?id=57441 - [HSW]I-G-T/sysfs_l3_parity fail Bug 58497https://bugs.freedesktop.org/show_bug.cgi?id=58497 - [IVB HSW] I-G-T/testdisplay, there's error in dmesg Bug 58695https://bugs.freedesktop.org/show_bug.cgi?id=58695 - I-G-T/prime_udl fail Bug 58701https://bugs.freedesktop.org/show_bug.cgi?id=58701 - [SNB DP]I-G-T/testdisplay 1920x1080i showing not full Bug 54687https://bugs.freedesktop.org/show_bug.cgi?id=54687 - [ilk] pipe off timeout Bug 52424https://bugs.freedesktop.org/show_bug.cgi?id=52424 - [Bisected SNB Regression] glxgears causes GPU hung Bug 45729https://bugs.freedesktop.org/show_bug.cgi?id=45729 - [bisected regression] Incorrect Mode Timing on DP Display, with 3.3-rc (due to interlaced CEA modes) (blocked by bug #61158) Closed Bugs: Bug 62584https://bugs.freedesktop.org/show_bug.cgi?id=62584 - [SNB Bisected]System hang while booting up with -queued kernel Thanks --Sun, Yi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed
According to the opengl glx_sync_control spec, the Unadjusted System Time
(or UST) is a 64-bit monotonically increasing counter that is available
throughout the system:
http://www.opengl.org/registry/specs/OML/glx_sync_control.txt
Therefore, sending 0, even in this corner case, is out of spec.
Instead, just return FALSE indicating that the operation could not be
completed.
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
src/intel_dri.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index f351203..179bfb7 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -1339,12 +1339,9 @@ I830DRI2GetMSC(DrawablePtr draw, CARD64 *ust, CARD64
*msc)
drmVBlank vbl;
int ret, pipe = I830DRI2DrawablePipe(draw);
- /* Drawable not displayed, make up a value */
- if (pipe == -1) {
- *ust = 0;
- *msc = 0;
- return TRUE;
- }
+ /* Drawable not displayed, return FALSE */
+ if (pipe == -1)
+ return FALSE;
vbl.request.type = DRM_VBLANK_RELATIVE | pipe_select(pipe);
vbl.request.sequence = 0;
--
1.8.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed
On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote: According to the opengl glx_sync_control spec, the Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system: http://www.opengl.org/registry/specs/OML/glx_sync_control.txt Therefore, sending 0, even in this corner case, is out of spec. Instead, just return FALSE indicating that the operation could not be completed. The problem is that ends up sending BadDrawable back to the client, which ends up killing many clients and a compositor or two due to the unexpected error. Would you prefer querying pipe 0 in this case for the UST? -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 xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed
On Fri, Mar 29, 2013 at 2:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote: According to the opengl glx_sync_control spec, the Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system: http://www.opengl.org/registry/specs/OML/glx_sync_control.txt Therefore, sending 0, even in this corner case, is out of spec. Instead, just return FALSE indicating that the operation could not be completed. The problem is that ends up sending BadDrawable back to the client, which ends up killing many clients and a compositor or two due to the unexpected error. Would you prefer querying pipe 0 in this case for the UST? For us it comes down to the fact that we'd like something monotonous. So yes querying pipe 0 could work if it's enabled. But I wonder what do you do when you have no enabled pipe though? Return the last UST? Stéphane ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed
On Fri, Mar 29, 2013 at 03:13:35AM -0700, Stéphane Marchesin wrote: On Fri, Mar 29, 2013 at 2:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote: According to the opengl glx_sync_control spec, the Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system: http://www.opengl.org/registry/specs/OML/glx_sync_control.txt Therefore, sending 0, even in this corner case, is out of spec. Instead, just return FALSE indicating that the operation could not be completed. The problem is that ends up sending BadDrawable back to the client, which ends up killing many clients and a compositor or two due to the unexpected error. Would you prefer querying pipe 0 in this case for the UST? For us it comes down to the fact that we'd like something monotonous. So yes querying pipe 0 could work if it's enabled. But I wonder what do you do when you have no enabled pipe though? Return the last UST? That's a problem as we would need a running pipe, which is not guaranteed. I wonder if CLOCK_MONOTONIC would suffice? -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: implement ibx_hpd_irq_setup
Sorry for replying so late, I wasn't able to task switch my brain
towards this when it was discussed:
Daniel Vetter writes:
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 43436e0..1279a44 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2084,7 +2084,7 @@ static void ibx_enable_hotplug(struct drm_device *dev)
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
-static void ibx_irq_postinstall(struct drm_device *dev)
+static void ibx_hpd_irq_setup(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
struct drm_mode_config *mode_config = dev-mode_config;
@@ -2095,12 +2095,10 @@ static void ibx_irq_postinstall(struct drm_device
*dev)
mask = ~SDE_HOTPLUG_MASK;
^^^
I'm missing those lines in the committed version of the patch.
list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
mask |= hpd_ibx[intel_encoder-hpd_pin];
-mask |= SDE_GMBUS | SDE_AUX_MASK;
} else {
mask = ~SDE_HOTPLUG_MASK_CPT;
^^^
list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
mask |= hpd_cpt[intel_encoder-hpd_pin];
-mask |= SDE_GMBUS_CPT | SDE_AUX_MASK_CPT;
}
I915_WRITE(SDEIIR, I915_READ(SDEIIR));
These are not really relevant in the present code, however they are
important once I've got the hotplug stuff refitted as one needs to be
able to turn off individual interrupts.
I'm going to prepare a commit for this and will send it with the hpd
irq storm patches.
Cheers,
Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed
On Fri, Mar 29, 2013 at 5:54 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Mar 29, 2013 at 03:13:35AM -0700, Stéphane Marchesin wrote: On Fri, Mar 29, 2013 at 2:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote: According to the opengl glx_sync_control spec, the Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system: http://www.opengl.org/registry/specs/OML/glx_sync_control.txt Therefore, sending 0, even in this corner case, is out of spec. Instead, just return FALSE indicating that the operation could not be completed. The problem is that ends up sending BadDrawable back to the client, which ends up killing many clients and a compositor or two due to the unexpected error. Would you prefer querying pipe 0 in this case for the UST? For us it comes down to the fact that we'd like something monotonous. So yes querying pipe 0 could work if it's enabled. But I wonder what do you do when you have no enabled pipe though? Return the last UST? That's a problem as we would need a running pipe, which is not guaranteed. I wonder if CLOCK_MONOTONIC would suffice? Yeah that's what I had in mind. Would that work for you? Stéphane ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
