Comment # 3
on bug 92005
from Adam J. Richter
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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
