Created attachment 112064 [details]
dmesg with drm.debug

I wasn't enable to reproduce it, as the external screen receives absolutely no signals from the card (though it works with the blob).

So I'll try to hack mine to get it to a working state, and hopefully it will solve your flickering.

Tried again using an mDP -> HDMI adapter and I was able to reproduce it.

Level 03 and 05 give some weird display no matter what.
Level 0e and 0f display the desktop without flickering; it starts flickering when running glxgears though.

I'll try to quickly solve some another bug and then come back to this one.

I managed to solve the other bug (notice how quick it was... --"), so back to this one. :)

There was a regression that happened between 4.2 and current HEAD, so I'm tracking it down but I should have it by tomorrow. Otherwise, running 4.2 or 3.19, I experience something else than what I reported in my last comment.

Using a mDP -> HDMI (I'm not sure whether this one is active or not; I have both, so I could try both):
- Desktop displays fine, even while running glxgears on levels 05 to 0f;
- Weird display on level 03 but I guess some clock is just too low, as even the blob uses at least level 05 or even 0e;
- LVDS screen starts flickering after turning off the external screen using `xrandr --output DP-2 --off`.

Using a mDP -> VGA:
- Screen receives a signal but stays blank.

Created attachment 136253 [details]
Bazz dmesg

On similar hardware, I am experiencing this display flicker with nouveau.

Macbook Pro 5,4 15" mid-2009
Nvidia GeForce 9400m
mini DisplayPort -> "Gigaware" DVI/HDMI/Displayport adapter -> using DVI port
 on the monitor.

--------
Software|
--------
Gentoo Linux 4.9.49 and 4.12.12. I recall this issue dating back to my use of
 3.18.11.
x11-base/xorg-server-1.19.5
x11-drivers/xf86-video-nouveau-1.0.15
No compositor
I've tested under XFCE4 or i3, the problem is the same.

kernel command line: ro root=PARTUUID=xxxxxxxx net.ifnames=0

-----------
Attachments|
-----------
bazz-dmesg.txt (dmesg command dump)
bazz-xrandr.txt (xrandr output)
bazz-vbios.rom

------
Issues|
------
1) intermittent flickering on the 2nd monitor.
2) If unplugging the mDP cable, the LVDS may flicker and the system appears
locked up (I cannot "blind" navigate to VT to reboot, like I usually do in
other circumstances). However, replugging the mDP cable will cease LVDS
flicker, although the system is still apparently rendered inoperable.

These problems do not occur when using the legacy nvidia-drivers (340.104).

Issue 1 is also experienced when booting to Virtual Terminal (VT) without
starting X. I have not experimented for Issue 2 on VT-only yet.

The DVI monitor is "usable" but experiences mild flicker and other times frequent
flickering. It can appear stable for 30 seconds to a couple minutes at a time,
only to have flickering return.

--------------------------------
Commandline / Module Parameters |
--------------------------------
I played around with the following parameters.

drm_kms_helper.poll=0
noveau atomic, mst, runpm.

Playing with those settings have not made visible changes to the problem.

------
pstate|
------
`cat /sys/kernel/debug/dri/0/pstate`
03: core 125 MHz shader 250 MHz vdec 125 MHz
05: core 150 MHz shader 300 MHz vdec 150 MHz
0e: core 350 MHz shader 800 MHz vdec 350 MHz AC DC *
0f: core 450 MHz shader 1100 MHz vdec 450 MHz
AC: core 350 MHz shader 800 MHz vdec 350 MHz

pstate 03, 05 produce incredible constant flicker on the 2nd monitor.
pstate 0e, 0f produce intermittent flickering I've always been experiencing.

Created attachment 136254 [details]
Bazz vbios

Created attachment 136255 [details]
Bazz `xrandr` output

Created attachment 136348 [details]
nvidia demmio-trace MARKing important points in the monitor attach sequence

Todo
---- 
Use this trace log and compare with nouveau source code or (the not yet provided) Nouveau trace to identify the distinction of nvidia blob providing flicker free display. Then, incorporate those changes to nouveau in a way that is unhindering to its present operation.

- INFO -

I had mmiotrace start at the point when my service "local" modprobes the nvidia driver.

You can search with string "MARK" or "bazz" to see where I've marked the different transition points.

I marked the following points: modprobe to VT, VT to X, plugin mDP adapter, activate screen via xrandr, deactivate via xrandr, and unplug mDP cable.

This log was processed with envytools rnn/demmio (https://github.com/envytools/envytools) and compressed by xz to a 4MB file. You could use `xzcat | less` to view it. The file is Ansi color coded so make sure you're able to reap those reading benefits. The bootup and startx parts of the log are likely extraneous but kept for posterity. 

I still have the original mmiotrace log if necessary.

mmiotrace picks up other devices that are iomap'd throughout this recording. demmio seems to have truncated or removed those details.

Created attachment 136349 [details]
nvidia raw mmiotrace (no demmio output)

here is the raw mmiotrace of the previously uploaded demmio output. See previous comment for further details pertaining to how to read and search this file's trace points.

This file is slightly bigger because it includes the other iomap accesses that demmio truncated. I left these included as I am unsure whether they will be needed.

Created attachment 136357 [details]
nouveau demmio-trace MARKed

see the related nvidia-blob (de)mmio attachments comments for more details. these are just the nouveau versions of the same kind of files.

Created attachment 136358 [details]
nouveau raw mmiotrace with trace MARK

When asking in #nouveau for some leads on related source code points:

pmoreau:
https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c and https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/disp/

Was the 2nd link meant to point to nv_50_display.c?

imirkin_: the other option is subdev/fb

I don't know how nv_50 was derived from the geforce 9400m.

I've got great news! I believe certain members of #nouveau and I have found a fix!

`config=NvForcePost=1`

append appropriately to your modprobe statement or use `nouveau.config=NvForcePost=1` in your kernel cmdline!

I will use this setting longer and report back on its effectiveness at a later date.

== Background Story ==

I noticed that screen flicker problems disappeared after waking from a `pm-suspend`. After reporting this to #nouveau, some more light was shed. see the following IRC snippet (more @ https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2017-12-22)

-- snip --
(regarding why pm-suspend solves the flicker bug)
15:58 imirkin: on resume we run the vbios scripts 
15:58 imirkin: on boot, we probably don't because the vbios already has

16:02 imirkin: but it could be that the interpreter skimps on DP support and so some bits don't run 
16:02 imirkin: or it could be something else entirely 
-- end --

== Tests ==

I have tested this new config option under the following scenarios

1) Boot with mDP adapter plugged in. OK
2) Boot without mDP adapter plugged in. Then, plug in after X has started. OK

Because it works without the mDP adapter being plugged in on boot, it's safe to say that no "mDP hint" at bootup is required to get some "optional" vbios code to run. force POSTing is solving the problem, but we don't know why yet. What is happening differently from normal bootup by this force post?

Perhaps another 2 mmiotrace bootup logs would shed light on this, or someone more familiar with gpu.

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