Bug 198619 - suspend / extremely slow after thaw
Summary: suspend / extremely slow after thaw
Status: RESOLVED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-31 06:49 UTC by Arne Woerner
Modified: 2019-10-28 15:43 UTC (History)
0 users

See Also:
Kernel Version: 4.15.0-1-MANJARO
Tree: Mainline
Regression: No


Attachments

Description Arne Woerner 2018-01-31 06:49:43 UTC
the first hibernate(s2disk)-thaw-cycle completed nicely...
then i played SecondLife and after some hours of video watching i started s2disk again and mentioned, that the monitor got no signal, when s2disk was writing the image to the swap device...
today when i tried to thaw the box, everything was extremely slow (it took seconds until i could c the letter in the gnome-terminal that i typed)...
then i switched to tty2 (ctrl+alt+F2) and saw the output from the process, that read the image, that s2disk wrote... and the screen had lots of equidistant vertical pink lines...

a reboot helped with the speed (now it is normal again), but of course that is not the reason to hibernate... giggle

my hardware is AMD A10-5800K and AMD Radeon RX550 (with a normal amdgpu/kernel).
Comment 1 Arne Woerner 2018-02-01 05:52:41 UTC
today it thawed nicely although i played SecondLife a lot before the s2disk without a reboot... but it was the first hibernate/thaw cycle since the last reboot... -arne
Comment 2 Arne Woerner 2018-02-01 10:47:28 UTC
could it be VLC related?
i mean: the hibernate-thaw-cycle worked fine without a vlc process... but yesterday morning there was a vlc process, when the thaw failed...
plus: i use VLC since 2018-01-25... before i used smplayer with some 4.15-rc and it always thawed nicely... iirc... :)
-arne
Comment 3 Arne Woerner 2018-02-02 05:09:32 UTC
it happens without vlc, too...
it seems like the first hibernate-thaw-cycle works fine,
but the second fails...
-arne
Comment 4 Arne Woerner 2018-02-02 05:38:03 UTC
in the journal it says quite often
kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0001 address=0x00000000e6625040 flags=0x0000]
kernel: amdgpu 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 address=0x00000000e6625000 flags=0x0000]
shortly after thaw... -arne
Comment 5 Arne Woerner 2018-02-03 05:38:41 UTC
the kernel parameter "iommu=soft" did not help...
it happened again during the second hibernate-thaw-cycle...

i found some more suspicious log lines:
(they showed up during the second thaw...)
kernel: PM: Device 0000:01:00.0 failed to restore async: error -22
kernel: dpm_run_callback(): pci_pm_restore+0x0/0xa0 returns -22
kernel: [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_resume failed (-22).
kernel: [drm:amdgpu_resume_phase2 [amdgpu]] *ERROR* resume of IP block <uvd_v6_0> failed -22
kernel: [drm:uvd_v6_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 12 test failed (0xCAFEDEAD)

during the first thaw the log says:
kernel: [drm] VCE initialized successfully.
kernel: [drm] ring test on 16 succeeded in 8 usecs


-arne
Comment 6 Arne Woerner 2019-10-28 15:43:08 UTC
it was gone for some time...
but since 5.2.8 it is back...
https://bugzilla.kernel.org/show_bug.cgi?id=205335
-arne

Note You need to log in before you can comment on or make changes to this bug.