Bug 1206864 - Direct Rendering Manager trouble upon resume from suspend to RAM
Direct Rendering Manager trouble upon resume from suspend to RAM
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2023-01-05 04:22 UTC by Karl Mistelberger
Modified: 2023-01-26 11:43 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jslaby: needinfo? (karl.mistelberger)


Attachments
journal (606.25 KB, text/plain)
2023-01-05 04:22 UTC, Karl Mistelberger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Mistelberger 2023-01-05 04:22:30 UTC
Created attachment 863857 [details]
journal

The system readily suspends. But resume is very slow and exhibits trouble with drm:

[  195.129982] kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400300000).
[  195.831331] kernel: [drm] Fence fallback timer expired on ring sdma0
[  196.343309] kernel: [drm] Fence fallback timer expired on ring sdma0
[  196.855320] kernel: [drm] Fence fallback timer expired on ring sdma0
[  197.367318] kernel: [drm] Fence fallback timer expired on ring sdma0
[  197.879296] kernel: [drm] Fence fallback timer expired on ring sdma0
[  198.391313] kernel: [drm] Fence fallback timer expired on ring sdma0
[  198.903334] kernel: [drm] Fence fallback timer expired on ring sdma0
[  199.415327] kernel: [drm] Fence fallback timer expired on ring sdma0
[  199.927300] kernel: [drm] Fence fallback timer expired on ring sdma0
[  200.439297] kernel: [drm] Fence fallback timer expired on ring sdma0
[  200.951299] kernel: [drm] Fence fallback timer expired on ring sdma0
[  201.463085] kernel: [drm] Fence fallback timer expired on ring sdma0
[  201.975089] kernel: [drm] Fence fallback timer expired on ring sdma0
[  202.487089] kernel: [drm] Fence fallback timer expired on ring sdma0
[  202.999090] kernel: [drm] Fence fallback timer expired on ring sdma0
[  203.511090] kernel: [drm] Fence fallback timer expired on ring sdma0
[  204.023091] kernel: [drm] Fence fallback timer expired on ring sdma0
[  204.535091] kernel: [drm] Fence fallback timer expired on ring sdma0
[  205.047358] kernel: [drm] Fence fallback timer expired on ring sdma0
[  205.123518] kernel: [drm] UVD and UVD ENC initialized successfully.
[  205.223510] kernel: [drm] VCE initialized successfully.

See also attached journal.
Comment 1 Takashi Iwai 2023-01-05 09:01:25 UTC
Looks like a problem of amdgpu.

I suppose it's something new in 6.1.x, and not happening with 6.0.x kernel?
If yes, please report to the upstream, e.g. gitlab.freedesktop.org Issues.

In anyway, please give the hardware details.
Comment 2 Karl Mistelberger 2023-01-05 11:51:01 UTC
(In reply to Takashi Iwai from comment #1)
> Looks like a problem of amdgpu.
> 
> I suppose it's something new in 6.1.x, and not happening with 6.0.x kernel?
> If yes, please report to the upstream, e.g. gitlab.freedesktop.org Issues.

Last (almost) known good kernel is 5.18.11-1:

Jan 05 03:20:49 erlangen kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400300000).
Jan 05 03:20:49 erlangen kernel: [drm] Fence fallback timer expired on ring sdma0
Jan 05 03:20:49 erlangen kernel: [drm] Fence fallback timer expired on ring sdma0
Jan 05 03:20:49 erlangen kernel: [drm] UVD and UVD ENC initialized successfully.
Jan 05 03:20:49 erlangen kernel: [drm] VCE initialized successfully.

All 6.0 and newer fail.

> In anyway, please give the hardware details.

erlangen:~ # inxi -zaG
Graphics:
  Device-1: AMD Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
    vendor: Sapphire driver: amdgpu v: kernel arch: GCN-4 code: Arctic Islands
    process: GF 14nm built: 2016-20 pcie: gen: 3 speed: 8 GT/s lanes: 8 ports:
    active: HDMI-A-1 empty: DP-1,DVI-D-1 bus-ID: 2b:00.0 chip-ID: 1002:699f
    class-ID: 0300 temp: 49.0 C
  Display: x11 server: X.Org v: 21.1.6 with: Xwayland v: 22.1.7
    compositor: kwin_x11 driver: X: loaded: amdgpu
    unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3840x2160 s-dpi: 192 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: HDMI-A-1 mapped: HDMI-A-0 model: Samsung LU28R55
    serial: <filter> built: 2038 res: 3840x2160 hz: 60 dpi: 154 gamma: 1.2
    size: 632x360mm (24.88x14.17") diag: 727mm (28.6") ratio: 16:9 modes:
    max: 3840x2160 min: 720x400
  API: OpenGL v: 4.6 Mesa 22.3.2 renderer: AMD Radeon RX 550 / 550 Series
    (polaris12 LLVM 15.0.6 DRM 3.46 5.18.11-1-default) direct render: Yes
erlangen:~ #
Comment 3 Takashi Iwai 2023-01-05 13:37:06 UTC
(In reply to Karl Mistelberger from comment #2)
> (In reply to Takashi Iwai from comment #1)
> > Looks like a problem of amdgpu.
> > 
> > I suppose it's something new in 6.1.x, and not happening with 6.0.x kernel?
> > If yes, please report to the upstream, e.g. gitlab.freedesktop.org Issues.
> 
> Last (almost) known good kernel is 5.18.11-1:
> 
> Jan 05 03:20:49 erlangen kernel: [drm] PCIE GART of 256M enabled (table at
> 0x000000F400300000).
> Jan 05 03:20:49 erlangen kernel: [drm] Fence fallback timer expired on ring
> sdma0
> Jan 05 03:20:49 erlangen kernel: [drm] Fence fallback timer expired on ring
> sdma0
> Jan 05 03:20:49 erlangen kernel: [drm] UVD and UVD ENC initialized
> successfully.
> Jan 05 03:20:49 erlangen kernel: [drm] VCE initialized successfully.

Aha, so the message itself appeared in 5.18, but they were fewer, and the shorter blockage.

> All 6.0 and newer fail.

How about 5.19.x?  And, as far as I understand correctly, it doesn't "fail" but just takes much longer time, right?
Comment 4 Karl Mistelberger 2023-01-06 06:07:28 UTC
(In reply to Takashi Iwai from comment #3)
> Aha, so the message itself appeared in 5.18, but they were fewer, and the
> shorter blockage.

Yep.


> > All 6.0 and newer fail.
> How about 5.19.x?

5.19.x already suffered from the multiple timeouts.

> And, as far as I understand correctly, it doesn't "fail" but just takes much longer time, right?

There is an annoying ten seconds delay. However the system eventually recovers and stays usable.
Comment 5 Jiri Slaby 2023-01-26 10:09:32 UTC
(In reply to Takashi Iwai from comment #1)
> If yes, please report to the upstream, e.g. gitlab.freedesktop.org Issues.

Provided it's a long-lasting problem (and upstream one), care to create an issue there? They can help you tracking this down.
Comment 6 Karl Mistelberger 2023-01-26 11:43:48 UTC
(In reply to Jiri Slaby from comment #5)
> (In reply to Takashi Iwai from comment #1)
> > If yes, please report to the upstream, e.g. gitlab.freedesktop.org Issues.
> 
> Provided it's a long-lasting problem (and upstream one), care to create an
> issue there? They can help you tracking this down.

https://gitlab.freedesktop.org/drm/amd/-/issues/2369