Files

T

Alexey Martemyanov 91a65c7b10 [2026-09-17] eagle: family/how-to/home-automation.md family/tech/t610-bios-and-memtest.md family/tech/t610-hang-investigation.md

2026-09-17 10:17:12 +06:00

50 KiB

Raw Blame History

title, aliases, tags, updated

title

aliases

🔴 t610 — зависания: состояние расследования

Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА. Три кандидата: (A) 🔴 память — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ (§3.1.0) + 🔑 UMA Frame Buffer в BIOS как документированный механизм потери (§3.1.3)

🔑 батарейка CMOS (§3.1.4) · (B) деградация носителя → SQLite disk I/O (§5). Сессия 2026-09-17. Ниже — что проверено фактом, что опровергнуто, и что осталось. 🧰 Процедура (флешка memtest + прошивка BIOS + UMA): family/tech/t610-bios-and-memtest — там пошагово, список скачанного (SHA256 сверены) и что осталось сделать. Родительская дока: family/how-to/home-automation · §3.1 (RCU stall, закрыто), §3.5 (ограничения аддона), §3.9 (память).

⚡ Читать в этом порядке: §1.0 формулировка задачи → §1 факты момента смерти → §2 логи недоступны → §3.1.0 главный факт про память → §3.1.3 UMA Frame Buffer → §3.1.4 батарейка CMOS → §4 что опровергнуто (не повторять) → §5 кандидаты + как проверить → §7 предложение (ждёт апрува) → §8 обновление BIOS.

🔴 Alex прямо указал: разгадка, скорее всего, в памяти, а логи ничего не дадут (их и нет — §2). Приоритет проверок: BIOS/планки (§5.1) наравне с SMART (§5.2).

1. Что произошло

Alex перезапустил t610 вручную (сброс питанием) 2026-09-17 ~09:38 +07. Хост поднялся заново; HA Core стартовал ~09:41–09:43.

1.0. 📋 ФОРМУЛИРОВКА ЗАДАЧИ (согласованная формулировка сессии)

Alex несколько раз требовал переписать формулировку — без ссылок на доки, только описание проблемы и симптомов. Ниже — финальный вариант. Держать его в голове при любой новой сессии по этой теме.

Задача: HP t610 работает как хост Home Assistant OS. Периодически зависает насмерть — хост перестаёт отвечать, помогает только отключение питания.

Оборудование:

HP t610 (тонкий клиент), AMD G-T56N, 2 ядра
Память: 4 ГБ, два слота SO-DIMM, оба заняты
Носитель: HDD WDC WD2500BEVT, 250 ГБ, 5400 rpm
ОС: Home Assistant OS 18.2, HA Core 2026.9.2
USB: Zigbee-стик, два CH340 (шина вентиляции, шина ZONT), веб-камера
Аддонов 7, из них запущены 5

Симптомы:

Хост перестаёт отвечать по сети и в вебе. Помогает только отключение питания.
Перед зависанием журнал обрывается — последняя запись в БД 07:29, активность SQLite 07:31.
База не закрывается чисто — при старте сообщение, что корректное завершение SQLite не подтверждено.
Логов прошлой загрузки не существует — HAOS пишет журнал в RAM, после зависания он теряется целиком.
Память деградировала. Раньше система видела 3.31 ГБ, сейчас 1.44 ГБ. Потеря ~1.9 ГБ. Когда — неизвестно.
При этом ядро сообщает, что заняты оба слота, и физически стоит 4 ГБ — то есть планки на месте, но поднимаются не полностью.
Карта памяти от BIOS обрывается на 1.44 ГБ — выше этой границы памяти нет.
Свободной памяти почти нет: 16–18 МБ при ~1 ГБ в файловом кэше. Swap 1 ГБ не используется.
Зависания повторяются.

Что неизвестно:

Когда и почему пропали 1.9 ГБ — планка деградировала, отходит контакт, несовместима, BIOS не поднимает.
Связана ли потеря памяти с зависаниями, или это два независимых дефекта.
Что именно приводит к зависанию.

Ограничение диагностики: после зависания следов не остаётся — журнал в RAM, метрик на момент смерти нет. Каждый следующий случай стирает свои доказательства.

Факты о моменте смерти (из читаемого после ребута):

Наблюдение	Значение	Откуда
Журнал оборван на	`07:29–07:31` локально, внезапно, без последней строки	mtime `home-assistant_v2.db` = 07:29, `-wal` = 07:31
БД закрыта чисто?	❌ НЕТ — `The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly`	`ha core logs`
Незакрытая сессия	`Ended unfinished session (id=36 from 2026-09-16 05:46:10)`	тam же
Аптайм до ребута	≈ 26 ч (сессия с 2026-09-16 05:46 → смерть 07:31)	тam же

🔴 Ключевой вывод: процесс не завершился сам — БД не закрыта, журнал обрывается на полуслове. Система умерла без возможности корректного shutdown (RCU stall / hard freeze), а не упала по исключению.

