<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c3">Comment # 3</a> on <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">bug 92005</a> from <a class="email" href="mailto:adam_richter2004@yahoo.com" title="Adam J. Richter <adam_richter2004@yahoo.com>"> Adam J. Richter</a> <pre>Created <a href="attachment.cgi?id=118306" name="attach_118306" title="dmesg log of some apparent delays, but not the deadlock, from kernel booted with "drm.debug=6 loglevel=7"">attachment 118306</a> <a href="attachment.cgi?id=118306&action=edit" title="dmesg log of some apparent delays, but not the deadlock, from kernel booted with "drm.debug=6 loglevel=7"">[details]</a> dmesg log of some apparent delays, but not the deadlock, from kernel booted with "drm.debug=6 loglevel=7" I have been asked to try attach a dmesg log of this problem with the kernel booted with a "drm.debug=6" kernel command line argument. The exact problem that produced this interesting stack trace is difficult to reproduce, but long waits when doing "xrandr --current" and other misbehavior happen frequently and I suspect may be related to this mutex contention. In this case, "xarndr" takes a long time to run, examination of /proc/<x-server-pid>/stack shows that the X server seems to be usually requesting new EDID data via DisplayPort MST, and, in this particular instance, the end result was the one of the two screens connected to the DisplayPort MST hub is not showing any video (and "xrandr" does not seem to see its EDID information either). I apologize if this attachment is essentially spam for a bug that might be completely separate from the issue for which I opened this ticket. I am posting it just on the chance that it might be relevant (and also because it as close as I think I'll get today to fulfilling the request to get a drm.debug=6 dmesg log of the original problem.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>