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

[spell at itl.ua]

2 января 2022 г., 16:22, "Valentin Nechayev" <netch at netch.kiev.ua> написал:

> hi,
> 
> Sun, Jan 02, 2022 at 13:14:20, spell wrote about "Re: [freebsd] 13.0 memstick не грузится": 
> 
>> Разумеется, легаси и прочее "640K хватит на все" приходится тащить,
>> куда деваться. Я больше про то, что, похоже, каждый новый трюк с картой
>> памяти делали как последний, не "на вырост",
> 
> А у Intel так чуть менее чем всё. Почти любое действие рассчитывается
> не более чем на полшага. Даже до одного шага не дотягивают... Примеры
> можно приводить десятками. Но описанные чудеса с памятью вытекают не
> только из этого.
> 
>> Я не знаю, как надо было сделать, но точно не так.
>> Ради того, чтобы вернуть доступ к полмегабайту (неумно отобранный ранее),
>> смапим повторно 16G, из которых будут доступны только эти полмегабайта,
>> и сдвинем 8G второй планки по адресному пространству, увеличив бардак еще больше.
>> Вот в этом месте KISS не только вышел из чата, но и застрелился.
> 
> Ну во-первых это только один из вариантов, и сейчас так обычно _не_
> делают (например, потому, что надо ограничить доступ к SMM памяти...
> но это ещё один костыль). Мапят кусок отдельно, да, но доступ дают
> только к этому небольшому участку. В любом случае, не стараются
> контроллеру задать много работы, он просто не успеет.

Т.е. мапят не всю планку памяти, а только вот те полмегабайта?
Так тоже не намного лучше...
А ход конем с HSEG (области, доступной только из SMM-режима CPU),
вернее, с перемапливанием ее в область из первого мегабайта -
тоже так себе идея...

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

Сама непрерывность - не вопрос.
Был бы набор физической памяти, plainly отображенный в системную,
с выпавшими отдельными кусками - это одно дело.
Но тут еще: 
1) перемап адресов 0xFEEA_0000h-0xFEEB_FFFF в 0x000A_0000h-0x000B_FFFF (HSEG).
2) дублирование "имеджа" (или его части) физической планки памяти,
и сдвиг в адресном пространстве другой планки (физическая и системная
память перестают совпадать по адресам).
Т.е. кроме недоступных областей имеем "искривление пространства" двух типов.
Конечно, при корректной прошивке контроллера/ов памяти все это
скрывается от системы, и ей все равно, но такая схема потенциально
более error-prone, и. в случае чего, ее сложней дебажить.

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

Хм. А вот тут не вижу проблемы - обучить контроллеры распределять
подобные наборы CPU/памяти. Вроде бы вполне рядовая задача.