Ubuntu 24.04: NVMe зникає під навантаженням — налаштування живлення/ASPM, які часто це вирішують

Ви навантажуєте ввод/вивід — контрольна точка бази даних, вікно резервного копіювання, ферма компіляції чи що завгодно — і раптом NVMe просто… зникає.
Хвилину тому це був /dev/nvme0n1, потім — археологічна загадка. Файлова система переходить у режим тільки для читання, RAID/ZFS починають кричати,
а система моніторингу світиться, як святкова гірлянда, яку ви не замовляли.

В Ubuntu 24.04 патерн «NVMe зникає під навантаженням» часто не означає, що SSD помирає. Це управління живленням: PCIe ASPM на лінку
та/або NVMe APST всередині контролера. Обидва у теорії працюють, але можуть стати катастрофічними, коли прошивка платформи, топологія PCIe
або прошивка диска поводяться творчо. Ось прагматичний, придатний для продакшну підхід — як швидко діагностувати, безпечно виправити і переконатися, що ви справді виправили.

Що означає «NVMe зникає» насправді (і чому це рідко магія)

Коли оператори кажуть «NVMe зник», зазвичай мають на увазі одну з трьох речей:

1. Блоковий пристрій зникає:
   /dev/nvme0n1 зник, udev його видалив, і все, що було змонтовано на ньому, — біда.
2. Пристрій залишається, але I/O зависає:
   він все ще присутній у списку, але читання/запис зависають, тайм-аутяться, а потім ядро переходить до скидання контролера.
3. PCIe-функція стає неактивною:
   контролер NVMe присутній на шині, але лінк флапає або AER (Advanced Error Reporting) голосно попереджає.

Ключова підказка — «під навантаженням». Велика черга, тривалі записи, активний DMA і термічний стрес підсилюють таймінги.
Саме тоді переходи станів живлення, що «зазвичай працюють», починають програвати гонки.

Якщо це відбувається в Ubuntu 24.04, ймовірно, у вас досить сучасне ядро та стек NVMe. Це добре для фіч.
Це також добре для виявлення того, що управління живленням платформи було спроєктоване комісією, чия робота закінчувалася на «завантажує Windows».

Факти та історичний контекст, які пояснюють безлад

• ASPM з’явився раніше за NVMe: PCIe Active State Power Management створювали для економії енергії лінка задовго до того, як NVMe став стандартом для зберігання.
• NVMe APST існує через потребу в економії енергії: Autonomous Power State Transitions дозволяють контролерам зберігати енергію без постійного втручання ОС.
• AER став поширеним із ростом швидкостей PCIe: вищі швидкості лінків і менші допуски зробили звітування помилок і відновлення важливішими — і більш помітними в логах.
• Прошивки споживчих NVMe часто оптимізовані під бенчмарки: швидкі пікові показники можуть приховувати неприємні крайові випадки при тривалих змішаних навантаженнях.
• Ноутбуки задавали агресивні енергетичні налаштування: багато вендорів орієнтуються на час роботи від батареї, іноді поставляючи прошивку, яка «оптимістично» оцінює стабільність лінка.
• Linux з часом краще навчився runtime PM: але «краще» також означає «більш активний», що збільшує шанси натрапити на баги конкретної платформи.
• PCIe Gen4/Gen5 зробили цілісність сигналів менш поблажливою: чим швидше — тим помітніший маргінальний макет плати або ретаймер як «випадкове відключення пристрою».
• NVMe має кілька шарів тайм-аутів: тайм-аути контролера, blk-mq, файлової системи та вищих рівнів можуть маскувати справжню точку відмови.
• Ubuntu 24.04 запускає systemd з агресивними інструментами енергозбереження: користувацький простір може впливати на runtime PM і політику, що інколи «допомагає», поки не нашкодить.

Операційний висновок: ви маєте справу з багаторівневим стеком живлення (прошивка платформи, політика PCIe лінка, політика контролера NVMe, Linux runtime PM).
Якщо один шар бреше, інші йому вірять — аж доки SSD не зникне під час контрольної точки.

Швидкий план діагностики (перевірте 1–2–3)

Коли ви на виклику, у вас немає часу на інтерпретаційний танець. Робіть це в порядку.

1) Підтвердіть, що це справді проблема пристрою/лінка, а не ілюзія файлової системи

