| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 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 /Отладки Данный уровень отладки серъезнее предыдущего и частенько используется и разработчиками и продвинутыми пользователями, описывать его то же не буду (нет смысла переписывать), а просто даю ссылку ... ссылку забанили - даю новую ссылку, выпущенную как DOC: Best practices for debugging Linux system hang and hibernation problems Но самым интересным в этой статье, на мой взгляд, является ссылка на очень хороший скрипт для отладки suspend (suspendresume) - на выходе получается несколько выходных файлов: лог вызова драйверов (и не только их), вшитых в ядро + лог ftrace + временная диаграмма (пример диаграммы) Как использовать — расписано в файле этого пакета. Наше ядро имеет все необходимые флаги для использования этого скрипта PS ... способы отладки, описанные в статье на первый взгляд могут показаться ничего незначащими, но это первое впечатление. Например, rtc trace - написано всего 3 строчки, но сам метод очень хорош - позволяет сохранить последнюю точку события PM в RTC после перезагрузки (и зачастую даже после падения), что поможет произвести отладку (отследить в demsg) зависания во время suspend/hibernate, но чтобы понять суть этого способа придется погрузится в поиск и чтение дополнительной литературы, как правило, на en ... Это относится и к другим способам, описанным в указанной ссылке. Это я к тому, что это только указатель/список возможных способов отладки, а их выбор и конкретное применение требует дополнительной проработки вопроса.
Ошибки не исчезают с опытом - они просто умнеют
|
| Aivar |
|
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
vasek, спасибо за труд! С тех пор как поменял видеокарту у меня напрочь отвалилась гибернация. При всем при том suspend-to-ram работает нормально. Как только поборю лень, обязательно протестирую трабл по вашему гайду. ) Да, трабл только с блобом nvidia, с нуво проблем нет. |
| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 17 февраля 2013
|
Для надежности записи логов требуется мягкая перегрузка - правда это не всегда помогает, но для спокойствия рекомендую при проведении отладки изменить значения параметров kernel.panic = 10 kernel.panic_on_oops = 1
Ошибки не исчезают с опытом - они просто умнеют
|
| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 17 февраля 2013
|
AivarЭто не гарантирует 100% успеха .... а тем более hibernate, этот режим самый тухлый - не даром он не стоит по умолчанию в Linux ..... и, главное, этот хороший скрипт работает только для suspend
Ошибки не исчезают с опытом - они просто умнеют
|
| Aivar |
|
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
Учту. Смотрю, любите вы это дело, т.е. дебагеры и т.д. ) В мое время это называлось проще - отладчик. Собственно, так оно и переводится. vasekТак в том вся и непонятка... Комп тупо виснет даже не успев скинуть память в своп... REISUB не помогает. К чему тут видеодрайвер??? |
| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 17 февраля 2013
|
AivarДля этого случая есть другие отладки ........ получение дампа упавшего ядра........ + утилиты для его исследования .... но лучше этим не заниматься....мозг вскипит... а выход кот наплакал ...
Ошибки не исчезают с опытом - они просто умнеют
|
| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 17 февраля 2013
|
AivarЗабыл спросить ...... cat /proc/sys/kernel/panic ......... случайно не равен 0
Ошибки не исчезают с опытом - они просто умнеют
|
| Aivar |
|
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
Равен. |
| vasek |
|
|
Темы:
47
Сообщения:
11856
Участник с: 17 февраля 2013
|
AivarПотому и висит - ждет команды на reboot ........ Я всегда ставлю равным 10 ........ смотри пост выше .....по истечение 10с комп автоматом идет на reboot, если, конечно, нет ничего более серьезного.
Ошибки не исчезают с опытом - они просто умнеют
|
| Aivar |
|
|
Темы:
4
Сообщения:
6897
Участник с: 17 февраля 2011
|
vasek, попробую, конечно, но не сегодня. В пятницу вечером соображается туго. ) |