Перевод документации драйвера NVIDIA для Linux, часть 3

Глава 9. Известные проблемы

Следующие проблемы имеются в текущей версии драйвера и ожидают решения.

Известные проблемы

OpenGL и вызов dlopen()

Есть некоторые трудности со старыми версиями загрузчика «glibc» (в частности, с версией из дистрибутива Red Hat Linux 7.2) и приложениями, такими как Quake3 и Radiant, использующими вызовы dlopen(). Обратитесь к Главе 7 за дополнительной информацией.

Несколько видеокарт, несколько мониторов

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

Взаимодействие с «pthreads»

Однопоточные приложения, использующие вызовы dlopen() для загрузки библиотеки «libGL» NVIDIA, и одновременно для загрузки любых других библиотек, связанных с «libpthread», аварийно завершают работу в libGL. Этого не происходит с новыми библиотеками OpenGL ELF TLS NVIDIA (обратитесь к Главе 5 за описанием библиотек ELF TLS OpenGL). Возможные действия в случае таких проблем:

1. Загружать библиотеку, связанную с libpthread, перед загрузкой libGL.
2. Связывать само приложение с libpthread.

 Платформа X86-64 (AMD64/EM64T) и ранние версии ядра операционной системы серии 2.6

Многие x86_64 версии ядра операционной системы серии 2.4 и 2.6 имеют неучтенные проблемы в реализации интерфейса ядра «change_page_attr». Ранние версии 2.6 ядра содержали проверку, вызывающую событие BUG() при обнаружении подобной проблемы (результатом события BUG() является принудительное завершение работы текущего приложения ядром ОС); это приложение может быть как приложением OpenGL, так и сервером Х-интерфейса. Проблема устранена в ядре версии 2.6.11.

В драйвер добавлены специальные проверки для определения, что модуль уровня ядра NVIDIA скомпилирован для платформы x86-64 при используемом ядре операционной системы версии между 2.6.0 и 2.6.11. В этом случае отключается использование интерфейса ядра change_page_attr. Это позволяет избежать проблемы, но оставляет систему уязвимой для конфликтов информации в кеше (см. конфликты информации в кеше ниже для дополнительной информации о проблеме). Обратите внимание, что проблема change_page_attr и событие BUG() могут быть вызваны другими подсистемами ядра, зависящими от этого интерфейса.

Если вы используете ядро x86_64 версии 2.6, мы рекомендуем обновить ядро до версии 2.6.11 или более поздней. Также обратите внимание на информацию о проблемах прямого обмена с памятью (DMA) в 64-битных системах в Главе 10.

Конфликты информации в кеше

Конфликты информации в кеше возникают, когда несколько связей со страницей оперативной памяти имеет взаимопротиворечащие состояния кеширования, например, кешируется или не кешируется. В силу этих противоречий, данные в странице памяти могут быть испорчены при сбросе кеша центрального процессора. Если страница использовалась для прямого обмена с памятью драйвером, например, драйвером NVIDIA, это может привести к проблемам в работе оборудования и зависаниям системы.

NVIDIA обнаружила ошибки в некоторых версиях ядра Linux, связанные с конфликтом информации в кеше. Хотя некоторые системы работают абсолютно нормально при возникновении конфликтов, в других наблюдаются проблемы со стабильностью, вплоть до случайных зависаний. Пользователям, сталкивающимся с нестабильной работой системы из-за конфликтов информации в кеше, лучше всего будет обновить ядро операционной системы до версии, не имеющей таких проблем.

NVIDIA добавила в драйвер механизм обнаружения случаев конфликтов информации в кеше, и драйвер выдает сообщение вроде: 

NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73

 Если вы увидели это сообщение в файле журнала, и столкнулись с нестабильной работой системы, вам необходимо обновить ядро операционной системы до последней доступной версии. Если сообщение продолжает появляться и после обновления ядра, направьте отчет об ошибке в NVIDIA.

64-битные BAR (Регистр базового адреса)

Начиная с первых графических процессоров с врожденной поддержкой PCI-Express, графические процессоры NVIDIA сообщают о поддержке 64-битных регистров базового адреса (регистр базового адреса хранит информацию о положении области памяти для операций ввода-вывода PCI устройства, для регистров или кадрового буфера). Это означает, что область памяти для операций ввода-вывода графического процессора (регистров или кадрового буфера) может быть размещена за пределами адресуемого по 32-битной схеме пространства (первых четырех гигабайт памяти).

