Debug suspend/hibernate

vasek	# 6 лет назад (отредактировано 3 года, 3 месяца назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Время от времени появляются вопросы по решению проблем с suspend и hidernate. Информации на этот счет вроде бы и много, а толку от решения данной проблемы мало. Частенько вроде бы и причина известна, а решить не всегда удается. Это к тому, что решение данной проблемы не всегда удается. Но, как говорят, попытка не пытка ….. и пробовать провести отладку следует всегда. В любом случае польза будет — всегда что то узнаешь новое, что то лучше поймешь. И основная цель статьи — собрать разрозненную информацию в одном месте, чтобы не рыскать в длительных поисках по инету, а лучше потратить это время на проведение анализа по данной проблеме. Описание состояний «сна» Безусловно, чтобы заниматься анализом, необходимо иметь представление о возможных состояниях «сна» S1 — S5, являющихся частью Power States (за подробностями отсылаю к спецификации ACPI) S0 - Working, т.е. обычная работа, все устройства включены. S1 (POS - Power on Suspend), отключается питание от жесткого диска, некоторых карт расширения, плюс, гасится монитор. Все остальные компоненты (процессор, оперативная память, чипсет…) работают в штатном режиме, возможен только переход на пониженные частоты. Устройства, которые не обозначили, что они должны оставаться включенными, могут быть отключены. Никакие регистры ни у CPU, ни у чипсета, ни у устройств в этом состоянии не сбрасываются. Благодаря этому пробуждение происходит очень быстро. S2 (STI) - более глубокое состояние сна, чем S1, процессор отключен, отключено и не используемое оборудование. Ближе к состоянию S3, разница между S2 и S3 минимальная, и чаще всего S2 вообще не выделяют в отдельное состояние. S3 (STR - Suspend to RAM), назывываемый как suspend, перед переходом вся информация о состоянии различных компонентов сохраняется в оперативной памяти, после чего все остальные устройства отключаются (процессор и часть чипсета отключаются полностью с потерей контекста и содержимого практически всех регистров), остается только дежурное питание. После пробуждения из S3 процессор начинает выполнять код с ResetVector, т.е. чтобы правильно «проснуться», ему нужно восстановить весь контекст для себя и чипсета. Вот на этом то этапе, как правило, и возникает много проблем. S4 (STD - Suspend to Disk), называемый как hibernate, содержимое памяти сбрасывается на диск и система отключает все устройства и подачу питания. После включения система стартует как обычно. Система, находящаяся в S4, может быть также переведена в G3 Mechanical Off (Механическое выключение) и все ещё оставаться в S4, сохраняя информацию о состоянии так, что можно восстановить операционное состояние после подачи питания. S5 (Soft-Off) - хитрый режим, даже на схеме в спецификации ACPI стоит отдельно от S0-S4 и обозначен как G2 (S5) + к этому его название Soft-Off (мягкое выключение), вообщем система отключена, но дежурное питание присутствует. Иногда называют этот режим hybrid, иногда Suspend to both. Описывать его подробно не буду, что-нибудь да напутаю. Некоторые нюансы этого режима: - из S4/S5 система может быть выведена по сигналу, либо по Wake-сигналу от устройства, либо по нажатию кнопки питания. - в отличие от обесточивания (выдёргиванием шнура из розетки) может не произойти совсем полного обесточивания всех частей ноутбука — не забывайте о дежурном питании (на некоторых ноутбуках имеется даже две разные кнопки выключения/включения. Из всех этих состояний только состояния S1 и S3 относятся к обеспечивающим режимам энергосбережения. В большинстве случаев проблема отказа suspend/hibernate — драйвера + железо и в меньшей степени кривизна таблиц ACPI (BIOS) Первый уровень Debug /Отладки Данный уровень предназначен для получения оценки состояния прооблемы и получения определенной дополнительной информации, которую способен без проблем выполнить обычный пользователь. Описывать не буду, все хорошо расписано в Wiki Ubuntu: - Debugging Suspend - Debugging Hibernate PS … как вегда забыл указать базовый документ Небольшие уточнения и рекомендации. 1. Если посмотреть вывод $ cat /sys/power/state freeze mem disk то видим 3 состояния - freeze - соответствует состоянию S1 (Power on Suspend) - mem - соответствует состоянию S3 (Suspend to RAM) - disk - соответствует состоянию S4 (Suspend to Disk) И начинают всегда проверку (echo freeze…mem…disk > /sys/power/state)с самого легкого состояния freeze, что можно заметить и в приведенных ссылках. EDIT (январь 2018) - для удобства (чтобы не использовать su) рекомендую использовать команду, типа - echo mem \| sudo tee /sys/power/state 2. От себя дополню, что лучше первоначально сделать эту проверку с минимальным окружением, а для этого рекомендую загрузиться в режиме восстановления (Recovery shell) rescue (другое название, single) - в меню Grub прописать параметр загрузки rescue или single и после окончания загрузки (и ввода пароля root) пробовать варианты echo freeze (mem, disk) > /sys/power/state .... а потом уже пробовать в обычном режиме (при нормальной загрузке). PS - раньше можно было проверить в режиме emergency, но сейчас из этого режима не работает. PSS - иногда также неплохо проверить уход в suspend/hibernate прямо из консоли, не загружая ни какие DE или WM ... 3. Иногда после пробуждения экран остается темным и не понятно что это …. В этих случаях рекомендую нагрузить диск, точнее набрать в слепую find / и если светодиод жесткого диска светится, значит система работает. Могут быть нюансы с прерыванием команды. 4. Иногда полезно запустить suspend/hibernate в режиме повышенного логирования $ SYSTEMD_LOG_LEVEL=debug systemctl suspend Возможно будут какие то дополнительные записи/логи PS… Лично мое мнение, все что написано в Wiki Ubuntu, считаю ерундой и никогда этого не делаю. Вместо этого проверяю последовательно режимы freeze, mem, hibernate (# echo режим > /sys/power/state) …… и потом сразу перехожу к следующему этапу, начинаю со скрипта + pm_trace, а потом в зависимости от ситуации использую другие способы, описанные там. Сылку на Wiki Ubuntu не привести не мог, как ни крути, все равно это информация Второй уровень Debug /Отладки Данный уровень отладки серъезнее предыдущего и частенько используется и разработчиками и продвинутыми пользователями, описывать его то же не буду (нет смысла переписывать), а просто даю ссылку Но самым интересным в этой статье, на мой взгляд, является ссылка на очень хороший скрипт для отладки suspend (suspendresume) - на выходе получается несколько выходных файлов: лог вызова драйверов (и не только их), вшитых в ядро + лог ftrace + временная диаграмма (пример диаграммы) Как использовать — расписано в файле этого пакета. Наше ядро имеет все необходимые флаги для использования этого скрипта `CONFIG_PM_DEBUG=y CONFIG_PM_SLEEP_DEBUG=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_KPROBES=y CONFIG_KPROBES_ON_FTRACE=y` Ну вот вообщем то и все …. думаю пригодится..... PS ... способы отладки, описанные в статье на первый взгляд могут показаться ничего незначащими, но это первое впечатление. Например, rtc trace - написано всего 3 строчки, но сам метод очень хорош - позволяет сохранить последнюю точку события PM в RTC после перезагрузки (и зачастую даже после падения), что поможет произвести отладку (отследить в demsg) зависания во время suspend/hibernate, но чтобы понять суть этого способа придется погрузится в поиск и чтение дополнительной литературы, как правило, на en ... Это относится и к другим способам, описанным в указанной ссылке. Это я к тому, что это только указатель/список возможных способов отладки, а их выбор и конкретное применение требует дополнительной проработки вопроса. Ошибки не исчезают с опытом - они просто умнеют

