Bug 92307

Created attachment 118693 [details]
dmesg 4.3.0-0.rc4.git0.1.fc24.x86_64+debug NV50

Tested with the latest
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63c
warnings are still occurring.

Seeing same here when 'switching off' and 'on' again hdmi display connected to a gm206

(In reply to Stefan Huehner from comment #3)
> Seeing same here when 'switching off' and 'on' again hdmi display connected
> to a gm206


Goes - both, S3 RESUME and disable/enable the output will induce these warnings, ...

$ xrandr --output DVI-I-1 --off ; xrandr --auto
$ xrandr --display :0
...
DVI-I-1 connected 1920x1080+0+0 ...
...

... with one behavioural exception - after xrandr OFF/ON routine, the mouse cursor is visible and motile, but the rest of the screen is as blanked.

Created attachment 118863 [details]
dmesg 4.3.0-0.rc5.git0.1.fc24.x86_64+debug & nouveau git on G98

$ dmesg | egrep WARNING\|kworker
[  131.880586] WARNING: CPU: 2 PID: 4017 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  131.880889] CPU: 2 PID: 4017 Comm: kworker/2:4 Tainted: G           OE   4.3.0-0.rc6.git2.1.fc24.x86_64 #1
[  131.881373] WARNING: CPU: 2 PID: 4017 at include/drm/drm_crtc.h:1577 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  131.881589] CPU: 2 PID: 4017 Comm: kworker/2:4 Tainted: G        W  OE   4.3.0-0.rc6.git2.1.fc24.x86_64 #1
[  132.578315] WARNING: CPU: 2 PID: 23 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  132.578383] CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: G        W  OE   4.3.0-0.rc6.git2.1.fc24.x86_64 #1
[  132.578517] WARNING: CPU: 2 PID: 23 at include/drm/drm_crtc.h:1577 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  132.578567] CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: G        W  OE   4.3.0-0.rc6.git2.1.fc24.x86_64 #1


$ modinfo -n nouveau
/lib/modules/4.3.0-0.rc6.git2.1.fc24.x86_64/updates/nouveau.ko


$ git log -1
commit 6b471ec900ba70fa72fddeb144fcf9ce59e80dfb
Author: Roy Spliet <rspliet@eclipso.eu>
Date:   Wed Sep 30 00:23:52 2015 +0100

    clk/g84: Enable reclocking for GDDR3 G94-G200
    
    Your milage may vary, as it's only been tested on a single G94 and one G96.
    
    Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
    Tested-by: Pierre Moreau <pierre.morrow@free.fr>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

FTR procedure:

$ uname -r
4.3.0-0.rc6.git2.1.fc24.x86_64

$ git clone git://people.freedesktop.org/~darktama/nouveau
$ cd nouveau/drm/
$ make
$ su

# cp nouveau/nouveau.ko /usr/lib/modules/$(uname -r)/updates/
# depmod
# dracut --kver $(uname -r) -f
# systemctl reboot

(In reply to poma from comment #7)
> FTR procedure:
> 
> $ uname -r
> 4.3.0-0.rc6.git2.1.fc24.x86_64
> 
> $ git clone git://people.freedesktop.org/~darktama/nouveau
> $ cd nouveau/drm/
> $ make
> $ su
> 
> # cp nouveau/nouveau.ko /usr/lib/modules/$(uname -r)/updates/
> # depmod
> # dracut --kver $(uname -r) -f
> # systemctl reboot


Update to commit f787ef9

nouveau/drm/nouveau/nouveau_drm.c:935:24: error: ‘drm_vblank_no_hw_counter’ undeclared here (not in a function)
  .get_vblank_counter = drm_vblank_no_hw_counter,
                        ^

Created attachment 119620 [details]
changes to make nouveau stop creating trace blowups

(In reply to Don O from comment #9)
> Created attachment 119620 [details]
> changes to make nouveau stop creating trace blowups


I was having the same problems as others with traces being generated by simply turning off the monitor. I found a solution by googling and realized that the radeon driver was having the same problem and the solution was simple (attached patch).

It has fixed the trace problem and the monitor turns back on and off properly.

I had this problem when I tried the 4.1.12 kernel also, so this is not just strictly 4.3 or whatever.


Note: to the comment 8 and non compile,
it needs a couple of updated *.h files in /usr/include/drm
to compile properly (doesn't fix the trace problem though)

(In reply to Don O from comment #10)
> (In reply to Don O from comment #9)
> > Created attachment 119620 [details]
> > changes to make nouveau stop creating trace blowups
> 
> 
> I was having the same problems as others with traces being generated by
> simply turning off the monitor. I found a solution by googling and realized
> that the radeon driver was having the same problem and the solution was
> simple (attached patch).
> 
> It has fixed the trace problem and the monitor turns back on and off
> properly.
> 
> I had this problem when I tried the 4.1.12 kernel also, so this is not just
> strictly 4.3 or whatever.
> 
> 
> Note: to the comment 8 and non compile,
> it needs a couple of updated *.h files in /usr/include/drm
> to compile properly (doesn't fix the trace problem though)

Sorry about this mess, I'm not used to bugzilla.
The patch is reversed (doh) but the nouveau_connector.c file needs
the drm_mode_lock_all, and unlock all wrapped around the call to
nvif_notify_init

(In reply to poma from comment #8)
> (In reply to poma from comment #7)
> > FTR procedure:
> > 
> > $ uname -r
> > 4.3.0-0.rc6.git2.1.fc24.x86_64
> > 
> > $ git clone git://people.freedesktop.org/~darktama/nouveau
> > $ cd nouveau/drm/
> > $ make
> > $ su
> > 
> > # cp nouveau/nouveau.ko /usr/lib/modules/$(uname -r)/updates/
> > # depmod
> > # dracut --kver $(uname -r) -f
> > # systemctl reboot
> 
> 
> Update to commit f787ef9
> 
> nouveau/drm/nouveau/nouveau_drm.c:935:24: error: ‘drm_vblank_no_hw_counter’
> undeclared here (not in a function)
>   .get_vblank_counter = drm_vblank_no_hw_counter,
>                         ^

It was the current compilation breakage within ~darktama/nouveau, not related to the actual bug.

Created attachment 119664 [details]
dmesg 4.4.0-0.rc0.git9.1.fc24.x86_64 connector_hotplug nvif_notify


- nouveau.ko built of:
http://cgit.freedesktop.org/~darktama/nouveau
git://people.freedesktop.org/~darktama/nouveau

- ending with:
$ git log -1
commit ad38b5e72b3acb40b820954f04293a0161e33845
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Wed Nov 11 13:06:10 2015 +1000

    WIPce/gk104: attempt at better handling of LAUNCHERR
    
    Very rough, no idea how correct it is at this point, but it prevents
    getteximage-depth from piglit from hanging the GPU.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

- patched with:
$ git diff
diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 36ec8f3..d6afbb0 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -1274,6 +1274,7 @@ nouveau_connector_create(struct drm_device *dev, int index)
                break;
        }
 
+       drm_modeset_lock_all(dev);
        ret = nvif_notify_init(&disp->disp, nouveau_connector_hotplug, true,
                               NV04_DISP_NTFY_CONN,
                               &(struct nvif_notify_conn_req_v0) {
@@ -1283,6 +1284,7 @@ nouveau_connector_create(struct drm_device *dev, int index)
                               sizeof(struct nvif_notify_conn_req_v0),
                               sizeof(struct nvif_notify_conn_rep_v0),
                               &nv_connector->hpd);
+       drm_modeset_unlock_all(dev);
        if (ret)
                connector->polled = DRM_CONNECTOR_POLL_CONNECT;
        else

Ref.
"drm/radeon: Sprinkle drm_modeset_lock_all to appease locking checks"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/radeon/radeon_device.c?id=6adaed5

Conclusion:
In this regard, it does not change anything - with or without ~darktama/nouveau update, with or without patch.

(In reply to poma from comment #13)
>...
> Conclusion:
> In this regard, it does not change anything - with or without
> ~darktama/nouveau update, with or without patch.

Do you have nouveau set up as built-in or module?

If you have it built-in then creating a module won't have any effect as the system will never use that.

$ grep -i nouveau /boot/config-4.4.0-0.rc0.git9.1.fc24.x86_64
CONFIG_DRM_NOUVEAU=m
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y


Furthermore, this one is actually loaded:

# lsinitrd --kver 4.4.0-0.rc0.git9.1.fc24.x86_64 | grep nouveau
... usr/lib/modules/4.4.0-0.rc0.git9.1.fc24.x86_64/updates/nouveau.ko

therefore "dracut --kver $(uname -r) -f" build&install step.

Tested kernels:
4.4.0-0.rc3.git0.1.fc24.x86_64+debug
&
4.4.0-0.rc3.git0.1.fc24.x86_64+debug with updated nouveau from
http://cgit.freedesktop.org/~darktama/nouveau - up to commit 115ed46

- dmesg:
[  242.712518] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  242.713194] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  243.410428] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  243.411084] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  429.026360] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  429.027127] WARNING: CPU: 2 PID: 2742 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  429.725127] WARNING: CPU: 2 PID: 308 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  429.725408] WARNING: CPU: 2 PID: 308 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  605.195250] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  605.195586] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  605.893962] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  605.894735] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  650.065838] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  650.066627] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[  650.764764] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[  650.765550] WARNING: CPU: 2 PID: 50 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[ 1258.081495] WARNING: CPU: 2 PID: 1879 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[ 1258.082210] WARNING: CPU: 2 PID: 1879 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
[ 1258.780213] WARNING: CPU: 2 PID: 1879 at include/drm/drm_crtc.h:1565 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
[ 1258.780934] WARNING: CPU: 2 PID: 1879 at include/drm/drm_crtc.h:1565 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
...

