Похожее поведение замечено иногда и при закрытии крышки ноутбука (хотя у меня в настройках выставлен Ждущий режим при закрытии крышки).

Сценарий: беру ноутбук, закрываю крышку, иду на кухню, открываю крышку: ноутбук не пробуждается.

Воспроизвелось по шагам 1-3 для 
plasma5-workspace-5.26.5-alt8.x86_64

(Ответ для Vera Blagoveschenskaya на комментарий #0)
> воспроизводится (у меня) только на ядре std-def.

Также воспроизвелось на стенде ASUS EXPERTBOOK L1500CDAY

На kernel-image-un-def-5.15.96-alt1.x86_64 так же воспроизвелось.

Вместо выхода из спящего режима, происходит "обычный" запуск системы: вместо ранее открытых приложений, открывается меню входа в систему SDDM.

Версия пакета: plasma5-workspace-5.26.5-alt8.x86_64

Прикладываю $ inxi -F

Created attachment 12657 [details]
inxi -F

1. На каком последнем std-def/p10 ядре проблема отсутствовала, а потом возникла?
2. Воспроизводится ли проблема в других средах рабочего стола с теми же ядрами где на KDE Plasma 5 проблема есть?

(Ответ для Vitaly Chikunov на комментарий #6)
> 1. На каком последнем std-def/p10 ядре проблема отсутствовала, а потом
> возникла?
Затрудняюсь ответить. 
Ноутбук, на котором обнаружена проблема, у меня около месяца. Проблема замечена около недели назад только потому, что я стала использовать спящий режим.

> 2. Воспроизводится ли проблема в других средах рабочего стола с теми же
> ядрами где на KDE Plasma 5 проблема есть?
Вот тут был один пользователь со стартеркитом (xfce) https://bugzilla.altlinux.org/45066
с похожей проблемой.

Результат проверки актуальности

Состояние:
Отчёт относится к Plasma 5.26 и ядрам 5.10/5.15. В Sisyphus используются Plasma Workspace 6.7 и ядра 6.12/6.18. Явного исправления аппаратно-зависимого сбоя suspend/resume в changelog не найдено.

Рекомендация:
выполнить ретест suspend/resume на актуальном Sisyphus на указанном или близком оборудовании.

Ретест на десктопе AMD (Gigabyte B650 GAMING X AX, Ryzen 7000, Radeon RX 7600 + встроенная
Raphael, обе на amdgpu), Sisyphus x86_64 на 17.09.2026, ядро 6.12.110-6.12-alt1,
plasma-workspace 6.7.5-alt1.

Сразу оговорюсь: это десктоп, поэтому сценарий с закрытой крышкой и всё, что связано с крышкой и
питанием от батареи, здесь непроверяемо. Проверял только засыпание и пробуждение как таковые.

Три цикла подряд в одной загрузке (два в сеансе MATE, один в сеансе Plasma 6 X11), пробуждение
нажатием клавиши:

    # cat /sys/power/mem_sleep
    s2idle [deep]
    # systemctl suspend
    # dmesg | grep -E 'ACPI: PM: (Preparing|Waking)|PM: suspend exit'
    [  588.888983] ACPI: PM: Preparing to enter system sleep state S3
    [  589.386462] ACPI: PM: Waking up from system sleep state S3
    [  591.164906] PM: suspend exit
    [  963.308720] ACPI: PM: Preparing to enter system sleep state S3
    [  965.321742] ACPI: PM: Waking up from system sleep state S3
    [  967.076677] PM: suspend exit
    [ 1293.749541] ACPI: PM: Preparing to enter system sleep state S3
    [ 1294.244392] ACPI: PM: Waking up from system sleep state S3
    [ 1296.008252] PM: suspend exit

    # dmesg | grep -icE 'ring.*timeout|GPU reset|drm.*ERROR'
    0
    # pgrep -c plasmashell ; pgrep -c kwin_x11
    1
    1

Машина каждый раз возвращалась в тот же сеанс: повторного входа не требовалось, самопроизвольного
ухода в сон не было, ошибок amdgpu после пробуждения в журнале нет. Потери данных, о которой идёт
речь в отчёте, тоже не было.

То есть на актуальном ядре и Plasma 6 на десктопном AMD проблема не воспроизводится. Отчёт же
относится к ноутбукам на ядрах 5.10 и 5.15, где сценарий завязан на крышку и работу от батареи,
а такого железа у меня нет.

Не закрываю. Просьба к репортёрам: проверьте, пожалуйста, на своих ноутбуках на актуальном
Sisyphus — если проблема ушла и там, баг можно закрывать как WORKSFORME. Если воспроизводится,
приложите `journalctl -b -1 -k | grep -iE 'PM:|amdgpu'` за неудачное пробуждение и вывод
`cat /sys/power/mem_sleep`.