На свете есть не так много вещей, способных выбесить программиста. И лишь одна делает это с гарантией: оборзевшая в край машина, возомнившая себя умнее человека.
А значит снова пришло время карать и патчить!
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), вы увидите дополнительные сообщения в логах, по которым можно продолжать искать реальную проблему.
Так что вопрос удаления этого сообщения больше косметический, плюс частично — лишней нагрузки, поскольку генерация по сотне таких сообщений в секунду разумеется нагружала систему.
Менее цензурный оригинал как обычно в нашем блоге, копия на Дзене.
Комментарии (23)
mentin
19.11.2025 19:16В гугловской библиотеке для логирования есть отличный макрос для таких случаев, LOG_EVERY_N_SEC(). Добавляет событие, но не чаще чем одно в указанное число секунд. Но наверное ещё лучше запилить фичу для самого ring buffer, дросселировать слишком часто повторяющиеся сообщения.
alex0x08 Автор
19.11.2025 19:16Если бы это сообщение об ошибке несло бы какой-то смысл и не появлялось в каждом репорте в качестве фона - да.
Но проще было уровень сменить на отладочный, чтобы эти сообщения появлялись только при явно заданном флаге отладки.
rivo
19.11.2025 19:16До появления DRM, каждый производитель мобильных устройств и медиаплееров выкатывал собственное SDK и кастомное ядро Linux. Чтобы поменять разрешение экрана, надо было изучить тонну китайского кода. Даже думать нельзя было, чтобы запустить какие-то сторонние приложения. Все прибито гвоздями и только от производителя. То что сейчас сделали, это просто фантастика, стандартизировали весь этот зоопарк.
anger32
19.11.2025 19:16Эта ошибка говорит о том, что pipe контроллера дисплея настроен не верно. 50/50 режим установится или нет. Наиболее часто встречается у DP / eDP портов ввиду link train процедуры. А поскольку вы говорите о ноутбуках, это 100% eDP.
Но главное: у драйвера i915 нет обязательных блобов, все опциональные и в этом смысле код чист. GuC, HuC, etc на работоспособность не влияют. Отсюда, постоянное их упоминание в статье выглядит не профессионально как минимум.
Скрытый текст
P. S. Времена патчей KDE под FreeBSD с появлением LinuxKPI вернулись, welcome
alex0x08 Автор
19.11.2025 19:16Эта ошибка говорит о том, что pipe контроллера дисплея настроен не верно
"Aw, snap!" от Intel, ага.
Написал же, что ошибка наведенная и никакого вменяемого смысла сама по себе не несет.
В случае появления мигания, реальная ошибка тоже появляется в логе - на скриншотах репортов ее видно.
нет обязательных блобов
Это как?
Самого чипа видеокарты ведь отдельно не существует — он реализован на кристалле процессора, где блобы очень даже есть. А «фирменное» и полностью закрытое управление питанием?
anger32
19.11.2025 19:16ошибка наведенная и никакого вменяемого смысла
Да-да. Прерывание об ошибке display engine само по себе появляется. А если серьёзно, регулярно его встречал при отладке раннего кода порта этого драйвера, сценарий уже описал. То, что ошибка не всехда приводит к видимым эффектами не значит, что её нет. Есть негласное правило компенсации 5-10% погрешностей modeline, вполне вероятно, что в конкретно этом сценарии не превысили и матрица компенсировала. А там, где замерцало модлайн попался не самый удачный.
Самого чипа видеокарты
Путаете чип (Hard) с драйвером (soft)? В коде драйвера бинарных закладок, кроме перечисленных мною, нет. DC, PMU, 2D и 3D реализуются на открытых исходных кодах. Блоб в драйвере это firmware, чьего исходника в опенсорсе нет. Внутренний микрокод контроллера таковым не является и присутствует в том или ином виде в любом контроллере.
Найдёте в коде драйвера i915 блоб, приведите ссылку. Как-то за более чем 10 лет его портировния в разные ОС так и не увидел. Управление питанием там также реализовано, как в виде различных профилей, так и в виде отключения отдельных блоков.
alex0x08 Автор
19.11.2025 19:16А там, где замерцало модлайн попался не самый удачный.
Вообще не было изменений modline: не было изменения частоты, разрешения экрана, не было suspend/resume или запуска чего-то нагружающего видеокарту. Так что не могу связать одно с другим ну никак.
Видимые эффекты проявлялись не на моем оборудовании а у багрепортеров в статье, там есть и версия чипа и версия прошивки. У них да - вплоть до зависания системы.
Найдёте в коде драйвера i915 блоб, приведите ссылку.
Есть вот такой репозиторий, в котором лежат файлы сборки для прошивки, используемыми KMS:
The firmware files are located in amdgpukmsfw-files, i915kmsfw-files and radeonkmsfw-files directories, for respective driver. The directories with the same names, but without -files, contain Makefiles for building firmware kmods for loading into the FreeBSD kernel.
Есть ссылка на git ядра Linux, откуда они берутся.
Выглядит все это как набор .bin файлов без исходников и загружаются они в момент инициализации KMS.
Что это если не бинарный блоб я не знаю.
Можно конечно называть их "друзьями по байтам" или "нечистыми данными" или еще как жонглировать терминами, но суть от этого не поменяется.
Ошибка кстати именно там, внутри, в этом самом бинарном блобе.
anger32
19.11.2025 19:16Вообще не было изменений modline: не было изменения частоты, разрешения экрана, не было suspend/resume или запуска чего-то нагружающего видеокарту
Модлайн не всегда берется системный. Для eDP вообще редко. Он вычитывается из пресетов VBT ("The contents of the VBT are independent of the driver or kernel version") или напрямую из EDID / DDC матрицы. Вы его может быть и не меняли, а вот "положили" вам его, видимо, вполне хорошо. Бывают девайсы (мониторы, панели, телевизоры, ...) у которых EDID вообще отсутствует или битый - в смысле прописанный там модлайн взят хз откуда, но данному девайсу не подходит. Как бэ тут драйверу законно сносит крышак в виде артефактов, отсутствия изображения и т.п., потому как угадать он его не может, если он не совместим с каким-либо из стандартов: CVT, GTF, RBT, RBT2, ...
Не то, чтобы я всё это защищал, но тут рыло в пуху не только у вендора GPU.
Что это если не бинарный блоб я не знаю
Да, это блобы. Но я о них написал вам в самом первом сообщении: "GuC, HuC, etc на работоспособность не влияют":
DMC - Display MicroController firmware provides support for advanced graphics low-power idle states
GuC / HuC - альтернативный механизм передачи команд CPU->GPU / опциональные ништяки для HEVC / H.265
В своих портах я их тупо не гружу и проблем не наблюдаю.
У тех же AMD, например, прошивка как раз безальтернативна и вокруг неё всё и строится, и вот тут бы я спорить не стал.
cupraer
19.11.2025 19:16возможно лишь
с лупойприщурившисьОпечатка, надо так: «[…] возможно лишь
за лупойприщурившись […]».
Frankenstine
19.11.2025 19:16Все что нужно сделать — закомментировать этот блок, начиная с условия
Фи, как грязно. Если конкретно 0x00000080
Просто «что-то сломалось», в переводе с языка Intel.
то следует "душить" конкретно этот код, а другие таки пушить дальше в
drm_err
Cfyz
19.11.2025 19:16В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS)
Внезапно, GPU это не только 3D. И даже аппаратное ускорение вывода на экран это тоже не только 3D.
То, что там при желании можно достучаться и до 3D тоже -- это просто побочный эффект работы с одним и тем же устройством вывода на экран через один и тот же интерфейс, что в терминале текстовой консоли, что за ее пределами.
GPU с аппаратным ускорением вывода это нынче такая же банальность, как вывод звука или сеть. Они тоже когда-то были опциональными внешними устройствами, которые в угаре оптимизации ядростроители включили прямо в стандартную поставку.
alex0x08 Автор
19.11.2025 19:16Вопрос не в банальности а в том что это с технической точки зрения шиза - использовать графический рендер для вывода текстового терминала.
Вот так выглядел один из первых VT100 терминалов, 1978й год:
DEC VT100 terminal И все замечательно работало 40 лет, поведение было предсказуемым.
Сейчас получается что буквы и цифры рисует GPU через шейдеры, собирая по пути все проблемы GPU - от нагрева до ошибок отрисовки.
Мой текстовый терминал не мигал экраном из-за сбоев в прошивке.
cupraer
19.11.2025 19:16Я с вами-то совершенно согласен, разумеется, но справедливости ради хочу уточнить: эти терминалы мигали, как заведенные. Я бы даже сказал, мерцали. Не из-за прошивки, конечно.
Cfyz
19.11.2025 19:16с технической точки зрения шиза - использовать графический рендер для вывода текстового терминала
Шиза использовать один общий способ вывода на экран вместо нескольких разных?
Или вы думаете что без DRM в текстовом терминале какой-то другой GPU с какой-то другой прошивкой используется?
Если хотите настоящий текстовый терминал, то придется подключать UART. Все остальное уже сто лет как графический режим и разница между текстом, 2D и 3D чистая условность.
буквы и цифры рисует GPU через шейдеры, собирая по пути все проблемы GPU - от нагрева до ошибок отрисовки
А есть где-то свидетельства, что в процессе отрисовки консоли через DRM используется что-то сложнее простого вывода фреймбуфера на экран самыми базовыми для GPU средствами, или вы чисто интуитивно провели параллель GPU = 3D игры = какие-то непонятные шейдеры и нагрузка?
Вот так выглядел один из первых VT100 терминалов. И все замечательно работало 40 лет, поведение было предсказуемым.
VGA уже давным давно нет и задолго до DRM использовался fbdev и примерно такая же плотная работа с GPU.
iamkisly
Размер шрифта же редактируется
alex0x08 Автор
Редактируется, но чтобы на Ретине или большом мониторе это нормально выглядело я еще не видел. Даже на скриншотах.
V1tol
Я себе на 27" 1440р мониторе для увеличенного шрифта с кириллицей прописал следующее в файл
/etc/vconsole.confИ выглядит это примерно вот так:
Cheater
Оно и не может нормально выглядеть, откуда вообще взяться сглаживанию в ядерной консоли, которое вы упоминаете в статье? Там шрифт всегда монохромный (https://en.wikipedia.org/wiki/PC_Screen_Font), задаётся битмапом из нулей и единиц (1=закрашено 0=фон). Соответственно нет полутонов и всего остального, нужного для сглаживания. Максимум можно взять шрифт побольше.
Jijiki
там в лоадере можно пошуршать
соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно