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

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

    ps: объем исходников, которые потребовалось написать, меньше объема переписки в этом треде в разы. :)
    1. видимо очень вчерне, т.к. списки типа "Table 5-67 Predefined ACPI Names" и др. вещи занимают места порядочно только учитывая StringОвые их представления.
    2. сдуть откуда не указано, означает "кошки-мышки"?
    3. не сказано, что от этого получено в принципе. Т.е. практически?!
    Через SMBus уже "притушили" потребление хоть какого нить устройства? Осмотрели аккумулятор, как он там? Или допустим DMA ресурсы (DMA Remapping Table) удалось заюзать, а вот ранее никак не удавалось у Вас?
    Вчерне: подключил, инициализировал, сдампил дерево объектов, подключил ребут и павер офф.
    Сдуть: http://code.google.com/p/phantomuserlan ... ail?r=1228
    Зачем: повер офф, таблицы для SMP/APIC (до того они тоже были, но из устаревших источников), остальное - по мере необходимости.

    Я, честно говоря, даже не вижу предмета для обсуждения тут: ACPI заявлен как основной интерфейс для этих машин - зачем эту ветряную мельницу бороть?

    Кстати - а почему Int0, а не APIC timer interrupt?
  • Serge wrote:VaStaNi
    Твои графики ничего не доказывают. Точность HPET 0.05%. Это +- 750 тактов для 1.5Ггц процессора. Точность 8254 ведома только Интелу. А разброс частоты у процессора ?
    Ты же не хочешь сказать что у тебя в чипсете идеальный таймер и идеальный процессор в сокете ? Если хочешь точно считать такты используй таймер LAPIC. А пока все эти замеры ничего не доказывают. Ты микрометры меряешь школьной линейкой.
    Очень жаль, что ты ничего не понял.
    Но я устал. И у меня мало времени.
    Устал от людского непонимания в том числе. У меня такое впечатление, порой, что я живу не в том временном периоде, не в той стране, не с теми людьми общаюсь...
    Короче, если ты напишешь почему я так думаю, каковы аргументы, я продолжу выводы, факты, куда нужно смотреть и какова, собственно линейка и где...
    Я не повышаю планку уровня общения, просто у меня порой бывают проблемные личностные обстоятельства, которые могут наложиться на процесс общения с кем либо и ты тут ни при причем.
    Так что без обид. Мало того, я могу пропасть на... прой N месяцев.
    Это не пренебрежение и не ненависть, это моя жизнь, как она есть. Писать об этом я не буду.
    dzavalishin wrote:Кстати - а почему Int0, а не APIC timer interrupt?
    есть такой метод для проведения анализа и оценок, метод приведения, метод равнозначных условий в первом и втором случае.
    Так вот, поскольку для тех вещей, что я писал и "примерял" - исконно, обычно, как правило, в больштнсте случаев...
    юзается именно это , т.е. Int0,
    то заюзано именно это.
    Это своего рода "общий знаменатель" для сравнения двух случаев.
    Именно так и таким образом можно искать корни своей проблемы,
    когда она нетривиальна, требует глубинного теста и анализа,
    меня так учили, мне так удавалось находить истину и решение, я так умею в конце концов, я в этом методе уверен.
  • art_zh, "Если бы полтора года назад существовала "прямая" ветка Колибри для Intel Atom, то я бы обязательно к ней присоединился." - кто сказал Atom? Я прямо сейчас сижу за ноутбуком с Intel Core i5, у Serge, вполне вероятно, более почтенный по возрасту чипсет. Сейчас мало кто может протестировать то, что делаешь ты, следовательно, маловероятно, что ты смог бы включиться в Kolibri-I. Более того, над Kolibri-I работало бы столько же ядерщиков, сколько сейчас работают над Kolibri-A, со всеми последствиями для системы.

    VaStaNi, "Без SMI не будет SMBUS" - общего у SMI и SMBUS только две буквы с расшифровками в аббревиатуре. В контексте ACPI, между прочим, можно заметить, что для SMBus есть полностью документированный метод работы через ACPI - http://smbus.org/specs/smbus_cmi10.pdf - хотя я не в курсе распространённости его в реальных ACPI-таблицах, а не в документации.
    "Или вообще просто выключить. Мне пока этого достаточно." - нельзя просто выключить, не предложив ничего взамен. Ладно ещё, если перестанет работать мышка, - пользователя, конечно, не слишком обрадует сообщение "КрутаяОС обнаружила, что ваша мышка обрабатывается кривым способом. Возрадуйтесь, КрутаяОС выключила этот способ, теперь ваша мышка не мешает КрутойОС. Ну а если вы хотите использовать мышку в КрутойОС, тогда бегом в магазин за компьютером с PS/2-разъёмом для мышки и переходником", но вас обычные пользователи явно не интересуют. Но что, если после выключения обнаружится, что где-то снаружи включился обогреватель, температура материнской платы растёт и через пару секунд будет критической, а сообщить она об этом не может, потому что SMI вы выключили, а про обычное прерывание SCI вы не в курсе? Гори она синим пламенем, что ли?
    Сделаем мир лучше!
  • VaStaNi, ответы по документации.
    "Основная "работа" SMI (как воздействие на что либо) запускается посредством командного порта (мне попадались лишь два 0xB2 и 0xB0)" - да, но только частично. Так внешний код - обычно BIOS, которому понадобилось, к примеру, обработать int 13h для флешки - запускает обработчик SMI. Кроме того, обработчик SMI может вызвать, к примеру, датчик с материнской платы, и именно это - его основное применение.

    "В доках на ACPI встречается его сокращенное название SMI_CMD." - да.

    "Если, допустим порт SMI_CMD = 0xB2, то поместив туда заветный код (или ряд "осмысленных засланий кодов", как этапы воздействия) можно "сказать" обработчику SMI что ему надо сделать с оборудованием или что выдернуть из него.
    Коды эти (байтовые), насколько я понял получаем посредством AML. А его кушает (опять же я так понял) API ACPI." - нет, это полностью неверно. В ACPI есть ровно две команды по взаимодействию со SMI - это выключить его и включить его. После выключения абсолютно всё остальное делает сама ОС в лице разборщика таблиц и интерпретатора AML. Например, два типичных элемента таблицы DSDT: определить переменную ABCD, связанную с портом 1234h размером один байт - это в таблице; присвоить ABCD = 56h - это в коде AML. Соответственно, ОС при разборе таблиц запоминает ABCD=1234h в I/O пространстве, а потом транслирует код ABCD=56h в команду out 1234h, 56h - условно, естественно, - которую сама же и выполняет, без всяких SMI.

    "А кто конкретно из уважаемой публики добрался хоть до какого нить массива параметров в ACPI?" - diamond, автор кода выключения через ACPI в kernel.asm. Посмотреть, соответственно, можно в kernel.asm.
    Сделаем мир лучше!
  • Serge, про время выполнения и влияние SMI - это VaStaNi уже как минимум года три мусолит, ничего нового не открыл. Вот тут, например, обсуждение на васме трёхгодичной давности, там даже diamond измерял непосредственно число инструкций, и действительно на некоторых конфигурациях эпизодически появляются лишние выполненные инструкции.
    Сделаем мир лучше!
  • Я охотно верю что такие лишние инструкции есть. Но я не увидел их в этих замерах. Нестабильность тактового генератора системного таймера накладывается на нестабильность тактового генератора процессора и даёт искомый разброс. Я не знаю как сильно плавает частота, может art_zh подскажет. Но если для HPET гарантируется 0.05% на миллисекундном интервале, то и для процессора будет что-то похожее. На всех графиках отклонения укладываются в эти предположительные 0.1%
    Если требуется измерить латентность обработчика и поймать лаг от SMM надо использовать совсем другой метод. Запрограммировать таймер LAPIC на периодические прерывания через определённое количество тактов. В обработчике прерываний считывать текущее значение счётчика тактов LAPIC. С учётом делителя частоты разница между инициирующим значением и считанным даст латентность обработчика.

    А вот diamond действительно замерил лаг от SMM.
  • CleverMouse wrote:art_zh, "Если бы полтора года назад существовала "прямая" ветка Колибри для Intel Atom, то я бы обязательно к ней присоединился." - кто сказал Atom?
    Атом - до сих пор самая распространенная платформа для дешевой PC-встроенки. Очень нужна встраиваемая Колибри, и не мне одному.
    CleverMouse wrote:Я прямо сейчас сижу за ноутбуком с Intel Core i5, у Serge, вполне вероятно, более почтенный по возрасту чипсет. Сейчас мало кто может протестировать то, что делаешь ты, следовательно, маловероятно, что ты смог бы включиться в Kolibri-I. Более того, над Kolibri-I работало бы столько же ядерщиков, сколько сейчас работают над Kolibri-A, со всеми последствиями для системы.
    - в этой конструкции "следовательно" ниоткуда не следует. И ничего логически ни с чем не связывает. Мимо.

    UPD: С выходом Fusion интерес к Атомам поостыл, особенно перспективны новые APU в "тонких" клиентах и медийных терминалах. Так что свой выбор считаю удачным.
    Очень надеюсь, что ядерщиков в А-версии будет больше. Понимаю, что это чисто финансовый вопрос, но решить его "прям щас" не могу.

    Serge
    Везде используется схема фазовой автоподстройки частоты (ФАПЧ или PLL), завязанная на внешний кварцевый резонатор.
    Центральное облако точек VaStaNi очень похоже на ФАПЧ-дрейф, реально не превышающий сотен пикосекунд на 10MHz (~0.1%).
    Учти что на графиках измерения усреднены по тысячам "автоподстроенных" периодов, то есть можно ожидать разброса ~0.001%.

    Отдельные резкие выбросы, четко заметные на всех графиках, для ФАПЧ не характерны.
    Со SMI пока не возился, спорить ни с кем не хочу.
  • Хорошо. Если средний разброс между соседними импульсами irq0 не превышает ~0.001% выбросы в 1000 тактов объяснить сложнее. Конечно надо ещё учитывать то, что прерывания теперь доставляются через процессорную шину и она тоже вносит свою погрешность. Поэтому самым точным методом поиска SMM будет таймер LAPIC + счётчик исполненных инструкций как у diamond-а.
    Все мои претензии к VaStaNi касаются неудачного выбора способа измерений.
  • Ладно, попробую развернуть факты лицом другим манером.
    Я спорить не хочу, но я за истину и факты и четкое понимание сути явлений.
    Надеюсь на этом закончим с этим делом.

    Если предположить, что классические вещи типа int0(irq0) очень нестабильны, как это предположил Serge, тогда непонятно, как объяснить обратное - его стабильность???
    Я имею ввиду то, что если присмотреться, то получается есть достаточно длительные интервалы времени, когда все стабильно, причем весьма!
    Весьма настолько, что "такты лежат" на одной линии, на четкой горизонтальной полке!
    На картиночке про 915 это характерно видно, ниже даю укрупненный характерный кусок с выбросом для созерцания и медитации. :D Макс точка выброса вверх - отсчет №4310 в массиве отсчетов.

    Остается непонятным и необъяснимым, с точки зрения поверхностных, книжечных знаний о PC, почему вдруг точность ухудшается в некоторые моменты времени, причем аж на 2000, 3000 тактов процессора...?
    И еще. Эти моменты имеют как бы "четкий рисунок" на оси времени и похоже даже свою периодичность жизни...
    Все знают (из книженок), что на всех машинах есть int0 созданную еще в XT древности.
    Тогда еще недоумение - почему разные машины этот базовый, я бы сказал, механизм имеют настолько разный?
    Настолько некачественные кварцы? Настолько корявые или прогрессивные чипсеты? Настолько крива или хороша ФАПЧ??? Где больше погрешность таймера или период тактовой проца?
    А может все же:
    "линейка" и "микрометр" использованы верно и налицо потусторонняя жизнь :) процессора где то, куда то, зачем то...
    И тогда,
    сей простой и дубовый метод выявляют главный факт - отложенность аппаратных прерываний. Всех! Любых!
    Похер SMMy чем как и кто пользуется HPET, LAPIC...
    Он падла, сожрёт процессорного времени столько, сколько папуаскод потребует (фактический фрагмент кода выше был).
    Проц проваливается в нирвану почти хаотическим образом и главное безобразие в том, что:
    - ОС про это ничего не знает!
    - ОС на это никак не повлияет, не изменит сути явления, его масштаб и т.д.!
    - ОС предсказать ЭТО НЕ МОЖЕТ!
    ну это для тех, кому в ОСестроении не нужны дребезги исчисляемые тысячами тактов проца, конечно.
    Или для тех, кто четко хочет понимать, что достижимо в приложениях этой ОСи в плане равномерных временных вещей, "пульса", а что нет в принципе.

    Теперь эти типа экстремумы.
    ВСЕГДА рядом с большим выбросом есть УМЕНЬШЕННЫЙ соседний интервал.
    Объяснение одно - SMI максимально неблагоприятно наложился на край int0 и тем самым возможно, что полностью показался из тени!
    Тогда что такое тень?
    "Полная тень" в данном случае - когда обработка SMI полностью умещается в интервале int0.
    Вот тут то, в этом случае и лежат они "на полочке" ровненько ровненько, подрагивая видимо из за незначительных нестабильностей умножения, ФАПЧ, кварцев, набега двух фаз разного периода....

    Когда же он вылезает (значит irq0 выставлен, но проц занят SMM и на него не реагирует никак), то это и объясняет, почему вдруг интервал прерывания увеличился и рядом другая соcедняя цифра - обязательно уменьшилась.

    Как это выглядит изнутри (скептикам можно не читать).
    В SMI есть ветвления конечно в зависимости от причин, условий, показаний... ,
    поэтому процессорное время обработки меняется, а значит в некоторых случаях
    наложение причин приводят к макимальным затратам процессора (такты), максимальной "длине" кода обработчика.
    Допустим появился флаг, говорящий, что нужно кулер разогнать больше, т.к. порог температуры превышен.
    Значит, нужно дополнительно отправить по SMBus сетевому адресу nn, допустим 4 байта.
    SMBus шина очень медленная (это I2C по сути), особенно для современных процов.
    Папуасский код в угоду работы по медленной этой шине использует WAITы, что приводил выше, т.е. УБИВАЕТ полезное для нас, для ОСи процессорное время в тупейшим методом ECX+LOOP (грея проц между прочим)!
    А ведь надо охлаждаться то, да!? Порог ведь превышен. Здорово получается.
    LOOP это тебе не HLT.
    Но это я так, к слову для полноты, этим количеством разогрева можно пренебречь.
    Но это еще не все прелести.

    Размышляем, усугубляемся...
    Если вам "повезло" настолько, что на матери "запаяли", родили SMBus туповатый, медленный(а скорости там могут быть разными на порядок(и) ),
    а проц очень скоростной, то дабы SMBus работал правильно, без сбоев, нужно...
    Теперь внимание!
    Нужно, убить больше тактов проца методом ECX+LOOP!
    Быстрее процессор - больше его тормозим ECX+LOOP!
    Т.е. в ECX загружается бОльшая константа.
    Это естественно т.к. это жертва, чтобы выдержать во временной диаграмме работы шины выдержку ту же, допустим 100мкс.
    Худший случай с матерью (что можно сказать тоже, как неповезло), если производитель все барахло мониторинга задоровья, как раз на SMBus и навесил.
    Таким образом возьмем два одинаковых проца, но на разных матерях их "потустороняя жизнь" будет отличаться. Жаль я не работаю в фирмочке, где свинчивают и продают машинки(материнки) публике. Вот бы статистички где набрать...
    Attachments
    max01_delta_915.png
    max01_delta_915.png (15.44 KiB)
    Viewed 8351 times
  • Serge wrote:Поэтому самым точным методом поиска SMM будет таймер LAPIC + счётчик исполненных инструкций как у diamond-а.
    Все мои претензии к VaStaNi касаются неудачного выбора способа измерений.
    Претензии??? Именно так? Не сомнение, не неуверенность, а претензии. Гм. Странная реакция.
    Думаешь "чётчик исполненных инструкций" даст что то радикально иное?
  • Вопрос уже кажется начинает съезжать в финальную фазу любого спора, где есть только последний самый веский аргумент.
  • VaStaNi
    Именно претензия. У всех измерительных приборов есть погрешность измерения. Если у штангенциркуля точность 0.02мм им не измерить десятые микрометра.
    В твоей методике измерения погрешность вносят тактовый генератор RTC, тактовый генератор процессора и доставка прерывания по процессорной шине. Я предположил что суммой этих погрешностей можно объяснить скачки в измерениях. Если ты представишь расчёт максимальной погрешности измерения, скажем 0.002% или +- 300 тактов для 1.5Ггц на интервале в 1 миллисекунду будет видно с чем мы имеем дело. А пока это можно списывать на spread spectrum.
    diamond использовал встроенные счетчики производительности процессора. Это объективный механизм контроля и принципиально другой метод. Если в коде из 84 инструкций процессор периодически выполняет лишние 100-200-300 инструкций останется только посмотреть в errata и признать что процессор не спал на hlt а делал что-то ещё
  • Serge, к сожалению не могу продолжить дискуссию по нюансам SMI влияния, хотя очень хотелось "добить вопрос".
    Жизнь препоносит черные сюрпризы, большая часть суток уходит на "результаты" отечественой медицины и реанимации ближайших родственников...

    Но. Но, теоретически ведь данные замеры можно (а может даже нужно делать вообще без прерываний. Т.е. в глухом цикле, длина цикла известна и не может быть+- xx тактов. Тогда все что свыше фиксируем, складываем, анализируем)

    И еще.
    По поводу ACPI не в бровь а в глаз.
    Накропал несмотря на... ACPI выключалку.
    Заюзан AMLSCAN.INC из http://icbook.com.ua/press/acpi_switch_ ... y.html#lit

    Проблема с декодированием Package Length, который идет сразу за кодом 10h = SCOPE Operator в самом начале DSDT.
    Некоторые машины выключаются, некоторые нет. Ничего не пойму.
    Такое впечатление, что ACPI данные не все "одинаково полезны",
    вернее глючные константы могут быть или необходимы костыли обхода или версии ACPI
    могут давать неоднозначность (неуниверсальность подхода) данных в этих гребаных таблицах.

    Примеры.

    DSDT, что выключается и понятно почему AMLSCAN.INC позволяет найти _S5_
    первый скриншот,

    DSDT, что не выключается и имееющий странное занчение Package Length, второй.

    Кто может помочь добраться до истины?
    Прошу помощи асов ACPI. Plz. Дело принципа вроде.
    Attachments
    good Package Length.png
    good Package Length.png (13.74 KiB)
    Viewed 8246 times
    bad Package Length.png
    bad Package Length.png (12.9 KiB)
    Viewed 8246 times
  • О чем этот бред. Дока ACPI:
    19.2.4 Package Length Encoding

    PkgLength := PkgLeadByte |
    <PkgLeadByte ByteData> |
    <PkgLeadByte ByteData ByteData> |
    <PkgLeadByte ByteData ByteData ByteData>

    PkgLeadByte := <bit 7-6: ByteData count that follows (0-3)>
    <bit 5-4: Only used if PkgLength < 63>
    <bit 3-0: Least significant package length nybble>

    Note: The high 2 bits of the first byte reveal how many follow bytes are in the PkgLength. If the PkgLength has only one byte, bit 0 through 5 are used to encode the package length (in other words, values 0-63). If the package length value is more than 63, more than one byte must be used for the encoding in which case bit 4 and 5 of the PkgLeadByte are reserved and must be zero. If the multiple bytes encoding is used, bits 0-3 of the PkgLeadByte become the least significant 4 bits of the resulting package length value. The next ByteData will become the next least significant 8 bits of the resulting value and so on, up to 3 ByteData bytes. Thus, the maximum package length is 2**28.
    в файле других сорцов проекта ACPICA src файл aslcodegen.c
    имеется следующее:

    Code: Select all

    /* Does this opcode have an associated "PackageLength" field? */
    
        if (Op->Asl.CompileFlags & NODE_AML_PACKAGE)
        {
            if (Op->Asl.AmlPkgLenBytes == 1)
            {
                /* Simplest case -- no bytes to follow, just write the count */
    
                CgLocalWriteAmlData (Op, &PkgLen.LenBytes[0], 1);
            }
            else if (Op->Asl.AmlPkgLenBytes != 0)
            {
                /*
                 * Encode the "bytes to follow" in the first byte, top two bits.
                 * The low-order nybble of the length is in the bottom 4 bits
                 */
                PkgLenFirstByte = (UINT8)
                    (((UINT32) (Op->Asl.AmlPkgLenBytes - 1) << 6) |
                    (PkgLen.LenBytes[0] & 0x0F));
    
                CgLocalWriteAmlData (Op, &PkgLenFirstByte, 1);
    
                /*
                 * Shift the length over by the 4 bits we just stuffed
                 * in the first byte
                 */
                PkgLen.Len >>= 4;
    
                /* Now we can write the remaining bytes - either 1, 2, or 3 bytes */
    
                for (i = 0; i < (UINT32) (Op->Asl.AmlPkgLenBytes - 1); i++)
                {
                    CgLocalWriteAmlData (Op, &PkgLen.LenBytes[i], 1);
                }
            }
        }
    
    вроде все в коде AMLSCAN.INC и правильно декод сделан...
    Не хочется тупо искать string "_S5_", т.к. грамотная декодировка этого байта вроде как залог успеха для корректного драйверка по ACPI.
  • Who is online

    Users browsing this forum: No registered users and 5 guests