Bug 99922 - [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor after monitors turn off
Summary: [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: bisected
: 99921 100025 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-02-23 14:28 UTC by Kevin Liu
Modified: 2017-10-31 22:24 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Attachments
problematic dmesg with three monitors on Linux 4.10 (111.02 KB, text/plain)
2017-02-23 14:29 UTC, Kevin Liu 		no flags Details
problematic xorg log on 4.10 with three monitors (48.23 KB, text/plain)
2017-02-23 14:33 UTC, Kevin Liu 		no flags Details
Normal Xorg logs on Linux 4.10 with xf86-video-modesetting (56.35 KB, text/plain)
2017-02-24 12:38 UTC, Kevin Liu 		no flags Details
View All

Description Kevin Liu 2017-02-23 14:28:52 UTC 
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):

commit 839ca903f12ef8f09374e0b655456482536a733e
Author: Ben Skeggs <bskeggs@redhat.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
      synchronised.
    - 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 <bskeggs@redhat.com>

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.
Comment 1 Kevin Liu 2017-02-23 14:29:38 UTC 
Created attachment 129871 [details]
problematic dmesg with three monitors on Linux 4.10
Comment 2 Kevin Liu 2017-02-23 14:32:20 UTC 
*** Bug 99921 has been marked as a duplicate of this bug. ***
Comment 3 Kevin Liu 2017-02-23 14:33:59 UTC 
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.)
Comment 4 Ben Skeggs 2017-02-24 01:35:59 UTC 
Are you able to try with xf86-video-modesetting instead of the nouveau 2d driver and report if the issue still occurs?
Comment 5 Kevin Liu 2017-02-24 12:38:37 UTC 
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.
Comment 6 Ben Skeggs 2017-02-25 05:03:10 UTC 
(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.
Comment 7 bastian.beischer 2017-02-27 12:43:22 UTC 
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
Comment 8 tkoenig 2017-03-01 19:20:03 UTC 
*** Bug 100025 has been marked as a duplicate of this bug. ***
Comment 9 Ben Skeggs 2017-03-04 07:38:36 UTC 
(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
> 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.

Lyude has posted a patch[1] which should address this issue.

Ben.

[1] https://lists.freedesktop.org/archives/nouveau/2017-March/027422.html
Comment 10 Kevin Liu 2017-03-06 23:21:25 UTC 
The patch indeed fixes this issue! The monitors go to sleep and wake up without problems.
Comment 11 bastian.beischer 2017-03-06 23:23:11 UTC 
I can also confirm that the patch fixes the problem.
Comment 12 Stefan Becker 2017-04-16 17:45:37 UTC 
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
Comment 13 mish 2017-04-24 00:06:15 UTC 
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.
Comment 14 sergio.callegari 2017-10-31 22:21:00 UTC 
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.
Comment 15 Ilia Mirkin 2017-10-31 22:24:43 UTC 
(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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.