[2026-09-17] eagle: family/how-to/home-automation.md family/tech/t610-hang-investigation.md
This commit is contained in:
Alexey Martemyanov
@@ -332,37 +332,50 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны
|
||||
|
||||
> ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. **`docker` на хосте НЕТ** — контейнеры поднимает `hassio-supervisor`, всё через `ha` CLI / Supervisor API.
|
||||
|
||||
### 3.9. 💾 Память: 4 ГБ в BIOS → 3.31 ГБ usable (проверено 2026-09-15)
|
||||
### 3.9. 💾 Память: 4 ГБ в BIOS → 3.31 ГБ usable (замер 2026-09-15) — ⚠️ РАСХОДИТСЯ С ЖИВЫМ
|
||||
|
||||
> 🔴🔴 **ОБНОВЛЕНО 2026-09-17 — ЦИФРЫ НЕ СХОДЯТСЯ. Живой хост отдаёт `MemTotal: 1 475 788 kB` = 1.44 ГБ.**
|
||||
> Это **НЕ** 3.31 ГБ из таблицы ниже и **не** объясняется округлением.
|
||||
> Не подтверждено: деградация/отсутствие планки, конфигурация UMA, либо таблица ниже снята с другого состояния.
|
||||
> Проверка не запущена: `dmesg | grep -iE "e820|BIOS-provided"`, `dmidecode -t memory`.
|
||||
> ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` при каждом разборе инцидента**, не доверять записанному.
|
||||
> Детали и развилка — [[family/tech/t610-hang-investigation]] §3.1.
|
||||
> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше памяти физически нет.**
|
||||
> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята фактом** — вырезать нечего.
|
||||
> Разбор, версии и способ проверки (BIOS F10, планки по одной, контакты, memtest86+ с USB):
|
||||
> **[[family/tech/t610-hang-investigation]] §3.1, §3.1.1, §3.1.2, §5.1.**
|
||||
> ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` + `dmesg | grep e820` при КАЖДОМ разборе инцидента**,
|
||||
> не доверять записанному. `dmidecode` на t610 **НЕТ** — число планок только из BIOS setup.
|
||||
|
||||
```
|
||||
MemTotal: 3 470 792 kB = 3.31 ГиБ ← столько видит ядро
|
||||
MemTotal: 3 470 792 kB = 3.31 ГиБ ← столько видит ядро (замер 2026-09-15)
|
||||
MemAvailable: 2 575 164 kB = 2.46 ГиБ ← реально свободно
|
||||
Cached: 2 414 348 kB = 2.30 ГиБ ← файловый кэш (НЕ занятая память!)
|
||||
SwapTotal: 1 145 356 kB = 1.09 ГиБ
|
||||
HA core: ~700 МБ (лимит 3.55 ГБ)
|
||||
```
|
||||
|
||||
**Куда ушли 800 МБ от 4096:** по карте `BIOS-e820` — `ACPI NVS`, `ACPI data`, `reserved`-диапазоны + iGPU/чипсет. Норма для t610, потери памяти нет.
|
||||
**Куда ушли 800 МБ от 4096 (для конфигурации 3.31 ГБ):** по карте `BIOS-e820` — `ACPI NVS`,
|
||||
`ACPI data`, `reserved`-диапазоны + iGPU/чипсет. Норма, потери памяти нет.
|
||||
|
||||
```
|
||||
0x00000000 – 0x9f028fff usable (~2.55 ГБ)
|
||||
0x00000000 – 0x9f028fff usable (~2.55 ГБ) ← состояние 2026-09-15
|
||||
0x100001000 – 0x13efffff usable (~1.0 ГБ)
|
||||
между ними — ACPI NVS / ACPI data / reserved (~30 МБ + MMIO-окна)
|
||||
```
|
||||
|
||||
> 🔴 **ПИТФОЛЛ: НЕ читать `MemFree` как «сколько памяти всего» или «сколько занято».** `MemFree` падает при заполнении файлового кэша (у нас Cached = 2.3 ГБ) и в I/O-шторме (наблюдали `MemFree 16 МБ`). Верные метрики — **`MemTotal`** (сколько всего) и **`MemAvailable`** (сколько реально доступно).
|
||||
> 🔴 **ПИТФОЛЛ: НЕ читать `MemFree` как «сколько памяти всего» или «сколько занято».** `MemFree` падает при заполнении файлового кэша (Cached 2.3 ГБ) и в I/O-шторме (наблюдали `MemFree 16 МБ`). Верные метрики — **`MemTotal`** (сколько всего) и **`MemAvailable`** (сколько реально доступно).
|
||||
> 🔴 **Версия «система видит 1.44 ГБ вместо 4» — ОШИБОЧНА.** Такая цифра получалась из неверного чтения (`MemFree` в шторме / лимит контейнера), а не из реального объёма. Проверять: `head -3 /proc/meminfo`.
|
||||
> 🔴 **НО (2026-09-17): живой `MemTotal` = 1.44 ГБ — это УЖЕ другой разговор, не округление.**
|
||||
> `MemFree` остаётся верной метрикой «занято», но `MemTotal` надо перемерять — см. врезку выше.
|
||||
> 📌 Полный e820-маппинг: `dmesg | grep -iE "e820|BIOS-provided"`.
|
||||
|
||||
### 3.4. 🔴 Носитель sda — HDD, и как НЕ измерить его нагрузку
|
||||
|
||||
> 🎯 **2026-09-17: носитель стал ГЛАВНЫМ КАНДИДАТОМ на причину зависаний.**
|
||||
> Симптом-матч на идентичном стеке (HA OS 18.2 / Core 2026.9.2) с `sqlite3.OperationalError:
|
||||
> disk I/O error` в Recorder — разбор и порядок проверки: **[[family/tech/t610-hang-investigation]] §5**.
|
||||
> Проверка: **`smartctl -a /dev/sda`** (ненулевые `Reallocated_Sector_Ct`,
|
||||
> `Current_Pending_Sector`, `Offline_Uncorrectable`, `UDMA_CRC_Error_Count`) +
|
||||
> `dmesg | grep -iE "ata|I/O error|failed command|medium error|UNC"`.
|
||||
> ⚠️ SMART мерить **на чистом фоне** — питфолл 21 ниже.
|
||||
|
||||
**Железо:** `WDC WD2500BEVT-0` · 250 ГБ · **5400 rpm** · `/sys/block/sda/queue/rotational = 1` · раздел данных `sda8` (243 ГБ, `hassos-data`, монтируется в `/mnt/data`, `/config`, `/share`, `/backup`, `/addons`).
|
||||
|
||||
> 🔴 **ПИТФОЛЛ ИЗМЕРЕНИЯ (моя ошибка 2026-09-15):** прогон `find /mnt/data -size +10M` + `du -sh /mnt/data/*` **сам создаёт I/O-шторм** на 5400-rpm HDD. Последовавший замер дал `io_ms_delta = 10007 ms за 10 с` (диск «занят 100%») — и это было **ложное** доказательство деградации носителя. Через минуту после снятия нагрузки: `io_ms_delta = 2609` (26%), `load 1.72`, `pressure 16%`.
|
||||
@@ -785,6 +798,11 @@ Hz:PWM 0:0 1:0 2:0 3:0 4:48 5:55 6:63 7:70 8:78 9:85 10:92 11:97 12:102 13:107 1
|
||||
| 53 | 🔴🔴 **При разборе ЗАВИСАНИЯ: логи прошлого запуска недоступны** — подтверждено 2026-09-17 на 5 источниках: `ha core logs` (12 строк текущего контейнера), `/config/home-assistant.log.fault` (0 байт), `home-assistant.log` (нет), `journalctl -b -1` (пусто), `ha supervisor logs` (только текущая загрузка) | Диагноз **до** ребута. **Логбук** в `home-assistant_v2.db` **переживает** ребут — реконструировать профиль нагрузки по нему. Подробно: [[family/tech/t610-hang-investigation]] §2 |
|
||||
| 54 | ⚠️ **`http://192.168.2.176:8123` из LAN → `curl` exit 7**, при живом хосте | Единственный путь к API — `https://mallexxx.duckdns.org`. Дубль питфолла 1 |
|
||||
| 55 | ⚠️ **После холодного старта ZHA догружается**: первый снимок дал 75 сущностей, полный — 310; часть висит `unavailable` минуты | Перемерить через 2–3 мин, не делать вывод «устройства отвалились» |
|
||||
| 56 | 🔴 **`dmidecode` на t610 НЕТ** (и `/sys/firmware/dmi/entries/17-*/raw` пуст) — число планок RAM этим путём не получить | Планки — только **BIOS setup (F10)**. Объём — `head -3 /proc/meminfo` + `dmesg \| grep e820`. См. §3.9 |
|
||||
| 57 | 🔴 **`dmesg` на t610 ВРЁТ без `\| tail`** (питфолл 5, подтверждён) | Всегда `dmesg \| grep … \| tail` |
|
||||
| 58 | 🎯 **Симптом-матч с форума ≠ доказанная причина** — тред HA `1025213` (та же версия стека, `sqlite3.OperationalError: disk I/O error`) | Это **сильнейший кандидат**, но закрывать только фактом: `smartctl` + `dmesg`. [[family/tech/t610-hang-investigation]] §5 |
|
||||
| 59 | 🔴 **Порядок разбора инцидента: ФАКТЫ → версия, НЕ версия → проверка** | Сессия 2026-09-17: три «версии» подряд (template-сенсоры → swap/cache → UMA → бэкап) сняты Alex'ом одной репликой каждая. Сначала e820/BIOS/SMART/метрики — потом формулировать |
|
||||
| 60 | 🔴 **«Система дропнула память в процессе работы» — физически невозможно** | Объём виден ядру **один раз** при загрузке через BIOS, не пересчитывается. «Дропнула память» = **зависла**. Режим отказа — **нестабильная планка**: иногда не детектится, иногда ребут, иногда зависон под нагрузкой |
|
||||
|
||||
---
|
||||
|
||||
@@ -858,7 +876,8 @@ ssh root@192.168.2.176 'ha apps logs local_modbus-bridge | grep -E "Raw RTU|→
|
||||
|
||||
## 8. Текущее состояние
|
||||
|
||||
> 🕐 Обновлено **2026-09-17**.
|
||||
> 🕐 Обновлено **2026-09-17**. ⚠️ **Хост t610 зависает — расследование открыто:**
|
||||
> **[[family/tech/t610-hang-investigation]]** (главный кандидат — деградация носителя, проверка не запущена).
|
||||
|
||||
> 🔴 **2026-09-17 ~09:38: t610 перезапущен ВРУЧНУЮ (сброс питанием) после очередного зависания.**
|
||||
> Причина **не установлена**, логи прошлого запуска недоступны. Аптайм до ребута ≈ 26 ч, БД закрыта не чисто.
|
||||
|
||||
Reference in New Issue
Block a user