Выбор места размещения регистра базового адреса осуществляется BIOS материнской платы во время загрузки компьютера. Если BIOS поддерживает 64-битные регистры, то области памяти для операций ввода-вывода могут быть размещены за пределами адресуемого по 32-битной схеме пространства. Если же BIOS не поддерживает эту функцию, то области памяти для операций ввода-вывода будут помещены в пределах адресуемого по 32-битной схеме пространства так же, как это делалось раньше.

К сожалению, некоторые версии ядра Linux (включая 2.6.11.x) не поддерживают или не принимают 64-битные регистры базового адреса. Если BIOS разместит любую из областей ввода-вывода за пределами 32-битного адресуемого пространства, ядро системы откажется использовать регистр базового адреса и драйвер NVIDIA не будет работать. Единственный способ решения данной проблемы — переход на более новое ядро.

Исчерпание виртуального адресного пространства ядра в платформе X86

В системе X86 и системах AMD64/EM64T, использующих ядро X86, виртуальное адресное пространство имеет размер только доступно только 4 Гб, который ядро операционной системы Linux обычно делит между пользовательскими процессами и ядром в соотношении 3 Гб к 1 Гб. Часть, выделенная ядру, используется для создания прямых отображений оперативной памяти. В зависимости от объема оперативной памяти размер части ядра виртуального адресного пространства, доступной для прочих применений, колеблется и может составлять лишь 128 мегабайт, если установлен 1 Гб и более оперативной памяти. Обычно резервируется не менее 128 Мб.

Виртуальное адресное пространство ядра, оставшееся после создания прямых отображений оперативной памяти, используется как самим ядром операционной системы, так и драйверами для отображения ресурсов ввода/вывода и резервирования областей памяти. В зависимости от числа претендентов и их требований, виртуальное адресное пространство ядра может оказаться исчерпанным. Когда это происходит, ядро операционной системы Linux выводит сообщение об ошибке вида:

allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.

или

vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.

Модуль уровня ядра драйвера NVIDIA требует определенный объем виртуального адресного пространства ядра для каждого графического процессора, и резервирования некоторых областей памяти. Если во время загрузки системы не больше 128 Мб пространства доступно для ядра и драйверов устройств, модуль уровня ядра NVIDIA возможно не сможет инициализировать все графические процессоры, или зарезервировать области памяти. Обычно таких проблем не возникает в системах с одним или двумя графическими процессорами, хотя это зависит от числа прочих драйверов и их потребностей, но в системах с тремя и более графическими процессорами эта проблема весьма вероятна.

Возможные решения проблемы включают в себя:

• Если ваш компьютер оснащен 64-разрядным процессором (совместимым с AMD64/EM64T), рекомендуется перейти на использование 64-битных дистрибутивов операционной системы/ядра Linux. Благодаря значительно большему размеру адресуемого адресного пространства у 64-разрядных процессоров, X86-64 ядрам операционной системы не угрожает проблема исчерпания виртуального адресного пространства в обозримом будущем.
• Если 64-разрядное ядро не может быть использовано, опция ядра vmalloc может быть использована для увеличения объема виртуального адресного пространства, резервируемом ядром операционной системы Linux (обычно это 128 Мб). Рекомендуется плавно увеличивать это значение до достижения баланса между доступным объемом виртуально адресного пространства и объемом прямых отображений оперативной памяти. Этого можно добиться последовательным заданием значений vmalloc=192M, vmalloc=256MB и т.д. и проверкой, что вышеприведенное сообщение об ошибке продолжает появляться.
  
  Обратите внимание, что некоторые версии загрузчика операционной системы GRUB имеют проблемы с вычислением распределения памяти и загрузкой initrd при использовании опции ядра vmalloc. Команда uppermem загрузчика GRUB может быть использована чтобы заставить GRUB загружать initrd в нижнюю область системной памяти в качестве обхода проблемы. Это не должно сильно повлиять на производительность системы после загрузки ядра. Требуемый формат команды (подразумевается GRUB версии 1):
  
  title Kernel Title
  uppermem 524288
  kernel (hdX,Y)/boot/vmlinuz...
  
  Также заметьте, что опция ядра vmalloc появилась только в ядре Linux версии 2.6.9 и более поздней. В старых системах объем памяти, используемый ядром может быть уменьшен с помощью опции ядра mem, которая заодно уменьшает объем прямых отображений памяти и увеличивает доступное ядру виртуальное адресное пространство. Например, mem=512M заставит ядро операционной системы игнорировать всю оперативную память кроме первых 512 Мб. Хотя уменьшение доступной оперативной памяти и не лучший выход, этот подход может быть использован для проверки, что проблемы с инициализацией видеокарты вызваны именно исчерпанием виртуального адресного пространства.
• В некоторых случаях помогает отключение драйверов буфера кадров, таких как «vesafb», так как эти драйверы могут пытаться отобразить всю или большую часть видеопамяти в виртуальное адресное пространство ядра, стремительно расходуя этот ресурс. Вы можете отключить драйвер vesafb установлением опции ядра: video=vesa:off vga=normal.
• Некоторые версии ядра операционной системы Linux могут быть настроены на другое распределение виртуального адресного пространства (например, 2.8 Гб и 1.2 Гб, 2 Гб и 2 Гб). Такая возможность может быть использована для предотвращения исчерпания виртуального адресного пространства ядра без уменьшения объема прямых отображений оперативной памяти. В некоторых дистрибутивах также содержатся версии ядра, использующие раздельные адресные пространства размером 4 Гб для пользовательских процессов и ядра. Такие ядра предоставляют достаточный объем виртуального адресного пространства ядра в обычных системах.

 Valgrind

Реализация OpenGL NVIDIA использует самомодифицирующийся код. Для того чтобы принудить Valgrind к восстановлению кода после изменения, необходимо запускать Valgrind с использованием опции командной строки:

--smc-check=all

Без этой опции Valgrind может выполнять некорректный код, что приводит к непредсказуемому поведению и ошибке вида:

==30313== Invalid write of size 4

Метод «MMConfig» управления адресным пространством конфигурации устройств PCI

Ядра операционной системы Linux версии 2.6 содержат поддержку отображения в оперативную память адресного пространства конфигурации устройств PCI. К сожалению, возникает много проблем с этой функцией, и последние версии ядра операционной системы более осторожны в использовании этого способа. Драйвер NVIDIA может оказаться не в состоянии надежно осуществлять чтение и запись адресного пространства конфигурации устройств PCI видеокарт на базе NVIDIA при использовании ядром операционной системы метода MMCONFIG для работы с адресным пространством PCI, особенно при использовании нескольких графических процессоров и нескольких центральных процессоров в 32-битных версиях ядра. Использование метода MMConfig может быть определено по присутствию строки PCI: Using MMCONFIG в выводимой информации по команде dmesg. Это метод управления может быть отключен с помощью параметра ядра pci=nommconf операционной системы.

Ноутбуки

Если используется ноутбук, обратитесь к секции «Известные проблемы с ноутбуками» в Главе 18.

Полноэкранное сглаживание (FSAA)

Когда включено полноэкранное сглаживание (переменной среды __GL_FSAA_MODE присвоено значение, включающее FSAA, и выбрано использование мультисэмплинга), может наблюдаться искажение изображения при изменении размера окна.

Вызов завершения «libGL» DSO и «pthreads»

При выходе из многопоточного приложения OpenGL возможна ситуация, когда вызов завершения DSO библиотеки «libGL» (также известный как деструктор или «_fini») вызывается в то время, когда некоторые потоки еще выполняют OpenGL код. Вызов завершения требуется для высвобождения системных ресурсов, занятых libGL. Это может вызвать неполадки в работе потоков, еще использующих эти ресурсы. Присвоение переменной среды __GL_NO_DSO_FINALIZER значение 1 позволяет избежать проблем путем принуждения вызова завершения библиотеки libGL к сохранению ее ресурсов на месте. Эти ресурсы станут доступны операционной системе после завершения процесса. Обратите внимание, что вызов завершения также выполняется как часть процесса dlclose(3), так что если имеются приложения, постоянно осуществляющие вызовы dlopens(3) и dlcloses(3) к libGL, использование переменной __GL_NO_DSO_FINALIZER приведет к утечке ресурсов libGL до завершения процесса. Использование этой возможности может улучшить стабильность работы некоторых многопоточных приложений, включая приложения Java3D.

В следующей секции описаны проблемы, которые не будут исправляться. Часто причина этих проблем находится не под контролем NVIDIA.

Проблемы, которые не будут исправлены

Материнская плата Gigabyte GA-6BX

В этой материнской плате используется регулятор напряжений LinFinity на линии 3.3 В, рассчитанный на максимальный ток в 5 A — меньше, чем предусмотрено стандартом AGP, требующим 6 A. Когда выполняется проверка или работают приложения, температура регулятора возрастает, приводя к падению напряжения, идущего на графический процессор NVIDIA вплоть до 2.2 В. В этих условиях, регулятор не может обеспечивать требуемое напряжение для графического процессора NVIDIA по линии 3.3 В.

Эта проблема не возникает, если видеокарта оснащена импульсным регулятором, или к линии 3.3 В подключено внешнее питание.

Чипсеты VIA KX133 и 694X с AGP 2x

На материнских платах для процессоров Athlon, построенных на чипсетах VIA KX133 или 694X, таких как ASUS K7V, драйверы NVIDIA по-умолчанию ограничивают скорость работы AGP порта 2x с целью избежать проблемы с недостаточным усилением одного из сигналов по шине.

Чипсеты Irongate с AGP 1x

AGP порт работает со скоростью 1x на материнских платах для процессоров Athlon, построенных на чипсетах Irongate, с целью избежать проблем с целостностью сигнала по шине.

Чипсеты ALi ALi1541 и ALi1647

С чипсетами ALi1541 и ALi1647 драйвер NVIDIA отключает AGP с целью избежать проблем с временной синхронизации и целостностью сигналов. Обратитесь к Главе 8 за дополнительной информацией о чипсетах ALi.

Расширение NV-CONTROL версий 1.8 и 1.9

В версии 1.8 расширения Х-интерфейса NV-CONTROL введено понятие типов объектов для выставления и проверки атрибутов и для получения сообщений об изменениях состояния объекта. В качестве объекта могут выступать экраны Х-интерфейса, GPU, устройства G-Sync. Ранее все атрибуты описывались применительно к экрану Х-интерфейса. Эта новая информация (сведения от типе объекта и его идентификаторе) сохранялась несовместимым способом в поток данных протокола, что при обращении к экрану Х-интерфейса с номером 1 или большим приводило к ошибкам протокола Х-интерфейса в случаях, когда клиент и сервер расширения NV-CONTROL имели разные версии.

Эта проблема была решена в протоколе версии 1.10 расширения NV-CONTROL, сделав возможным обмен между старыми (версии 1.7 и раньше) клиентами и серверами NV-CONTROL 1.10. Дополнительно, библиотека клиента NV-CONTROL версии 1.10 была доработана для внесения ошибки сохранения информации объекта в протоколе при обмене с сервером NV-CONTROL версии 1.8 или 1.9. Это означает, что библиотека клиента NV-CONTROL версии 1.10 позволяет работать с серверами NV-CONTROL любой версии.

Рекомендуется заново связать приложения-клиенты NV-CONTROL с библиотекой клиента NV-CONTROL версии 1.10 или более поздней (libXNVCtrl.a, в пакете nvidia-settings-ХХХ.ХХ.tar.bz2). Версия библиотеки клиента может быть определена проверкой значений NV_CONTROL_MAJOR и NV_CONTROL_MINOR в присоединенном nv_control.h.

Единственный выпущенный драйвер NVIDIA для Linux, имеющий описанную проблему (т.е. содержащий расширение Х-интерфейса версии 1.8 или 1.9) — 1.0-8756.

Технология снижения энергопотребления центрального процессора может уменьшить полосу пропускания памяти для интегрированных графических процессоров (IGP)

В некоторых моделях центральных процессоров технология снижения энергопотребления может влиять не только на частоту процессора, но и на частоту/полосу пропускания оперативной памяти. В системах с интегрированным графическим процессором любое снижение полосы пропускания оперативной памяти прямо повлияет на графический процессор, также как и на центральный. Это снижение может негативно сказаться на приложениях, зависящих от полосы пропускания памяти, например, на декодирование видео через API VDPAU или выполнение OpenGL. Такие приложения из-за этого могут работать медленнее, чем предполагалось.

В качестве обходного решения, NVIDIA рекомендует так настроить технологии снижения энергопотребления центрального процессора, чтобы избежать любого снижения полосы пропускания оперативной памяти. Возможно, будет достаточным просто задать порог снижения частоты для центрального процессора.

В зависимости от операционной системы и/или дистрибутива, может быть достаточным написать соответствующий файл конфигурации в файловой системе /sys или /proc, или иной файл системных настроек. Обратитесь к документации или Интернет за информацией о настройке технологий снижения энергопотребления центрального процессора в вашей операционной системе.

Ошибки инициализации VDPAU в системах с поддерживаемыми графическими процессорами

Если при инициализации VDPAU выдает сообщение об ошибке VDP_STATUS_NO_IMPLEMENTATION в системе с графическим процессором, отмеченным как поддерживающий PureVideo или PureVideo HD, одной из возможных причин может быть аппаратная ошибка. После исключения всех программных проблем, NVIDIA рекомендует обратится к производителю видеокарты за заменой.

Некоторые приложения, такие как Quake 3, аварийно завершают работу после проверки строки расширений OpenGL

В некоторых приложениях содержится ошибка, проявляющаяся при обработке строки расширений OpenGL, большей определенного размера. По мере добавления новых функций в драйвер, длина строки расширений увеличивается и может вызвать подобные проблемы.

Вы можете ограничить расширения, сообщаемые в строке расширений OpenGL, расширениями, поддерживаемыми определенной версией драйвера с помощью установки переменной среды __GL_ExtensionStringVersion в значение, соответствующее определенной версии. Например,

 __GL_ExtensionStringVersion=17700 quake3

 запустит Quake 3 с расширениями, поддерживавшимися драйвером версий 177.*. Ограничение размера строки расширений помогает обойти подобные ошибки в приложениях.

XVideo и расширение Composite X-интерфейса

XVideo работает неправильно при включенном расширении Composite, если используется более ранняя версия Х-интерфейса, чем X.Org 7.1. Обратитесь к Главе 23.

Области вывода изображения с использованием GLX и расширение Xinerama

Серверы X-интерфейса версий до 1.5.0 имеют ограничения на число доступных областей вывода изображения при включенном расширении Xinerama. Конкретно, использование областей со значением идентификатора больше 255 приведет к порче сервером содержимого памяти, за чем последует некорректная работа или аварийное завершение. В некоторых конфигурациях с большим количеством одновременно включенных функций GLX число областей моет превысить данное ограничение. Во избежание неполадок драйвер Х-интерфейса NVIDIA отбросит области, превышающие лимит сервера. Узнать об отброшенных областях можно, запустив сервер X-интерфейса c ключом запуска -logverbose 6, после чего обратиться к файлу журнала сервера X-интерфейса.

Проблемы работы некоторых серверов Х-интерфейса в системах с несколькими графическими процессорами

Некоторые версии серверов  X.Org 1.5.0 содержат ошибку, приводящую к аварийному завершению Х-интерфейса в системах с более чем одним графическим процессором с ошибкой вида:
   
(!!) More than one possible primary device found
(II) Primary Device is:
(EE) No devices detected.

Fatal server error:
no screens found
    
    Эта ошибка исправлена в выпуске X.Org версии 1.7. Вы можете обойти эту проблему указанием идентификатора шины предпочтительного устройства. За дополнительной информацией обратитесь к описанию опции «BusID» в документации xorg.conf. Вы можете настроить сервер Х-интерфейса на использование отдельного экрана Х-интерфейса на каждом графическом процессоре NVIDIA командой:
    
nvidia-xconfig --enable-all-gpus

Смотрите также описание данной проблемы сервера Х-интерфейса на сайте http://bugs.freedesktop.org/show_bug.cgi?id=18321.

I/O APIC (многопроцессорная система)

Если вы столкнулись с проблемой нестабильной работы системы Linux на многопроцессорном компьютере SMP, и наблюдаете предупреждения I/O APIC от ядра Linux, надежность работы системы может быть значительно улучшена выставлением опции ядра noapic.

Local APIC (однопроцессорная система)

В некоторых системах, использование опции ядра «Local APIC Support on Uniprocessors» может негативно повлиять на стабильность системы и производительность. Если вы столкнулись с зависаниями однопроцессорного компьютера с Linux и используется эта опция ядра, попробуйте отключить поддержку local APIC.

Чипсеты NForce2 и AGPGART

Некоторые ранние версии драйвера agpgart с поддержкой чипсета nForce2 имеют ошибки, приводящие к зависанию системы. В качестве возможных решений можно использовать NVAGP или обновить ядро операционной системы. Известные версии с этой проблемой содержат все дистрибутивы Red Hat Enterprise Linux 3 (до обновления 7). Если используется драйвер agpgart с ошибкой с чипсетом nForce2, драйвер NVIDIA попытается обойти эти ошибки насколько это возможно, путем восстановления после ошибок шины AGP и отключением AGP вообще.

Для использования NVAGP обратитесь к Главе 12.

Глава 10. Размещение буферов DMA в 64-х битных системах

Графические процессоры NVIDIA имеют ограничения по адресуемой оперативной памяти. Это напрямую влияет на буферы прямого обмена с памятью (DMA), так как буферы DMA, размещенные в оперативной памяти, недоступной графическому процессору, не могут быть использованы (или будут обрезаны, что приведет к обращению к неправильному адресу памяти).

Все графические процессоры, не поддерживающие шину PCI-Express и процессоры, поддерживающие PCI-Express посредством моста, ограничены 32-битной адресацией оперативной памяти, что равнозначно 4 гигабайтам памяти. В компьютерах, оснащенных более чем 4 Гб оперативной памяти, размещение доступных буферов DMA может оказаться проблемой. Поддерживающие PCI-Express графические процессоры могут адресовать более 32-бит оперативной памяти и не испытывают таких проблем.

Новые версии ядра предоставляют простой способ размещения памяти с гарантией помещения в адресуемом по 32-битной схеме пространстве. Версия ядра 2.6.15 предоставляет такую возможность с помощью интерфейса __GFP_DMA32. Более ранние версии ядра предоставляют программные функции I/O TLB на платформе Intel EM64T и поддержку IOMMU на платформе AMD64.

К сожалению, некоторые проблемы имеют место быть с обоими интерфейсами. Ранние реализации SWIOTLB в Linux использовали очень небольшой объем памяти для своего буфера (всего 4 Мб). Также, при опустошении буфера, некоторые реализации SWIOTLB вызвали ошибку ядра «kernel panic». Это также верно для некоторых реализаций интерфейса IOMMU.

Ошибки «kernel panic» и сопутствующих проблем со стабильностью на платформе Intel EM64T можно избежать увеличением объема буфера SWIOTLB с помощью опции ядра swiotlb. Этот параметр содержит величину желаемого размеры, деленную пополам. NVIDIA рекомендует увеличение объема буфера SWIOTLB до 64MB; это можно сделать, задав значение swiotlb=16384 для ядра. Обратите внимание, что в ядре версий 2.6 объема буфера SWIOTLB уже установлен в 64 Мб.

Начиная с ядра Linux версии 2.6.9, исходный размер памяти для SWIOTLB стал 64 Мб, и улучшена обработка переполнения. Оба изменения заметно повысили стабильность работы системы на платформе Intel EM64T. Если вы решили обновить версию ядра для использования этих преимуществ, NVIDIA рекомендует обновиться до версии 2.6.11 или более поздней ядра Linux. Смотрите предыдущую секцию для дополнительной информации.

На платформе AMD64, объем памяти для IOMMU может быть настроен в BIOS материнской платы или, если опции BIOS для регулирования IOMMU нет, то через опцию ядра iommu=memaper. Эта опция ядра задает ядру Linux создание IOMMU размером перекрываемой оперативной памяти 32 в степени значения опции. Если значение IOMMU по-умолчанию меньше 64 Мб, ядро Linux автоматически заменяет его IOMMU размером 64 Мб.

Для уменьшения риска проблем со стабильностью в результате опустошения IOMMU или SWIOTLB на платформе X86-64, драйвер NVIDIA для Linux имеет внутреннее ограничение на использование этих интерфейсов. По-умолчанию, драйвер использует не более 60 Мб из размера IOMMU/SWIOTLB, оставляя 4 Мб для системы (подразумевая IOMMU/SWIOTLB размером 64 Мб).

Это ограничение может быть изменено с помощью опции модуля уровня ядра драйвера NVIDIA NVreg_RemapLimit. Если размер IOMMU/SWIOTLB больше 64 Мб, ограничение может быть расширено в большую сторону для использования преимущества дополнительного пространства. В опции NVreg_RemapLimit задается желаемый размер в байтах.

NVIDIA рекомендует оставлять 4 Мб доступными для системы при увеличении ограничения. Например, если внутреннее ограничение должно быть расширено для размера IOMMU/SWIOTLB в 128 Мб, рекомендуемое значение ограничения – 124 Мб. Это ограничение может быть задано опцией NVreg_RemapLimit=0x7c00000 модуля уровня ядра NVIDIA.

Обратитесь к секции «Платформа X86-64 (AMD64/EM64T) и ядра операционной системы серии 2.6» в Главе 9 за дополнительной информацией.