entering gnome lockscreen causes astfb displays to hang

[dann frazier]

When I install ubuntu-desktop on servers with an AMI BMC, I find a remote desktop running on the BMC's virtual KVM display hangs when I transition to the lock screen. The screen either goes blank and fails to wake up on keyboard/mouse input - or the lock screen appears but freezes, leaving the clock display frozen in time.

Correlated with the issue are the following messages in /var/log/syslog, which are emitted when I move the mouse cursor while the lock screen is frozen:

Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument

A commonality of these systems is that they use the astfb driver.

I've found that this issue follows the kernel version. If I run a jammy desktop with jammy's 5.15 kernel, this issue occurs. If I downgrade just the kernel back to focal's 5.4, the issue vanishes.

[dann frazier (dannf)]

I found that this issue also impacts upstream kernels, so I bisected and found that the problem was introduced in this commit:

commit d6ddbd5c97d1b9156646ac5c42b8851edd664ee2
Author: Thomas Zimmermann <email address hidden>
Date: Thu May 7 11:06:40 2020 +0200

    drm/ast: Don't check new mode if CRTC is being disabled

I verified that this issue can still be reproduced with current upstream (currently between v5.16 & v5.17-rc1), and that reverting the above patch[*] causes it to go away.

[*] The patch doesn't cleanly revert because the underlying code has evolved a bit, but it's straightforward to back out:

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 956c8982192b..336c545c46f5 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1012,9 +1012,6 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc,
        const struct drm_format_info *format;
        bool succ;

- if (!crtc_state->enable)
- return 0; /* no mode checks if CRTC is being disabled */
-
        ast_state = to_ast_crtc_state(crtc_state);

        format = ast_state->format;

[Daniel van Vugt (vanvugt)]

While waiting for a kernel fix, this workaround might avoid it:

  MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0

in /etc/environment

[dann frazier (dannf)]

On Thu, Jan 20, 2022 at 7:30 PM Daniel van Vugt
<email address hidden> wrote:
>
> While waiting for a kernel fix, this workaround might avoid it:
>
> MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0
>
> in /etc/environment

Thanks Daniel! Strangely though, that causes gdm to only show a
background, so I'm unable to login to test it. See the attached
screenshot. Personally I don't require a workaround - this is just
something I ran into while debugging a different issue for a user - so
no need to spend time finding one on my behalf.

[dann frazier (dannf)]

Forwarded upstream: https://www.spinics.net/lists/dri-devel/msg330115.html