Although warnings are still here,
during S3 RESUME connected output/display -IS- enabled.

However with the xrandr routine:
xrandr --output DVI-I-1 --off ; xrandr --auto

is still problematic,
the mouse cursor is visible and motile, but the rest of the screen is as blanked.

Moreover, through the further testing I found a component that is causing the problem.
Is it the only variable in equation, dunno.

Therefore,
Xfwm4 XPresent compositor -and- GLX compositor -are problematic-
in xrandr routine - of course when they are used.

What -is NOT- problematic:
- Xfwm4 XRender compositor
- DRI 3


Related to this problem, and not only
https://bugzilla.xfce.org/show_bug.cgi?id=12339

Stefan, what DE/compositor are you running?

No compositor just old fvwm2 as window manager. For this quick test i did either just startx or via lightdm.

Note: was just quick test using blob for now and not nouveau mainly on that box.

nouveau & fvwm-2.6.5-10.fc23.x86_64,
except ever-present warnings, no problemos for both - S3 RESUME and xrandr.

Valid for all three Xfwm4 compositors:

w/
Driver "nouveau"

Option "AccelMethod" "none"
and/or
Option "NoAccel" "off"

"... xrandr --auto" zaps Xserver


w/
Driver "modesetting"

"... xrandr --auto" works OK

