Не выходит из спящего режима: sata просыпается после того, как пытается читаться swap

Я тебе больше скажу - не обязательно по ssh подключаться, можно на другую консоль переключиться (отличную от того где x11 стартует в твоём дистрибутиве).

Как воркэраунд - можно перемонтировать корень с rw типа так:

sudo mount -o remount,rw /dev/mapper/root /

К сожалению нет, там видимо ломается что-то глубже еще, видео совсем не работает. Но не суть, хочется чтобы самой этой проблемы не было.

Можно, но там уже из-за этого хрен знает сколько всего поотваливаться успело. Так что перезагрузка надежней (это же не сервер какой, а простой десктоп, его не жалко перегрузить). Как воркэраунд пока отключил своп, теоретически должно помочь, если я правильно определил источник проблемы — пока закономерность только в пустоте/непустоте свопа.

Да, с отключенным свопом не воспроизводится. Но, дело не только в пустоте не пустоте, у меня сиё воспроизводится крайне редко, а в свопе почти всегда что-то есть.

Инит - systemd?

У меня воспроизводится гарантированно. Пока стоял дефолтный vm.swappiness, после усыпления после рабочего дня на ночь комп уже не просыпался с описанными симптомами. Переставил в 0 — проблема вроде бы ушла, но вот сегодня опять не проснулся. Подключился, посмотрел что как — 200кб в своп попало. Т.е. вроде как эксперимент подтверждает гипотезу: если своп пуст, то просыпается без проблем, если своп не пуст то вот такая вот хрень.

И судя по таймингам, подожди ядро еще хоть одну секунду, все было бы ок. Но я никак не могу найти в доках параметров ядра такой опции, чтобы оно при просыпании подождало. И в гугле все больше жалуются на то, что ядро слишком долго ждет, а как добавить сюда паузу я не нашел.

systemd. Но вроде как до самого systemd дело то еще и не доходит…

Это конечно тоже workaround но может поэтому у меня так редко воспроизводится:

Поставь для корневого раздела опцию errors=remount-ro в 0:

UUID=/dev/sda1 /               ext4    errors=remount-ro 0       1

Т.е. я не понимаю, почему система вначале «пробуждает» диск:

[152965.714865] sd 1:0:0:0: [sda] Starting disk

а только потом шину:

[152968.248058] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [152968.258885] ata2.00: configured for UDMA/133

И не вижу ничего удивительного в том, что диск без шины не работает. Корень зла мне видится именно вот тут, последовательность пробуждения должна бы быть обратной: вначале шина, потом диск. Ну или как минимум система должна дождаться пробуждения шины перед тем как что-либо делать с диском. А так оно будит диск, решает что все уже хорошо, пытается работать дальше, и только потом пробуждается шина. Если успевает.

Так оно так и стоит, иначе бы в панику бы выпадало.

Я не уверен, что можно пробудить диск не пробудив шину(как ещё с ним общаться если не через шину? ну питание можно включить видимо).

Надо конечно сорцы смотреть, что бы убедиться, но имхо, пробуждение шины это часть процесса пробуждения диска.

опцию errors=remount-ro в 0

Ам… errors=remount-ro это же и есть сама опция (и она у меня проставлена, как уже сказал), самодостаточная, а этот 0 это флаг для системы бекапов, и по факту не используется уже давно. Я чего-то пропустил?

Так вон логи же: sd активируется раньше чем ata link. Как оно так делает и зачем, и как это исправить — собственно и есть основа вопроса.

Может я чего-то не шарю, может быть инициализируется все в правильном порядке, и просто sata линк слишком долго устанавливается/согласуется (м.б., например, диск просто раскручивается и игнорирует в это время команды). Но как бы это обойти — хз.

Скорее, это я чего то пропустил.

Что я могу сказать точно, на том же оборудовании но на более древнем ядре и дистре (ubuntu 14.04) у меня эта проблема не воспроизводилась.

Можно нагрепать в сорцах ядра откуда идут эти сообщения и посмотреть git log по директориям содержащим эти файлы.

Про 3.15 есть такая новость: https://www.phoronix.com/scan.php?page=news_item&px=MTY0MDU Может быть это оно и есть, что-то перепилили для ускорения, и переускорили так, что некоторое железо уже не поспевает?

Забавно, но в мастере, этот лог вообще закомментили (про SATA link up).

А, не это для какого то конкретного дивайса похоже.

В общем чего я нашёл, лог про SATA link up для 4.16 может выводится либо из обработчика который вызывается «асинхронно» либо в случае ошибки. Слово асинхронно мне тут совершенно не нравится, но дальше копаться нету времени к сожалению.

Асинхронный обработчик ввели в 3.3-rc3. Как оно работает и зачем - надо разбираться, может дело вовсе и не в этом.

Грусть печаль в общем. Ну чтож, посмотрим как оно поживет без свопа, 24 гига оперативки должно хватить всем.

Какого же у тебя размера своп?

Кстати, не может быть причиной нехватка объёма свопа?

Размер свопа равен размеру оперативки — 24 гига. И нет, он практически не используется. Просто ядро что-то в него все-таки скидывает иногда, особенно при vm.swappiness большим чем 0.

Две недели с отключенным свопом — ни единого разрыва. Но саму проблему победить так и не смог, только такой обходной путь.

Я ленивая голова джека, так и не полез дальше в сорцы :(