BIOS-коди звукових сигналів: діагностика апаратних відмов за допомогою звуку (і паніки)

November 8, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

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

Коли машина не проходить POST і екран залишається чорним, ви раптом працюєте на слух. Коробка або точно каже, що не так… або кричить у порожнечу, бо ніхто не підключив динамік.

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

Що таке BIOS beep-коди насправді (і чому вони досі важливі)

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

Важлива операційна деталь: beep-коди видаються під час POST (Power-On Self Test). POST — це не один тест; це послідовність. Прошивка тестує стільки апаратури, скільки потрібно, щоб рухатись далі. Якщо не виходить — вона зупиняється і пищить. Отже шаблони писків часто корелюють зі стадією, на якій процес завантаження застряг: ініціалізація пам’яті, ініціалізація GPU, контролер клавіатури, мікрокод CPU або живлення/напряження.

У виробничій реальності beep-коди — це «сигнал останньої милі». Вони мають найбільше значення коли:

Немає відеовиходу і немає віддаленої консолі.
Журнали BMC неповні або недоступні.
Система «запалена» після оновлення прошивки або заміни апаратури.
Ви в шумному датацентрі з ліхтариком і запитом на зміну, що ось-ось спливе.

Є жорстока правда: сучасні системи все більше покладаються на дисплеї POST-кодів, діагностичні світлодіоди і журнали BMC замість писків. Але писки виживають, бо вони дешеві і майже не потребують інфраструктури. І тому, що всесвіт любить іронію: найстаріший канал діагностики часто переживає найновішу відмову.

Одна цитата варта того, щоб тримати її при собі під час діагностики в умовах невизначеності: Надія — це не стратегія. — генерал Гордон Р. Салліван (часто цитують у колах операцій)

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

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

Перший: підтвердіть, що ви насправді чуєте діагностику

Є на материнській платі динамік? Багато корпусів його не мають. Деякі сервери пропускають писки через маленький вбудований бузер; у багатьох десктопів покладаються на фронтальний динамік, який ніхто не підключив.
Чи чуєте ви підшипники вентиляторів або coil whine? Високі писки — не «beeps», незалежно від того, як поетично це звучить о 2-й ночі.
Повторюваний шаблон? Справжній POST beep-код повторюваний: той самий ритм на кожному холодному завантаженні, поки ви щось не зміните.

Другий: класифікуйте режим відмови за «чого не вистачає»

Писки + немає відео часто вказують на ініціалізацію GPU, ОЗП або на те, що CPU не виконує код правильно.
Немає писків + немає відео часто вказує на живлення, плату, CPU або відсутній динамік. Також може бути «застрягло настільки рано, що не може пищати».
Один короткий писк + завантаження зазвичай означає «POST OK», що є прошивковим «я не виявив явних порушень».

Третій: зробіть мінімальну апаратну ізоляцію, яка змінює результат

Не робіть «шотган» замін компонентів. Ви втратите причинно-наслідковий ланцюг і нічого не дізнаєтесь. Робіть мінімальне завантаження: плата + CPU + одна планка ОЗП + GPU тільки якщо потрібен відеовихід. Видаліть все інше.

Вимкніть живлення. Вийміть мережевий кабель. Злийте залишкову енергію (утримуйте кнопку живлення 10 секунд).
Переустановіть ОЗП. Спробуйте одну планку в роз’ємі, рекомендованому мануалом плати.
Переустановіть GPU (або видаліть його, якщо CPU має iGPU і плата підтримує відеовихід).
Очистіть CMOS, якщо підозрюєте погані налаштування (особливо після змін XMP/EXPO).
Якщо все ще «мертво»: поміняйте БП (або протестуйте рейли), потім замініть ОЗП, потім GPU, потім плату/CPU.

Якщо у вас є BMC (IPMI/Redfish): заберіть System Event Log, перш ніж чіпати щось. Цей журнал — ваш «чорний ящик», і він обожнює зникати після перезавантажень.

«Мова» писків: постачальники, шаблони і чому таблиці брешуть

Люди обожнюють публікувати таблиці beep-кодів ніби всесвіт погодився на стандарт. Ні — не погодився. Beep-коди відрізняються за виробником BIOS (AMI, Award, Phoenix), за OEM-налаштуваннями (Dell/HP/Lenovo люблять додавати свої варіації) і за поколінням. UEFI не стандартизувала звукові ефекти.

