Linked bug report contains kernel logs from ancient version of nouveau. Please attach complete kernel log (as obtained by dmesg command) from the latest possible kernel.

Created attachment 66783 [details]
Dmesg outout

Created attachment 66784 [details]
Screen 1

Created attachment 66785 [details]
Screen 2

This flickering is very strong when I move a window. Some interference can be seen when I move mouse. Screen is stable when nothing changes in screen.

Does it work if you boot with video=TV-1:d in kernel command line?

This kernel option reduced interference.

At 1024x768:
- no interference when the screen changes
- occasionally the screen trembles quickly at 10 seconds interval
- leftmost part of the screen shows in the right side 

At 1920x1080
- moving a window causes snow
- constant quick trembling at 10 seconds interval
- horizontally the screen is ok

In both cases
- bottom of the screen is missing
- vertically the screen seems to be off position about on line down. For example in menus mouse pointer selects the item below.

Do you use xorg.conf? If yes, please remove it and recheck.
Periodical flickering might disappear with drm_kms_helper.poll=0 in kernel command line.

After you do the above, please attach:
- new dmesg
- Xorg.0.log
- vbios (see http://nouveau.freedesktop.org/wiki/DumpingVideoBios - nouveau wiki is unavailable today, but you can find old copy of this page on archive.org / google cache)

Created attachment 66864 [details]
New dmesg output

Created attachment 66865 [details]
Xorg log

Created attachment 66866 [details]
VGA ROM

I had xorg.conf because Ubuntu display settings did not offer the correct resolution for my monitor (1920x1080). Removing it did not help. Removing polling worked. See attached photo of the monitor and notice the wrong position of the screen and difference in mouse pointer and focus.

Created attachment 66869 [details]
Photo of my monitor

Quite unlikely, but maybe you can fix it with cvt / xvidtune. 
Other than that I have no idea how to proceed. Let's CC curro.

I tried to move screen position with xvidtune but it did not allow. I took xvidtune -show in my current well working Ubuntu 10.04 setup:

"1920x1080"   148.50   1920 2008 2056 2200   1080 1084 1089 1125 +hsync +vsync

I set exactly like this in Ubuntu 12.04 modeline. Still there is a grey block above the top of the screen and missing lines at the bottom. The mouse cursor and focus does not sync. Snow when scrolling window contents and even when the mouse pointer has a waiting animation on. Horizontally the screen is fine.

Please test both resolutions with compositing disabled.

Can you see those problems on VT with both resolutions? (you can force resolution by appending video=VGA-1:WIDTHxHEIGHT on kernel command line, see http://nouveau.freedesktop.org/wiki/KernelModeSetting for details)

I was not able to get any better results. I do not expect any simple trick to get this adapter work well. I think you should get Geforce 4 and code/test yourselves. 

In the meantime, NVidia has recently released a new and final official driver version 96.43.23 for X.Org xserver versions 1.11 and 1.12. I hope Ubuntu distribution will soon include it. 
http://www.nvidia.co.uk/object/linux-display-ia32-96.43.23-driver-uk.html

I installed directly NVidia 96.43.23 driver and it works well at full resolution. It conflicts with Nouveau so I have to use "nouveau.modeset=0" in kernel boot parameters.

Your logs are from very old versions of nouveau. Does this still happen with a recent kernel (e.g. 3.13.x)?

Created attachment 93641 [details]
Photo

Created attachment 93642 [details]
Dmesg

Created attachment 93643 [details]
Xorg log

I updated to Ubuntu 13.10. Very much flickering. See attached photo and log files.

(In reply to comment #23)
> I updated to Ubuntu 13.10. Very much flickering. See attached photo and log
> files.

Is using a digital connector an option? I wouldn't be surprised if things got better if you did.

Are you manually adding the 1920x1080 modeline? Do lower resolutions work OK?

What happens if you use Marcin's old suggestion of booting with video=TV-1:d ?

There is no digital connector available. This is ten years old mother board with integrated graphic adapter :)

Adding video=TV-1:d removes most of the interference.

At 1920x1080 (monitor native resolution) there are still some odd lines here and there, moving a mouse increases interference and moving a window makes the screen very wild. I am not sure where I got this resolution, maybe from nvidia's driver.

At 1024x768 the screen is stable if mouse is not moved, moving a window causes interference, a few lines at the top of the screen are missing.

At 800x600 the screen is stable even when moving a mouse, moving a window causes some odd lines to appear.

I noticed that traffic with hard disk causes big interference! Even when nothing changes in the screen.

(In reply to comment #26)
> I noticed that traffic with hard disk causes big interference! Even when
> nothing changes in the screen.

This makes it really sound like you're having analog isolation issues. Does your VGA cable have a ferrite core on it? (Here's an image of what I'm talking about: http://image.made-in-china.com/2f1j00cSjErnoMZtkg/VGA-Computer-Monitor-Cable-with-Ferrite-Cores-Hdb15m-Hdb15m.jpg -- the things on the cable that aren't the connector itself.)

Did you not see these issues with the nvidia binary driver? That'd be very surprising...

Created attachment 93694 [details]
Photo of lines

My VGA cable has ferrites on both ends and connectors are well secured. I have not seen this problem with Windows, nvidia or vesa (not me) driver. Even now with Ubuntu 10.04 and nvidia driver the screen is perfect.

I attached a new photo. It shows horizontal lines when nothing changes in the screen contents and the hard disk is idle.

I am an embedded software programmer. I think this might have something to do with graphic adapter bus timings. Once I had an AD converter board which had periodical errors in DMA transfers when wait states were not set correctly. This graphic adapter shares memory with mother board and I guess it picks other memory bus traffic. This might not be shown if graphic adapter has an internal memory. Do you yourself have a geforce 4?

(In reply to comment #29)
> Do you yourself have a geforce 4?

I have a NV18 (GeForce4 MX 400) PCI card which shows no such issues at 1920x1200 over VGA with nouveau. Your description of the problem reads like an analog issue, which is why I went for the "do your cables suck" option :) But if the same hw doesn't show the issue with other software, clearly nouveau is at fault.

However... who knows why. Certainly bus timings are an option. Perhaps the IGP is configured a little differently than the other stuff. Unfortunately the current code to handle all that for pre-nv50 is basically a sequence of semi-random writes to semi-random places. Take a look at drivers/gpu/drm/nouveau/dispnv04/ to see what I mean.

Chances are that in order to get any movement on this issue, you will need to make a mmiotrace of the nvidia driver setting the resolution. See https://wiki.ubuntu.com/X/MMIOTracing for how to do that. With trace in hand, one could then try to match it up with what dispnv04 does. Good times...

Created attachment 93765 [details]
Mmiotrace

I tried to get mmiotrace log file. I had to manually stop generating it after it was 400 megs long. It seems to be almost full of consecutive memory writes. I copied some lines from it to an attachment. Hopefully these lines are useful.

Maybe nvidia people are now willing to help...

On the off chance that this hardware still lives, can you try the patch in https://bugs.freedesktop.org/attachment.cgi?id=119726

That should divide the clock on NV1F by 1000. There are other differences from xf86-video-nv in the arb calculation logic, but let's start small :)

I wonder if this bug may either be related to, or may actually be the same as, bug 61537. I also have this same issue with a PC using an nVidia GeForce 4 MX IGP, and I know that the monitor attached to it has a bad EDID. I suspect Vesa may also have a monitor with a bad EDID; that would explain why his monitor's resolution was not correctly detected by Xorg (see comment #12).

I applied the above patch to Linux 4.4.11 sources, recompiled my kernel, and rebooted. The problem is not completely fixed, but it is noticeably improved. Whereas before the whole screen would intermittently jump, now there are simply random flashes of horizontal lines on random places on the screen. I generally run this box as a light-duty server, so I mainly ssh into it from my desktop, and I didn't boot into a GUI for testing. I just booted it and observed the text console.

I wouldn't consider this patch a fix, but it is perhaps a mitigation. In any case, since I suspect that this may actually be the same as bug 61537, it would probably be wise to discuss with other devs, per Martin Peres' comment, before submitting any changes to the tree.

(In reply to Patrick McMunn from comment #34)
> I wonder if this bug may either be related to, or may actually be the same
> as, bug 61537. I also have this same issue with a PC using an nVidia GeForce
> 4 MX IGP, and I know that the monitor attached to it has a bad EDID. I
> suspect Vesa may also have a monitor with a bad EDID; that would explain why
> his monitor's resolution was not correctly detected by Xorg (see comment
> #12).
> 
> I applied the above patch to Linux 4.4.11 sources, recompiled my kernel, and
> rebooted. The problem is not completely fixed, but it is noticeably
> improved. Whereas before the whole screen would intermittently jump, now
> there are simply random flashes of horizontal lines on random places on the
> screen. I generally run this box as a light-duty server, so I mainly ssh
> into it from my desktop, and I didn't boot into a GUI for testing. I just
> booted it and observed the text console.
> 
> I wouldn't consider this patch a fix, but it is perhaps a mitigation. In any
> case, since I suspect that this may actually be the same as bug 61537, it
> would probably be wise to discuss with other devs, per Martin Peres'
> comment, before submitting any changes to the tree.

Thanks for testing. The other bug you reference is on very different hardware (G80+) which has an *entirely* different display unit. The patch I wrote was based on a few observations of the old xf86-video-nv code compared to nouveau. There were other differences, but those seemed like the biggest ones.

Sounds like some of the other ones still matter though if you're still seeing flickering.

-- 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/28.