Аморальный патч для Intel DRM

На свете есть не так много вещей, способных выбесить программиста. И лишь одна делает это с гарантией: оборзевшая в край машина, возомнившая себя умнее человека. А значит снова пришло время карать и патчить! Direct Rendering Manager (DRM) Развитие современных видеокарт пошло по весьма.. сюрреалистичному пути: производители страстно желают, чтобы выпускаемые устройства имели максимальную совместимость с модными открытыми ОС, но одновременно были закрытыми и неповторимыми, защищенными разнообразными патентами. То что звучит как чистая шизофрения для человека с техническим образованием, будучи спущенным сверху в виде директивы, еще и подкрепленной серьезным бюджетом, породило на свет такую «хтонь» как binary blob. Это когда основная часть управляющей устройством логики реализуется в виде специальной прошивки с защитой и обфрускацией — того самого «блоба». Затем вокруг создается открытая часть ПО, которая линкуется с открытым ядром и/или окружением. А все это вместе без смущения объявляется как частично беременна открытое решение. Еще в современном Linux есть такая штука как Direct Rendering Manager: The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards Если кратко и цензурно, то это такая специальная дыра в ядре Linux, для максимально прямой коммуникации между видеокартой и клиентским ПО, создаваемая в первую очередь ради видеоиг.. скажем так «медийных приложений, требующих аппаратного ускорения графики». В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS): И теперь мы все имеем «клевый терминал» в разрешении 1920×1280 со сглаживанием шрифтов, на котором что-то разобрать возможно лишь с лупой прищурившись. Угар портирования Под натиском волн малолетних специалистов, желающих «гонять игоры» на серверной ОС, не выдержали даже разработчики FreeBSD: подсистема DRM и KMS, вместе с проприетарными блобами была перенесена из Linux и теперь вовсю используется в FreeBSD. По-умолчанию, да. Кстати с тех лет и до сих пор разработка DRM синхронизируется с апстримом (это отдельный проект) и ядром Linux, заезжая в сборки FreeBSD вместе со всеми свежими багами в виде срезов исходников. А основная разработка при этом едет дальше. Нетрудно догадаться, что отправлять багрепорты что в проект drm-kmod , курируемый FreeBSD, что в апстрим ядра Linux при таком подходе равнозначно отправке в «Спортлото». Заодно во FreeBSD были фактически похоронены альтернативные варианты: старый текстовый TTY и Xorg-драйвер для видеокарт Intel пока еще существуют и собираются в виде пакетов, но вот их настройку и главное — все сопутствующие сбои в клиентском ПО вы теперь вынуждены отлавливать и исправлять самостоятельно. «Интерес сообщества» к таким технологиям оказался утрачен. В качестве вишенки на этом интересном торте, добавлю что всенародно любимый браузер Google Chrome плохо работает без загруженного модуля KMS, поэтому заводить весь этот цирк с DRM и KMS приходится даже на откровенно винтажных машинах — просто ради работающего браузера. И других вариантов уже фактически нет. Оборзевшая техника Вся эта технологическая «многоножка» из разработчиков Intel с блобами, апстрима ядра Linux с любовью к тотальным переделкам на Rust, на практике приводит к тому, что в бедную FreeBSD постоянно попадают ломающие обновления, отследить и исправить которые «в моменте» не получается. «Думали что работает» — говорят в таких случаях разработчики FreeBSD и советуют обновиться до -CURRENT версии. Что для обычных людей и рабочего окружения на машине равносильно старому японскому ритуалу сеппуку, поскольку упадет и сломается вообще все. В какой-то момент обновление пакета drm-kmod , содержащего тот самый порт подсистемы DRM из ядра Linux принесло мне такое: drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080 Ну принесло и принесло, ошибок много разных, исправляются далеко не все, дело это небыстрое и так далее. Но только эта забивала собой весь буфер сообщений ядра! Сообщений генерировалось настолько много, что dmesg — команда для отображения этого самого буфера, показывала только одну эту бесконечно повторяющуюся ошибку, как на скриншоте в шапке статьи. При этом ошибка сама по себе довольно известная, страдают как пользователи FreeBSD: Так и линуксоиды: Но самое веселое, что баг оказался с рогами и копытами совсем не специфичным и само сообщение означает буквально.. ничего. Просто «что-то сломалось», в переводе с языка Intel. Ну что, вы все еще любите проприетарные драйвера от уважаемых производителей? Беглый поиск в репозитории, в котором ведется разработка подсистемы DRM (да, она ведется отдельно от ядра Linux) показал, что сообщений с этой ошибкой навалом: Положение дел В итоге есть некий баг, с гнездом в районе прошивки видекарты Intel. Который (судя по репортам) зверствует проявляет себя самым феерическим образом: от спама сообщениями до мигания экрана и полного зависания системы. Исправить своими силами этот баг нельзя, все «workaround» в сети по накалу дичи в рекомендациях напоминают известное шоу «Битва Экстрасенсов»: нарисуйте ночью в поле пентаграмму из соли, разложите по углам загрузочные диски FreeBSD с 5й по 10ю и громко читайте файл Changelog задом наперед. В качестве примера, вот так выглядит одно из решений: Но есть и хорошие новости. Хорошие новости Целых две. Первая заключается в том, что в свежих прошивках баг вроде бы исправили на стороне Intel, но чтобы эту прошивку поставить — нужна сборка модуля DRM для FreeBSD 15 , которая еще не выпущена: Еще стоит рассказать, что прямо сейчас идет серьезная работа по перепиливанию DRM как в его основном проекте так и на стороне команды FreeBSD (в -CURRENT ), поэтому даже пытаться бекпортировать текущую версию drm-kmod в 14.х ветку не стоит. Также (к сожалению) не стоит рассматривать переезд на 15ю версию как гарантированное решение, поскольку есть уже открытые багрепорты и оттуда: Вторая хорошая новость заключается в том, что на двух моих ноутбуках, где проявляется данный баг все тем не менее работает без критических сбоев — без мигания и зависаний. А само сообщение до недавних пор глушилось настройкой: compat.linuxkpi.i915_disable_power_well="0" Так что конкретно в моем случае, проблема заключается лишь в бесконечном затирании буфера сообщений ядра этой дурацкой и бессмысленной ошибкой: drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080 Которую мы и будем сейчас глушить, что поделаешь. Аморальный патч Разумеется так делать нельзя: глушить сообщения об ошибках в ваших реальных проектах не стоит. Хотя если в вашем проекте возникает ситуация, когда сообщение об ошибке генерируется по сотне раз за секунду — ну наверное вопрос уже к вам как к разработчику, допустившему такую дичь. К счастью FreeBSD — проект не мой, прямого доступа к разработчикам нет, а сам процесс разработки подсистемы DRM сильно напоминает известный фильм «Human Centipede». Где (а главное — зачем) искать концы в такой ситуации не очень понятно, для примера багрепорты по ошибкам DRM в трекере ядра Linux сразу просят перенаправлять в отдельный проект, не разбираясь вообще: Так что было решено применить военную хитрость просто заглушить сообщение об ошибке в исходниках, пересобрав DRM из портов. Так выглядит конечный результат после патча: Поскольку новая 15я по счету версия FreeBSD еще официально не вышла на момент написания статьи, я все еще использую 14.3 , где максимально доступная версия DRM для этой ветки — 6.1. Ее мы и будем жестоко патчить. В портах она находится в этом каталоге: /usr/ports/graphics/drm-61-kmod Поиск в исходном коде по тексту сообщения об ошибке показал, что генерируется она всего в одном месте, в файле i915_irq.c: drivers/gpu/drm/i915/i915_irq.c Так выглядит место появления: .. fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), fault_errors); .. Все что нужно сделать — закомментировать этот блок, начиная с условия. И все, больше вы это проклятое сообщение не увидите, ура. Для уменьшения работы мозгом у дорогих читателей, подготовил на этот раз готовый патч, который достаточно положить в специальный каталог и он автоматически применится при сборке drm-kmod . Надо Создать файл patch-i915_irq.c в каталоге /usr/ports/graphics/drm-61-kmod/files , затем вставить туда вот такое содержимое: *** drivers/gpu/drm/i915/i915_irq.c.orig Tue Nov 18 17:17:39 2025 --- drivers/gpu/drm/i915/i915_irq.c Tue Nov 18 17:17:52 2025 *************** *** 2571,2585 **** if (iir & gen8_de_pipe_underrun_mask(dev_priv)) intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe); fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); ! if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), ! fault_errors); } if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) && master_ctl & GEN8_DE_PCH_IRQ) { /* --- 2571,2585 ---- if (iir & gen8_de_pipe_underrun_mask(dev_priv)) intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe); fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); ! /*if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), ! fault_errors);*/ } if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) && master_ctl & GEN8_DE_PCH_IRQ) { /* Дальше просто перезапускаем сборку: make clean make Проверяем что изменения в файле i915_irq.c применились и запускаем установку собранного пакета: make reinstall После чего перезагружаем систему. Если все прошло удачно — дурацкое сообщение вас больше беспокоить не будет, если нет — компьютер взорвется система скорее всего зависнет при запуске, либо вас будет ожидать черный экран. Но главное это разумеется хорошее настроение и поставленная на место машина, вернувшаяся к своей основной задаче служить людям. P.S. Ошибка действительно дурацкая, еще и наведенная — если дойдет до серьезных сбоев вроде мигания экрана (screen flickering), вы увидите дополнительные сообщения в логах, по которым можно продолжать искать реальную проблему. Так что вопрос удаления этого сообщения больше косметический, плюс частично — лишней нагрузки, поскольку генерация по сотне таких сообщений в секунду разумеется нагружала систему. Менее цензурный оригинал как обычно в нашем блоге, копия на Дзене.