Bug 2385963
| Summary: | [abrt] kwin: KCrash::defaultCrashHandler(): kwin_wayland killed by SIGSEGV | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mr. Beedell, Roke Julian Lockhart (RJLB) <8ru2u4gz> | ||||||||||||||||||||||||
| Component: | mesa | Assignee: | Adam Jackson <ajax> | ||||||||||||||||||||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||
| Version: | 42 | CC: | 8ru2u4gz, ajanulgu, ajax, igor.raits, jexposit, jgrulich, j, kde-sig, lina, lyude, marcandre.lureau, marcdeop, rdieter, rstrode, suraj.ghimire7, than, tstellar, walter.pete | ||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/1781a6793147861b99acb347be9f9bda6373a64 | ||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:a9fa7f8a57c35aaf1bcdfcdec710372645f805a0;VARIANT_ID=kde; | ||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | --- | |||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||
| Last Closed: | Type: | --- | |||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
Mr. Beedell, Roke Julian Lockhart (RJLB)
2025-08-01 15:26:46 UTC
Created attachment 2102408 [details]
File: proc_pid_status
Created attachment 2102409 [details]
File: maps
Created attachment 2102410 [details]
File: limits
Created attachment 2102411 [details]
File: environ
Created attachment 2102412 [details]
File: open_fds
Created attachment 2102413 [details]
File: mountinfo
Created attachment 2102414 [details]
File: os_info
Created attachment 2102415 [details]
File: cpuinfo
Created attachment 2102416 [details]
File: core_backtrace
Created attachment 2102417 [details]
File: var_log_messages
Created attachment 2102418 [details]
File: backtrace
*** Bug 2385942 has been marked as a duplicate of this bug. *** This has been reported upstream, at . (In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #13) > This has been reported upstream, at . ...at https://bugs.kde.org/show_bug.cgi?id=507748#c0:~:text=Information%20about%20the%20crash. Oops. *** Bug 2385966 has been marked as a duplicate of this bug. *** *** Bug 2385965 has been marked as a duplicate of this bug. *** *** Bug 2385967 has been marked as a duplicate of this bug. *** Added https://bugzilla.redhat.com/show_bug.cgi?id=2368988#c12, although it's a generic crash-on-compositor-death-and-then-reboot report. *** Bug 2385972 has been marked as a duplicate of this bug. *** *** Bug 2385973 has been marked as a duplicate of this bug. *** https://bugzilla.redhat.com/show_bug.cgi?id=2385973#c0 might provide a new trace. This is not a crash in KWin, it's a crash in mesa. I don't think anyone expects this to work. GPUs have maximum texture sizes and with modern desktops relying on GPU acceleration, you simply cannot have windows wider than 16384 pixels or so. Mesa should have better error handling than just crashing in radeonsi, but there is no good way to handle this. Even if you try to limit window dimensions, just knowing the maximum dimensions that don't hit texture size limits is a heavily situation-specific problem given things like fractional scaling and window borders and other effects. You could have a window that is just 8200 logical pixels in width, then move it to a 2.0x scale monitor, and suddenly you are hitting the texture size limit. Other than fixing the Mesa handling to not segfault, perhaps compositors could at least handle this cleanly by killing the problem client or something, but even that is going to be difficult because by the time the compositor is trying to create a texture that is too large, it might not be evident at that point in the code who the culprit is. Step 1 is to just make Mesa handle this gracefully and fail the relevant operations. Then compositors have to decide how to handle it... Thanks! I forgot to add that this appears to reproduce something very similar to https://gitlab.freedesktop.org/drm/amd/-/issues/3462, [^1] if the undermentioned [^2] is equivalent: > ~~~ > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: Dumping IP State > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: Dumping IP State Completed > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: [drm] AMDGPU device coredump file has been created > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=611809, emitted seq=611811 > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: Process information: process kwin_wayland pid 1895 thread kwin_wayla:cs0 pid 1974 > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: Starting gfx_0.0.0 ring reset > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: Ring gfx_0.0.0 reset failure > 16:10:56 kernel: amdgpu 0000:03:00.0: amdgpu: GPU reset begin! > 16:10:57 kernel: amdgpu 0000:03:00.0: amdgpu: BACO reset > 16:10:58 kernel: amdgpu 0000:59:00.0: [drm] *ERROR* lttpr_caps phy_repeater_cnt is 0x0, forcing it to 0x80. > 16:10:58 kernel: amdgpu 0000:59:00.0: [drm] *ERROR* LTTPR count is nonzero but invalid lane count reported. Assuming no LTTPR present. > 16:10:58 kernel: amdgpu 0000:59:00.0: [drm] Cannot find any crtc or sizes > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: GPU reset succeeded, trying to resume > 16:11:00 kernel: [drm] PCIE GART of 512M enabled (table at 0x00000081FEE00000). > 16:11:00 kernel: [drm] VRAM is lost due to GPU reset! > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: PSP is resuming... > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: reserve 0x900000 from 0x81fd000000 for PSP TMR > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming... > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: use vbios provided pptable > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: smc_dpm_info table revision(format.content): 4.5 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully! > 16:11:00 kernel: [drm] kiq ring mec 2 pipe 1 q 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 8 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 8 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 8 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8 > 16:11:00 kernel: amdgpu 0000:03:00.0: amdgpu: GPU reset(9) succeeded! > 16:11:00 kernel: amdgpu 0000:03:00.0: [drm] device wedged, but recovered through reset > ~~~ [^1]: https://bugs.kde.org/show_bug.cgi?id=507748#c3:~:text=Created%20attachment%20183714%20%5Bdetails%5D [^2]: https://discussion.fedoraproject.org/t/dmesg-from-previous-boot/109564/5#:~:text=journalctl%20%2Db%20%2D1%20%2D%2Dsystem Wrong bug ID. Apologies for the noise. *** Bug 2385957 has been marked as a duplicate of this bug. *** *** Bug 2385954 has been marked as a duplicate of this bug. *** *** Bug 2385953 has been marked as a duplicate of this bug. *** *** Bug 2385950 has been marked as a duplicate of this bug. *** *** Bug 2385944 has been marked as a duplicate of this bug. *** *** Bug 2385943 has been marked as a duplicate of this bug. *** Apologies again. They were reported before I filed this, whilst I was attempting to ascertain what the cause was. Forgot to deal with them until now. Reported upstream, at https://gitlab.freedesktop.org/drm/amd/-/issues/4473. |