On Linux 4.10, after waking monitors up from powersave mode, X displays only a black screen with a movable cursor on all three monitors. Linux 4.9.11 does not exhibit this issue.
I initially noticed the issue with a triple-monitor setup, but it still occurs even if only one monitor is plugged in via HDMI.
I've bisected the issue to the following atomic-mode-setting commit (full git bisect log attached):
Author: Ben Skeggs <email@example.com>
Date: Fri Nov 4 17:20:36 2016 +1000
drm/nouveau/kms/nv50: transition to atomic interfaces internally
This commit implements the atomic commit interfaces, and implements the
legacy modeset and page flipping interfaces on top of them.
There's two major changes in behavior from before:
- We're now making use of interlocks between core and satellite EVO
channels, which greatly improves our ability to keep their states
- DPMS is now implemented as a full modeset to either tear down the
entire pipe (or bring it back up). This choice was made mostly
to ease the initial implementation, but I'm also not sure what we
gain by bring backing the old behaviour. We shall see.
This does NOT currently expose the atomic ioctl by default, due to
limited testing having been performed.
Signed-off-by: Ben Skeggs <firstname.lastname@example.org>
Dmesgs and Xorg logs will be provided for the following configurations that exhibit the issue:
- 4.10, with one monitor attached
- 4.10, with three monitors attached
- A bisected revision that displays the issue (seems to have a bit more information)
I'm using an MSI GTX 770 2GB; vbios will be attached.
Created attachment 129871 [details]
problematic dmesg with three monitors on Linux 4.10
*** Bug 99921 has been marked as a duplicate of this bug. ***
Created attachment 129872 [details]
problematic xorg log on 4.10 with three monitors
(Apologies for the email spam; I'm new to bugzilla. I'll refrain from posting any more attachments to avoid more spam. If you need the vbios/other dmesgs or Xorg logs, just ask.)
Are you able to try with xf86-video-modesetting instead of the nouveau 2d driver and report if the issue still occurs?
Created attachment 129896 [details]
Normal Xorg logs on Linux 4.10 with xf86-video-modesetting
Interestingly, the bug does not appear with the generic modesetting driver! I've attached the Xorg log, but it seems normal.
(In reply to kevin from comment #5)
> Created attachment 129896 [details]
> Normal Xorg logs on Linux 4.10 with xf86-video-modesetting
> Interestingly, the bug does not appear with the generic modesetting driver!
> I've attached the Xorg log, but it seems normal.
Yeah, the nouveau 2D driver doesn't handle page flips failing correctly for some reason (this can happen under atomic when DPMS is set to a power-saving mode).
I wasn't able to reproduce this with the nouveau DDX running in its (default) DRI2 mode, only DRI3, so I hadn't prioritized looking into it.
I can confirm this problem. I'm using nouveau on a "NVIDIA Corporation GT200b [GeForce GTX 285]" GPU. I'm not using DRI3 either:
$ grep DRI /var/log/Xorg.0.log
[ 14.197] (==) NOUVEAU(0): Allowed maximum DRI level 2.
[ 14.350] (==) NOUVEAU(G0): Allowed maximum DRI level 2.
[ 14.426] (II) NOUVEAU(G0): [DRI2] Setup complete
[ 14.426] (II) NOUVEAU(G0): [DRI2] DRI driver: nouveau
[ 14.426] (II) NOUVEAU(G0): [DRI2] VDPAU driver: nouveau
[ 14.443] (II) NOUVEAU(0): [DRI2] Setup complete
[ 14.443] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau
[ 14.443] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau
[ 14.598] (II) GLX: Initialized DRI2 GL provider for screen 0
$ LIBGL_DEBUG=verbose glxinfo 2>&1 | grep DRI
libGL: Using DRI2 for screen 0
*** Bug 100025 has been marked as a duplicate of this bug. ***
(In reply to Ben Skeggs from comment #6)
> (In reply to kevin from comment #5)
> > Created attachment 129896 [details]
> > Normal Xorg logs on Linux 4.10 with xf86-video-modesetting
> > Interestingly, the bug does not appear with the generic modesetting driver!
> > I've attached the Xorg log, but it seems normal.
> Yeah, the nouveau 2D driver doesn't handle page flips failing correctly for
> some reason (this can happen under atomic when DPMS is set to a power-saving
> I wasn't able to reproduce this with the nouveau DDX running in its
> (default) DRI2 mode, only DRI3, so I hadn't prioritized looking into it.
Lyude has posted a patch which should address this issue.
The patch indeed fixes this issue! The monitors go to sleep and wake up without problems.
I can also confirm that the patch fixes the problem.
I can also confirm that the DPMS problem with kernel 4.10.x is gone after installing xorg-x11-drv-nouveau-1.0.14-1.fc25.x86_64.
1.0.14 includes the patch: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/log/?id=b71de83b7fae0abeb311251e6144294d319062cf
I had the same issue on an Intel-based system. I managed to overcome it by changing the BIOS video settings from PEG to IGD. I have to use the on-board video to see the BIOS bootup screen, but once Linux takes over, both of my monitors work fine.
I see this regularly on a system with
Kubuntu 17.10 (that is linux 4.13.x)
Nvidia G84GL [Quadro FX 570]
Xserver xserver-xorg-video-nouveau 1.0.15
so the issue does not seem to be solved yet.
When the power management kicks in and the screen dims, it is then impossible to get back to work. Ideally, by moving the mouse you should get the screenlock screen and the possibility to enter a password to disable the lock. In fact, you only get a black screen with a moving cursor.
(In reply to sergio.callegari from comment #14)
> I see this regularly on a system with
> Kubuntu 17.10 (that is linux 4.13.x)
> Nvidia G84GL [Quadro FX 570]
> Xserver xserver-xorg-video-nouveau 1.0.15
That's a contradiction in terms. This bug was for a GK104. You have a G84.
Have you gone through all the diagnostic stages that the OP went through and you've found the same thing? Seems highly unlikely. Even if it's true, it's still a different bug.