LINUX.ORG.RU

Не просыпается после suspend to RAM.

 ,


0

1

С неделю назад началась такая хрень: после suspend to RAM (команда sudo s2ram -f) комп выходит из спячки, но только один раз. Если его снова отправить в спячку и снова пробудить, то системник просыпается, но изображения нет, клавиатура только однократно реагирует на Ctrl+Alt+F1 (вываливает в консоль и ждет логин) и после этого отрубается полностью. Дальше - только хард ресет.

Как это дело разруливать? Файл dmesg вообще никакой информации не содержит, последняя запись в нем обычно на 3-й секунде от начала загрузки, дальше как будто никаких событий и не происходило вообще, для чего он в системе нужен - загадка. В Xorg.0.log тоже ничего полезного не нашёл. Вот хвост Xorg.0.log непосредственно перед подачей команды s2ram -f:

[  3682.229] (--) NVIDIA(GPU-0): 
[  3682.229] (--) NVIDIA(GPU-0): DFP-1: disconnected
[  3682.229] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS
[  3682.229] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
[  3682.229] (--) NVIDIA(GPU-0): 
[  3682.239] (II) NVIDIA(0): Setting mode "CRT-1:nvidia-auto-select"
[  3682.279] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[  3682.279] (II) NVIDIA(0):     may not be running or the "AcpidSocketPath" X
[  3682.279] (II) NVIDIA(0):     configuration option may not be set correctly.  When the
[  3682.279] (II) NVIDIA(0):     ACPI event daemon is available, the NVIDIA X driver will
[  3682.279] (II) NVIDIA(0):     try to use it to receive ACPI event notifications.  For
[  3682.279] (II) NVIDIA(0):     details, please see the "ConnectToAcpid" and
[  3682.279] (II) NVIDIA(0):     "AcpidSocketPath" X configuration options in Appendix B: X
[  3682.279] (II) NVIDIA(0):     Config Options in the README.
[  3682.302] (II) event1  - Power Button: is tagged by udev as: Keyboard
[  3682.302] (II) event1  - Power Button: device is a keyboard
[  3682.302] (II) event0  - Power Button: is tagged by udev as: Keyboard
[  3682.303] (II) event0  - Power Button: device is a keyboard
[  3682.304] (II) event14 - BTC  USB Keyboard: is tagged by udev as: Keyboard
[  3682.304] (II) event14 - BTC  USB Keyboard: device is a keyboard
[  3682.305] (II) event15 - BTC  USB Keyboard Consumer Control: is tagged by udev as: Keyboard
[  3682.305] (II) event15 - BTC  USB Keyboard Consumer Control: device is a keyboard
[  3682.306] (II) event16 - BTC  USB Keyboard System Control: is tagged by udev as: Keyboard
[  3682.306] (II) event16 - BTC  USB Keyboard System Control: device is a keyboard
[  3682.358] (II) event17 - KYE SYSTEMS CORP. Wired Mouse: is tagged by udev as: Mouse
[  3682.358] (II) event17 - KYE SYSTEMS CORP. Wired Mouse: device is a pointer

После попытки пробуждения (комп спал более часа) перегрузился в другую систему и оттуда прочитал Xorg.0.log. В конце файла было дописано несколько строк:

[  3755.013] (II) event1  - Power Button: device removed
[  3755.026] (II) event0  - Power Button: device removed
[  3755.037] (II) event14 - BTC  USB Keyboard: device removed
[  3755.043] (II) event16 - BTC  USB Keyboard System Control: device removed
[  3755.054] (II) event17 - KYE SYSTEMS CORP. Wired Mouse: device removed
[  3755.076] (II) event15 - BTC  USB Keyboard Consumer Control: device removed

Никаких следов не вижу.

★★★

Ответ на: комментарий от t184256

Зайди по SSH через проводную сеть и мониторь логи так?

Ну так логи прочитать проблем нет, после невыхода из спячки делаю хард ресет и гружусь в другую систему (на другом разделе). И из другой системы могу прочитать логи без проблем, прям как они были на момент попытки выхода из спячки. Дело не в недоступности логов, а в отсутствии какой-либо инфы в них. Туда просто ничего не пишется.

Или речь не о логах dmesg и Xorg.0.log?

Chord ★★★
() автор топика
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от drl

Что-то я не слышал о таких службах. Да и видео отображается (в смысле в консоль выскочить могу, там текст виден)

Да и как служба нвидии может повлиять на то, что клава после пробеждения не работает?

Chord ★★★
() автор топика

На другой версии ядра повторяется проблема? Я в nixos ловил баги при выходе из suspend(не эту), а на дебиан\генте - нет. Вангую, что именно ядро виновато. В общем на LTS ядре надо пробовать

serg002 ★★★
()
Последнее исправление: serg002 (всего исправлений: 4)
Ответ на: комментарий от serg002

s2ram (из одноименного пакета) - это я так понял просто обертка над echo mem > /sys/power/state, через эту команду, кстати, такой же дефект, не просыпается.

В другой системе с ядром 5.4 этого нет, но и в текущей системе на ядре 5.15 тоже все работало ещё неделю назад. Ядро не обновлял уже несколько месяцев.

Chord ★★★
() автор топика
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от Chord

но и в текущей системе на ядре 5.15 тоже все работало ещё неделю назад. Ядро не обновлял уже несколько месяцев.

Перечитай свою фразу. Смысл ее такой: я ничего не обновлял, оно работало еще неделю назад, а сейчас не работает. Получается, что ты ничего не менял в системе. Неделю назад оно работало, а сейчас не работает. Если да - тогда это магия

Если нет - тогда формулируй свои мысли чётче

serg002 ★★★
()
Последнее исправление: serg002 (всего исправлений: 1)
Ответ на: комментарий от serg002

Ядро, линукс-фирмваре и дрова нвидии не обновлялись.

Другие обновления были, много чего. Что, кроме ядра и дров нвидии могло повлиять?

Chord ★★★
() автор топика

s2ram

s2ram - оболочка вокруг механизма приостановки работы ядра в оперативной памяти, позволяющая пользователю выполнять некоторые манипуляции с графическим адаптером из пользовательского интерфейса перед приостановкой и после возобновления, что может помочь вернуть графику (и всю систему) к жизни после возобновления.

Входит в пакет µswsusp. А крайнее упоминание, в новостях на оф. сайте утилиты, от 2011 года.

Ну не знаю, динозавр какой-то, имхо. )

UPD. Кстати, особенности онлайн-переводчиков. Google перевел «from the user land» как «с пользовательской земли». А DeepL - «из пользовательского интерфейса».

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 6)