Черный экран после Suspend

А на lts-ядре все нормально работает? Хотя у меня тоже такое иногда происходит, но я почему-то всегда плюю на проблему. Ну хотя все таки грешить надо на Wayland, он ещё оооочень далеко от идеала. Надо вывод dmesg -g чтобы сделать выводы.

Ну как бы тут у всех такие истории могут быть, причем на разном железе. У меня на 5.10 (Debian stable) тоже перестало в сон уходить. Правильнее сказать, что не перестало, а засыпать стал мертвым сном. Не просыпается никак. Откатился на 4.19 из oldstable - работает. Причем дело в ядре. Делаю echo -n "mem" > /sys/power/state. На 4.19 просыпается, а на 5.10 виснет намертво и тогда только перезагруз. Буду вот как раз перебирать все ядра до и после 5.10 из snapshot, чтобы понять, на каком поломалось.

А на lts-ядре все нормально работает?

Уже нет.

грешить надо на Wayland

Откатывал к прошлой версии - безрезультатно. За полтора-два года первая такая серьезная «бага». Где и что поломали не могу понять.

Тут вот еще:

Клавиатура, мышь и другие устройства ввода также (вероятно) не реагируют.

Если по hdmi подключить (или переподключить) второй монитор - рабочий стол на нем появляется (но не основной на матрице LVDS ноута), но ни клавиатура, ни мышь не реагируют.

dmesg -g

Сейчас сделаю.

Печально это. Без suspend работать совсем не удобно. Может кто-то найдет баг и отправит репорт (в моем случае, такое поведение буквально 2-3 недели, причем непонятно после какого обновления, сразу не заметил, а потом после lts некоторое время работал норм).

Надо вывод dmesg -g чтобы сделать выводы.

У меня такого ключа нет. Сделал просто dmesg (после просыпания): https://pastebin.com/aUhJvxuM

В общем, я в выводе ничего сверхъестественного не вижy, кроме уже указанного в ОП:

[ 3212.711855] debugfs: File 'radeon_ring_gfx' in directory '0' already present!
[ 3212.711859] debugfs: File 'radeon_ring_dma1' in directory '0' already present!
[ 3212.712915] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[ 3212.728276] [drm] ring test on 0 succeeded in 1 usecs
[ 3212.728282] [drm] ring test on 3 succeeded in 2 usecs
[ 3212.728285] debugfs: File 'radeon_ring_uvd' in directory '0' already present!

• Получается хочет создать файлы которые уже существуют. Куда копать дальше и кому писать? В этом причина и что это может быть (в драйвере что-то поломали или ядре?)?

• Как на arch поставить старое ядро (ниже lts, например 4.19)?

1. Возможно так, у меня как-то в гноме тоже такое было под вяленым, но эта надпись пару секунд висела, а потом появлялся скринсейвер.
2. Хз, в репах ничего подобного не нашел.

Как на arch поставить старое ядро (ниже lts, например 4.19)?

https://wiki.archlinux.org/title/Arch_Linux_Archive

Ну и в догонку

https://wiki.archlinux.org/title/Downgrading_packages

в моем случае, такое поведение буквально 2-3 недели, причем непонятно после какого обновления, сразу не заметил, а потом после lts некоторое время работал норм).

Я сомневаюсь, что поможет, так как железо абсолютно разное. Проблема может быть железоспецифичной.

Я тут поставил все ядра подряд snapshot.debian.org от 5.5 до 5.10 и запускал с каждым. Ну, тут ядра, которые в Debian в репозиториях были когда-то. У меня поломка сна произошла между 5.7.17 (нормально уходит в сон и нормально просыпается) и 5.8.14 (пытается уйти в сон, но кулер не останавливается и все - висит). В общем, где-то поломалось между 5.7 и 5.8. Буду разбираться. В дистрибутивном 5.10, как я сказал, тоже не работает. На всякий случай поставил еще 5.13 и 5.14, чтобы проверить, не починили ли, но нет, по-прежнему уходит в мертвый сон. Вот такая информация. Если ты сумеешь в своем Arch перебрать ядра и понять, где перестало работать, и если где-то там же перестало, то можно предположить какую-то общую причину, но я пока что сомневаюсь.

4.20.* не завелось. Поставил 5.9.10-arch1-1 - хорошо работает и эти ошибки исчезли:

-- Journal begins at Sat 2021-09-25 16:51:45 MSK, ends at Sat 2021-10-02 15:44:14 MSK. --
окт 02 15:43:55 sr538 kernel: debugfs: File 'radeon_ring_gfx' in directory '0' already present!
окт 02 15:43:55 sr538 kernel: debugfs: File 'radeon_ring_dma1' in directory '0' already present!
окт 02 15:43:55 sr538 kernel: debugfs: File 'radeon_ring_uvd' in directory '0' already present!

Засыпает/просыпается, все ок. Получается, в ядре причина была. Пока заигнорил обновления ядра, все работает на старом и хорошо.

Методом тыка поставил 5.9.10-arch1-1. УМВР. Буду сидеть пока на нем. Желаю и Вам удачи, без suspend’а уже недели 3 мучась, на ноуте это жесть (особенно в дороге). Сначала «забивал», но уже подзадолбала проблема.

