2 января 2022 г., 16:22, "Valentin Nechayev" <ne...@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/памяти. Вроде бы вполне рядовая задача. _______________________________________________ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd