Есть комп на 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 шина, и диск стал доступен.

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

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

Суть проблемы: система иногда зависает. Причем намертво, так, что ни пинги, ни alt-sysreq уже не работают. Если система во время зависания издавала какой-либо звук — он также повиснет, превратившись в однотонный сигнал (т.е. звуковуха не воспроизводит по циклическому буферу — где встало, тот сигнал и останется на выходе). Более того — reset и тот не работает: при нажатии на резет секунд 10 ничего не происходит, потом комп полностью выключается, и секунд через 5 включается обратно. Если же нажать резет когда все работает — система моментально уходит в ребут.

Зависания происходят непредсказуемо, обычно при перемотке видео, но иногда и просто на ровном месте. Нагрузки у системы во время зависаний обычно нет. Частота возникновения — примерно раз-два в сутки. В логах, само собой, все чисто.

Система: debian sid, ядро дистрибутивное 3.0.0-1-amd64 (но проявлялось и на более ранних, как минимум с .38, возможно и еще раньше).

Железо:

CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (4 ядра с HT, итого 8 логических);

RAM: 10Gb (проблема проявляется и если уменьшить до 4);

GPU: GeForce GT 240 на нвидиевском блобе версии 280.11 (на более ранние версиях, как минимум начиная с 197.*, проблема также проявляется).

lspci: http://pastebin.com/LKZhLjQ2

Что смог обнаружить:

* при попытке импортировать медиатеку в ~16к треков в rhythmbox, где-то 95% что зависание произойдет. Медиатека на NFS шаре, так что i/o операций с диском тут практически нет. Замена NFSv4 на NFSv3 или на SSHFS ничего не меняет — все равно виснет. Отключение композитинга и закрытие окна программы во время добавления не помогает, т.е. проблема очевидно не в видео;

* k3b гарантированно вис при запуске. Решилось параметром ядра libata.dma=1, но это ничуть не повлияло на описываемые зависоны;

* на liquorix ядрах аналогичного вида зависание происходило при инициализации видеосистемы при загрузке X-ов. Вылечилось через intel_iommu=off, но опять же это нисколько не помогает с описываемым;

* переключение IRQ на одно ядро ничуть не помогает;

* clocksource=hpet не помогает;

* memtest86+ никаких ошибок не выявляет;

* отключение свопа не помогает;

* cpu-интенсивные операции (cpuburn, кодирование видео, компиляция и т.п.) зависонов не вызывают, даже в случае если все ядра длительно загружены на 100%.

Предположительно это проблема с железом, но локализовать не могу. Разве что новую мать покупать, что как-то не хочется т.к. нет никакой гарантии что проблема в ней.

Что можете порекомендовать попробовать для локализации/исправления проблемы?