Випадкові зависання без BSOD: журнал, який виявляє винуватця

Ви знаєте той тип «зависання». Миша зупиняється. Аудіо зациклюється, ніби проклята касета. Caps Lock не реагує. Немає синього екрану. Немає дампа. Просто машина, яка мовчки вирішила взяти вихідний.

Коли люди кажуть «випадково», я чую «ми не шукали в потрібному місці». Потрібне місце зазвичай не в драйвері GPU, не в ОЗП (хоч іноді й так), і не в якомусь «оптимізаторі продуктивності». Потрібне місце — це журнал, що фіксує таймаути та скидання в підсистемі зберігання: момент, коли система спробувала читати або писати, а пристрій… не відповів вчасно.

Журнал-винуватець: де зависання лишають відбитки

Тверді зависання без BSOD часто списують на «графіку», бо саме це видно. Але видима частина — лише фасад. За фасадом — I/O: зберігання, лінки PCIe, прошивка контролера та рішення щодо енергоменеджменту, що гарно виглядали в презентації.

«Один журнал», який найчастіше виявляє винуватця — це той, що фіксує таймаути зберігання та скидання:

• Windows: Event Viewer → System лог, особливо події StorPort, stornvme, disk та WHEA-Logger навколо моменту зависання. Класика: Event ID 129 («Reset to device, \Device\RaidPortX, was issued») і Event ID 153 (повторені I/O операції).
• Linux: кільцевий буфер ядра: dmesg / journalctl -k, особливо повідомлення типу blk_update_request: I/O error, timed out, nvme ... controller is down; will reset, resetting controller, ataX: hard resetting link та попередження файлової системи.

Чому це працює: стек зберігання консервативний. Коли ОС не отримує відповіді від пристрою, вона це логуватиме. Навіть коли інше зависло. Навіть коли інтерфейс мертвий. Навіть якщо система «відновлюється» й здається, що нічого не сталося.

Зависання часто є видимим симптомом того, що ядро чекає на I/O в невідриваємому стані (Linux «D-state») або драйвер порту зберігання Windows виконує скидання й повтора, поки ваш робочий стіл чемно перестає працювати.

Цитата, яку варто тримати на моніторі:

John Allspaw: «Невдача — нормальна частина складних систем.» (перефразована думка)

Чим насправді є «зависання без BSOD» на рівні ОС

BSOD — це контрольоване зупинення: ОС знає, що сталося невідновлюване, і зупиняється з дампом. Зависання в іншому сенсі гірше: ОС «жива», але прогрес зупиняється, бо якийсь критичний потік заблоковано, відбувається шторм переривань або система застрягла на рівні, де не може спланувати роботу для відновлення.

На практиці більшість «випадкових зависань» вписуються в кілька категорій:

1) Таймаути I/O зберігання та скидання контролера

Це велика категорія. NVMe пристрої можуть зависати, SATA-лінки можуть «флапати», USB-зберігання може обнулятися живлення, прошивка RAID/HBA може «втратити зв’язок», а енергетичні стани контролера можуть працювати некоректно. ОС тоді виконує повтори, скидання й чекає. Поки це триває, все, що звертається до ураженого диска, зупиняється. Якщо диск — ваш системний диск, вітаю: все до нього звертається.

2) Застережні випадки PCIe / енергоменеджменту

ASPM, L1 підстани, агресивні політики простою й баги прошивки можуть створити поведінку «працює днями, а потім зависає при невдалому поєднанні таймінгів». Це не містика. Це автоматний стан із поганим переходом.

3) Нестабільність пам’яті та CPU

Проблемна оперативна пам’ять, нестабільні розгони, занадто низьке напруження або недостатній БП можуть зависити систему без чистих логів. Але навіть у таких випадках журнали зберігання часто показують «таймаути», бо CPU перестав обробляти переривання. Це не означає, що зберігання спричинило проблему — але журнал вказує, де система перестала відповідати.

4) Застої файлової системи / проблеми цілісності

