Bug 89484

Summary: [NVD9] xrandr no output to DisplayPort with GeForce GT 520M.
Product: xorg Reporter: Corey Bresnan <corey.quixote>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output
none
Xorg log
none
VBIOS
none
dmesg output with nouveau.debug=trace drm.debug=0xe none

Description Corey Bresnan 2015-03-07 19:02:18 UTC
Originially posted in Archlinux BBS:
https://bbs.archlinux.org/viewtopic.php?id=193143

DisplayPort fails to show output when using xrandr to set display.  Monitor shown as "connected" and displays correct modes, however no output is sent to the attached monitor. 

dmesg and xorg.0.log are showing errors related to Nouveau driver (see attachments in subsequent posts).

xorg.conf is empty (defaults).

Machine uses descrete graphics (Optimus), with DisplayPort attached to the Nvidia card:

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

01:00.0 VGA compatible controller: NVIDIA Corporation GF119M 
[GeForce GT 520M] (rev a1)
Comment 1 Corey Bresnan 2015-03-07 19:03:22 UTC
Created attachment 114116 [details]
dmesg output
Comment 2 Corey Bresnan 2015-03-07 19:03:52 UTC
Created attachment 114117 [details]
Xorg log
Comment 3 Corey Bresnan 2015-03-07 19:04:41 UTC
Created attachment 114118 [details]
VBIOS
Comment 4 Ilia Mirkin 2015-03-07 19:23:01 UTC
[    5.212934] nouveau  [     DRM] TMDS table version 2.0
[    5.212935] nouveau  [     DRM] DCB version 4.0
[    5.212937] nouveau  [     DRM] DCB outp 00: 020003a6 0f220010
[    5.212938] nouveau  [     DRM] DCB outp 01: 02000362 00020010
[    5.212940] nouveau  [     DRM] DCB conn 00: 00101046
[    5.213611] nouveau E[   VBIOS][0000:01:00.0] 0x5c86[0]: script needs crtc

