Bugzilla – Bug 1219546
[Build 50.1][ xen-pv] switch from console to x11 failed
Last modified: 2024-06-26 21:10:27 UTC
## Observation openQA test in scenario sle-15-SP6-Online-x86_64-extra_tests_gnome@svirt-xen-pv fails in [x11_setup](https://openqa.suse.de/tests/13432306/modules/x11_setup/steps/6) ## Test suite description Maintainer: QE Core, asmorodskyi. Extra tests which were designed to run on gnome , VNC_STALL_THRESHOLD is needed for xen svirt to don't turn off the scrreen after default 4 sec New version of extra_tests_on_gnome for yaml scheduling ## Reproducible Fails since (at least) Build [44.1](https://openqa.suse.de/tests/13003969) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=svirt-xen-pv&test=extra_tests_gnome&version=15-SP6)
I can get many trace log in serial terminal. https://openqa.suse.de/tests/13432306#step/x11_setup/98 Please see attached file
Created attachment 872439 [details] serial log
Richard, do we have a workaround?
(In reply to Radoslav Tzvetkov from comment #3) > Richard, do we have a workaround? Hmm, I tried to login the vnc console via debug mode, and send `ctrl-alt-f7` hot key to switch x11 console. 1. Switch failed and only a part of x11 window show [please see pic1] 2. Slide the mouse will produce a ghost shadow [please see pic2] 3l Seems mouse click can be a workaround here [please see pic3]
Created attachment 872485 [details] pic1
Created attachment 872486 [details] pic2
Created attachment 872487 [details] pic3
The system journal shows mesa is trying to load zink and failed. I think zink is not supposed to be used on this arch? Could this be a mesa or llvm problem? @Richard Could you login to the desktop in debug mode, and then run glxinfo and get the output? Thanks!
On my VM, GNOME Shell cannot start with zink, is zink expected to be used on xen?
Also, could you try write `MESA_LOADER_DRIVER_OVERRIDE=llvmpipe` to /etc/environment` and restart?
https://gitlab.gnome.org/GNOME/mutter/-/issues/3302 Send an upstream issue, I am afraid it is hard for them to reproduce it with a Xen VM.
I've setup Xen hvm locally with fedora and tumbleweed, none of those can reproduce this. Is this only reproducible on Xen pv or SLES? Do we have testcases for Xen hvm?
This seems only happens when `modesettings` is not usable for Xorg and `fbdev` is used. Xen PV does not have `/dev/dri`, so it will always use `fbdev`. I can reproduce this after running `sudo mv /usr/lib64/xorg/modules/drivers/modesetting_drv.so /usr/lib64/xorg/modules/drivers/modesetting_drv.so.back` on a KVM Guest.
For openSUSE Leap 15.3, I also need to set QEMU Video to `Ramfb` instead of `Virtio` to use `fbdev`. And this bug cannot be reproduced on Leap 15.3.
This does not happen with Plasma (x11) on Tumbleweed, so it is not a X server issue but a mutter issue.
I did a complex bisect between 41.0 and 45.3, it is very complex because I need to build version matched mutter, gnome-shell and maybe other dependencies (gsettings-desktop-schemas, libnma, ...). The bad commit is <https://gitlab.gnome.org/GNOME/mutter/-/commit/703bbe0e99dbb688352e0bff396e5cbf2c6af45b>, revert it fixed this. I'd like to test it on Tumbleweed or SLE, but OBS currently is in maintenance mode.
Revert https://gitlab.gnome.org/GNOME/mutter/-/commit/703bbe0e99dbb688352e0bff396e5cbf2c6af45b fixes this for both Tumbleweed and SLE, I'll make a SR tomorrow. I'm also working with upstream to find a real fix.
https://build.opensuse.org/request/show/1158156 https://build.opensuse.org/request/show/1158155
OpenQA test passes with this patch: https://openqa.suse.de/tests/13809126#step/x11_setup/4 https://build.suse.de/request/show/324209 For SUSE:SLE-15-SP6:GA
Patch merged, should be fine to close this.