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)
Created attachment 114116 [details] dmesg output
Created attachment 114117 [details] Xorg log
Created attachment 114118 [details] VBIOS
[ 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?
(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.
(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.
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.
(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.
Created attachment 114209 [details] dmesg output with nouveau.debug=trace drm.debug=0xe
(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.
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?
(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.
The MMIOTrace is a 211M file (does that sound right?), I may have to upload it from a better connection.
(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
(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?
(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
MMIOTrace can be found here: https://drive.google.com/file/d/0ByBNUo1iKCq2bWZQTzQ0N215WW8/view?usp=sharing
-- 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.