Bug 32645 - NV20 GF 3 Ti 200, displays blank screen to DVI
Summary: NV20 GF 3 Ti 200, displays blank screen to DVI
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-24 21:00 UTC by Bryan Quigley
Modified: 2011-01-23 17:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Kern log using DVI (69.98 KB, text/plain)
2010-12-24 21:01 UTC, Bryan Quigley
no flags Details
Xorg log using DVI (16.45 KB, text/x-log)
2010-12-24 21:01 UTC, Bryan Quigley
no flags Details
Kern log using VGA (this works just for comparison) (70.97 KB, text/plain)
2010-12-24 21:02 UTC, Bryan Quigley
no flags Details
Xorg log using VGA (this works just for comparison) (57.23 KB, text/plain)
2010-12-24 21:02 UTC, Bryan Quigley
no flags Details
Kern log using DVI (with debug mode turned on.. I think) (79.57 KB, text/plain)
2010-12-24 21:32 UTC, Bryan Quigley
no flags Details
nv20_broken_dcb.patch (1.05 KB, patch)
2010-12-25 05:39 UTC, Francisco Jerez
no flags Details | Splinter Review
Kern log DVI with patch (76.05 KB, text/plain)
2010-12-25 13:40 UTC, Bryan Quigley
no flags Details
Kern with DVI with patch really working (171.44 KB, text/x-log)
2010-12-26 15:17 UTC, Bryan Quigley
no flags Details
Xorg with DVI and patch actually working (55.23 KB, text/plain)
2010-12-26 15:17 UTC, Bryan Quigley
no flags Details
NVidia driver - different problem (508.33 KB, image/png)
2011-01-06 18:27 UTC, Bryan Quigley
no flags Details
Lower Resolution Dump of nVidia driver (24.22 KB, application/octet-stream)
2011-01-06 18:28 UTC, Bryan Quigley
no flags Details
75Hz Dump with 24 bit color (24.22 KB, application/octet-stream)
2011-01-06 18:28 UTC, Bryan Quigley
no flags Details
Just on boot dump (24.22 KB, application/octet-stream)
2011-01-06 18:29 UTC, Bryan Quigley
no flags Details
VGA for same monitor for hopefully useful reference (24.22 KB, application/octet-stream)
2011-01-06 20:19 UTC, Bryan Quigley
no flags Details
nv20_crtc_lwm.patch (431 bytes, patch)
2011-01-09 04:48 UTC, Francisco Jerez
no flags Details | Splinter Review
TVDump from the 1600x1200 monitor (24.23 KB, application/octet-stream)
2011-01-16 10:54 UTC, Bryan Quigley
no flags Details
nv20_crtc_lwm_2.patch (438 bytes, patch)
2011-01-20 04:01 UTC, Francisco Jerez
no flags Details | Splinter Review
TVdump from nouveau running 1600x1200 (24.23 KB, text/plain)
2011-01-21 16:37 UTC, Bryan Quigley
no flags Details

Description Bryan Quigley 2010-12-24 21:00:23 UTC
I have a monitor that supports both DVI and VGA.  The VGA seems to work fine (aside from the fact that at startup it sometimes powers down for a second). The DVI on the other hand doesn't work as soon as we start booting (BIOS and GRUB work).  

I am attaching the kern and Xorg log for both when using VGA and when using DVI.  I am using the latest Xorg Edgers PPA in Ubuntu, built from git 3 days ago.
Comment 1 Bryan Quigley 2010-12-24 21:01:04 UTC
Created attachment 41431 [details]
Kern log using DVI
Comment 2 Bryan Quigley 2010-12-24 21:01:33 UTC
Created attachment 41432 [details]
Xorg log using DVI
Comment 3 Bryan Quigley 2010-12-24 21:02:13 UTC
Created attachment 41433 [details]
Kern log using VGA (this works just for comparison)
Comment 4 Bryan Quigley 2010-12-24 21:02:40 UTC
Created attachment 41434 [details]
Xorg log using VGA (this works just for comparison)
Comment 5 Bryan Quigley 2010-12-24 21:32:00 UTC
Created attachment 41435 [details]
Kern log using DVI (with debug mode turned on.. I think)
Comment 6 Francisco Jerez 2010-12-25 05:39:26 UTC
Created attachment 41440 [details] [review]
nv20_broken_dcb.patch

(In reply to comment #0)
> I have a monitor that supports both DVI and VGA.  The VGA seems to work fine
> (aside from the fact that at startup it sometimes powers down for a second).
> The DVI on the other hand doesn't work as soon as we start booting (BIOS and
> GRUB work).  
> 
> I am attaching the kern and Xorg log for both when using VGA and when using
> DVI.  I am using the latest Xorg Edgers PPA in Ubuntu, built from git 3 days
> ago.

Apparently your BIOS incorrectly claims that you have an LVDS output (instead of TMDS), the attached patch may help.
Comment 7 Bryan Quigley 2010-12-25 13:40:50 UTC
Created attachment 41444 [details]
Kern log DVI with patch

