Bugzilla – Bug 1217748
Display corruption with spesific applications in Gnome-wayland session
Last modified: 2024-03-04 00:59:33 UTC
Created attachment 871111 [details] sudo hwinfo >hwinfo.txt (macbook 5.1 with nvidia 9400/ core2 duo. 2008 old and rare) current build: 20231129 yast-snapper gui says my oldest snapshot is 2023-11-23 After a KDE/SDDM issue I installed a base gnome with gnome-wayland session and GDM. While most of the warnings on kernel log disappeared, couple of applications are causing massive display corruption in their work windows. gnome-terminal current and kde system monitor. They even corrupt the areas of desktop when they are moved. This is a kernel/nouveau hardware issue for sure as when I use gnome screen recording/snapshot all looks fine. Gnome developers suggested me to compile a new gnome git version which includes gtk4-terminal as opposed to current one which is a gtk3 version. I found a binary ( https://build.opensuse.org/package/show/home:mantarimay:GNOME:apps/gnome-terminal ) and it is fine. I launched kde system monitor. I don't think it has anything to do with gtk3 and yet behaves same way. I am used to nouveau warnings but never seen this one: nouveau 0000:02:00.0: imem: OOM: 00100000 00001000 -2 I decided to post this bug report here as gnome-terminal from Fedora current official live USB works all fine. I have dmesg etc from it if needed. I can live without these applications however as this is a particularly rare configuration I thought I better report. I am OK with testing things.
Created attachment 871112 [details] possibly overflowed dmesg taken while corruptions happening
Created attachment 871113 [details] Screenshot of the gnome-terminal. This is the only time I could take a screenshot with glitches happening. Several others show the screen is fine, There is absolutely no transparency/hacks etc applied. I am using unmodified gnome with only additional keyboard layout. I have to add that the glitches are "animated" syncing with cursor flash.
Created attachment 871114 [details] photo of terminal (via phone) As the screenshots look fine when taken digitally, I captured photo of terminal. Terminal developers say Gnome Terminal can't display these even if it wanted to.
Created attachment 871115 [details] Different looking issue with kde system monitor This is kde system monitor. Corruption looks different. Kate etc are all fine.
As it's a nouveau problem on TW, the best would be to report to the upstream, e.g. gitlab.freedesktop.org Issues https://gitlab.freedesktop.org/drm/nouveau/-/issues/
(In reply to Takashi Iwai from comment #5) > As it's a nouveau problem on TW, the best would be to report to the upstream, > e.g. gitlab.freedesktop.org Issues > https://gitlab.freedesktop.org/drm/nouveau/-/issues/ As I am mainly a KDE user I almost never launch Gnome-Terminal. On my home laptop having Intel 5500 GPU which already have some freeze issues and debugging enabled I launched gnome-terminal by mistake and to my surprise it displayed the exact same glitch. As it won't appear in screen digital recording, I took a video of it. I am making some space for distrobox right now so I can test another similar distributions gnome-terminal.
Did you open the gitlab issue entry for nouveau already and discussed with developers there? If yes, please give the URL, so that we can note it here, too as a reference. In anyway, if the same problem is seen on i915, it's likely a different problem. You can try to report either to KDE or GNOME at first, although this can be rather a rendering problem in a lower layer.
(In reply to Takashi Iwai from comment #7) > Did you open the gitlab issue entry for nouveau already and discussed with > developers there? If yes, please give the URL, so that we can note it here, > too as a reference. > > In anyway, if the same problem is seen on i915, it's likely a different > problem. > You can try to report either to KDE or GNOME at first, although this can be > rather a rendering problem in a lower layer. I managed to create the exact same issue on a fresh user account and Fedora 39 gnome-terminal via distrobox does have the same issue too. It is possible to compress the fresh user account home directory to a file as it doesn't have any personal info in case it is needed. gitlab/nouveau bug report is at https://gitlab.freedesktop.org/drm/nouveau/-/issues/295
I am pretty much confused now since I reproduced the same issue with a fresh Tumbleweed install with a fresh home on Intel 5200U HD5500 GPU. This time it happens under KDE current (TW 20240108) with Microsoft Edge and Google Chrome. I am OK to test anything. It is exactly the same with HD5500, e.g. when you screenshot or screen record, issue isn't there in the recording but you can see it. I took a video of it.
I've been seeing SDDM look like attachment #871115 [details] on multiple installations, but was ignoring it until stumbling here. If the following seems related, I will have to return, after determining where among 15.5, 15.6, Slowroll, TW and/or other Mageia or Fedora, and what CPUs/GPUs, other than the last seen: TW20240301 & 6.6.18 on a Cedar Mill Pentium 641 CPU and PCI Tesla 10de:06e4 GPU with dmesg flooding: (kernel cmdline ...ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 mitigations=off drm.debug=0x1e log_bug_len=2M) # dmesg ... [ 437.498754] nouveau 0000:0b:00.0: DRM: base-0 cleanup: 0000000058e43383 [ 437.498762] nouveau 0000:0b:00.0: DRM: curs-0 cleanup: 0000000000000000 [ 437.498770] nouveau 0000:0b:00.0: [drm:drm_atomic_state_default_clear] Clearing atomic state 0000000051b08724 [ 437.498793] nouveau 0000:0b:00.0: [drm:__drm_atomic_state_free] Freeing atomic state 0000000051b08724 [ 437.498842] nouveau 0000:0b:00.0: [drm:drm_atomic_state_init] Allocated atomic state 000000009deb8fe9 [ 437.498854] nouveau 0000:0b:00.0: [drm:drm_atomic_get_plane_state] Added [PLANE:57:curs-1] 0000000053232996 state to 000000009deb8fe9 [ 437.498868] nouveau 0000:0b:00.0: [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for [PLANE:57:curs-1] state 0000000053232996 [ 437.498877] nouveau 0000:0b:00.0: [drm:drm_atomic_check_only] checking 000000009deb8fe9 [ 437.498891] nouveau 0000:0b:00.0: DRM: curs-1 atomic_check [ 437.498899] nouveau 0000:0b:00.0: [drm:drm_atomic_commit] committing 000000009deb8fe9 [ 437.498911] nouveau 0000:0b:00.0: DRM: curs-1 prepare: 0000000000000000 [ 437.498920] nouveau 0000:0b:00.0: DRM: commit 0 0 [ 437.498927] nouveau 0000:0b:00.0: DRM: curs-1: clr 00 (set 00) [ 437.498934] nouveau 0000:0b:00.0: DRM: curs-1: set 00 (clr 00) [ 437.498941] nouveau 0000:0b:00.0: DRM: curs-1 cleanup: 0000000000000000 [ 437.498948] nouveau 0000:0b:00.0: [drm:drm_atomic_state_default_clear] Clearing atomic state 000000009deb8fe9 [ 437.498967] nouveau 0000:0b:00.0: [drm:__drm_atomic_state_free] Freeing atomic state 000000009deb8fe9 [ 437.526894] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000003:fenceNonStallIntr] [ALLOW] [ 437.526922] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000003:fenceNonStallIntr] [BLOCK] [ 437.528031] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000003:fenceNonStallIntr] [ALLOW] [ 437.528534] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000003:fenceNonStallIntr] [BLOCK] [ 437.552990] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000006:fenceNonStallIntr] [ALLOW] [ 437.553022] nouveau 0000:0b:00.0: DRM: [Xorg.bin[807]/00000006:fenceNonStallIntr] [BLOCK] ...