Created attachment 77837 [details] After the last mode setting,DP lost output Bios Version: ACRVMBY1.86C.0080.B00 Kernel: 3.9.rc6 Label: MBY02SDP Platform: MahoBay Processor/Chipset: IvyBridge/PantherPoint OS:SUSE Linux Enterprise Desktop 11 SP3 Beta4 (x86_64) 2D driver version: 2.21.4 Details: Connected the VGA + DP and then switched the terminal, sometimes DP output lost, VGA output normally. This issue doesn't find when connected the HDMI and VGA. Steps to Reproduce: 1.Connect DP + VGA . 2.Switch the terminal. Further info: If connecting one DP, terminal switch has no problem. But if connecting two displays(DP + VGA), DP worked as 1920 X 1200, VGA worked as 1024 X 768, sometimes DP will lost display no matter in text mode or graphic mode, the lost rate is about 20 percent. When switch terminal to console, DP will work in 1920 X 1200 also. So maybe DP can't work perfectly in 1920 X 1200 on this platform.
Just to check: When you the DP signal is lost, is there anything in the dmesg debug output about it? I somewhat expected a link training issue, but in the attached dmesg there's nothing ... Also, if DP signal is lost, does it restore in a few seconds? If not, does unplugging and replugging the DP cable fix things?
(In reply to comment #1) > Just to check: When you the DP signal is lost, is there anything in the > dmesg debug output about it? I somewhat expected a link training issue, but > in the attached dmesg there's nothing ... Yes, when dp lost display, there isn't error mesg in dmesg. Once setting dp from 1024 X 768 to 1920 X 1200 at 151.091982 in dmesg, then dp output nothing. >Also, if DP signal is lost, does > it restore in a few seconds? If not, does unplugging and replugging the DP > cable fix things? it will not restore in a few seconds. But unplugging and replugging the DP cable can restore it. thanks
(In reply to comment #2) > (In reply to comment #1) > > Just to check: When you the DP signal is lost, is there anything in the > > dmesg debug output about it? I somewhat expected a link training issue, but > > in the attached dmesg there's nothing ... > > Yes, when dp lost display, there isn't error mesg in dmesg. Once setting dp > from 1024 X 768 to 1920 X 1200 at 151.091982 in dmesg, then dp output > nothing. Can you please attach that error? Also, can you please retest on latest drm-intel-nightly branch from http://cgit.freedesktop.org/~danvet/drm-intel ?
(In reply to comment #3) >Can you please attach that > error? This is no error message in dmesg when DP lost display. >Also, can you please retest on latest drm-intel-nightly branch from > http://cgit.freedesktop.org/~danvet/drm-intel ? drm-intel-nightly has the same issue
Created attachment 78540 [details] dmesg After setting DP to 1920X1080, dp screen become black and lost display. But there is no error message in dmesg.
I'm pretty clueless here, but it might be interesting to see intel_reg_dumper output after a successful switch and after a failed switch.
Created attachment 78964 [details] Both VGA and DP work at 1024 X 768, both can display
Created attachment 78965 [details] VGA is 1024 * 768, DP is 1920 X 1200, both can display
Created attachment 78966 [details] VGA is 1024 * 768, DP is 1920 X 1200, VGA can display but DP is lost the register is almost the same between success and fail.
Probably fixed with commit cdbd2316a03f68b25a135a34d1d24f01ddef0c53 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 5 13:34:03 2013 +0200 drm/i915: fix up pch pll handling in ->mode_set in drm-intel-next. Please reopen if that's not the case, thanks.
Today, I tested drm-intel-next-queued branch, this issue exist also. the latest commit is: commit 4a46ddde4c0bab99d7bfa26045166d8669bd83a6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jun 25 17:26:45 2013 +0100 drm/i915: Detect invalid scanout pitches
The register difference is just a rolling counter so I would expect that to be different. What is your target Displayport display and did you try reproducing this with a different display? With no message in the logs and no difference between pass and fail in the registers, it's possible this is a failure is on the sink side, not on the source side. Certainly not ruling out a potential problem on our side, I'm just curious to see if it happens with more than one Displayport monitor.
I tried three DP screens, one screen hasn't this issue, two screens have this problem. DELL 2408WFPb: no such problem DELL U2410: has such problem. HP ZR2440w: has such problem.
Interesting. The DELL 2408 is the older model and doesn't exhibit the same problem. Without errors in the logs, though, we're not chasing a link or lane failure. This might be some discrepancy in how sink devices react to mode changes and how they handle changing or updated stream attributes. I'll keep looking into this and see what I can find.
Ping. What's the status?
Today, I tested drm-intel-next-queued branch, this issue still exist and is the same as comment#14.
I need to try this again with the latest drm-intel-nightly. But just to clarify - when both VGA and DP are set to 1024x768, then you change DP to 1920x1200, the Displayport signal is lost. Correct?
yes, the dp lost rate is about 20%
When I tried this previously I could not get it to happen on the combination of my MahoBay system and the HP ZR2440w on my desk. I haven't tried this in quite some time though, so I'll see if I can do that by the end of the week. Have you tried to set different modes once the signal is lost to see if it will come up with a different resolution? Or does it require retraining/hot plugging to restore the video? How about setting it back to 1024x768?
(In reply to comment #20) > Have you tried to set different modes once the signal is lost to see if it > will come up with a different resolution? Or does it require retraining/hot > plugging to restore the video? How about setting it back to 1024x768? I can reproduce this issue using latest drm-intel-nightly branch.When DP lost output and hot plug DP, sometimes dp can restore. sometimes it can't. Setting it back to 1024X768, dp can restore display.
Please retest with current drm-intel-nightly.
Timing out and assuming (hopefully!) that this is fixed with misc DP changes since then.
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.