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: | mutter | Assignee: | Florian Müllner <fmuellner> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 34 | CC: | 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: | 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 | ||||||||||
Attachments: |
|
Description
Paul Whalen
2021-03-09 16:03:32 UTC
Created attachment 1762021 [details]
journalctl output
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? 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. Created attachment 1762067 [details]
MUTTER_DEBUG added
Created attachment 1762068 [details]
MUTTER_DEBUG_ENABLE_ATOMIC_KMS added
After adding MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0, the pointer is visible on screen and the system is usable. 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.
(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. > 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?
(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. (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. (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). 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. +3 in https://pagure.io/fedora-qa/blocker-review/issue/294 , marking accepted. FEDORA-2021-7ff726a721 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ff726a721 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... (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! 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. 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. 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. |