Page 10 of 12

Re: APIC

Posted: Sun Sep 25, 2011 12:40 am
by Serge
Не понятно, почему завис ASRock M3A770DE. Хороший лог, правильный devices.dat. Какие-то особенности включения APIC на AMD ? Буду разбираться.

Re: APIC

Posted: Mon Sep 26, 2011 9:55 pm
by ilya
Serge wrote:Не понятно, почему завис ASRock M3A770DE. Хороший лог, правильный devices.dat. Какие-то особенности включения APIC на AMD ? Буду разбираться.
Make sure IOAPIC ID > highest LAPIC ID. Непохоже что в файле kernel/branches/Kolibri-acpi/core/apic.inc вы об этом заботитесь.

Re: APIC

Posted: Tue Sep 27, 2011 1:08 am
by Serge
ilya
А подробнее можно ?

Re: APIC

Posted: Tue Sep 27, 2011 2:17 am
by 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):
The ID of each I/O APIC unit is set to zero during RESET. It is the responsibility of the operating system to verify the uniqueness of the I/O APIC ID and to assign a unique ID if a conflict is found. The assignment of APIC IDs for I/O units must always begin from the lowest number that is possible after the assignment of local APIC IDs. The operating system must not attempt to change the ID of an APIC I/O unit if the preset ID number is acceptable.
Я конечно знаю что этот документ давно не в ходу. Но многие не ноутбучные матери всё ещё поставляются с MP Table. В добавок от того что стандарт перешёл в статус 'deprecated' не означает что произодство железа поменяется. Ну и всегда есть старое железо.

Re: APIC

Posted: Tue Sep 27, 2011 8:44 am
by Serge
ilya
Спасибо.

Re: APIC

Posted: Tue Sep 27, 2011 1:40 pm
by Ghost
Классно! Проверю вечером.
Собственно поддержка APIC делалась с целью запуска SMP, можно попробовать, но с оглядкой на проблемы с прерываниями.

Re: APIC

Posted: Tue Sep 27, 2011 1:42 pm
by Mario
Объясните тупому деревенскому программисту - как будет использоваться SMP если планировщик и остальное на это не рассчитано?

Re: APIC

Posted: Tue Sep 27, 2011 3:06 pm
by Ghost
Mario ну Just for fun же!
Первая хотелка - хоть как то запустить :) Ну а там терпения хватит - доделаешь(ю), не хватит - доделают другие. Можно конечно заранее договариваться, как лучше и что надо - но у нас это не очень получается, поэтому надо просто брать и делать, хотя бы ради интереса. К тому же там не сложно, а кто то повис на этом, будет толчек.

Re: APIC

Posted: Tue Sep 27, 2011 3:47 pm
by Serge
Запустить AP дело совсем нехитрое. Для каждого процессора надо свой TSS и соответствующий дескриптор TSS в gdt. Ещё потребуется tls для хранения локальных данных - fpu_owner и т.п. Это обычно делается через создание сегмента с ненулевой базой и адресацией через gs или fs. tss обычно входит в этот сегмент как часть локальных данных процессора.

Re: APIC

Posted: Sat Mar 24, 2012 8:19 am
by Стас
АПИК можно включить, но мне кажется чтобы сделать нормальный доступ к процам нужно переписать половину оси, или начать её с нуля и перенести туда все готовые функции после отработки работы с несколькими процами, я писал название книги где то в темах в которой есть пример включения апика настройки прерываний таймера и клавы, и работы с несколькими процами. Там написано, что нужно делать семафоры для проверки того, чтобы два проца не писали в один и тот же байт, мне кажется этого делать не надо, а надо думать как чтоб такого небыло.

Re: APIC

Posted: Sat Mar 24, 2012 12:06 pm
by SII
Стас wrote:АПИК можно включить, но мне кажется чтобы сделать нормальный доступ к процам нужно переписать половину оси, или начать её с нуля и перенести туда все готовые функции после отработки работы с несколькими процами
А единственный правильный путь -- выкинуть вообще всё сделанное и разрабатывать с нуля, причём не сохранять совместимость со старым на уровне API (поскольку этот самый API, доставшийся в наследство от Менуэта -- сплошной идиотизм). Естественно, сразу сделать систему не только с поддержкой SMP, но и 64-разрядной, с виртуальной памятью, PnP, ACPI... Ну а если так хочется сохранить возможность запуска имеющихся программ, слепить прослойку, поддерживающую выполнение прикладного 32-разрядного кода со старым API на новой 64-разрядной системе.

Re: APIC

Posted: Sat Mar 24, 2012 12:11 pm
by Стас
АПИК и без 64битности не плох, главное чтобы была поддержка многопроцессорности и комп без апика работает не на полную мощность, а только один проц, остольные без апика не включить.

Re: APIC

Posted: Sat Mar 24, 2012 12:25 pm
by SII
Стас, в нынешнем виде КОС -- свалка костылей, появившися в первую очередь из-за шедеврально талантливого проекта Вилле. Чтобы внедрить что-то новое, надо либо городить очередную порцию костылей, либо переделывать всё с нуля и самым кардинальным образом. Но если уж идти вторым путём, то надо закладывать сразу всё, а не только какие-то части. Другое дело, что реализовать это "всё" сразу не удастся -- но если не предусматривать такую возможность, то в дальнейшем без костылей опять-таки не обойтись.

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

Re: APIC

Posted: Sat Mar 24, 2012 1:04 pm
by art_zh
SII wrote:в нынешнем виде КОС -- свалка костылей...
Враньё :evil: :evil:
SII wrote:Чтобы внедрить что-то новое, надо либо городить очередную порцию костылей, либо переделывать всё с нуля и самым кардинальным образом.
Нет.
Прогресс может (и должен!) идти поэтапно, с полным сохранением живучести всей системы.
SII wrote:Но если уж идти вторым путём, то надо закладывать сразу всё, а не только какие-то части. Другое дело, что реализовать это "всё" сразу не удастся -- но если не предусматривать такую возможность, то в дальнейшем без костылей опять-таки не обойтись.
Похерить всё что работает, и не построить ничего.
Ну а не использовать те же 64 бита -- это делать систему вчерашнего дня, что заведомо бесперспективно. Понятно, что в качестве хобби, для собственного удовольствия, можно делать что угодно и как угодно. Но ведь КОСовцы постоянно говорят о реальном использовании системы как минимум совместно, а то и вместо "настоящих" систем (читай -- Винды), а тогда надо сразу работать на перспективу, а не так, как проще-удобней-интересней и т.д.
Колибри развивалась и продолжает развиваться усилиями нескольких упёртых энтузиастов, каждый из которых реально использует ее для каких-то вполне реальных задач.
У каждого из разработчиков - работа, учеба, семья и куча своих проблем.
И тем не менее развитие, тестирование, эксперименты, дискуссии не останавливаются ни на один день!

Re: APIC

Posted: Sat Mar 24, 2012 1:05 pm
by Стас
Я и говорю, что добавление многоядерности без переписки оси почти невозможно, а по поводу 64битности считаю не настолько необходимой. Возможности 4гигов оперативной памяти ещё долго не раскоют, приложений нету даже у винды нуждающихся в ней, хотя она оперативку засерает не слабо. Колибри не засерает так сильно оперативку и это её плюс и если былабы дописаны офисные проги браузер, апик и многоядерность то смотрелась бы выгоднее винды. Размер меньше, установка проще и т.д. .