2. ⛔ Логи прошлого запуска — ДОСТУПА НЕТ (ограничение подтверждено)

Проверено повторно 2026-09-17, подтверждает family/how-to/home-automation §3.5:

Источник	Результат
`ha core logs`	только 12 строк текущего контейнера (s6-rc boot)
`/config/home-assistant.log.fault`	0 байт
`/config/home-assistant.log`	не существует
`journalctl -b -1`	пусто; `/var/log/journal` не существует
`ha supervisor logs`	только текущая загрузка (100 строк)

📌 Следствие, которое надо принять: после каждого жёсткого зависания следы стираются. Диагноз надо ставить до перезагрузки, либо поднять ретенцию (см. §6). Это не «не нашёл» — это структурное свойство HAOS (журнал в RAM).

Что спасло расследование: журнал событий (логбук) лежит в /config/home-assistant_v2.db и пережил ребут. Именно из него реконструирован профиль нагрузки до смерти.

3. Что проверено ФАКТОМ (данные после ребута)

3.1. Хост видит 1.44 ГБ, не 3.31 ГБ — расхождение с докой

MemTotal:     1475788 kB   ← 1.44 ГБ  ← ЖИВОЙ ФАКТ 2026-09-17
MemFree:        18620 kB   ← 18 МБ
MemAvailable:  758304 kB   ← 740 МБ
Cached:        837992 kB
SwapTotal:    1024 МБ, used 0

🔴 ЭТО ПРОТИВОРЕЧИТ family/how-to/home-automation §3.9, где зафиксировано MemTotal: 3 470 792 kB = 3.31 ГиБ (проверено 2026-09-15).

Расхождение: 3.31 ГБ → 1.44 ГБ. Это НЕ объясняется округлением.

3.1.1. ✅ РАЗРЕШЕНО фактом: e820 обрывается на 1.48 ГБ — памяти физически нет выше

Снято 2026-09-17 с живого хоста:

BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
BIOS-e820: [mem 0x0000000000100000-0x000000005e028fff] usable   ← верх e820
... ACPI NVS / ACPI data / reserved (много мелких окон) ...
BIOS-e820: [mem 0x000000005e7f4000-0x000000005e7fffff] usable   ← ПОСЛЕДНИЙ usable

Верхняя граница памяти = 0x5e7fffff ≈ 1.48 ГБ. Выше — ничего.

Что это доказывает: если бы стояла планка 2 ГБ и её часть забирал iGPU/UMA, e820 уходил бы за 0x80000000 (2 ГБ). Он обрывается ровно на 1.48 ГБ → BIOS отдаёт ядру только 1.48 ГБ, хотя физически стоит 4 ГБ (§3.1.0).

⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» — ОКОНЧАТЕЛЬНО СНЯТА (см. §4). Резерв ACPI NVS/data + reserved ≈ 30–40 МБ — это норма, не потеря. ⚠️ Но и «UMA вырезал 2.5 ГБ» — тоже не проходит: iGPU у G-T56N берёт фиксированный фреймбуфер (сотни МБ), а не 2.5 ГБ. Масштаб не тот.

🔑 Следствие: в BIOS на старте отдаётся 1.44 ГБ. Если после очередного холодного сброса MemTotal изменится — это прямое доказательство нестабильности планки/слота.

# Воспроизведение (только чтение)
ssh root@192.168.2.176 'head -3 /proc/meminfo'
ssh root@192.168.2.176 'dmesg | grep -iE "BIOS-provided|e820.*usable"'

⚠️ dmidecode на t610 НЕТ (и /sys/firmware/dmi/entries/17-*/raw пуст) — число планок и объём каждой этим путём не получить. Смотреть в BIOS setup (см. §5.1).

3.1.0. 🔴 ГЛАВНЫЙ ФАКТ: оба слота ЗАНЯТЫ, а видно 1.44 ГБ — это НЕОБЪЯСНИМО

Снято с живого хоста 2026-09-17 (только чтение):

[    0.000000] DMI: Memory slots populated: 2/2

🔴 Ядро само сообщает: слотов 2, заняты ОБА.

Alex подтвердил: физически установлено 4 ГБ.

Отсюда прямое противоречие, которое и есть суть проблемы:

Вводная Значение

Физически установлено 4 ГБ (2 планки, оба слота заняты)

Видит ядро (MemTotal) 1.44 ГБ

Верх e820 0x5e7fffff ≈ 1.48 ГБ

ПОТЕРЯНО ~2.5 ГБ

Объём памяти не изменился физически — изменилось то, сколько из неё BIOS/ядро поднимают. Раньше система видела 3.31 ГБ, теперь 1.44 ГБ (§3.9 родительской доки).

Это и есть главная нерешённая проблема. Не «сколько планок стоит» (ответ: две, обе на месте), а почему с 4 ГБ поднимается только 1.44.

⛔ Версия «планка вынута» — снята (2/2 из ядра). ⛔ Версия «планки по 1 ГБ + 512 МБ, так и было» — снята (Alex: памяти 4 ГБ).

