Board.KolibriOS.org

Не понятно, почему завис ASRock M3A770DE. Хороший лог, правильный devices.dat. Какие-то особенности включения APIC на AMD ? Буду разбираться.

Make sure IOAPIC ID > highest LAPIC ID. Непохоже что в файле kernel/branches/Kolibri-acpi/core/apic.inc вы об этом заботитесь.

ilya
А подробнее можно ?

Подробнее сложно. Есть догадки после прочтения главы 10 интеловских доков.
Похоже что все прерывания(IPIs,SMI,Fixed,...) проходят по одному проводу(шине). Нужно как то различать не только их но и отправителя. Я так понимаю делается по ID. Если ioapic_id_0 шлёт прерывание cpu_id_0 то процессор может подумать что послал прерывание сам себе. Некоторые матери/BIOSы ксати ставят IOAPIC ID в 0.
А то что ioapic_id > больший lapic_id связано как то с приоритетами.

Такой вот текстик имеется в MP Specification 1.4(глава 3.6.6):
Я конечно знаю что этот документ давно не в ходу. Но многие не ноутбучные матери всё ещё поставляются с MP Table. В добавок от того что стандарт перешёл в статус 'deprecated' не означает что произодство железа поменяется. Ну и всегда есть старое железо.

ilya
Спасибо.

Классно! Проверю вечером.
Собственно поддержка APIC делалась с целью запуска SMP, можно попробовать, но с оглядкой на проблемы с прерываниями.

Объясните тупому деревенскому программисту - как будет использоваться SMP если планировщик и остальное на это не рассчитано?

Mario ну Just for fun же!
Первая хотелка - хоть как то запустить Ну а там терпения хватит - доделаешь(ю), не хватит - доделают другие. Можно конечно заранее договариваться, как лучше и что надо - но у нас это не очень получается, поэтому надо просто брать и делать, хотя бы ради интереса. К тому же там не сложно, а кто то повис на этом, будет толчек.

Запустить AP дело совсем нехитрое. Для каждого процессора надо свой TSS и соответствующий дескриптор TSS в gdt. Ещё потребуется tls для хранения локальных данных - fpu_owner и т.п. Это обычно делается через создание сегмента с ненулевой базой и адресацией через gs или fs. tss обычно входит в этот сегмент как часть локальных данных процессора.

АПИК можно включить, но мне кажется чтобы сделать нормальный доступ к процам нужно переписать половину оси, или начать её с нуля и перенести туда все готовые функции после отработки работы с несколькими процами, я писал название книги где то в темах в которой есть пример включения апика настройки прерываний таймера и клавы, и работы с несколькими процами. Там написано, что нужно делать семафоры для проверки того, чтобы два проца не писали в один и тот же байт, мне кажется этого делать не надо, а надо думать как чтоб такого небыло.

А единственный правильный путь -- выкинуть вообще всё сделанное и разрабатывать с нуля, причём не сохранять совместимость со старым на уровне API (поскольку этот самый API, доставшийся в наследство от Менуэта -- сплошной идиотизм). Естественно, сразу сделать систему не только с поддержкой SMP, но и 64-разрядной, с виртуальной памятью, PnP, ACPI... Ну а если так хочется сохранить возможность запуска имеющихся программ, слепить прослойку, поддерживающую выполнение прикладного 32-разрядного кода со старым API на новой 64-разрядной системе.

АПИК и без 64битности не плох, главное чтобы была поддержка многопроцессорности и комп без апика работает не на полную мощность, а только один проц, остольные без апика не включить.

Стас, в нынешнем виде КОС -- свалка костылей, появившися в первую очередь из-за шедеврально талантливого проекта Вилле. Чтобы внедрить что-то новое, надо либо городить очередную порцию костылей, либо переделывать всё с нуля и самым кардинальным образом. Но если уж идти вторым путём, то надо закладывать сразу всё, а не только какие-то части. Другое дело, что реализовать это "всё" сразу не удастся -- но если не предусматривать такую возможность, то в дальнейшем без костылей опять-таки не обойтись.

Ну а не использовать те же 64 бита -- это делать систему вчерашнего дня, что заведомо бесперспективно. Понятно, что в качестве хобби, для собственного удовольствия, можно делать что угодно и как угодно. Но ведь КОСовцы постоянно говорят о реальном использовании системы как минимум совместно, а то и вместо "настоящих" систем (читай -- Винды), а тогда надо сразу работать на перспективу, а не так, как проще-удобней-интересней и т.д.

Враньё

Нет.
Прогресс может (и должен!) идти поэтапно, с полным сохранением живучести всей системы.

Похерить всё что работает, и не построить ничего.

Колибри развивалась и продолжает развиваться усилиями нескольких упёртых энтузиастов, каждый из которых реально использует ее для каких-то вполне реальных задач.
У каждого из разработчиков - работа, учеба, семья и куча своих проблем.
И тем не менее развитие, тестирование, эксперименты, дискуссии не останавливаются ни на один день!

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