Это работало отлично 17.10, но после обновления до 18.04 вчера, когда крышка закрыта, экран выключается, но не приостанавливается должным образом.

Я много путешествую и сразу заметил тепло (и разряд батареи), когда вынул его из дорожного чемодана.

Я попытался раскомментировать эти строки в /etc/systemd/logind.conf

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

и перезапущен, но не имеет никакого значения.

Я думаю, что мне удалось выяснить, что происходит, благодаря этим двум источникам: Dell XPS 13 (9370) ArchLinux Замечания по установке и Arch Linux Forum .

По какой-то причине ноутбук больше не идет в глубокий сон, а скорее в s2idleрежим, который является просто выключенным экраном.

Диагностика проблемы

Чтобы проверить, так ли это для вашей системы, приостановите работу ноутбука, используя ваш любимый метод (закройте крышку, нажмите Fn+ End, введите pm-suspendв терминал, если вы pm-utilsустановили, или нажмите Windowsтип ключа suspendи нажмите Enterклавишу).

Проснитесь от режима и типа приостановки в терминале: sudo journalctl | grep "PM: suspend" | tail -2. Если вывод

May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit

Тогда вы не входите в глубокий сон. Вы также можете проверить, cat /sys/power/mem_sleepкоторый должен вернуть

[s2idle] deep

который подтверждает, что режимом приостановки по умолчанию является s2idle (так как он выделен скобками).

Временное исправление

Чтобы попробовать временное исправление, сделайте это echo deep > /sys/power/mem_sleepкак пользователь root. Проверьте, что это было успешно, посмотрев на выход cat /sys/power/mem_sleepкоторого должен быть

s2idle [deep]

затем приостановите работу ноутбука и снова проснитесь. Если sudo journalctl | grep "PM: suspend" | tail -2возвращается

May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit

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

Постоянное исправление

Чтобы сделать его постоянным, вы должны отредактировать командную строку загрузчика. Для этого отредактируйте от имени пользователя root файл / etc / default / grub, например, запустив sudo -H gedit /etc/default/grub. Заменить линию

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

с участием

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

и восстановить вашу конфигурацию grub (запустить sudo grub-mkconfig -o /boot/grub/grub.cfg).

Попробуйте создать /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

И перезагрузка. Кажется, это работает для меня, хотя я не уверен, что я также не получил улучшения с /etc/systemd/logind.confизменением, которое я сделал первым. В любом случае, не наблюдается никакого тепла или шум вентилятора во время приостановки с отсечной крышкой, и он не отвечает на пинг через Wi - Fi либо, что я уже получал, с перерывами, до этого .

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

Пробовал на моем XPS 13 9370, я не знаю о старых моделях, хотя, похоже, они будут похожи.

Я попытался установить pm-utilsи использовать, pm-suspendи это, похоже, довольно эффективно приостанавливало работу, поэтому я хотел посмотреть, смогу ли я сделать systemd-suspendто же самое.

Я просмотрел сценарии, pm-utilsчтобы выяснить, что он на самом деле делал, и похоже, что в этой ситуации он делал echo -n "mem" > /sys/power/state. Поэтому я создал /etc/systemd/sleep.confфайл, как показано выше, чтобы соответствовать ему.

Не совсем понятно, каково поведение по умолчанию. На странице man systemd-sleep.confсказано, что дистрибутив должен включать /etc/systemd/sleep.confв себя закомментированные значения по умолчанию, чтобы вы могли видеть эту информацию, но в Ubuntu этот файл отсутствует. Я заметил, что если cat /sys/power/stateвы получите:

freeze mem

Я предполагаю, что это то, что он делает по умолчанию. Я предполагаю, что это freezeможет быть принято, поскольку оно не выдает ошибку, которая в противном случае могла бы вызвать переход systemd mem, но, возможно, не работает должным образом или надежно по сложным причинам, которые мы, похоже, не можем определить. Так что просто отправка memвместо этого является обнадеживающим ударом, чтобы избежать этого и просто делать то, что pm-suspendделает.

Я подозреваю, что настройка SuspendMode на самом деле излишня и ничего не делает в любом случае. Я подозреваю это, потому что cat /sys/power/diskпросто получает вас:

[disabled]

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

Другие ответы здесь отличные, глубокие и хорошо проработанные.

К сожалению, они не работают для моей конкретной машины :(

Если у вас есть графика nVidia, кажется, есть исправление, которое работает для большого числа людей, услужливо предоставленное cascagrossa в ответе на этот вопрос: Ubuntu 18.04 падает при выходе из режима ожидания

Предполагается, что он является ошибочным драйвером nouveau и может решить проблемы с приостановкой, добавив nouveau.modeset = 0 в grub, и это было подтверждено в комментариях за помощь в устранении проблемы и для других.

У меня есть проблемная графика Intel на моей проблемной машине, и, что любопытно, у меня не было проблем с приостановкой работы с Ubuntu или Kubuntu 18.04 как минимум на 3 других машинах (моей и моей подруги), так почему эта конкретная машина так обескуражена? неясно.

Я рекомендую всем, у кого возникла проблема такого рода, выполнить следующие действия, чтобы помочь выявить проблему:

1. У вас есть графика nVidia? Если это так, попробуйте nouveau.modeset = 0 grub trick.

2. Проверьте, что приостановка работает вообще. Если вы закрываете крышку, а затем открываете ее позже, и она не просыпается, может показаться, что она не может «возобновить».

   • Вы должны иметь возможность вручную выбрать приостановку на любом рабочем столе, но она немного скрыта в Gnome Shell - вы можете либо нажать и удерживать кнопку питания в верхнем правом меню экрана, либо нажать эту кнопку, удерживая клавишу Alt, или нажать клавишу Super и введите в «приостановить»

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

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

   • В моем случае (на одном проблемном ноутбуке) экран гаснет, но индикатор питания остается включенным, и если вентилятор работает, он продолжает работать. Аппарат не реагирует на нажатия клавиш, движения сенсорной панели, щелчки или нажатия кнопок питания. Единственное, что можно сделать, это закрыть его.

   • Я пытался проигрывать музыку во время приостановки (чтобы убедиться, что экран не просто гаснет), но музыка останавливается, и машина в основном зависла.

3. Попробуйте свой компьютер с Live USB 18.04 и проверьте, есть ли у вас похожие проблемы с приостановкой.

   • Это просто подтвердит, что проблемы с приостановкой не связаны с какими-либо дополнительными программами, которые вы установили.

   • В моем случае я подозревал, что это потому, что я установил tlp, который мог каким-то образом вмешиваться в режим приостановки, но такое же поведение происходило с Live USB Ubuntu 18.04 и Kubuntu 18.04.

4. Попробуйте два других хорошо изученных решения, предоставленных здесь monty47 и StrangeNoises, и посмотрите, получите ли вы хорошие результаты.

   • Похоже, что они помогли многим людям восстановить работоспособность приостановки 18.04 и, возможно, больше связаны с переходом машины в состояние s2idle, а не в спящий (глубокий) режим обычного «приостановления».

5. Если ни одно из решений не помогло решить ваши проблемы с приостановкой 18.04, попробуйте принять общепринятый ответ на этот вопрос: сбой Ubuntu 18.04 при возобновлении работы с приостановкой

   • Решение, предоставленное Маталаком (который также задал вопрос), состояло в том, чтобы использовать UKUU, чтобы попробовать старое ядро ​​4.14.

   • У моей проблемной машины не было проблем с приостановкой работы с Ubuntu 17.10 и Kubuntu 17.10, поэтому имеет смысл, поскольку 17.10 использует ядро ​​4.14. Теперь он нормально приостанавливается как в Ubuntu 18.04, так и в Kubuntu 18.04 с использованием ядра 4.14.

6. Если вы попробовали другие решения и смогли исправить проблемы с приостановкой, вернувшись к ядру 4.14, вас может заинтересовать отчет об ошибке: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/ 1774950

   • Похоже, что он влияет только на несколько машин с определенной комбинацией аппаратного обеспечения, и его трудно определить среди других проблем, связанных с Nouveau, или проблем с s2idle.

   • Похоже, он более распространен среди тех, кто использует Bay Trail Atom Celeron / Pentium, но другие сообщают о сходной проблеме с другими машинами.

   • Если вы сможете проверить свой kern.log после неудачной приостановки (то есть после того, как вам пришлось выключить компьютер и перезагрузить компьютер), вы можете заметить, что в нем написано PM: приостановить вход (глубокий), и у вас больше не будет записей, кроме много строк загрузки снова.

   • В настоящее время существует исправление, которое, похоже, решает проблему.

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

Также пытается собрать «Приостановить проблемы в 18.04» вместе в этой теме: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Я считаю, что эта ошибка ядра связана с:

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

Смотрите комментарий № 3, в частности:

[…] На самом деле намеренно использовать s2idle на этой машине с последним вышестоящим ядром.

Просто хочу добавить ответ пользователям Thinkpad X1 Carbon 6th Gen, у которых есть похожий симптом - разряд батареи во время ожидания, вызванный также отсутствием режима глубокого сна.

Эта проблема обсуждается в этой теме на форуме Lenovo , короче говоря, X1C6 решил поддерживать Windows Modern Standby. Если вы внимательно прочитаете эту ветку, вы увидите, что, хотя симптом является общим, основные причины сильно различаются между XPS 13 9370 и X1C6 . Например, вывод cat /sys/power/mem_sleepна X1C6 будет указывать только [s2idle]на отсутствие поддержки для deepсна.

Решения, опубликованные до сих пор по этому вопросу, относятся только к XPS 13, а не к X1C6. Насколько я понимаю, лучшее решение проблемы режима ожидания X1C6 - это применить DSDTпатч, сначала выпущенный Delta Xi , а затем обновленный PombeirP . В этом посте рассказывается, как применить исправление, но перед любыми действиями обязательно прочитайте пост и все его обновления.

Я написал краткое описание проблем, связанных с установкой Ubuntu 18.04 на Thinkpad X1 Carbon 6th Gen, включая решения, которые я нашел о проблеме медленной загрузки, вызванной LVM, а также об этой проблеме глубокого сна .

Я использую Lenovo ThinkPad Edge E531 и столкнулся с аналогичной проблемой, когда машина не смогла войти в глубокий сон. Поведение было прерывистым, и при возобновлении иногда приводило к прекращению работы тачпада при отключении Wi-Fi.

Я попробовал дюжину или около того исправлений, предложенных онлайн, но единственное решение, которое мне помогло, это установка UKUU и обновление ядра до 4.19.11-041911-generic.

Просто, чтобы завершить этот Вопрос (надеюсь ...), у меня только (июль 2019 года) было обновление для моего 18.04 LTS с HWE, которое утверждает, что решило эту проблему специально для Dell XPS 13 (в том числе не входит в s2idle .)

Кстати, я только что заменил батарею на своем 2016 XPS 13 (9350) на Ubuntu 16.04 и kernél 4.14.12-041412-generic (машина была настроена в начале 2016 года с 15.10 и пользовательское ядро ​​было обновлено до 16.04). Перед заменой крышка перевела Linux в режим ожидания, как и должно (хотя, если вы подключили блок питания, находясь в режиме ожидания, или подключили его, например, изменили состояние, в котором, по мнению Linux, он работал, он будет работать очень медленно до перезагрузки) , В любом случае, после замены (раздувшаяся батарея) ноутбук перезагрузится, чтобы притереть крышку при закрытой крышке.

Установка управления питанием на «Стандартное» (из «Расширенного») в «Конфигурация первичной батареи» в EFI BIOS Dell / AMI (которое можно вызвать, удерживая Fn-F2 во время загрузки), похоже, решило проблему.

Перебрал множество перечисленных решений и ничего не получилось для popOS на xps 9560 :(

Пока я не увидел это смешное исправление на сайте Dell, который был взят из сообщения LTT.

Итак, мое предварительное решение, которое, кажется, работает до сих пор: включение и выключение определенных настроек BIOS. Я знаю, это звучит совершенно идиотски, но я клянусь, что, похоже, это работает из того, что я тестировал до сих пор.

В частности, я либо выключил настройки и / или выбрал другую опцию для настройки, применил ее, затем вернул обратно и применил ее. Настройки, которые я переключал туда и обратно:

• Конфигурация системы> Сенсорный экран (выключен, затем снова включен)

• Управление питанием> Время автоматического включения (переключил его на другой параметр, затем снова на «Отключено»)

• Управление питанием> Пробуждение от док-станции Dell USB-C (выключено, затем включено)

Отлично работает сейчас. , , ,