* [PATCH] drm: Don't race connector registration
@ 2017-01-12 16:15 Daniel Vetter
2017-01-12 16:17 ` Daniel Vetter
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Daniel Vetter @ 2017-01-12 16:15 UTC (permalink / raw)
To: Intel Graphics Development
Cc: Daniel Vetter, Daniel Vetter, DRI Development, Dave Hansen
I was under the misconception that the sysfs dev stuff can be fully
set up, and then registered all in one step with device_add. That's
true for properties and property groups, but not for parents and child
devices. Those must be fully registered before you can register a
child.
Add a bit of tracking to make sure that asynchronous mst connector
hotplugging gets this right. For consistency we rely upon the implicit
barriers of the connector->mutex, which is taken anyway, to ensure
that at least either the connector or device registration call will
work out.
Mildly tested since I can't reliably reproduce this on my mst box
here.
Reported-by: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_connector.c | 3 +++
drivers/gpu/drm/drm_drv.c | 4 ++++
include/drm/drmP.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c75ab242f907..5999cb83d05b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -378,6 +378,9 @@ int drm_connector_register(struct drm_connector *connector)
{
int ret = 0;
+ if (!connector->dev->registered)
+ return 0;
+
mutex_lock(&connector->mutex);
if (connector->registered)
goto unlock;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7e24103c47f1..cad6df626678 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -749,6 +749,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
if (ret)
goto err_minors;
+ dev->registered = true;
+
if (dev->driver->load) {
ret = dev->driver->load(dev, flags);
if (ret)
@@ -796,6 +798,8 @@ void drm_dev_unregister(struct drm_device *dev)
drm_lastclose(dev);
+ dev->registered = false;
+
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c537c278a4be..ec105c339347 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -518,6 +518,7 @@ struct drm_device {
struct drm_minor *control; /**< Control node */
struct drm_minor *primary; /**< Primary node */
struct drm_minor *render; /**< Render node */
+ bool registered;
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
--
2.5.5
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-12 16:15 [PATCH] drm: Don't race connector registration Daniel Vetter
@ 2017-01-12 16:17 ` Daniel Vetter
2017-01-25 6:21 ` Daniel Vetter
2017-01-12 16:54 ` Chris Wilson
2017-01-12 17:54 ` ✓ Fi.CI.BAT: success for " Patchwork
2 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-01-12 16:17 UTC (permalink / raw)
To: Intel Graphics Development
Cc: Daniel Vetter, Daniel Vetter, DRI Development, Dave Hansen
On Thu, Jan 12, 2017 at 05:15:56PM +0100, Daniel Vetter wrote:
> I was under the misconception that the sysfs dev stuff can be fully
> set up, and then registered all in one step with device_add. That's
> true for properties and property groups, but not for parents and child
> devices. Those must be fully registered before you can register a
> child.
>
> Add a bit of tracking to make sure that asynchronous mst connector
> hotplugging gets this right. For consistency we rely upon the implicit
> barriers of the connector->mutex, which is taken anyway, to ensure
> that at least either the connector or device registration call will
> work out.
>
> Mildly tested since I can't reliably reproduce this on my mst box
> here.
>
> Reported-by: Dave Hansen <dave.hansen@intel.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/drm_connector.c | 3 +++
> drivers/gpu/drm/drm_drv.c | 4 ++++
> include/drm/drmP.h | 1 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index c75ab242f907..5999cb83d05b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -378,6 +378,9 @@ int drm_connector_register(struct drm_connector *connector)
> {
> int ret = 0;
>
> + if (!connector->dev->registered)
> + return 0;
> +
> mutex_lock(&connector->mutex);
> if (connector->registered)
> goto unlock;
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7e24103c47f1..cad6df626678 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -749,6 +749,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
> if (ret)
> goto err_minors;
>
> + dev->registered = true;
> +
> if (dev->driver->load) {
> ret = dev->driver->load(dev, flags);
> if (ret)
> @@ -796,6 +798,8 @@ void drm_dev_unregister(struct drm_device *dev)
>
> drm_lastclose(dev);
>
> + dev->registered = false;
> +
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_modeset_unregister_all(dev);
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index c537c278a4be..ec105c339347 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -518,6 +518,7 @@ struct drm_device {
> struct drm_minor *control; /**< Control node */
> struct drm_minor *primary; /**< Primary node */
> struct drm_minor *render; /**< Render node */
> + bool registered;
>
> /* currently active master for this device. Protected by master_mutex */
> struct drm_master *master;
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-12 16:15 [PATCH] drm: Don't race connector registration Daniel Vetter
2017-01-12 16:17 ` Daniel Vetter
@ 2017-01-12 16:54 ` Chris Wilson
2017-01-12 17:54 ` ✓ Fi.CI.BAT: success for " Patchwork
2 siblings, 0 replies; 14+ messages in thread
From: Chris Wilson @ 2017-01-12 16:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Hansen, Intel Graphics Development, DRI Development, Daniel Vetter
On Thu, Jan 12, 2017 at 05:15:56PM +0100, Daniel Vetter wrote:
> I was under the misconception that the sysfs dev stuff can be fully
> set up, and then registered all in one step with device_add. That's
> true for properties and property groups, but not for parents and child
> devices. Those must be fully registered before you can register a
> child.
>
> Add a bit of tracking to make sure that asynchronous mst connector
> hotplugging gets this right. For consistency we rely upon the implicit
> barriers of the connector->mutex, which is taken anyway, to ensure
> that at least either the connector or device registration call will
> work out.
>
> Mildly tested since I can't reliably reproduce this on my mst box
> here.
Hmm, right it should prevent the oops on load. I think we need to
control the async dp-mst better and stop it running until we have the
device registered, and so if we use in the interim, plonk a WARN_ON on
top for -next and try and fix it for realz. (Probably a
drm_dp_mst_mgr_register() hook?)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* ✓ Fi.CI.BAT: success for drm: Don't race connector registration
2017-01-12 16:15 [PATCH] drm: Don't race connector registration Daniel Vetter
2017-01-12 16:17 ` Daniel Vetter
2017-01-12 16:54 ` Chris Wilson
@ 2017-01-12 17:54 ` Patchwork
2 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2017-01-12 17:54 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Series Details ==
Series: drm: Don't race connector registration
URL : https://patchwork.freedesktop.org/series/17910/
State : success
== Summary ==
Series 17910v1 drm: Don't race connector registration
https://patchwork.freedesktop.org/api/1.0/series/17910/revisions/1/mbox/
fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14
fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39
fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22
fi-bxt-t5700 total:82 pass:69 dwarn:0 dfail:0 fail:0 skip:12
fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27
fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31
fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19
fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19
fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-ivb-3770 total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-kbl-7500u total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13
fi-skl-6700hq total:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20
fi-skl-6700k total:246 pass:222 dwarn:3 dfail:0 fail:0 skip:21
fi-skl-6770hq total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13
fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31
fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32
8f7458237916d6c1e5e1e9ebfc5923a6d1658385 drm-tip: 2017y-01m-12d-15h-39m-40s UTC integration manifest
f9e487c drm: Don't race connector registration
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3503/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-12 16:17 ` Daniel Vetter
@ 2017-01-25 6:21 ` Daniel Vetter
2017-01-25 15:20 ` Dave Hansen
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-01-25 6:21 UTC (permalink / raw)
To: Intel Graphics Development
Cc: Daniel Vetter, Daniel Vetter, DRI Development, Dave Hansen
Hi Dave,
Still waiting for your testing results on this one here ...
-Daniel
On Thu, Jan 12, 2017 at 05:17:21PM +0100, Daniel Vetter wrote:
> On Thu, Jan 12, 2017 at 05:15:56PM +0100, Daniel Vetter wrote:
> > I was under the misconception that the sysfs dev stuff can be fully
> > set up, and then registered all in one step with device_add. That's
> > true for properties and property groups, but not for parents and child
> > devices. Those must be fully registered before you can register a
> > child.
> >
> > Add a bit of tracking to make sure that asynchronous mst connector
> > hotplugging gets this right. For consistency we rely upon the implicit
> > barriers of the connector->mutex, which is taken anyway, to ensure
> > that at least either the connector or device registration call will
> > work out.
> >
> > Mildly tested since I can't reliably reproduce this on my mst box
> > here.
> >
> > Reported-by: Dave Hansen <dave.hansen@intel.com>
> > Cc: Dave Hansen <dave.hansen@intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Cc: stable@vger.kernel.org
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 3 +++
> > drivers/gpu/drm/drm_drv.c | 4 ++++
> > include/drm/drmP.h | 1 +
> > 3 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index c75ab242f907..5999cb83d05b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -378,6 +378,9 @@ int drm_connector_register(struct drm_connector *connector)
> > {
> > int ret = 0;
> >
> > + if (!connector->dev->registered)
> > + return 0;
> > +
> > mutex_lock(&connector->mutex);
> > if (connector->registered)
> > goto unlock;
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 7e24103c47f1..cad6df626678 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -749,6 +749,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
> > if (ret)
> > goto err_minors;
> >
> > + dev->registered = true;
> > +
> > if (dev->driver->load) {
> > ret = dev->driver->load(dev, flags);
> > if (ret)
> > @@ -796,6 +798,8 @@ void drm_dev_unregister(struct drm_device *dev)
> >
> > drm_lastclose(dev);
> >
> > + dev->registered = false;
> > +
> > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > drm_modeset_unregister_all(dev);
> >
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index c537c278a4be..ec105c339347 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -518,6 +518,7 @@ struct drm_device {
> > struct drm_minor *control; /**< Control node */
> > struct drm_minor *primary; /**< Primary node */
> > struct drm_minor *render; /**< Render node */
> > + bool registered;
> >
> > /* currently active master for this device. Protected by master_mutex */
> > struct drm_master *master;
> > --
> > 2.5.5
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-25 6:21 ` Daniel Vetter
@ 2017-01-25 15:20 ` Dave Hansen
2017-01-25 15:38 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Dave Hansen @ 2017-01-25 15:20 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics Development
Cc: Daniel Vetter, Daniel Vetter, DRI Development
On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> Hi Dave,
>
> Still waiting for your testing results on this one here ...
It's definitely stable with that patch applied. No more crashes.
But, it's also definitely having difficulty re-probing to find the
monitor that's attached to the dock in some cases. Whatever is going on
isn't fixed by poking it with xrandr.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-25 15:20 ` Dave Hansen
@ 2017-01-25 15:38 ` Daniel Vetter
2017-01-26 20:34 ` Dave Hansen
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-01-25 15:38 UTC (permalink / raw)
To: Dave Hansen
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> > Hi Dave,
> >
> > Still waiting for your testing results on this one here ...
>
> It's definitely stable with that patch applied. No more crashes.
>
> But, it's also definitely having difficulty re-probing to find the
> monitor that's attached to the dock in some cases. Whatever is going on
> isn't fixed by poking it with xrandr.
Is this new? When exactly does this happen? Does the mst sink connector no
longer show up, or is the connected/disconnected status all wrong?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-25 15:38 ` Daniel Vetter
@ 2017-01-26 20:34 ` Dave Hansen
2017-01-30 9:12 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Dave Hansen @ 2017-01-26 20:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
DRI Development
On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
>> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Still waiting for your testing results on this one here ...
>>
>> It's definitely stable with that patch applied. No more crashes.
>>
>> But, it's also definitely having difficulty re-probing to find the
>> monitor that's attached to the dock in some cases. Whatever is going on
>> isn't fixed by poking it with xrandr.
>
> Is this new? When exactly does this happen? Does the mst sink connector no
> longer show up, or is the connected/disconnected status all wrong?
It's hard to say whether it's new or not. I *think* it worked better
before, but it also crashed pretty often, so it's hard to say.
And, yeah, I think it just gets the connected status wrong. The
connector is still there.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-26 20:34 ` Dave Hansen
@ 2017-01-30 9:12 ` Daniel Vetter
2017-01-30 16:43 ` Dave Hansen
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-01-30 9:12 UTC (permalink / raw)
To: Dave Hansen
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
> On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> > On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
> >> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> >>> Hi Dave,
> >>>
> >>> Still waiting for your testing results on this one here ...
> >>
> >> It's definitely stable with that patch applied. No more crashes.
> >>
> >> But, it's also definitely having difficulty re-probing to find the
> >> monitor that's attached to the dock in some cases. Whatever is going on
> >> isn't fixed by poking it with xrandr.
> >
> > Is this new? When exactly does this happen? Does the mst sink connector no
> > longer show up, or is the connected/disconnected status all wrong?
>
> It's hard to say whether it's new or not. I *think* it worked better
> before, but it also crashed pretty often, so it's hard to say.
Ok, I guess that's good enough to push at least the crash fix forward.
> And, yeah, I think it just gets the connected status wrong. The
> connector is still there.
Hm, I thought I replied here but I didn't:
- Is this just after boot (and then the connector is stuck forever), or
starts to happen after suspend/resume, or some other system change like
that? Or do they just crop up eventually?
- Does this only happen once the connector is destroyed? Please trace
intel_dp_destroy_mst_connector with something like:
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 38e3ca2f6f18..24ac2d1ce3ad 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -502,6 +502,8 @@ static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
drm_connector_unregister(connector);
+ printk("mst connector getting destroyed: %s\n", connector->name);
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
- If it's not that then something in intel_dp_mst_detect (well, it's
helper implementation drm_dp_mst_detect_port) is probably going wrong.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-30 9:12 ` Daniel Vetter
@ 2017-01-30 16:43 ` Dave Hansen
2017-01-31 7:44 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Dave Hansen @ 2017-01-30 16:43 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
DRI Development
On 01/30/2017 01:12 AM, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
...
>> And, yeah, I think it just gets the connected status wrong. The
>> connector is still there.
>
> Hm, I thought I replied here but I didn't:
> - Is this just after boot (and then the connector is stuck forever), or
> starts to happen after suspend/resume, or some other system change like
> that? Or do they just crop up eventually?
The most consistent thing I do to screw it up is switch systems on my
DVI KVM switch. When I switch back to the system in question, it
doesn't seem to notice the condition. The connectors eventually show up
with random combinations of switching to the console (ctrl-alt-f1) and
back, running xrandr, or running gnome-control-panel and opening the
Displays applet.
I haven't been able to discern any pattern to it. Sometimes just
running xrandr fixes it. Sometimes just opening the control panel.
Others, I have to do it several times.
I don't think it shows up if I just leave it for a while.
> - Does this only happen once the connector is destroyed? Please trace
> intel_dp_destroy_mst_connector with something like:
I'll see if I can gather that.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-01-30 16:43 ` Dave Hansen
@ 2017-01-31 7:44 ` Daniel Vetter
[not found] ` <e5d9f6e2-3fcc-59e1-6e12-b8062b5122f5@intel.com>
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-01-31 7:44 UTC (permalink / raw)
To: Dave Hansen
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Jan 30, 2017 at 08:43:17AM -0800, Dave Hansen wrote:
> On 01/30/2017 01:12 AM, Daniel Vetter wrote:
> > On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
> ...
> >> And, yeah, I think it just gets the connected status wrong. The
> >> connector is still there.
> >
> > Hm, I thought I replied here but I didn't:
> > - Is this just after boot (and then the connector is stuck forever), or
> > starts to happen after suspend/resume, or some other system change like
> > that? Or do they just crop up eventually?
>
> The most consistent thing I do to screw it up is switch systems on my
> DVI KVM switch. When I switch back to the system in question, it
> doesn't seem to notice the condition. The connectors eventually show up
> with random combinations of switching to the console (ctrl-alt-f1) and
> back, running xrandr, or running gnome-control-panel and opening the
> Displays applet.
Hm, so is this a dp mst kvm switch (i.e. do the connectors get
hot-added/removed when you plug/unplug that thing)? Or just some other
non-mst switch? I was working under the assumption that this is mst still,
but I've never seen an mst kvm switch.
> I haven't been able to discern any pattern to it. Sometimes just
> running xrandr fixes it. Sometimes just opening the control panel.
> Others, I have to do it several times.
>
> I don't think it shows up if I just leave it for a while.
>
> > - Does this only happen once the connector is destroyed? Please trace
> > intel_dp_destroy_mst_connector with something like:
>
> I'll see if I can gather that.
If it's not mst, then don't bother with this for obvious reasons :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
[not found] ` <e5d9f6e2-3fcc-59e1-6e12-b8062b5122f5@intel.com>
@ 2017-02-01 0:27 ` Dave Hansen
2017-02-01 8:52 ` Daniel Vetter
0 siblings, 1 reply; 14+ messages in thread
From: Dave Hansen @ 2017-02-01 0:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
DRI Development
I added some printk()s all over and gathered a bit more information
about what's going on. It looks like the display doesn't work until the
drm connector code cleans up the *old* connector. For some reason, it
isn't motivated to do that until I go to the console and back.
In this case, the display was connected to DP-4.
intel_dp_destroy_mst_connector() got called on it when I switched away,
but drm_connector_cleanup() did not get called. Upon switching back
DP-3/5/6 get created. One of these *eventually* ends up being
"enabled", but is not now. When I switch over to the console,
drm_connector_cleanup() finally gets called on the old connector: DP-4
and I can switch back to X and I see one of DP-3/5/6 enabled and working.
Here are some snippets of dmesg interspersed with what I was doing:
Push DVI switch button to switch to other system:
> [ 6824.562838] drm_dp_destroy_port() kfree(ffff8801ade46800)
> [ 6824.563164] drm_dp_destroy_connector_work() port: ffff8801ade42000 connector: ffff8801ade46000
> [ 6824.563178] intel_dp_destroy_mst_connector() connector: ffff8801ade46000 name: DP-3 &name: ffff8801ade46048 intel_connector: ffff8801ade46000
> [ 6824.563186] drm_sysfs_connector_remove() connector: ffff8801ade46000 kdev: ffff8801a941b400
> [ 6824.571556] drm_connector_cleanup(ffff8801ade46000)::329 connector->registered: 0 cpu: 3
> [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' &name: ffff8801ade46048
> [ 6824.571581] drm_dp_free_mst_port() kfree port: ffff8801ade42000
> [ 6824.571587] drm_dp_destroy_connector_work() port: ffff8801ade42800 connector: ffff8801ade47000
> [ 6824.571594] intel_dp_destroy_mst_connector() connector: ffff8801ade47000 name: DP-4 &name: ffff8801ade47048 intel_connector: ffff8801ade47000
> [ 6824.571601] drm_sysfs_connector_remove() connector: ffff8801ade47000 kdev: ffff8801a941a000
> [ 6824.571915] drm_dp_free_mst_port() kfree port: ffff8801ade42800
> [ 6824.571925] drm_dp_destroy_connector_work() port: ffff8801ade40800 connector: ffff8801ade43000
> [ 6824.571934] intel_dp_destroy_mst_connector() connector: ffff8801ade43000 name: DP-6 &name: ffff8801ade43048 intel_connector: ffff8801ade43000
> [ 6824.571943] drm_sysfs_connector_remove() connector: ffff8801ade43000 kdev: ffff8801a9419800
> [ 6824.572091] drm_connector_cleanup(ffff8801ade43000)::329 connector->registered: 0 cpu: 3
> [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' &name: ffff8801ade43048
> [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: ffff88030ac22600
> [ 6824.572117] drm_dp_free_mst_port() kfree port: ffff8801ade40800
Push button to switch back:
> [ 6837.349693] drm_connector_init() connector->name: 'DP-3' &name: ffff88040231d848
> [ 6837.349894] drm_sysfs_connector_add() connector: ffff88040231d800 kdev: ffff8801ae99f400
> [ 6837.352786] drm_connector_init() connector->name: 'DP-5' &name: ffff880402318048
> [ 6837.352951] drm_sysfs_connector_add() connector: ffff880402318000 kdev: ffff8801ae99c000
> [ 6837.353036] drm_connector_init() connector->name: 'DP-6' &name: ffff88040d37f048
> [ 6837.353154] drm_sysfs_connector_add() connector: ffff88040d37f000 kdev: ffff8801ae99ec00
I can type into the X session, but both screens are blank. When I press
Ctrl-Alt-F2, I get:
> [ 6850.494310] drm_connector_cleanup(ffff8801ade47000)::329 connector->registered: 0 cpu: 1
> [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' &name: ffff8801ade47048
Now I can switch back to X and everything is OK again.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-02-01 0:27 ` Dave Hansen
@ 2017-02-01 8:52 ` Daniel Vetter
2017-02-01 20:55 ` Dave Hansen
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Vetter @ 2017-02-01 8:52 UTC (permalink / raw)
To: Dave Hansen
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
> I added some printk()s all over and gathered a bit more information
> about what's going on. It looks like the display doesn't work until the
> drm connector code cleans up the *old* connector. For some reason, it
> isn't motivated to do that until I go to the console and back.
>
> In this case, the display was connected to DP-4.
> intel_dp_destroy_mst_connector() got called on it when I switched away,
> but drm_connector_cleanup() did not get called. Upon switching back
> DP-3/5/6 get created. One of these *eventually* ends up being
> "enabled", but is not now. When I switch over to the console,
> drm_connector_cleanup() finally gets called on the old connector: DP-4
> and I can switch back to X and I see one of DP-3/5/6 enabled and working.
>
> Here are some snippets of dmesg interspersed with what I was doing:
Ok, so the delayed deleting seems to be involved in the bug (and we only
do that since we recently introduced refcounting for hotplugged
connectors). The question is who's getting confused, either kernel or X.
To figure this out, next time things are out of sync, please compare the
output of
$ xrandr
with what's reported in /sys/class/drm/*/status:
$ grep . /sys/class/drm/card0-DP-*/status
Another question: What desktop are you using, and if you unplug a screen,
does that general reconfigure the desktop size to disable that output? The
zombie connector only sticks around as long as someone is still using it
in the screen configuration. As soon as the reconfiguration has happened,
it should go away. You can test this by manually disabling the output when
it's stuck as on:
$ xrandr --output DP-4 --off
That should result in the delayed cleanup happening when you look at dmesg
afterwards.
Thanks, Daniel
>
> Push DVI switch button to switch to other system:
>
> > [ 6824.562838] drm_dp_destroy_port() kfree(ffff8801ade46800)
> > [ 6824.563164] drm_dp_destroy_connector_work() port: ffff8801ade42000 connector: ffff8801ade46000
> > [ 6824.563178] intel_dp_destroy_mst_connector() connector: ffff8801ade46000 name: DP-3 &name: ffff8801ade46048 intel_connector: ffff8801ade46000
> > [ 6824.563186] drm_sysfs_connector_remove() connector: ffff8801ade46000 kdev: ffff8801a941b400
> > [ 6824.571556] drm_connector_cleanup(ffff8801ade46000)::329 connector->registered: 0 cpu: 3
> > [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' &name: ffff8801ade46048
> > [ 6824.571581] drm_dp_free_mst_port() kfree port: ffff8801ade42000
> > [ 6824.571587] drm_dp_destroy_connector_work() port: ffff8801ade42800 connector: ffff8801ade47000
> > [ 6824.571594] intel_dp_destroy_mst_connector() connector: ffff8801ade47000 name: DP-4 &name: ffff8801ade47048 intel_connector: ffff8801ade47000
> > [ 6824.571601] drm_sysfs_connector_remove() connector: ffff8801ade47000 kdev: ffff8801a941a000
> > [ 6824.571915] drm_dp_free_mst_port() kfree port: ffff8801ade42800
> > [ 6824.571925] drm_dp_destroy_connector_work() port: ffff8801ade40800 connector: ffff8801ade43000
> > [ 6824.571934] intel_dp_destroy_mst_connector() connector: ffff8801ade43000 name: DP-6 &name: ffff8801ade43048 intel_connector: ffff8801ade43000
> > [ 6824.571943] drm_sysfs_connector_remove() connector: ffff8801ade43000 kdev: ffff8801a9419800
> > [ 6824.572091] drm_connector_cleanup(ffff8801ade43000)::329 connector->registered: 0 cpu: 3
> > [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' &name: ffff8801ade43048
> > [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: ffff88030ac22600
> > [ 6824.572117] drm_dp_free_mst_port() kfree port: ffff8801ade40800
>
> Push button to switch back:
>
> > [ 6837.349693] drm_connector_init() connector->name: 'DP-3' &name: ffff88040231d848
> > [ 6837.349894] drm_sysfs_connector_add() connector: ffff88040231d800 kdev: ffff8801ae99f400
> > [ 6837.352786] drm_connector_init() connector->name: 'DP-5' &name: ffff880402318048
> > [ 6837.352951] drm_sysfs_connector_add() connector: ffff880402318000 kdev: ffff8801ae99c000
> > [ 6837.353036] drm_connector_init() connector->name: 'DP-6' &name: ffff88040d37f048
> > [ 6837.353154] drm_sysfs_connector_add() connector: ffff88040d37f000 kdev: ffff8801ae99ec00
>
> I can type into the X session, but both screens are blank. When I press
> Ctrl-Alt-F2, I get:
>
> > [ 6850.494310] drm_connector_cleanup(ffff8801ade47000)::329 connector->registered: 0 cpu: 1
> > [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' &name: ffff8801ade47048
>
> Now I can switch back to X and everything is OK again.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] drm: Don't race connector registration
2017-02-01 8:52 ` Daniel Vetter
@ 2017-02-01 20:55 ` Dave Hansen
0 siblings, 0 replies; 14+ messages in thread
From: Dave Hansen @ 2017-02-01 20:55 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
DRI Development
[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]
On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
>> I added some printk()s all over and gathered a bit more information
>> about what's going on. It looks like the display doesn't work until the
>> drm connector code cleans up the *old* connector. For some reason, it
>> isn't motivated to do that until I go to the console and back.
>>
>> In this case, the display was connected to DP-4.
>> intel_dp_destroy_mst_connector() got called on it when I switched away,
>> but drm_connector_cleanup() did not get called. Upon switching back
>> DP-3/5/6 get created. One of these *eventually* ends up being
>> "enabled", but is not now. When I switch over to the console,
>> drm_connector_cleanup() finally gets called on the old connector: DP-4
>> and I can switch back to X and I see one of DP-3/5/6 enabled and working.
>>
>> Here are some snippets of dmesg interspersed with what I was doing:
>
> Ok, so the delayed deleting seems to be involved in the bug (and we only
> do that since we recently introduced refcounting for hotplugged
> connectors). The question is who's getting confused, either kernel or X.
> To figure this out, next time things are out of sync, please compare the
> output of
>
> $ xrandr
>
> with what's reported in /sys/class/drm/*/status:
>
> $ grep . /sys/class/drm/card0-DP-*/status
OK, I collected that 4 times:
1. When everything is OK
2. When the DVI is unplugged
3. When the DVI is re-plugged (no output)
4. After I press Ctrl-Alt-F2 (back to OK)
The good vs. bad diff looks like this:
--- xdebug.1485980540.start.log 2017-02-01 12:22:20.328242293 -0800
+++ xdebug.1485980621.dvi-replugged.log 2017-02-01 12:23:41.964241982 -0800
@@ -25,15 +25,6 @@
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x
axis y axis) 518mm x 324mm
1920x1200 60.0*+
- 1920x1080 60.0
- 1600x1200 60.0
- 1680x1050 59.9
- 1280x1024 60.0
- 1280x960 60.0
- 1024x768 60.0
- 800x600 60.3
- 640x480 59.9
- 720x400 70.1
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
@@ -41,5 +32,5 @@
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:disconnected
-/sys/class/drm/card0-DP-5/status:connected
+/sys/class/drm/card0-DP-4/status:connected
/sys/class/drm/card0-DP-6/status:disconnected
But it's very interesting that when I unplug the DVI, the xrandr output
does not change. Only the /sys/class/drm/.../status does.
> Another question: What desktop are you using, and if you unplug a screen,
> does that general reconfigure the desktop size to disable that output? The
> zombie connector only sticks around as long as someone is still using it
> in the screen configuration. As soon as the reconfiguration has happened,
> it should go away. You can test this by manually disabling the output when
> it's stuck as on:
>
> $ xrandr --output DP-4 --off
Yep, it does the delayed cleanup. The output still shows up in xrandr
(as an 8x8 display) at this point, but it can at least be turned back on.
xrandr snippet:
Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767
So, if I do a pair of these:
xrandr --output DP-4 --off
xrandr --output DP-4 --auto
it does bring the display back consistently.
[-- Attachment #2: xdebug.1485980540.start.log --]
[-- Type: text/x-log, Size: 1667 bytes --]
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
1920x1080 60.0 + 59.9
1680x1050 60.0 59.9
1600x1024 60.2
1400x1050 60.0
1600x900 60.0
1280x1024 60.0
1440x900 59.9
1280x960 60.0
1368x768 60.0
1360x768 59.8 60.0
1152x864 60.0
1280x720 60.0
1024x768 60.0
1024x576 60.0
960x540 60.0
800x600 60.3 56.2
864x486 60.0
640x480 59.9
720x405 60.0
640x360 60.0
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
1920x1080 60.0
1600x1200 60.0
1680x1050 59.9
1280x1024 60.0
1280x960 60.0
1024x768 60.0
800x600 60.3
640x480 59.9
720x400 70.1
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:disconnected
/sys/class/drm/card0-DP-5/status:connected
/sys/class/drm/card0-DP-6/status:disconnected
[-- Attachment #3: xdebug.1485980606.dvi-unplugged.log --]
[-- Type: text/x-log, Size: 1532 bytes --]
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
1920x1080 60.0 + 59.9
1680x1050 60.0 59.9
1600x1024 60.2
1400x1050 60.0
1600x900 60.0
1280x1024 60.0
1440x900 59.9
1280x960 60.0
1368x768 60.0
1360x768 59.8 60.0
1152x864 60.0
1280x720 60.0
1024x768 60.0
1024x576 60.0
960x540 60.0
800x600 60.3 56.2
864x486 60.0
640x480 59.9
720x405 60.0
640x360 60.0
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
1920x1080 60.0
1600x1200 60.0
1680x1050 59.9
1280x1024 60.0
1280x960 60.0
1024x768 60.0
800x600 60.3
640x480 59.9
720x400 70.1
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
[-- Attachment #4: xdebug.1485980621.dvi-replugged.log --]
[-- Type: text/x-log, Size: 1442 bytes --]
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
1920x1080 60.0 + 59.9
1680x1050 60.0 59.9
1600x1024 60.2
1400x1050 60.0
1600x900 60.0
1280x1024 60.0
1440x900 59.9
1280x960 60.0
1368x768 60.0
1360x768 59.8 60.0
1152x864 60.0
1280x720 60.0
1024x768 60.0
1024x576 60.0
960x540 60.0
800x600 60.3 56.2
864x486 60.0
640x480 59.9
720x405 60.0
640x360 60.0
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:disconnected
/sys/class/drm/card0-DP-4/status:connected
/sys/class/drm/card0-DP-6/status:disconnected
[-- Attachment #5: xdebug.1485980647.f2.log --]
[-- Type: text/x-log, Size: 1667 bytes --]
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
1920x1080 60.0 + 59.9
1680x1050 60.0 59.9
1600x1024 60.2
1400x1050 60.0
1600x900 60.0
1280x1024 60.0
1440x900 59.9
1280x960 60.0
1368x768 60.0
1360x768 59.8 60.0
1152x864 60.0
1280x720 60.0
1024x768 60.0
1024x576 60.0
960x540 60.0
800x600 60.3 56.2
864x486 60.0
640x480 59.9
720x405 60.0
640x360 60.0
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
1920x1080 60.0
1600x1200 60.0
1680x1050 59.9
1280x1024 60.0
1280x960 60.0
1024x768 60.0
800x600 60.3
640x480 59.9
720x400 70.1
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
/sys/class/drm/card0-DP-1/status:disconnected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:disconnected
/sys/class/drm/card0-DP-4/status:connected
/sys/class/drm/card0-DP-6/status:disconnected
[-- Attachment #6: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-02-01 20:55 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-12 16:15 [PATCH] drm: Don't race connector registration Daniel Vetter
2017-01-12 16:17 ` Daniel Vetter
2017-01-25 6:21 ` Daniel Vetter
2017-01-25 15:20 ` Dave Hansen
2017-01-25 15:38 ` Daniel Vetter
2017-01-26 20:34 ` Dave Hansen
2017-01-30 9:12 ` Daniel Vetter
2017-01-30 16:43 ` Dave Hansen
2017-01-31 7:44 ` Daniel Vetter
[not found] ` <e5d9f6e2-3fcc-59e1-6e12-b8062b5122f5@intel.com>
2017-02-01 0:27 ` Dave Hansen
2017-02-01 8:52 ` Daniel Vetter
2017-02-01 20:55 ` Dave Hansen
2017-01-12 16:54 ` Chris Wilson
2017-01-12 17:54 ` ✓ Fi.CI.BAT: success for " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.