• Шукайте в логах ядра тайм-аути nvme і скидання контролера.
• Шукайте помилки PCIe AER від апстрім-порту (pcieport).
• Підтвердіть, чи namespace-пристрій зник, чи просто завис.

2) Визначте, які енергетичні опції задіяні

• Чи увімкнено PCIe ASPM у системі?
• Чи увімкнено NVMe APST (і які затримки простою дозволені)?
• Чи встановлено runtime PM у значення auto для PCI-пристрою NVMe?

3) Відтворіть безпечно і вирішіть: стабілізуйте спочатку, оптимізуйте потім

• Запустіть контрольоване I/O навантаження й спостерігайте за шаблонами помилок.
• Застосуйте найменшу стабілізуючу зміну (часто вимкнення ASPM і/або APST).
• Повторіть те саме навантаження й порівняйте логи, не відчуття.

Парафраз ідеї від Werner Vogels (надійність/операції): «Усе ламається; проєктуйте так, щоб відмова була очікуваною і відновлення — рутинним».

Практичні завдання: команди, виводи та рішення (12+)

Це завдання, які я реально виконую, коли NVMe поводиться некоректно під навантаженням. Кожне містить (а) команду, (б) що зазвичай означає вивід,
і (в) рішення, яке слід прийняти.

Завдання 1: Знайдіть помилки ядра, пов’язані з NVMe, швидко

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'nvme|pcie|aer|timeout|reset' | tail -n 60
Dec 29 09:11:22 server kernel: nvme nvme0: I/O 123 QID 6 timeout, aborting
Dec 29 09:11:22 server kernel: nvme nvme0: Abort status: 0x371
Dec 29 09:11:22 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1
Dec 29 09:11:23 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
Dec 29 09:11:23 server kernel: pcieport 0000:00:1c.0: AER: device recovery successful

Що це означає: Тайм-аути NVMe I/O і скидання контролера часто вказують на нестабільність лінка/живлення або зависання прошивки/контролера під навантаженням.
Corrected AER на апстрім-порту — сильна підказка, що PCIe-лінк глючить.

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

Завдання 2: Перевірте, чи namespace-пристрій NVMe реально зник

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,MOUNTPOINTS | egrep -i 'nvme|NAME'
NAME        TYPE   SIZE MODEL               SERIAL            MOUNTPOINTS
nvme0n1     disk 931.5G ExampleNVMe 1TB     ABCD1234
├─nvme0n1p1 part   512M                                     /boot
└─nvme0n1p2 part   931G                                     /

Що це означає: Якщо nvme0n1 зникає тут після інциденту, udev видалив його через те, що контролер впав з шини або серйозно вийшов з ладу.
Якщо він залишається, але I/O зависає, контролер може бути заблокований, але все ще перерахований.

Рішення: «Зник з lsblk» штовхає вас до проблем PCIe/лінка/сильних скидань контролера; «присутній але завис» може бути пов’язане з живленням, термікою або прошивкою.

Завдання 3: Перегляньте стан контролера NVMe через nvme-cli

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1      ABCD1234             ExampleNVMe 1TB                           1         120.0  GB /  1.00  TB    512   B +  0 B   3B2QEXM7

Що це означає: Якщо nvme list періодично падає або не показує пристроїв під час проблеми, контролер зникає з шини.

Рішення: Якщо контролер зникає — спочатку зосередьтесь на управлінні живленням PCIe і прошивці платформи; SMART не врятує, якщо шина зникла.

Завдання 4: Зчитайте SMART/здоров’я і шукайте ознаки медіа проти транспорту

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 54 C
available_spare                     : 100%
percentage_used                     : 2%
media_errors                        : 0
num_err_log_entries                 : 18
power_cycles                        : 23
power_on_hours                      : 410
unsafe_shutdowns                    : 6

Що це означає: Нульові помилки медіа з одночасним інкрементом записів логів помилок зазвичай вказують не на відмову NAND, а на скидання транспорту/контролера.
Зростання unsafe_shutdowns відповідає подіям «контролер зник».

Рішення: Якщо помилок медіа мало/немає, але скидання/тайм-аути часті — не поспішайте на RMA; стабілізуйте поведінку живлення/лінка і повторіть тест.

Завдання 5: Прочитайте журнал помилок NVMe, щоб підтвердити шаблон тайм-аут/скидання

cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 20
Error Log Entries for device:nvme0 entries:64
Entry[ 0]
 error_count     : 18
 sqid            : 6
 cmdid           : 0x00a2
 status_field    : 0x4004
 parm_error_location: 0x0000
 lba             : 0
 nsid            : 1
 vs              : 0x00000000

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

Рішення: Корелюйте стрибки error_count зі скиданнями ядра. Якщо вони співпадають — розглядайте це як проблему стабільності/станів живлення.

Завдання 6: Визначте шлях PCIe-пристрою (щоб інспектувати апстрім-порт)

cr0x@server:~$ sudo lspci -nn | egrep -i 'non-volatile|nvme'
02:00.0 Non-Volatile memory controller [0108]: Example Corp NVMe Controller [1234:11aa] (rev 01)

Що це означає: Ваш контролер NVMe на 0000:02:00.0. Ця адреса стає вашою опорою для AER, ASPM, runtime PM і стану лінка.

Рішення: Використайте цей BDF для запиту lspci -vv, sysfs power control і для знаходження апстрім-порту, що може генерувати AER.

Завдання 7: Перевірте стан PCIe-лінка і ASPM

cr0x@server:~$ sudo lspci -s 02:00.0 -vv | egrep -i 'LnkCap:|LnkSta:|ASPM|L1Sub|AER' -n
45:        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
52:        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
60:        L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+

Що це означає: Якщо LnkCap і пов’язані рядки показують підтримувані/увімкнені режими ASPM, лінк може входити в низькопотужні стани.
Це не обов’язково погано, але це основний підозрюваний, коли пристрої зникають під навантаженням або при спалахах трафіку.

Рішення: Якщо у вас відключення й ASPM увімкнено, варто перевірити з вимкненим ASPM. Стабілізуйте спочатку.

Завдання 8: Підтвердіть, чи ядро вважає ASPM увімкненим глобально

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

Що це означає: Політики як default, powersave або performance впливають на агресивність ASPM.
Деякі системи стабільні на default; інші трактують це як підказку поводитися ненадійно.

Рішення: Якщо ви гонитеся за зникненнями, заплануйте тестове завантаження з pcie_aspm=off. Якщо стабільність повернеться — ви знайшли причину.

Завдання 9: Перевірте статус NVMe APST (автономні переходи живлення контролера)

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

Що це означає: Значення 0 зазвичай означає «без обмеження», що дозволяє глибші стани енергозбереження, якщо контролер/прошивка цього хоче.
На деяких дисках глибокі переходи простою можуть погано взаємодіяти з піковими навантаженнями і викликати скидання.

Рішення: Для тестування стабільності встановіть консервативне максимальне значення затримки (або вимкніть APST) через параметр ядра. Не вгадуйте — тестуйте.

Завдання 10: Перевірте стан runtime power management для PCI-функції NVMe

cr0x@server:~$ cat /sys/bus/pci/devices/0000:02:00.0/power/control
auto

Що це означає: auto дозволяє ядру runtime-приглушувати пристрій, коли той вважається неактивним.
На ненадійних платформах runtime PM може бути тією останньою штовхалкою, що запускає дивну поведінку лінка/контролера.

Рішення: Якщо бачите скидання, спробуйте тимчасово зафіксувати runtime PM у on (без autosuspend) для NVMe-пристрою.

Завдання 11: Перевірте тайм-аути NVMe, налаштовані ядром

cr0x@server:~$ cat /sys/module/nvme_core/parameters/io_timeout
30

Що це означає: Це тайм-аут I/O в секундах. Збільшення його може маскувати симптоми (ви «довше чекатимете» перед скиданням),
але не виправляє причину, якщо контролер зникає.

Рішення: Не «виправляйте» зникнення шляхом роздуття тайм-аутів, якщо ви не впевнені, що пристрій просто повільнішає під GC. Зникнення — це не проблема затримки.

Завдання 12: Нагрузьте I/O так, щоб відтворити проблему, але не знищити продакшн

cr0x@server:~$ sudo fio --name=nvme-load --filename=/dev/nvme0n1 --direct=1 --rw=randwrite --bs=4k --iodepth=64 --numjobs=4 --runtime=120 --time_based=1 --group_reporting
nvme-load: (groupid=0, jobs=4): err= 0: pid=9123: Mon Dec 29 09:15:01 2025
  write: IOPS=82.1k, BW=321MiB/s (337MB/s)(38.6GiB/123002msec)
    lat (usec): min=48, max=21234, avg=311.42, stdev=145.11

