local_machine/docs/mac/DISPLAY_FREEZE_RUNBOOK.md

MacBook Pro M1 — зависания после замены матрицы

Контекст: заменена матрица (Built-in Liquid Retina XDR). После ремонта — повторяющиеся полные зависания системы.
Инцидент: 2026-06-16, ~4 зависания за час (21:31–21:43).
Проверено: 2026-06-16, логи /Library/Logs/DiagnosticReports/, log show, last reboot.

См. также: README.md

---

1. Симптом

Что видит пользователь	Что в логах
Экран и ввод «замирают», курсор не двигается	Нет записей в unified log на время freeze (дыра в логах)
Помогает только удержание кнопки питания	btn_rst / finger_reset в forceReset-full-*.diag
Зависания повторяются сразу после перезагрузки (через 2–9 мин)	Аптайм в отчётах: 155 с, 537 с
Не kernel panic с диалогом «перезагрузить»	Нет свежих panic-full-*.panic за 16.06; только forceReset

Это hard lockup (полная неотзывчивость SoC), а не обычный краш приложения.

---

2. Хронология 2026-06-16

Время	Событие	Аптайм до freeze
~19:19	Загрузка (сессия до первого сбоя)	—
21:24–21:26	Telegram: отчёт cpu_resource (~55% CPU за 3 мин)	~2 ч
21:31	forceReset-full-2026-06-16-213115 · btn_rst	~7921 с (~2 ч 12 мин)
21:34	forceReset-full-2026-06-16-213425 · btn_rst	~155 с (~2.5 мин)
21:34–21:37	deleted (CacheDelete): cpu_resource (~52% CPU)	после 2-го reboot
21:43	forceReset-full-2026-06-16-214334 · btn_rst	~537 с (~9 мин)

last reboot:

reboot  Tue Jun 16 21:43
reboot  Tue Jun 16 21:34
reboot  Tue Jun 16 21:31

В логах — пропуск ~18 мин (21:33 → 21:51): пока система зависла, запись остановилась.

---

3. RCA — что зафиксировано в отчётах

3.1 Тип сбоя: принудительный reset

Все три отчёта за 16.06:

panic(cpu N caller ...): btn_rst
Debugger message: panic
Boot faults: btn_rst, finger_reset, force_off   (в ResetCounter)

btn_rst = ядро зафиксировало сброс кнопкой питания, когда система уже не отвечала. Это не программный panic с stack trace приложения.

Файлы:

• /Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-213115.0002.diag
• /Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-213425.0002.diag
• /Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-214334.0002.diag
• /Library/Logs/DiagnosticReports/ResetCounter-2026-06-16-213129.diag (и 213438, 214346)

3.2 Главный подозреваемый: WindowServer (графический стек)

Снимок процессов на момент зависания (поле systemTimeTask):

Freeze	Аптайм	WindowServer CPU time	Паттерн потоков
21:31	~2 ч 12 мин	714 с	потоки ждут semaphore port ... owned by pid самого WindowServer
21:34	~2.5 мин	15 с	то же — deadlock на semaphore
21:43	~9 мин	49 с	то же — deadlock на semaphore

WindowServer — процесс отрисовки всего UI (SkyLight). Потоки, ждущие semaphore у того же PID, — типичный deadlock в графическом конвейере.

Рядом в снимках присутствуют процессы дисплейного стека:

• corebrightnessd — яркость / подсветка
• IOMFB_bics_daemon — framebuffer (IOMFB)
• backboardd — события ввода / дисплей

3.3 Что не найдено в открытых логах

Поиск за 3 ч по DCP, IOMFB, CLCD, backlight, GPU reset, panel, LCD:

• Нет явных ошибок драйвера дисплея или DCP
• Только штатные записи (mobileassetd, backlightservices, уведомления)

Apple часто не пишет аппаратные ошибки шлейфа/матрицы в открытый unified log. Отсутствие строк не опровергает аппаратную причину.

3.4 Дополнительная нагрузка (усиливающие факторы)

Процесс	Когда	Наблюдение
Telegram	21:24–21:26	cpu_resource: ~55% CPU за 162 с
deleted (CacheDelete)	21:34–21:37	cpu_resource: ~52% CPU, 88 с после boot
mds / Spotlight	после каждого reboot	активная индексация (mdworker_shared)
Память	на момент проверки	16 GB почти заняты, ~7.8 GB в compressor, свободно ~140 MB

Высокая нагрузка и давление на память усиливают нестабильность, но паттерн WindowServer-deadlock + быстрые повторы после reboot указывают на проблему графики/дисплея, а не только на фоновые процессы.

3.5 История до 16.06 (система нестабильна несколько дней)

Период	Тип отчётов	Характер
10–11.06	shutdown_stall	зависание при выключении
12–14.06	panic-full + shutdown_stall	Wake transition timed out after 35 seconds · suspected: com.apple.driver.AppleSEPManager
15.06	forceReset (21:42) + shutdown_stall	тот же btn_rst
16.06	3× forceReset за час	WindowServer deadlock

До замены матрицы уже были сбои power management (SEP / wake). После ремонта доминирует другой профиль: GUI freeze через WindowServer, в том числе через несколько минут после загрузки.

---

4. Связь с заменой матрицы

Прямых строк «ошибка шлейфа» в логах нет. Косвенные признаки, согласующиеся с ремонтом дисплея:

1. WindowServer стабильно уходит в deadlock на всех трёх снимках
2. В стеке рядом — corebrightnessd, IOMFB_bics_daemon
3. Зависания сразу после reboot (2.5 и 9 мин) — типично для драйвера/железа дисплея, а не для «прогрева» одного приложения
4. Полный lockup (btn_rst) без kernel panic — возможен при зависании GPU/DCP-конвейера

Вероятные аппаратные причины (для сервиса):

• плохой контакт шлейфа матрицы (eDP/LVDS)
• повреждение или неправильная укладка кабеля дисплея
• несовместимая или дефектная матрица для MacBookPro18,1 (Liquid Retina XDR)
• ошибка сборки: винты, заземление, T-Con / подсветка

---

5. Действия

5.1 Сервис (приоритет)

Вернуть в сервис с этим runbook. Попросить проверить:

1. Посадку шлейфа матрицы и display cable на обоих концах
2. Отсутствие перекоса / залома шлейфа при закрытии крышки
3. Совместимость матрицы с MacBookPro18,1 (Liquid Retina XDR, не «похожая» панель)
4. Корректность сборки подсветки и T-Con

5.2 Диагностика на Mac

Apple Diagnostics (нативная):

1. Выключить Mac
2. Зажать питание → «Параметры» → «Диагностика»

Safe Mode (отсечь сторонние драйверы/агенты):

1. Выключить → зажать питание → «Продолжить с безопасным режимом»
2. Если в Safe Mode стабильно час+ — сильнее аргумент в пользу софта/агентов; если снова freeze — железо/драйвер дисплея

Минимальная нагрузка после reboot:

• не открывать Cursor, Brave, Telegram сразу после загрузки
• проверить, воспроизводится ли freeze на пустом рабочем столе

5.3 Мониторинг

# последние force reset
ls -lt /Library/Logs/DiagnosticReports/forceReset-full-* | head -5

# причина в заголовке отчёта
head -12 /Library/Logs/DiagnosticReports/forceReset-full-*.0002.diag | \
  grep -o 'panic(cpu[^\\]*'

# ошибки WindowServer
log stream --predicate 'process == "WindowServer"' --level error

# перезагрузки
last reboot | head -10

После следующего зависания не перезагружать сразу (если возможно подождать 1–2 мин) — иногда успевает дописаться больше в /Library/Logs/DiagnosticReports/. На практике при hard lockup это редко помогает; основные данные уже в forceReset-full.

---

6. Краткий вывод

Вопрос	Ответ
Это kernel panic?	Нет (16.06). Это hard lockup → сброс кнопкой (btn_rst)
Сколько зафиксировано 16.06?	3 отчёта forceReset; пользователь сообщал о ~4 зависаниях
Что зависало?	WindowServer — deadlock, графический стек
Есть ли ошибки DCP/шлейфа в логах?	Нет в открытом unified log
Главная рекомендация	Перепроверка шлейфа и сборки дисплея в сервисе
Была ли нестабильность раньше?	Да, с 10–11.06 (shutdown_stall, SEP wake timeout)

---

7. Ссылки на файлы отчётов

/Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-213115.0002.diag
/Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-213425.0002.diag
/Library/Logs/DiagnosticReports/forceReset-full-2026-06-16-214334.0002.diag
/Library/Logs/DiagnosticReports/ResetCounter-2026-06-16-213129.diag
/Library/Logs/DiagnosticReports/ResetCounter-2026-06-16-213438.diag
/Library/Logs/DiagnosticReports/ResetCounter-2026-06-16-214346.diag
/Library/Logs/DiagnosticReports/Telegram_2026-06-16-212645_Eternals.cpu_resource.diag
/Library/Logs/DiagnosticReports/deleted_2026-06-16-213726_Eternals.cpu_resource.diag

# более ранние (контекст)
/Library/Logs/DiagnosticReports/panic-full-2026-06-14-115455.0002.panic   # Wake transition / SEP
/Library/Logs/DiagnosticReports/panic-full-2026-06-13-155145.0002.panic
/Library/Logs/DiagnosticReports/forceReset-full-2026-06-15-194242.0002.diag