Восстановление от спящего режима часто перестало работать (tuxonice)

Спецификации преамбулы/Системы

Я отправил основной раздел этого сообщения также к https://github.com/NigelCunningham/tuxonice-kernel/issues/30

У меня было восстановление проблем от спящего режима в Ubuntu, начиная вскоре после того, как я купил свой ноутбук несколько лет назад...

Моя система работает unity DM на xenial (16.04LTS) в настоящее время с ядром Linux [namehere] 4.4.0-78-generic-tuxonice #99~ppa1-Ubuntu SMP Thu May 18 20:29:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux. tuxonice разновидность ядра была установлена и обновлена от ppa: deb http://ppa.launchpad.net/tuxonice/ppa/ubuntu xenial main. Ноутбуком является Dell Inspiron 14-5447 с i5-4210U ЦП, 8 ГБ RAM и не-Dell на 1 ТБ жесткий диск приблизительно с 55% в разделах Linux. Кроме того, я использую tint2 для systray, который перечисляет все окна всех приложений (в дополнение к прикреплению, которое просто показывает все приложения, которые открыты), в дополнение к показу состояния батареи выше time-til-empty и hh:nn:ss выше DDDD yyyy-mm-dd (извинения за использование нотации MS).

Система является двойной загрузкой (grub2) с windows10, но я редко использую окна и как правило не имею изображения спящего режима Linux на диске, когда я использую окна (или изображение спящего режима окон при использовании Linux)

(Основная) проблема

Приблизительно 50% времени, когда я hibernate, Я не могу восстановить этот образ диска на первой попытке. Процесс добирается до 100% основного пространства пользователя + копия/восстановление ядра, но затем замораживается на одном из следующих нескольких шагов:

• (Пустой экран нес подсветкой)
• Doing atomic copy/restore (в 100%)
• Doing atomic copy/restore (в 0%)

• (возможно Doing atomic copy/restore в 100% снова)

• Нечасто это добирается до экрана входа в систему, но затем замораживается.

Иногда, когда система блокирует, caps lock вспышки света постоянно. Другие времена там не являются никаким исходящим признаком, что это заблокировано. После закрытия путем содержания в кнопке питания, ожидая несколько secs и снова включая его, он обычно (возможно, 75% времени) может восстановить от hibernate (конечно, если я нажал 'c' клавишу, чтобы подтвердить, что я хочу попытаться использовать изображение снова).

Если это запрется на второй попытке, то я попытаюсь до 8 раз восстановить.. но если это не восстановило на 4-й попытке, я не думаю, что у меня когда-либо был он, восстанавливают позже, таким образом, я буду в конечном счете делать недействительным изображение, при этом мое предположение будет то, что некоторая часть изображения спящего режима была сохранена неправильно. Если это запирает на входе в систему экран это иногда, но не всегда, уже удалило изображение спящего режима, лишив возможности пытаться восстановить снова с тем изображением.

Если я использую значение по умолчанию (не -tuxonice) ядро, у меня, КАЖЕТСЯ, есть немного более высокий уровень успеха на первой попытке, но в случае отказа мне не предоставляют опцию попытаться использовать изображение снова. Так, я строго не протестировал уровни успеха с обоими ядрами.

У меня, кажется, есть восстановление проблем из изображения более часто, когда я изменил питание или состояние дисплея (включенный к отключенному или наоборот; внешний дисплей к отключенному или vv) между тем, когда я создал изображение и восстанавливаю изображение. Но проблем не происходит каждый раз, который происходит, и при этом их исключительно не происходит, когда питание или отображается, состояние изменяются.

Я иногда использую suspend вместо hibernate. Приблизительно 10% времени, это соединяет экран входа в систему, отображая время, я поместил его для сна, а не текущее время. При закрытии и перезагрузке, нет никакой опции использовать изображение для восстановления (как ожидалось).

Частота отказов или для в спящем режиме или приостанавливает, кажется, не зависит от метода спящего режима/приостанавливать: выбор из меню питания в главной строке меню, заключительный ноутбук w/o оба внешних включенные display+power, критически низкий уровень заряда или вызов командной строки.

Другие системные причуды

Для пользы полноты: в моей системе существует несколько причуд. Иногда (~1%) при включении (или на горячей загрузке или на "холодной" начальной загрузке; спящий режим или никакой спящий режим), клавиатура не отвечает. У меня есть 100-секундная задержка ожидания нажатия клавиши grub2 так, чтобы, если Кбит не отвечает, я мог отключить систему и попробовать еще раз, прежде чем запрошено об изображении спящего режима. Клавиатура всегда, кажется, работает над второй попыткой, но это могло бы просто быть на основании низкой интенсивности отказов. Включение внешней клавиатуры во время обратного отсчета не спасает встроенную клавиатуру, и при этом внешняя клавиатура не работает.

Кроме того, иногда мой tint2 панель появляется на начальной загрузке, но обычно нет. При восстановлении из бывшего в спящем режиме изображения tint2 панель всегда появляется (поскольку она всегда работала до спящего режима). Когда tint2 не показывает на GUI, top ДЕЛАЕТ шоу tint2 выполнение, но должен быть разделен на уровни под моим рабочим столом.

Три раза, так как я владел этой системой, раздел подкачки "исчез" и запись в /etc/fstab или mtab имеет недопустимую или незарегистрированную идентификацию код UUID.

Заключительные вопросы/просьба для справки

Таким образом, как я иду собирающийся диагностировать/устранить спящий режим (и приостановите?) проблема (проблемы)? Есть ли способ сбросить все открытые дескрипторы файлов к диску перед спящим режимом, как тогда, когда спящий режим перестал работать, последние несколько объектов, я сохраненный к диску не полностью присутствую в ext4 фс (в LVM я верю). Использование диска/BIOS gpt таблицы разделов и efi. Моя клавиатура не имеет a sysreq ключ перечислен (как раз когда a Fn ключевая опция), таким образом, я не могу использовать alt sysreq r e i s u b мнемосхема, если это даже рекомендуется для начала.