USB-пристрій не розпізнано: налаштування живлення, яке вбиває ваші порти

February 14, 2026 • February 14, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Ви підключаєте USB‑пристрій, а Windows повідомляє «Device not recognized», Linux виводить загадкову помилку descriptor, або диск монтується й раптом зникає під час копіювання, ніби пригадав, що забув вимкнути плиту. Ви міняєте порти. Перезавантажуєте. Пильно дивитесь на кабель. Нічого.

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

Чому налаштування живлення ламають USB (і чому це виглядає випадково)

USB продавали як «plug and play». У реальному використанні це «підключив, домовився, перечислив, виділив живлення, можливо завантажив прошивку, потім працюєш». Цей ланцюжок крихкий. Коли будь-який шар «допомагає» заощаджувати енергію, ви не отримуєте чисту помилку на кшталт «недостатній пусковий струм на VBUS». Ви отримуєте класику: невідомий пристрій, device descriptor request failed, пристрій працює лише по вівторках або флешка поводиться нормально тільки при підключеному живленні ноутбука.

Менеджмент живлення може ламати USB трьома основними шляхами:

Логіка призупинення на боці хоста: «USB selective suspend» у Windows, autosuspend у Linux, поведінка power nap у macOS. Хост вирішує відключити живлення або перевести лінк у низький енергетичний стан.
Бюджетування та захист на боці хаба: у хаба є обмеження за струмом і правила; дешеві хаби іноді «творчо» інтерпретують фізику. Спрацьовує захист від перевантаження, порти просаджують напругу або хаб бреше щодо доступного струму.
Толерантність пристрою: деякі пристрої мають великий пусковий струм (диски), нестабільну прошивку або жорсткі вимоги до таймінгів під час enumeration. Моментальна просадка змушує їх перезапуститися; повторні перезапуски виглядають як «не розпізнано».

Чому це здається випадковим: тригер часто — перехід у інший стан. Екран вимикається. Кришка зачиняється. ОС вирішує, що пристрій простає. Пакетний стан CPU змінюється. Хаб нагрівається. SSD починає тривалу запис‑операцію й контролер споживає більше струму. Випадковість? Ні. Це системна історія: кілька оптимізаторів діють автономно.

Две прості правила, яким я довіряю:

Якщо пристрій падає під час enumeration, підозрюйте перш за все живлення та цілісність сигналу (кабель, порт, хаб, проводка фронт‑панелі, політика живлення), перш ніж ганятися за драйверами.
Якщо він відмовляє під навантаженням (копіювання, стрім камери, мережевий адаптер, аудіоінтерфейс), підозрюйте бюджет живлення, особливості UASP та управління енергоспоживанням лінку. Потім — прошивку.

Жарт #1: USB означає «Universal Serial Bus», але іноді хочеться думати «Usually Something’s Broken».

Швидкий план діагностики

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

Перш за все: вирішіть, чи це пов’язано з політикою живлення чи чистим апаратним дефектом

Відтворіть на мережевому живленні (AC) (ноутбук) і з увімкненим екраном. Якщо проблема виникає лише на батареї або після простою — головний підозрюваний — політика живлення.
Перемістіть порт: порт на задній панелі матплати (десктоп) або інший бік (ноутбук). Уникніть спочатку фронт‑панельних хедерів.
Вимкніть хаби/доки: підключіть напряму host ↔ device. Якщо починає працювати — хаб/док винні, поки не доведено зворотне.

Друге: зберіть докази (не діагностуйте всліпу)

Windows: Event Viewer (Kernel‑PnP), вкладка «Power Management» у Диспетчері пристроїв і налаштування powercfg.
Linux: dmesg -Tw під час підключення пристрою; перевірте autosuspend і топологію USB.
macOS: System Information → USB tree; шукайте «Accessory needs power» або повторні відключення.

Третє: застосуйте найменш інвазивне виправлення