Вводная	Значение
Физически установлено	4 ГБ (2 планки, оба слота заняты)
Видит ядро (`MemTotal`)	1.44 ГБ
Верх e820	`0x5e7fffff` ≈ 1.48 ГБ
ПОТЕРЯНО	~2.5 ГБ

Что это меняет: режим отказа — не «планка отвалилась и исчезла», а одна/обе планки не поднимаются полностью либо недетектируются BIOS'ом: контакт, несовместимость (x4 SDRAM), деградация модуля, сбой инициализации памяти в BIOS. Проверка — §5.1, BIOS setup обязателен (он покажет объём каждого слота).

3.1.2. 🧩 ЖЕЛЕЗО: HP t610 — 2 слота SO-DIMM, max 4 ГБ (сервис-мануал HP)

Из официального Troubleshooting Guide HP t610 (PDF c03394393, изд. 2, июнь 2012):

Параметр	Значение
Слотов	2 × SO-DIMM, максимум 4 ГБ
Тип	204-pin, DDR3-1600 PC3-12800, 1.5 В, non-ECC, CAS 9
⚠️ Не поддерживается	x4 SDRAM (только x8/x16)
Порядок заполнения	SODIMM1, затем SODIMM2
⚠️ Thermal pad	Обязателен на SO-DIMM в HP t610 (в PLUS-модели — нет)
Доступ	Правая боковая панель
Загрузка с USB	F10 при старте → boot menu

🔴 HP прямо предупреждает: при апгрейде ставить модули с золочёными контактами — иначе коррозия/окисление на стыке разных металлов. Плохой контакт в слоте — штатный режим отказа этого железа, а не экзотика.

⚠️ Питание на модули подаётся ВСЕГДА, пока воткнут шнур. Перед работами — отключить кабель и подождать ~30 с (требование HP).

📌 Два слота = ступенчатое падение объёма. Если один слот/планка отваливается, MemTotal падает ступенькой (2 ГБ → 1 ГБ), и e820 обрезается — ровно то, что видно.

⚠️ НЕ читать MemFree как «сколько всего памяти» (питфоллы 44–45 в родительской доке). Alex видел «1 ГБ» на экране — вероятнее всего это MemFree в состоянии с большим файловым кэшем, но живой MemTotal 1.44 ГБ — это уже другой разговор, не округление.

3.1.3. 🔑 UMA FRAME BUFFER В BIOS — прямой рычаг объёма памяти (найдено 2026-09-17)

Источник: parkytowers.me.uk/thin/hp/t610/firmware.shtml — разбор ровно нашей проблемы на том же железе, раздел «Missing Memory Investigation».

Триггер у того человека: воткнул 4 ГБ, система показала ~2.5 ГБ вместо ожидаемых ~3.5 ГБ.

Его замеры (4 ГБ установлено) — таблица, которую надо знать:

UMA Frame Buffer	Свободно памяти
Auto (256 МБ)	2 607 496 К
256 МБ	2 869 640 К
🔑 128 МБ	3 525 000 К
🔑 64 МБ	3 590 536 К

Его наблюдения (важные, аномальные):

64 → 128 МБ теряется ровно 64 МБ — логично
🔴 128 → 256 МБ теряется ещё ~650 МБ — «absurd», бессмыслица. Масштаб потери нелинейный
Явный 256 МБ вместо Auto дал чуть больше памяти, чем Auto — видимо, код инициализации Auto не выбрасывается полностью
⚠️ Обновление BIOS до 1.20 памяти НЕ вернуло — версия BIOS на эту проблему не влияет
Автор: «у меня нет объяснения, куда уходит память, пишите версии»

Где это в BIOS:

Advanced → Device Options → Integrated Graphics
  Auto  → 256 МБ при 4 ГБ RAM, 128 МБ при 2 ГБ RAM
  Force → появляется параметр UMA Frame buffer size:
          32M / 64M / 128M / 256M / 512M / 1G

HP-мануал: «Если поставить 512 МБ на системе с 2 ГБ RAM, система всегда отдаёт 512 МБ под графику, а остальные 1.5 ГБ — под BIOS и ОС».

Почему это важно для нашей аномалии:

Это штатный, документированный ямой-механизм потери памяти на t610 — не экзотика.
Настройка живёт в BIOS. 🔴 Питание на t610 Alex отключает физически (только так он его и сбрасывает). Если села батарейка CMOS (CR2032) — BIOS слетает в дефолт при каждом отключении питания. Это прямо объясняет: «раньше видел 3.31 ГБ, после сброса — 1.44 ГБ, и не вернулось». Настройка могла вернуться к другому значению.
🔴 НО масштаб не сходится: iGPU-фреймбуфер — это сотни МБ (макс 1G), а у нас потеряно ~2.5 ГБ. Даже 1G + нелинейные ~650 МБ не дают 2.5 ГБ. UMA объясняет яму, но НЕ объясняет всю потерю. Остаётся открытым.
Что это даёт практически: если в BIOS UMA стоит Auto/256M — переставить на 128M или 64M. По чужим замерам это возвращает ~0.9 ГБ (2.6 → 3.5 ГБ). Дёшево, обратимо, проверяемо.

