backtrace with 3.9.0-rc4 on MBP retina

backtrace with 3.9.0-rc4 on MBP retina

[Dave Airlie]

Just stuck 3.9.0-rc4 on my MBP today, got this throwing up.

Dave.

[    3.482355] [drm] Memory usable by graphics device = 2048M
[    3.482381] i915 0000:00:02.0: setting latency timer to 64
[    3.482768] sdhci-pci 0000:03:00.1: SDHCI controller found
[14e4:16bc] (rev 10)
[    3.482825] sdhci-pci 0000:03:00.1: enabling device (0000 -> 0002)
[    3.512438] mmc0: SDHCI controller on PCI [0000:03:00.1] using ADMA
[    3.524138] i915 0000:00:02.0: irq 53 for MSI/MSI-X
[    3.524150] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    3.524151] [drm] Driver supports precise vblank timestamp query.
[    3.524158] i915 0000:00:02.0: Invalid ROM contents
[    3.524162] [drm] failed to find VBIOS tables
[    3.524486] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[    3.524488] vgaarb: transferring owner from PCI:0000:00:02.0 to
PCI:0000:01:00.0
[    3.557336] [drm] failed to retrieve link info, disabling eDP
[    3.557787] ------------[ cut here ]------------
[    3.557805] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1132
ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()
[    3.557806] Hardware name: MacBookPro10,1
[    3.557807] Modules linked in: sdhci_pci sdhci mmc_core i915(+)
nouveau(+) mxm_wmi wmi ttm i2c_algo_bit drm_kms_helper drm i2c_core
video
[    3.557816] Pid: 172, comm: systemd-udevd Tainted: G        W
3.9.0-rc4+ #34
[    3.557817] Call Trace:
[    3.557822]  [<ffffffff81060b2f>] warn_slowpath_common+0x7f/0xc0
[    3.557825]  [<ffffffff81060b8a>] warn_slowpath_null+0x1a/0x20
[    3.557836]  [<ffffffffa01eb45f>]
ironlake_panel_vdd_off_sync+0xef/0x100 [i915]
[    3.557846]  [<ffffffffa01ec814>] intel_dp_encoder_destroy+0x64/0x70 [i915]
[    3.557856]  [<ffffffffa01ef716>] intel_dp_init_connector+0xaa6/0xac0 [i915]
[    3.557864]  [<ffffffffa002c3f2>] ? drm_modeset_unlock_all+0x52/0x60 [drm]
[    3.557874]  [<ffffffffa01ef836>] intel_dp_init+0x106/0x140 [i915]
[    3.557884]  [<ffffffffa01e3bf9>] intel_modeset_init+0xbf9/0xea0 [i915]
[    3.557894]  [<ffffffffa01b40e1>] i915_driver_load+0xb81/0xe30 [i915]
[    3.557901]  [<ffffffffa0028c16>] drm_get_pci_dev+0x186/0x2d0 [drm]
[    3.557904]  [<ffffffff810c4ffd>] ? trace_hardirqs_on+0xd/0x10
[    3.557913]  [<ffffffffa01af33c>] i915_pci_probe+0x3c/0x90 [i915]
[    3.557915]  [<ffffffff813300ab>] local_pci_probe+0x4b/0x80
[    3.557918]  [<ffffffff81330311>] pci_device_probe+0x111/0x120
[    3.557921]  [<ffffffff8141188b>] driver_probe_device+0x8b/0x390
[    3.557923]  [<ffffffff81411c3b>] __driver_attach+0xab/0xb0
[    3.557926]  [<ffffffff81411b90>] ? driver_probe_device+0x390/0x390
[    3.557928]  [<ffffffff8140f80d>] bus_for_each_dev+0x5d/0xa0
[    3.557930]  [<ffffffff814111ee>] driver_attach+0x1e/0x20
[    3.557933]  [<ffffffff81410d81>] bus_add_driver+0x121/0x2b0
[    3.557935]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
[    3.557937]  [<ffffffff81412327>] driver_register+0x77/0x170
[    3.557939]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
[    3.557941]  [<ffffffff8132f0a4>] __pci_register_driver+0x64/0x70
[    3.557946]  [<ffffffffa0028e7a>] drm_pci_init+0x11a/0x130 [drm]
[    3.557948]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
[    3.557956]  [<ffffffffa0246066>] i915_init+0x66/0x68 [i915]
[    3.557959]  [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
[    3.557962]  [<ffffffff810d10ce>] load_module+0x1c3e/0x27e0
[    3.557964]  [<ffffffff81324010>] ? ddebug_proc_open+0xd0/0xd0
[    3.557967]  [<ffffffff8131261e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    3.557969]  [<ffffffff810d1d47>] sys_init_module+0xd7/0x120
[    3.557972]  [<ffffffff8168e3d9>] system_call_fastpath+0x16/0x1b
[    3.557973] ---[ end trace 6cad52bf765be3e1 ]---

Re: backtrace with 3.9.0-rc4 on MBP retina

[Daniel Vetter]

On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie <airlied@gmail.com> wrote:
> Just stuck 3.9.0-rc4 on my MBP today, got this throwing up.

Is the bad stuff just the WARN (bad locking in our init code,
surprise!) or did i915.ko kill your eDP panel? Or is the
non-responsive panel just the usual apple gpu switching fail we have?
-Daniel

> [    3.482355] [drm] Memory usable by graphics device = 2048M
> [    3.482381] i915 0000:00:02.0: setting latency timer to 64
> [    3.482768] sdhci-pci 0000:03:00.1: SDHCI controller found
> [14e4:16bc] (rev 10)
> [    3.482825] sdhci-pci 0000:03:00.1: enabling device (0000 -> 0002)
> [    3.512438] mmc0: SDHCI controller on PCI [0000:03:00.1] using ADMA
> [    3.524138] i915 0000:00:02.0: irq 53 for MSI/MSI-X
> [    3.524150] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [    3.524151] [drm] Driver supports precise vblank timestamp query.
> [    3.524158] i915 0000:00:02.0: Invalid ROM contents
> [    3.524162] [drm] failed to find VBIOS tables
> [    3.524486] vgaarb: device changed decodes:
> PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
> [    3.524488] vgaarb: transferring owner from PCI:0000:00:02.0 to
> PCI:0000:01:00.0
> [    3.557336] [drm] failed to retrieve link info, disabling eDP
> [    3.557787] ------------[ cut here ]------------
> [    3.557805] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1132
> ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()
> [    3.557806] Hardware name: MacBookPro10,1
> [    3.557807] Modules linked in: sdhci_pci sdhci mmc_core i915(+)
> nouveau(+) mxm_wmi wmi ttm i2c_algo_bit drm_kms_helper drm i2c_core
> video
> [    3.557816] Pid: 172, comm: systemd-udevd Tainted: G        W
> 3.9.0-rc4+ #34
> [    3.557817] Call Trace:
> [    3.557822]  [<ffffffff81060b2f>] warn_slowpath_common+0x7f/0xc0
> [    3.557825]  [<ffffffff81060b8a>] warn_slowpath_null+0x1a/0x20
> [    3.557836]  [<ffffffffa01eb45f>]
> ironlake_panel_vdd_off_sync+0xef/0x100 [i915]
> [    3.557846]  [<ffffffffa01ec814>] intel_dp_encoder_destroy+0x64/0x70 [i915]
> [    3.557856]  [<ffffffffa01ef716>] intel_dp_init_connector+0xaa6/0xac0 [i915]
> [    3.557864]  [<ffffffffa002c3f2>] ? drm_modeset_unlock_all+0x52/0x60 [drm]
> [    3.557874]  [<ffffffffa01ef836>] intel_dp_init+0x106/0x140 [i915]
> [    3.557884]  [<ffffffffa01e3bf9>] intel_modeset_init+0xbf9/0xea0 [i915]
> [    3.557894]  [<ffffffffa01b40e1>] i915_driver_load+0xb81/0xe30 [i915]
> [    3.557901]  [<ffffffffa0028c16>] drm_get_pci_dev+0x186/0x2d0 [drm]
> [    3.557904]  [<ffffffff810c4ffd>] ? trace_hardirqs_on+0xd/0x10
> [    3.557913]  [<ffffffffa01af33c>] i915_pci_probe+0x3c/0x90 [i915]
> [    3.557915]  [<ffffffff813300ab>] local_pci_probe+0x4b/0x80
> [    3.557918]  [<ffffffff81330311>] pci_device_probe+0x111/0x120
> [    3.557921]  [<ffffffff8141188b>] driver_probe_device+0x8b/0x390
> [    3.557923]  [<ffffffff81411c3b>] __driver_attach+0xab/0xb0
> [    3.557926]  [<ffffffff81411b90>] ? driver_probe_device+0x390/0x390
> [    3.557928]  [<ffffffff8140f80d>] bus_for_each_dev+0x5d/0xa0
> [    3.557930]  [<ffffffff814111ee>] driver_attach+0x1e/0x20
> [    3.557933]  [<ffffffff81410d81>] bus_add_driver+0x121/0x2b0
> [    3.557935]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
> [    3.557937]  [<ffffffff81412327>] driver_register+0x77/0x170
> [    3.557939]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
> [    3.557941]  [<ffffffff8132f0a4>] __pci_register_driver+0x64/0x70
> [    3.557946]  [<ffffffffa0028e7a>] drm_pci_init+0x11a/0x130 [drm]
> [    3.557948]  [<ffffffffa0246000>] ? 0xffffffffa0245fff
> [    3.557956]  [<ffffffffa0246066>] i915_init+0x66/0x68 [i915]
> [    3.557959]  [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
> [    3.557962]  [<ffffffff810d10ce>] load_module+0x1c3e/0x27e0
> [    3.557964]  [<ffffffff81324010>] ? ddebug_proc_open+0xd0/0xd0
> [    3.557967]  [<ffffffff8131261e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [    3.557969]  [<ffffffff810d1d47>] sys_init_module+0xd7/0x120
> [    3.557972]  [<ffffffff8168e3d9>] system_call_fastpath+0x16/0x1b
> [    3.557973] ---[ end trace 6cad52bf765be3e1 ]---



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: backtrace with 3.9.0-rc4 on MBP retina

[Dave Airlie]

On Mon, Mar 25, 2013 at 8:02 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie <airlied@gmail.com> wrote:
>> Just stuck 3.9.0-rc4 on my MBP today, got this throwing up.
>
> Is the bad stuff just the WARN (bad locking in our init code,
> surprise!) or did i915.ko kill your eDP panel? Or is the
> non-responsive panel just the usual apple gpu switching fail we have?

its just normal apple gpu mux switched to nvidia gpu fail.

Dave.

[PATCH] drm/i915: duct-tape locking when eDP init fails

[Daniel Vetter]

Thanks to apple gpu mux fail we detect an eDP output, but can't read
anything over dp aux. In the resulting failure path we then hit a
paranoid WARN about potential locking.

Since the WARN is pretty useful for normal operation just paper over
it in the failure case by grabbing the demanded (but for init/teardown
not really required) lock.

I've checked our driver unload code and we already don't hold the kms
lock when calling drm_mode_config_cleanup. So this won't lead to a new
deadlock when reloading i915.ko.

Reported-by: Dave Airlie <airlied@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/intel_dp.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d7d4afe..8e66592 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2564,7 +2564,9 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
 	drm_encoder_cleanup(encoder);
 	if (is_edp(intel_dp)) {
 		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+		mutex_lock(&dev->mode_config.mutex);
 		ironlake_panel_vdd_off_sync(intel_dp);
+		mutex_unlock(&dev->mode_config.mutex);
 	}
 	kfree(intel_dig_port);
 }
-- 
1.7.10.4

[PATCH] drm/i915: duct-tape locking when eDP init fails

[Daniel Vetter]

Thanks to apple gpu mux fail we detect an eDP output, but can't read
anything over dp aux. In the resulting failure path we then hit a
paranoid WARN about potential locking.

Since the WARN is pretty useful for normal operation just paper over
it in the failure case by grabbing the demanded (but for init/teardown
not really required) lock.

I've checked our driver unload code and we already don't hold the kms
lock when calling drm_mode_config_cleanup. So this won't lead to a new
deadlock when reloading i915.ko.

v2: Make it compile.

Reported-by: Dave Airlie <airlied@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/intel_dp.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d7d4afe..8fc93f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2559,12 +2559,15 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
 {
 	struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
 	struct intel_dp *intel_dp = &intel_dig_port->dp;
+	struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
 	i2c_del_adapter(&intel_dp->adapter);
 	drm_encoder_cleanup(encoder);
 	if (is_edp(intel_dp)) {
 		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+		mutex_lock(&dev->mode_config.mutex);
 		ironlake_panel_vdd_off_sync(intel_dp);
+		mutex_unlock(&dev->mode_config.mutex);
 	}
 	kfree(intel_dig_port);
 }
-- 
1.7.10.4

Re: [PATCH] drm/i915: duct-tape locking when eDP init fails

[Daniel Vetter]

On Mon, Mar 25, 2013 at 5:56 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Thanks to apple gpu mux fail we detect an eDP output, but can't read
> anything over dp aux. In the resulting failure path we then hit a
> paranoid WARN about potential locking.
>
> Since the WARN is pretty useful for normal operation just paper over
> it in the failure case by grabbing the demanded (but for init/teardown
> not really required) lock.
>
> I've checked our driver unload code and we already don't hold the kms
> lock when calling drm_mode_config_cleanup. So this won't lead to a new
> deadlock when reloading i915.ko.
>
> v2: Make it compile.
>
> Reported-by: Dave Airlie <airlied@gmail.com>
> Cc: Dave Airlie <airlied@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Now also quickly tested on my edp to check whether I really didn't
break module reload. Seems to still work.

Dave, since I don't have anything else pending for fixes, can you
please merge this for drm-fixes directly if it works for you?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm/i915: duct-tape locking when eDP init fails

[Jani Nikula]

On Mon, 25 Mar 2013, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Thanks to apple gpu mux fail we detect an eDP output, but can't read
> anything over dp aux. In the resulting failure path we then hit a
> paranoid WARN about potential locking.
>
> Since the WARN is pretty useful for normal operation just paper over
> it in the failure case by grabbing the demanded (but for init/teardown
> not really required) lock.
>
> I've checked our driver unload code and we already don't hold the kms
> lock when calling drm_mode_config_cleanup. So this won't lead to a new
> deadlock when reloading i915.ko.

Also, drm_encoder_cleanup() grabs mode_config mutex internally, so we
would have deadlocks already if intel_dp_encoder_destroy() were called
while holding the lock.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


An observation outside of this patch, I find it a bit ugly that it
depends on the ironlake_edp_panel_vdd_off() sync parameter whether the
caller needs to hold the mode_config mutex or not. Perhaps separate
functions for sync/async would be neater, but don't hold your breath
waiting for patches from me to that effect. ;)

>
> v2: Make it compile.
>
> Reported-by: Dave Airlie <airlied@gmail.com>
> Cc: Dave Airlie <airlied@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/intel_dp.c |    3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d7d4afe..8fc93f9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2559,12 +2559,15 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
>  {
>  	struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>  	struct intel_dp *intel_dp = &intel_dig_port->dp;
> +	struct drm_device *dev = intel_dp_to_dev(intel_dp);
>  
>  	i2c_del_adapter(&intel_dp->adapter);
>  	drm_encoder_cleanup(encoder);
>  	if (is_edp(intel_dp)) {
>  		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
> +		mutex_lock(&dev->mode_config.mutex);
>  		ironlake_panel_vdd_off_sync(intel_dp);
> +		mutex_unlock(&dev->mode_config.mutex);
>  	}
>  	kfree(intel_dig_port);
>  }
> -- 
> 1.7.10.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: duct-tape locking when eDP init fails

[Daniel Vetter]

On Tue, Mar 26, 2013 at 09:45:47AM +0200, Jani Nikula wrote:
> On Mon, 25 Mar 2013, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Thanks to apple gpu mux fail we detect an eDP output, but can't read
> > anything over dp aux. In the resulting failure path we then hit a
> > paranoid WARN about potential locking.
> >
> > Since the WARN is pretty useful for normal operation just paper over
> > it in the failure case by grabbing the demanded (but for init/teardown
> > not really required) lock.
> >
> > I've checked our driver unload code and we already don't hold the kms
> > lock when calling drm_mode_config_cleanup. So this won't lead to a new
> > deadlock when reloading i915.ko.
> 
> Also, drm_encoder_cleanup() grabs mode_config mutex internally, so we
> would have deadlocks already if intel_dp_encoder_destroy() were called
> while holding the lock.
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Thanks for the review, smashed on top of -fixes.

> An observation outside of this patch, I find it a bit ugly that it
> depends on the ironlake_edp_panel_vdd_off() sync parameter whether the
> caller needs to hold the mode_config mutex or not. Perhaps separate
> functions for sync/async would be neater, but don't hold your breath
> waiting for patches from me to that effect. ;)

Yeah, it's no the greatest interface, ever ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch