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

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

  • DOES: С успешно подключенной машины (journalctl подтверждает успех), при возобновлении работы появляется "мертвый экран" (черный дисплей, нет видимого сеанса или взаимодействия с клавиатурой, но ничего в 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 раздела подкачки, о котором идет речь question (i.e., resume=UUID=453f0121-505d-42d3-8dad-87f913e67ddc). Мой текущий GRUB_CMDLINE_LINUX_DEFAULT - это GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=453f0121-505d-42d3-8dad-87f913e67ddc"
  2. Run sudo update-grub
  3. Edit/confirm resume=UUID=453f0121-505d-42d3-8dad-87f913e67ddc entry в файле resume, расположенном в /etc/initramfs
  4. Выполните sudo update-initramfs -u
  5. Отредактируйте /etc/systemd/logind.conf, чтобы установить HandleLidSwitch=hibernate
  6. Выполните sudo service systemd-logind restart
  7. Перезагрузитесь для хорошей меры

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

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

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

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

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

Rich

1
задан 7 November 2015 в 07:31

3 ответа

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

Hope это помогает людям с теми же проблемами, которые я имел...

1
ответ дан 3 December 2019 в 07:00

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

обновление с практическими рекомендациями ядро Linux описано здесь .

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

uname -r
2
ответ дан 3 December 2019 в 07:00

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

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

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

взятый от этого , связь

РЕДАКТИРУЕТ:

acpi_osi = '! Windows 2012'

теперь я использую этот выбор, и до сих пор он работает, как это должно быть

, РЕДАКТИРУЮТ

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

1
ответ дан 3 December 2019 в 07:00

Другие вопросы по тегам:

Похожие вопросы: