* [PATCH] drm/i915: Disable all outputs early, before KMS takeover [not found] <AANLkTi=VqkYjdiDLJvM-OfmBSGx-EkRkt=4XCDEnvZsU@mail.gmail.com> @ 2011-03-29 10:46 ` Chris Wilson 2011-03-29 12:23 ` [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init Chris Wilson 2011-04-01 11:44 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Daniel Vetter 0 siblings, 2 replies; 25+ messages in thread From: Chris Wilson @ 2011-03-29 10:46 UTC (permalink / raw) To: intel-gfx; +Cc: Pekka Enberg, linux-kernel, Chris Wilson If the outputs are active and continuing to access the GATT when we teardown the PTEs, then there is a potential for us to hang the GPU. The hang tends to be a PGTBL_ER with either an invalid host access or an invalid display plane fetch. Reported-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_dma.c | 31 ++++++++++++++++++++++--------- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_display.c | 17 +++++++++++------ 3 files changed, 34 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 7273037..65d5adf 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1176,11 +1176,11 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev) return can_switch; } -static int i915_load_modeset_init(struct drm_device *dev) +static int i915_load_gem_init(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; unsigned long prealloc_size, gtt_size, mappable_size; - int ret = 0; + int ret; prealloc_size = dev_priv->mm.gtt->stolen_size; gtt_size = dev_priv->mm.gtt->gtt_total_entries << PAGE_SHIFT; @@ -1204,7 +1204,7 @@ static int i915_load_modeset_init(struct drm_device *dev) ret = i915_gem_init_ringbuffer(dev); mutex_unlock(&dev->struct_mutex); if (ret) - goto out; + return ret; /* Try to set up FBC with a reasonable compressed buffer size */ if (I915_HAS_FBC(dev) && i915_powersave) { @@ -1222,6 +1222,13 @@ static int i915_load_modeset_init(struct drm_device *dev) /* Allow hardware batchbuffers unless told otherwise. */ dev_priv->allow_batchbuffer = 1; + return 0; +} + +static int i915_load_modeset_init(struct drm_device *dev) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + int ret; ret = intel_parse_bios(dev); if (ret) @@ -1236,7 +1243,7 @@ static int i915_load_modeset_init(struct drm_device *dev) */ ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode); if (ret && ret != -ENODEV) - goto cleanup_ringbuffer; + goto out; intel_register_dsm_handler(); @@ -1257,13 +1264,19 @@ static int i915_load_modeset_init(struct drm_device *dev) if (ret) goto cleanup_vga_switcheroo; + ret = i915_load_gem_init(dev); + if (ret) + goto cleanup_irq; + + intel_modeset_gem_init(dev); + /* Always safe in the mode setting case. */ /* FIXME: do pre/post-mode set stuff in core KMS code */ dev->vblank_disable_allowed = 1; ret = intel_fbdev_init(dev); if (ret) - goto cleanup_irq; + goto cleanup_gem; drm_kms_helper_poll_init(dev); @@ -1272,16 +1285,16 @@ static int i915_load_modeset_init(struct drm_device *dev) return 0; +cleanup_gem: + mutex_lock(&dev->struct_mutex); + i915_gem_cleanup_ringbuffer(dev); + mutex_unlock(&dev->struct_mutex); cleanup_irq: drm_irq_uninstall(dev); cleanup_vga_switcheroo: vga_switcheroo_unregister_client(dev->pdev); cleanup_vga_client: vga_client_register(dev->pdev, NULL, NULL, NULL); -cleanup_ringbuffer: - mutex_lock(&dev->struct_mutex); - i915_gem_cleanup_ringbuffer(dev); - mutex_unlock(&dev->struct_mutex); out: return ret; } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 359ddce..60ebd79 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1268,6 +1268,7 @@ static inline void intel_unregister_dsm_handler(void) { return; } /* modesetting */ extern void intel_modeset_init(struct drm_device *dev); +extern void intel_modeset_gem_init(struct drm_device *dev); extern void intel_modeset_cleanup(struct drm_device *dev); extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state); extern void i8xx_disable_fbc(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 432fc04..5c7385b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6497,6 +6497,9 @@ static void intel_setup_outputs(struct drm_device *dev) } intel_panel_setup_backlight(dev); + + /* disable all the possible outputs/crtcs before entering KMS mode */ + drm_helper_disable_unused_functions(dev); } static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) @@ -7432,13 +7435,12 @@ void intel_modeset_init(struct drm_device *dev) intel_crtc_init(dev, i); } + /* Just disable it once at startup */ + i915_disable_vga(dev); intel_setup_outputs(dev); intel_enable_clock_gating(dev); - /* Just disable it once at startup */ - i915_disable_vga(dev); - if (IS_IRONLAKE_M(dev)) { ironlake_enable_drps(dev); intel_init_emon(dev); @@ -7447,12 +7449,15 @@ void intel_modeset_init(struct drm_device *dev) if (IS_GEN6(dev)) gen6_enable_rps(dev_priv); - if (IS_IRONLAKE_M(dev)) - ironlake_enable_rc6(dev); - INIT_WORK(&dev_priv->idle_work, intel_idle_update); setup_timer(&dev_priv->idle_timer, intel_gpu_idle_timer, (unsigned long)dev); +} + +void intel_modeset_gem_init(struct drm_device *dev) +{ + if (IS_IRONLAKE_M(dev)) + ironlake_enable_rc6(dev); intel_setup_overlay(dev); } -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 10:46 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Chris Wilson @ 2011-03-29 12:23 ` Chris Wilson 2011-03-29 13:05 ` Pekka Enberg 2011-04-01 11:44 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Daniel Vetter 1 sibling, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-03-29 12:23 UTC (permalink / raw) To: intel-gfx; +Cc: Pekka Enberg, linux-kernel, Chris Wilson Required so that we don't obliterate the queue if initialising the rings after the global IRQ handler is installed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- This patch is required in conjunction with the first to prevent an oops the first time we try to use i915_wait_request (i.e. when starting X). -Chris --- drivers/gpu/drm/i915/i915_irq.c | 6 ------ drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + 2 files changed, 1 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 188b497..46ccfc8 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1688,12 +1688,6 @@ int i915_driver_irq_postinstall(struct drm_device *dev) u32 enable_mask = I915_INTERRUPT_ENABLE_FIX | I915_INTERRUPT_ENABLE_VAR; u32 error_mask; - DRM_INIT_WAITQUEUE(&dev_priv->ring[RCS].irq_queue); - if (HAS_BSD(dev)) - DRM_INIT_WAITQUEUE(&dev_priv->ring[VCS].irq_queue); - if (HAS_BLT(dev)) - DRM_INIT_WAITQUEUE(&dev_priv->ring[BCS].irq_queue); - dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B; if (HAS_PCH_SPLIT(dev)) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e9e6f71..884556d 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -800,6 +800,7 @@ int intel_init_ring_buffer(struct drm_device *dev, INIT_LIST_HEAD(&ring->request_list); INIT_LIST_HEAD(&ring->gpu_write_list); + init_waitqueue_head(&ring->irq_queue); spin_lock_init(&ring->irq_lock); ring->irq_mask = ~0; -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 12:23 ` [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init Chris Wilson @ 2011-03-29 13:05 ` Pekka Enberg 2011-03-29 13:22 ` Chris Wilson 0 siblings, 1 reply; 25+ messages in thread From: Pekka Enberg @ 2011-03-29 13:05 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, linux-kernel On Tue, Mar 29, 2011 at 3:23 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > Required so that we don't obliterate the queue if initialising the > rings after the global IRQ handler is installed. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> I applied both of the patches on top of yesterdays git HEAD and I just get a blank screen after GRUB. No serial or net console here. Do you want me to try just one of the patches or turn on some debugging options? Pekka ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 13:05 ` Pekka Enberg @ 2011-03-29 13:22 ` Chris Wilson 2011-03-29 13:39 ` Pekka Enberg 0 siblings, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-03-29 13:22 UTC (permalink / raw) To: Pekka Enberg; +Cc: intel-gfx, linux-kernel On Tue, 29 Mar 2011 16:05:35 +0300, Pekka Enberg <penberg@kernel.org> wrote: > On Tue, Mar 29, 2011 at 3:23 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > Required so that we don't obliterate the queue if initialising the > > rings after the global IRQ handler is installed. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > I applied both of the patches on top of yesterdays git HEAD and I just > get a blank screen after GRUB. No serial or net console here. Do you > want me to try just one of the patches or turn on some debugging > options? That was the unspoken side-effect: if we fail to load the i915 module after disabling the outputs, then we would be left with a blank screen. If you can ssh in and retrieve the dmesg, then it should at least give a reason... -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 13:22 ` Chris Wilson @ 2011-03-29 13:39 ` Pekka Enberg 2011-03-29 14:22 ` Pekka Enberg 0 siblings, 1 reply; 25+ messages in thread From: Pekka Enberg @ 2011-03-29 13:39 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, linux-kernel On Tue, Mar 29, 2011 at 4:22 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 29 Mar 2011 16:05:35 +0300, Pekka Enberg <penberg@kernel.org> wrote: >> On Tue, Mar 29, 2011 at 3:23 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> > Required so that we don't obliterate the queue if initialising the >> > rings after the global IRQ handler is installed. >> > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >> >> I applied both of the patches on top of yesterdays git HEAD and I just >> get a blank screen after GRUB. No serial or net console here. Do you >> want me to try just one of the patches or turn on some debugging >> options? > > That was the unspoken side-effect: if we fail to load the i915 module after > disabling the outputs, then we would be left with a blank screen. > > If you can ssh in and retrieve the dmesg, then it should at least give a > reason... I have CONFIG_DRM_I915=y so there are no modules involved. I'll see if I can ssh to the box. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 13:39 ` Pekka Enberg @ 2011-03-29 14:22 ` Pekka Enberg 2011-03-29 14:32 ` Chris Wilson 0 siblings, 1 reply; 25+ messages in thread From: Pekka Enberg @ 2011-03-29 14:22 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, linux-kernel On Tue, Mar 29, 2011 at 4:39 PM, Pekka Enberg <penberg@kernel.org> wrote: > On Tue, Mar 29, 2011 at 4:22 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> On Tue, 29 Mar 2011 16:05:35 +0300, Pekka Enberg <penberg@kernel.org> wrote: >>> On Tue, Mar 29, 2011 at 3:23 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >>> > Required so that we don't obliterate the queue if initialising the >>> > rings after the global IRQ handler is installed. >>> > >>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>> >>> I applied both of the patches on top of yesterdays git HEAD and I just >>> get a blank screen after GRUB. No serial or net console here. Do you >>> want me to try just one of the patches or turn on some debugging >>> options? >> >> That was the unspoken side-effect: if we fail to load the i915 module after >> disabling the outputs, then we would be left with a blank screen. >> >> If you can ssh in and retrieve the dmesg, then it should at least give a >> reason... > > I have > > CONFIG_DRM_I915=y > > so there are no modules involved. I'll see if I can ssh to the box. No ssh - the box seems to be dead. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 14:22 ` Pekka Enberg @ 2011-03-29 14:32 ` Chris Wilson 2011-03-29 15:21 ` Pekka Enberg 0 siblings, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-03-29 14:32 UTC (permalink / raw) To: Pekka Enberg; +Cc: intel-gfx, linux-kernel On Tue, 29 Mar 2011 17:22:13 +0300, Pekka Enberg <penberg@kernel.org> wrote: > No ssh - the box seems to be dead. But now you have a machine with which to listen out for the netconsole scream of anguish... -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init 2011-03-29 14:32 ` Chris Wilson @ 2011-03-29 15:21 ` Pekka Enberg 0 siblings, 0 replies; 25+ messages in thread From: Pekka Enberg @ 2011-03-29 15:21 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, linux-kernel On Tue, Mar 29, 2011 at 5:32 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 29 Mar 2011 17:22:13 +0300, Pekka Enberg <penberg@kernel.org> wrote: >> No ssh - the box seems to be dead. > > But now you have a machine with which to listen out for the netconsole > scream of anguish... OK, this gets interesting. With netconsole=... loglevel=7 I am not able to reproduce the bug. With netconsole=... loglevel=6 I am able to reproduce but nothing is printed to netconsole. I guess the kernel dies before it's able to set it up. Pekka ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-03-29 10:46 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Chris Wilson 2011-03-29 12:23 ` [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init Chris Wilson @ 2011-04-01 11:44 ` Daniel Vetter 2011-04-01 11:51 ` [Intel-gfx] " Pekka Enberg 1 sibling, 1 reply; 25+ messages in thread From: Daniel Vetter @ 2011-04-01 11:44 UTC (permalink / raw) To: Chris Wilson; +Cc: Pekka Enberg, intel-gfx, linux-kernel On Tue, Mar 29, 2011 at 11:46:29AM +0100, Chris Wilson wrote: > If the outputs are active and continuing to access the GATT when we > teardown the PTEs, then there is a potential for us to hang the GPU. > The hang tends to be a PGTBL_ER with either an invalid host access or > an invalid display plane fetch. This patch seems to fix resume flakiness (that recently developed complete reliability in hanging the gpu) on my i855gm. Captured error_states look as described here. Latest -staging merged into latest -linus is now again fully reliable at s/r. Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-01 11:44 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Daniel Vetter @ 2011-04-01 11:51 ` Pekka Enberg 2011-04-05 10:21 ` Tomas Winkler 0 siblings, 1 reply; 25+ messages in thread From: Pekka Enberg @ 2011-04-01 11:51 UTC (permalink / raw) To: Chris Wilson, intel-gfx, Pekka Enberg, linux-kernel; +Cc: Daniel Vetter On Fri, Apr 1, 2011 at 2:44 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Mar 29, 2011 at 11:46:29AM +0100, Chris Wilson wrote: >> If the outputs are active and continuing to access the GATT when we >> teardown the PTEs, then there is a potential for us to hang the GPU. >> The hang tends to be a PGTBL_ER with either an invalid host access or >> an invalid display plane fetch. > > This patch seems to fix resume flakiness (that recently developed > complete reliability in hanging the gpu) on my i855gm. Captured > error_states look as described here. Latest -staging merged into latest > -linus is now again fully reliable at s/r. > > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Unfortunately I get a blank screen with after boot: Nacked-by: Pekka Enberg <penberg@kernel.org> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-01 11:51 ` [Intel-gfx] " Pekka Enberg @ 2011-04-05 10:21 ` Tomas Winkler 2011-04-05 10:30 ` Chris Wilson 0 siblings, 1 reply; 25+ messages in thread From: Tomas Winkler @ 2011-04-05 10:21 UTC (permalink / raw) To: Pekka Enberg, Chris Wilson, intel-gfx, linux-kernel, Daniel Vetter On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: > On Fri, Apr 1, 2011 at 2:44 PM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Tue, Mar 29, 2011 at 11:46:29AM +0100, Chris Wilson wrote: >>> If the outputs are active and continuing to access the GATT when we >>> teardown the PTEs, then there is a potential for us to hang the GPU. >>> The hang tends to be a PGTBL_ER with either an invalid host access or >>> an invalid display plane fetch. >> >> This patch seems to fix resume flakiness (that recently developed >> complete reliability in hanging the gpu) on my i855gm. Captured >> error_states look as described here. Latest -staging merged into latest >> -linus is now again fully reliable at s/r. >> >> Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > Unfortunately I get a blank screen with after boot: > Nacked-by: Pekka Enberg <penberg@kernel.org> Not sure this is related, but when I enable DRM_I915_KMS=y I'm got stuck after boot too. When KMS is disabled I can at least get to the console (no graphics) This is with kernel 2.6.39-rc1. It worked fine with 2.6.38. I don't have much time bisect and reboot. Shell I try to pull drm-fixes for rc2 or use try this patch? lspci -vv 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device 0036 Flags: bus master, fast devsel, latency 0, IRQ 42 Memory at fe000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at f160 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 Thanks Tomas ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 10:21 ` Tomas Winkler @ 2011-04-05 10:30 ` Chris Wilson 2011-04-05 10:37 ` Pekka Enberg 2011-04-05 14:42 ` Linus Torvalds 0 siblings, 2 replies; 25+ messages in thread From: Chris Wilson @ 2011-04-05 10:30 UTC (permalink / raw) To: Tomas Winkler, Pekka Enberg, intel-gfx, linux-kernel, Daniel Vetter On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote: > On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: > > Unfortunately I get a blank screen with after boot: > > Nacked-by: Pekka Enberg <penberg@kernel.org> But until you can tell me where it explodes on your system, we fix issues on several other machines... > Not sure this is related, but when I enable DRM_I915_KMS=y I'm got > stuck after boot too. When KMS is disabled I can at least get to the > console (no graphics) > This is with kernel 2.6.39-rc1. It worked fine with 2.6.38. I don't > have much time bisect and reboot. Shell I try to pull drm-fixes for > rc2 or use try this patch? Add drm.debug=0xe to your grub kernel parameters and attach the dmesg for the failing boot. From that I should be able to recommend a course of action. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 10:30 ` Chris Wilson @ 2011-04-05 10:37 ` Pekka Enberg 2011-04-05 11:55 ` Tomas Winkler 2011-04-05 14:11 ` Pekka Enberg 2011-04-05 14:42 ` Linus Torvalds 1 sibling, 2 replies; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 10:37 UTC (permalink / raw) To: Chris Wilson Cc: Tomas Winkler, intel-gfx, linux-kernel, Daniel Vetter, Linus Torvalds, Andrew Morton Hi Chris! On Tue, Apr 5, 2011 at 1:30 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote: >> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: >> > Unfortunately I get a blank screen with after boot: >> > Nacked-by: Pekka Enberg <penberg@kernel.org> > > But until you can tell me where it explodes on your system, we fix > issues on several other machines... Oh, that's nice, you first made the damn thing flicker in 2.6.39-rc1 and now you're fixing it for others by giving me a blank screen after boot? I guess I don't need to tell you that I am not at all happy especially since you keep breaking i915 in almost every damn release! >> Not sure this is related, but when I enable DRM_I915_KMS=y I'm got >> stuck after boot too. When KMS is disabled I can at least get to the >> console (no graphics) >> This is with kernel 2.6.39-rc1. It worked fine with 2.6.38. I don't >> have much time bisect and reboot. Shell I try to pull drm-fixes for >> rc2 or use try this patch? > > Add drm.debug=0xe to your grub kernel parameters and attach the dmesg for > the failing boot. From that I should be able to recommend a course of > action. OK, I'll try that tonight. Pekka ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 10:37 ` Pekka Enberg @ 2011-04-05 11:55 ` Tomas Winkler 2011-04-05 14:11 ` Pekka Enberg 1 sibling, 0 replies; 25+ messages in thread From: Tomas Winkler @ 2011-04-05 11:55 UTC (permalink / raw) To: Chris Wilson, intel-gfx, linux-kernel, Daniel Vetter, Linus Torvalds On Tue, Apr 5, 2011 at 1:37 PM, Pekka Enberg <penberg@kernel.org> wrote: > Hi Chris! > > On Tue, Apr 5, 2011 at 1:30 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote: >>> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: >>> > Unfortunately I get a blank screen with after boot: >>> > Nacked-by: Pekka Enberg <penberg@kernel.org> >> >> But until you can tell me where it explodes on your system, we fix >> issues on several other machines... > > Oh, that's nice, you first made the damn thing flicker in 2.6.39-rc1 > and now you're fixing it for others by giving me a blank screen after > boot? > > I guess I don't need to tell you that I am not at all happy especially > since you keep breaking i915 in almost every damn release! > >>> Not sure this is related, but when I enable DRM_I915_KMS=y I'm got >>> stuck after boot too. When KMS is disabled I can at least get to the >>> console (no graphics) >>> This is with kernel 2.6.39-rc1. It worked fine with 2.6.38. I don't >>> have much time bisect and reboot. Shell I try to pull drm-fixes for >>> rc2 or use try this patch? merging drm-fixes for rc2 definitely helped booting. >> Add drm.debug=0xe to your grub kernel parameters and attach the dmesg for >> the failing boot. From that I should be able to recommend a course of >> action. There are some error messages 4.311738] [drm:intel_crt_init], pch crt adpa set to 0xf40000 [ 4.311792] [drm:intel_dp_i2c_init], i2c_init DPDDC-C [ 4.312300] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 4.312302] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 4.312814] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 4.312815] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 4.312848] [drm:intel_dp_i2c_init], i2c_init DPDDC-D [ 4.313357] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 4.313358] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 4.313866] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e [ 4.313868] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 4.313886] [drm:intel_panel_get_backlight], get backlight PWM = 0 [ 4.313891] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 4.314378] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off [ 4.314381] [drm:i915_get_vblank_timestamp], crtc 0 is disabled [ 4.343908] [drm:intel_update_fbc], [ 4.343910] [drm:ironlake_crtc_dpms], crtc 1/1 dpms off [ 4.343912] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe B [ 4.343914] [drm:i915_get_vblank_timestamp], crtc 1 is disabled [ 4.343916] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe B [ 4.344555] [drm:intel_update_fbc], [ 4.344559] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] [ 4.344562] [drm:intel_ironlake_crt_detect_hotplug], trigger hotplug detect cycle: adpa=0xf40000 [ 4.354477] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40000, result 0 [ 4.354483] [drm:intel_crt_detect], CRT not detected via hotplug [ 4.354488] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] disconnected [ 4.354493] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] [ 4.364484] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:8:HDMI-A-1] disconnected [ 4.364491] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:HDMI-A-2] [ 4.416299] [drm] GMBUS timed out, falling back to bit banging on pin 7 [i915 gmbus dpd] [ 4.537460] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:HDMI-A-2] probed modes : [ 4.537462] [drm:drm_mode_debug_printmodeline], Modeline 21:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 Tomas ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 10:37 ` Pekka Enberg 2011-04-05 11:55 ` Tomas Winkler @ 2011-04-05 14:11 ` Pekka Enberg 2011-04-05 14:27 ` Chris Wilson 2011-04-05 14:34 ` Chris Wilson 1 sibling, 2 replies; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 14:11 UTC (permalink / raw) To: Chris Wilson Cc: Tomas Winkler, intel-gfx, linux-kernel, Daniel Vetter, Linus Torvalds, Andrew Morton On Tue, Apr 5, 2011 at 1:37 PM, Pekka Enberg <penberg@kernel.org> wrote: > Hi Chris! > > On Tue, Apr 5, 2011 at 1:30 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote: >>> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: >>> > Unfortunately I get a blank screen with after boot: >>> > Nacked-by: Pekka Enberg <penberg@kernel.org> >> >> But until you can tell me where it explodes on your system, we fix >> issues on several other machines... > > Oh, that's nice, you first made the damn thing flicker in 2.6.39-rc1 > and now you're fixing it for others by giving me a blank screen after > boot? I compiled i195 drm as module and I now see this with netconsole: [ 4.861272] i8042: No controller found [ 5.260688] Unable to load isight firmware [ 7.120150] usbhid 5-1:1.0: couldn't find an input interrupt endpoint [ 9.310010] [ 9.310010] Pid: 3757, comm: sh Not tainted 2.6.38+ #18 Apple Inc. MacBook2,1/Mac-F4208CAA [ 9.310010] RIP: 0010:[<0000000000000000>] [< (null)>] (null) [ 9.310010] RSP: 0018:ffff88003de03d80 EFLAGS: 00010096 [ 9.310010] RAX: 000000000000006d RBX: ffff88002e6be000 RCX: 000000000003ffff [ 9.310010] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffff88002e6be030 [ 9.310010] RBP: ffff88003de03de8 R08: 0000000000000000 R09: 0000000000000000 [ 9.310010] R10: 0000000000000006 R11: 0000000000000003 R12: ffff88002e5db800 [ 9.310010] R13: ffff88002e6be82c R14: ffff88003ad24200 R15: 0000000000000000 [ 9.310010] FS: 00007f60f21aa700(0000) GS:ffff88003de00000(0000) knlGS:0000000000000000 [ 9.310010] [<ffffffffa0061628>] ? i915_handle_error+0x198/0xed0 [i915] [ 9.310010] [<ffffffff8137d04a>] ? scsi_next_command+0x4a/0x60 [ 9.310010] [<ffffffff8137ddd6>] ? scsi_io_completion+0x2f6/0x630 [ 9.310010] [<ffffffffa0064c62>] i915_driver_irq_handler+0x472/0x17f0 [i915] [ 9.310010] [<ffffffff810e150d>] handle_irq_event_percpu+0x5d/0x210 [ 9.310010] [<ffffffff8108c56c>] ? __do_softirq+0x11c/0x200 [ 9.310010] [<ffffffff8108c56c>] ? __do_softirq+0x11c/0x200 [ 9.310010] [<ffffffff810e173a>] handle_irq_event+0x4a/0x80 [ 9.310010] [<ffffffff810e42c1>] handle_fasteoi_irq+0x51/0xc0 [ 9.310010] [<ffffffff8103e3a2>] handle_irq+0x22/0x30 [ 9.310010] [<ffffffff81698e0d>] do_IRQ+0x5d/0xe0 [ 9.310010] [<ffffffff8168fad3>] common_interrupt+0x13/0x13 [ 9.310010] <EOI> [ 9.310010] Call Trace: [ 9.310010] <IRQ> [<ffffffff8168cd0c>] panic+0x91/0x19e [ 9.310010] [<ffffffff816909ea>] oops_end+0xea/0xf0 [ 9.310010] [<ffffffff8106afbb>] no_context+0xfb/0x260 [ 9.310010] [<ffffffff8106b245>] __bad_area_nosemaphore+0x125/0x1e0 [ 9.310010] [<ffffffff8106b313>] bad_area_nosemaphore+0x13/0x20 [ 9.310010] [<ffffffff816930c0>] do_page_fault+0x310/0x4c0 [ 9.310010] [<ffffffff810ac06f>] ? up+0x2f/0x50 [ 9.310010] [<ffffffff8108652f>] ? console_unlock+0x17f/0x1d0 [ 9.310010] [<ffffffff8168fd25>] page_fault+0x25/0x30 [ 9.310010] [<ffffffffa0061628>] ? i915_handle_error+0x198/0xed0 [i915] [ 9.310010] [<ffffffff8137d04a>] ? scsi_next_command+0x4a/0x60 [ 9.310010] [<ffffffff8137ddd6>] ? scsi_io_completion+0x2f6/0x630 [ 9.310010] [<ffffffffa0064c62>] i915_driver_irq_handler+0x472/0x17f0 [i915] This is the same pre-2.6.39-rc1 kernel with the two patches applied. I'll try latest Linus master next to see if the same problem triggers. Pekka ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:11 ` Pekka Enberg @ 2011-04-05 14:27 ` Chris Wilson 2011-04-05 14:31 ` [Intel-gfx] " Pekka Enberg 2011-04-05 14:34 ` Chris Wilson 1 sibling, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-04-05 14:27 UTC (permalink / raw) To: Pekka Enberg Cc: Tomas Winkler, intel-gfx, linux-kernel, Andrew Morton, Linus Torvalds On Tue, 5 Apr 2011 17:11:56 +0300, Pekka Enberg <penberg@kernel.org> wrote: > [ 9.310010] <IRQ> [<ffffffff8168cd0c>] panic+0x91/0x19e > [ 9.310010] [<ffffffff816909ea>] oops_end+0xea/0xf0 > [ 9.310010] [<ffffffff8106afbb>] no_context+0xfb/0x260 > [ 9.310010] [<ffffffff8106b245>] __bad_area_nosemaphore+0x125/0x1e0 > [ 9.310010] [<ffffffff8106b313>] bad_area_nosemaphore+0x13/0x20 > [ 9.310010] [<ffffffff816930c0>] do_page_fault+0x310/0x4c0 > [ 9.310010] [<ffffffff810ac06f>] ? up+0x2f/0x50 > [ 9.310010] [<ffffffff8108652f>] ? console_unlock+0x17f/0x1d0 > [ 9.310010] [<ffffffff8168fd25>] page_fault+0x25/0x30 > [ 9.310010] [<ffffffffa0061628>] ? i915_handle_error+0x198/0xed0 [i915] > [ 9.310010] [<ffffffff8137d04a>] ? scsi_next_command+0x4a/0x60 > [ 9.310010] [<ffffffff8137ddd6>] ? scsi_io_completion+0x2f6/0x630 > [ 9.310010] [<ffffffffa0064c62>] i915_driver_irq_handler+0x472/0x17f0 [i915] > > This is the same pre-2.6.39-rc1 kernel with the two patches applied. > I'll try latest Linus master next to see if the same problem triggers. Hmm. Looks like we don't prevent the PGTBL_ER with those patches (or we provoke another), and trigger the error before we can handle it. Double ungood. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:27 ` Chris Wilson @ 2011-04-05 14:31 ` Pekka Enberg 0 siblings, 0 replies; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 14:31 UTC (permalink / raw) To: Chris Wilson Cc: Tomas Winkler, intel-gfx, linux-kernel, Daniel Vetter, Linus Torvalds, Andrew Morton On Tue, Apr 5, 2011 at 5:27 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 5 Apr 2011 17:11:56 +0300, Pekka Enberg <penberg@kernel.org> wrote: >> [ 9.310010] <IRQ> [<ffffffff8168cd0c>] panic+0x91/0x19e >> [ 9.310010] [<ffffffff816909ea>] oops_end+0xea/0xf0 >> [ 9.310010] [<ffffffff8106afbb>] no_context+0xfb/0x260 >> [ 9.310010] [<ffffffff8106b245>] __bad_area_nosemaphore+0x125/0x1e0 >> [ 9.310010] [<ffffffff8106b313>] bad_area_nosemaphore+0x13/0x20 >> [ 9.310010] [<ffffffff816930c0>] do_page_fault+0x310/0x4c0 >> [ 9.310010] [<ffffffff810ac06f>] ? up+0x2f/0x50 >> [ 9.310010] [<ffffffff8108652f>] ? console_unlock+0x17f/0x1d0 >> [ 9.310010] [<ffffffff8168fd25>] page_fault+0x25/0x30 >> [ 9.310010] [<ffffffffa0061628>] ? i915_handle_error+0x198/0xed0 [i915] >> [ 9.310010] [<ffffffff8137d04a>] ? scsi_next_command+0x4a/0x60 >> [ 9.310010] [<ffffffff8137ddd6>] ? scsi_io_completion+0x2f6/0x630 >> [ 9.310010] [<ffffffffa0064c62>] i915_driver_irq_handler+0x472/0x17f0 [i915] >> >> This is the same pre-2.6.39-rc1 kernel with the two patches applied. >> I'll try latest Linus master next to see if the same problem triggers. > > Hmm. Looks like we don't prevent the PGTBL_ER with those patches (or we > provoke another), and trigger the error before we can handle it. I'm guessing it's the same PGTBL_ER I've seen for the past two-three kernel releases during boot. It seems to be harmless otherwise. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:11 ` Pekka Enberg 2011-04-05 14:27 ` Chris Wilson @ 2011-04-05 14:34 ` Chris Wilson 2011-04-05 15:11 ` Pekka Enberg 1 sibling, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-04-05 14:34 UTC (permalink / raw) To: Pekka Enberg; +Cc: intel-gfx, linux-kernel, Chris Wilson If the outputs are active and continuing to access the GATT when we teardown the PTEs, then there is a potential for us to hang the GPU. The hang tends to be a PGTBL_ER with either an invalid host access or an invalid display plane fetch. v2: Reorder IRQ initialisation to defer until after GEM is setup. Reported-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM) --- drivers/gpu/drm/i915/i915_dma.c | 31 ++++++++++++++++++++++--------- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_display.c | 17 +++++++++++------ drivers/gpu/drm/i915/intel_dp.c | 9 +++++++++ 4 files changed, 43 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 7273037..b28e023 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1176,11 +1176,11 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev) return can_switch; } -static int i915_load_modeset_init(struct drm_device *dev) +static int i915_load_gem_init(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; unsigned long prealloc_size, gtt_size, mappable_size; - int ret = 0; + int ret; prealloc_size = dev_priv->mm.gtt->stolen_size; gtt_size = dev_priv->mm.gtt->gtt_total_entries << PAGE_SHIFT; @@ -1204,7 +1204,7 @@ static int i915_load_modeset_init(struct drm_device *dev) ret = i915_gem_init_ringbuffer(dev); mutex_unlock(&dev->struct_mutex); if (ret) - goto out; + return ret; /* Try to set up FBC with a reasonable compressed buffer size */ if (I915_HAS_FBC(dev) && i915_powersave) { @@ -1222,6 +1222,13 @@ static int i915_load_modeset_init(struct drm_device *dev) /* Allow hardware batchbuffers unless told otherwise. */ dev_priv->allow_batchbuffer = 1; + return 0; +} + +static int i915_load_modeset_init(struct drm_device *dev) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + int ret; ret = intel_parse_bios(dev); if (ret) @@ -1236,7 +1243,7 @@ static int i915_load_modeset_init(struct drm_device *dev) */ ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode); if (ret && ret != -ENODEV) - goto cleanup_ringbuffer; + goto out; intel_register_dsm_handler(); @@ -1253,10 +1260,16 @@ static int i915_load_modeset_init(struct drm_device *dev) intel_modeset_init(dev); - ret = drm_irq_install(dev); + ret = i915_load_gem_init(dev); if (ret) goto cleanup_vga_switcheroo; + intel_modeset_gem_init(dev); + + ret = drm_irq_install(dev); + if (ret) + goto cleanup_gem; + /* Always safe in the mode setting case. */ /* FIXME: do pre/post-mode set stuff in core KMS code */ dev->vblank_disable_allowed = 1; @@ -1274,14 +1287,14 @@ static int i915_load_modeset_init(struct drm_device *dev) cleanup_irq: drm_irq_uninstall(dev); +cleanup_gem: + mutex_lock(&dev->struct_mutex); + i915_gem_cleanup_ringbuffer(dev); + mutex_unlock(&dev->struct_mutex); cleanup_vga_switcheroo: vga_switcheroo_unregister_client(dev->pdev); cleanup_vga_client: vga_client_register(dev->pdev, NULL, NULL, NULL); -cleanup_ringbuffer: - mutex_lock(&dev->struct_mutex); - i915_gem_cleanup_ringbuffer(dev); - mutex_unlock(&dev->struct_mutex); out: return ret; } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 359ddce..60ebd79 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1268,6 +1268,7 @@ static inline void intel_unregister_dsm_handler(void) { return; } /* modesetting */ extern void intel_modeset_init(struct drm_device *dev); +extern void intel_modeset_gem_init(struct drm_device *dev); extern void intel_modeset_cleanup(struct drm_device *dev); extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state); extern void i8xx_disable_fbc(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 432fc04..5c7385b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6497,6 +6497,9 @@ static void intel_setup_outputs(struct drm_device *dev) } intel_panel_setup_backlight(dev); + + /* disable all the possible outputs/crtcs before entering KMS mode */ + drm_helper_disable_unused_functions(dev); } static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) @@ -7432,13 +7435,12 @@ void intel_modeset_init(struct drm_device *dev) intel_crtc_init(dev, i); } + /* Just disable it once at startup */ + i915_disable_vga(dev); intel_setup_outputs(dev); intel_enable_clock_gating(dev); - /* Just disable it once at startup */ - i915_disable_vga(dev); - if (IS_IRONLAKE_M(dev)) { ironlake_enable_drps(dev); intel_init_emon(dev); @@ -7447,12 +7449,15 @@ void intel_modeset_init(struct drm_device *dev) if (IS_GEN6(dev)) gen6_enable_rps(dev_priv); - if (IS_IRONLAKE_M(dev)) - ironlake_enable_rc6(dev); - INIT_WORK(&dev_priv->idle_work, intel_idle_update); setup_timer(&dev_priv->idle_timer, intel_gpu_idle_timer, (unsigned long)dev); +} + +void intel_modeset_gem_init(struct drm_device *dev) +{ + if (IS_IRONLAKE_M(dev)) + ironlake_enable_rc6(dev); intel_setup_overlay(dev); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 0daefca..6caeabb 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -218,7 +218,16 @@ intel_dp_mode_valid(struct drm_connector *connector, if (!is_edp(intel_dp) && (intel_dp_link_required(connector->dev, intel_dp, mode->clock) > intel_dp_max_data_rate(max_link_clock, max_lanes))) + { + DRM_DEBUG_KMS("mode exceeds DP bandwidth: required=%d, max=%d [clock=%d, lanes=%d]\n", + intel_dp_link_required(connector->dev, + intel_dp, + mode->clock), + intel_dp_max_data_rate(max_link_clock, + max_lanes), + max_link_clock, max_lanes); return MODE_CLOCK_HIGH; + } if (mode->clock < 10000) return MODE_CLOCK_LOW; -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:34 ` Chris Wilson @ 2011-04-05 15:11 ` Pekka Enberg 2011-04-05 15:32 ` Chris Wilson 0 siblings, 1 reply; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 15:11 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, Linus Torvalds, keith.packard, danie.vettel [-- Attachment #1: Type: text/plain, Size: 1240 bytes --] Hi Chris, On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > If the outputs are active and continuing to access the GATT when we > teardown the PTEs, then there is a potential for us to hang the GPU. > The hang tends to be a PGTBL_ER with either an invalid host access or > an invalid display plane fetch. > > v2: Reorder IRQ initialisation to defer until after GEM is setup. > > Reported-by: Pekka Enberg <penberg@kernel.org> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM) I no longer get a blank screen after boot but flicker got more aggressive during boot (it calms down after I've logged in). I see tons of these in dmesg that don't appear with 2.6.39-rc1: [ 10.175843] [drm:intel_update_fbc], [ 10.183100] [drm:i915_driver_irq_handler], pipe A underrun [ 10.185085] [drm:i915_driver_irq_handler], pipe A underrun [ 10.186082] [drm:i915_driver_irq_handler], pipe A underrun [ 10.187087] [drm:i915_driver_irq_handler], pipe A underrun [ 10.189082] [drm:i915_driver_irq_handler], pipe A underrun [ 10.190085] [drm:i915_driver_irq_handler], pipe A underrun I've attached the full dmesg. Pekka [-- Attachment #2: dmesg.gz --] [-- Type: application/x-gzip, Size: 30692 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 15:11 ` Pekka Enberg @ 2011-04-05 15:32 ` Chris Wilson 2011-04-05 15:44 ` Pekka Enberg 0 siblings, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-04-05 15:32 UTC (permalink / raw) To: Pekka Enberg Cc: intel-gfx, Linus Torvalds, linux-kernel, danie.vettel, keith.packard On Tue, 5 Apr 2011 18:11:37 +0300, Pekka Enberg <penberg@kernel.org> wrote: > Hi Chris, > > On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > If the outputs are active and continuing to access the GATT when we > > teardown the PTEs, then there is a potential for us to hang the GPU. > > The hang tends to be a PGTBL_ER with either an invalid host access or > > an invalid display plane fetch. > > > > v2: Reorder IRQ initialisation to defer until after GEM is setup. > > > > Reported-by: Pekka Enberg <penberg@kernel.org> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM) > > I no longer get a blank screen after boot but flicker got more > aggressive during boot (it calms down after I've logged in). I see > tons of these in dmesg that don't appear with 2.6.39-rc1: Well the PGTBL_ER is still there. I'm thinking it might worth a check to see if that is asserted even before we start... > [ 10.175843] [drm:intel_update_fbc], > [ 10.183100] [drm:i915_driver_irq_handler], pipe A underrun > [ 10.185085] [drm:i915_driver_irq_handler], pipe A underrun > [ 10.186082] [drm:i915_driver_irq_handler], pipe A underrun > [ 10.187087] [drm:i915_driver_irq_handler], pipe A underrun > [ 10.189082] [drm:i915_driver_irq_handler], pipe A underrun > [ 10.190085] [drm:i915_driver_irq_handler], pipe A underrun If I'm understanding the dmesg correctly, then these start even before we setup the first crtc. Whether that means we're not completely disabling all outputs or that we set a register incorrectly I don't know. Comparing an intel_reg_dumper with and without the patch applied might give a clue if it is a register that is set differently due to the reordering. The other question is of course whether you see those in 2.6.39-rc1 as well... Probably not since they will correspond with the increased flicker. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 15:32 ` Chris Wilson @ 2011-04-05 15:44 ` Pekka Enberg 0 siblings, 0 replies; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 15:44 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, Linus Torvalds, keith.packard, danie.vettel [-- Attachment #1: Type: text/plain, Size: 2341 bytes --] On Tue, Apr 5, 2011 at 6:32 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 5 Apr 2011 18:11:37 +0300, Pekka Enberg <penberg@kernel.org> wrote: >> Hi Chris, >> >> On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: >> > If the outputs are active and continuing to access the GATT when we >> > teardown the PTEs, then there is a potential for us to hang the GPU. >> > The hang tends to be a PGTBL_ER with either an invalid host access or >> > an invalid display plane fetch. >> > >> > v2: Reorder IRQ initialisation to defer until after GEM is setup. >> > >> > Reported-by: Pekka Enberg <penberg@kernel.org> >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM) >> >> I no longer get a blank screen after boot but flicker got more >> aggressive during boot (it calms down after I've logged in). I see >> tons of these in dmesg that don't appear with 2.6.39-rc1: > > Well the PGTBL_ER is still there. I'm thinking it might worth a check to > see if that is asserted even before we start... > >> [ 10.175843] [drm:intel_update_fbc], >> [ 10.183100] [drm:i915_driver_irq_handler], pipe A underrun >> [ 10.185085] [drm:i915_driver_irq_handler], pipe A underrun >> [ 10.186082] [drm:i915_driver_irq_handler], pipe A underrun >> [ 10.187087] [drm:i915_driver_irq_handler], pipe A underrun >> [ 10.189082] [drm:i915_driver_irq_handler], pipe A underrun >> [ 10.190085] [drm:i915_driver_irq_handler], pipe A underrun > > If I'm understanding the dmesg correctly, then these start even before we > setup the first crtc. > > Whether that means we're not completely disabling all outputs or that we > set a register incorrectly I don't know. Comparing an intel_reg_dumper > with and without the patch applied might give a clue if it is a register > that is set differently due to the reordering. > > The other question is of course whether you see those in 2.6.39-rc1 as > well... Probably not since they will correspond with the increased > flicker. Actually, I do. I guess that logging is enabled by 'drm.debug=0xe'? I've included dmesg from latest Linus master. As for the v2 of the patch: Tested-by: Pekka Enberg <penberg@kernel.org> (i915) Pekka [-- Attachment #2: dmesg.gz --] [-- Type: application/x-gzip, Size: 29227 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 10:30 ` Chris Wilson 2011-04-05 10:37 ` Pekka Enberg @ 2011-04-05 14:42 ` Linus Torvalds 2011-04-05 15:01 ` Keith Packard 2011-04-05 15:12 ` [Intel-gfx] " Chris Wilson 1 sibling, 2 replies; 25+ messages in thread From: Linus Torvalds @ 2011-04-05 14:42 UTC (permalink / raw) To: Chris Wilson, Keith Packard Cc: Pekka Enberg, intel-gfx, Tomas Winkler, linux-kernel On Tue, Apr 5, 2011 at 3:30 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote: >> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote: >> > Unfortunately I get a blank screen with after boot: >> > Nacked-by: Pekka Enberg <penberg@kernel.org> > > But until you can tell me where it explodes on your system, we fix > issues on several other machines... NO. Chris, you need to understand the issue of "NO REGRESSIONS". It's a very simple rule: it DOES NOT MATTER ONE WHIT how many machines you fix. You never ever regress. Patches that cause regressions are reverted. There are multiple reasons for that rule, but the basic one ends up being very simple: you only _think_ you fix more machines than you break. Why? Because the people who test out your patches are the "active" people - and often predominantly the active people who have problems. In contrast, the people for whom things already work aren't even testing your patches in the first place. Then, six months later, when they update to a new Fedora version, things suddenly don't work for them, and it turns out that yes, you fixed ten active testers, but you broke a thousand random people. So even _one_ person saying "this is a regression" is a total blocker. Really. It's that simple. YOU NEVER EVER BREAK WORKING MACHINES. Seriously. We had this for years in ACPI-land and with suspend/resume with "one step forward, two steps back", and nobody ever knew if we were doing any real progress at all, because machines that had working suspend/resume one kernel version would be broken again the next. There was no real pattern of improvement, there was just a random pattern of "things get fixed on one machine, and break on another". We introduced the "no regressions" rule, and things got seriously better. Suddenly things started getting _reliably_ better. The whole situation with i915 has been pretty damn random lately, and you really really need to understand that this is simply not how it's done. Your cavalier attitude ("but it fixes things for others") is absolutely not acceptable. Keith Cc'd, because that patch had better not show up in my tree. Linus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:42 ` Linus Torvalds @ 2011-04-05 15:01 ` Keith Packard 2011-04-05 15:12 ` [Intel-gfx] " Chris Wilson 1 sibling, 0 replies; 25+ messages in thread From: Keith Packard @ 2011-04-05 15:01 UTC (permalink / raw) To: Linus Torvalds, Chris Wilson Cc: Pekka Enberg, intel-gfx, Tomas Winkler, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 296 bytes --] On Tue, 5 Apr 2011 07:42:14 -0700, Linus Torvalds <torvalds@linux-foundation.org> wrote: > Keith Cc'd, because that patch had better not show up in my tree. Having experienced the delights of ACPI in the past, I have already subscribed to your newsletter. -- keith.packard@intel.com [-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 14:42 ` Linus Torvalds 2011-04-05 15:01 ` Keith Packard @ 2011-04-05 15:12 ` Chris Wilson 2011-04-05 15:35 ` Pekka Enberg 1 sibling, 1 reply; 25+ messages in thread From: Chris Wilson @ 2011-04-05 15:12 UTC (permalink / raw) To: Linus Torvalds, Keith Packard Cc: Tomas Winkler, Pekka Enberg, intel-gfx, linux-kernel, Daniel Vetter On Tue, 5 Apr 2011 07:42:14 -0700, Linus Torvalds <torvalds@linux-foundation.org> wrote: > NO. And you seemed to have missed that patch has sat around waiting for Pekka to give me some information on the failure on his machine. I have been poking as many people as I could to get it reviewed and tested on more machines so that someone else could either spot the problem or capture the oops. I was being facetious in order to get a response. Thanks for playing, -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover 2011-04-05 15:12 ` [Intel-gfx] " Chris Wilson @ 2011-04-05 15:35 ` Pekka Enberg 0 siblings, 0 replies; 25+ messages in thread From: Pekka Enberg @ 2011-04-05 15:35 UTC (permalink / raw) To: Chris Wilson Cc: Linus Torvalds, Keith Packard, Tomas Winkler, intel-gfx, linux-kernel, Daniel Vetter On Tue, 5 Apr 2011 07:42:14 -0700, Linus Torvalds <torvalds@linux-foundation.org> wrote: >> NO. On Tue, Apr 5, 2011 at 6:12 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > And you seemed to have missed that patch has sat around waiting for Pekka > to give me some information on the failure on his machine. No, it wasn't. I told you I wasn't able to capture anything useful and that 2.6.38 didn't have the problem. On Tue, Apr 5, 2011 at 6:12 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > I was being facetious in order to get a response. Thanks for playing, I am happy to test patches but I don't appreciate being blackmailed into debugging your shit. Pekka ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2011-04-05 15:44 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <AANLkTi=VqkYjdiDLJvM-OfmBSGx-EkRkt=4XCDEnvZsU@mail.gmail.com> 2011-03-29 10:46 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Chris Wilson 2011-03-29 12:23 ` [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init Chris Wilson 2011-03-29 13:05 ` Pekka Enberg 2011-03-29 13:22 ` Chris Wilson 2011-03-29 13:39 ` Pekka Enberg 2011-03-29 14:22 ` Pekka Enberg 2011-03-29 14:32 ` Chris Wilson 2011-03-29 15:21 ` Pekka Enberg 2011-04-01 11:44 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Daniel Vetter 2011-04-01 11:51 ` [Intel-gfx] " Pekka Enberg 2011-04-05 10:21 ` Tomas Winkler 2011-04-05 10:30 ` Chris Wilson 2011-04-05 10:37 ` Pekka Enberg 2011-04-05 11:55 ` Tomas Winkler 2011-04-05 14:11 ` Pekka Enberg 2011-04-05 14:27 ` Chris Wilson 2011-04-05 14:31 ` [Intel-gfx] " Pekka Enberg 2011-04-05 14:34 ` Chris Wilson 2011-04-05 15:11 ` Pekka Enberg 2011-04-05 15:32 ` Chris Wilson 2011-04-05 15:44 ` Pekka Enberg 2011-04-05 14:42 ` Linus Torvalds 2011-04-05 15:01 ` Keith Packard 2011-04-05 15:12 ` [Intel-gfx] " Chris Wilson 2011-04-05 15:35 ` Pekka Enberg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).