# 6 лет назад (отредактировано 3 года, 3 месяца назад)

Сообщения: 11320

Участник с: 17 февраля 2013

Время от времени появляются вопросы по решению проблем с suspend и hidernate.
Информации на этот счет вроде бы и много, а толку от решения данной проблемы мало. Частенько вроде бы и причина известна, а решить не всегда удается.
Это к тому, что решение данной проблемы не всегда удается. Но, как говорят, попытка не пытка ….. и пробовать провести отладку следует всегда. В любом случае польза будет — всегда что то узнаешь новое, что то лучше поймешь.
И основная цель статьи — собрать разрозненную информацию в одном месте, чтобы не рыскать в длительных поисках по инету, а лучше потратить это время на проведение анализа по данной проблеме.
Описание состояний «сна»
Безусловно, чтобы заниматься анализом, необходимо иметь представление о возможных состояниях «сна» S1 — S5, являющихся частью Power States (за подробностями отсылаю к спецификации ACPI)
S0 - Working, т.е. обычная работа, все устройства включены.
S1 (POS - Power on Suspend), отключается питание от жесткого диска, некоторых карт расширения, плюс, гасится монитор. Все остальные компоненты (процессор, оперативная память, чипсет…) работают в штатном режиме, возможен только переход на пониженные частоты. Устройства, которые не обозначили, что они должны оставаться включенными, могут быть отключены. Никакие регистры ни у CPU, ни у чипсета, ни у устройств в этом состоянии не сбрасываются. Благодаря этому пробуждение происходит очень быстро.
S2 (STI) - более глубокое состояние сна, чем S1, процессор отключен, отключено и не используемое оборудование. Ближе к состоянию S3, разница между S2 и S3 минимальная, и чаще всего S2 вообще не выделяют в отдельное состояние.
S3 (STR - Suspend to RAM), назывываемый как suspend, перед переходом вся информация о состоянии различных компонентов сохраняется в оперативной памяти, после чего все остальные устройства отключаются (процессор и часть чипсета отключаются полностью с потерей контекста и содержимого практически всех регистров), остается только дежурное питание. После пробуждения из S3 процессор начинает выполнять код с ResetVector, т.е. чтобы правильно «проснуться», ему нужно восстановить весь контекст для себя и чипсета. Вот на этом то этапе, как правило, и возникает много проблем.
S4 (STD - Suspend to Disk), называемый как hibernate, содержимое памяти сбрасывается на диск и система отключает все устройства и подачу питания. После включения система стартует как обычно. Система, находящаяся в S4, может быть также переведена в G3 Mechanical Off (Механическое выключение) и все ещё оставаться в S4, сохраняя информацию о состоянии так, что можно восстановить операционное состояние после подачи питания.
S5 (Soft-Off) - хитрый режим, даже на схеме в спецификации ACPI стоит отдельно от S0-S4 и обозначен как G2 (S5) + к этому его название Soft-Off (мягкое выключение), вообщем система отключена, но дежурное питание присутствует. Иногда называют этот режим hybrid, иногда Suspend to both. Описывать его подробно не буду, что-нибудь да напутаю.
Некоторые нюансы этого режима:
- из S4/S5 система может быть выведена по сигналу, либо по Wake-сигналу от устройства, либо по нажатию кнопки питания.
- в отличие от обесточивания (выдёргиванием шнура из розетки) может не произойти совсем полного обесточивания всех частей ноутбука — не забывайте о дежурном питании (на некоторых ноутбуках имеется даже две разные кнопки выключения/включения.
Из всех этих состояний только состояния S1 и S3 относятся к обеспечивающим режимам энергосбережения.
В большинстве случаев проблема отказа suspend/hibernate — драйвера + железо и в меньшей степени кривизна таблиц ACPI (BIOS)

Первый уровень Debug /Отладки
Данный уровень предназначен для получения оценки состояния прооблемы и получения определенной дополнительной информации, которую способен без проблем выполнить обычный пользователь.
Описывать не буду, все хорошо расписано в Wiki Ubuntu:
- Debugging Suspend
- Debugging Hibernate
PS … как вегда забыл указать базовый документ
Небольшие уточнения и рекомендации.
1. Если посмотреть вывод
$ cat /sys/power/state
freeze mem disk
то видим 3 состояния
- freeze - соответствует состоянию S1 (Power on Suspend)
- mem - соответствует состоянию S3 (Suspend to RAM)
- disk - соответствует состоянию S4 (Suspend to Disk)
И начинают всегда проверку (echo freeze…mem…disk > /sys/power/state)с самого легкого состояния freeze, что можно заметить и в приведенных ссылках.

EDIT (январь 2018) - для удобства (чтобы не использовать su) рекомендую использовать команду, типа - echo mem | sudo tee /sys/power/state

2. От себя дополню, что лучше первоначально сделать эту проверку с минимальным окружением, а для этого рекомендую загрузиться в режиме восстановления (Recovery shell) rescue (другое название, single) - в меню Grub прописать параметр загрузки rescue или single и после окончания загрузки (и ввода пароля root) пробовать варианты echo freeze (mem, disk) > /sys/power/state .... а потом уже пробовать в обычном режиме (при нормальной загрузке).
PS - раньше можно было проверить в режиме emergency, но сейчас из этого режима не работает.

PSS - иногда также неплохо проверить уход в suspend/hibernate прямо из консоли, не загружая ни какие DE или WM ...

3. Иногда после пробуждения экран остается темным и не понятно что это ….
В этих случаях рекомендую нагрузить диск, точнее набрать в слепую find / и если светодиод жесткого диска светится, значит система работает. Могут быть нюансы с прерыванием команды.
4. Иногда полезно запустить suspend/hibernate в режиме повышенного логирования
$ SYSTEMD_LOG_LEVEL=debug systemctl suspend
Возможно будут какие то дополнительные записи/логи

PS… Лично мое мнение, все что написано в Wiki Ubuntu, считаю ерундой и никогда этого не делаю. Вместо этого проверяю последовательно режимы freeze, mem, hibernate (# echo режим > /sys/power/state) …… и потом сразу перехожу к следующему этапу, начинаю со скрипта + pm_trace, а потом в зависимости от ситуации использую другие способы, описанные там. Сылку на Wiki Ubuntu не привести не мог, как ни крути, все равно это информация

Второй уровень Debug /Отладки
Данный уровень отладки серъезнее предыдущего и частенько используется и разработчиками и продвинутыми пользователями, описывать его то же не буду (нет смысла переписывать), а просто даю ссылку
Но самым интересным в этой статье, на мой взгляд, является ссылка на очень хороший скрипт для отладки suspend (suspendresume) - на выходе получается несколько выходных файлов: лог вызова драйверов (и не только их), вшитых в ядро + лог ftrace + временная диаграмма (пример диаграммы) Как использовать — расписано в файле этого пакета.
Наше ядро имеет все необходимые флаги для использования этого скрипта

CONFIG_PM_DEBUG=y
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
 CONFIG_KPROBES=y
 CONFIG_KPROBES_ON_FTRACE=y

Ну вот вообщем то и все …. думаю пригодится.....

PS ... способы отладки, описанные в статье на первый взгляд могут показаться ничего незначащими, но это первое впечатление. Например, rtc trace - написано всего 3 строчки, но сам метод очень хорош - позволяет сохранить последнюю точку события PM в RTC после перезагрузки (и зачастую даже после падения), что поможет произвести отладку (отследить в demsg) зависания во время suspend/hibernate, но чтобы понять суть этого способа придется погрузится в поиск и чтение дополнительной литературы, как правило, на en ...
Это относится и к другим способам, описанным в указанной ссылке.
Это я к тому, что это только указатель/список возможных способов отладки, а их выбор и конкретное применение требует дополнительной проработки вопроса.

Ошибки не исчезают с опытом - они просто умнеют

Aivar	# 6 лет назад (отредактировано 6 лет назад)
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	vasek, спасибо за труд! С тех пор как поменял видеокарту у меня напрочь отвалилась гибернация. При всем при том suspend-to-ram работает нормально. Как только поборю лень, обязательно протестирую трабл по вашему гайду. ) Да, трабл только с блобом nvidia, с нуво проблем нет.

Aivar

# 6 лет назад (отредактировано 6 лет назад)

Темы: 4

Сообщения: 6897

Участник с: 17 февраля 2011

vasek, спасибо за труд! С тех пор как поменял видеокарту у меня напрочь отвалилась гибернация. При всем при том suspend-to-ram работает нормально.
Как только поборю лень, обязательно протестирую трабл по вашему гайду. )