Що це означає: Потрібен відтворюваний робочий навантаження, яке тригерить проблему. Якщо пристрій зникає під час цього тесту — у вас є репродусер.
Якщо зникає тільки під змішаним read/write або послідовним шаблоном — налаштуйте відповідно.

Рішення: Ніколи не налаштовуйте параметри живлення наосліп. Відтворіть, змініть одну змінну, повторіть, порівняйте логи.

Завдання 13: Слідкуйте за AER подіями в реальному часі під час навантаження

cr0x@server:~$ sudo dmesg -wT | egrep -i 'aer|pcieport|nvme|timeout|reset'
[Mon Dec 29 09:16:22 2025] pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
[Mon Dec 29 09:16:22 2025] nvme nvme0: I/O 87 QID 3 timeout, aborting
[Mon Dec 29 09:16:23 2025] nvme nvme0: controller is down; will reset: CSTS=0x1

Що це означає: Послідовність «AER corrected error» → «NVMe timeout» → «controller reset» — знайомий сюжет.

Рішення: Сприймайте AER як доказ. Якщо вимкнення ASPM зупиняє AER-спам і тайм-аути, імовірно ви вирішили корінь проблеми.

Завдання 14: Перевірте помилки апстрім-порту PCIe (не лише кінцевого NVMe)

cr0x@server:~$ sudo lspci -s 00:1c.0 -vv | egrep -i 'AER|UESta|CESta|Err' -n
78:        Capabilities: [100 v2] Advanced Error Reporting
96:        UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
104:       CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-

Що це означає: Corrected errors як RxErr+ вказують на проблеми сигналізації лінка або маргінальні стани живлення.
Вони «виправлені», поки не стануть невиправними.

Рішення: Якщо corrected errors різко зростають під навантаженням, припиніть ганяння за налаштуваннями файлової системи. Ідіть за управлінням живленням лінка і стабільністю платформи.

Завдання 15: Перевірте, чи диск не перегрівається до нестабільності

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning|critical'
temperature                         : 73 C
critical_warning                    : 0x00

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

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

Стек живлення: ASPM vs APST vs runtime PM (хто може вивести ваш диск з ладу)

Є три регулятори, які люди плутають. Не плутайте. Це різні шари, і їх можна змінювати окремо.

PCIe ASPM (енергозбереження на рівні лінка)

ASPM керує низькопотужними станами PCIe-лінка (не внутрішніми станами контролера NVMe). Великі гравці:
L0s і L1 (а також підстани L1.1/L1.2 на новіших платформах).

В ідеальному світі кінцевий пристрій і root-порт домовляються, входять у низькопотужний стан під час простою і швидко виходять при відновленні трафіку.
У світі, де ми живемо, час виходу іноді більш ніж амбіційний. Під навантаженням переходи можуть траплятися в невідповідний момент:
спалахи I/O, MSI/MSI-X переривання, події вирубування живлення та час від часу прошивкові баги, що говорять «я на місці», коли насправді ні.

NVMe APST (автономні стани живлення контролера)

APST — внутрішній механізм контролера NVMe. Він може вирішувати переходити в глибші стани простою, керуючись політикою ОС (макс. затримка)
і власними таблицями диска. Якщо прошивка диска надто чутлива, APST може перетворити «idle → busy» на «idle → скидання контролера».

APST також місце, де «виправлення» стають небезпечно популярними. Люди відключають його й проблема зникає. Чудово.
Потім вони розгортають цю конфігурацію повсюди і дивуються, чому ноутбуки втрачають годину заряду. Продакшн-рішення мають наслідки.

Runtime PM / autosuspend (побудоване в ОС енергозбереження на рівні пристрою)

Runtime PM — це коли ядро вирішує «пристрій неактивний, давайте призупинимо його». Для PCI-пристроїв це може означати D-стани і зміни лінка.
Це множник: навіть якщо ASPM і APST поводяться добре, runtime PM може викликати додаткові переходи.

Коротка жартівлива метафора: керування живленням PCIe нагадує світло з датчиком руху в коридорі — чудово, поки ви не несете щось крихке і воно згасає посеред кроку.

Виправлення, які зазвичай працюють: параметри ядра, udev та BIOS-настройки

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

Варіант виправлення A: Вимкнути PCIe ASPM (висока ймовірність успіху для «зникає під навантаженням»)

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

Тимчасовий тест (одне завантаження)

У меню GRUB відредагуйте рядок завантаження й додайте:
pcie_aspm=off

Постійна зміна (GRUB)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=off /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-xx-generic
Found initrd image: /boot/initrd.img-6.8.0-xx-generic
done

Що означає вивід: update-grub згенерував конфігурацію завантаження і знайшов ядро/initrd.

Рішення: Перезавантажтесь із новим cmdline ядра. Заново запустіть репродусер (fio + перегляд dmesg). Якщо відключення dropouts припинилося — лишіть це, поки не вирішите, чи потрібне вузькіше виправлення.

Варіант виправлення B: Обмежити або відключити NVMe APST (часто фіксує «тайм-аути → скидання»)

Якщо контролер заходить у глибокі стани NVMe і не повертається коректно, APST — ваш важіль.
У Linux загальний контроль — nvme_core.default_ps_max_latency_us=.

Поширені налаштування

• Вимкнути APST (часто): nvme_core.default_ps_max_latency_us=0 іноді інтерпретується як «без обмеження», а не «вимкнути», залежно від поведінки ядра і таблиць диска. На практиці багато операторів використовують невелике ненульове значення, щоб запобігти глибоким станам.
• Запобігти глибоким станам: встановіть низьку максимальну затримку, наприклад 1000 (1ms) або 5000 (5ms), щоб уникнути найглибшого сну, але залишити невелику економію енергії.

Неприємна правда: правильне число залежить від платформи і диска. Це не філософія — логи після контрольованого тесту підкажуть.

Постійна зміна (GRUB)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="nvme_core.default_ps_max_latency_us=5000 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-xx-generic
Found initrd image: /boot/initrd.img-6.8.0-xx-generic
done

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

Варіант виправлення C: Вимкнути runtime autosuspend для PCI-пристрою NVMe

Для систем, де runtime PM занадто винахідливий, зафіксувати PCI-функцію NVMe у стані «on» може допомогти.
Це виправлення на рівні пристрою, тож не караєте всю машину.

Негайно (до перезавантаження)

cr0x@server:~$ echo on | sudo tee /sys/bus/pci/devices/0000:02:00.0/power/control
on

Що це означає: Пристрій тепер виключений з runtime autosuspend.

Рішення: Якщо стабільність покращилась — зробіть це постійним через udev-правило.

Постійно через udev-правило

cr0x@server:~$ sudo tee /etc/udev/rules.d/80-nvme-runtimepm.rules >/dev/null <<'EOF'
ACTION=="add", SUBSYSTEM=="pci", KERNELS=="0000:02:00.0", ATTR{power/control}="on"
EOF
cr0x@server:~$ sudo udevadm control --reload-rules
cr0x@server:~$ sudo udevadm trigger -s pci

Що означає вивід: Відсутність виводу — нормально; правила udev перезавантажено і застосовано. Перевірте через sysfs.

cr0x@server:~$ cat /sys/bus/pci/devices/0000:02:00.0/power/control
on

Рішення: Тримайте це, якщо вирішило проблему і ви готові терпіти компроміс по енергії. Це часто м’якше за повне вимкнення ASPM глобально.

Варіант виправлення D: Налаштування BIOS/UEFI (коли програмні важелі не допомагають)

Якщо корінь — у поведінці ASPM на рівні прошивки або проблемі з сигналізацією плати, програмними методами не обійтися.
Корисні опції BIOS/UEFI:

• PCIe ASPM: вимкніть або поставте «off». Деякі вендори ховають це в розділі «Power» або «Advanced > PCIe».
• Native ASPM: вимкнення може змусити прошивку керувати поведінкою; увімкнення передає контроль ОС. Що допоможе — залежить від якості вендора.
• PCIe Link Speed: примусове зниження до Gen3 замість Gen4 може стабілізувати маргінальні лінки. Це «потрібно стабільності сьогодні» рішення.
• Global C-states / Package C-states: глибокі стани сну CPU можуть взаємодіяти з енергетичними шинами чипсету. Вимкнення найглибших станів іноді вирішує проблему.

Якщо ви змушені примусово ставити Gen3 або вимикати глибокі C-states, сприймайте це як обхід дефекту апаратури/прошивки, а не «налаштування Linux».

Варіант виправлення E: Оновлення прошивки (NVMe + BIOS)

Оновлення прошивки NVMe може виправити таблиці APST, відновлення після скидання і баги станів живлення. Оновлення BIOS може виправити тренінг PCIe і політику ASPM.
Застосовуйте їх як дорослі: change management, вікно обслуговування, можливість відкату там, де можливо.

Три міні-історії з корпоративного життя (оскільки реальність дивна)

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

Команда працювала на кількох Ubuntu-хостах, куди надходили логи у локальний NVMe-чергу. Хости були стабільні тижнями.
Потім нова версія пайплайна підвищила конкуруючу інтенсивність записів. Спочатку це виглядало як софтверна проблема: корупція черги, дивні повторні спроби і різкі сплески затримки.

Неправильне припущення було тонким: «Якщо SMART чистий, диск в порядку». Їхні SMART-перевірки не показували помилок медіа і запас був добрий.
Тож вони почали налаштовувати застосунок, розширювати буфери й додавати повторні спроби. Це зменшило видимі помилки, але збільшило час відновлення після стагнації.

Під час сильного сплеску ядро залогувало NVMe I/O тайм-аути, потім скидання контролера, потім namespace зник. Процес-менеджер перезапустив сервіси, що не допомогло.
Хости відновилися лише після перезавантаження. Зберігання «самосянилося», а це знак, що проблема повториться.

Насправді проблема не була в NAND. Це була нестабільність PCIe-лінка під агресивним управлінням живленням на тій ревізії материнської плати.
Вимкнення ASPM припинило зникаючий ефект одразу. Команда потім тестувала повторне увімкнення ASPM з обмеженням APST — це допомогло на деяких машинах, не на всіх.

Операційний урок: SMART говорить про флеш і стан контролера, а не про те, чи PCIe-лінк в паніці.
Вони додали оповіщення по AER і скиданнях NVMe, щоб наступного разу зловити це до того, як файлова система стане тільки для читання.

Міні-історія 2: Оптимізація, що вдарила в спину

Інша організація намагалася зменшити споживання енергії в лабораторному кластері, що «може стати продакшном». Вони увімкнули агресивний енергетичний профіль і
налаштували політики ядра на економію. Машини були переважно в прості, з періодичними важкими збірками.

На папері це виглядало розумно: машини в простої повинні споживати мало. На практиці кластер почав скидати NVMe під час сплесків збірок.
Шаблон був божевільним: довга пауза, потім буря компіляцій, потім скидання контролера під час запису артефактів.

Вони тижнями ганялися за продуктивністю. Проблема не в пропускній здатності; це був шлях переходів станів. Навантаження мало різкий on/off:
нічого хвилин, потім екстремальний метаданих-чурн і паралельні записи. Це фактично тортурний тест для станів енергозбереження.

«Оптимізація» була runtime PM + глибокий ASPM + дозволений APST. Це змусило платформу постійно входити в глибокий сон,
а потім вимагати миттєвого пробудження в найгірший момент. Вимкнення runtime autosuspend для NVMe виправило більшість вузлів.
Декілька вузлів потребували повного вимкнення ASPM.

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

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

Сервіс поруч із фінансами працював на парі серверів з NVMe-базованими базами. Нічого особливого. Просто стабільне I/O і суворі очікування доступності.
Їхній SRE-лідер відомий своєю нудною педантичністю щодо контролю змін. Ця нудність окупилася.

Вони мали звичку: кожне оновлення ядра/прошивки мало pre-flight тест, що включав I/O-стрес і чекліст перегляду логів.
Це не було героїчним. Це було заплановано, задокументовано і повторювано.

Після оновлення прошивки платформи стрес-тест почав давати corrected AER помилки на апстрім-порту NVMe.
Аварій ще не було, видимого впливу на додаток теж, лише новий тип шуму в логах. Більшість команд ігнорують це, бо «corrected».

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

Через тижні вендор надав виправлену прошивку, яка відкоригувала поведінку станів PCIe. Сервіс ніколи не мав продакшн-аутейджу від цього.
Практика, що врятувала їх, була не геніальною; вона полягала в тому, щоб відмовитися деплоїти, коли система шепотіла «я не в порядку».

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

Тут більшість аутеджів переходять з «дратівливих» у «генерують резюме».

1) Симптом: «Файлова система стала тільки для читання, отже NVMe помирає»

Коренева причина: скидання контролера або відключення PCIe-лінка викликало помилки I/O; файлова система змонтувалася тільки для читання, щоб себе захистити.

Виправлення: підтвердіть через journalctl -k на наявність тайм-аутів/скидань; вирішіть ASPM/APST/runtime PM; потім валідуйте під навантаженням.

2) Симптом: «SMART чистий, отже диск не винен»

Коренева причина: нестабільність транспорту/лінка не завжди проявляється як помилки медіа.

Виправлення: корелюйте AER-помилки і скидання NVMe; перевірте статус PCIe-лінка; розглядайте це як проблему стабільності платформи.

3) Симптом: «Тільки під навантаженням, отже перегрів»

Коренева причина: може бути терміка, але часто це таймінги переходів станів живлення під тривалим навантаженням черги.

Виправлення: перевірте температури, так; але також відтворіть з ASPM off або APST обмеженим. Термальні зміни без підтвердження в логах — це просто косметика для ОВК.

4) Симптом: «Вимкнення ASPM виправило — розгортаю повсюди»

Коренева причина: генеральна політика на основі однієї невдалої комбінації платформи/диска.

Виправлення: сприймайте як hardware profile-specific. На ноутбуках і енергочутливих розгортаннях пробуйте точкові виправлення (обмеження APST, вимкнення runtime autosuspend лише для NVMe).

5) Симптом: «Я збільшив nvme io_timeout і тепер не скидається»

Коренева причина: ви перетворили жорстку відмову на довшу завислості. Пристрій все ще стає в нескінченний стан; ви просто довше чекаєте, щоб це визнати.

Виправлення: скасуйте хитрощі з тайм-аутами; виправте базову нестабільність; використовуйте тайм-аути для налагодження поведінки відновлення лише після доведення стабільності.

6) Симптом: «AER corrected errors нешкідливі»

Коренева причина: corrected errors можуть бути раннім попередженням маргінального лінка, який під навантаженням згодом дасть невиправлені помилки.

Виправлення: відстежуйте рівні corrected errors; розслідуйте сплески; тестуйте з примусовим пониженням швидкості Gen або налаштуваннями ASPM.

7) Симптом: «Відбувається тільки після простою»

Коренева причина: глибокі стани простою (ASPM L1.2, глибокі PS APST, runtime suspend) плюс раптове навантаження створюють невдалий шлях пробудження.

Виправлення: вимкніть runtime autosuspend для NVMe; обмежте APST max latency; розгляньте вимкнення ASPM, якщо потрібно.

Другий і останній жарт: Якщо ваш NVMe постійно зникає, вітаю — ви винайшли хмарне зберігання, тільки хмара тут — ваша шина PCIe і вона бере відсоток.

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

Покроково: як стабілізувати ненадійний NVMe на Ubuntu 24.04 в продакшн

1. Спочатку зафіксуйте докази.
   Збережіть journalctl -k -b, lspci -vv для NVMe і апстрім-порту, та nvme smart-log.
   Потрібні докази «до/після».
2. Визначте клас відмови.
   Пристрій зник проти пристрій завис. «Зник» сильно вказує на PCIe/лінк/енергію; «завис» може бути пов’язане з живленням, прошивкою або термікою.
3. Відтворіть з контрольованим навантаженням.
   Використайте fio на сирому пристрої, якщо безпечно, або на тестовому розділі. Слідкуйте dmesg -wT в реальному часі.
4. Перша зміна: вимкнути ASPM для одного завантаження.
   Додайте pcie_aspm=off. Повторіть тест. Якщо виправило — вирішіть, тримати чи шукати вужче рішення.
5. Друга зміна: обмежити NVMe APST.
   Додайте nvme_core.default_ps_max_latency_us=5000 (або схоже) і тестуйте. Налаштовуйте за результатами.
6. Третя зміна: вимкнути runtime autosuspend для PCI NVMe.
   Встановіть /sys/bus/pci/devices/.../power/control в on; збережіть через udev, якщо це працює.
7. Перевірте переходи idle→burst.
   Класична відмова: «проста 10 хвилин, потім сплеск». Відтворіть цей сценарій вашим тестом.
8. Перевірте BIOS/UEFI, якщо софт не допоміг.
   Вимкніть ASPM у прошивці, принудьте Gen3 або тимчасово вимкніть глибокі C-states, щоб підтвердити корінь.
9. Коли стабільно — оптимізуйте обережно.
   Увімкніть по одному елементу енергозбереження, вимірюйте і зупиняйтеся при поверненні помилок.