Ставте будь-яку таблицю як генератор гіпотез, а не як вирок. Ваше завдання — корелювати шаблон писку з іншими сигналами: світлодіодами, дисплеєм POST-кодів, журналами BMC і фізичною поведінкою (обертання вентиляторів, цикли живлення тощо).

Як правильно записати шаблон

Рахуйте короткі й довгі. «Один довгий, два короткі» — класика. Не зливайте в «три писки».
Зверніть увагу на повтори й паузи. Phoenix-шаблони часто використовують групи типу 1-2-2-3 з паузами між групами.
Запишіть 10-секундний аудіокліп. Так, серйозно. Під стресом люди стають ненадійними метрономами.

Типові (але не універсальні) тлумачення

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

Безперервне пискання: часто ОЗП не зафіксоване, несумісна пам’ять або провал тренування пам’яті.
Повторювані короткі писки: проблема живлення або плата скаржиться на напругу/термальні умови.
1 довгий, 2 короткі: зазвичай помилка відео/GPU або відсутність відеопристрою.
1 довгий, 3 короткі: часто GPU/пам’ять GPU, іноді контролер клавіатури на старих платах.
Немає писків: може бути відсутній динамік, мертвий PSU, мертва плата, мертвий CPU або заблокована прошивка.
Один короткий писк: успішний POST на багатьох системах.

Помилка не в «користуванні таблицями». Помилка — в тому, що ви вірите таблиці більше, ніж своїм доказам. Таблиці — відправна точка; ізоляція — фініш.

Типові корені проблем, зіставлені з симптомами

Проблеми з ОЗП: найпоширеніший винуватець

Проблеми з пам’яттю домінують у випадках beep-кодів, бо ініціалізація пам’яті відбувається рано і нещадна. «Проблема з ОЗП» включає:

Планка не до кінця вставлена (вона защёлкнулась з одного боку; ви обманули себе щодо іншого).
Неправильний слот для конфігурації з однією планкою.
Несумісна швидкість/таймінги, особливо після увімкнення XMP/EXPO.
Невідповідність ECC і non-ECC на деяких платах.
Брудні контакти або окислені слоти на старому обладнанні.

Збої ініціалізації GPU і відео

Дивовижна кількість «GPU beep-кодів» — це проблеми живлення: відсутність PCIe живлення, канцелярський розгалужений конектор, який не може подати стабільний струм, або PSU, що просідає під навантаженням під час ініціалізації.

Ще один класичний випадок: GPU в порядку, але система налаштована використовувати відеошлях, якого не існує (iGPU відключено, дискретної карти немає; або налаштовано на дискретну, а карта видалена).

Помилки живлення і на рівні плати

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

PSU відмовляє під час стартового виштовху струму (inrush).
ATX 24-pin або CPU EPS конектори не повністю зафіксовані.
Короткі замикання: невірно встановлений стояк, защемлений кабель, провідний сміття.
Відмова VRM: плата намагається стартувати, виявляє неправильну напругу і припиняє роботу.

CPU і крайові випадки прошивки

Відмови CPU рідші, ніж інтернет змушує вірити. Але проблеми, пов’язані з CPU (писк/відсутність писку), трапляються при:

Непідтримуваному CPU для поточної версії BIOS (після оновлення CPU).
Регресіях мікрокоду/прошивки.
Пошкодженні пінів сокета (особливо на LGA-платах).
Перетягнутому охолоджувачі, що викликає згин плати (так, таке трапляється).

Периферія та «це не те, що ви думаєте»

Раніше клавіатури мали більше значення (ера контролера 8042). Сьогодні USB-аномалії все ще можуть блокувати POST на деяких платах, а погані PCIe-карти можуть зависнути під час перерахування раніше, ніж це виглядає як помилка ОЗП.

Жарт №1: BIOS не «пищить вам». Він пищить для вас. Як pager SRE, але з меншими можливостями і більше осуду.

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

Beep-коди відбуваються до ОС, тож навіщо команди? Бо ваше завдання не лише виправити миттєву відмову POST. Ваше завдання:

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

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

Завдання 1: Перевірити журнали ядра на виправлені помилки пам’яті (ECC)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "mce|edac|ecc|memory error" | tail -n 20
[    2.184012] EDAC MC0: Giving out device to module i7core_edac controller MC0: DEV 0000:00:00.0 (INTEL 8086:3ec4)
[  214.992801] mce: [Hardware Error]: Machine check events logged
[  214.992806] EDAC sbridge MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)

Значення: Виникли виправлені помилки ECC (CE). Система продовжила працювати, але DIMM підозрілий.

Рішення: Заплануйте заміну DIMM і запустіть тест пам’яті. Якщо помилки повторюються або перетворюються на UE (uncorrectable), виймайте його негайно.

Завдання 2: Підсумувати апаратний інвентар, щоб підтвердити, що ОС бачить

cr0x@server:~$ sudo lshw -short | egrep -i "system|memory|display|processor" 
H/W path       Device      Class          Description
/0                        system         PowerEdge R740
/0/4                      processor      Intel(R) Xeon(R) Silver 4210
/0/17                     memory         32GiB System Memory
/0/100/3                  display        VGA compatible controller

Значення: Після ремонту ОС бачить CPU, пам’ять і відеопристрій.

Рішення: Якщо обсяг пам’яті менший за очікуваний — перевірте розташування модулів і налаштування BIOS; не оголошуйте перемогу зарано.

Завдання 3: Перевірити населення DIMM і швидкість через DMI

cr0x@server:~$ sudo dmidecode -t memory | egrep -i "locator:|size:|type:|speed:|configured memory speed" | head -n 20
	Locator: DIMM_A1
	Size: 16384 MB
	Type: DDR4
	Speed: 2666 MT/s
	Configured Memory Speed: 2133 MT/s
	Locator: DIMM_A2
	Size: No Module Installed

Значення: DIMM присутній, але працює на зниженої швидкості (2133 замість 2666).

Рішення: Перевірте BIOS щодо XMP/JEDEC, підтримку CPU та змішані DIMM. Знижена швидкість — не відмова, але може бути прихованим регресом продуктивності.

Завдання 4: Визначити «GPU присутній, але не ініціалізований» після події писків

cr0x@server:~$ lspci -nn | egrep -i "vga|3d|display"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104GL [Quadro RTX 4000] [10de:1eb1]

Значення: ОС бачить GPU на рівні PCIe.

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

Завдання 5: Підтвердити ширину/швидкість PCIe зв’язку для переустановленого GPU або HBA

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x16
LnkSta: Speed 8GT/s, Width x16

Значення: Пристрій погодив повний x16 на 8GT/s. Добра посадка та доступні лінії.

Рішення: Якщо ширина лінка несподівано x1 або x4 — переустановіть, перемістіть слот або перевірте налаштування біфуркації. Знижена ширина також може вказувати на бруд або дефектний роз’єм.

Завдання 6: Прочитати журнал подій BMC для подій живлення/теплових подій, що корелюють з писками

cr0x@server:~$ sudo ipmitool sel elist | tail -n 8
 1a | 01/21/2026 | 02:04:11 | Power Supply PS1 | Failure detected | Asserted
 1b | 01/21/2026 | 02:04:14 | Power Unit | Power off/down | Asserted
 1c | 01/21/2026 | 02:06:02 | Power Supply PS1 | Presence detected | Deasserted
 1d | 01/21/2026 | 02:06:05 | System Boot Initiated | Initiated by power up | Asserted

Значення: PSU PS1 відмовив, потім сталося відключення живлення. Ваш «пищання ОЗП» могло насправді бути «провалом напруги під час тренування пам’яті».

Рішення: Замініть/перерозподіліть БП і перевірте резервування живлення. Не продовжуйте постійно переустановлювати DIMM, поки БП вмирає.

Завдання 7: Перевірити показники сенсорів (напруги/термальні) через IPMI

cr0x@server:~$ sudo ipmitool sdr type "Temperature" | head
Inlet Temp       | 21 degrees C      | ok
CPU1 Temp        | 38 degrees C      | ok
PCH Temp         | 45 degrees C      | ok

Значення: Температури виглядають нормальними в ідл після відновлення.

Рішення: Якщо температури високі — перевірте посадку кулера і профілі обертання вентиляторів; термальне відключення може виглядати як випадкова поведінка POST.

Завдання 8: Після очищення CMOS перевірити, чи не стрибнув час BIOS (це викликає проблеми TLS і журналювання)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-01-21 02:12:09 UTC
           Universal time: Tue 2026-01-21 02:12:09 UTC
                 RTC time: Tue 2026-01-21 02:12:08
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Час правильний; NTP активне.

Рішення: Якщо RTC неправильний і NTP недоступне — виправте час перед поверненням у сервіс, інакше ви отримаєте збій аутентифікації й заплутані таймлайни інцидентів.

Завдання 9: Перевірити, чи не «зникли» накопичувачі через переустановлення контролера або зміну PCIe

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL | head -n 12
NAME   SIZE TYPE MODEL            SERIAL
sda   3.6T  disk PERC H740P Mini  1234ABCD
sdb   3.6T  disk PERC H740P Mini  1234ABCE
nvme0n1 1.8T disk SAMSUNG MZ1LB1T9  S4GNNF0R123456

Значення: Диски і NVMe відображаються.

Рішення: Якщо диск відсутній після апаратних робіт — зупиніться і перевірте кабелі/бекплейн/посадку HBA. «Воно, мабуть, повернеться» — це те, як масиви помирають повільно.

Завдання 10: Швидка SMART-перевірка SATA/SAS дисків після події живлення

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "SMART overall|Reallocated|Pending|Offline_Uncorrectable" 
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0
Current_Pending_Sector  0
Offline_Uncorrectable   0

Значення: Диск не повідомляє про очевидну відмову носія.

Рішення: Якщо pending/reallocated значення ненульові і зростають після різкого відключення живлення — плануйте заміну; також перевірте якість PSU/UPS.

Завдання 11: Перевірити стан RAID/HBA (бо писки часто слідують за «хтось переустановив не ту карту»)

cr0x@server:~$ sudo storcli /c0 show
Controller = 0
Status = Success
Description = None

Product Name = PERC H740P Mini
FW Package Build = 50.12.0-xxxx
Virtual Drives = 2
VD LIST :
------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC
------------------------------------------------------------
0/0   RAID5 Optl  RW     Yes     RWBD  -   ON
1/1   RAID1 Optl  RW     Yes     RWBD  -   ON

Значення: RAID-томи оптимальні.

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

Завдання 12: Запустити тест пам’яті з Linux-boot media (післяінцидентна валідація)

cr0x@server:~$ sudo memtester 4096 1
memtester version 4.6.0 (64-bit)
testing 4096MB:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok
  8-bit Writes        : ok
  16-bit Writes       : ok
  Done.

Значення: Базовий стрес-прохід не виявив помилок.

Рішення: Якщо memtester падає — інцидент не закритий. Замініть DIMM і/або поверніть налаштування пам’яті BIOS до консервативних значень.

Завдання 13: Перевірити кількість помилок WHEA/MCE (післязавантажувальна стабільність CPU/плати)

cr0x@server:~$ sudo ras-mc-ctl --summary
Summary:
  Memory CE: 1
  Memory UE: 0
  CPU CE: 0
  CPU UE: 0

Значення: Виникли виправлені помилки пам’яті принаймні один раз.

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

Завдання 14: Перевірити, що система не перебуває в циклі перезавантажень (сервісна адекватність)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.8.0-31-generic Tue Jan 21 02:06   still running
shutdown system down  6.8.0-31-generic Tue Jan 21 02:04 - 02:06  (00:01)
reboot   system boot  6.8.0-31-generic Tue Jan 21 02:03 - 02:04  (00:00)

Значення: Було циклічне перезавантаження близько 02:03–02:06.

Рішення: Підтвердіть події PSU/BMC і стабілізуйте живлення/термальні умови перед повторним включенням продуктивного навантаження.

Три корпоративні міні-історії з «польових» писків

Міні-історія №1: Інцидент, спричинений хибним припущенням

Внутрішній сервіс обробки файлів почав флапати після планового вікна обслуговування. Хост не стартував стабільно. Інколи він проходив POST, інколи ні. Коли відмовляв — видавав повторюваний короткий шаблон писків — досить швидкий, щоб усі почули «ОЗП» і закінчили на цьому.

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

Наступна зміна прийшла з нудною звичкою: забрати BMC SEL перед будь-якими апаратними діями. Журнал показав періодичні твердження про відмову PSU, потім вимкнення блоку живлення, а далі спробу завантаження. Шаблон писків не був «погане ОЗП». Це був «просідання напруги під час ініціалізації пам’яті», тож прошивка верещала тим діалектом, який вона знала.