It still doesn't work... and I am not entirely sure I applied the patch correctly.. but the output was a bit different.
Comment 8 Francisco Jerez 2010-12-25 14:12:50 UTC
(In reply to comment #7)
> Created an attachment (id=41444) [details]
> Kern log DVI with patch
> 
> It still doesn't work... and I am not entirely sure I applied the patch
> correctly.. but the output was a bit different.

It doesn't look like you were running the patched kernel module, it's still detecting LVDS. Make sure you've updated your initrd (if that's where the module is being loaded from).
Comment 9 Bryan Quigley 2010-12-26 15:17:27 UTC
Created attachment 41463 [details]
Kern with DVI with patch really working

Thanks! It now works.. but there is an ok amount of artifacting and flashing going on.  (It's usable, but acceleration (video) at least doesn't appear to work).
Comment 10 Bryan Quigley 2010-12-26 15:17:59 UTC
Created attachment 41464 [details]
Xorg with DVI and patch actually working
Comment 11 Francisco Jerez 2010-12-27 02:22:59 UTC
(In reply to comment #9)
> Created an attachment (id=41463) [details]
> Kern with DVI with patch really working
> 
> Thanks! It now works.. but there is an ok amount of artifacting and flashing
> going on.  (It's usable, but acceleration (video) at least doesn't appear to
> work).

Could you be a bit more specific about this "artifacting and flashing"? What do you have to do to trigger it? Can you catch it in a screenshot? Do you see anything wrong in the accelerated framebuffer console?

If you are running an OpenGL compositing manager or any OpenGL applications,
please uninstall the 3D drivers to rule that out as the cause of corruption.
Comment 12 Bryan Quigley 2010-12-27 18:01:55 UTC
My fault.  Testing with a new monitor revealed no issues..  Thanks again!  Should I mark as fixed or wait until the patch is committed?
Comment 13 Francisco Jerez 2010-12-29 05:06:10 UTC
(In reply to comment #12)
> My fault.  Testing with a new monitor revealed no issues..  Thanks again! 
> Should I mark as fixed or wait until the patch is committed?

Are you sure that wasn't a driver issue? Do you get any corruption with the same monitor and same video modes on the "nv" or nvidia proprietary driver?
Comment 14 Bryan Quigley 2010-12-29 19:31:13 UTC
Oops.. you are correct
here are two videos documenting the two issues I've seen so far:
Bootup:  About a third of the screen flashes on the bottom, then the top,this happens repeatadly.  Also happens when playing videos.
https://docs.google.com/leaf?id=0B9PdLrdrtm1wOGQzMzYwNjMtZjgwMC00ZTljLThlOGEtZDFmODM0ZDIwMWNh&hl=en&authkey=CNngh6UD
Small artifacts:  Note on the top of the video (side of the screen) When the mouse is over certain objects small artifacts appear.
https://docs.google.com/leaf?id=0B9PdLrdrtm1wMGNiOGQ4YzMtZWUwOC00Mzg2LWIwN2EtMzRhZmMzNDAwNTk5&hl=en&authkey=CPygr9cM
Comment 15 Francisco Jerez 2011-01-03 11:06:32 UTC
(In reply to comment #14)
> Oops.. you are correct
> here are two videos documenting the two issues I've seen so far:
> Bootup:  About a third of the screen flashes on the bottom, then the top,this
> happens repeatadly.  Also happens when playing videos.
> https://docs.google.com/leaf?id=0B9PdLrdrtm1wOGQzMzYwNjMtZjgwMC00ZTljLThlOGEtZDFmODM0ZDIwMWNh&hl=en&authkey=CNngh6UD
> Small artifacts:  Note on the top of the video (side of the screen) When the
> mouse is over certain objects small artifacts appear.
> https://docs.google.com/leaf?id=0B9PdLrdrtm1wMGNiOGQ4YzMtZWUwOC00Mzg2LWIwN2EtMzRhZmMzNDAwNTk5&hl=en&authkey=CPygr9cM

So, if I've understood correctly, you only get artifacts with this monitor and not with the other one? Could you please try "nv" or the nvidia binary driver?
Comment 16 Bryan Quigley 2011-01-03 21:45:48 UTC
It works but has the artifacts on both monitors that I have that are 1440 x 900 and 1600 x 1200 using DVI (with patch).  Using VGA they both work great.

The monitors are fine (I swapped out the GF3 and put in a GF5 for the time being)
And the Geforce3 works fine with the nvidia driver, no flickering or artifacts.
But the nv driver doesn't work at all with the GF3 DVI setup.
Comment 17 Francisco Jerez 2011-01-04 05:33:17 UTC
(In reply to comment #16)
> It works but has the artifacts on both monitors that I have that are 1440 x 900
> and 1600 x 1200 using DVI (with patch).  Using VGA they both work great.
> 
> The monitors are fine (I swapped out the GF3 and put in a GF5 for the time
> being)
> And the Geforce3 works fine with the nvidia driver, no flickering or artifacts.
> But the nv driver doesn't work at all with the GF3 DVI setup.

OK, a few register dumps (running [1] as root) from the nvidia driver at several different video modes/refresh rates/color depths would be very useful.

[1] http://cgit.freedesktop.org/~currojerez/tvdump/
Comment 18 Bryan Quigley 2011-01-06 18:27:26 UTC
Created attachment 41731 [details]
NVidia driver - different problem

Apparently, I was wrong about the nVidia driver working fine.  It doesn't have the same issues though as shown in the screen-shot.
Comment 19 Bryan Quigley 2011-01-06 18:28:06 UTC
Created attachment 41732 [details]
Lower Resolution Dump of nVidia driver
Comment 20 Bryan Quigley 2011-01-06 18:28:33 UTC
Created attachment 41733 [details]
75Hz Dump with 24 bit color
Comment 21 Bryan Quigley 2011-01-06 18:29:00 UTC
Created attachment 41734 [details]
Just on boot dump
Comment 22 Bryan Quigley 2011-01-06 20:19:01 UTC
Created attachment 41736 [details]
VGA for same monitor for hopefully useful reference
Comment 23 Francisco Jerez 2011-01-09 04:48:14 UTC
Created attachment 41797 [details] [review]
nv20_crtc_lwm.patch

Thank you for the dumps, does the attached patch have any effect on the artifacts?
Comment 24 Bryan Quigley 2011-01-16 10:54:59 UTC
Created attachment 42106 [details]
TVDump from the 1600x1200 monitor

I've switched monitors a couple times, and just realized all the tvdumps were from the lesser resolution one.  I tried the patch nv20_crtc_lwm.patch on the 1600x1200 and it doesn't fix the corruption.  (If anything it might be a little worse, I realized the flickering is actually displaying at some points the contents of one of the VTs)
Comment 25 Francisco Jerez 2011-01-20 04:01:13 UTC
Created attachment 42222 [details] [review]
nv20_crtc_lwm_2.patch

Second try. If you're still seeing corruption with this on the 1440x900
monitor, can you get another register dump from nouveau for comparison?
Comment 26 Bryan Quigley 2011-01-20 20:47:18 UTC
I've actually switched to just testing the 1600x1200 monitor for now... It
didn't appear to have any effect.. Should I have undone the previous patch
first?
Can I just do a register dump of the 1600x1200?
Comment 27 Francisco Jerez 2011-01-21 04:45:59 UTC
(In reply to comment #26)
> Can I just do a register dump of the 1600x1200?

Yeah, that should do it, thanks.
Comment 28 Bryan Quigley 2011-01-21 16:37:34 UTC
Created attachment 42295 [details]
TVdump from nouveau running 1600x1200
Comment 29 Francisco Jerez 2011-01-21 18:49:39 UTC
(In reply to comment #28)
> Created an attachment (id=42295) [details]
> TVdump from nouveau running 1600x1200

Apparently this video mode is making your card hit its memory bandwidth limits - a 279MHz memory clock (the default your BIOS sets) is usually enough for it, but when you start doing acceleration the CRTC FIFOs get filled more slowly and they eventually underflow, causing this corruption.

The last two patches set a more aggressive CRTC FIFO arbitration policy. That doesn't seem to be enough. Does it get any better with "nouveau.perflvl_wr=7777 nouveau.perflvl=0" in the kernel command line?
Comment 30 Bryan Quigley 2011-01-21 22:09:18 UTC
It does, the "Small artifacts" go away.  The flickering does not, but does
seem to be slightly reduced.
Comment 31 Francisco Jerez 2011-01-22 05:13:12 UTC
(In reply to comment #30)
> It does, the "Small artifacts" go away.  The flickering does not, but does
> seem to be slightly reduced.

Does "video=VGA-1:d" (in the kernel command line) make the flickering go away?
Comment 32 Bryan Quigley 2011-01-22 09:55:38 UTC
The flickering is gone! Thanks!
Comment 33 Francisco Jerez 2011-01-22 10:43:57 UTC
(In reply to comment #32)
> The flickering is gone! Thanks!

OK, that means that something's repeatedly polling the status of your VGA connector. Your card has only one CRTC and there's no way to do that without disrupting the DVI-D output. That's not our bug, whatever is polling your VGA connector should be listening to RandR events instead.

By the way, do you need any of the nv20_crtc_lwm patches to get rid of the bandwidth artifacts, or are the "perflvl" kernel options enough?
Comment 34 Bryan Quigley 2011-01-23 14:12:16 UTC
How would I narrow down who is repeatedly polling the status of my VGA?
The perflvl kernel options are enough.. What is that actually doing?
Comment 35 Francisco Jerez 2011-01-23 17:01:43 UTC
(In reply to comment #34)
> How would I narrow down who is repeatedly polling the status of my VGA?
I guess you don't get any flickering with other window managers?

> The perflvl kernel options are enough.. What is that actually doing?
"perflvl" tells the driver to set a performance level different to the BIOS defaults (BIOSes usually leave the GPU in some kind of low power consumption mode), in your case that just means 400MHz instead of 279MHz as memory clock.

Right now we leave the clocks set by the BIOS untouched because our PM code isn't considered stable yet, that will probably change at some point, until then you'll have to keep these module options in your command line to avoid the corruption you've seen.

I've pushed the patch that fixed your original problem to the nouveau kernel tree, so I'm marking this as fixed.


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.