From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Richter Subject: MST locking problem? Date: Sat, 28 Feb 2015 02:35:36 +0000 (UTC) Message-ID: <510268688.29929.1425090936861.JavaMail.yahoo@mail.yahoo.com> Reply-To: Adam Richter Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0332122006==" Return-path: Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by gabe.freedesktop.org (Postfix) with ESMTP id 1A8256E338 for ; Fri, 27 Feb 2015 18:35:39 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0332122006== Content-Type: multipart/alternative; boundary="----=_Part_29928_767387392.1425090936858" ------=_Part_29928_767387392.1425090936858 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 ------=_Part_29928_767387392.1425090936858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

CONFI= G_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 --> mutex_lock

I believe that any function called in the "condi= tion" argument in the wait_event_timeout macro (in this case, check_txmsg_s= tate) is not allowed to block when the condition is being evalutated to det= ermine whether to unblock the process.

I think the problem is real. On two different com= puters 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 m= inutes of doing a few "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 call= ed 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 s= upports an MST hub where the accessing that field is not atomic. Howe= ver, altough removing those mutex calls eliminated the complaint from CONFI= G_DEBUG_ATOMIC_SLEEP, it also resulted in the system eventually getting a k= ernel memory fault in the DisplayPort MST code. 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. Thanks in advance for any input.

<= div id=3D"yui_3_16_0_1_1425087399541_3057" dir=3D"ltr"> Adam Richter

<= div id=3D"yui_3_16_0_1_1425087399541_3253" dir=3D"ltr">
------=_Part_29928_767387392.1425090936858-- --===============0332122006== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0332122006==--