[freebsd] 13.0 memstick не грузится

[Valentin Nechayev]

hi,

 Sun, Jan 02, 2022 at 13:14:20, spell wrote about "Re: [freebsd] 13.0 memstick не грузится": 

> Разумеется, легаси и прочее "640K хватит на все" приходится тащить,
> куда деваться. Я больше про то, что, похоже, каждый новый трюк с картой
> памяти делали как последний, не "на вырост",

А у Intel так чуть менее чем всё. Почти любое действие рассчитывается
не более чем на полшага. Даже до одного шага не дотягивают... Примеры
можно приводить десятками. Но описанные чудеса с памятью вытекают не
только из этого.

> Я не знаю, как надо было сделать, но точно не так.
> Ради того, чтобы вернуть доступ к полмегабайту (неумно отобранный ранее),
> смапим повторно 16G, из которых будут доступны только эти полмегабайта,
> и сдвинем 8G второй планки по адресному пространству, увеличив бардак еще больше. 
> Вот в этом месте KISS не только вышел из чата, но и застрелился.

Ну во-первых это только один из вариантов, и сейчас так обычно _не_
делают (например, потому, что надо ограничить доступ к SMM памяти...
но это ещё один костыль). Мапят кусок отдельно, да, но доступ дают
только к этому небольшому участку. В любом случае, не стараются
контроллеру задать много работы, он просто не успеет.

А во-вторых - а зачем вообще тут непрерывность памяти?

1) Когда работает загрузчик (типа GRUB или фрёвый /boot/loader), ему
нужно распаковать всё ядро в связную область, ну и ещё пару мег на
данные старта с офигенным запасом - дальше ядро подхватит это и само
полетит. То есть считаем современному ядру достаточно ну даже 30MB (с
запасом в километр) одним связным куском, чтобы дальше разобраться
самому.
В принципе он и тут мог бы покрошить мелкими кусочками, но это
заморочнее потом восстанавливаться.

2) Когда инициализируется система управления виртуальной памятью в
ядре, ей нужен (на x86) небольшой "идемпотентно" отображённый кусок в
десяток килобайт (обычно в нижнем 1MB) для переключений, а дальше она
способна проитерировать все выделенные области и подготовить их для
нарезания по страницам (4KB, если не large/huge). Даже если бы было,
что идёт "полосатая" схема - 4KB есть, 4KB нет, 4KB есть, 4KB нет... -
она бы справилась.

И учтите, что может оказаться, что полная непрерывность адресов памяти
вообще невозможна даже если б не было выкусывания легаси-блоков. В
случае одного физического процессора, да, можно начинать мапить с
более толстых модулей памяти, тогда будет непрерывность. А представим
себе серверную материнку с 2 физическими процессорами и памятью -
сейчас в этом случае половина слотов памяти будет подключена к
контроллеру первого процессора, половина - второго. И вот ставим мы
48GB (32+16) на первый процессор (в слоты под его контроллером) и 40GB
(32+8) на второй. Имеем право, а больше не нашлось. Контроллеры памяти
могут просто не суметь поставить их так, чтобы получилась непрерывная
область.

Потому, ничего этого и не требуют.


-netch-