From 35a0a518c04ef76960749039665ed7990ca0718e Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Thu, 17 Sep 2026 09:56:52 +0600 Subject: [PATCH] [2026-09-17] eagle: family/how-to/home-automation.md family/tech/t610-hang-investigation.md --- family/how-to/home-automation.md | 20 +++-- family/tech/t610-hang-investigation.md | 109 +++++++++++++++++++++++-- 2 files changed, 111 insertions(+), 18 deletions(-) diff --git a/family/how-to/home-automation.md b/family/how-to/home-automation.md index 7fb10b82..9b7ba4da 100644 --- a/family/how-to/home-automation.md +++ b/family/how-to/home-automation.md @@ -2,7 +2,7 @@ title: "🏠 Домашняя автоматизация" aliases: [Умный дом, Home automation, HA, Zigbee, Modbus, вентиляция, t610, RCU stall, USB reset] tags: [family, how-to, smarthome] -updated: 2026-09-17 +updated: 2026-09-17b --- # 🏠 Домашняя автоматизация @@ -336,12 +336,16 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны > 🔴🔴 **ОБНОВЛЕНО 2026-09-17 — ЦИФРЫ НЕ СХОДЯТСЯ. Живой хост отдаёт `MemTotal: 1 475 788 kB` = 1.44 ГБ.** > Это **НЕ** 3.31 ГБ из таблицы ниже и **не** объясняется округлением. -> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше памяти физически нет.** -> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята фактом** — вырезать нечего. +> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше этой границы памяти нет.** +> 🔴 **Физически установлено 4 ГБ, оба слота ЗАНЯТЫ** (`DMI: Memory slots populated: 2/2`), +> а поднимается только 1.44 ГБ. **Потеряно ~2.5 ГБ — ГЛАВНАЯ НЕРЕШЁННАЯ ПРОБЛЕМА.** +> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята** — масштаб не тот (iGPU берёт +> фиксированный фреймбуфер в сотни МБ, а не 2.5 ГБ). > Разбор, версии и способ проверки (BIOS F10, планки по одной, контакты, memtest86+ с USB): -> **[[family/tech/t610-hang-investigation]] §3.1, §3.1.1, §3.1.2, §5.1.** +> **[[family/tech/t610-hang-investigation]] §3.1.0, §3.1.1, §3.1.2, §5.1.** > ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` + `dmesg | grep e820` при КАЖДОМ разборе инцидента**, -> не доверять записанному. `dmidecode` на t610 **НЕТ** — число планок только из BIOS setup. +> не доверять записанному. `dmidecode` на t610 **НЕТ** — заполненность слотов даёт +> `dmesg | grep "Memory slots"`, объём каждой планки — только BIOS setup. ``` MemTotal: 3 470 792 kB = 3.31 ГиБ ← столько видит ядро (замер 2026-09-15) @@ -361,9 +365,7 @@ HA core: ~700 МБ (лимит 3.55 ГБ) ``` > 🔴 **ПИТФОЛЛ: НЕ читать `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` надо перемерять — см. врезку выше. +> 🔴🔴 **ОТМЕНЕНО 2026-09-17.** Ранее здесь было записано: «версия „система видит 1.44 ГБ вместо 4“ — ОШИБОЧНА». **Это опровергнуто живым замером:** `MemTotal` = **1.44 ГБ**, при физически установленных 4 ГБ и **двух занятых слотах** (`DMI: Memory slots populated: 2/2`). Разница «3.31 → 1.44» **реальна** и не объясняется округлением. См. врезку выше и [[family/tech/t610-hang-investigation]] §3.1.0. > 📌 Полный e820-маппинг: `dmesg | grep -iE "e820|BIOS-provided"`. ### 3.4. 🔴 Носитель sda — HDD, и как НЕ измерить его нагрузку @@ -787,7 +789,7 @@ 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 | 41 | 🔴 **`sensor.*_summary` показывает мусор вида `1692° 780ppm`, но датчик под ним исправен** | Смотреть **сырые** `sensor._temperature`/`_co2`, не шаблонную сводку. Сводка склеивает атрибуты своим шаблоном — её кривизна не означает поломку датчика. См. §9 | | 42 | ⚠️ **Живой конфиг сниффа — НЕ в `/addons/modbus-bridge/config.yaml`** | `config.yaml` = только опции аддона (device/baud). Регистры и коррекции — в `data/config.template.tmpl` → `run.sh` рендерит из него `/app/config.yml` при старте | | 44 | 🔴 **`MemFree` читают как «сколько памяти всего/занято»** | Верные метрики: **`MemTotal`** (всего) и **`MemAvailable`** (доступно). `MemFree` падает из-за файлового кэша (Cached 2.3 ГБ) и в I/O-шторме. См. §3.9 | -| 45 | 🔴 **«BIOS 4096 МБ → HA видит 1.44 ГБ»** — ложная тревога | Реально usable **3.31 ГБ** (минус ~800 МБ ACPI NVS/data + reserved + iGPU). Проверять `head -3 /proc/meminfo` + `dmesg \| grep e820`. См. §3.9 | +| 45 | 🔴🔴 **«BIOS 4096 МБ → HA видит 1.44 ГБ» — БЫЛА названа «ложной тревогой», ОТМЕНЕНО 2026-09-17** | ⛔ Прежний вывод («реально usable 3.31 ГБ») **опровергнут живым замером**: ядро отдаёт `MemTotal: 1 475 788 kB` = **1.44 ГБ**, e820 обрывается на `0x5e7fffff`. При этом **физически стоит 4 ГБ, оба слота заняты** (`DMI: Memory slots populated: 2/2`). **Потеряно ~2.5 ГБ — не объяснено.** Разбор: [[family/tech/t610-hang-investigation]] §3.1.0 | | 46 | 🔴 **Создал сущность → «в UI её нет»** | Проверять **4** вещи: (1) `/api/states/` отвечает, (2) `area_id` ≠ `null` в реестре, (3) диагностика устройства скрыта, (4) дашборды не ссылаются на мёртвые сущности. Разбор — [[family/tech/kitchen-hood-fan-template]] §6.1 | | 47 | 🔴 **Template-сущность из YAML не получает `area_id`** | У неё нет `device_id` → зону назначать вручную WS `config/entity_registry/update` с `area_id`. Иначе «невидима» на дашбордах зон | | 48 | 🔴 **`hidden_by: user` НЕ убирает сущность из storage-дашбордов и `area_entities()`** | Это два независимых механизма. Ссылки в `/config/.storage/lovelace.*` вписаны руками — править их отдельно (`jq`). Реально «выключить» — только `disabled_by` | diff --git a/family/tech/t610-hang-investigation.md b/family/tech/t610-hang-investigation.md index 6b7c3741..aee020b4 100644 --- a/family/tech/t610-hang-investigation.md +++ b/family/tech/t610-hang-investigation.md @@ -7,12 +7,18 @@ updated: 2026-09-17 # 🔴 t610 — зависания: состояние расследования -> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА. Главный кандидат — деградация носителя (§5).** +> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА.** +> **Два кандидата:** (A) 🔴 **память** — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ +> (§3.1.0) · (B) деградация носителя → SQLite disk I/O (§5). > Сессия 2026-09-17. Ниже — что проверено фактом, что опровергнуто, и что осталось. > Родительская дока: [[family/how-to/home-automation]] · §3.1 (RCU stall, закрыто), §3.5 (ограничения аддона), §3.9 (память). > -> ⚡ **Читать в этом порядке:** §1 факты момента смерти → §2 логи недоступны → §4 что опровергнуто -> (**не повторять**) → §5 главный кандидат + как проверить → §7 предложение (ждёт апрува). +> ⚡ **Читать в этом порядке:** §1.0 формулировка задачи → §1 факты момента смерти → +> §2 логи недоступны → §3.1.0 главный факт про память → §4 что опровергнуто +> (**не повторять**) → §5 кандидаты + как проверить → §7 предложение (ждёт апрува). +> +> 🔴 **Alex прямо указал:** разгадка, скорее всего, **в памяти**, а логи ничего не дадут +> (их и нет — §2). Приоритет проверок: **BIOS/планки (§5.1)** наравне с SMART (§5.2). --- @@ -21,6 +27,44 @@ updated: 2026-09-17 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, метрик +на момент смерти нет. Каждый следующий случай стирает свои доказательства. + +--- + **Факты о моменте смерти (из читаемого после ребута):** | Наблюдение | Значение | Откуда | @@ -88,11 +132,13 @@ BIOS-e820: [mem 0x000000005e7f4000-0x000000005e7fffff] usable ← ПОСЛЕД > **Верхняя граница памяти = `0x5e7fffff` ≈ 1.48 ГБ. Выше — ничего.** > > **Что это доказывает:** если бы стояла планка 2 ГБ и её часть забирал iGPU/UMA, -> e820 уходил бы за `0x80000000` (2 ГБ). Он обрывается ровно на 1.48 ГБ → -> **сейчас видна одна планка ~1.44 ГБ**, и никакой «вырезанной области» нет. +> 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` изменится — это прямое доказательство нестабильности планки/слота. @@ -104,7 +150,42 @@ 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). +> число планок и объём **каждой** этим путём не получить. Смотреть в **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) @@ -197,6 +278,8 @@ kids_summary / dining_summary / dining_air_summary / bedroom_summary | «Логи есть, надо просто посмотреть внимательнее» | Их **нет** физически (§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 **на слабом хосте**. Это уточнение, **не** причина | +| «Планка вынута / одна из планок исчезла» | ⛔ **Снято фактом:** `DMI: Memory slots populated: 2/2` — оба слота заняты (§3.1.0) | +| «Так всегда и было — планки по 1 ГБ + 512 МБ» | ⛔ **Снято:** Alex подтвердил 4 ГБ физически; раньше ядро видело 3.31 ГБ | > 📌 **Урок метода (для будущих сессий):** я трижды подряд выдал «версию», построенную > на одной цифре без проверки смежных фактов (template-сенсоры → swap/cache → UMA → @@ -242,10 +325,16 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state ### 5.1. Как проверить память (BIOS + планки) -1. **BIOS setup: `F10` при старте** → `System Information` / `Memory` — **точный объём и число планок**. - Это ответ на «сколько ставит BIOS». Разводит «планка отваливается» от «дока устарела». +> 🔑 **Точка входа — BIOS setup.** Он единственный покажет **объём КАЖДОГО слота** +> (`dmidecode` на t610 нет, §3.1.1). Разводит: одна планка не поднимается полностью, +> обе частично, или сбой инициализации. + +1. **BIOS setup: `F10` при старте** → `System Information` / `Memory` — **точный объём и объём каждого слота**. + ⚠️ Ключевой вопрос: BIOS видит **4 ГБ** (значит теряется на этапе ядра/ACPI) или + тоже **1.44 ГБ** (значит BIOS сам не поднимает планки). **Ответ разводит два разных диагноза.** 2. **`MemTotal` после холодного сброса** — если меняется между загрузками → планка/слот нестабильны (§3.1.1). 3. **Планки по одной** — вынуть вторую, стартовать с первой, затем наоборот. + Смотреть, какой объём поднимает каждая **в одиночку**. 4. **Контакты** — вынуть, протереть ластиком (HP: золочение обязательно; окисление — штатный отказ). 5. **memtest86+** (`memtest.org`) — грузится с USB, понимает legacy BIOS **и** UEFI. ⚠️ **MemTest86 v11.7 (memtest86.com) — только UEFI**, на t610 **не загрузится**; @@ -255,6 +344,8 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state один раз при загрузке через BIOS и не пересчитывается. «Дропнула память» на практике означает **зависла**, а не потеряла. Режим отказа — **нестабильная планка**: иногда не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой. +7. ⚠️ **Проверить thermal pad** — HP требует его на SO-DIMM в модели t610 (не PLUS). + Перегрев модуля — возможный спутник деградации. ### 5.2. Как проверить носитель (первый приоритет) @@ -325,7 +416,7 @@ ssh root@192.168.2.176 'smartctl -t long /dev/sda' # затем -l selftest | 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` пуст | Число/объём планок — только **BIOS setup** (F10). `MemTotal` + e820 дают объём, но не число планок | +| 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 |