|Summary:||[NVAC] Flickering screen on 1920x1080 monitor with 9400M in MacbookPro 5,5|
|Product:||xorg||Reporter:||Nils Alex <nils>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Nils Alex 2015-01-10 15:47:15 UTC
Created attachment 112063 [details] dmesg without drm.debug I'm using nouveau from the git kernel to drive the GeForce 9400M, the only graphics adapter in my MacbookPro 5,5. My Dell U2312HM monitor (1920x1080@60, attached via DisplayPort -> DisplayPort cable) won't show a static picture, moving pictures make the flickering even worse. The problem still stands in the highest pstate level and with only the DisplayPort as active output. I also tried a DisplayPort -> VGA adapter and got the same result. Included two dmesg: 1) Without drm.debug 2) With drm.debug=0xf, flooded
Comment 1 Nils Alex 2015-01-10 15:49:00 UTC
Created attachment 112064 [details] dmesg with drm.debug
Comment 2 Pierre Moreau 2015-01-12 12:11:04 UTC
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.
Comment 3 Pierre Moreau 2015-01-24 20:14:46 UTC
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.
Comment 4 Pierre Moreau 2015-09-03 23:24:53 UTC
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.
Comment 5 mbazzinotti 2017-12-18 18:24:55 UTC
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.
Comment 7 mbazzinotti 2017-12-18 18:29:34 UTC
Created attachment 136255 [details] Bazz `xrandr` output
Comment 8 mbazzinotti 2017-12-21 19:54:56 UTC
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.
Comment 9 mbazzinotti 2017-12-21 20:13:01 UTC
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.
Comment 10 mbazzinotti 2017-12-22 03:20:14 UTC
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.
Comment 11 mbazzinotti 2017-12-22 03:27:44 UTC
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.
Comment 12 mbazzinotti 2017-12-22 16:42:36 UTC
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.
Comment 13 Martin Peres 2019-12-04 08:54:42 UTC
-- 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.