10. Операціоналізуйте запобіжні заходи.
    Додайте алерти на скидання NVMe/тайм-аути і сплески PCIe AER. Стабільність без виявлення — це просто несподіваний ребалансинг.

Чек-лист відкату (бо він стане в нагоді)

1. Майте доступ до консолі (IPMI/iDRAC/KVM) перед змінами параметрів ядра.
2. Документуйте попередній рядок у /etc/default/grub і збережіть копію.
3. Вносіть по одній постійній зміні; перезавантажуйтесь; тестуйте; потім рухайтеся далі.
4. Якщо хост не завантажується або поведінка зберігання погіршується — видаліть останній параметр ядра і згенеруйте GRUB заново.

FAQ

1) Це баг Ubuntu 24.04?

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

2) Що спочатку вимкнути: PCIe ASPM чи NVMe APST?

Якщо NVMe «зникає» (випадає з шини) і ви бачите AER/шум лінка, спочатку вимкніть ASPM.
Якщо більше «тайм-аути → скидання» без явного AER, спробуйте обмежити APST. На практиці ASPM-off — швидкий бінарний тест.

3) Чи вплине вимкнення ASPM на продуктивність?

Зазвичай не в пропускній здатності. Може трохи підвищити споживання в простої і іноді змінити мікро-латентність. Справжня «шкода» — енергоефективність,
що важливіше на ноутбуках і в щільних фермах.

4) Чи зіпсує відключення APST батарею на ноутбуках?

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

5) Я бачу лише «AER corrected errors». Чи це важливо?

Так, якщо вони корелюють зі сплесками навантаження або передують NVMe тайм-аутах/скиданням. Corrected errors — раннє попередження.
Якщо вони постійні і без наслідків місяцями — можливо ігноруйте; якщо з’явилися після оновлення — розслідуйте.

6) Чи може поганий кабель викликати відвал NVMe?

Для M.2 on-board NVMe — ні. Але для U.2/U.3 або PCIe бекплейнів — абсолютне так. Погана цілісність сигналів виглядає як AER-шум і перетренування лінка.
В серверах «це кабель/бекплейн» — нудно, але часто правильно.

7) Чи варто примусово переводити PCIe у Gen3 як обходний шлях?

Якщо потрібна стабільність сьогодні і ваш лінк маргінальний на Gen4/Gen5, примусове Gen3 — робочий тимчасовий крок.
Ви пожертвуєте піковою пропускною здатністю, але збережете файлову систему — хороший обмін.

8) Чому це трапляється під навантаженням, а не в простої?

Навантаження збільшує чергу, DMA-активність, переривання і тепловиділення. Також створює різкі переходи між зайнятим і простим режимами.
Саме ці переходи підривають баги логіки станів живлення.

9) Чи коли-небудь варто збільшувати nvme_core.io_timeout?

Рідко, і лише коли доведено, що пристрій повільний, але стабільний (наприклад, тривалий внутрішній GC) і скидання контрпродуктивні.
Для «пристрій зникає» збільшення тайм-аутів — не рішення.

10) Як довести, що виправлення справді спрацювало?

Використайте той самий репродусер (той самий fio-шаблон, тривалість, глибину черги), порівняйте логи ядра на AER/тайм-аути/скидання і проведіть idle→burst тест.
«Відчувається краще» — це не стратегія валідації.

Висновок: практичні наступні кроки

Коли NVMe зникає під навантаженням в Ubuntu 24.04, зазвичай це крайовий випадок управління живленням:
PCIe ASPM на лінку, NVMe APST у контролері, runtime PM в ОС або якась приємна комбінація.
Виправлення рідко містичне. Воно дисципліноване: зберіть логи, відтворіть, змініть один важіль і перевірте знову.

Наступні кроки, які швидко дають результат:

• Запустіть швидкий план: перевірте логи на NVMe тайм-аути/скидання і PCIe AER; підтвердіть, чи пристрій зник чи завис.
• Тестово завантажте з pcie_aspm=off. Якщо стабільність повертається, вирішіть, тримати чи шукати вужчий варіант.
• Якщо потрібно, обмежте APST через nvme_core.default_ps_max_latency_us і/або вимкніть runtime autosuspend для PCI-функції NVMe.
• Підтверджуйте результат повторюваним навантаженням і idle→burst тестом, потім додайте алерти на сплески AER і скидання NVMe.