Created attachment 98688 [details]
vbios.rom

Created attachment 98689 [details]
Photo of the screen.

Does it fix itself if you do a suspend/resume cycle?

I can't test with suspend to RAM. My laptop only partially suspends and then it is stuck in that state.

I tried it with suspend to disk. The laptop also fails to suspend, however this time it aborts the suspend and returns to the working state with no screen corruption. Moreover, the corruption is completely gone till the next reboot, i.e. I can reattach connector and the display is still fine.

There is a substantial DP rework bound for 3.16. Can you give http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot?

(In reply to comment #5)
> There is a substantial DP rework bound for 3.16. Can you give
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot?

Completely broken. Does not even start DP screen.

Created attachment 100920 [details]
dmesg (drm-next for 3.16)

That's unfortunate... would you mind providing a dmesg from a boot with

nouveau.debug=PDISP=trace,VBIOS=trace,I2C=trace,DRM=trace

Created attachment 100923 [details]
dmesg (3.16) with debug info

Created attachment 100924 [details]
dmesg (3.16) with debug info

Would you be able to bisect nouveau between 3.15 and current -next to find where it got worse?

(In reply to comment #11)
> Would you be able to bisect nouveau between 3.15 and current -next to find
> where it got worse?

I think so. But it might have to wait till Friday afternoon or Saturday (I can't do this from home now).

I didn't have enough time to finish bisection today but I managed to narrow it down, so it might already be useful. There are just two untested revisions left.


Bad revision is 8894f4919bc43f821775db2cfff4b917871b2102
ebd6acbb068b6558735eb80aabce1e7af9e78e1e
55f083c33feb7231c7574a64cd01b0477715a370
Good revision is 13a61757db124b16cef9b8f9b60ff7337a01b398

I will finish bisecting on Monday.

55f083c33feb7231c7574a64cd01b0477715a370 is the first bad commit which makes the problem worse.
    drm/nouveau/disp/dp: maintain link in response to hpd signal
    
    This previously worked for the most part due to userspace doing a
    modeset in response to HPD interrupts.  This will allow us to
    properly handle cases where sync is lost for other reasons, or if
    userspace isn't caring.

Also, I noticed that the original problem is only present if just DP screen is active. If I have both DP and LVDS screens active then unplugging and plugging back DP cable does not result in display corruption.

Thanks for that.  Can I grab the same debug log, but from the (working) commit before it too.

Thanks.

Created attachment 101180 [details]
dmesg_good

Created attachment 101204 [details] [review]
test patch

Are you able to test whether this helps at all?

Yes it helps. DP screen is no longer black.

The original issue has diminished too. The corrupted portion of the display is three times narrower. But I haven't tested whether this patch helps or one of the patches after that "bad revision" 8894f4919bc43f821775db2cfff4b917871b2102.

(In reply to comment #18)
> Yes it helps. DP screen is no longer black.
> 
> The original issue has diminished too. The corrupted portion of the display
> is three times narrower. But I haven't tested whether this patch helps or
> one of the patches after that "bad revision"
> 8894f4919bc43f821775db2cfff4b917871b2102.

Well, the interesting thing is that the "bad" patch is doing nothing wrong.  There is a change in behaviour in that we train the link at the highest rate supported between the display and the GPU instead of the bare minimum required to support the mode (something which is sensible for supporting MST, and which the NVIDIA binary driver also does).

I've seen some odd behaviour on my GF108 with one particular DP->VGA adapter at the high bit rate too, which the NVIDIA binary driver is also effected by, however, I'm not sure it's the same as you're seeing.  Mine is random, and works a lot of the time.  The bad log *does* look like the same symptoms (the link trains successfully, but continually drops out afterwards).

Would it be at all possible for you to try NVIDIA's driver, and see how it does?  And, if it works, get a trace[1] of it initialising the screen?  Hopefully in your case it works perfectly fine, and I can find something we're doing wrong for the high link rate.

[1] http://nouveau.freedesktop.org/wiki/MmioTrace/

I sent mmiotrace to the usual address.

Created attachment 101299 [details]
dmesg_dont_touch_link

dmesg with "drm/nouveau/disp/dp: don't touch link config after success" patch

(In reply to comment #21)
> Created attachment 101299 [details]
> dmesg_dont_touch_link
> 
> dmesg with "drm/nouveau/disp/dp: don't touch link config after success" patch

I forgot to mention that the screen is not working even with this patch.

I retested this with the newest kernel (drm-fixes branch) but the screen is still black.

Created attachment 115643 [details]
dmesg.txt (higher modes)

Ilia asked to create dmesg with the following nouveau_dp_rates[] enabled:

{  648000, 0x06, 4 },
{  324000, 0x06, 2 },
{  162000, 0x06, 1 },

In this 648 mode the whole screen flickers a lot (no reattaching is necessary to reproduce it, it happens immediately)

Created attachment 115644 [details]
dmesg.txt.xz (lower modes, reattaching)

only the lower modes are enabled:

{  324000, 0x06, 2 },
{  162000, 0x06, 1 }

When booting, everything starts fine. After reattaching DP connector, the right side of the screen flickers. (Note that flickering in 648 mode is more severe, affects the whole screen and even causes blinking of the screen)

The screen that I used in this bug is now broken. I can't test this bug right now because the replacement screen that I was given does not have DP connector.

I'll close this because I don't have hardware any more  and nobody else was able to reproduce it.