От: Проверка и настройка режима гибернации

[kol1978]

Доклад об очередной стадии испытания: Получился очень положительный эффект в результате очередной установки – был создан раздел /boot с файловой системой ext2. Не знаю в чем причина положительного эффекта так как при этом, всегда swap на отдельном разделе и образ гибернации пишется именно туда а не в /boot... сейчас гибернация стабильна при загрузке 1/2 ОЗУ.

Нужна помощь – является ли ограничение в свободной ½ ОЗУ для гибернации стабильным для всех и (или) это «техническое» ограничение механизма ядра?

На данный момент сложности включения режима гибернации в Linux остаются частью его очарования и сложности.
Это напоминание о нашем контроле над нашими системами и о возможностях обучения, которые предлагает Linux. И хотя иногда это может разочаровывать, это также свидетельствует о богатом и разнообразном мире Linux.
В версиях ядра с 6.9.0 по 6.9.8 отсутствует поддержка приостановки с сохранением на диск, если есть параметр ядра для возобновления работы и обнаружена какая-либо ошибка при проверке и/или чтении данных приостановки. Ошибка 218845 в основной ветке отслеживает проблему и исправлена в ядре 6.9.9.

Помогите с поиском?, где в исходниках ядра реализован механизм гибернации и этот конкретно: 

Чтобы проверить, работает ли режим гибернации, вы можете попробовать перевести компьютер в режим гибернации в режиме «перезагрузки»:
# echo reboot > /sys/power/disk
# echo disk > /sys/power/state

Задачу в капании на такую глубину этого вопроса вижу в том, что бы сделать «понятный» механизм(интерфейс) сообщений о процессе гибернации или (и) её невозможности выполнить. PS запилил несколько модулей ядра из литературы и сделал один свой...но пока не удачно в плане продвижения в данном направлении(оценка и описание процесса гибернации). Скажем модуль отвечает за записи в системный журнал процесса гибернации и «погибает» последним без сохранения...при этом что бы было понятно что «погиб» только этот модуль, а все остальные процессы заморожены и корректно сохранены – со стопроцентной уверенностью возможности их разморозки после перезагрузки системы.
Да и нужен аналог Sourcetrail для навигации по коду ядра? И так же может посоветуете среду разработки для ядра...? Потому что Sourcetrail не подходит – находит много ошибок и в результате индексация не работает и использую Qt Creator для обычного кода для того что бы видеть ошибки в коде еще на стадии написания (и навигации по коду), а не после того как их выдаст компилятор – если так можно для модулей ядра подскажите что использовать?



15 ноября 2024, 09:44:55
удалил неиспользуемые модули...и индексация прокатила :

last indexed: 2024-11-15 13:49:21
 
    6700 files (134 complete)
    5806816 lines of code
 
    663424 symbols
    3337958 references
 
    31659 errors (0 fatal)

удивительно как при таком количестве ошибок это работает