Виправлення було майже образливе: перемістити сервер на перевірений розетковий PDU і замінити один підозрілий PSU. Машина стабілізувалася миттєво. Заміна материнської плати не знадобилась. Постмортем-урок не був «не вірте beep-кодам». Це був «не інтерпретуйте писк у ізоляції, коли у вас є краща телеметрія».

Хибне припущення: «beep-код = відмова компонента». Реальність: beep-код означає «етап POST зазнав невдачі», і проблеми живлення можуть маскуватися під що завгодно.

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

Команда хотіла швидше завантажувати невелику групу аналітичних робочих станцій для нічних пакетних завдань. Хтось знайшов опцію «Fast Boot» і вирішив, що це безкоштовний приріст. Вони також увімкнули агресивні профілі пам’яті (XMP), бо DIMM-ки «заявляли», що можуть, і хто не любить велике число.

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

Ось що сталося: fast boot зменшив ретельність тренування пам’яті і пропускав ініціалізації деяких пристроїв. XMP-профіль був ледь стабільний при робочих температурах, але ненадійний під час холодного старту. Коли кімната охолоджувалась у вихідні, маргінальний таймінг став твердою відмовою. POST не зміг завершити ініціалізацію пам’яті і вдався до писків.

Виправлення не було героїчним. Вимкнули XMP, відключили найагресивніший fast boot і запустили пам’ять на JEDEC-дефолтах. Час завантаження зріс на кілька секунд. Пакетні завдання нічого не втратили значущого. Надійність повернулась — це краще KPI, ніж «час завантаження», якщо ви не продаєте ноутбуки.

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

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

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

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

Це означало, що вони не витратили першу годину на дебати, чи то «три писки» чи «один довгий, два короткі», або на довіру до якоїсь таблиці. Вони вже знали сімейство плат і лінійку прошивки. Вони також мали рукопис: для тієї платформи «один довгий, два короткі» сильно корелює з «немає відеопристрою / помилка ініціалізації GPU». Сервер використовував недорогий GPU для KVM, бо відео BMC того покоління було ненадійним.

Вони поміняли GPU на відому запасну карту, перевірили живлення PCIe, і машина пройшла POST. Потім виконали швидку перевірку сховища і пам’яті перед поверненням до кластера. Загальний простій залишався обмеженим, в основному тому, що команда трактувала писки як сигнал для триажу в межах документації.

Нудна практика була не «мати запаси». Вона була «знати, що у вас є, і верифікувати діагностичні шляхи до того, як вони стануть потрібні».

Поширені помилки: симптом → корінь → виправлення

Цей розділ навмисно конкретний. Загальні поради дешеві; ваш простій — ні.

1) Симптом: безперервне пискання після додавання ОЗП

Корінь: DIMM не зафіксовано; неправильний слот; змішані комплекти; нестабільний XMP; плата не підтримує щільність/ракування.
Виправлення: Завантажте з однією відомою робочою планкою в рекомендованому слоті. Вимкніть XMP/EXPO. Оновіть BIOS, якщо підтримка CPU/ОЗП новіша за прошивку.

2) Симптом: «1 довгий, 2 короткі» і немає зображення після заміни GPU

Корінь: Додаткове живлення PCIe не підключено; GPU не до кінця вставлено; BIOS налаштований тільки на iGPU; несумісне поєднання UEFI/CSM.
Виправлення: Переустановіть GPU; перевірте кабелі живлення PCIe; встановіть «Primary Display» на PCIe/Auto; спробуйте перемикати CSM/UEFI, якщо змінили покоління GPU.

3) Симптом: немає писків, вентилятори обертаються, немає відео

Корінь: Немає динаміка/бузера; мертвий PSU; CPU не підтримується BIOS; коротка плата; EPS-живлення CPU не підключено.
Виправлення: Підтвердьте наявність динаміка. Перевірте 24-pin і EPS конектори. Спробуйте відомий робочий PSU. Якщо нещодавно оновлювали CPU — повертайте CPU або оновіть BIOS за допомогою старішого підтримуваного CPU.

4) Симптом: писки тільки при холодному старті

Корінь: Маргінальні таймінги ОЗП; граничний PSU; термальне розширення покращує контакт після прогріву; fast boot пропускає тренування.
Виправлення: Поверніть пам’ять до JEDEC-дефолтів; вимкніть агресивний fast boot; запустіть тест пам’яті; розгляньте заміну PSU, якщо в BMC SEL видно події живлення.

5) Симптом: випадкові шаблони писків, випадкові перезавантаження