Вимкніть selective suspend/autosuspend для конкретного пристрою або контролера, перш ніж лізти в глобальні налаштування.
Використовуйте живлений хаб для дисків, що живляться від шини, і пристроїв з великим споживанням; уникайте підозрілих «тільки зарядних» хабів.
Оновіть BIOS/UEFI та прошивку/драйвери контролера USB (так, це ще важливо).

Четверте: підтвердіть виправлення під навантаженням

Запустіть тривале копіювання, стрім камери або I/O‑тест 10–20 хвилин.
Переведіть машину в сплячий режим і прокиньте. Відключіть/підключіть знову. Перевірте саме той сценарій, який важливий.

Цікаві факти й історія (коротко, корисно, трохи тривожно)

USB 1.0 анонсували 1996 року, частково щоб замінити зоопарк портів (serial, parallel, PS/2). «Універсальний» аспект був так само політичним, як і технічним.
Живлення USB спочатку було консервативним: ранні порти проектувалися для пристроїв з низьким енергоспоживанням, як‑от миші й клавіатури, а не для SSD, які під час запису беруть значний струм.
Концепція «unit load» (шматки по 100 mA у ранніх специфікаціях) сформувала, як пристрої запитують живлення під час enumeration. Деякі пристрої й досі поводяться, ніби це 1999.
USB 3.x додав більше енергетичних станів і складності керування лінком. Більше швидкості — більше крайніх випадків, більше «чому він заснув?».
UASP (USB Attached SCSI Protocol) підвищив продуктивність для сховищ, але виявив баги в прошивках деяких мостів. Bulk‑only був повільніший, але терпиміший.
Type‑C зробив переговори про живлення явними, але також ввів новий клас помилок: некоректні кабелі й «майже сумісні» адаптери, що неправильно звітують можливості.
Функції «Sleep and charge» у BIOS фактично — логіка маршрутизації живлення. На деяких платах вони погано взаємодіють з suspend/wake ОС.
Фронт‑панельні USB‑порти часто мають довші траси й дешевші роз’єми. І цілісність сигналу, й падіння напруги тут гірші.
Захист від перевантаження реальний: деякі хости різко вимикають порт при виявленні піка. Для ОС це виглядає як загадкове відключення.

Що насправді означає «USB-пристрій не розпізнано» на електричному та протокольному рівні

USB‑пристрої не просто «з’являються». Хост подає 5 В на VBUS, визначає підтягування резистора на D+ або D‑ (USB 2.0) або проводить переговори по SuperSpeed‑ланках (USB 3.x), виконує reset пристрою, потім запитує дескриптори: device, configuration, interface, endpoints. Якщо будь‑який із цих кроків таймаутиться, ви отримуєте «unknown device», «device descriptor request failed» або пристрій, що постійно перепідключається.

Проблеми з живленням можуть вражати на різних етапах:

Під час підключення: пусковий струм викликає просадку напруги; пристрій просаджується недостатньо швидко, щоб відповісти на перший запит дескриптора.
Під час reset: хост ініціює reset; прошивка пристрою перезапускається; таймінги зсуваються; enumeration періодично не вдається.
Після конфігурації: пристрій налаштований, але хост агресивно переводить його в suspend; пристрій не пробуджується коректно; ОС вважає його не відповідаючим.
Під навантаженням: місток SSD витягує більше струму або падіння напруги в кабелі збільшується; пристрій перезапускається; можлива корупція файлової системи.

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

Моя упередженість: якщо пристрій «не розпізнається» і ви використовуєте хаб/док, вважайте, що хаб бреше щодо живлення або спрацьовує захист. Багато хабів нормальні — поки ви не додасте один пристрій з великим споживанням, який перетворить вашу конфігурацію на симулятор brownout.

Жарт #2: Специфікація USB — тисячі сторінок; ваш кабель — три долари. Вгадайте, що зіпсує ваш день.

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

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

Завдання 1 (Linux): Слідкуйте за подіями ядра під час підключення пристрою

cr0x@server:~$ sudo dmesg -Tw
[Mon Feb  3 12:18:41 2026] usb 2-1: new SuperSpeed USB device number 7 using xhci_hcd
[Mon Feb  3 12:18:41 2026] usb 2-1: device descriptor read/64, error -71
[Mon Feb  3 12:18:41 2026] usb 2-1: device descriptor read/64, error -71
[Mon Feb  3 12:18:42 2026] usb 2-1: new SuperSpeed USB device number 8 using xhci_hcd
[Mon Feb  3 12:18:42 2026] usb 2-1: device not accepting address 8, error -71
[Mon Feb  3 12:18:42 2026] usb 2-1: USB disconnect, device number 8

Що це означає: Error -71 часто свідчить про протокольну помилку (EPROTO). На практиці: поганий сигнал, нестабільне живлення або хаб/кабель, який робить SuperSpeed нестабільним.

Рішення: Підключіться напряму до хоста (без хаба), поміняйте кабель, спробуйте порт/режим USB 2.0 (іноді стабільніше), а налаштування живлення/autosuspend перевіряйте пізніше.

Завдання 2 (Linux): Показати топологію USB і погоджену швидкість

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 1: Dev 7, If 0, Class=Mass Storage, Driver=uas, 5000M

Що це означає: Пристрій на контролері xHCI на 5 Gbps і використовує UAS. Це добре для продуктивності, але деякі мостики поводяться нестабільно з UAS.

Рішення: Якщо відключення відбуваються під навантаженням, розгляньте примусове використання BOT замість UAS для цього пристрою (цільова «quirk») або протестуйте через USB 2.0, щоб зрозуміти, чи проблема в SuperSpeed SI/живленні.

Завдання 3 (Linux): Перевірити налаштування autosuspend для пристрою

cr0x@server:~$ for f in /sys/bus/usb/devices/2-1/power/*; do echo "$f: $(cat $f)"; done
/sys/bus/usb/devices/2-1/power/autosuspend: 2
/sys/bus/usb/devices/2-1/power/autosuspend_delay_ms: 2000
/sys/bus/usb/devices/2-1/power/control: auto
/sys/bus/usb/devices/2-1/power/runtime_status: active

Що це означає: Пристрій може підлягати runtime autosuspend (control: auto) з затримкою 2 секунди. Для мишей це може бути нормально. Для деяких мостів сховищ, аудіоінтерфейсів і серійних адаптерів — жахливо.

Рішення: Якщо відмова трапляється після простою, встановіть control у on для цього пристрою (цільове виправлення) і повторіть тест.

Завдання 4 (Linux): Тимчасово вимкнути autosuspend для одного пристрою

cr0x@server:~$ echo on | sudo tee /sys/bus/usb/devices/2-1/power/control
on

Що це означає: Runtime PM вимкнено для цього USB‑пристрою до перезавантаження.

Рішення: Якщо стабільність покращилась, зробіть це постійним за допомогою udev‑правила (описано нижче), замість глобального відключення autosuspend.

Завдання 5 (Linux): Знайти помилки USB і перезапуски в логах

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'usb|xhci|reset|over-current|descriptor' | tail -n 20
Feb 03 12:18:41 server kernel: usb 2-1: device descriptor read/64, error -71
Feb 03 12:18:42 server kernel: usb 2-1: device not accepting address 8, error -71
Feb 03 12:18:42 server kernel: usb 2-1: USB disconnect, device number 8
Feb 03 12:22:10 server kernel: usb 2-1: new SuperSpeed USB device number 9 using xhci_hcd
Feb 03 12:22:10 server kernel: usb 2-1: New USB device found, idVendor=174c, idProduct=55aa

Що це означає: Повторні помилки дескриптора з подальшим успіхом сильно вказують на переривчасті умови фізичного шару: кабель/хаб/просадка живлення.

Рішення: Сприймайте це як проблему апаратного шляху перш за все. Якщо це док — поміняйте док. Якщо фронт‑панель — перемістіть на задній IO. Якщо довгий кабель — скоротіть його.

Завдання 6 (Linux): Перевірити погоджений режим живлення для USB‑C / PD (якщо доступно)

cr0x@server:~$ ls /sys/class/typec
port0

cr0x@server:~$ for f in /sys/class/typec/port0/* 2>/dev/null; do [ -f "$f" ] && echo "$f: $(cat "$f")"; done
/sys/class/typec/port0/data_role: host
/sys/class/typec/port0/power_role: source
/sys/class/typec/port0/port_type: dual

Що це означає: Порт виступає джерелом живлення і хостом. На деяких системах також можна прочитати погоджені струм/напругу через інтерфейси USB PD; доступність варіює.

Рішення: Якщо навколо відмов відбувається змінювання ролей Type‑C, підозрюйте сумісність кабелю/адаптера і використайте відомий‑хороший e‑marked кабель для режимів високого струму.

Завдання 7 (Linux): Примусово перевести USB‑накопичувач на BOT замість UAS (цільова «quirk»)

cr0x@server:~$ lsusb
Bus 002 Device 007: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge

cr0x@server:~$ echo 'options usb-storage quirks=174c:55aa:u' | sudo tee /etc/modprobe.d/usb-storage-quirks.conf
options usb-storage quirks=174c:55aa:u

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

Що це означає: Цей USB‑міст уникатиме UAS (:u) і використовуватиме старіший bulk‑only transport. Часто менш продуктивно, але іноді значно стабільніше.

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

Завдання 8 (Linux): Створити постійне udev‑правило для відключення autosuspend для одного пристрою

cr0x@server:~$ sudo tee /etc/udev/rules.d/99-usb-no-autosuspend.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="174c", ATTR{idProduct}=="55aa", TEST=="power/control", ATTR{power/control}="on"
EOF

cr0x@server:~$ sudo udevadm control --reload

cr0x@server:~$ sudo udevadm trigger

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

Рішення: Використовуйте це для відомих проблемних пристроїв. Не відключайте енергоменеджмент на всіх корпоративних ноутбуках, якщо вам не подобаються скарги на батарею й підвищення температури.

Завдання 9 (Windows): Знайти конфігурацію selective suspend через powercfg

cr0x@server:~$ powercfg /q SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND
Power Setting GUID: 2a737441-1930-4402-8d77-b2bebba308a3  (USB selective suspend setting)
  GUID Alias: USBSELECTIVE
  Minimum Possible Setting: 0x00000000
  Maximum Possible Setting: 0x00000001
  Possible Settings increment: 0x00000001
  Possible Settings units: 
Current AC Power Setting Index: 0x00000001
Current DC Power Setting Index: 0x00000001

Що це означає: Selective suspend увімкнено і на AC, і на батареї (DC). Це головний підозрюваний, коли пристрої відмовляють після простою або під час низької активності.

Рішення: Якщо пристрій критично важливий (серійна консоль, лабораторний інструмент, зовнішній диск для бекапів), вимкніть selective suspend принаймні на AC, бажано через політику для уражених систем.

Завдання 10 (Windows): Вимкнути selective suspend (для поточної схеми живлення)

cr0x@server:~$ powercfg /setacvalueindex SCHEME_CURRENT SUB_USB USBSELECTIVE 0

cr0x@server:~$ powercfg /setdcvalueindex SCHEME_CURRENT SUB_USB USBSELECTIVE 0

cr0x@server:~$ powercfg /setactive SCHEME_CURRENT

Що це означає: Selective suspend вимкнено для поточної активної схеми живлення.

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

Завдання 11 (Windows): Перевірити управління живленням на USB Root Hub

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse
Intel(R) USB 3.20 eXtensible Host Controller - 1.20 (Microsoft)

Що це означає: Пристрої, дозволені для пробудження системи. Це прямо не показує «Allow the computer to turn off this device», але вказує, які контролери беруть участь у поведінці пробудження.

Рішення: Якщо система прокидається, але USB‑пристрої мертві після сну, ймовірно — проблема відновлення стану хаба/контролера; вимкніть selective suspend і оновіть драйвери чіпсету/USB та BIOS.

Завдання 12 (Windows): Швидко перерахувати проблемні PnP‑пристрої

cr0x@server:~$ pnputil /enum-devices /problem
Microsoft PnP Utility

Instance ID: USB\VID_0000&PID_0002\5&2B6A2B1A&0&3
Device Description: Unknown USB Device (Device Descriptor Request Failed)
Class Name: USB
Class GUID: {36fc9e60-c465-11cf-8056-444553540000}
Problem Code: 43
Problem Status: 0xC00000E5

Що це означає: Code 43 з device descriptor failed часто стоїть не в драйверах: enumeration не завершилася. Драйвери не можуть прив’язатися до пристрою, який не представив себе коректно.

Рішення: Трактуйте це як апаратний/енергетичний шлях: спробуйте інший порт, видаліть хаб, вимкніть selective suspend і лише потім перевстановіть драйвери контролера.

Завдання 13 (Windows): Перезапустити USB‑контролери без повного перезавантаження (іноді)

cr0x@server:~$ devcon restart "PCI\CC_0C0330*"
PCI\CC_0C0330: Restarted
1 device(s) restarted.

Що це означає: Ви перезапустили пристрої контролера xHCI (показаний клас‑код). Потрібен devcon і відповідні права.

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

Завдання 14 (macOS): Показати дерево USB і підказки щодо струму

cr0x@server:~$ system_profiler SPUSBDataType
USB:

    USB 3.1 Bus:

      Host Controller Driver: AppleUSBXHCITR
      PCI Device ID: 0x15d9

        USB3.0 Hub:

          Product ID: 0x2812
          Vendor ID: 0x2109  (VIA Labs, Inc.)
          Current Available (mA): 900
          Current Required (mA): 896

Що це означає: Хаб майже на межі доступного струму. Число «Required» — те, що пристрої заявляють, а не завжди те, що вони споживають у піках, але це велика підказка.

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

Завдання 15 (Linux): Підтвердити, чи порт звітує про події over-current

cr0x@server:~$ sudo dmesg | egrep -i 'over-current|overcurrent|ocp|port power'
[Mon Feb  3 12:30:14 2026] usb usb2-port1: over-current condition
[Mon Feb  3 12:30:14 2026] usb usb2-port1: disabled by hub (EMI?), re-enabling...

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

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

Завдання 16 (Linux): Навантажити змонтований USB‑диск і слідкувати за скиданнями

cr0x@server:~$ sudo dd if=/dev/zero of=/mnt/usb/testfile.bin bs=64M count=64 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 9 s, 239 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 18 s, 239 MB/s

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

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

Три міні‑історії з корпоративного життя (анонімізовано, боляче правдоподібно)

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

Команда розгорнула невелику партію міні‑ПК як «edge collectors» у філіях. Кожен бокс мав USB LTE модем для резервного підключення та USB SSD для буферизації. В лабораторії все виглядало нормально: підключили, запустили швидке копіювання, відправили у поле.

На місцях пристрої працювали дні, а потім раптово втрачали модем. Іноді SSD перемикався в режим тільки для читання. Віддаленій діагностиці заважало те, що бокси були безголовими; коли модем помирав, бокс зникав із мережі. Єдина підказка з небагатьох логів: USB‑відключення майже щовечора.

Неправильне припущення було просте: «Якщо в лабораторії працює, то й у магазині працюватиме». У лабораторії пристрої стояли на столі з постійним AC‑живленням і без сну. У магазинах дисплеї вимикалися ночами; міні‑ПК переходили в глибші стани простою, і Windows починав гратися з selective suspend як із футбольною м’ячем для модему та зовнішнього диска.

Фікс був прісний і ефективний: вимкнули selective suspend на AC і зафіксували налаштування управління живленням для конкретних USB root hub. Також перемістили SSD у живлений корпус. Постмортем не про пошук винних, а про визнання, що «нічний простій» — це продукційна умова як будь‑яка інша.

Міні‑історія 2: Оптимізація, що обернулась проти

Команда образів робочих станцій хотіла зробити машини енергоефективнішими й подовжити час автономної роботи ноутбуків. Вони оновили плани живлення, ввімкнувши агресивний USB selective suspend і скоротивши таймери простою. На папері й у кількох синтетичних тестах це виглядало чудово.

Потім на інженерному поверсі почали надходити скарги: док‑станції час від часу втрачали Ethernet, аудіоінтерфейси переривались під час дзвінків, зовнішні NVMe корпуси падали під час збірок, залишаючи пошкоджені артефакти. Люди міняли кабелі, купували інші хаби і тихо лаяли ІТ.

Оптимізація обернулася проти, бо всі USB‑пристрої прирівняли до однакових. Миша толерує suspend/resume. Док з хабом, Ethernet‑контролером і аудіокодеком — це розподілена маленька система, якій потрібне стабільне живлення і чиста послідовність відновлення. Так само і UASP‑накопичувач під час тривалого запису.

Відкат був цілеспрямований. Залишили батарейні оптимізації для малоризикових категорій (HID), але відключили selective suspend для док‑станцій і мостів сховищ, визначених за VID/PID. Також вимагали оновлення прошивки для популярної моделі дока. Отриманий виграш по батареї зменшився, але кількість інцидентів впала. Це той компроміс, який приймають завжди.

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

Дослідницька група мала інструментальні ПК, підключені до лабораторного обладнання через USB‑послідовні адаптери. Налаштування працювало 24/7 збираючи дані. Нічого екстраординарного — просто надійність.

Коли вони оновлювали апарат, один інженер порадив консолідувати порти через один багатопортовий хаб під робочими столами. Кабельний менеджмент покращився. Натомість зросла кількість відмов. Пристрої зникали через кілька годин; іноді повертались, іноді потрібно було перезапускати експеримент.

Одна людина тихо дотримувалась «нудної» практики роками: вела інвентар відомих‑хороших адаптерів і живлених хабів, і маркувала пристрої, що потребують «no suspend» налаштувань. Також була стандартна перевірка: тест напряму в порт, тест через живлений хаб, і лише потім застосування udev‑правил (Linux) або змін у плані живлення (Windows), якщо потрібно.

Ця дисципліна їх врятувала. Вони виявили, що новий підстільний хаб живився від marginal USB‑C адаптера; він працював у стані простою, але відбувалися просадки, коли кілька інструментів передавали одночасно. Хаб замінили на живлений промисловий варіант і застосували per‑device no‑autosuspend правило. Експерименти знову стали нудними. У експлуатації нудне — це мета.

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

Цей розділ навмисно конкретний. Якщо ви можете зіставити свій симптом з одним із цих пунктів, перестаньте танцювати навколо Диспетчера пристроїв.

1) «Unknown USB Device (Device Descriptor Request Failed)» у Windows

Симптом: Code 43, descriptor request failed, пристрій ніколи не з’являється коректно.
Корінна причина: Enumeration не вдалася — часто просадка живлення кабелю/хаба/порту, іноді пристрій застряг у поганому стані прошивки.
Виправлення: Приберіть хаб/док, використайте короткий відомо‑хороший кабель, спробуйте інший порт; вимкніть selective suspend; повністю вимкніть пристрій від живлення на 10 секунд. Потім оновіть драйвери чіпсету/USB та BIOS.

2) Пристрій працює від AC, але відмовляє від батареї

Симптом: Стабільно при підключеному живленні; нестабільно в мобільному режимі.
Корінна причина: Агресивна DC‑політика живлення, selective suspend, глибші стани платформи або обмеження ролі USB‑C PD.
Виправлення: Вимкніть selective suspend в DC для цього плану; використайте режим «Best performance» для роботи з інтенсивним використанням USB; використайте живлений хаб/корпус для сховищ.

3) Зовнішній диск відключається під час великого копіювання

Симптом: Починається нормально; падає посеред копіювання; при повторному підключенні файловій системі може бути боляче.
Корінна причина: Бюджет живлення або пускові струми; баги прошивки UAS; термічні проблеми призводять до скидань.
Виправлення: Спробуйте живлений хаб або інший корпус; протестуйте з відключеним UAS (quirk у Linux) або іншим драйвером; скоротіть кабель; уникайте фронт‑панелі.

4) Док втрачає Ethernet/аудіо після сну

Симптом: Після відновлення деякі функції дока пропадають до перепідключення.
Корінна причина: Послідовність відновлення хаба + невідповідність керування живленням; баг прошивки дока; selective suspend відрізає дочірній пристрій.
Виправлення: Оновіть прошивку дока; вимкніть selective suspend; за потреби вимкніть опцію «Allow the computer to turn off this device» для USB‑хабів/контролерів; протестуйте інший порт/шину.

5) Linux: повторні повідомлення «reset SuperSpeed USB device»

Симптом: dmesg показує перезапуски і цикли відключення/підключення.
Корінна причина: Проблеми цілісності сигналу на SuperSpeed‑ланках або нестабільне живлення.
Виправлення: Поміняйте кабель; уникайте довгих пасивних кабелів; обійдіть хаб; спробуйте режим USB 2.0 (якщо прийнятно); використайте живлений хаб для пристроїв з великим споживанням.

6) Фронт‑панельні порти ненадійні, задні порти в порядку

Симптом: Той самий пристрій і кабель працює на задній IO, але падає на фронт‑панелі.
Корінна причина: Падіння напруги та гірша цілісність сигналу через проводку корпуса; ослаблені роз’єми; шумове середовище.
Виправлення: Використовуйте задні порти для сховищ/доків; пересуньте та перезакріпіть фронт‑панельний хедер; якщо потрібно використовувати фронт‑панель, застосуйте живлений хаб, змонтований біля задньої IO.

7) «Accessory needs power» на macOS

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

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

Чекліст A: Фізична перевірка «не витрачайте час»

Підключіть напряму host ↔ device (без хабу, без дока).
Використайте короткий відомо‑хороший кабель (особливо для USB 3.x).
Переключіться на інший порт хоста (задня IO у десктопі).
Якщо це сховище: спробуйте живлений корпус або живлений хаб.
Якщо це Type‑C: спробуйте інший кабель/адаптер; надавайте перевагу e‑marked кабелям для вищого струму.

Чекліст B: Windows поетапно (спочатку налаштування живлення, потім драйвери)

Перевірте стан selective suspend через powercfg /q.
Вимкніть selective suspend на AC (і DC за потреби) для поточної схеми.
Відтворіть: простоїть 5–10 хвилин, потім скористайтеся пристроєм; також тестуйте sleep/wake.
Якщо все ще відмовляє: видаліть/перевстановіть пристрій у Device Manager (особливо «Unknown USB Device»), потім перезавантажте.
Оновіть драйвери чіпсету/контролера USB та BIOS/UEFI; док‑станції часто потребують оновлення прошивки.
Якщо проблема обмежена одним хабом: замініть його на живлений хаб з реальним блоком живлення.

Чекліст C: Linux поетапно (спостерігайте, потім прив’яжіть політику)

Запустіть dmesg -Tw під час підключення.
Побудуйте топологію з lsusb -t.
Перевірте стан autosuspend у /sys/bus/usb/devices/.../power/.
Тимчасово відключіть autosuspend для цього пристрою (control=on), повторіть тест.
Якщо стабільно: додайте udev‑правило для збереження.
Якщо відключається під навантаженням: розгляньте відключення UAS для конкретного VID:PID і повторіть тест.

Чекліст D: Правила для інженера зі зберігання даних (бо дані мають значення)

Якщо USB‑диск відключився під час запису, уявіть можливу корупцію. Запустіть перевірку файлової системи перш ніж довіряти йому знову.
Віддавайте перевагу живленим корпусам для 2.5″ HDD та багатьох NVMe‑містків.
Не використовуйте «таємничі хаби» для бекапів. Ваш бекап‑пристрій не повинен ділити шину з п’ятьма іншими пристроями, що живляться від шини.
Якщо використовуєте USB для критичних потоків даних, тестуйте під тривалим навантаженням і через цикли suspend/resume.

Питання й відповіді

1) Чи «USB selective suspend» справді поганий?

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

2) Чи варто вимикати selective suspend глобально?

Тільки для діагностики або якщо ви прийняли компроміс. Краще відцільно вимикати для конкретних пристроїв або класів пристроїв. Глобальні зміни — це як вирішити одну проблему і створити три нові.

3) Чому перехід з USB 3 порту на USB 2 «вирішує» проблему?

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

4) Мій зовнішній SSD швидкий, але відключається під час великих копіювань. Яке найкраще виправлення?

Почніть з живлення і кабелю: короткий якісний кабель, підключення в прямий порт, потім живлений хаб/корпус. Якщо це Linux і пристрій використовує UAS — спробуйте тимчасово відключити UAS для цього VID:PID. Якщо корпус сильно нагрівається — перевірте теплову поведінку.

5) Чи може USB‑хаб викликати «не розпізнано», навіть якщо він «USB 3.0 сумісний»?

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

6) Чому фронт‑панельні USB‑порти частіше відмовляють?

Довші дроти, більше з’єднань, іноді слабша подача живлення і більша механічна зношеність. Задні порти материнської плати зазвичай мають найчистіший електричний шлях.

7) Після сну мої USB‑пристрої мертві, поки я їх не перепідключу. Це живлення чи драйвери?

Часто — відновлення стану живлення: контролер/хаб відновлюється в дивному стані. Виправлення зазвичай включають вимкнення selective suspend, оновлення BIOS/чіпсету/прошивки дока або перезапуск контролера.

8) У Linux, що означає «device descriptor read/64, error -71»?

Це низькорівнева протокольна помилка під час enumeration. На практиці це вказує на маргінальні фізичні умови (кабель/хаб/живлення) або пристрій, що перезапускається посеред рукостискання.

9) Чи завжди живлений хаб вирішує проблему?

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

10) Яка найнадійніша конфігурація для USB‑зберігання, якщо вам не байдуже?

Короткий відомо‑хороший кабель, прямий задній порт або якісний живлений хаб, стабільна політика живлення (без агресивного suspend) і корпус/міст, відомий своєю поведінкою під тривалим навантаженням.

Висновок: подальші кроки, які дійсно працюють

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

Робіть це натомість:

Ізолюйте шлях: прямий порт, короткий кабель, без хаба. Підтвердіть, чи відмова — «хаб/док» або «пристрій/хост».
Перевірте політику живлення: selective suspend/autosuspend — головний підозрюваний, коли відмови корелюють з простоєм або батареєю.
Виправляйте вузько: per‑device no‑autosuspend, живлений хаб для великого споживання, quirks UAS тільки для потрібних пристроїв.
Доведіть це: тест під навантаженням та через sleep/wake. Якщо ви не тестували сценарій відмови, ви не виправили проблему — вам просто пощастило.

Одна операційна ідея, яку варто пам’ятати (перефразовано): Werner Vogels наголошував, що надійність будують, проектуючи на випадок відмов і відновлюючи швидко, а не припускаючи, що компоненти поводяться ідеально.