(In reply to poma from comment #21)
> Valid for all three Xfwm4 compositors:
> 
> w/
> Driver "nouveau"
> 
> Option "AccelMethod" "none"
> and/or
> Option "NoAccel" "off"
> 
> "... xrandr --auto" zaps Xserver
> 
> 
> w/
> Driver "modesetting"
> 
> "... xrandr --auto" works OK


Nevertheless,
SEGV catches xfdesktop and warnings are.

For comparison - valid for both:

Driver "nouveau"
and
Driver "modesetting"

"... xrandr --auto"  produces

kernel: gnome-shell[2161]: segfault at fffffffd2fd160c0 ip 00007f1bab442f05 sp 00007ffd1ec98490 error 5 in libmutter.so.0.0.0[7f1bab3b3000+fd000]
kernel: gnome-shell[6058]: segfault at fffffffdfcc2e1c0 ip 00007f36c4e25f05 sp 00007fffb16775a0 error 5 in libmutter.so.0.0.0[7f36c4d96000+fd000]

thereby terms Xorg.

Material for:
Product: 	xorg
Component: 	App/xrandr
?

There are also problemos - "xrandr --rotate ..." produced,
related to GL compositor.

When engaged, Xfwm4 GL compositor with XPresent VSync
$ XFWM4_USE_PRESENT=1 xfwm4
xrandr related problemos(--off/--auto/--rotate) start with this particular commita
"enable dri3 support without glamor"
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728

With the former commita, which works OK
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=762b22f
while "xrandr-ing", there is no warning in the kernel ring buffer, whatsoever.
Still, SEGV catches xfdesktop.

Yet with commita 762b22f, while S3 RESUME, warnings are still occurring,
very persistent, aye. :)


In contrast, when engaged, Xfwm4 GL compositor with default VSync,
xrandr related problemos(--off/--auto/--rotate) are "all the way",
at least I have tested from xf86-video-nouveau-1.0.3 up to the latest,
xf86-video-nouveau-1.0.12.
So there is no love there at all.

I wonder whether this problemo is comparable to one occurs with the clutter/mutter/gnome-shell
https://bugzilla.gnome.org/buglist.cgi?quicksearch=meta_monitor_manager_xrandr_handle_xevent
https://bugzilla.redhat.com/buglist.cgi?quicksearch=meta_monitor_manager_xrandr_handle_xevent

Have the same issue on G94, 4.4.0-rc5+ kernel. Tried the patch from comment #13, didn't help.

Commit:
"drm/nouveau/kms: take mode_config mutex in connector hotplug path"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau/nouveau_connector.c?id=0a882cad
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/drivers/gpu/drm/nouveau/nouveau_connector.c?id=0a882cad

solves only WARNING(s),
everything else is equally broken - "xrandr-ing" with GL(X) compositing.

Tested with 4.5.0-0.rc0.git3.1.fc24.x86_64

*** Bug 93733 has been marked as a duplicate of this bug. ***

*** Bug 93634 has been marked as a duplicate of this bug. ***

While GL(X) compositing,

not only that DRI3 introduces cca. 1 sec lag,
i.e. slowdown as reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=92271

but it breaks overall "xrandr --rotate ..." routine.

Tested with Latest n' Greatest on Rawhide - Xfce, GNOME and KDE.

(In reply to poma from comment #31)
> While GL(X) compositing,
> 
> not only that DRI3 introduces cca. 1 sec lag,
> i.e. slowdown as reported here:
> https://bugs.freedesktop.org/show_bug.cgi?id=92271
> 
> but it breaks overall "xrandr --rotate ..." routine.
> 
> Tested with Latest n' Greatest on Rawhide - Xfce, GNOME and KDE.


In this sense "overall" means, "xrandr-ial" rotation can easily produce unusable session screen,
and the only thing left is to zap the xserver and re-log.

(In reply to poma from comment #17)
> However with the xrandr routine:
> xrandr --output DVI-I-1 --off ; xrandr --auto
> 
> is still problematic,
...

G98: GL(X) compositing - XRandR DPMS trouble
https://bugs.freedesktop.org/show_bug.cgi?id=93795

This report was originally referred to the problem that has since been resolved,
"WARNING: ... at include/drm/drm_crtc.h:1577"

If your GPU comprises the same problem, related to GL(X) compositing and XRandR DPMS,
you can join here:
https://bugs.freedesktop.org/show_bug.cgi?id=93795

The same goes with GL(X) compositing and XRandR rotation problem,
you can join here:
https://bugs.freedesktop.org/show_bug.cgi?id=92271


Thank you for attention folks,
and thanks Ben for "WARNINGs" relief.