Файлові системи можуть зависати, чекаючи завершення записів або комітів журналу. ZFS може зупинятися в TXG sync, якщо підлеглий пристрій поводиться некоректно. NTFS може виглядати «в порядку», поки нижчий рівень зберігання не працює.

Жарт #1: «Випадкове зависання» ніколи не випадкове; це просто ваш комп’ютер відмовляється писати розгорнутий інцидентний звіт.

Цікаві факти та історичний контекст (коротко й по суті)

1. StorPort у Windows існує, бо зберігання складне. Microsoft ввела StorPort, щоб замінити старий SCSIport для вищої продуктивності та сучасних архітектур зберігання.
2. Event ID 129 — це скидання, а не діагноз. Він каже, що ОС змусила виконати скидання, бо пристрій не відповідав; «чому» — в іншому місці (живлення, прошивка, кабелі, PCIe).
3. NVMe приніс продуктивність і нові режими відмов. NVMe — протокол з багатьма чергами поверх PCIe, тому стани лінку і таймінги прошивки важать більше, ніж багато хто очікує.
4. Повідомлення ATA/SATA про «link reset» існують десятиліттями. Логування Linux типу «hard resetting link» — сучасний еквівалент «кабель або контролер трохи підводить».
5. Споживчі SSD оптимізовані під бенчмарки, не під гірший хвіст латентності. Диск може мати відмінний результат у тестах і все одно зависати, коли збірка сміття відбувається в невдалий момент.
6. Політики кешування запису були постійною проблемою. Від ранніх IDE до сучасного NVMe «увімкнути кеш запису» підвищувало пропускну здатність, але іноді збільшувало масштаб проблем при відключенні живлення або багах прошивки.
7. SMART створювали для передбачення, а не для абсолютних висновків. Диски можуть виходити з ладу з «ідеальним» SMART, і навпаки — деякі можуть працювати довго з страшними лічильниками. Використовуйте SMART як підказку, а не вирок.
8. Журнали ядра часто останні, що працюють. Навіть коли простір користувача замер, ядро може писати повтори й скидання в кольцевий буфер, який зберігається до перезавантаження.
9. Команди збереження говорять частіше про «tail latency», ніж про пропускну здатність. Саме 99.9-й процентиль затримки I/O створює відчуття зависання, а не середній MB/s.

Швидка діагностика — покроковий план (перший/другий/третій)

Це найкоротший шлях, який я знаю, від «мій комп’ютер зависає» до «я можу вказати підсистему, відповідальну за це». Дотримуйтесь вказаного порядку. Не імпровізуйте.

Перший: встановіть, чи I/O зберігання зупинився в момент зависання

• Windows: шукайте події в системному журналі (StorPort/stornvme/disk) за кілька хвилин до/після зависання і при наступному завантаженні після вимушеного перезапуску.
• Linux: перевірте journalctl -k -b -1 (попереднє завантаження) на наявність таймаутів, скидань та помилок файлової системи.

Якщо ви бачите скидання/таймаути — вважайте шлях зберігання підозрілим, поки не доведете протилежне.

Другий: скореляйте з апаратною топологією й енергоменеджментом

• Визначте, чи уражений пристрій — NVMe на PCIe, SATA, USB або за RAID/HBA.
• Перевірте налаштування лінку/живлення (Windows PCI Express Link State Power Management; Linux ASPM).
• Перевірте версії прошивки (SSD, BIOS/UEFI) та драйвери (chipset/storage).

Третій: відтворіть під контролем навантаження й виміряйте хвостову латентність

• Використайте fio на Linux або аналогічний інструмент, щоб створити стійкий змішаний I/O і спостерігати за помилками/таймаутами.
• Спостерігайте розподіли латентності (iostat -x, nvme smart-log, лічильники PerfMon у Windows).

Якщо ви можете викликати зависання навантаженням I/O, ви перетворили «випадкове» на «діагностоване». Це перемога.

Практичні завдання: команди, очікуваний вивід, і рішення

