Невозможно выйти из спящего режима с помощью systemd под Ubuntu15.10

У меня возникли некоторые проблемы с получением резюме из спящего режима с использованием systemd (swsusp) для работы на Lenovo IdeaPad Z510, работающем под Ubuntu 15.10 (проблема была такой же в предыдущих версиях Ubuntu).

  • ДЕЛАЕТ: На успешно спящем компьютере (journalctl подтверждает успех), при возобновлении появляется "мертвый экран" (черный дисплей, нет видимого сеанса или взаимодействия с клавиатурой, но в журнале нет ничего, указывающего на сбой отображения / сеанса).

  • СЛЕДУЕТ: Из спящего режима восстановить сеанс из раздела подкачки и разрешить пользователю продолжить сеанс.

В качестве подсказки, если я установлю nomodeset в grub, строка GRUB_CMDLINE_LINUX_DEFAULT, резюме работает стабильно хорошо, хотя встроенное графическое оборудование явно отключено (Haswell HD Mobile 4400).

Учитывая это, я подозреваю две возможные проблемы, которые могут вызвать эту проблему:

  • На моей машине резюме со встроенным видеодрайвером (Intel i915) еще не настроено должным образом.

  • В моем чтении я столкнулся с известной проблемой ядра, которая связана с ошибкой возобновления из-за несоответствия размера памяти в файле подкачки резюме. Называется несоответствием BIOS e820, его лучше всего описать здесь: http://www.slideshare.net/joeylikernel/the-e820-trap-of-linux-kernel-hibernation.

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

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

На сегодняшний день, вот что я сделал, чтобы настроить мой компьютер для спящего режима / возобновления с помощью systemd:

  1. В etc / default / grub сконфигурируйте GRUB_CMDLINE_LINUX_DEFAULT для включения параметра возобновления, передавая UUID рассматриваемого раздела подкачки (то есть резюме =UUID=453f0121-505d-42d3-8dad-87f913e67ddc). Мой текущий GRUB_CMDLINE_LINUX_DEFAULT - GRUB_CMDLINE_LINUX_DEFAULT="тихий всплеск резюме =UUID=453f0121-505d-42d3-8dad-87f913e67ddc"
  2. Запустите sudo update-grub
  3. Редактировать / подтвердить резюме = UUID = 453f0121-505d-42d3-8dad-87f913e67ddc запись в файле резюме, расположенном в / etc / initramfs
  4. Запустите sudo update-initramfs -u
  5. Отредактируйте /etc/systemd/logind.conf, чтобы установить HandleLidSwitch = hibernate
  6. Запустите sudo service systemd-logind restart
  7. Перезагрузка для хорошей меры

Резюме будет постоянно терпеть неудачу без явных (для меня) ошибок, указывающих причину ошибки возобновления.

Итак, мой вопрос к форуму такой:

Какие инструменты отладки, системные информационные ресурсы и общее понимание того, как устранить неполадки, связанные с видео драйвером, вы можете порекомендовать?

Я весьма заинтересован в разрешении этой ситуации в контексте использования systemd в качестве решения.

Спасибо большое.

Богатые

Источник

3 ответа

Решение

Хотя я так и не получил хорошего ответа на вопрос о том, как лучше всего решать проблемы гибернации на моем ноутбуке, я наконец-то установил ядро ​​4.8 (с помощью новой установки Ubuntu 16.10), и теперь hibernate работает, как и ожидалось.

Надеюсь, это поможет людям с теми же проблемами, которые у меня были...

Источник

У меня была такая же проблема в Ubuntu Gnome 16.04. Единственным решением, которое я нашел в то время, было обновление ядра. После обновления до 4.5.3-generic проблема исчезла.

Как обновить ядро ​​Linux описано здесь.

Вы можете проверить версию своего ядра через терминал:

uname -r
Источник

Я пробовал эти варианты

acpi_osi=linux i915.enable_rc6=1 i915.lvds_downclock=1 i915.enable_fbc=1 pcie_aspm=force

и до сих пор проблема, кажется, ушла

взято по этой ссылке

РЕДАКТИРОВАТЬ:

acpi_osi = '! Windows 2012'

сейчас я использую эту опцию и до сих пор она работает как положено

РЕДАКТИРОВАТЬ

Я не эксперт, но у меня та же проблема. Моя последняя попытка (и, похоже, она работает), я удалил acpiacpid а также acpi_call пакеты... Я не знаю, связаны ли они с проблемой... но я знаю, что использую ядро ​​4.4.10, и гибернация работает хорошо.

Источник
Другие вопросы по тегам