Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1936991

Summary: Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Product: [Fedora] Fedora Reporter: Paul Whalen <pwhalen>
Component: mutterAssignee: Florian Müllner <fmuellner>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: awilliam, fmuellner, gnome-sig, Hi-Angel, jadahl, kherbst, kwizart, otaylor, philip.wyett, robatino, walters
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: mutter-40.0~beta-2.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2001010 (view as bug list) Environment:
Last Closed: 2021-03-12 01:36:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1829022, 2001010    
Attachments:
Description Flags
journalctl output
none
MUTTER_DEBUG added
none
MUTTER_DEBUG_ENABLE_ATOMIC_KMS added none

Description Paul Whalen 2021-03-09 16:03:32 UTC
Description of problem:

Attempting to boot F34 Workstation on a Jetson Nano, the system boots to the F34 wallpaper briefly before displaying the "Oops" screen with initial-setup on top (BZ#1924908) but no visible pointer. Once the mouse is moved:

Mar 09 10:53:11 nano gnome-shell[1158]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Mar 09 10:53:11 nano gnome-shell[1158]: Page flip discarded: drmModeAtomicCommit: Invalid argument

Mar 09 10:55:08 nano gnome-session-f[1616]: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node headerbar, owner GtkHeaderBar)
Mar 09 10:55:08 nano gnome-session-f[1616]: gtk_widget_size_allocate(): attempt to allocate widget with width -34 and height 18
Mar 09 10:55:08 nano gnome-session-f[1616]: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node label, owner GtkLabel)
Mar 09 10:55:08 nano gnome-session-f[1616]: gtk_widget_size_allocate(): attempt to allocate widget with width -39 and height 0
Mar 09 10:55:08 nano /usr/libexec/gdm-wayland-session[1616]: *** BUG ***
Mar 09 10:55:08 nano /usr/libexec/gdm-wayland-session[1616]: In pixman_region32_init_rect: Invalid rectangle passed
Mar 09 10:55:08 nano /usr/libexec/gdm-wayland-session[1616]: Set a breakpoint on '_pixman_log_error' to debug

Followed by a black screen with flashing cursor. 


Version-Release number of selected component (if applicable):

gnome-shell-40.0~beta-1.fc34.aarch64
kernel-5.11.3-300.fc34.aarch64
mesa-21.0.0~rc5-3.fc34

How reproducible:
Everytime.

Comment 1 Paul Whalen 2021-03-09 16:04:15 UTC
Created attachment 1762021 [details]
journalctl output

Comment 2 Adam Williamson 2021-03-09 17:21:04 UTC
Well, if we took the crash as a blocker, it seems like logically speaking this ought to be a blocker too. Sounds like GNOME is still not at all usable on a target platform, right?

Comment 3 Jonas Ådahl 2021-03-09 17:25:44 UTC
Could you try two things:

Run with 

MUTTER_DEBUG=kms

in the environment, and attach the whole log from gnome-shell.

Then add

MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0

to the environment again, and try again.

Comment 4 Paul Whalen 2021-03-09 18:30:16 UTC
Created attachment 1762067 [details]
MUTTER_DEBUG added

Comment 5 Paul Whalen 2021-03-09 18:30:58 UTC
Created attachment 1762068 [details]
MUTTER_DEBUG_ENABLE_ATOMIC_KMS added

Comment 6 Paul Whalen 2021-03-09 18:32:01 UTC
After adding MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0, the pointer is visible on screen and the system is usable.

Comment 7 Jonas Ådahl 2021-03-09 18:36:47 UTC
Does adding

DRIVER=="tegra", SUBSYSTEM=="platform", TAG+="mutter-device-requires-kms-modifiers"

to

/usr/lib/udev/rules.d/61-mutter.rules

then removing

MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0

from the env, then rebooting, help?

> After adding MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0, the pointer is visible on screen and the system is usable.

At least a work around is available at our hands then, the issue is when using atomic mode setting.