Да, трабл только с блобом nvidia, с нуво проблем нет.

vasek	# 6 лет назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Для надежности записи логов требуется мягкая перегрузка - правда это не всегда помогает, но для спокойствия рекомендую при проведении отладки изменить значения параметров kernel.panic = 10 kernel.panic_on_oops = 1 Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Для надежности записи логов требуется мягкая перегрузка - правда это не всегда помогает, но для спокойствия рекомендую при проведении отладки изменить значения параметров
kernel.panic = 10
kernel.panic_on_oops = 1

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 6 лет назад (отредактировано 6 лет назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Aivar Как только поборю лень, обязательно протестирую трабл по вашему гайду. ) Это не гарантирует 100% успеха .... а тем более hibernate, этот режим самый тухлый - не даром он не стоит по умолчанию в Linux ..... и, главное, этот хороший скрипт работает только для suspend Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет назад (отредактировано 6 лет назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Aivar
Как только поборю лень, обязательно протестирую трабл по вашему гайду. )

Это не гарантирует 100% успеха .... а тем более hibernate, этот режим самый тухлый - не даром он не стоит по умолчанию в Linux ..... и, главное, этот хороший скрипт работает только для suspend

Ошибки не исчезают с опытом - они просто умнеют

Aivar	# 6 лет назад (отредактировано 6 лет назад)
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Учту. Смотрю, любите вы это дело, т.е. дебагеры и т.д. ) В мое время это называлось проще - отладчик. Собственно, так оно и переводится. vasek а тем более hibernate, этот режим самый тухлый Так в том вся и непонятка... Комп тупо виснет даже не успев скинуть память в своп... REISUB не помогает. К чему тут видеодрайвер???

