|
Description
Bryan Quigley
2010-12-24 21:00:23 UTC
Created attachment 41431 [details]
Kern log using DVI
Created attachment 41432 [details]
Xorg log using DVI
Created attachment 41433 [details]
Kern log using VGA (this works just for comparison)
Created attachment 41434 [details]
Xorg log using VGA (this works just for comparison)
Created attachment 41435 [details]
Kern log using DVI (with debug mode turned on.. I think)
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. 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.
(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). 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).
Created attachment 41464 [details]
Xorg with DVI and patch actually working
(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. My fault. Testing with a new monitor revealed no issues.. Thanks again! Should I mark as fixed or wait until the patch is committed? (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? 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 (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? 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. (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/ 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.
Created attachment 41732 [details]
Lower Resolution Dump of nVidia driver
Created attachment 41733 [details]
75Hz Dump with 24 bit color
Created attachment 41734 [details]
Just on boot dump
Created attachment 41736 [details]
VGA for same monitor for hopefully useful reference
Created attachment 41797 [details] [review] nv20_crtc_lwm.patch Thank you for the dumps, does the attached patch have any effect on the artifacts? 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)
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? 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? (In reply to comment #26) > Can I just do a register dump of the 1600x1200? Yeah, that should do it, thanks. Created attachment 42295 [details]
TVdump from nouveau running 1600x1200
(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? It does, the "Small artifacts" go away. The flickering does not, but does seem to be slightly reduced. (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? The flickering is gone! Thanks! (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? 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? (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.