📌 Приоритет проверки BIOS поднят: System Information (сколько видит BIOS)

Advanced → Device Options → Integrated Graphics (значение UMA). Это два экрана, 1 минута, и они либо показывают яму, либо снимают версию.

3.1.4. 🔴 БАТАРЕЙКА CMOS — кандидат на «почему память пропала после сброса»

Логическая связка, которую надо проверить (не факт, а гипотеза):

CR2032 села → при физическом отключении питания BIOS сбрасывается в дефолт
           → настройки памяти/UMA возвращаются к дефолтным
           → MemTotal меняется между загрузками, «раньше 3.31, теперь 1.44»

Проверка: в BIOS setup посмотреть, сохраняется ли время/дата между физическими отключениями питания. Сбитые дата/время = севшая батарейка — факт, не догадка. Доступ к батарейке: левая боковая панель (по сервис-мануалу HP, §3.1.2). Замена — CR2032, копейки.

⚠️ Дата в BIOS у t610 — быстрый и однозначный индикатор. Если после каждого обесточивания дата уезжает на 2012 год — батарейка мертва.

3.2. Память по контейнерам (норма из доки, для сравнения)

Node-RED 197 МБ · HA Core 212 МБ · Supervisor 77 МБ · modbus-bridge 20 МБ · Mosquitto 19 МБ · mbusd 0.8 МБ. Большинство аддонов сейчас stopped (nodered, z2m).

3.3. Состояние HA после подъёма

Метрика	Значение
Сущностей	310
Автоматизаций	23 (22 `on`, 1 `off` намеренно)
Выключена намеренно	`automation.ventilation_automation_on` (`last_triggered` 2026-03-12)
`unavailable` (Zigbee)	13 (блок `kitchen_hood`, `office_table_light_switch`, `bedroom/kitchen` light, `shower_2_presence_sensor`, `dushevaia_floor_temperature`) — ZHA ещё догружается после холодного старта
HA / HAOS	`2026.9.2` / HAOS `18.2`
Аддоны	`core_ssh` 10.4.0 (апдейт до 10.5.0 доступен), `core_mosquitto`, `local_mbusd`, `local_modbus-bridge`, `local_ustreamer` — started; `nodered`, `zigbee2mqtt` — stopped (как и должно)

✅ Холодный старт медленный, но штатный: внешний https://mallexxx.duckdns.org начал отвечать только через ~1 минуту после запуска Core. http://192.168.2.176:8123 из LAN даёт curl exit 7 (недоступен) — не поломка, ходить только через duckdns (питфолл 1).

3.4. Профиль нагрузки перед смертью (из логбука, пережил ребут)

Замер на окне 06:30–07:40 локально: 1763 записи логбука. Доминировали template-сводки:

kids_summary / dining_summary / dining_air_summary / bedroom_summary
→ каждые ~5–10 секунд, круглосуточно

Механизм (установлен):

sensor.kids_co2 / bedroom_co2 / dining_co2 — platform: mqtt, приходят от modbus-bridge (сниффер ZONT-шины, ha.url: http://localhost:8123, poll_interval: 15); значение меняется каждый тик (CO2 живой: 1677 → 1592 ppm за 9 мин).
В /config/configuration.yaml:1172–1189 объявлены template-сенсоры БЕЗ trigger::
```
- name: kids_summary
  state: "{{ states('sensor.kids_temperature')|round(0)|int }}° {{ states('sensor.kids_co2')|int }}ppm"
```
Без trigger такой сенсор пересчитывается на любой state_changed в системе, не только на своих источниках.
Замер живьём: sensor.kids_summary — 53 изменения за 9 минут (каждые ~5 с).
recorder: блока в configuration.yaml НЕТ ВООБЩЕ → запись всего подряд, дефолт 10 дней, без exclude.

⚠️ Статус версии: ОПРОВЕРГНУТА как причина (Alex, 2026-09-17). «Это обычная работа HA пересчитывать датчики» — верно. Пересчёт шаблонов сам по себе не вешает систему. Нагрузка на БД реальна (77 МБ БД + WAL 4.4 МБ + поток записи), но связь с зависанием НЕ доказана. Записано как «контекст нагрузки», а не как причина.

4. ⛔ Что ОПРОВЕРГНУТО (не повторять)

Версия	Почему неверна
«Template-сенсоры без `trigger` вешают HA»	Alex: это штатная работа HA. Пересчёт — норма, не причина
«iGPU/UMA вырезал ~607 МБ из 2 ГБ»	⛔ Снято фактом: e820 обрывается на `0x5e7fffff` (§3.1.1). Выше 1.48 ГБ памяти нет — вырезать нечего
«`MemFree` 1 ГБ = кончилась память»	Питфоллы 44–45: `MemFree` падает из-за файлового кэша. Верные метрики — `MemTotal` + `MemAvailable`
«Логи есть, надо просто посмотреть внимательнее»	Их нет физически (§2). Проверено 5 источников
🔴 «Бэкап-джоб (tar `home-assistant_v2.db`) вешает хост»	Alex: «такая операция по факту ничего не может убить». `tar czf` 77 МБ = секунды чтения + секунды gzip. Докин RCU stall (§3.6 родительской доки) был непрерывным ffmpeg-ретранскодом, а не разовой архивацией. Разница принципиальная
⚠️ Уточнение по бэкапу	`tar` собирается НА t610 (`tar czf -` по ssh, stdout → `> OUT` уже на TrueNAS). Значит нагрузка — чтение + gzip на слабом хосте. Это уточнение, не причина
⚠️ «Ядро сообщило 2 планки — значит BIOS видит обе»	⛔ Поправка: `slots populated: 2/2` = модули физически вставлены, это НЕ «BIOS поднял два модуля с их объёмом». Ранее в этой сессии я выдал первое за второе — не повторять
«BIOS устарел → память не поднимается»	⚠️ Не проверено, но косвенно маловероятно: в разборе parkytowers обновление BIOS до `1.20` памяти не вернуло (§3.1.3). Обновлять стоит, но не как фикс памяти
«Планка вынута / одна из планок исчезла»	⛔ Снято фактом: `DMI: Memory slots populated: 2/2` — оба слота заняты (§3.1.0)
«Так всегда и было — планки по 1 ГБ + 512 МБ»	⛔ Снято: Alex подтвердил 4 ГБ физически; раньше ядро видело 3.31 ГБ

📌 Урок метода (для будущих сессий): я трижды подряд выдал «версию», построенную на одной цифре без проверки смежных фактов (template-сенсоры → swap/cache → UMA → бэкап-джоб). Каждый раз Alex снимал её одной репликой. Порядок обратный: сначала снять все факты (e820, BIOS, SMART, ретенция метрик), потом формулировать.

5. 🎯 ГЛАВНЫЙ КАНДИДАТ: деградация носителя → SQLite disk I/O error

Найден симптом-матч (форум HA, тред 1025213, 15 сентября 2026) — та же версия стека: HA OS 18.2 · Core 2026.9.2 · Supervisor 2026.09.

Симптомы у пострадавшего (RPi 5):

Фронтенд недоступен часами (и локально, и из интернета), при этом IP пингуется
Несколько перезагрузок не помогали
После ребута всё поднималось, через несколько часов — снова умирало
Устройства становились unavailable

Ключевые строки лога:

ERROR (Recorder) [recorder.core] Error in database connectivity during commit:
  Error executing query: (sqlite3.OperationalError) disk I/O error
SQLAlchemyError error processing task CommitTask()
sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state

🔴 sqlite3.OperationalError: disk I/O error = проблема НОСИТЕЛЯ, а не софта.

Как это бьётся с фактами t610:

Факт t610	Объяснение через носитель
Обрыв записи БД на `07:29`, shm/wal `07:31`	SQLite упёрся в I/O и перестал писать
`could not validate that the sqlite3 database was shutdown cleanly`	БД не закрыта — процесс умер в середине транзакции
`Ended unfinished session (id=36)`	Сессия оборвалась на середине
Хост не отвечает, сброс только питанием	Классика деградации носителя, не OOM и не RCU
Ошибок в логе нет	Журнал HAOS в RAM — для disk I/O error нужно, чтобы он дожил

⚠️ Симптом-матч ≠ доказанная причина. Это сильнейший из имеющихся кандидатов, потому что объясняет весь набор фактов сразу (§1) и подтверждён на идентичном стеке. Проверяется фактом — SMART + dmesg (§5.2), не рассуждением.

5.1. Как проверить память (BIOS + планки)

🔑 Точка входа — BIOS setup. Он единственный покажет объём КАЖДОГО слота (dmidecode на t610 нет, §3.1.1). Разводит: одна планка не поднимается полностью, обе частично, или сбой инициализации. 🆕 Два экрана, 1 минута, снимают сразу две версии: System Information + Advanced → Device Options → Integrated Graphics (§3.1.3). Начинать отсюда. ⚠️ Вход в BIOS — через трюк Ctrl+Alt+Del на syslinux-меню, иначе не попасть (§8.1).

BIOS setup: F10 при старте → System Information — точный объём. ⚠️ Ключевой вопрос: BIOS видит 4 ГБ (значит теряется на этапе ядра/ACPI) или тоже 1.44 ГБ (значит BIOS сам не поднимает планки). Ответ разводит два разных диагноза. 1a. 🆕 Advanced → Device Options → Integrated Graphics — значение UMA Frame Buffer. Если Auto/256M → переставить на 128M/64M; по чужим замерам возвращает ~0.9 ГБ (§3.1.3). 1b. 🆕 Дата/время в Setup — если уезжает после обесточивания → села батарейка CMOS (§3.1.4).
MemTotal после холодного сброса — если меняется между загрузками → планка/слот нестабильны (§3.1.1).
Планки по одной — вынуть вторую, стартовать с первой, затем наоборот. Смотреть, какой объём поднимает каждая в одиночку.
Контакты — вынуть, протереть ластиком (HP: золочение обязательно; окисление — штатный отказ).
memtest86+ (memtest.org) — грузится с USB, понимает legacy BIOS и UEFI. ⚠️ MemTest86 v11.7 (memtest86.com) — только UEFI, на t610 не загрузится; для legacy брать v4. Гонять часами, потом каждую планку отдельно. Показывает и объём как его видит BIOS, и ошибки по адресам.
🔑 Физически «дропнуть 3 ГБ в процессе работы» невозможно — объём виден ядру один раз при загрузке через BIOS и не пересчитывается. «Дропнула память» на практике означает зависла, а не потеряла. Режим отказа — нестабильная планка: иногда не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой.
⚠️ Проверить thermal pad — HP требует его на SO-DIMM в модели t610 (не PLUS). Перегрев модуля — возможный спутник деградации.
🆕 Обновить BIOS (K30 v01.07 → актуальная) — процедура в §8. ⚠️ Память это скорее всего не вернёт (§3.1.3), но версия 2012 года сама по себе нездорова.

5.2. Как проверить носитель (первый приоритет)

# ① SMART — ГЛАВНЫЙ тест. Ищем НЕНУЛЕВЫЕ:
#    Reallocated_Sector_Ct, Current_Pending_Sector,
#    Offline_Uncorrectable, UDMA_CRC_Error_Count
ssh root@192.168.2.176 'smartctl -a /dev/sda'

# ② Ошибки I/O в dmesg: ata, I/O error, failed command, medium error, UNC
ssh root@192.168.2.176 'dmesg | grep -iE "ata|I/O error|failed command|medium error|UNC|sense key"'

# ③ Долгий тест (часы)
ssh root@192.168.2.176 'smartctl -t long /dev/sda'   # затем -l selftest
#   либо  badblocks -nsv /dev/sda8

🔴 ПИТФОЛЛ 21 родительской доки (§3.4): свой find/du по /mnt/data сам создаёт I/O-шторм и даёт ложный вывод «диск деградировал». SMART мерить на ЧИСТОМ фоне — до любых сканирований, либо через ≥60 с.

⚠️ smartctl в аддоне core_ssh может отсутствовать, а docker там нет (§3.5 родительской доки). Если не выйдет из аддона — снимать с другого хоста.

6. ❓ ОТКРЫТЫЕ ВОПРОСЫ

Развилка по времени до зависания (ответ не получен):

Если…	То диагноз	Куда копать
Вешается через примерно одинаковый аптайм	Софт накапливает: утечка, рост БД, исчерпание ресурса	`recorder` + `exclude`, профилирование памяти по контейнерам во времени
Вешается хаотично	Железо: питание, температура, HDD 5400 rpm, деградация планки RAM	SMART, `k10temp`, `pressure/io`, `dmesg \| grep -i usb`, BIOS

Также не выяснено:

Это какой по счёту раз? Есть ли даты/периодичность предыдущих зависаний?
В момент зависания хост отвечал вообще (веб открывался, но тупил) или пропал полностью?

7. 📋 Предложение (НЕ одобрено, НЕ внедрено)

⛔ Ничего из этого не применено. План-first: ждёт апрува Alex. Правки configuration.yaml — только через патч + показ диффа → апрув → заливка → проверка Alex'ом.

🔴 SMART + dmesg по носителю — первый приоритет (§5.2). Сильнейший кандидат §5. ⚠️ Требует smartctl, которого на t610 нет (§9, питфолл 64) — решить, откуда снимать.
🔴 🆕 BIOS setup — 1 минута, 3 экрана (§5.1, вход §8.1): System Information (сколько памяти видит BIOS), Integrated Graphics (UMA Frame Buffer), дата/время (батарейка CMOS). Дёшево и сразу снимает/подтверждает два кандидата.
Сбор метрик, переживающий перезагрузку — раз в минуту писать в файл на /mnt/data: MemTotal/MemAvailable/MemFree, load, pressure/io+pressure/memory, k10temp, размер БД+WAL, аптайм. Это то, что даст версию к следующему зависанию — сейчас каждый инцидент стирает свои следы (§2).
recorder: с exclude — исключить sensor.*_summary, at2_*_summary, update.*, button.*_identify, event.*. Снижает нагрузку на БД. Не «фикс зависания» — отдельное улучшение.
Включить watchdog local_ustreamer — единственный аддон без watchdog (§3.7 родительской доки).
Обновить core_ssh 10.4.0 → 10.5.0.
🆕 Обновить BIOS K30 v01.07 → актуальная — процедура §8. Не как фикс памяти, а как гигиена (версия от 2012-07-27).

📌 Версия «что именно вешает» появится только после п.1+п.2. Без ретенции расследование упирается в §2 и превращается в перебор гипотез — что и произошло в сессии 2026-09-17.

8. 🔧 ОБНОВЛЕНИЕ BIOS НА t610 (без Windows) — процедура

Найдено 2026-09-17. Текущая версия у Alex: K30 v01.07 (дата 07/27/2012), плата 17E2. Проверено на живом хосте: dmesg | grep -i DMI → BIOS K30 v01.07 07/27/2012.

⚠️ Ожидание по памяти: BIOS скорее всего НЕ поможет. В разборе parkytowers обновление до 1.20 памяти не вернуло (§3.1.3). Поднимать версию всё равно стоит — 07 vs 16/20 это годы патчей, — но не как средство вернуть 2.5 ГБ.

8.1. Вход в BIOS — трюк, без которого не попасть

🔴 При старте t610 часто грузится сразу в syslinux и не даёт прервать загрузку. Рабочий приём: на этом меню сделать Ctrl+Alt+Del (перезагрузка) → дальше F10 попадёт в Setup (сообщают 100 % успех).

Клавиши:

F10 → Computer Setup (SETUP screen)
ESC → STARTUP screen
F9 → Boot Menu
F2 → Diagnostics

8.2. Подготовка флешки (с Mac)

Требования (иначе BIOS не увидит):

MBR (DOS) partition table
Раздел FAT32, метка ровно HP_TOOLS
100 МБ достаточно; ⚠️ флешки >32 ГБ обычно exFAT — НЕ работает

diskutil list                                  # найти диск флешки, напр. /dev/disk4
diskutil eraseDisk MS-DOS "HP_TOOLS" MBR /dev/disk4

8.3. Распаковка softpaq и заливка

# 1) скачать softpaq для t610: support.hp.com/us-en/drivers/hp-t610-flexible-thin-client/5226816
#    файл вида spXXXXXX.exe
# 2) распаковать (нужен 7z / p7zip)
7z x spXXXXXX.exe
# 3) скопировать содержимое каталога ToolLess/ в КОРЕНЬ флешки
#    → в корне должен появиться каталог HP/

Структура на флешке (пример для родственных моделей, у t610 аналогично):

./HP/BIOSUpdate/CryptRSA.efi
./HP/BIOSUpdate/HpBiosUpdate.efi
./HP/BIOSUpdate/HpBiosUpdate.sig
./HP/BIOS/Current/<VER>.bin
./HP/BIOS/New/<VER>.bin

Заливка:

Воткнуть флешку в t610
F10 → Setup
File → Flash System BIOS → Update System BIOS from USB
Пойдёт отсчёт 15 секунд на отмену. Дальше — не трогать, ждать
Перезагрузится сам

8.4. После обновления — два обязательных шага

🔴 Может включиться Secure Boot. Отключать:

Security → Secure Boot Configuration → F10 (Accept)
→ Secure Boot: Disabled → F10 (Save)

⚠️ При первом бусте после смены Secure Boot попросит ввести случайное 4-значное число (защита от тихой отмены) — это норма.

🔑 Заодно — то, что реально влияет на память: Advanced → Device Options → Integrated Graphics → UMA Frame buffer size → поставить 128M или 64M (§3.1.3).

8.5. Полезные экраны BIOS для нашей задачи

Экран	Что даёт
`System Information`	Сколько памяти видит BIOS + версия BIOS
`Advanced → Device Options → Integrated Graphics`	Значение UMA Frame Buffer
`Storage → Device Configuration`	Все видимые устройства (быстрая проверка детекта)
`Storage → Boot Order`	Порядок загрузки (EFI/Legacy)
Дата/время в Setup	🔑 Севшая батарейка CMOS — если уезжает после обесточивания (§3.1.4)

8.6. Сброс пароля BIOS (если понадобится)

Три перемычки на мат. плате у радиатора, центральная помечена PSWD:

Питание off → снять джампер PSWD → кратко включить → off → вернуть джампер.

📌 Источники: parkytowers.me.uk/thin/hp/t610/firmware.shtml, watchmysys.com/blog/2026/04/hp-thin-client-bios-update-without-windows/, STH forum «Sucker-Free way to update the BIOS in your HP thin clients».

9. Питфоллы сессии (дополнение к родительской доке)

#	Питфолл	Обход
53	🔴 Журнал прошлого запуска недоступен ПОСЛЕ жёсткого зависания — подтверждено повторно, 5 источников пусты	Ставить диагноз ДО ребута, либо ретенция (§7.2). Логбук в `home-assistant_v2.db` переживает ребут — использовать его
54	⚠️ `ha core logs` показывает только текущий контейнер (12 строк s6-rc), не историю	Не искать «старые строки» — их нет
55	⚠️ `MemTotal` может расходиться с докой — живой факт `1.44 ГБ` против зафиксированных `3.31 ГБ` (§3.9 родительской доки)	Всегда перемерять `head -3 /proc/meminfo` + e820 при разборе инцидента, не полагаться на записанное
56	🔴 `http://192.168.2.176:8123` из LAN → `curl` exit 7, хоть хост жив	Единственный путь к API — `https://mallexxx.duckdns.org`. Совпадает с питфоллом 1
57	⚠️ После холодного старта ZHA догружается: часть сущностей минуты висит `unavailable`	Не спешить с выводом «устройства отвалились» — перемерить через 2–3 мин. Первый снимок дал 75 сущностей, полный — 310
58	🔴 `dmidecode` на t610 НЕТ, `/sys/firmware/dmi/entries/17-*/raw` пуст	Число планок — `dmesg \| grep "Memory slots"` → `DMI: Memory slots populated: 2/2` (⚠️ даёт только заполненность, не объём). Объём каждой планки — только BIOS setup (F10). `MemTotal` + e820 дают суммарный объём
59	🔴 `dmesg` на t610 требует `\| tail` — без хвоста врёт (питфолл 5 родительской доки, подтверждён)	Всегда `dmesg \| grep … \| tail`
60	🔴 Порядок расследования: ФАКТЫ → версия, а не версия → проверка	Три подряд опровергнутые «версии» (§4) съели сессию. Сначала e820/BIOS/SMART/метрики, потом формулировка
61	⚠️ Симптом-матч с форума ≠ доказательство	Тред `1025213` совпал по версии стека и симптомам, но это кандидат, не причина. Закрывать только фактом по §5.2
62	🔴 `/dev/mem` в аддоне → `Operation not permitted`	SMBIOS/DMI-таблицу из `core_ssh` прочитать нельзя (как и `dd` блочных устройств, питфолл 22 родительской доки). Проверено: `dd if=/dev/mem skip=0x5e3a7a18` → отказ
63	🔴 `/sys/firmware/dmi/` в аддоне НЕ существует, `/proc/iomem` отдаёт нули (скрыт)	Единственные рабочие источники памяти из аддона: `/proc/meminfo` (`MemTotal`), `dmesg` (e820 + `Memory slots populated`). Объём каждого слота — только BIOS setup
64	⚠️ `smartctl`/`dmidecode`/`lshw`/`lsmem` на t610 ОТСУТСТВУЮТ (проверено `command -v`)	Есть: `hexdump`, `od`, `xxd`. SMART — только если `smartctl` окажется в каком-то аддоне, иначе с другого хоста
65	🔴 `slots populated: N/N` ≠ «BIOS поднял N модулей»	Это «модули физически вставлены». Объём — отдельный вопрос. Не выдавать одно за другое (моя ошибка этой сессии, Alex поймал: «то есть ты напиздел»)
66	🔴 Порядок: не строить версию на одной цифре	В этой сессии снято/опровергнуто пять версий подряд (template-сенсоры → swap/cache → UMA-607МБ → бэкап-джоб → «BIOS видит 2 планки»). Каждая — одна цифра без смежных фактов. Сначала снять факты, потом формулировать (совпадает с питфоллом 60)
67	🔴 Не цитировать сервис-мануал/доки, когда просят ФАКТ или ПРОБЛЕМУ	Alex прямо: «нахуя ты мне сервис мануал цитируешь?!». Цитата уместна как обоснование шага, не как ответ. Ответ = факт или найденная проблема
68	🔴 `support.hp.com` блокирует скриптовые запросы — `Access Denied` (Akamai EdgeSuite) на `/wcc-services/rest/search/drivers`, пустой ответ на прямые `curl`	Softpaq/драйверы качать браузером вручную. Поиск «номера softpaq» через web_search по t610 пустой
69	⚠️ `ftp.hp.com/pub/softpaq/<range>/<name>.exe` отдаёт `200 OK` на «угаданные» имена (`sp70221.exe` → 6.1 МБ, `sp60365.exe` → 23 МБ)	🔴 Это НЕ доказательство, что файл — BIOS для t610. Так можно скачать чужой softpaq. Без точного номера из страницы HP — не качать
70	🔴 Проверка «подключена ли флешка» — только `diskutil list external physical`	На этом Mac `diskutil list` забит `disk image`/`synthesized` (симуляторы iOS, 20+ записей). Флешку искать по `physical` + `external`; пусто = не вставлена. Не писать `dd` вслепую
71	⚠️ Два разных проекта memtest — не путать	`memtest.org` = memtest86+ (open-source, legacy BIOS OK) ✅. `memtest86.com` = MemTest86 (v11.7 только UEFI, на t610 не загрузится; legacy — лишь старая v4). Для t610 — memtest86+ i586
72	🔴 Порядок действий: сначала 3 экрана BIOS, потом разбирать корпус	BIOS-проверка (память / UMA / дата) — 1 минута и ничего не разбирая. Разбирать t610 под memtest до неё — потеря времени. См. family/tech/t610-bios-and-memtest §6

50 KiB Raw Blame History Unescape Escape