Created attachment 114057 [details] The log from running "git bisect" between 3.16 and 3.17 I have a DisplayPort MST monitor that I have attached to my Mac Book Pro 2014 via a mini DisplayPort to DisplayPort cable. Since 3.16 my monitor doesn't come back from sleep mode (this can be triggered by "xset dpms force off"). Specifically, I: * xset dpms force off * Wait for the monitor to say it's going to sleep and turn the backlight off * Push a button on my keyboard * The monitor wakes back up and turns the backlight on * After a few seconds the monitor goes back into sleep mode, no image is ever displayed. During this time, my second monitor (a USB DisplayLink monitor) continues to work fine. Rebooting fixes the problem, but running "xrandr --output DP2 --off; xrandr --output DP2 --preferred" doesn't help, unplugging and re-plugging the cable doesn't help, and killing X doesn't help. I ran a "git bisect" which indicates that 0e32b39ceed665bfa4a77a4bc307b6652b991632 is the problem, but it's too big of a commit for me to understand, sorry. Attached is the "git bisect" log. I'll be attaching some other logs, but I'm afraid they're not very useful... This in still broken on both 3.19 and 99aedde0869ce194539166ac5a4d2e1a20995348 (master from this morning). 4.0-rc2 has other problems, the display doesn't come up at all.
Created attachment 114058 [details] "dmesg" from before running "xset dpms force off"
Created attachment 114059 [details] "dmesg" from after I pushed a keyboard button
Created attachment 114060 [details] "dmesg" from after I toggle the display with "xrandr"
Created attachment 114061 [details] "dmesg" from after I run "killall X", let slim restart, and log in
Created attachment 114062 [details] "/var/log/Xorg.0.log" from my first X session
Created attachment 114063 [details] "/var/log/Xorg.0.log" from my second X session
OK, that's all the logs I have. If there's anything else I can do just say so!
+Dave
Created attachment 114232 [details] "dmesg" from after I pushed a keyboard button to wake the monitor up, with "drm.debug=1" I tried collecting a log with more debug informaiton. I ran "xset dpms force off" around 55 seconds.
I've been trying to play around a bit to see if I could get any more information, as I'm afraid those logs aren't useful at all. Here's what I found: * My monitor (Asus PB287Q) has two modes, listed as "DisplayPort 1.1 Steam" and "DisplayPort 1.2 Stream". The monitor only supports 4k@60Hz when on DP1.2, which is what I've been using. I believe this means the monitor is not actually a MST monitor, but I'm not sure as I don't know much about this stuff. * When I set the monitor to "DisplayPort 1.1 Stream" it defaults to 1080p@60Hz, but I still get similar behavior -- the monitor works fine before that MST related commit, and is broken afterwards. * In addition to not coming back from DPMS off, the monitor doesn't hotplug. There aren't any errors in dmesg when it fails to come up this way. * Everything appears to work fine (both before and after the MST commit) when I use a Dell 2408WFPb, which I assume is a DP1.1-only monitor (it's manufacture date is listed as August 26th, 2009, which I believe predates the DP1.2 standard). * linux-4.0-rc3 exhibits the same behavior as 3.17. Are there are any more useful debug logs I can produce?
This bug still exists on linux-4.1.5. I can get my monitor to function correctly if I apply the following patch, but I get some warnings from the kernel during both boot and hotplug. I don't understand how DP hotplug works on my other systems if this intel_dp_hot_plug is empty. Additionally, I went and printk()ed some stuff, and I never seem to have is_mst set. If I understand correctly, this means that I don't have an MST monitor. Should I change this bug's feature to "display/DP"? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d714a4b5711e..274bd293d9e9 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4625,7 +4625,9 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs = { void intel_dp_hot_plug(struct intel_encoder *intel_encoder) { - return; + struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base); + + intel_dp_check_link_status(intel_dp); } enum irqreturn [ 4.932814] ------------[ cut here ]------------ [ 4.935170] WARNING: CPU: 2 PID: 1180 at drivers/gpu/drm/i915/intel_dp.c:4032 intel_dp_check_link_status+0x16a/0x1b0() [ 4.937557] WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)) [ 4.937589] Modules linked in: [ 4.942308] CPU: 2 PID: 1180 Comm: kworker/2:2 Not tainted 4.1.5+ #12 [ 4.944700] Hardware name: Apple Inc. MacBookPro11,2/Mac-3CBD00234E554E41, BIOS MBP112.88Z.0138.B07.1402121134 02/12/2014 [ 4.947142] Workqueue: events i915_hotplug_work_func [ 4.949583] ffffffff81e86920 ffff88046bbcfca8 ffffffff81a1ea6d 000000000000005a [ 4.952053] ffff88046bbcfcf8 ffff88046bbcfce8 ffffffff810ca965 ffff88046bbcfd08 [ 4.954521] ffff88046caf20e0 ffff88046c9fbb28 0000000000000001 ffff88046b487508 [ 4.956989] Call Trace: [ 4.959445] [<ffffffff81a1ea6d>] dump_stack+0x45/0x57 [ 4.961915] [<ffffffff810ca965>] warn_slowpath_common+0x85/0xc0 [ 4.964389] [<ffffffff810ca9e1>] warn_slowpath_fmt+0x41/0x50 [ 4.966860] [<ffffffff815dc70a>] intel_dp_check_link_status+0x16a/0x1b0 [ 4.969342] [<ffffffff810fc116>] ? pick_next_task_fair+0x206/0x8b0 [ 4.971802] [<ffffffff815dc760>] intel_dp_hot_plug+0x10/0x20 [ 4.974251] [<ffffffff815d21a5>] intel_ddi_hot_plug+0x25/0x30 [ 4.976703] [<ffffffff81586576>] i915_hotplug_work_func+0x1c6/0x2e0 [ 4.979162] [<ffffffff810e0af7>] process_one_work+0x147/0x3f0 [ 4.981626] [<ffffffff810e0eb9>] worker_thread+0x119/0x450 [ 4.984096] [<ffffffff810e0da0>] ? process_one_work+0x3f0/0x3f0 [ 4.986574] [<ffffffff810e5da4>] kthread+0xc4/0xe0 [ 4.989053] [<ffffffff810e5ce0>] ? kthread_create_on_node+0x180/0x180 [ 4.991541] [<ffffffff81a27f92>] ret_from_fork+0x42/0x70 [ 4.994017] [<ffffffff810e5ce0>] ? kthread_create_on_node+0x180/0x180 [ 4.996552] ---[ end trace 2223e668b1c35f11 ]---
Please test http://lists.freedesktop.org/archives/intel-gfx/2015-August/074150.html
That patch fixes my problem and I no longer get the warning.
(In reply to Palmer Dabbelt from comment #13) > That patch fixes my problem and I no longer get the warning. Thanks for testing. However reopening for tracking purposes until the fix has landed in a git tree.
commit d14e7b6d1d8747826cb900db852351c550e00fdd Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Aug 20 19:37:29 2015 +0300 drm/i915: Check DP link status on long hpd too
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.