Нижче — практичні завдання. Кожне містить команду, зразок виводу, що це означає, і наступне рішення. Команди показані в форматі оболонки Linux; якщо ви на Windows, еквівалент — Event Viewer + PowerShell. Я даю Linux-команди, бо вони точні й відтворювані, і багато «Windows desktop» зависань врешті виявляються проблемою прошивки + NVMe, яка ідентично проявляється на Live Linux.

Завдання 1: Перевірте журнал ядра попереднього завантаження на наявність таймаутів

cr0x@server:~$ journalctl -k -b -1 | egrep -i 'timeout|reset|nvme|ata|i/o error|blk_update_request|hung'
Jan 12 09:41:02 host kernel: nvme nvme0: I/O 123 QID 7 timeout, aborting
Jan 12 09:41:02 host kernel: nvme nvme0: controller is down; will reset: CSTS=0x3
Jan 12 09:41:03 host kernel: blk_update_request: I/O error, dev nvme0n1, sector 1953525168

Що це означає: Ядро відправило I/O, не отримало підтвердження, і скинуло контролер. Це ненормально. Один випадок може статись; повтори — це патерн.

Рішення: Вважайте NVMe/контролер/енергоменеджмент PCIe основними підозрюваними. Перевіряйте стан здоров’я NVMe і лінк PCIe. Також плануйте оновлення прошивки.

Завдання 2: Визначте, чи процеси застрягли в невідриваємому I/O (D-state)

cr0x@server:~$ ps -eo state,pid,comm,wchan:32 | awk '$1 ~ /D/ {print}' | head
D  1423  postgres         nvme_poll
D  2210  jbd2/nvme0n1-8   __flush_work

Що це означає: Процеси в D-state чекають на I/O. Коли достатньо критичних потоків у D-state, система виглядає завислою.

Рішення: Зосередьтесь на пристрої зберігання, що викликає ці очікування (тут: nvme0n1). Не витрачайте години на діагностику інтерфейсу користувача.

Завдання 3: Перевірте помилки блочного шару й пристрою в dmesg (поточне завантаження)

cr0x@server:~$ dmesg -T | egrep -i 'nvme|ata|I/O error|resetting|link is down|frozen|AER' | tail -n 30
[Mon Jan 13 10:12:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 13 10:12:44 2026] nvme 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
[Mon Jan 13 10:12:44 2026] nvme nvme0: controller reset

Що це означає: Помилки PCIe (навіть «Corrected») плюс скидання контролера — це підозрілий сигнал. Проблеми фізичного рівня можуть бути пов’язані з живленням, цілісністю сигналу, прошивкою або переходами станів ASPM.

Рішення: Перевірте статус лінку PCIe і ASPM; розгляньте оновлення BIOS, перепідключення пристрою, тест у іншому слоті (desktop) або інший шлях кабелю/бэкплейну (server).

Завдання 4: Перевірте швидкість/ширину лінку PCIe та лічильники помилок

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta|ASPM|AER|DevSta' -n
45:        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
47:        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
63:        DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

Що це означає: Лінк узгодився на повну ширину/швидкість, але CorrErr+ вказує на виправлені помилки. Це не завжди фатально, але у поєднанні з зависаннями — варто діяти.

Рішення: Якщо помилки ростуть з часом, протестуйте з вимкненим ASPM і/або зниженою швидкістю лінку (налаштування BIOS), щоб підтвердити стабільність. Якщо стабільність покращиться — ви знайшли вісь відмови.

Завдання 5: Перевірте SMART/стан NVMe і журнал помилок

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 45 C
available_spare                     : 100%
percentage_used                     : 7%
media_errors                        : 12
num_err_log_entries                 : 98

Що це означає: media_errors і наростаючий num_err_log_entries — це не «нормально». Навіть якщо диск «працює», він каже, що має проблеми.

Рішення: Робіть резервні копії негайно, плануйте заміну або оновлення прошивки. Якщо це ноутбук/десктоп з ОС на цьому диску — ставте пріоритет високо.

Завдання 6: Перевірте журнал помилок контролера NVMe на таймаути/скидання

cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 20
Error Log Entries for device:nvme0 entries:64
 Entry[ 0]
  error_count     : 98
  sqid            : 7
  cmdid           : 0x0012
  status_field    : 0x4004
  parm_error_loc  : 0x0000
  lba             : 1953525168

Що це означає: Диск зафіксував помилки, пов’язані з командами/чергами. Це доповнює таймаути ядра. Разом вони складають історію: «ОС запитала, диск не відповів коректно».

Рішення: Підтвердіть версію прошивки і перевірте, чи ваша платформа має відомі проблеми з APST/ASPM. Якщо відтворюється, тимчасово відключіть APST для тестування.

Завдання 7: Для SATA-систем — перевірте SMART на переназначені/очікувані сектора

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_On_Hours'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       45
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       18765

Що це означає: Очікувані сектори й CRC-помилки — класичне паливо для «зависань і повторів». CRC часто вказує на кабель/бэкплейн; pending-сектори — на поверхню диска/FTL.

Рішення: Якщо UDMA_CRC_Error_Count зростає — насамперед замініть кабель/порт бэкплейну. Якщо є pending-сектори — плануйте заміну диска.

Завдання 8: Перевірте файлову систему на сигнали корупції після вимушених перезавантажень

cr0x@server:~$ journalctl -b | egrep -i 'EXT4-fs error|xfs_repair|I/O error|journal|buffer i/o error' | tail
Jan 13 10:18:11 host kernel: EXT4-fs warning (device nvme0n1p2): ext4_end_bio:345: I/O error 10 writing to inode 262402 starting block 12345678)

Що це означає: Файлова система скаржиться на невдалі записи. Це подальша шкода від проблем I/O, а не корінна причина.

Рішення: Спочатку відновіть стабільність підсистеми зберігання. Потім виконайте перевірки файлової системи у вікні обслуговування (і лише після підтверджених резервних копій).

Завдання 9: Виміряйте хвостову латентність і насичення за допомогою iostat

cr0x@server:~$ iostat -x 1 5
Linux 6.5.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          2.10    0.00    1.20   35.40    0.00   61.30

Device            r/s     w/s   r_await   w_await  aqu-sz  %util
nvme0n1         120.0   300.0     3.20   220.50   18.40  99.80

Що це означає: w_await 220 ms з %util ~100% генерує зупинки. Система «зависає», бо все чекає завершення записів.

Рішення: Визначте, чи це очікуване насичення навантаження (потрібно швидше сховище / інша конфігурація черг) або патологічна латентність (прошивка, GC, помилки). Якщо спади латентності корелюють із скиданнями/помилками — це патологія.

Завдання 10: Відтворіть під контролем I/O за допомогою fio (без знищення даних)

cr0x@server:~$ fio --name=latcheck --filename=/var/tmp/fio.test --size=2G --direct=1 --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=1 --time_based --runtime=120 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=3210: Mon Jan 13 10:30:10 2026
  read: IOPS=12.3k, BW=48.0MiB/s (50.3MB/s)
    slat (usec): min=4, max=420, avg=12.5, stdev=5.3
    clat (usec): min=75, max=850000, avg=240.1, stdev=9200.4
  write: IOPS=5, BW=20.0KiB/s
    clat (msec): min=2, max=12000, avg=980.0, stdev=2100.0

Що це означає: Максимальна латентність завершення в секундах (або гірше) — це місце, де живе «зависання». Також зверніть увагу на падіння пропускної здатності запису — часто ознака внутрішнього обслуговування диска або проблем.

Рішення: Якщо fio викликає затримку, у вас є відтворюваний тест. Використайте його, щоб перевірити виправлення (оновлення прошивки, налаштування живлення, інший драйвер) і обґрунтувати заміну.

Завдання 11: Перевірте специфічні затори ZFS (якщо ви використовуєте ZFS)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          nvme0n1   ONLINE       0     3     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/guest01.img

Що це означає: ZFS повідомляє про помилки запису; це корелює із зависаннями. Файл із помилками — жертва.

Рішення: Замініть/відремонтуйте базовий пристрій або шлях. Після відновлення стабільності проведіть scrub. Якщо це пул на одному диску — прийміть, що потрібна надлишковість, якщо ви цінуєте свої вихідні дні.

Завдання 12: Перевірте soft lockup і RCU stalls (CPU не прогресує)

cr0x@server:~$ journalctl -k -b | egrep -i 'soft lockup|hard lockup|RCU stall|watchdog' | tail
Jan 13 10:14:22 host kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [kworker/u32:1:842]

Що це означає: CPU довго не планувався як звичайно. Це може бути через драйвери, що крутяться, шторм переривань або апаратні проблеми. Таймаути зберігання можуть бути і причиною, і наслідком.

Рішення: Якщо soft lockups корелюють з PCIe/AER або NVMe скиданнями — підозрюйте платформу/прошивку/енергоменеджмент. Якщо вони з’являються самостійно — розширте діагностику на CPU/ОЗП.

Завдання 13: Перевірте, чи включено ASPM (частий фактор зависань NVMe)

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Що це означає: Система агресивно керує станами живлення PCIe.

Рішення: Для діагностики переключіться на performance або відключіть ASPM і перевірте, чи зникли зависання. Якщо зникли — у вас тимчасове рішення і вказівка на проблему сумісності/прошивки.

Завдання 14: Підтвердіть, чи активний APST у NVMe (Linux)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/default_ps_max_latency_us
25000

Що це означає: Політика APST (Autonomous Power State Transition) активна. Деякі диски/платформи некоректно поводяться при певних бюджетах латентності.

Рішення: Для тесту встановіть консервативнішу політику через параметр ядра в завантажувачі (наприклад, nvme_core.default_ps_max_latency_us=0) і перевірте, зникає чи проблема. Якщо так — прагніть оновлення прошивки або залиште налаштування як практичне виправлення.

Жарт #2: Прошивка сховища як офісна кава — зазвичай нормальна, інколи катастрофічна, і ніколи не покращиться від того, що ви робите вигляд, ніби її не існує.

Три корпоративні історії з натовпу

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мала парк Windows-робочих станцій для CAD і обробки даних. Люди скаржилися на «випадкові зависання» кілька разів на тиждень. IT ганялися за драйверами GPU, бо зависання відбувалися при обертанні моделей або перетягуванні вікон. Робоче припущення було: «якщо екран зупиняється — значить графіка».

Команда замінила кілька GPU. Перерозгортала образи машин. Навіть звинуватила оновлення Windows. Проблема тривала, і єдиною послідовною деталлю була відсутність BSOD. Керівництво називало це «помилкою користувача», як це вміють робити лише менеджери.

В одного особливо поганого тижня хтось нарешті перевірив System event log відразу після зависання і примусового перевантаження. Ті самі дві події повторювалися: StorPort ресети (ID 129) і події повторів диска (ID 153). Вони були скупчені навколо часу зависання.

Неправильне припущення не полягало в тому, що «драйвери GPU ніколи не спричиняють зависань». Вони можуть. Неправильним було вважати видиму підсистему границею проблеми. Коли команда повернула увагу до зберігання, виявився патерн: певна модель NVMe + конкретна ревізія BIOS ноутбуків + агресивний енергоменеджмент лінку. Оновлення BIOS і зміна політики живлення припинили зависання, а решта винятків вирішувалася оновленнями прошивки SSD.

Урок: починайте з журналу таймаутів зберігання. Він показує, де ОС перестала довіряти пристрою, а не де користувач перестав довіряти комп’ютеру.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Сервісна компанія поставляла Linux-аналітичний пристрій клієнтам. Щоб виграти продуктивність, інженер увімкнув глибші енергозбереження в BIOS і налаштував ОС для нижчого енергоспоживання в простої. В лабораторії все пройшло добре: бенчмарки відмінні, температури нижчі, всі почувалися відповідальними.

В полі пристрої почали «зависати» під час нічних пакетних завдань. Ніяких панікуючих логів, ніяких чистих крашів. Просто потрібен був жорсткий power-cycle. Завдання сильно писали на локальний NVMe scratch.