Comment 8 Paul Whalen 2021-03-09 18:57:08 UTC
(In reply to Jonas Ådahl from comment #7)
> Does adding
> 
> DRIVER=="tegra", SUBSYSTEM=="platform",
> TAG+="mutter-device-requires-kms-modifiers"
> 
> to
> 
> /usr/lib/udev/rules.d/61-mutter.rules
> 
> then removing
> 
> MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0
> 
> from the env, then rebooting, help?

The pointer was no longer visible with those changes. 

> 
> > After adding MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0, the pointer is visible on screen and the system is usable.
> 
> At least a work around is available at our hands then, the issue is when
> using atomic mode setting.

There is quite a bit of graphical flashing, but its definitely a usable workaround.

Comment 9 Jonas Ådahl 2021-03-09 19:24:59 UTC
> There is quite a bit of graphical flashing, but its definitely a usable workaround.

Are you saying that with MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 there is still graphical flashing? What kind of flashing is this?

Comment 10 Paul Whalen 2021-03-09 19:58:20 UTC
(In reply to Jonas Ådahl from comment #9)
> > There is quite a bit of graphical flashing, but its definitely a usable workaround.
> 
> Are you saying that with MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 there is still
> graphical flashing? What kind of flashing is this?

Yes, even with MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0, windows still flash semitransparent when moved or opened.

Comment 11 Karol Herbst 2021-03-09 20:09:46 UTC
(In reply to Jonas Ådahl from comment #9)
> > There is quite a bit of graphical flashing, but its definitely a usable workaround.
> 
> Are you saying that with MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 there is still
> graphical flashing? What kind of flashing is this?

That's probably a long outstanding bug on either tegradrms or nouveaus side. I have no good idea on how to fix it. And tagr proposed a solution which changes nouveaus UAPI. Still working on it, but super sure that no solution will be ready for fedora 34.

Comment 12 Nicolas Chauvet (kwizart) 2021-03-09 22:24:53 UTC
(In reply to Jonas Ådahl from comment #9)
 > There is quite a bit of graphical flashing, but its definitely a usable workaround.
I wonder if tearing could be fixed by this serie on tegra:
http://patchwork.ozlabs.org/project/linux-tegra/patch/20210302124445.29444-2-digetx@gmail.com/

This relies upon interconnect changes, so that's too much to backport for 5.11 and f34 GA, but probably doable for 5.12 if the serie is good for 5.13-rc1.
Using the grate-driver kernel on jetson-tk1 (armhfp), I'm not experiencing any tearing at all (so maybe others WIP/pending patches are also needed).

Comment 13 Adam Williamson 2021-03-09 22:40:33 UTC
so can we at least come up with a udev rules equivalent of the MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 workaround today? This is the last thing blocking a Beta compose at present.

Comment 14 Adam Williamson 2021-03-09 23:10:56 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/294 , marking accepted.

Comment 15 Fedora Update System 2021-03-10 02:29:36 UTC
FEDORA-2021-7ff726a721 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ff726a721

Comment 16 Nicolas Chauvet (kwizart) 2021-03-10 08:37:12 UTC
I confirm that the update discard the "drmModeAtomicCommit: Invalid argument" message, but it also doesn't fix any issue for me (using jetson-tk1, so different device and arch).

I've filled two separate issues, that might or might not be related:

1/ Using fedora kernel, there is a nouveau page fault on armhfp
https://bugzilla.redhat.com/show_bug.cgi?id=1937129

2/ Using a patched kernel (linux-next + WIP tegra patches from grate):
It cannot use the GPU acceleration and fall back to nouveau.
https://bugzilla.redhat.com/show_bug.cgi?id=1937236

I wonder if any on theses can be reproduced on nano or other jetson aarch64 boards...

Comment 17 Karol Herbst 2021-03-10 11:13:22 UTC
(In reply to Nicolas Chauvet (kwizart) from comment #12)
> (In reply to Jonas Ådahl from comment #9)
>  > There is quite a bit of graphical flashing, but its definitely a usable
> workaround.
> I wonder if tearing could be fixed by this serie on tegra:
> http://patchwork.ozlabs.org/project/linux-tegra/patch/20210302124445.29444-2-
> digetx/
> 
> This relies upon interconnect changes, so that's too much to backport for
> 5.11 and f34 GA, but probably doable for 5.12 if the serie is good for
> 5.13-rc1.
> Using the grate-driver kernel on jetson-tk1 (armhfp), I'm not experiencing
> any tearing at all (so maybe others WIP/pending patches are also needed).

ohh, nice pointing that out. This might indeed explain why it only happens on low bandwidth boards... will try that out on my jetson nano as well. Thanks!

Comment 18 Adam Williamson 2021-03-10 17:17:26 UTC
Nicolas: the update basically does the same thing as MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 for all systems using the "tegra" driver. The idea was to get Jetson boards to the state described by Paul when using that parameter (usable with visible cursor). If it does that and doesn't make things any *worse than they already are* on other Tegra platforms, it's doing its job.

jetson-tk1 is 32-bit, right? If so, we don't block on anything desktop-y on it for F34, AIUI.

Comment 19 Fedora Update System 2021-03-10 18:51:50 UTC
FEDORA-2021-7ff726a721 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-7ff726a721`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ff726a721

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 20 Fedora Update System 2021-03-12 01:36:18 UTC
FEDORA-2021-7ff726a721 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.