Created attachment 89290 [details] archive of log files Hardware: Lenovo ThinkCentre M2600C Chipset: Intel 2nd Gen Core Processor Family Integrated Graphics Controller (rev 09) i915 driver OS: Ubuntu 13.10 Kernel: 3.11 Intel Driver: 2.99.904 Monitors: Acer X223W 22" (VGA) and Asus VW224 22" (DVI with displayPort adapter) Problem: If we use a DisplayPort to DVI/VGA adapter the monitor is not being detected and remains in its sleep state. Reproduction Steps: 1. Plug in a VGA monitor into VGA port. 2. Plug in a DVI monitor via a DisplayPort to DVI adapter. 3. Boot Ubuntu 13.10 LiveUSB 4. Video will only output on the monitor connected via VGA - other monitor with displayPort adapter slips into power saving mode after bios screens display 5. Run xrandr in the xterm to confirm only one display (VGA) is seen The second monitor which is plugged in using the adapter remains in its sleep state and is never seen or acknowledged by the OS. We see the exact same behavior in our custom OS which is running the 3.8 kernel and an older version of the Intel driver. If we use a regular DisplayPort monitor (no adapter) we have no problems with getting video on the 2nd monitor. It is only when using these adapters (we've tried about 5 different kinds) that we see this problem. I'm pretty sure this is happening in intel-drm as I can set drm.debug=14 in the boot command line and get all sorts of information. Now here is where it gets interesting. If I roll back to Ubuntu 12.04 then the monitor attached via the adapter now works however in xrandr it is listed as an HDMI-1 monitor while it says DP1 is disconnected. Regardless we're able to get video on both screens with an older kernel. I tracked it down to basically anything running the 3.5 kernel or earlier seem to be working however the 3.6, 3.8 and 3.11 kernel have this issue. The Ubuntu 12.04 distro is running the Intel 2.17.0 module. I'm attaching both drm.debug=14 logs to provide some deeper insight. Included is the dmesg logs from a working (good) kernel and a non-working (bad) kernel build as well as the Xorg logs from the system.
One bit of follow up information - we found that in some random cases, if we put the unit to suspend mode (whole unit) and then hit the power button to wake it up sometimes we do get the 2nd monitor using the adapter to wake it up. I think the code to wake it up follows a different path but it isn't 100% reproducable (usually 5-8 tries for it to wake up) if the monitor then is left alone and goes into a screen saver or you type xrandr you lose the monitor again.
We've made a few fixes to the DP code recently, can you please test the drm-intel-nightly branch from http://cgit.freedesktop.org/~danvet/drm-intel/ If that doesn't work please attach a new drm.debug=0xe dmesg grabbed after having reproduced the issue.
Created attachment 90671 [details] updated dmesg using drm.debug=0xe using nightly build
Hello Dan, sorry for the delay in getting you this log. I just attached the updated log from a nightly build from a few days ago. Still seeing the same issue unfortunately. Is there anything else I can assist with?
Ok the HDMI vs DP thing makes sense if this is a passive dongle. In that case, it just level shifts and ends up talking to our HDMI port on the chip. So DP wouldn't be involved in that case. I see the kernel properly detects that HDMI is enabled at boot time, but then fails to detect any modes later on, so assumes the output is disconnected. I wonder if this has something to do with the dongle... If this worked in 3.5 and failed in 3.6, I wonder if you can bisect it. That might give us some clues at least...
Any chance you could bisect this?
Hello Jesse, do you mean do run a diff on the two kernel configs? Yeah, I can check to see what is different however I'm pretty sure its just a stock Ubuntu kernels - nothing was changed from the original downloads but I'm not sure what all they do to their kernels. I'll try and post something back later today. Thank you for your help thus far.
No I was thinking you could use "git bisect" to figure this out. It would involve building your own kernels, but there are lots of googleable guide on it out there on the web. Finding the offending commit would be the fastest way to get this fixed.
Here's a guide to bisecting: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
Is this still an issue? Or have you given up?
Hello Jesse - I had not gotten a chance to do the git-bisect however in the past few months we have bumped our kernel to 3.13 as a result of some other changes and as of testing with this particular peice of hardware it appears that we now get video output on the previous missing display with the adapter. I want to test with a few more monitors and adapters but this might be safe to close soon as fixed. I'll provide a follow up post before the end of the day.
Awesome, thanks for the follow up. Please re-open if you still see this particular problem, or file a new bug (or bugs!) if you find new issues. Thanks, Jesse
This issue has popped up again, I've narrowed it down and have it working with the 3.7.10 kernel and it appears to have broken on the 3.8.0 kernel. Not sure how it was broken before with a 3.6 kernel but as of my testing today all of the 3.6 kernels seemed fine. This only happens with passive adapters. Tested with various kernels going all the way up to 3.13 and as long as I have a passive adapter I get no output. Active adapters seem fine. Now for my testing I was simply installing Ubuntu kernels - I'll attempt to do a bisect but this is my first time doing such a thing so I'm walking through this slowly.
FWIW it just might be more productive to try to debug this with a recent kernel, v3.17 or later.
Scrap that re-opened... the problem was being reported on earlier hardware revisions that were not finalized. This is no longer an issue. Our passive adapters are working fine on the latest revisions. Sorry for the concern!
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.