Обсуждение необходимости ACPI

Kernel architecture questions
  • dzavalishin wrote:Короче, я, тем временем, впаял вчерне acpica в Фантом. Не очень это трудоемко. заморочка была только с mem map, но и она легко обходится. Так что если кто захочет повторить для колибри - можно сдуть оттуда.

    ps: объем исходников, которые потребовалось написать, меньше объема переписки в этом треде в разы. :)
    1. видимо очень вчерне, т.к. списки типа "Table 5-67 Predefined ACPI Names" и др. вещи занимают места порядочно только учитывая StringОвые их представления.
    2. сдуть откуда не указано, означает "кошки-мышки"?
    3. не сказано, что от этого получено в принципе. Т.е. практически?!
    Через SMBus уже "притушили" потребление хоть какого нить устройства? Осмотрели аккумулятор, как он там? Или допустим DMA ресурсы (DMA Remapping Table) удалось заюзать, а вот ранее никак не удавалось у Вас?
  • CleverMouse wrote:VaStaNi, вы сами себе противоречите. ACPI - это отнюдь не только список устройств с используемыми ресурсами. ACPI - это в первую очередь средство, позволяющее операционной системе сказать железу "здравствуй, я современная операционная система, знающая, как обрабатывать всевозможные срочные события, и о них нужно рассказывать мне, а не SMI". ACPI придуман именно для того, чтобы избавиться от SMI
    Мышончик, как это избавиться?
    Он же на нем (не ней) "сидит"?
    Без SMI не будет SMBUS, без SMBUS не будет BIOS "любимых фич"............
    CleverMouse wrote:поэтому acpica столь велика, собственно разбор таблиц и получение списка устройств - это ерунда, основная сложность в куче новых событий, которые нужно обрабатывать. Так что, по вашей же логике, вы должны повсеместно агитировать за использование ACPI.
    Событий? Аппаратных и просроченных? (Чипсеты и их "крутость" BIOS реализаций разная встречается, кто плавал - тот занет о чем я).
    С задержкой в миллисекунды и с дополнительной буферной опухолью API ACPI? Нафиг.
    Для ОС, которая нужна для работы с текстом и иконки рисовать и в контактах дебильствовать - да, все равно и даже нужно! :mrgreen:
    Но не для всех или не в чистом виде, я бы так сказал!
    ACPIем можно попользоваться раз, два, три с целью поиметь и поднастроить и.... ВЫКЛЮЧИТЬ SMI в конце концов!!!!
    Особенно, если это необходимо по сути режима режима использования ОС, так сказать (типа ОС применибельности на объекте, по факту установки и настройки ОС, пусть администратором).
    Почему пользователь не должен иметь права выбора (это так и есть сейчас!)
    юзать ему ACPI или нет,
    SMI урода выключить или нет?
    Я за альтернативы и против теневых механизмов, закладок!
    Или, как там ты говоришь, за универсальное решение ОС возможностей! Так да?
    Для этого перво наперво надо уметь выключить SMI механизм (обработчик) и.... подставить свой.
    Или вообще просто выключить. Мне пока этого достаточно.
    Все равно ведь надо писать драйвера!
    ОСь без драйверов это поделка.
    Драйвера - это умение (как можно профессиональнее и эффективнее, а значит очень глубоко пухнуть мозгами. И на фоне этого 1-5% больше изучить в пользу сказанного, это мелочи) владеть чипами,
    чипы это доки и желательно примеры к ним или сорцы.
    А тут вот то и возникают вопрс(ы) по чипсетам и ДОКИ!!!!!
    Неужели это нелогично, противоречит самому себе, CleverMouse?
  • Для справки.
    (Если я не прав и Вы в этом уверены, просьба поправить с указанием аргументов и материала. Заранее спасибо!)
    Основная "работа" SMI (как воздействие на что либо) запускается посредством командного порта (мне попадались лишь два 0xB2 и 0xB0). Любопытным (помимо лазанья в BIOS) увидеть его можно так:
    Attachments
    smi_command_port.png
    smi_command_port.png (52.88 KiB)
    Viewed 8491 times
  • В доках на ACPI встречается его сокращенное название SMI_CMD.
    Вот наглядная картиночка про мечту некоторых, а именно управление питанием и потреблением:
    Attachments
    ACPI_Sleeping_States.png
    ACPI_Sleeping_States.png (7.81 KiB)
    Viewed 8489 times
  • Поскольку передать параметры (команду) в SMM "проблемно", в силу архитектурно-принципиальных отличий режима, то SMI_CMD, как бы почтовый тоннель в обработчик SMI.
    Если, допустим порт SMI_CMD = 0xB2, то поместив туда заветный код (или ряд "осмысленных засланий кодов", как этапы воздействия) можно "сказать" обработчику SMI что ему надо сделать с оборудованием или что выдернуть из него.
    Коды эти (байтовые), насколько я понял получаем посредством AML. А его кушает (опять же я так понял) API ACPI.

    Другое дело таблицы ACPI, как данные (пусть даже абстрактные), которыми можно воспользоваться, как детали текущей BIOS настройки, конкретного чипсета, в данный момент.
    Предпочту воспользоваться этими таблицами, так массивом данных именно на стадии "разворот и тюнинг ядра", т.е. до активации IDT, GDT, PM. Думаю понятно почему.
    Добираться как до них, давал ссылку, кажется XVilka тут пример неплохой, т.к. проливает свет на DSDT.

    Все бы ничего, если бы не папуасский код SMI обработчика.
    Что я так распинаюсь и так долго, да? Надоело? (Читать и думать не заставляю. Каждому своё! Факт!)
    Ну смотрите сами, что мы имеем при попытке получать кванты, да и вообще использовать (в DOS тоже!) замеры чего либо по оси времени при помощи IRQ0, факты иллюстрирующие "работу" ECX+LOOP в папуасском коде (chipset I815, Celoron~1,45ГГЦ):
    Attachments
    IRQ0_GA8I915.png
    IRQ0_GA8I915.png (12.26 KiB)
    Viewed 8481 times
    Last edited by VaStaNi on Wed Oct 05, 2011 2:42 pm, edited 3 times in total.
  • VaStaNi
    Если тебе нужна система в чистом виде поступай как art_zh, проектируй свою собственную плату, или ищи подходящие промышленные варианты. Современная бытовая материнка да ещё в каком-нибудь Deluxe варианте утыкана разными датчиками, занимается саморазгоном и следит за всем и вся. Это маркетинговый продукт под определённую категорию потребителей. Если ты не в этой категории так и ищи себе продукт в своей нише.
  • P.S.
    тестовый код ничего не делает вообще.
    Т.е. только крутится короткий почти пустой обработчик IRQ0 и каждый в тике,
    запоминаются в массив значения проца rdtsc.
    Затем массив импорт в Exel и лупим эту статистику для наглядности.
    Когда увидел первый раз - у меня был шок (давненько это было), затем понял где и почему у меня плавало и ошибалось при попытках организовать периодически стабильные замеры, родить прогу.......
    Многие (да и тут слышно и не раз) говорят, что дескать PC архитектура не предназначена для.......... в том числе и РВ, ЖРВ....
    А я говорю - уберите мне SMI! Выключите в BIOS этого урода, и будет все ОК!
    Мой аватар имхо!
  • Serge, вот если бы ты поюзал промварианты, где ситуация 1:1 материнкам из офиса, и сказал, что они сссссукииии! Какой нить AWARD 6.0 без малейшего нюанса туда зашили и развели плату, тогда я бы на тя посмотрел.
    Сделать свое? Найти купить спец, под.... для....????
    Денег дашь? :D
    Скажи где и как их взять, дураку?
    А может выкл. SMI проще, дешевле, универсальнее?
    К тому же уметь = владеть.
    Не уметь = заложник.
    Имхо.
  • VaStaNi
    1.По твоему графику я бы сказал что встроенный 8254 даёт очень маленький разброс. Какие у него паспортные параметры ? Или ты используешь HPET ? Кстати проверка с HPET намного интересней. Можно точно измерить латентность обработчика. Ещё лучше проверять с использованием таймера LAPIC. Считаем латентность с точностью до нескольких тактов и не беспокоимся о точности системного таймера
    2.Не факт что бытовая плата вообще может без SMM работать. Там же термодатчики, управление вентиляторами и прочая хрень.

    Update.
    Максимальные отклонения примерно 1000 тактов. При среднем значении 1 455 800 тактов это даёт 0,067%. Заявленная точность HPET на интервале от 1 миллисекунды 0.05%.
  • по п.2 это ты преувеличиваешь. Разве, что питающие напруги проверяет и то вопрос чипсетозависимый.

    по п.1
    Эт ты куда то не туда и слишком далеко и сразу. :D
    Там все просто на самом деле было и без всяких новомодных ухищрений и технологий HPET, LAPIC...
    Оно там и не надо в принципе исходя из цели.
    Прога была под дос, простая как бревно.
    Маской задавлены все прерывания кроме irq0.
    Собственно "весь временной ресурс CPU" или как раньше говаривали машинное время проца должно приходиться на паузы между irq0 обработкой.
    Т.к. irq0 оно самое, самое приоритерное и на нем стоит типа в ОСях переключатель задач + замеры, кванты и т.д. - ему мешать никто не должен.
    Но это не так по факту, получается!

    Если нужно по полочкам то план типа такой был:
    1. разобраться, как влияет SMI на работу IRQ0 в плане равноценности квантов irq0.
    Создать среду измерений, маскимально чистую и без существенной погрешности.
    Обработчик максимально короткий по тактам, чтобы "чувствительность" к дрожанию интервалов тактов была высокой.
    2. какие кванты выбирать, что более подвержено искажению
    3. есть ли синхронность тактов или псевдотактов этих механизмов, возможно ли синхронизировать, дабы SMI попадал всегда вовнутрь IRQ0.
    4. реально увидеть отложенность аппаратных прерываний по сути
    5. научиться выключать SMI и произвести замеры без него в принципе
    6. подмена SMI обработчика на свой и включение в работу
    (интел для этого, особенно старый самая клёвая вешь.На wasmЕ про это терли очень хорошо ник:_BC_)
    Где то так.

    Картинку выше поправил, т.к. это у меня завалялась от чипсета 815 интел.
    Там не про точность суть, а то сколько тактов пожирает SMI варварским кодом по отношению к аппаратным событиям чипсета, при замерах кулеров, напруг, температуры.
    И конкретно, как это оттягивает следующий программный квант таймера...
    Как это выглядит и на каких чипсетах и т.д.....

    Ведь наглядно видно, что есть нечто среднее в тиках, как большинство.
    И их некоторый разброс можно принять (для сомоуспокоения, типа что не все так плохо) за погрешность умножителя, например, чет -нечет..., кварца таймера... и то с натяжкой, а вот серьезные выпады вверх и вниз - это и есть раковая опухоль!
    Причем это броуновское движение :evil:, а не периодичность, млин!
    Сплошной набег фаз на лицо + уродские wait при работе с шиной SMBus внутри SMI обработчика, когда он вытаскивает эти самые показания приборов температуры, оборотов.... или еще что нить рулит им. Чем больше этим проц ТАМ озадачен, например рост температуры, тем больше сожрал тактов на waitах, тем позднее ФАКТИЧЕСКИ пройдет IRQ0 на проц!
    Витиеватости папуаскода + вендоробезобразия в совокупности определяют то, что есть
    машина более менее, есть так себе, а есть вообще никуда не годящиеся хромоножки-склеротики от рожденья!
    А потом несведующий народ до одури спорит, что у него дескать прога так замерила, а у него так и кто прав и как потанцевать с бубном, чтобы было хоть ка то прилично в плане замеров... или работало стабильно некое управляющее чудо или скоростное стробоскопическое что нить типа программный оссцилл, это уже не важно.
    Главное то, что ничего может не выйти из этого, как ни программируй.
    А сколько хаос показаний-замеров крови может попить некоторым это ваще.

    Вот еще красота полюбоваться и помедитировать для пытливых.
    Даю ребусы загадки-отгадки на все вышесказанное, найти стописят отличий, типа. :P
    Картиночки двух разных машин двух разных поколений, правда опять гигабайтовские интелы оба.
    GA-I915 (лет 7 ей с роду) 3ГГц, пень 4.
    Attachments
    I915_01.png
    I915_01.png (20.34 KiB)
    Viewed 8407 times
    I915_02.png
    I915_02.png (26.84 KiB)
    Viewed 8407 times
  • GA-P55 относительно свеженький. 3,2ГГц, Intel Core I5
    Attachments
    ga-p55_1.png
    ga-p55_1.png (28.28 KiB)
    Viewed 8406 times
    ga-p55_2.png
    ga-p55_2.png (32.65 KiB)
    Viewed 8406 times
  • Раз уж ОПЯТЬ пошла такая возня с этим ACPI, решил сам поднять свои черновички по этому вопросу, тем более, что именно выключить SMI в моих потугах тогда так и не вышло.
    Есть надега на ACPI: SMI_Enable, SMI_Disable.
    Это дело там присутствует, надо попробовать будет.
    Пока потрошу ихненные таблицы убогие. Мутняк. Плюс на каждой машине "своя картина".
    Там есть эта таблица и эти данные, а там нет вовсе.... Каша.
    Это говорить хорошо и мечтать об универсальности, о новых свойствах....
    А кто конкретно из уважаемой публики добрался хоть до какого нить массива параметров в ACPI?
    Кто достиг чего???
    Завалишин не в счет.
    С кем общаться по сабжу, так сказать? Хочу знать, ведь может кто то созрел таки.
  • Давно хочу спросить, и тебе не впадло столько писать каждый раз? :)
    Из хаоса в космос
  • Наверное не впадло, иногда. Иногда зависит от многого, начиная от настроения и вдохновения, заканчивая словом нужно.
    Прикинь, некоторые люди бывают, что пишут целые книги и даже их переписывают наново иногда. Мало того, в рукопашную ведь было раньше.
  • Who is online

    Users browsing this forum: No registered users and 2 guests