Ошибка #1281

Не работает спящий режим

Добавил(а) Andrey Volkov почти 4 года назад. Обновлено почти 4 года назад.

Статус:Обратная связьНачата:04.12.2013
Приоритет:НизкийДата выполнения:
Назначена:Igor GnatenkoГотовность:

0%

Категория:Система
Версия:20
Bugzilla-Id: Upstream bug:

Описание

Доброго времени суток! В Fedora/RFRemix 20 наблюдается такой баг в работе спящего режима: в спящий режим система уходит, но при последующем запуске либо запускает новый сеанс (а не восстанавливает старый), либо виснет при загрузке. В Fedora/RFRemix 19 такого не наблюдалось - система благополучно возобновляла сохраненный сеанс и не зависала. Система загружается в режиме UEFI (AMI Aptio 2012 года выпуска), размер swap-раздела совпадает с объемом оперативной памяти.

dmidecode.txt Magnifier (14,378 КБ) Andrey Volkov, 05.12.2013 05:22

dmesg.txt Magnifier (71,786 КБ) Andrey Volkov, 05.12.2013 05:22

lspci-knnn.txt Magnifier (3,843 КБ) Andrey Volkov, 05.12.2013 05:22

lsusb.txt Magnifier (528 байта) Andrey Volkov, 05.12.2013 05:22

disk.txt Magnifier (36 байта) Andrey Volkov, 05.12.2013 11:44

state.txt Magnifier (16 байта) Andrey Volkov, 05.12.2013 11:44

снимок20.png (40,259 КБ) Andrey Volkov, 05.12.2013 13:41

История

#1 Обновлено Alexei Panov почти 4 года назад

  • Параметр Статус изменился с Новая на Обратная связь
  • Параметр Назначена изменился с Alexei Panov на Igor Gnatenko
  • Параметр Приоритет изменился с Немедленный на Низкий
Видимо это все-таки сильно железная проблема.
У меня на 20-ой все в порядке со спящим режимом.
Размер swap-раздела все-таки должен быть в полтора раза больше оперативной памяти. Поскольку в нем может что-то хранится и до погружения в сон.
Описываем оборудование, прикладываем в виде файлов (именно в виде файлов!) к этой задаче:
  • lspci -knnn
  • dmidecode
  • lsusb
  • dmesg

#2 Обновлено Andrey Volkov почти 4 года назад

Alexei Panov, высылаю выхлоп перечисленных команд. Что касаемо swap-раздела, то на ноутбуке система ни разу его не использовала для целей, отличных от спящего режима (видимо, объем его ОЗУ избыточен даже для 64-разрядной Fedora/RFRemix с KDE 4). Поэтому я и не делаю его больше, чем объем ОЗУ - все равно большую часть времени простаивает.

#3 Обновлено Igor Gnatenko почти 4 года назад

В студию:

$ cat /sys/power/state
$ cat /sys/power/disk

Что из этого работает нормально?
# systemctl suspend
# systemctl hibernate
# systemctl hybrid-sleep

#4 Обновлено Alexei Panov почти 4 года назад

Andrey Volkov писал(а):

Alexei Panov, высылаю выхлоп перечисленных команд. Что касаемо swap-раздела, то на ноутбуке система ни разу его не использовала для целей, отличных от спящего режима (видимо, объем его ОЗУ избыточен даже для 64-разрядной Fedora/RFRemix с KDE 4). Поэтому я и не делаю его больше, чем объем ОЗУ - все равно большую часть времени простаивает.

Это не рекомендация была, это правило для корректной работы спящего режима. При любом дебаге спящего режима, первое требование - swap = mem * 1.5

#5 Обновлено Andrey Volkov почти 4 года назад

Igor Gnatenko, высылаю выхлоп $ cat /sys/power/state и $ cat /sys/power/disk. Что касается # systemctl suspend; # systemctl hibernate и # systemctl hybrid-sleep, то # systemctl suspend и # systemctl hybrid-sleep на моей системе работают одинаково (экран гаснет, индикатор питания мигает, комп не выключается, но прекращает шуметь и при нажатии кнопки питания возобновляет работу в том же сеансе). # systemctl hibernate работает явно некорректно - сеанс якобы сохраняется, комп выключается, но при повторном запуске сеанс не восстанавливается, система подвисает, а при входе в систему наблюдается баг, описанный здесь: http://redmine.russianfedora.pro/issues/1280, т.е., видимо, эти ошибки взаимосвязаны.
Alexei Panov, дело в том, что RFRemix 19, загружавшаяся на той же самой машине в режиме Legacy, нормально засыпала и пробуждалась при swap = mem. Проблемы начались именно при переезде на таблицу разделов GPT, загрузку в UEFI-режиме и RFRemix 20.

#6 Обновлено Igor Gnatenko почти 4 года назад

перед уводом в сон, что выдаёт free -m и swapon -s?

#7 Обновлено Andrey Volkov почти 4 года назад

Igor Gnatenko писал(а):

перед уводом в сон, что выдаёт free -m и swapon -s?

#8 Обновлено Andrey Volkov почти 4 года назад

См. снимок20.png. Это он и выдает.

#9 Обновлено Igor Gnatenko почти 4 года назад

Andrey Volkov писал(а):

См. снимок20.png. Это он и выдает.

Проверь на том же лайве, что и в соседней теме.

#10 Обновлено Andrey Volkov почти 4 года назад

#systemctl suspend и # systemctl hybrid-sleep ведут себя так же, как здесь: http://redmine.russianfedora.pro/issues/1281#note-6. Что касаемо # systemctl hibernate, то сеанс якобы сохраняется, комп выключается, но при повторном запуске комп пишет: Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key.

#11 Обновлено Andrey Volkov почти 4 года назад

Правда, перед тем, как выдать "Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key", UEFI пишет "system resuming" ("возобновление работы системы").

#12 Обновлено Arsen Butaev почти 4 года назад

Наблюдалась совершенно аналогичная проблема. После недавнего обновления ядра (3.11.10-301.fc20.x86_64) она исчезла и сейчас всё работает, как и было ранее в 19.

#13 Обновлено Andrey Volkov почти 4 года назад

Arsen Butaev, подтверждаю. Спящий режим работает нормально (система сохраняет сеанс, отключает комп и восстанавливает его при последующем запуске, видимо, косяк был именно в ядре). Проверю

  1. systemctl suspend,
  2. systemctl hibernate,
  3. systemctl hybrid-sleep.

После проверки отпишусь здесь.

#14 Обновлено Andrey Volkov почти 4 года назад

#systemctl suspend и # systemctl hybrid-sleep работают так же, как и раньше. # systemctl hibernate сохраняет сеанс, отключает комп и восстанавливает его при последующем запуске. Так что остался только один вопрос: почему ни одна из команд не блокирует сеанс? Это баг или фича?

Экспортировать в Atom PDF