From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 92005] Linux 4.2 DisplayPort MST deadlock? Date: Wed, 16 Sep 2015 01:44:21 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1512387512==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 794176E401 for ; Tue, 15 Sep 2015 18:44:21 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1512387512== Content-Type: multipart/alternative; boundary="1442367861.cEab6EF0.28452"; charset="UTF-8" --1442367861.cEab6EF0.28452 Date: Wed, 16 Sep 2015 01:44:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=92005 --- Comment #3 from Adam J. Richter --- Created attachment 118306 --> https://bugs.freedesktop.org/attachment.cgi?id=118306&action=edit 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//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. -- You are receiving this mail because: You are the assignee for the bug. --1442367861.cEab6EF0.28452 Date: Wed, 16 Sep 2015 01:44:21 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 3 on bug 92005 from 
Created attachment 118306 [details]
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.

You are receiving this mail because:
  • You are the assignee for the bug.
--1442367861.cEab6EF0.28452-- --===============1512387512== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1512387512==--