Something unexpected is going on in the VBIOS which breaks everything. Did this work with older kernels?
Comment 5 Corey Bresnan 2015-03-07 20:28:53 UTC
(In reply to Ilia Mirkin from comment #4)
> [    5.212934] nouveau  [     DRM] TMDS table version 2.0
> [    5.212935] nouveau  [     DRM] DCB version 4.0
> [    5.212937] nouveau  [     DRM] DCB outp 00: 020003a6 0f220010
> [    5.212938] nouveau  [     DRM] DCB outp 01: 02000362 00020010
> [    5.212940] nouveau  [     DRM] DCB conn 00: 00101046
> [    5.213611] nouveau E[   VBIOS][0000:01:00.0] 0x5c86[0]: script needs crtc
> 
> Something unexpected is going on in the VBIOS which breaks everything. Did
> this work with older kernels?

At this point, I can only say for certain that it hasn't worked since 3.18.4-1-ARCH (currently using 3.18.6-1-ARCH); before that I was using Nvidia's proprietary drivers and have not tested with nouveau.
Comment 6 Corey Bresnan 2015-03-07 21:25:57 UTC
(In reply to Corey Bresnan from comment #5)
> (In reply to Ilia Mirkin from comment #4)
> > [    5.212934] nouveau  [     DRM] TMDS table version 2.0
> > [    5.212935] nouveau  [     DRM] DCB version 4.0
> > [    5.212937] nouveau  [     DRM] DCB outp 00: 020003a6 0f220010
> > [    5.212938] nouveau  [     DRM] DCB outp 01: 02000362 00020010
> > [    5.212940] nouveau  [     DRM] DCB conn 00: 00101046
> > [    5.213611] nouveau E[   VBIOS][0000:01:00.0] 0x5c86[0]: script needs crtc
> > 
> > Something unexpected is going on in the VBIOS which breaks everything. Did
> > this work with older kernels?
> 
> At this point, I can only say for certain that it hasn't worked since
> 3.18.4-1-ARCH (currently using 3.18.6-1-ARCH); before that I was using
> Nvidia's proprietary drivers and have not tested with nouveau.

Downgraded to kernels 3.16.* and 3.17.* with the same results.
Comment 7 Ilia Mirkin 2015-03-09 14:20:27 UTC
Could you supply a dmesg from a boot with

nouveau.debug=trace drm.debug=0xe

where you try to activate the DP screen? It's unclear whether your vbios issue is related to your DP problems. Additionally, can you confirm that you've properly set up the provider stuff as per http://nouveau.freedesktop.org/wiki/Optimus/ to be able to use reverse prime? (I guess if it shows up in xrandr, that's a pretty good sign.)

Lastly, the reason for the VBIOS errors is that we hit unexpected opcodes in some scripts. Seeing what the blob does would be instructional. If possible, please produce a mmiotrace of nvidia's driver. See https://wiki.ubuntu.com/X/MMIOTracing for a quick guide.
Comment 8 Corey Bresnan 2015-03-10 20:04:20 UTC
(In reply to Ilia Mirkin from comment #7)
> Could you supply a dmesg from a boot with
> 
> nouveau.debug=trace drm.debug=0xe

See below.

> where you try to activate the DP screen? It's unclear whether your vbios
> issue is related to your DP problems. Additionally, can you confirm that
> you've properly set up the provider stuff as per
> http://nouveau.freedesktop.org/wiki/Optimus/ to be able to use reverse
> prime? (I guess if it shows up in xrandr, that's a pretty good sign.)

As far as I can tell, the provider stuff is set up correctly as per the link (I'm not sure as to what specifically you would like me to confirm, could you please elaborate?). On closer inspection, I think the VBIOS issue is related, *but not limited* to my DP problems; I can't seem to access the GPU with other methods, i.e using the method described in the above link or via bumblebee for example.

> Lastly, the reason for the VBIOS errors is that we hit unexpected opcodes in
> some scripts. Seeing what the blob does would be instructional. If possible,
> please produce a mmiotrace of nvidia's driver. See
> https://wiki.ubuntu.com/X/MMIOTracing for a quick guide.

See below.
Comment 9 Corey Bresnan 2015-03-10 20:10:03 UTC
Created attachment 114209 [details]
dmesg output with nouveau.debug=trace drm.debug=0xe
Comment 10 Ilia Mirkin 2015-03-10 20:16:53 UTC
(In reply to Corey Bresnan from comment #8)
> As far as I can tell, the provider stuff is set up correctly as per the link
> (I'm not sure as to what specifically you would like me to confirm, could
> you please elaborate?).

The fact that you know about provider stuff to begin with leads me to believe you've probably done it correctly :) Basically wanted to make sure that you had done xrandr --setprovideroutputsource 1 0 or something.

> On closer inspection, I think the VBIOS issue is
> related, *but not limited* to my DP problems; I can't seem to access the GPU
> with other methods, i.e using the method described in the above link or via
> bumblebee for example.

bumblebee just causes more issues. nouveau should auto-suspend the card if things are working fine -- check the vgaswitcheroo file, it should say DynOff.

Will look at the nouveau trace + blob mmiotrace to see if anything interesting pops up.
Comment 11 Ilia Mirkin 2015-03-10 20:25:33 UTC
What hardware is this on? It appears to detect a LVDS panel connected to intel, and the DP port on nvidia gets detected as eDP, which is also used to drive internal panels. I assume that little bit is wrong and it's just a regular DP port?
Comment 12 Corey Bresnan 2015-03-10 20:34:42 UTC
(In reply to Ilia Mirkin from comment #11)
> What hardware is this on? It appears to detect a LVDS panel connected to
> intel, and the DP port on nvidia gets detected as eDP, which is also used to
> drive internal panels. I assume that little bit is wrong and it's just a
> regular DP port?

Yes, you are correct. The DP port is an external port hard-wired to the Nvidia card.

I'm using a Dell XPS 14z, so specifically the Nvidia card is a GeForce GT 520M. The Intel has the laptops's LVDS and an external HDMI, and the Nvidia has the offending external DP.
Comment 13 Corey Bresnan 2015-03-10 20:44:00 UTC
The MMIOTrace is a 211M file (does that sound right?), I may have to upload it from a better connection.
Comment 14 Ilia Mirkin 2015-03-10 20:49:39 UTC
(In reply to Corey Bresnan from comment #13)
> The MMIOTrace is a 211M file (does that sound right?), I may have to upload
> it from a better connection.

xz -9 helps a lot
Comment 15 Corey Bresnan 2015-03-10 21:39:08 UTC
(In reply to Ilia Mirkin from comment #14)
> (In reply to Corey Bresnan from comment #13)
> > The MMIOTrace is a 211M file (does that sound right?), I may have to upload
> > it from a better connection.
> 
> xz -9 helps a lot

Haha, I think I need another coffee. I still can't get it below 8.9M (upload to Bugzilla requires < 3M). Where is the most convenient place to upload it with a link?
Comment 16 Ilia Mirkin 2015-03-10 21:41:54 UTC
(In reply to Corey Bresnan from comment #15)
> (In reply to Ilia Mirkin from comment #14)
> > (In reply to Corey Bresnan from comment #13)
> > > The MMIOTrace is a 211M file (does that sound right?), I may have to upload
> > > it from a better connection.
> > 
> > xz -9 helps a lot
> 
> Haha, I think I need another coffee. I still can't get it below 8.9M (upload
> to Bugzilla requires < 3M). Where is the most convenient place to upload it
> with a link?

email to mmio.dumps@gmail.com and/or use google drive
Comment 17 Corey Bresnan 2015-03-10 23:30:50 UTC
MMIOTrace can be found here:

https://drive.google.com/file/d/0ByBNUo1iKCq2bWZQTzQ0N215WW8/view?usp=sharing
Comment 18 Martin Peres 2019-12-04 08:56:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/174.

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.