LINUX.ORG.RU

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

 , ,


0

2

Есть комп на debian buster/sid с дистрибутивным ядром 4.16.0, на i7-4820K@MSI X79A-GD45 Plus (MS-7760). С ним творится странная фигня: если при засыпании своп использовался по нулям, то он просыпается нормально. Ежели же в свопе что-то было, то просыпается с черным экраном и ничего не пишет. Однако можно подключиться по ssh и увидеть, что происходило примерно следующее (Система живет на sda, находящемся на ata2.00):

[152965.686149] ACPI: Waking up from system sleep state S3 блаблабла [152965.714865] sd 1:0:0:0: [sda] Starting disk [152965.714868] sd 2:0:0:0: [sdb] Starting disk [152967.463276] PM: suspend exit [152967.629198] Read-error on swap-device (253:1:6744) [152967.634200] Read-error on swap-device (253:1:6560) [152967.646608] EXT4-fs error (device dm-0): ext4_find_entry:1437: inode #1438994: comm ksmserver: reading directory lblock 0 [152967.646626] Buffer I/O error on dev dm-0, logical block 0, lost sync page write [152967.646628] Aborting journal on device dm-0-8. [152967.646635] Buffer I/O error on dev dm-0, logical block 3178496, lost sync page write [152967.646637] JBD2: Error -5 detected when updating journal superblock for dm-0-8. [152967.646638] EXT4-fs (dm-0): Remounting filesystem read-only [152967.652600] EXT4-fs error (device dm-2): ext4_find_entry:1437: inode #1202707: comm ksmserver: reading directory lblock 0 [152967.652615] Buffer I/O error on dev dm-2, logical block 0, lost sync page write [152967.942246] Read-error on swap-device (253:1:4352) [152968.248058] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [152968.258885] ata2.00: configured for UDMA/133

Т.е. система вначале попыталась прочитать что-то из свопа, не смогла потому что нет диска, попыталась что-то сохранить на корневую ФС (лог о том что своп сломался?), опять же не смогла, переткнула корневую ФС в ридонли, и только тут проснулась SATA шина, и диск стал доступен.

Соответственно после этого система переходит в состояние нестояния с ридонли корневой ФС.

Собственно вопрос: как можно с этим бороться? Можно ли каким-либо образом сказать ядру, чтобы после выхода из сна оно чуть-чуть подождало перед тем как своп теребить?


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

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)

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

sudo mount -o remount,rw /dev/mapper/root /
pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

ynn ()
Ответ на: комментарий от pon4ik

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

ynn ()
Ответ на: комментарий от ynn

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

ynn ()
Ответ на: комментарий от ynn

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

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

UUID=/dev/sda1 /               ext4    errors=remount-ro 0       1
pon4ik ★★★★★ ()
Ответ на: комментарий от ynn

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

[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

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

ynn ()
Ответ на: комментарий от pon4ik

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

ynn ()
Ответ на: комментарий от ynn

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

ynn ()
Ответ на: комментарий от pon4ik

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

ynn ()
Ответ на: комментарий от ynn

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

ynn ()
Ответ на: комментарий от ynn

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

pon4ik ★★★★★ ()
Ответ на: комментарий от ynn

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

ynn ()
Ответ на: комментарий от te111011010

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

ynn ()
Ответ на: комментарий от ynn

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

ynn ()
Ответ на: комментарий от ynn

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

pon4ik ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.