Першою відповіддю було оптимізувати навантаження: менше fsync, більші буфери, більше конкурентності. Це тільки погіршило ситуацію. Хвостова латентність зросла, і системи стали ще крихкіші. Чим більше «оптимізували», тим частіше пристрій опинявся в стані, коли він переставав відповідати й потребував скидання контролера.

Коли хтось нарешті витягнув журнали ядра попереднього завантаження, історія прозвучала голосно: NVMe таймаути, скидання контролера і іноді PCIe corrected errors. «Оптимізація» підштовхнула платформу в куток енергетичної сумісності при тривалому I/O. Виправлення було нудним: відключити проблемний енергетичний стан (комбінація ASPM/APST) і покатати оновлення прошивки. Продуктивність ледь змінилася, але стабільність з’явилася.

Оптимізація, що шкодить, трапляється, бо вона змінює таймінги. А баги прошивки живуть саме в таймінгах.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Невелика інфраструктурна команда мала змішані навантаження: віртуалізований кластер і кілька bare-metal БД. У них була сувора, неефектна практика: кожен хост збирав і зберігав журнали ядра/системи через перезавантаження, і кожен інцидентний тикет вимагав прикріплення логів останнього завантаження.

Один сервер баз даних почав «зависати» раз на пару тижнів. Аутейдж був коротким (хтось перезавантажував), але бізнес-наслідки великі, бо там був критичний внутрішній сервіс. Перші інциденти списували на «Linux поводиться дивно». Це не діагноз; це капітуляція.

Оскільки логи зберігалися, команда змогла порівняти кілька випадків. Кожного разу з’являвся той самий патерн: збільшення SATA CRC помилок, потім скидання лінку і довгий I/O застій. SMART не показував переназначених секторів, тож диск здавався «здоровим», якщо дивитися не на ті лічильники.

Вони замінили один кабель у шасі під вікно обслуговування. Зависання припинилися. Ніякої героїчної ночної відладки. Ніякої заміни половини сервера «на всяк випадок». Просто дисциплінована звичка: зберігати логи, порівнювати інциденти, слідувати доказам.

Ця практика здається нудною, поки вона не рятує вам тиждень. Тоді вона виглядає як професіоналізм.

Типові помилки: симптом → причина → виправлення

Цей розділ навмисно специфічний. Якщо ви впізнаєте себе в якому-небудь пункті — добре. Виправлення дешевше за гордість.

1) «Зависає тільки під час ігор» → припущення «драйвер GPU» → реальність: зберігання/PCIe

• Симптом: Тверде зависання під навантаженням, немає BSOD, аудіо зациклюється.
• Ймовірна причина: NVMe таймаути під час запису shader cache, потокової підвантаження ігор або активності підкачки; або проблеми PCIe, що проявляються як corrected AER помилки.
• Виправлення: Перевірити журнали на NVMe скидання/таймаути; оновити BIOS та прошивку SSD; протестувати відключення ASPM/APST; переконатися, що драйвери чипсету/зберігання актуальні; перевірити охолодження SSD.

2) «Немає помилок у SMART, отже диск в порядку» → ігнорування неправильних лічильників

• Симптом: Система стагнує, потім відновлюється; з часом зависання посилюються.
• Ймовірна причина: CRC-помилки (кабель/бэкплейн), записи в NVMe error log або зависання на рівні прошивки, що не відображаються в базовому SMART «PASSED» статусі.
• Виправлення: Перевірте UDMA_CRC_Error_Count (SATA) і журнали помилок NVMe; замініть кабелі; перепідключіть пристрої; перевірте помилки PCIe.

3) «Увімкнули кеш запису — стало швидше» → хвостова латентність і ризик втрати даних при відключенні живлення

• Симптом: Кращі бенчмарки, гірші реальні зависання, особливо при інтенсивних записах.
• Ймовірна причина: Політики кешування взаємодіють з GC прошивки або поведінкою flush; збільшення черг приховує проблеми, поки ті не проявляться.
• Виправлення: Використовуйте тестування, орієнтоване на латентність (fio з перцентилями clat); тримайте налаштування кешування консервативними, якщо немає захисту живлення й валідації.