Aivar

# 6 лет назад (отредактировано 6 лет назад)

Темы: 4

Сообщения: 6897

Участник с: 17 февраля 2011

Учту.
Смотрю, любите вы это дело, т.е. дебагеры и т.д. ) В мое время это называлось проще - отладчик. Собственно, так оно и переводится.

vasek
а тем более hibernate, этот режим самый тухлый

Так в том вся и непонятка... Комп тупо виснет даже не успев скинуть память в своп... REISUB не помогает. К чему тут видеодрайвер???

vasek	# 6 лет назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Aivar Комп тупо виснет даже не успев скинуть память в своп Для этого случая есть другие отладки ........ получение дампа упавшего ядра........ + утилиты для его исследования .... но лучше этим не заниматься....мозг вскипит... а выход кот наплакал ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Aivar
Комп тупо виснет даже не успев скинуть память в своп

Для этого случая есть другие отладки ........ получение дампа упавшего ядра........ + утилиты для его исследования .... но лучше этим не заниматься....мозг вскипит... а выход кот наплакал ...

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 6 лет назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Aivar Комп тупо виснет Забыл спросить ...... cat /proc/sys/kernel/panic ......... случайно не равен 0 Ошибки не исчезают с опытом - они просто умнеют

Aivar	# 6 лет назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Равен.

vasek	# 6 лет назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Aivar Равен. Потому и висит - ждет команды на reboot ........ Я всегда ставлю равным 10 ........ смотри пост выше .....по истечение 10с комп автоматом идет на reboot, если, конечно, нет ничего более серьезного. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Aivar
Равен.

Потому и висит - ждет команды на reboot ........
Я всегда ставлю равным 10 ........ смотри пост выше .....по истечение 10с комп автоматом идет на reboot, если, конечно, нет ничего более серьезного.

Ошибки не исчезают с опытом - они просто умнеют

Aivar	# 6 лет назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	vasek, попробую, конечно, но не сегодня. В пятницу вечером соображается туго. )