[prev in list] [next in list] [prev in thread] [next in thread]
List: dri-devel
Subject: MST locking problem?
From: Adam Richter <adam_richter2004 () yahoo ! com>
Date: 2015-02-28 2:35:36
Message-ID: 510268688.29929.1425090936861.JavaMail.yahoo () mail ! yahoo ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
CONFIG_DEBUG_ATOMIC_SLEEP complains about the following locking problem in =
linux-4.0-rc1/drivers/gpu/drm/drm_dp_mst_topology.c:
drm_dp_mst_wait_tx_reply --> wait_event_timeout --> check_txmsg_state=C2=A0=
--> mutex_lock
I believe that any function called in the "condition" argument in the wait_=
event_timeout macro (in this case, check_txmsg_state) is not allowed to blo=
ck when the condition is being evalutated to determine whether to unblock t=
he process.
I think the problem is real.=C2=A0 On two different computers and three dif=
ferent DisplayPort MST hubs, plugging in a DisplayPort hub or having it plu=
gged in from boot time results in a hang within a few minutes of doing a fe=
w "xrandr" commands.
At first glance, it looked to me like it might be safe to remove the mutex_=
{,un}lock calls from check_txmsg_state (which is not called from anywhere e=
lse), and change the integer field txmsg->state to be an atomic_t (although=
I'd be surprised if there is existing hardware that supports an MST hub wh=
ere the accessing that field is not atomic.=C2=A0 However, altough removing=
those mutex calls eliminated the complaint from CONFIG_DEBUG_ATOMIC_SLEEP,=
it also resulted in the system eventually getting a kernel memory fault in=
the DisplayPort MST code.=C2=A0 So, I need to look at this more carefully.
I'm not stuck in my debugging of this issue at the moment, but wanted to pa=
ss along this information to the mailing list now, in case anyone wanted to=
express some preference regarding the eventual fix or is already dealing w=
ith the same problem.
I hope this information is useful.=C2=A0 Thanks in advance for any input.
Adam Richter
[Attachment #5 (text/html)]
<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, \
Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div \
id="yui_3_16_0_1_1425087399541_2989" dir="ltr">CONFIG_DEBUG_ATOMIC_SLEEP complains \
about the following locking problem in \
linux-4.0-rc1/drivers/gpu/drm/drm_dp_mst_topology.c:</div><div \
id="yui_3_16_0_1_1425087399541_3023" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3022" dir="ltr">drm_dp_mst_wait_tx_reply --> \
wait_event_timeout --> check_txmsg_state --> mutex_lock</div><div \
id="yui_3_16_0_1_1425087399541_3001" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3056" dir="ltr">I believe that any function called in \
the "condition" argument in the wait_event_timeout macro (in this case, \
check_txmsg_state) is not allowed to block when the condition is being evalutated to \
determine whether to unblock the process.<br></div><div \
id="yui_3_16_0_1_1425087399541_3275" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3274" dir="ltr">I think the problem is real. On \
two different computers and three different DisplayPort MST hubs, plugging in a \
DisplayPort hub or having it plugged in from boot time results in a hang within a few \
minutes of doing a few "xrandr" commands.</div><div \
id="yui_3_16_0_1_1425087399541_3109" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3393" dir="ltr">At first glance, it looked to me like \
it might be safe to remove the mutex_{,un}lock calls from check_txmsg_state (which is \
not called from anywhere else), and change the integer field txmsg->state to be an \
atomic_t (although I'd be surprised if there is existing hardware that supports an \
MST hub where the accessing that field is not atomic. However, altough removing \
those mutex calls eliminated the complaint from CONFIG_DEBUG_ATOMIC_SLEEP, it also \
resulted in the system eventually getting a kernel memory fault in the DisplayPort \
MST code. So, I need to look at this more carefully.</div><div \
id="yui_3_16_0_1_1425087399541_3527" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3460" dir="ltr">I'm not stuck in my debugging of this \
issue at the moment, but wanted to pass along this information to the mailing list \
now, in case anyone wanted to express some preference regarding the eventual fix or \
is already dealing with the same problem.</div><div \
id="yui_3_16_0_1_1425087399541_3505" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3506" dir="ltr">I hope this information is \
useful. Thanks in advance for any input.<br></div><div \
id="yui_3_16_0_1_1425087399541_3446" dir="ltr"><br></div><div \
id="yui_3_16_0_1_1425087399541_3057" dir="ltr"> Adam Richter</div><div \
id="yui_3_16_0_1_1425087399541_3253" dir="ltr"><br></div></div></body></html>
[Attachment #6 (text/plain)]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic