здрасти. Столкнулся с проблемой - периодические задержки вызова обработчика IRQ. Проводился эксперимент: Устанавливался собственный обработчик IRQ0. Программировался таймер0 на 2кГц. В обработчике замерялось время от вызова до вызова прерывания. Все остальный аппаратные прерывания замаскированы + NMI. Операционка DOS. Прога писалась в PM под PMODEW. Думал сначала изза PM. Переписал в RM - глюк повторился. Результат: приблизительно каждый 250мс происходила задержка вызова прерывания на 1мс. Почему такое происходит или как от этого избавиться? Памагите пажаласта)
Незнаю! Конечно есть предположение что это SMM. Но всетаки цифры у тебя странные. Может ошибква в коде измерения переолнения не учтено? А если проверить через другой таймер RTC, ACPI Timer? Может приведешь точные цифры?
pyrodex,Pavia это 99% SMI обработчик хавает!!! pyrodex я такие же эксперименты проводил и потом написал ряд тестов под дос, где была цель выключить ВСЕ кроме IRQ0 (т.к. якобы самый самый приоритеный....) и выяснить его стабильность... но все оказалось весьма печально.... О! Вот кажись нашел свой последний исходничек этого дела! Прошу протестить кто хочет "набить" статистику "разлетов" между IRQ0 срабатываниями. Итак: Code (Text): ; ; (с) <<< VaStaNi >>> vastani....pochta.net ; ; Программулина создания массива тактовых итервалов IRQ0. ; Интервалы измеряются количеством тактов процессора, ; затрачиваемых на АППАРАТНЫЙ интервал между запросами IRQ0. ; Запрещены ВСЕ IRQ кроме IRQ0. ; Массив пишется в файл по окончании требуемого количества периодов = LEN. ; ЦЕЛЬ: ; Анализ стабильности периода таймерных задач, основой которых является ; высокоприоритеный аппаратный запрос IRQ0 для таймерного обработчика. LEN = 6000 ORG 0x100 xor ax, ax mov fs, ax mov ebx, [fs:0x20] ; взять живой вектор IRQ0 из памяти mov [SaveIRQ0], ebx ; сохраним для восстановления по окончании работы cld cli ; выключим прерывания dec al ; mov al, 0xFF ; маска запрета всех IRQ8..IRQ15 out 0xA1, al dec al ; AL = 0xFE --> разрешен только IRQ0 (маска запрета IRQ1..IRQ7) out 0x21, al mov ax, EmptyIRQ0 ; это смещение на процедуру замера по IRQ0 mov [fs:0x20], ax ; меняем вектор mov [fs:0x22], cs ; меняем сегмент на фактический для нашего кода mov di, DumpRDTSC ; начало дампа замеров mov cx, LEN mov ax, (1193180/10000) ; 10000 Гц call SetTimer0 ; установим тики таймерного канала 0 частотой 20 Гц (IRQ0) sti ; запустим работу только IRQ0 hlt hlt hlt rdtsc mov ebx, eax @rep: hlt rdtsc ; читаем счетчики! push cx push eax sub eax, ebx jnc @ncor not eax inc eax @ncor: call Int32_to_String mov ax, 0x0A0D stosw pop ebx pop cx loop @rep cli ; Все! Намеряли! Будем анализировать дальше mov eax, [SaveIRQ0] mov [fs:0x20], eax ; восстановим вектор xor ax, ax out 0x21, al out 0xA1, al ; сняли все маски call SetTimer0 ; восстановим тики таймерного канала IRQ0 sti xor cx, cx mov ah, 0x3C mov dx, FileName int 0x21 mov bx, ax mov ah, 0x40 mov dx, DumpRDTSC mov cx, di sub cx, dx int 0x21 mov ah, 0x3E int 0x21 int 0x20 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; EmptyIRQ0: mov al, 0x20 out 0x20, al IRET ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; SetTimer0: push ax mov al, 0x36 ; выбрать счетчик 0, шестнадцатеричный счет, загрузить младший байт, затем старший out 0x43, al pop ax out 0x40, al ; младший байт mov al, ah out 0x40, al ; старший байт RET ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Int32_to_String: ; Перевести число из двоичного кода в код BCD mov [Data_Int32], eax fild [Data_Int32] ; Загрузить число в двоичном коде fbstp [Data_BCD] ; Извлечь число в коде BCD mov si, Data_BCD ; ПРЕОБРАЗОВАТЬ ЧИСЛО ИЗ КОДА BCD В КОД ASCII add si, 8 ; Пропустить незначащие (нулевые) разряды слева mov cx, 9 @@n1: ;проверяем на 0 очередную пару разрядов cmp byte [si], 0 jne @@n2 dec si loop @@n1 ; Если значение числа равно нулю, записать символ ; нуля в строку результата и выйти из программы mov al, '0' stosb jmp @@End ; Пропустить незначащий ноль в старшей тетраде (если он есть) @@n2: ; Загрузить первую значащую пару разрядов mov al, [si] mov ah, al ; Выделить, перевести в ASCII и ; сохранить старшую тетраду shr al, 4 or al, al ; Если 0 - пропустить старшую тетраду je @@n3 add al, '0' stosb ; Выделить, перевести в ASCII и сохранить младшую тетраду @@n3: mov al, ah and al, 0xF add al, '0' stosb dec si dec cx jz @@End ;выход, если это последний разряд ; Распаковать остальные разряды числа (если они есть) @@n4: ; Загрузить очередную пару разрядов mov al, [si] mov ah, al ; Выделить, перевести в ASCII и сохранить старшую тетраду shr al, 4 add al, '0' stosb ; Выделить, перевести в ASCII и сохранить младшую тетраду mov al, ah and al, 0xF add al, '0' stosb dec si loop @@n4 @@End: RET ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; FileName DB 'delta.txt', 0 SaveIRQ0 DD 0 Data_Int32 DD ? ; 32-разрядное целое число Data_BCD DT ? ; Число в BCD-формате DumpRDTSC DD ? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Жаль тут прямо файло не цепляется. Короче файл статистики можно глазами конечно проверить, убедиться + взять калькуляток и посчитать, но... я еще накропал XLS файло с макросом ,который обработывает весь массив и наглядно показывает + периодичность "размыва" периода IRQ0 видна. Своего рода частотная модуляция Firq0 частотой Fsmi получается А жрет SMI тактов немеряно особенно у некоторых вендоров материнок их архитектур... видимо и варианта кода самого обраб. SMI... (все. бегу. пропадаю дня на 3.как вернусь почитаю тутычки, интересно ведь)
VaStaNi я замеры делал через канал 2 таймера. в сам ИНТ запихал чтение значений таймера. как ты праивльно выразился - происходит размыв. какоето аремя идёт стабильно, потом одна задержка, и опять стабильно. причем задержки повторяются с одинаковым периодом. а как эту проблему побороть? прочитал что от SMI никак нельзя избавиться.
можно поставить свой обработчик на SMI# в обработчике только rsm только скорее всего придется BIOS патчить, т. к на современных чипсетах есть аппаратная защита SMRAM (lock bit), а она как раз в BIOS включается
получается, что на PC-подобных машинах не возможно создать ОС реального времени. И все кто заявляет об этом просто пе..дят.
pyrodex ОСРВ создать можно. Вот тут можешь почитай ftp://ftp.prosoft.ru/pub/Hardware/Fastwel/QNX/6.3.x/technotes/SMI_handler_overlay_QNX.pdf
как её можно создать если есть задержки в 1мс при вызовах аппаратных прерываний? или эти товарищи (создатели ОСРВ) знают как сделать так, чтобы этих задержек не было
pyrodex Я же говорю что зависит от железа. Порылся в исходниках биоса ничего интерестного не нашел. Берем даташит на чипсет и согласно нему запрещаем SMI. В исходниках биоса конечно есть подсказка как включить SMRAM. Как записать туда данные. Хотя тут прикольные строчки нашел. Пока не разобрался но по ощущением что в SMI идет работа с HDD.
pyrodex ОСРВ можно, главное чтобы приложению требовалось переодичность не чаще 1-2мс. А вот ОСРЖВ уже нет.
Привет всем пытливым! Было такое впечатление, но не долго, т.к. порассуждав, почитав, посчитав, понимаешь, что они вполне честно ПОЭТОМУ и приводят в своих хар-ках оси, что дескать гарантируем время отклика НЕ менее чем 10мс... Это почему собссссвенно? Задаешь себе вопрос. А что получается? Если скажем, основной пульс системы 5мс и он базирован на IRQ0 и "они2 знают, что некогда, в него вонзается доп "потеря тактов" плоть до 2...3 мс, то тогда, можно и гарантировать, что 5+(2..3) < 10! Когда я еще и не догадывался про существование и "подпольную жизнь" SMI в машинах РС архитекруры (в том числе своей)), я все время думал, чего это они такие медленные оси РВ делают? Ведь можно и меньше квант (пульс) в системе сделать и обеспечить гораздо большие возможности, скажем для робототехники, точных манипуляторов, науки и пр...... Оказывается вот оно, что SMI!!! Самый крутой вирус из всех известных в мире. : Суперминирование любой оси! Когда первый шок прошел, я понял, что это не иначе как жизнь внутри жизни блин. В тему (в фазу реплики) рекомендую прочитать кто не был здесь: http://www.rom.by/article/А_кто_управляет_Вашим_компьютером Это мое мнение, выводы основы я привел. Рад буду прочесть другие суждения, факты, ссылки. Теперь какбы поуспокоившись и зная правду и суть неугомонный разработчик(ну пусть я) думает, а как бы мне ОСЖРВ всеже сделать... ну хотябы замутить... ну хотябы попробовать замутить ЧЁТКИЙ пульс, базу отсчетов, дабы быть уверенным, что можно обеспечить, ну пусть 1мс! Но ЖЕЛЕЗНО, четко, без размыва? Один из путей Pavia правильно сказал - рубить! В самом худшем случае ВООБЩЕ ЗАРУБИТЬ SMI!!! Задай сам себе вопрос, а ОНО НАДО мне(разработчику, заказчику, пользователю ОСЖРВ, конечному "агрегату", конечному результату)? Думаю если рассмотреть, ЧТО делает SMI (хотя это почти супер секреты пентагона получаются для основной массы нас смертных, что неправильно, я считаю) - можно прожить и без ЭТОГО! Ну даже типа такой довод - жили же раньше, когда его нам НЕ ПОДКЛАДЫВАЛИ в бивис!? Ну хрен с ними с этими спасениями аппаратуры от перегрева, от остановки кулера (а может у меня его вообще нет!), от питающих напряжений (а я их вообще сам буду и мерять в оси и оценивать быть может и делать свои выводы и действия в связи с этим...), ну и бибикать спикером в кризисах мне на кой, я и сам бибикну, да еще и лучше + там где надо мне(!), что-то еще о чем я не знаю!??? Ну и хрен с ним! Лучше спать будем, спокойней, что бомбы то нету и никто мой ОС-мозг не травмирует (может Чернобыля НЕ будет! Не дай Бог!). Получается либо вообще рубить, либо писать свой, либо пытаться мириться с ним. Итого 3 варианта, которые стоит прикинуть исходя из своих ТЗ на разработку (пусть и сам себе режиссер, но таково должно быть, если не в песочницу играться!). Таксссс... 1. рубить. Нужно знать чипсет(ы) с которыми работать будем(!) и уметь убить правильно. Тогда ОСЖРВ - реальность на РС! 2. писать свой. Нужно еще больше знать чипсет(ы)!!! И очень правильно все сделать! Висяки могут быть очень серьёзные и система может очень уж НЕвосстановимо умирать! Большущие проблемы отладки кода, очень профессиональный НИЗКОУРОВНЕВЫЙ кодинг (равно как самому BIOS код разаб./отлаживать). "Вендоробезобразие" большой отдельный разговор...... 3. мириться (типа ною-хаЮ). Тут предполагается, что если четко знать пульс проектируемой системы (элементарный квант) и ЗНАТЬ некий БАЗОВЫЙ период SMI (если он существует или его можно замерить адаптивно по принципу выше, скажем) то можно попытаться именно СИНХРОНИЗИРОВАТЬ IRQ0 и SMI (запустить IRQ0 в нужной фазе с известным периодом, который....), так чтобы SMIшные потери тактов ложились в временной интервал обработчика IRQ0 (все капец мне, выдал суперсекрет! пентагон уже звонит в мелкософт ). Ну думается, что не совсем уроды должны(!) SMI код обработчика писать, то он должен(!) быть максимально краток, оптимален... дабы не влиять на..... НО Я в ЭТО НЕ верю! Если честно. Хотя нужно пробовать, это идея пока не окружена практикой... Факты бьют больно. Верю замерам. Можно попытаться, если много жрется, ЧАСТь SMI причин зарубить (см.Pavia), т.к. если накуриться даже поверхностно манов по чипсетам, то видно, что SMI - это сборище причин хаотически возможного срабатывания! Одно из которых - таймерное с довольно таки широким размахом вплоть до секундных, кажись.... (+ поправка на чипсет, вендорные бзыки, заморочки). Поправте меня если не так plz! Вот это прорвало меня сегодня так сказать что накипело то и вывалил, надеюсь на продуктивное развитие и обсуждение и НЕравнодушие. Спасибо!
из исследовательского архивчика файлики (XLS демонстрирует любопытно-красивый экземпляр PC): http://openfile.ru/75115/
VaStaNi 1. Есть предположение что переключение в SMM занимает время также если небольше, как переключение процессора между задачами и защищенным режимом. Так что рубить выгледит более лучше. 2. Тут хитрый ACPI он вроде позволяет перевести часть обработчиков из SMI. 3. Есть два периуда 64мс и 2,3 с (воемя переполнения счетчика), но почемуто основная задержка приходиться на 250мс. Есть мнение что идет регулировка куллера. Сам я считаю что походу там несколько задачь выполняется. На самом деле SMI не так уж сильно нужно. Отключение, включение компьютера. USB клавиотура и мышь - задействован SMI Про таймеры я говорил. Есть еще сигнал тревогу перегрев или скачки петания. В отчетах QNX говориться о ISA DMA странно упоминанейней в мануалах что-то не встречал. Полное отключение SMI возможно. Но можно частично отключить, чтобы он следил за безопасностью и выполня часть функций. Только порезать таймеры. PS. Файл битый.
с п.1 - согласен. Чем ближе требования по РВ (ЖРВ), тем больше рубить, гасить, давить его как гада ) п.2 - на кой? Возни туева ...., нюансов и головомойки ух! Разве для очень подкованности в исключительно таких эксклюзивах! п.3. Да. И кулер и температуры и выкл (скорее всего и программо-таймерный ВКЛ. там же!), и питания и USB клава и мышь (еше неизвестно какой кривости и тактов эта реализация, есть разные слухи по поводу). Частично резать... все равно он ведь гад сдампит и восстановит кучу данных + время на переключение видимо около (в может и больше) игр с TSS! Я имею виду в тактах проца, конечно. Самое красивое, конечно видится, это ЯДРО ОС ЖРВ вешать(делать) НА SMI! Т.е. использовать его дейстивельно как СУПЕР-ПУПЕР-МЕГА-АДМИНИСТРАЦИЯ ЯДРА на передмет НЕУБИЕННОСТИ ОСИ её живучести, надзор за целостностью, этакий WatchDOG системы. Но писаный он должен быть под Ось, под задачу, под ТАКТ!, под цели, а НЕ паразитически! Но это предполагает п.2 что писал выше. Кто знает, может некогда так и будет. И вообще неизвестно, как и какие ОСи его используют... Это все скрывается как то от ручек Да, бит зараза, файл! Враги посекли, млин! Презалито: http://openfile.ru/75155/ Проверил сам вроде ОК!
Что то все молчат даже pyrodex не интересно? Попытаться добить вопрос до точки и зарубить SMI, дабы снять статистику и в таком случае. Пробовал так Code (Text): ORG 0x100 ;Disable SMI mov cl, 30h call _Get_PMIO and al, not 1 call _Set_PMIO ret _Get_PMIO: push dx mov dx, 4000h ; port PMBase! mov dl, cl in al, dx out 0EBh, al pop dx retn _Set_PMIO: push dx mov dx, 4000h mov dl, cl out dx, al out 0EBh, al pop dx retn как я понял ничего не произошло, т.к. кнопкой выключился БП ATX, заначит SMI жив... PMBase правильна, чипсетина древняя, известная, интел 815. Кто знает что не так?
Можно влезть в обсуждение? На графиках (и на выложенном VaStaNi, и построенным для моего компа - http://diamondz.land.ru/irq0_d1.png, если кому интересно) видно, что от базовой точки идут отклонения как вверх, так и вниз, причём примерно в равном количестве. Но обслуживание SMI, очевидно, может только увеличивать время отклика из-за дополнительных затрат. Откуда тогда берётся уменьшение времени реакции? Дык