4) «Це файлова система» → трактування корупції як причини замість наслідку

• Симптом: Попередження файлової системи після вимушеного перезавантаження.
• Ймовірна причина: Нижчестоящі I/O помилки, що призводять до неповних записів.
• Виправлення: Спочатку стабілізуйте шлях зберігання; потім виконайте відновлення файлової системи; відновлюйте з резервних копій, якщо є постійні помилки.

5) «Збільшимо конкурентність, щоб закінчити швидше» → насичення пристрою до відмови

• Симптом: Частота зависань зростає, коли ви «прискорюєте» навантаження.
• Ймовірна причина: Глибина черги й тривалі записи запускають гірші сценарії прошивки або тепловий тротлінг, що веде до таймаутів.
• Виправлення: Обмежте concurrency/iodepth; покращіть охолодження; валідируйте за допомогою iostat і fio; розгляньте SSD для стійких записів.

6) «Немає логів, бо зависло» → не зберігаються логи попереднього завантаження

• Симптом: Після перезавантаження нічого корисного; всі гадки.
• Ймовірна причина: Логи були прокручені, журнал у пам’яті, відсутність збереження дампів.
• Виправлення: Увімкніть persistent journaling, збільште збереження, експортуйте логи. Якщо ви не бачите останнього завантаження — не зможете робити судову експертизу.

Чеклісти / покроковий план

Використовуйте це як оперативний план. Роздрукуйте. Виконуйте як інцидент, а не як хобі.

Чекліст A: Перші 30 хвилин після зависання

1. Зафіксуйте приблизний час зависання і що робила система (копіювання файлів, оновлення, ігри, компіляція, бекап VM).
2. Після перезавантаження негайно витягніть логи попереднього завантаження:
   • Linux: journalctl -k -b -1
   • Windows: System log навколо часу зависання і при наступному завантаженні
3. Шукайте: таймаути, скидання, I/O помилки, AER/WHEA події.
4. Зробіть знімок апаратного контексту: модель SSD, прошивка, версія BIOS, версії драйверів зберігання.
5. Якщо є помилки зберігання: зробіть резервну копію зараз. Не «чекайте наступного разу».

Чекліст B: Контрольоване відтворення та ізоляція

1. Запустіть контрольоване I/O навантаження (fio або еквівалент) і моніторте:
   • iostat -x 1 для await/utilization
   • журнали ядра на предмет скидань/таймаутів
2. Тестуйте по одній змінній:
   • Вимкнути ASPM (залежить від платформи) і протестувати
   • Вимкнути/знизити NVMe APST (параметр ядра) і протестувати
   • Оновити прошивку SSD і протестувати
   • Оновити BIOS/UEFI і протестувати
3. Якщо SATA: поміняйте кабель/порт бэкплейну; повторіть тест.
4. Якщо відтворюється лише при нагріванні: виміряйте температуру SSD; покращіть охолодження; повторіть тест.

Чекліст C: Якщо не вдається відтворити, але зависання тривають

1. Підвищіть спостережуваність:
   • Увімкніть persistent journald
   • Налаштуйте core/kernel dump (де застосовно)
2. Шукайте повільні сигнали:
   • Наростаючі записи в NVMe error log
   • Зростаючі CRC лічильники
   • Зростаючі corrected PCIe помилки
3. Заплануйте вікно обслуговування для перепідключення апаратури й оновлення прошивки.
4. Встановіть поріг заміни: якщо скидання трапляються більше одного разу на тиждень — не сперечайтеся, замініть пристрій/шлях.

FAQ

1) Чому немає BSOD? Хіба Windows/Linux не впадуть, якщо зберігання помре?

Ні. Обидві ОС намагаються відновитися від проблем зі зберіганням через повтори і скидання. Зависання може бути тим, що ОС чекає на I/O, а не фатальною помилкою.