Как-то не додумался из «архива» ядро поставить (вернее, думал там старых ядер нет).

У меня есть подозрение, что проблема в видео. Я тут эксперименты провел. Оказалось, что если не грузить графику (иксы в моем случае), а вызвать уход в сон из фреймбуферного терминала, то в сон уходит. Как только загружаешь иксы - всё, больше не работает. Иксы тут ни при чем. У меня работает сон в 5.7 и не работает в 5.8. А тут как раз оказалось, что в Linux 5.8 были масштабные изменения: 20% исходного кода ядра подверглись изменениям. Даже Линус сказал, что изменения очень большие. Они, в частности, затронули Power Management (PM). И где-то там в changelog я видел приписку, что где-то возникают конфликты с drm. Патчи к PM, я вижу, затронули

 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c            |   2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c            |   2 +-
 drivers/gpu/drm/radeon/radeon_kms.c                |   2 +-

У меня сейчас, к большому несчастью, стоит Невидиа, но используется с драйвером, nouveau. Его, я смотрю, не трогали в данном патчсете. И вот результат: иксы тут же инициализируют графику через KMS и что-то ломается. Этот ваш Wayland также может попасть в эту ловушку.

Я проверяю так: загружаюсь с графикой (с X-сервером), чтобы прошла инициализация (для чистоты эксперимента), потом прибиваю иксы и из консоли вгоняю комп в сон - комп засыпает нормально и просыпается. Загружаю иксы, возвращаюсь в консоль, засыпаю - мертвый висяк. В общем, грешу на nouveau: в PM что-то поменяли и что-то поломалось.

Вы правы. Я забыл написать, у меня sway запускается в ручном режиме, сначала грузится «голая консоль», а потом делаю exec sway. Так вот, естественно, я проверял suspend в «голой консоли» и он адекватно работал (и наверняка работает) на последнем новейшем ядре.

Похоже, что где-то в PM поломали и происходит конфликт с видеодрайвером.

В соседних темах тоже жалуются на «черный экран» после последних обновлений на разных системах и разном железе. Не знаю как в таком случае issue отправлять, но кто-то это должен сделать (кто знает как правильно), проблема похоже глобальная.

Я вот тут поискал в nouveau конкретно в кернельной багзилле. Оказалось, что такие багрепорты есть и добрые люди уже покопались, что избавило от разбирательств. Вот конкретно по nouveau описание такой же проблемы:

https://bugzilla.kernel.org/show_bug.cgi?id=213617

Но тут ситуация такая, что в Debian, начиная с 5.8.какой-то-там. начали собирать ядро с параметром CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y. Это обнаружили, сравнивая версии ядер где работало и где перестало. Обход: указать в параметрах ядра init_on_alloc=0. Я сейчас сделал - и все теперь уходит в сон и просыпается с ядром 5.10 (lts). Осталось понять, кто и что должен исправлять, так как этот параметр не про PM, а про Memory Management. Во всяком случае, в kernel/nouveau баг зафайлен.

В Arch тоже такое было у людей. Не знаю, твой ли это случай, но вот: https://bbs.archlinux.org/viewtopic.php?pid=1876347#p1876347

Вполне может быть, спасибо. Пока уже ведро не хочу «тыкать», подожду новую версию. Если не исправят попробую этот вариант. На старом все работает и ок.

В debian тоже проблему заметил (точнее на armbian, 5.10.60-sunxi). После переноса системы на SSD, а загрузчика на SPI-Flash (orange pi zero) перестал адекватно работать reboot. Вырубаться - вырубается, а загрузка дальше не идет. Правда тут хз, возможно, особенности железа и причина в этом. Poweroff при этом работает, как и прежде. Так что тут не 100% грешу на ядро.

Win+P

Кстати, вроде бы по теме. Как отключить просыпание по нажатию клавиш на клавиатуре? На тычпад не реагирует и так. Хочется будить только по кнопке «power». KDE Plasma 5

В AUR есть linux-ltsxx на выбор. Например

https://aur.archlinux.org/packages/linux-lts54/

(если туда не бэкпортировали баг)

Спасибо, но AUR не использую. Уже говорил здесь, что поставил 5.9.10-arch1-1 из Arch Linux Archive и заигнорил обновления ядра. Всё отлично работает. Через месяц-другой вновь попробую свежее, возможно, к этому времени устранят баг.

своп раздел хоть есть

Какое отношение suspend (не hibernate) имеет с swap? Причина уже давно установлена - тему прочтите.

А причем здесь hibernate? Тема была изначально про режим сна. Так может быть, что из режима сна компуктер не обязан выходить без наличия swap раздела. На нормальном дистрибутиве линукс загрузка будет упираться в черный экран.

в смысле при выходе из сна

Так может быть, что из режима сна компуктер не обязан выходить без наличия swap раздела. На нормальном дистрибутиве линукс загрузка будет упираться в черный экран.

ЯННП.

В заголовке (и тексте [и даже логах видно S3]) явно указан «suspend», что всю жизнь подразумевало «suspend to RAM» (S3). S4 всегда обозначали как hibernate или явно указывая «suspend to disk».

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