68. В погоне за Kernel Panic: Как мы искали аппаратный сбой видеокарты через логи Linux

от

Бытует мнение, что если операционная система Linux внезапно падает в обморок, увлекая за собой в перезагрузку или глухое выключение весь компьютер, то виной тому — «кривые» обновления, сырые дистрибутивы или неправильно настроенные конфиги. Однако на практике Linux и его кольцо логов ядра могут выступить в роли точнейшего диагностического инструмента, способного выявить скрытую физическую деградацию железа, о которой пользователь даже не подозревал.

В этой статье мы пройдем по следам одного детективного расследования: от внезапных падений системы на YouTube до раскопки конкретных функций управления видеопамятью в логах ядра.

Подопытный и загадочное поведение

Нашим рабочим инструментом стал заслуженный ноутбук Toshiba Satellite L750D на платформе AMD (четырехъядерный процессор A6-3400M со встроенной графикой Radeon HD 6000-й серии). В качестве основной операционной системы выступает Astra Linux.

Проблема выглядела следующим образом: Ноутбук прекрасно загружался, шуршал интерфейсом, позволял работать с документами и файлами. Но стоило зайти на YouTube и включить любое видео в качестве 1080p (Full HD), как система мгновенно гасла. Никаких предупреждений, никаких зависаний звука — просто глухой сруб питания или мгновенный перезапуск.

Первая банальная мысль — банальный перегрев процессора от старости. Но чистка и замена пасты — дело долгое, а как инженеры, мы сначала должны собрать доказательную базу.

Детективный этап: вытаскиваем правду из ядра

Когда Linux выключается мгновенно, он не успевает записать финальный аккорд в стандартный системный журнал (в утилите journalctl в такие моменты часто красуется лаконичная фраза «no persistent journal was found»). Однако кольцо сообщений ядра (kernel ring buffer) успевает зафиксировать предсмертный крик драйвера перед тем, как сработает защита.

После очередной аварийной перезагрузки открываем терминал Fly и вызываем хвост лога ядра:

Bash

sudo tail -n 50 /var/log/kern.log

И прямо на экране перед нами разворачивается классическая драма под названием Kernel Panic. Посмотрим на ключевые строки, которые удалось зафиксировать:

Plaintext

Jul  2 07:18:15 astra kernel: [   53.786471] RIP: 0010:ttm_bo_release+0x2fd/0x340 [ttm]
Jul  2 07:18:15 astra kernel: [   53.786554] Call Trace:
Jul  2 07:18:15 astra kernel: [   53.786559]  <TASK>
Jul  2 07:18:15 astra kernel: [   53.786565]  ttm_bo_put+0x34/0x50 [ttm]
Jul  2 07:18:15 astra kernel: [   53.786586]  radeon_bo_unref+0x1e/0x30 [radeon]
Jul  2 07:18:15 astra kernel: [   53.786694]  radeon_gem_object_free+0x37/0x60 [radeon]

Разбор улик «на пальцах»:

  1. Временная метка [ 53.786471] — сбой произошел всего лишь на 53-й секунде после включения ноутбука! Система только загрузила рабочий стол, пользователь открыл тяжелую вкладку — и всё, финал. Это сразу отметает теорию о «медленном» классическом перегреве, когда радиатор прогревается минутами.
  2. RIP: ttm_bo_release — ядро споткнулось на функции освобождения буфера памяти.
  3. radeon_bo_unref и radeon_gem_object_free — а вот и главные виновники. Это подсистемы открытого драйвера radeon, которые отвечают за выделение и очистку памяти (Buffer Objects и Graphics Execution Manager) под нужды видеопотока.

Что произошло физически? Браузер при воспроизведении 1080p задействовал аппаратное ускорение и попытался прогнать через видеочип тяжелый массив данных. Видеокарта выделила под это дело буферы памяти. А вот когда пришла пора эти буферы очистить и перевыделить, контроллер памяти внутри старого чипа Radeon из-за физического износа кремния (или деградации пайки под чипом от времени) выдал некорректный ответ. Драйвер Linux не смог переварить этот аппаратный сбой, ядро запаниковало (Kernel Panic) и в целях безопасности мгновенно затушило систему.

Кросс-платформенный эксперимент

Любой хороший администратор скажет: «А вдруг это баг конкретного ядра в Astra Linux?». Чтобы исключить софтверную ошибку дистрибутива, мы провели чистый эксперимент — запустили на этом же ноутбуке Arch Linux со свежайшим ванильным ядром.

Результат? Абсолютно идентичное поведение. При нагрузке в 1080p — мгновенный вылет с точно такой же трассировкой стека вызовов в сторону подсистемы памяти radeon. Это окончательно подтвердило: мы имеем дело не с программным багом, а с чистым «железным» ограничением деградировавшего кристалла.

Вывод первой части

Логи Linux не соврали. Они помогли нам заглянуть глубоко «под капот» графического стека и выявить аппаратную усталость видеокарты без дорогостоящей диагностики в сервисном центре. Проблема найдена: контроллер памяти Radeon физически не держит высокие частоты и токи, необходимые для обработки Full HD потока.

Но ноутбук списывать рано — он еще послужит. В следующей статье мы займемся его физическим обслуживанием (ведь температуру процессора снижать всё равно нужно) и применим несколько изящных программных «костылей», которые закроют эту уязвимость и позволят комфортно пользоваться машиной в её безопасном максимуме.

Продолжение следует…

Смотрите также: «Диагностика и исправление проблем (логи) сервера«

Оставьте комментарий