Debug suspend/hibernate

vasek	# 8 лет, 2 месяца назад (отредактировано 8 лет, 2 месяца назад)
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Прочитал внимательнее свою писанину и пришел к выводу, что зря, похоже, привел ссылки на Wiki Ubuntu, в принципе достаточно 2-ой части. Свое мнение о тех ссылках Ubuntu дополнил и выделил красным цветом. Повторюсь, привел эти ссылки просто для ознакомления. Пробовать, что там написано или не пробовать, решать Вам. PS .... Как всегда, мысли путаются (похоже уже от старости) и, зациклившись на этой гребанной Ubuntu, совсем забыл про базовый документ, на который уже как то давал ссылку в одном из топиков. PSS .... И еще один момент, кто будет пробовать pm_trace .... слетит время в BIOS, нужно будет править. Это следствие pm_trace (echo 1 > /sys/power/pm_trace). В этом режиме трассировочная инфа в RTC (которую потом можно увидеть в dmesg после неудачной попытки выйти из suspend)....... просто это единственное место для записи, а потому и слетает время ............ ну и следует уложиться в 3 мин, чтобы выйти из зависона и перегрузиться ............... это все расписано ..... правда не помню - то ли по указанной ссылке, то ли по-другой.... нашел у себя - привожу цитату из первоисточника `If resume fails to complete, then press the power button until the computer turns off. Power on your computer making sure that it loads the same kernel that exhibited the resume problem. You have about 3 minutes to start this boot process before the information saved in the RTC gets corrupted. CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume.` Ошибки не исчезают с опытом - они просто умнеют

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

Сообщения: 11853

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

Прочитал внимательнее свою писанину и пришел к выводу, что зря, похоже, привел ссылки на Wiki Ubuntu, в принципе достаточно 2-ой части.
Свое мнение о тех ссылках Ubuntu дополнил и выделил красным цветом. Повторюсь, привел эти ссылки просто для ознакомления.
Пробовать, что там написано или не пробовать, решать Вам.

PS .... Как всегда, мысли путаются (похоже уже от старости) и, зациклившись на этой гребанной Ubuntu, совсем забыл про базовый документ, на который уже как то давал ссылку в одном из топиков.
PSS .... И еще один момент, кто будет пробовать pm_trace .... слетит время в BIOS, нужно будет править. Это следствие pm_trace (echo 1 > /sys/power/pm_trace). В этом режиме трассировочная инфа в RTC (которую потом можно увидеть в dmesg после неудачной попытки выйти из suspend)....... просто это единственное место для записи, а потому и слетает время ............ ну и следует уложиться в 3 мин, чтобы выйти из зависона и перегрузиться ............... это все расписано ..... правда не помню - то ли по указанной ссылке, то ли по-другой.... нашел у себя - привожу цитату из первоисточника

If resume fails to complete, then press the power button until the computer turns off.
Power on your computer making sure that it loads the same kernel that exhibited the resume problem.
You have about 3 minutes to start this boot process before the information saved in the RTC gets corrupted.
CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume.

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

vasek	# 6 лет, 10 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Внес изменения - НЕ ИСПОЛЬЗУЙТЕ проверку в режиме emergency Не давно пришлось воспользоваться echo freeze…mem > /sys/power/state в режиме emergency - получил облом, не смог вернуться обратно, получил темный экран, правда в режиме mem набрал в слепую reboot и перегрузился. Насколько помню раньше работало нормально. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет, 10 месяцев назад

Темы: 47

Сообщения: 11853

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

Внес изменения - НЕ ИСПОЛЬЗУЙТЕ проверку в режиме emergency
Не давно пришлось воспользоваться echo freeze…mem > /sys/power/state в режиме emergency - получил облом, не смог вернуться обратно, получил темный экран, правда в режиме mem набрал в слепую reboot и перегрузился.
Насколько помню раньше работало нормально.

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

anode	# 6 лет, 8 месяцев назад (отредактировано 6 лет, 8 месяцев назад)
Темы: 8 Сообщения: 1019 Участник с: 30 августа 2011	Бытует мнение, что размер своп файла/раздела должен быть равным размеру ОЗУ для успешной "зимней спячки", она же гибернация. Однако, у разработчиков ядра мнение несколько другое :) Как ни странно. Желающие могут почитать первоисточник я же позволю себе достаточно вольный перевод привести здесь: /sys/power/image_size управляет размером образа гибернации. Это может быть строка, неотрицательное целое число, которое будет использоваться в качестве значения максимального размера образа в байтах. Ядро спящего режима сделает все возможное, чтобы размер образа не превышал это число. Однако, если это окажется невозможным, образ спящего режима будет создан и его размер будет как можно меньше. В частности, запись '0' в этот файл приведет к тому, что образ гибернации будет настолько маленьким, насколько єто возможно. Чтение из этого файла возвращает текущий предел размера образа, который установлен по умолчанию на 2/5 доступного ОЗУ. Что это значит? Да ни чего :) Просто для информации.

anode

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

Темы: 8

Сообщения: 1019

Участник с: 30 августа 2011

Бытует мнение, что размер своп файла/раздела должен быть равным размеру ОЗУ для успешной "зимней спячки", она же гибернация. Однако, у разработчиков ядра мнение несколько другое :) Как ни странно. Желающие могут почитать первоисточник я же позволю себе достаточно вольный перевод привести здесь:


/sys/power/image_size управляет размером образа гибернации.
Это может быть строка,  неотрицательное целое число, которое будет использоваться в качестве значения максимального размера образа в байтах. Ядро спящего режима сделает все возможное, чтобы размер образа не превышал это число. Однако, если это окажется невозможным, образ спящего режима будет создан и его размер будет как можно меньше. В частности, запись '0' в этот файл приведет к тому, что образ гибернации будет настолько маленьким, насколько єто возможно.
Чтение из этого файла возвращает текущий предел размера образа, который установлен по умолчанию на 2/5 доступного ОЗУ.

Что это значит? Да ни чего :) Просто для информации.

vasek	# 6 лет, 8 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	anode Что это значит? Да ни чего :) Просто для информации. Как то читал это, перечитал несколько раз - особенно удивило значение 2/5 ОЗУ. Хотел поэкспериментировать с этим значением, но забил, просто не любитель использовать hibernate - не вижу смысла (да и надежностью страдает - подводил несколько раз). И что то сомнения у меня про минимальный образ. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет, 8 месяцев назад

Темы: 47

Сообщения: 11853

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

anode
Что это значит? Да ни чего :) Просто для информации.

Как то читал это, перечитал несколько раз - особенно удивило значение 2/5 ОЗУ. Хотел поэкспериментировать с этим значением, но забил, просто не любитель использовать hibernate - не вижу смысла (да и надежностью страдает - подводил несколько раз). И что то сомнения у меня про минимальный образ.

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

anode	# 6 лет, 8 месяцев назад (отредактировано 6 лет, 8 месяцев назад)
Темы: 8 Сообщения: 1019 Участник с: 30 августа 2011	Попробовав уменьшать значение image_size, получил, во-первых, значительное увеличение времени перехода в сон, во-вторых, большие тормоза при просыпании. Вероятно, 2/5 такое себе империческое значение, при котором возможен более-менее комфортный переход в режим сна. Я бы смотрел в сторону увеличения этого значения по умолчанию. 1/2 от ОЗУ очень даже ни чего себя показала, 3/4 еще лучше: после пробуждения при куче запущенніх программ все работает без тормозов и подвисаний, например, видео на ютубе и компиляция ядра( правда я не проверял его работоспособность :) ). ЗЫ. Кстати, на счет "подводил": ни когда ни каких сбоев не было. Правда, я пользуюсь чаще все же не Арчем, хотя и на Арче проблем не было ни разу.

anode

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

Темы: 8

Сообщения: 1019

Участник с: 30 августа 2011

Попробовав уменьшать значение image_size, получил, во-первых, значительное увеличение времени перехода в сон, во-вторых, большие тормоза при просыпании. Вероятно, 2/5 такое себе империческое значение, при котором возможен более-менее комфортный переход в режим сна. Я бы смотрел в сторону увеличения этого значения по умолчанию. 1/2 от ОЗУ очень даже ни чего себя показала, 3/4 еще лучше: после пробуждения при куче запущенніх программ все работает без тормозов и подвисаний, например, видео на ютубе и компиляция ядра( правда я не проверял его работоспособность :) ).
ЗЫ. Кстати, на счет "подводил": ни когда ни каких сбоев не было. Правда, я пользуюсь чаще все же не Арчем, хотя и на Арче проблем не было ни разу.