Попробуйте создать /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 файл, как показано выше, чтобы соответствовать ему.

Не совсем понятно, каково поведение по умолчанию. Manpage для 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

Просто хочу добавить ответ пользователям 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, а также об этой проблеме глубокого сна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как настроить динамическое переключение между s2idle или глубоким режимом, зависит от того, подключен он или нет

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

      sudo apt install udev

2. проверить подключенное состояние (примечание: последняя часть пути может отличаться)

   ссылка: https://unix.stackexchange.com/a/227967

      sudo udevadm info --path=/sys/class/power_supply/ACAD

и он должен вывести что-то вроде следующего:

      E: POWER_SUPPLY_NAME=ACAD
E: POWER_SUPPLY_TYPE=Mains
E: POWER_SUPPLY_ONLINE=1
E: SUBSYSTEM=power_supply

3. далее мы подготовим сценарий, который будет использоваться для управления состоянием простоя или глубокого состояния. Я создаю сценарий в /opt/custom-scripts/auto_cycle_sleep_mode.sh, вы можете разместить скрипт в любом месте. После создания файла введите следующее

      #!/bin/bash

#This script is used to control when to put laptop in idle mode or sleep mode
#after lid closed depending if it is connected to AC or not so it does not require any manual changes

IS_PLUGGED_IN=${1:-0}

MESSAGE=""

if [ $IS_PLUGGED_IN -eq 1 ]
then
        MESSAGE="AC Plugged In, switch to idle mode"
        echo s2idle > /sys/power/mem_sleep
else
        MESSAGE="AC Unplugged, switch to deep sleep mode"
        echo deep > /sys/power/mem_sleep
fi

now=`date +'%Y-%m-%d %H:%M:%S'`

echo "[$now] - $MESSAGE" | sudo tee --append /tmp/udev.log

Выше приведен простой скрипт, который принимает параметр подключенного состояния и выводит его на /sys/power/mem_sleepи написать лог

4. далее мы создадим правило

      sudo nano /etc/udev/rules.d/80-local.rules

и введите следующее

      SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_NAME}=="ACAD", ENV{POWER_SUPPLY_TYPE}=="Mains", RUN+="/opt/custom-scripts/auto_cycle_sleep_mode.sh %E{POWER_SUPPLY_ONLINE}"

то, что делает скрипт, фильтрует нужное нам событие, которое в данном случае является состоянием POWER_SUPPLY_ONLINE, и мы передадим его нашему скрипту. если вы хотите узнать немного об udev, вот введение в udev: https://opensource.com/article/18/11/udev

5. Когда он будет готов, перезапустите службу, чтобы убедиться, что

      sudo service udev restart

6. Теперь мы можем попробовать подключить и отключить его, что в файле журнала должно вывести следующее:

      [2022-04-16 11:16:48] - AC Unplugged, switch to deep sleep mode
[2022-04-16 11:16:52] - AC Plugged In, switch to idle mode
[2022-04-16 11:22:15] - AC Unplugged, switch to deep sleep mode
[2022-04-16 11:22:23] - AC Plugged In, switch to idle mode

7. если вы столкнулись с какой-либо ошибкой, попробуйте посмотреть с помощью sudo service udev statusили же tail -f /var/log/syslog

Правила могут различаться в зависимости от различного оборудования, пожалуйста, проверьте их с помощью udevadm на шаге 2.

Если у вас есть видеокарта nvidia, эту проблему можно легко решить. Просто измените GRUB_CMDLINE_LINUX=""к GRUB_CMDLINE_LINUX="nouveau.modeset=0"в /etc/default/grubфайл затем sudo update-grub && reboot. Также проверьте в магазине приложений, возможно, вам потребуется установить дополнительные драйверы.

Если все еще не решает проблему, попробуйте это cat /sys/power/mem_sleep. Если не печатает s2idle [deep]затем проверьте это для решения.

для тех, у кого нет графики nvidia, не повезло, ребята. По состоянию на 2021 год он все еще не решен. Единственный способ решить проблему - понизить версию ядра до 4.14.0-041400-genericчто решит проблему зависания при закрытой крышке.

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

Вы можете понизить версию ядра, используя ukuuинструмент или путем ручной компиляции исходного кода. За инструмент ukuu вам нужно заплатить деньги, но если вы не хотите платить, проверьте раздел релизов github и загрузите его оттуда .

Есть страница проблемы , которая до сих пор не закрыта, но я не видел ответа от разработчиков в 2021 году.

Некоторую подробную информацию об ошибках можно найти здесь и здесь .

Мои системные характеристики :( lscpu)

      Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               55
Model name:          Intel(R) Pentium(R) CPU  N3510  @ 1.99GHz

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

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

Я использую Dell XPS13 9360 с Linux Mint 19.3. Приостановка работала нормально, пока ядро ​​не обновилось до серии 5.4. Затем у меня возникли проблемы, описанные выше. Ни одно из предложенных решений не помогло. Однако понижение версии ядра до 5.3.0-62-generic решило проблему, и приостановка теперь работает правильно. Это неподдерживаемое ядро, поэтому я попробую еще раз, когда станет доступно дальнейшее обновление ядра.