<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Linux 4.2 DisplayPort MST deadlock?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92005">92005</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Linux 4.2 DisplayPort MST deadlock?
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>General
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dri-devel@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>adam_richter2004@yahoo.com
</td>
</tr></table>
<p>
<div>
<pre>In Linux-4.2, there appears to be mutex contention and possible occasionally a
deadlock between two kernel functions, drm_mode_getconnector and
drm_fb_helper_hotplug_event over the mutex dev->mode_config.mutex .
Neither of these functions is specific to MultiStreamTransport or even
DisplayPort generally, but I think that the DP-MST code might be unique in
causing the contention and deadlock, either due to unanticipated the unusual
tree structure of DP-MST or because of a bug in the DP-MST code. In
particular, I have at least once observed the following call trace, where I
think drm_mode_getconnector took the mutex, though a long hierarcy of calls,
eventually ended up calling drm_fb_helper_hotplug_event, which tried to take it
again.
I hesitate to open this ticket, because I am not sure that "dev" variable at
the top of this stack trace is the same one as at the bottom, especially
considering that I did not notice the system complaining about attempting to
block on a mutex where mutex->owner == current, even though
CONFIG_DEBUG_MUTEXES was set. The system that I got this trace from was
blocked infinitely as far as I could tell, which is unusual, in that the
problem that I usually observe has to do with "xrandr" taking on the order of a
minute to complete, and often being inaccurate, but usually not hanging
forever.
I suspect that what happened probably involved some intervening hotplug event
or perhaps involving kernel work functions in a way that I am not completely
clear about where mutex->owner could somehow have been set to the "current" of
a kernel work thread instead of the X server.
Anyhow, the part that I think would likely be helpful to anyone working on this
(and basically the reason I am posting now, rather than waiting) is that this
stack trace might indicate some confusion in assemptions about whether
dev->mode_config.mutex is help by the caller of certain functions in the middle
of this stack trace.
[<ffffffffa01837c8>] drm_fb_helper_hotplug_event+0x138/0x150 [drm_kms_helper]
[<ffffffffa02de31e>] intel_fbdev_output_poll_changed+0x1e/0x30 [i915]
[<ffffffffa017755b>] drm_kms_helper_hotplug_event+0x2b/0x40 [drm_kms_helper]
[<ffffffffa02f1c15>] intel_dp_mst_hotplug+0x15/0x20 [i915]
[<ffffffffa017aef4>] drm_dp_destroy_port+0xd4/0xe0 [drm_kms_helper]
[<ffffffffa017af15>] drm_dp_put_port+0x15/0x20 [drm_kms_helper]
[<ffffffffa017b04e>] drm_dp_destroy_mst_branch_device+0x4e/0x100
[drm_kms_helper]
[<ffffffffa017b115>] drm_dp_put_mst_branch_device+0x15/0x20 [drm_kms_helper]
[<ffffffffa017b6fd>] drm_dp_mst_i2c_xfer+0x9d/0x270 [drm_kms_helper]
[<ffffffff814cca91>] __i2c_transfer+0x121/0x430
[<ffffffff814cce19>] i2c_transfer+0x79/0xb0
[<ffffffffa00bb4a9>] drm_do_probe_ddc_edid+0xc9/0x130 [drm]
[<ffffffffa00bb0fa>] drm_do_get_edid+0x17a/0x250 [drm]
[<ffffffffa00bca55>] drm_get_edid+0x45/0x3d0 [drm]
[<ffffffffa017b9ee>] drm_dp_mst_get_edid+0x7e/0xa0 [drm_kms_helper]
[<ffffffffa02f1c99>] intel_dp_mst_get_modes+0x29/0x50 [i915]
[<ffffffffa0177908>]
drm_helper_probe_single_connector_modes_merge_bits+0x108/0x4e0 [drm_kms_helper]
[<ffffffffa0177cf3>] drm_helper_probe_single_connector_modes+0x13/0x20
[drm_kms_helper]
[<ffffffffa00b6ab9>] drm_mode_getconnector+0x389/0x410 [drm]
[<ffffffffa00a8685>] drm_ioctl+0x1a5/0x670 [drm]
[<ffffffffa00c4e53>] drm_compat_ioctl+0x33/0x40 [drm]
[<ffffffffa026bde2>] i915_compat_ioctl+0x32/0x40 [i915]
[<ffffffff812475f9>] compat_SyS_ioctl+0xc9/0x15d0
[<ffffffff8161ed22>] sysenter_dispatch+0xf/0x29
[<ffffffffffffffff>] 0xffffffffffffffff
I expect that I will update or close this ticket as (or if) I learn more.
I hope this information is helpful. Comments, and, of course, fixes, are most
welcome.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>