[2026-09-17] eagle: family/how-to/home-automation.md family/tech/t610-hang-investigation.md

family/how-to/home-automation.md

@@ -341,8 +341,15 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны
 > а поднимается только 1.44 ГБ. **Потеряно ~2.5 ГБ — ГЛАВНАЯ НЕРЕШЁННАЯ ПРОБЛЕМА.**
 > ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята** — масштаб не тот (iGPU берёт
 > фиксированный фреймбуфер в сотни МБ, а не 2.5 ГБ).
+> 🔑 **НО UMA Frame Buffer — реальный документированный механизм потери памяти на t610:**
+> в `Advanced → Device Options → Integrated Graphics` значение `Auto`/`256M` съедает
+> **~0.9 ГБ** (замер: `Auto` → 2.6 ГБ свободно, `128M` → 3.5 ГБ). Ставить **`128M`/`64M`**.
+> Заодно проверить дату/время в BIOS — **сбитая = севшая батарейка CMOS** (а питание Alex
+> рвёт физически при каждом сбросе → BIOS может слетать в дефолт). Разбор:
+> [[family/tech/t610-hang-investigation]] §3.1.3, §3.1.4.
 > Разбор, версии и способ проверки (BIOS F10, планки по одной, контакты, memtest86+ с USB):
 > **[[family/tech/t610-hang-investigation]] §3.1.0, §3.1.1, §3.1.2, §5.1.**
+> 🔧 **Обновление BIOS (`K30 v01.07` → актуальная) без Windows — процедура там же, §8.**
 > ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` + `dmesg | grep e820` при КАЖДОМ разборе инцидента**,
 > не доверять записанному. `dmidecode` на t610 **НЕТ** — заполненность слотов даёт
 > `dmesg | grep "Memory slots"`, объём каждой планки — только BIOS setup.

family/tech/t610-hang-investigation.md

@@ -1,21 +1,23 @@
 ---
 title: "🔴 t610: зависания — диагностика (незакрыто)"
-aliases: [t610 hang, t610 зависание, t610 freeze, RCU stall investigation, MemTotal деградация]
+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-17
+updated: 2026-09-17b
 ---
 
 # 🔴 t610 — зависания: состояние расследования
 
 > **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА.**
-> **Два кандидата:** (A) 🔴 **память** — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ
-> (§3.1.0) · (B) деградация носителя → SQLite disk I/O (§5).
+> **Три кандидата:** (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 главный факт про память → §4 что опровергнуто
-> (**не повторять**) → §5 кандидаты + как проверить → §7 предложение (ждёт апрува).
+> §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).
@@ -215,6 +217,75 @@ ssh root@192.168.2.176 'dmesg | grep -iE "BIOS-provided|e820.*usable"'
 > 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 МБ` ·
@@ -278,6 +349,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 **на слабом хосте**. Это уточнение, **не** причина |
+| ⚠️ «Ядро сообщило 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 ГБ |
 
@@ -328,10 +401,16 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state
 > 🔑 **Точка входа — 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` / `Memory` — **точный объём и объём каждого слота**.
+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. **Планки по одной** — вынуть вторую, стартовать с первой, затем наоборот.
    Смотреть, какой объём поднимает каждая **в одиночку**.
@@ -346,6 +425,8 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state
    не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой.
 7. ⚠️ **Проверить thermal pad** — HP требует его на SO-DIMM в модели t610 (не PLUS).
    Перегрев модуля — возможный спутник деградации.
+8. 🆕 **Обновить BIOS** (`K30 v01.07` → актуальная) — процедура в §8.
+   ⚠️ Память это **скорее всего не вернёт** (§3.1.3), но версия 2012 года сама по себе нездорова.
 
 ### 5.2. Как проверить носитель (первый приоритет)
 
@@ -393,21 +474,121 @@ ssh root@192.168.2.176 'smartctl -t long /dev/sda'   # затем -l selftest
 > Правки `configuration.yaml` — только через патч + показ диффа → апрув → заливка → проверка Alex'ом.
 
 1. 🔴 **SMART + `dmesg` по носителю** — **первый приоритет** (§5.2). Сильнейший кандидат §5.
-2. **Сбор метрик, переживающий перезагрузку** — раз в минуту писать в файл на `/mnt/data`:
+   ⚠️ Требует `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).
-3. **`recorder:` с `exclude`** — исключить `sensor.*_summary`, `at2_*_summary`, `update.*`,
+4. **`recorder:` с `exclude`** — исключить `sensor.*_summary`, `at2_*_summary`, `update.*`,
    `button.*_identify`, `event.*`. Снижает нагрузку на БД. **Не «фикс зависания»** — отдельное улучшение.
-4. **Включить watchdog `local_ustreamer`** — единственный аддон без watchdog (§3.7 родительской доки).
-5. **Обновить `core_ssh`** 10.4.0 → 10.5.0.
+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. Питфоллы сессии (дополнение к родительской доке)
+## 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. Питфоллы сессии (дополнение к родительской доке)
 
 | # | Питфолл | Обход |
 |---|---|---|
@@ -420,3 +601,9 @@ ssh root@192.168.2.176 'smartctl -t long /dev/sda'   # затем -l selftest
 | 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 прямо: «нахуя ты мне сервис мануал цитируешь?!». Цитата уместна как **обоснование шага**, не как ответ. Ответ = факт или найденная проблема |