[Bug 89366] DisplayPort MST (multi-stream transport) "atomic sleep" Linux kernel bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bug ID 89366
Summary DisplayPort MST (multi-stream transport) "atomic sleep" Linux kernel bug
Product DRI
Version unspecified
Hardware x86 (IA32)
OS Linux (All)
Status NEW
Severity normal
Priority medium
Component General
Assignee dri-devel@lists.freedesktop.org
Reporter adam_richter2004@yahoo.com

[This is a slightly edited version of an email that I attempted to send to the
dri-devel mailing list.]

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  -->
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
block when the condition is being evalutated to determine whether to unblock
the process.

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.

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 sometimes seeming to ignore the MST hub and otherwise eventually
getting a kernel memory fault in the DisplayPort MST code or another
spontaneous reset (possibly deadlock follwed by a watchdog reset).

Advice is welcome, although I am not blocked in my own efforts to analyze this
further.  I plan to post updates when I have more news.


You are receiving this mail because:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux