Я не уверен, почему это сработало, но если вы сделаете это, чтобы проверить udev на наличие сетевых интерфейсов.
user@host:~$ udevadm info -a -p /sys/class/net/eth0 |grep address
ATTR{address}=="22:22:33:44:33:22"
Обратите внимание, что перед адресом стоит ATTR
, а не SYSFS
. Я изменил свой файл, заменив SYSFS
на ATTR
, и это исправлено.
KERNEL=="eth*", ATTR{address}=="22:22:33:44:33:22", NAME="eth0"
Раньше это работало, поэтому я предположил, что «автоматические обновления» внесли изменения в udev.
Только что обнаружил, что есть пара вики-страниц, связанных с этой темой:PCI _отверстие и 3 _ГБ _барьер
В настоящее время на x86 дыру PCI можно устранить с помощью перераспределения памяти, но это не восстанавливает ВСЕ адреса ОЗУ, украденные MMIO, например, несколько небольших областей размером менее 16 МБ. -Чипсет имеет возможности переназначения только ограниченного числа областей.
Поскольку у вас 64 -битная операционная система, вы можете включить параметр BIOS «Декодирование выше 4G», «64 -битное декодирование адреса ввода/вывода» или как он называется у вашей системы/производителя материнской платы. Если этот параметр включен, любое оборудование MMIO, способное работать с 64-битными -адресами, сопоставляется с адресами за пределами традиционного 32-битного диапазона -, сводя к минимуму конфликты с памятью и, таким образом, уменьшая потребность в переназначении слотов.
В моей системе результирующее сопоставление для графического процессора выглядит следующим образом:
6000000000-600fffffff : 0000:01:00.0
Кроме того, 250 МБ — это примерно 1,5% от 16 ГБ; если получение последних 1,5% памяти действительно критично, вы можете получить заметный выигрыш в производительности от увеличения объема оперативной памяти, если это вообще возможно. Просто говорю...
Насколько мне известно, «таблица маршрутизации» для переназначения памяти, по крайней мере, частично реализована в аппаратном обеспечении чипсета и сильно зависит -от чипсета, поэтому она обычно настраивается системной прошивкой во время загрузки. Если возможен какой-либо доступ к времени выполнения -, я ожидаю, что это будет через подпрограммы прошивки ACPI; в противном случае ядро должно было бы иметь определенные процедуры для каждого набора микросхем.
(Да, в ядре есть аппаратные -модели -специфические подпрограммы для обхода известных аппаратных ошибок; но чтобы углубиться в это и обойти абстракцию ACPI, предоставляемую системной прошивкой, потребуется гораздо больше усилий, что-то вроде coreboot .)