Корінь: Нестабільне живлення, відмова VRM або коротке замикання; іноді додаткова карта зависає при перерахуванні PCIe.
Виправлення: Мінімальна конфігурація завантаження. Видаліть усі PCIe-карти, крім необхідних. Перевірте стояки. Перемістіть на перевірену розетку/PDU. Перевірте BMC SEL на наявність подій живлення.

6) Симптом: писки типу «помилка клавіатури» на сучасних системах

Корінь: USB-пристрій викликає зависання POST; KVM-перемикачі; кейси з legacy USB.
Виправлення: Завантажтеся без USB-пристроїв, окрім клавіатури. Спробуйте просту дротову клавіатуру. Вимикайте legacy USB тільки якщо у вас є інший спосіб потрапити в BIOS.

7) Симптом: beep-коди з’явилися після оновлення прошивки

Корінь: Налаштування скинуто (зміни CSM/UEFI), зміни у тренуванні пам’яті, несумісність мікрокоду/CPU або частковий збій оновлення.
Виправлення: Очистіть CMOS, потім поверніть мінімальні налаштування. Якщо є dual BIOS/відкат — відкотіть. Перевірте контрольну суму BIOS/версію прошивки в налаштуваннях.

Жарт №2: Якщо ви «вирішили» проблему писків, видаливши динамік, ви також вирішили моніторинг — аж до того моменту, як сервер тихо згорить.

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

Чекліст A: Перед тим як щось чіпати (збережіть докази)

Запишіть точний шаблон писків (довгі/короткі, групування, повтори).
Зверніть увагу на поведінку вентиляторів: стабільні, розгортання, циклічні або миттєве відключення.
Якщо присутній — захопіть значення дисплея POST-кодів або діагностичних LED.
Якщо система має BMC — витягніть SEL і показники сенсорів.
Зфотографуйте кабелі і розташування модулів перед тим, як щось переустановлювати.

Чекліст B: Мінімальна апаратна ізоляція (швидкий шлях до кореня проблеми)

Вимкніть живлення, відключіть AC, розрядьте залишкову енергію.
Відключіть усі накопичувачі (так, навіть якщо «знаєте, що це не сховище»).
Видаліть усі PCIe-карти, окрім GPU якщо потрібен відеовихід.
Залиште CPU + охолоджувач встановленими; перевірте EPS-кабель CPU.
Встановіть одну відому робочу планку DIMM у рекомендований слот.
Завантажтеся і слухайте/спостерігайте за змінами.
Додавайте компоненти по одному, поки не повернеться відмова.

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

Перевірте журнали ядра на MCE/EDAC/ECC події.
Підтвердіть обсяг/швидкість пам’яті згідно очікувань.
Перевірте накопичувачі та стан RAID/ZFS.
Запустіть базовий тест пам’яті та коротку перевірку здоров’я сховища.
Підтвердіть синхронізацію часу і відсутність циклу перезавантажень.

Чекліст D: Правила прийняття рішення (коли зупинити відладку і змінити частину)

Змінюйте ОЗП в першу чергу, коли шаблони писків сильно вказують на пам’ять і переустановка не допомагає.
Змінюйте PSU в першу чергу, коли ви бачите події харчування в SEL, симптоми brownout або повторні скидання.
Змінюйте GPU, коли шаблони ініціалізації відео зберігаються після перевірки живлення і посадки слота.
Ескалюйте до плати/CPU лише після мінімального завантаження + відомого робочого PSU + відомої робочої ОЗП, якщо все ще невдача.

Цікаві факти та історичний контекст (писки мають свою міфологію)

IBM PC мав вбудований динамік, який виконував роль грубого звукового пристрою; POST-писки були «безкоштовні», бо обладнання вже було присутнє.
Ранні ПК використовували писки, бо відео не було гарантоване; відеокарта могла бути відсутня, неправильно налаштована або несумісна, тож аудіо було запасним шляхом.
Phoenix популяризував багаточастинні шаблони писків (груповані послідовності типу 1-2-2-3), щоб закодувати більше станів, ніж прості «короткий/довгий» могли.
Beep-коди передували стандартизованим повідомленням на екрані; в еру DOS не можна було розраховувати на UI — тому отримували аудіо-морзянку.
Багато OEM-ів кастомізують значення писків, навіть коли використовують того самого постачальника BIOS, тому «універсальні таблиці писків» часто дрейфують у вигадку.
UEFI не вбило beep-коди; воно просто зробило їх менш центральними, додавши LED, дисплеї POST-кодів і багатшу телеметрію BMC.
Платформи серверів часто віддають перевагу записам SEL перед писками; писк може бути присутній, але журнал — авторитетний наратив.
Деякі сучасні корпуси постачаються без динаміка, щоб заощадити цент і місце, що виглядає як класна оптимізація витрат — поки ви не диагностуєте чорний екран при завантаженні.
Тренування пам’яті ставало складнішим з часом (особливо з DDR4/DDR5), що збільшує шанси, що прошивка «провалиться в фазі ОЗП» і буде пищати про це.

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

1) Чи стандартизовані BIOS beep-коди?

Ні. Вони залежать від виробника і OEM. Використовуйте таблиці як підказки, потім валідуйте ізоляцією, журналами і індикаторами POST.

2) Що робити, якщо я не чую жодних писків?

Або система не може пищати (немає динаміка/бузера або відмовляє занадто рано), або вона ніколи не досягає POST. Спочатку перевірте доставку живлення: PSU, конектори, короткі замикання і журнали BMC, якщо доступні.

3) Чи може поганий PSU спричинити писки, схожі на помилки ОЗП?

Абсолютно. Ініціалізація пам’яті чутлива до стабільності напруги. Просідання рейлу може дати «помилки, схожі на ОЗП», без того, щоб ОЗП було коренем проблеми.

4) Я очистив CMOS і тепер система завантажується — то це «просто налаштування»?

Іноді. Також може означати, що попередні налаштування (XMP/розгін, незвичні опції PCIe) були маргінальними. Розглядайте це як ризик стабільності: валідуйте пам’ять і перевірте журнали на апаратні помилки.

5) Чому писки змінюються, коли я переміщаю планки ОЗП?

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

6) Чи сервери досі використовують beep-коди?

Деякі — так, але багато покладаються більше на журнали BMC, LED і дисплеї POST-кодів. Якщо у вас є IPMI/Redfish — користуйтеся ними; це менш неоднозначно, ніж рахувати писки в шумній кімнаті.

7) Який найшвидший спосіб підтвердити, що «GPU beep-код» — не просто проблема монітора/кабелю?

Використайте інший вихід (DisplayPort vs HDMI), відомий робочий кабель/монітор і підтвердіть, що GPU виявляється на рівні PCIe після завантаження (коли можливо). Також перевірте живлення PCIe.

8) Чи варто оновлювати BIOS/UEFI в рамках виправлення проблем з писками?

Тільки якщо є причина: несумісність CPU, відомі поліпшення сумісності пам’яті або офіційні порадники від постачальника. Не оновлюйте прошивку на нестабільній системі, якщо у вас немає плану відкату.

9) Якщо система завантажується після переустановлення ОЗП, проблема вирішена?

Не обов’язково. Переустановка може тимчасово усунути маргінальний контакт. Запустіть діагностику пам’яті і стежте за ECC/MCE подіями. Якщо це продуктивна машина — заплануйте контрольне обслуговування.

10) Якщо таблиця писків каже «відмова CPU» — чи варто замінювати CPU?

Заміна CPU — рідко перший крок. Перевірте підтримку CPU прошивкою, перевірте конектори живлення, спробуйте відому робочу ОЗП і PSU, огляньте сокет на пошкодження перед тим, як звинувачувати CPU.

Висновок: наступні кроки, які можна зробити сьогодні

BIOS beep-коди не магічні; це грубий індикатор стану, який ви слухаєте. Трактуйте їх як вказівний сигнал, а не як повну діагностику. Ваш найшвидший шлях — дисциплінована ізоляція, підкріплена журналами.

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

Переконайтесь, що у вашого парку справді є динаміки/бузери або альтернативні індикатори POST (LED/POST код/BMC). Виправте відсутні зараз, а не під час інциденту.
Оновіть інвентар активів з інформацією про постачальника BIOS/версію та модель платформи, щоб таблиці писків були менш спекулятивними.
Напишіть runbook для мінімального завантаження і тримайте відомі робочі планки ОЗП/PSU в доступі.
Після будь-якого інциденту з beep-кодами, що дійшов до продакшну, виконайте післязавантажувальну валідацію: журнали, перевірки пам’яті, здоров’я сховища і синхронізацію часу.