obsidian-vault/family/tech/t610-hang-investigation.md

---
title: "🔴 t610: зависания — диагностика (незакрыто)"
aliases: [t610 hang, t610 зависание, t610 freeze, RCU stall investigation, MemTotal деградация, UMA frame buffer, BIOS update t610, CMOS батарейка]
tags: [family, tech, smarthome, t610, incident]
updated: 2026-09-17b
---

# 🔴 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. Ниже — что проверено фактом, что опровергнуто, и что осталось.
> Родительская дока: [[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

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

**Что неизвестно:**
- Когда и почему пропали 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` изменится — это прямое доказательство нестабильности планки/слота.

```bash
# Воспроизведение (только чтение)
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 ГБ).

**Что это меняет:** режим отказа — не «планка отвалилась и исчезла», а
**одна/обе планки не поднимаются полностью либо недетектируются 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 и ОС».

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

1. **Это штатный, документированный ямой-механизм потери памяти на t610** — не экзотика.
2. **Настройка живёт в BIOS.** 🔴 **Питание на t610 Alex отключает физически** (только так
   он его и сбрасывает). **Если села батарейка CMOS (CR2032) — BIOS слетает в дефолт
   при каждом отключении питания.** Это прямо объясняет: «раньше видел 3.31 ГБ, после
   сброса — 1.44 ГБ, и не вернулось». Настройка могла вернуться к другому значению.
3. 🔴 **НО масштаб не сходится:** iGPU-фреймбуфер — это сотни МБ (макс `1G`), а у нас
   потеряно **~2.5 ГБ**. Даже `1G` + нелинейные ~650 МБ не дают 2.5 ГБ.
   **UMA объясняет яму, но НЕ объясняет всю потерю.** Остаётся открытым.
4. **Что это даёт практически:** если в 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 секунд, круглосуточно
```

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

1. `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 мин).
2. В `/config/configuration.yaml:1172–1189` объявлены **template-сенсоры БЕЗ `trigger:`**:
   ```yaml
   - name: kids_summary
     state: "{{ states('sensor.kids_temperature')|round(0)|int }}° {{ states('sensor.kids_co2')|int }}ppm"
   ```
   Без `trigger` такой сенсор пересчитывается **на любой `state_changed` в системе**, не только
   на своих источниках.
3. Замер живьём: `sensor.kids_summary` — **53 изменения за 9 минут** (каждые ~5 с).
4. **`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).

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).
2. **`MemTotal` после холодного сброса** — если меняется между загрузками → планка/слот нестабильны (§3.1.1).
3. **Планки по одной** — вынуть вторую, стартовать с первой, затем наоборот.
   Смотреть, какой объём поднимает каждая **в одиночку**.
4. **Контакты** — вынуть, протереть ластиком (HP: золочение обязательно; окисление — штатный отказ).
5. **memtest86+** (`memtest.org`) — грузится с USB, понимает legacy BIOS **и** UEFI.
   ⚠️ **MemTest86 v11.7 (memtest86.com) — только UEFI**, на t610 **не загрузится**;
   для legacy брать **v4**. Гонять **часами**, потом **каждую планку отдельно**.
   Показывает и объём **как его видит BIOS**, и ошибки по адресам.
6. 🔑 **Физически «дропнуть 3 ГБ в процессе работы» невозможно** — объём виден ядру
   один раз при загрузке через BIOS и не пересчитывается. «Дропнула память» на практике
   означает **зависла**, а не потеряла. Режим отказа — **нестабильная планка**: иногда
   не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой.
7. ⚠️ **Проверить thermal pad** — HP требует его на SO-DIMM в модели t610 (не PLUS).
   Перегрев модуля — возможный спутник деградации.
8. 🆕 **Обновить BIOS** (`K30 v01.07` → актуальная) — процедура в §8.
   ⚠️ Память это **скорее всего не вернёт** (§3.1.3), но версия 2012 года сама по себе нездорова.

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

```bash
# ① 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'ом.

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

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

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

```bash
# 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
```

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

### 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`**:
1. Питание 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 прямо: «нахуя ты мне сервис мануал цитируешь?!». Цитата уместна как **обоснование шага**, не как ответ. Ответ = факт или найденная проблема |