2) Я бачу Windows Event ID 129. Чи означає це, що мій SSD поганий?

Це означає, що Windows виконала скидання пристрою, бо він перестав відповідати. SSD може бути поганим, але також проблемою може бути прошивка, енергоменеджмент PCIe, нестабільний слот або драйвер. Розглядайте це як «нестабільність шляху зберігання».

3) Linux показує «controller is down; will reset.» Це завжди апаратна проблема?

Часто — так, але не завжди. Це може бути баг прошивки, активований APST/ASPM, тепловий тротлінг або проблеми лінку PCIe. Іноді заміна апаратури — найшвидше рішення, але спочатку валідність перевіряють прошивкою й тестами енергоменеджменту.

4) Чи справді поганий SATA-кабель може зависити систему?

Так. CRC-помилки викликають повтори; повтори спричиняють затримки; затримки змушують ОС виглядати завислою — особливо якщо цей диск зайнятий або там розміщено журнал ОС.

5) Мій SMART каже «PASSED». Чому ви все одно підозрюєте зберігання?

Бо «PASSED» — не гарантія. Дивіться на конкретні лічильники (pending sectors, CRC errors, NVMe error logs) і на журнали таймаутів ОС. Вони ближчі до реального стану.

6) Чи може це бути нестабільність ОЗП або CPU?

Абсолютно. Якщо ви бачите watchdog soft lockups без помилок зберігання, або якщо помилки з’являються в різних несуміжних підсистемах, виконуйте тестування пам’яті і вимикайте розгони/заниження напруг. Але не пропускайте журнали зберігання — вони часто показують першу видиму ланку в ланцюгу.

7) Якщо вимкнення ASPM/APST усуває проблему, чи це «остаточне рішення»?

Це може бути прийнятне робоче рішення, особливо на десктопах. «Остаточне рішення» зазвичай — оновлення BIOS/прошивки SSD або заміна апаратури, щоб зберегти можливість енергоменеджменту без зависань.

8) Як припинити втрату доказів після жорсткого вимкнення живлення?

На Linux переконайтеся, що journald persistent і логи не зберігаються лише в пам’яті. На Windows переконайтеся, що журнали подій зберігаються достатньо довго і не перезаписуються. Також записуйте час зависання, щоб корелювати події.

9) Що робити, якщо зависання відбувається раніше, ніж ОС встигає щось залогувати?

Тоді покладайтеся на те, що зберігається: логи прошивки (якщо доступні), апаратні індикатори і крос-завантажувальні докази (логи попередніх завантажень, інкрементні лічильники SMART/NVMe error). Також намагайтеся відтворити під контролем навантаження й міняти одну змінну за раз.

10) Чи викликають зовнішні USB-диски теж зависання?

Так, особливо пристрої, що живляться з шини, або ненадійні корпуси. Таймаути USB-зберігання можуть блокувати I/O і створювати затримки системи, залежно від того, що змонтовано і як ОС це обробляє.

Наступні кроки, які ви можете виконати сьогодні

Припиніть трактувати «без BSOD» як «без підказки». Підказка зазвичай вже є в журналах таймаутів зберігання, тихо документуючи кожний випадок, коли система змушена була скинути пристрій, щоб продовжувати роботу.

Зробіть наступне:

1. Витягніть журнали попереднього завантаження ядра/системи і пошукайте таймаути/скидання (NVMe/SATA/AER/WHEA).
2. Якщо їх знайдено, негайно зробіть резервну копію і почніть з оновлення прошивки/BIOS та тестів енергоменеджменту (ASPM/APST).
3. Виміряйте хвостову латентність під навантаженням. Якщо максимальна латентність доходить до секунд — ось ваш генератор зависань.
4. Якщо докази вказують на конкретний диск або шлях — замініть його. Це не одкровення про вашу компетентність; це звичне технічне обслуговування.

Мета не в тому, щоб виграти суперечку з машиною. Мета — зробити зависання нудно неможливими. Журнали приведуть вас туди — якщо ви читаєте правильні.