SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Upgrade to latest 5.24.90 (kde-unstable) 2. Seems to disconnect on it's own 3. No output, although it is still listed in display's, it cannot be enabled. OBSERVED RESULT mei 20 14:16:55 desktop kernel: usb 2-1.2: USB disconnect, device number 3 mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) Backtrace: mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 0: /usr/bin/Xwayland (0x5568b0ca3000+0x16386a) [0x5568b0e0686a] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 4: /usr/lib/libffi.so.8 (0x7f350a592000+0x7536) [0x7f350a599536] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 5: /usr/lib/libffi.so.8 (0x7f350a592000+0x4037) [0x7f350a596037] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 6: /usr/lib/libwayland-client.so.0 (0x7f350abef000+0x75e2) [0x7f350abf65e2] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 7: /usr/lib/libwayland-client.so.0 (0x7f350abef000+0x7d73) [0x7f350abf6d73] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 8: /usr/lib/libwayland-client.so.0 (wl_display_dispatch_queue_pending+0x7c) [0x7f350abf6f8c] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 9: /usr/bin/Xwayland (0x5568b0ca3000+0x393ed) [0x5568b0cdc3ed] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 10: /usr/bin/Xwayland (0x5568b0ca3000+0x164e31) [0x5568b0e07e31] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 11: /usr/bin/Xwayland (0x5568b0ca3000+0xa1ef0) [0x5568b0d44ef0] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 12: /usr/bin/Xwayland (0x5568b0ca3000+0x2f8e0) [0x5568b0cd28e0] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 13: /usr/lib/libc.so.6 (0x7f350a691000+0x29290) [0x7f350a6ba290] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 14: /usr/lib/libc.so.6 (__libc_start_main+0x8a) [0x7f350a6ba34a] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) 15: /usr/bin/Xwayland (0x5568b0ca3000+0x31135) [0x5568b0cd4135] mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) Bus error at address 0x0 mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: Fatal server error: mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) Caught signal 7 (Bus error). Server aborting mei 20 14:16:56 desktop kwin_wayland_wrapper[7157]: (EE) mei 20 14:16:56 desktop systemd[1]: Started Process Core Dump (PID 21574/UID 0). EXPECTED RESULT Working external USB-C screen SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.24.90 (available in About System) KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION ASUS ZenScreen MB16ACE
Please add QT_LOGGING_RULES="kwin_wayland_*.debug=true" into your /etc/environment and reboot. Then wait until the bug happens, try to enable the output again and then attach the output of journalctl --boot 0 --user-unit plasma-kwin_wayland | grep kwin_wayland_drm here
Created attachment 149233 [details] journalctl log I am also getting the same bug but I am using HDMI instead of USB-C. I have attached the journalctl output.
> kwin_wayland_drm: Failed to find a working setup for new outputs! That is the culprit, there is however no information about why it failed. To get more information, please execute the script from https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues in a tty with the output connected and upload the two files it generates.
Created attachment 149256 [details] dmesh-drm-debug.log
Created attachment 149257 [details] kwin-drm-debug.log I have attached the required files
Confusingly, the drm / kernel log doesn't mention any failed commits, it should have something like "Atomic check failed with err" in it. Are you using some kernel boot flags like amdgpu.dc=0?
> loglevel=3 quiet acpi_osi='Windows 2020' initcall_blacklist=acpi_cpufreq_init I am using these flags. First two are default in Arch. Third one emulates the Windows acpi calls (I think) and fourth one blacklists the acpi_cpufreq driver for AMD CPUs because I use the new P-State drivers instead.
Sorry, this was my mistake - the flags for which debug messages to enable was wrong, it needs to be 0xFF instead of 0xFE. I adjusted the script accordingly. Can you try again with the correct flags?
Created attachment 149456 [details] New kwin-drm-debug.log
Created attachment 149457 [details] New dmesg-drm-debug.log I have uploaded the required files
I can also confirm reproducing this issue on both the 5.24.90 beta and the 5.25.0 release. Reverting back to 5.24.5 fixes this issue. Both USB-C DP and HDMI do not work for my laptop (ASUS ProArt Studiobook 16). Maybe important to note: The laptop is AMDGPU+NVIDIA. Nvidia must be turned on with nvidia-drm.modeset=1 so that the external monitor works on any version. I will try to get useful logs and attach it asap.
*** Bug 455300 has been marked as a duplicate of this bug. ***
So (In reply to VesperLlama from comment #10) > New dmesg-drm-debug.log now contains messages about commits failing with EINVAL (-22), but still nothing about the reason for it, or the expected messages about it. (In reply to Tony Stipanic from comment #11) I will try to get useful logs and attach it asap. Please do! I don't know how much logging NVidia does, but it may yield useful information either way. @Andrew Ammerlaan if you also run the script from comment #3 that might help as well. Some general things you could all try is using the environment variables (one by one) KWIN_DRM_USE_MODIFIERS=0 KWIN_DRM_PREFER_COLOR_DEPTH=24 KWIN_DRM_NO_AMS=1
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2534
Testing that MR may also help, even though using the buffer for outputs should fail completely (and show in the logs), I faintly remember debugging a similar problem in the past
Git commit 34ce3dde87efef745c864b78bc1db541080552cb by Xaver Hugl. Committed on 16/06/2022 at 15:02. Pushed by zamundaaa into branch 'master'. backends/drm: use GBM_BO_USE_SCANOUT when importing buffers for multi gpu The gbm surface may not have the scanout use flag, and if the buffer is imported without it, creating the framebuffer may fail M +1 -1 src/backends/drm/egl_gbm_layer_surface.cpp https://invent.kde.org/plasma/kwin/commit/34ce3dde87efef745c864b78bc1db541080552cb
Git commit 9baa2c3ee4fef11a5df92fb43fa39ba2ef141709 by Xaver Hugl. Committed on 16/06/2022 at 20:08. Pushed by zamundaaa into branch 'Plasma/5.25'. backends/drm: use GBM_BO_USE_SCANOUT when importing buffers for multi gpu The gbm surface may not have the scanout use flag, and if the buffer is imported without it, creating the framebuffer may fail (cherry picked from commit 34ce3dde87efef745c864b78bc1db541080552cb) M +1 -1 src/backends/drm/egl_gbm_layer_surface.cpp https://invent.kde.org/plasma/kwin/commit/9baa2c3ee4fef11a5df92fb43fa39ba2ef141709
*** Bug 455437 has been marked as a duplicate of this bug. ***
I have tried running with the currently merged MR from the Plasma/5.25 branch but unfortunately, it doesn't seem to have fixed the issue. I've run the script with that version. The only useful logs I've got were from dmesg. The kwin one is just empty
Created attachment 149846 [details] Debug logs from script with MR
Created attachment 149850 [details] kwin debug log, no extra env vars
Created attachment 149851 [details] dmesg, no extra env vars
Created attachment 149852 [details] kwin debug log, NO_AMS
Created attachment 149853 [details] dmesg, NO_AMS
Created attachment 149854 [details] kwin debug log, PREFER_COLOR_DEPTH
Created attachment 149855 [details] dmesg, PREFER_COLOR_DEPTH
Created attachment 149856 [details] kwin debug log, USE_MODIFIERS
Created attachment 149857 [details] dmesg, USE_MODIFIERS
(In reply to Zamundaaa from comment #13) > So (In reply to VesperLlama from comment #10) > > New dmesg-drm-debug.log > now contains messages about commits failing with EINVAL (-22), but still > nothing about the reason for it, or the expected messages about it. > > (In reply to Tony Stipanic from comment #11) > I will try to get useful logs and attach it asap. > Please do! I don't know how much logging NVidia does, but it may yield > useful information either way. > > @Andrew Ammerlaan if you also run the script from comment #3 that might help > as well. > > Some general things you could all try is using the environment variables > (one by one) > KWIN_DRM_USE_MODIFIERS=0 > KWIN_DRM_PREFER_COLOR_DEPTH=24 > KWIN_DRM_NO_AMS=1 I uploaded the logs from the debug script, plus the same logs with the environment variables you suggested. For some reason my computer is acting very 'weird' after running this script and rebooting. It's very slow to start up now, and the system POST is no longer displayed on the screen.
(In reply to Andrew Ammerlaan from comment #29) > For some reason my computer is acting very 'weird' after running this script > and rebooting. It's very slow to start up now, and the system POST is no > longer displayed on the screen. Never mind about this, it is unrelated. Apparently I had a secondary hard drive failure that happened to coincide with me running this debug script. Made all the more confusing by that the debug LED that turned on at boot was the one for the GPU.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2538
Unfortunately the kernel doesn't seem to do any logging for when the buffers are still on the wrong GPU, but this MR should finally fix the problem
Git commit 1966638017f8692e9358bd95b521e199a4d02f6b by Xaver Hugl. Committed on 17/06/2022 at 15:45. Pushed by zamundaaa into branch 'master'. backends/drm: do cross-gpu imports again for test commits Otherwise all commits will fail without a clear visible reason. M +13 -0 src/backends/drm/egl_gbm_layer_surface.cpp https://invent.kde.org/plasma/kwin/commit/1966638017f8692e9358bd95b521e199a4d02f6b
Git commit 9d9854b79b7a6eb031695e6190e7bd8bc0bff340 by Xaver Hugl. Committed on 17/06/2022 at 18:33. Pushed by zamundaaa into branch 'Plasma/5.25'. backends/drm: do cross-gpu imports again for test commits Otherwise all commits will fail without a clear visible reason. (cherry picked from commit 1966638017f8692e9358bd95b521e199a4d02f6b) M +13 -0 src/backends/drm/egl_gbm_layer_surface.cpp https://invent.kde.org/plasma/kwin/commit/9d9854b79b7a6eb031695e6190e7bd8bc0bff340
The fix was already confirmed; if any issues in this area remain, please open new bug reports and cc me there
*** Bug 455550 has been marked as a duplicate of this bug. ***
(In reply to Andrew Ammerlaan from comment #30) > Apparently I had a secondary hard > drive failure that happened to coincide with me running this debug script. > Made all the more confusing by that the debug LED that turned on at boot was > the one for the GPU. Replaced the faulty HDD, upgraded to 5.25.1. And indeed everything is working again. Thanks for your work on this! The bug that I briefly mentioned earlier where the screen gets corrupted when an application is full screen on a monitor connected to the iGPU is still present, but I'll open a new bug for that later.
Well, it's official, i now have kde plasma 5.25.1 - and i sill have no multi-monitors :( So the USB-C bug reported either is not totally fixed or it was a mistake saying it was related to my original multi-monitor bug
(In reply to Ben from comment #38) > Well, it's official, i now have kde plasma 5.25.1 - and i sill have no > multi-monitors :( > So the USB-C bug reported either is not totally fixed or it was a mistake > saying it was related to my original multi-monitor bug Where did you report your problems? I only see two other bug reports marked as identical to this one, and none of seem to have been submitted by you.
(In reply to kde.org from comment #39) > (In reply to Ben from comment #38) > > Well, it's official, i now have kde plasma 5.25.1 - and i sill have no > > multi-monitors :( > > So the USB-C bug reported either is not totally fixed or it was a mistake > > saying it was related to my original multi-monitor bug > > Where did you report your problems? I only see two other bug reports marked > as identical to this one, and none of seem to have been submitted by you. Here: https://bugs.kde.org/show_bug.cgi?id=455300
*** Bug 456369 has been marked as a duplicate of this bug. ***
Are we sure https://bugs.kde.org/show_bug.cgi?id=456369 is a duplicate of this one? I can't find any entries in the uploaded logs that match the ones I attached to the other bug report. Also, the issue here seems to be entirely non functional usb-c monitors. In my experience, the monitor works fine (connected before boot). Both external monitor and built in fail after disconnecting it, until reboot. The log entry that caught my eye was: plasmashell[1693]: requesting unexisting screen 0 There are a lot of those, everytime I reproduce the issue.
No, this was specifically about multi-gpu setups