задержка вызова обработчика IRQ

diamond
Это не очевидно. Если таймер пропустил прерывания. Его могут вызвать после того как было прерывание от SMI тем самым разбросс будет, а среднее время должно быть одинаковым.

Мы в память не лезим. Мы пробуем отключить источник SMI.

VaStaNi
Кнопка может быть не показателем.

Пока не до этой темы.

 

Процессор считает такты в TSC даже в SM-режиме. Соответственно если было прерывание от SMI, задержавшее либо совсем отменившее очередное прерывание таймера, то когда прерывание (очередное или следующее) таки наступит, то разность значений счётчика тактов будет всегда больше, чем при отсутствии SMI - либо на время обработки SMI (если прерывание отложилось), либо просто увеличится в несколько раз (если прерывание "проглотили"). Примерно равные в обе стороны колебания вокруг базового значения ну никак из-за этого не получатся.

Запустил irq0_05 на соседнем компе - http://diamondz.land.ru/irq0_d2.png - и обнаружил, что там иногда (с периодом примерно в 250 миллисекунд) наблюдаются огромные выбросы, причём исключительно вверх. Понял, что здесь обсуждается (как видно, этот эффект всё-таки не на всех компах проявляется). Но всё-таки интересно: а колебания вокруг базовой линии, которые могут достигать по величине нескольких процентов (картинка в моём прошлом посте для одного компа, http://diamondz.land.ru/irq0_d2_2.png - крупный план для irq0_d2.png), чем вызваны?

Понял.

 

Да отклонения и вверх и вниз(!) от среднего уровня(именно он и есть "чистое" IRQ0).
Да, на первый взгляд именно "вниз" обескураживает, но... но почитав маны находишь, что SMI, то сволочь ОТКЛАДЫВАЕТ!!!!! ВСЕ!!! возникающие аппаратные прерывания, ДО своего окончания. Тогка все сходится и одно перетекает в другое, среднее же останется.
НАС интересует СТАБИЛЬНОСТЬ такта, а раз SMI тоталитарный диктатор, что откладывает и херит все в "свои" моменты времени то имеем, что имеем, к сожалению.
Пока кнопке верю, что SMI зарубив, она перестанет фунциклить (естественно затрагивая только то что влияет не на кнопку а на причины возн. SMI).
Докопался вот в манах на южный мост вот до чего:
GEN_PMCON_1—General PM Configuration 1 Register (PM—D31:F0)
БИТ4: SMI_LOCK — R/W-Once. When this bit is set, writes to the GLB_SMI_EN bit will have no effect. Once the SMI_LOCK bit is set, writes of 0 to SMI_LOCK bit will have no effect (i.e., once set, this bit can only be cleared by PCIRST#).
Выходит много манТравы курить надо Шаманские бубны! Блин. Есть мысля, что можно без SMI запрета явного, порубить ее линии(причины) SCI кажись там обзываются...
Похоже, что занающие это "пикантное дело" либо не заходят сюда, либо... вне коннекта. Жаль, хотелось быстро правду сыскать по сабжу. Бум маны курить и тыкать в небо.

 

diamond спасибо за интерес!

ды к благодаря именно этому свойству мы и видим эти чудные картинки! :0)
Ты открой в блокноте файл статистики и пробежись, затем открой калькулятор + вылови глазами измерение-"яму", а потом внимательно посмотри на соседствующие заначения, выпиши их, хатем далее найди еще яму дальше и опять окружающие возми. И последнее с пом. калькулятора посмотри перетекание процессорного времени. Исседования + факты это крутата! Будут доводы против давай обсуждать, только сначала сделай, как прошу(советую). Я привел все свои вещи и намерен приводить далее. Правды и ясности хоца.
Успехов всем пытливым и неравнодушным!

 

Если таймер, тикающий с частотой 10 кГц, испытывает возмущения от SMI, влияющие на все значения (соседние значения отличаются на несколько тысяч тактов!), значит, SMI тикает как минимум не реже. Вопрос номер 1: нафига какому-то прерыванию такая частота? Раз в 250 миллисекунд - это правдоподобно, но несколько раз в 0.1 миллисекунду - это уже слишком. Но предположим, что тикает. Ясно, что обработчик SMI работает значительно быстрее, чем возникают SMI и относительно небольшой процент времени приходится на обработку SMI (иначе процессор тратил бы слишком много времени на SMI, а этого нельзя было бы не заметить - ну хотя бы потому, что определение тактовой частоты по rdtsc давало бы явно отличающиеся от реальных числа). Следовательно, если SMI и таймер независимы, то вероятность попадания таймерного прерывания в точности в промежуток обработки SMI мала, и уж точно SMI не может искажать все значения. А если они зависимы, то не может быть такого разброса - сейчас такое-то значение, а через 0.1 миллисекунду в таких же условиях (SMI находится в том же состоянии, что и раньше; иначе необъяснимо, что прерывание снова попало на SMI) уже на несколько тысяч тактов больше.

 

diamond
А какая схемотехника таймера случаем не знаешь? Он небось и не кварцованный "из экономии" тогда имхо такой разброс вполне естественное явление...

 

Y_Mur
Нет, не знаю. Вот, влез в разговор, надеюсь, что кто-нибудь объяснит Мне тоже кажется, что такой разброс обусловлен какими-то особенностями железа. Но всё-таки хочется возможно более детальных объяснений, откуда он всё-таки берётся и почему имеет именно такое распределение (отклонения от среднего ведь явно не по нормальному закону распределены).

 

что то я не вьехал, что ты хотел сказать или привести доводы... Это ты про возможную синхронизацию наверное. Ну если так, то я считаю что

один из которых ПЕРИОДИЧЕСКИЙ, или НЕ один. Посему более хочу давить. Во всяком случае ман говорит что могут быть таймерные тики SMI разные + подмешиваются аппаратно возникающие событийные, они то НЕпериодические по определию... Вообще хрен его знает этот SMI, что там творится. Если сдампить обработчик его или выковырять из биоса это еще реально + дизасм, а вот как железо настраивает биос и как оно "поёт" реально это темнота для 99,99%
Одни предположения и догадки, да потуги чтото понять. Вот это факт.

 

вот ответы на этот и другие вопросы считаю даст, как говорят патологоанатомы вскрытие, т.е. программным владением причин SMI его источников. Тут маны рулят + пробы рубить если не все сразу (неполучается, как видно выше. SMI берегут как зеницу ока виш залочка оказывается имеется SMI_LOCK бит!) так по кусочкам. Во всеком случае сейчас на ум приходит в связи с diamond постом провести ряд статистических рамеров с РАЗНЫМИ таймерными уставками по SMI что в манах видел + зачитать их в PCI cfg. ТОгда можно попытаться "узнать" их в статистике отсчетов.
Вообще интеловские матери где то в районе 810-915 чипсетов самое милое дело для исследований и BIOS и SMI и SMRAM и разлочек всяких... + МАНЫ ЕСТЬ!
А вот нвидиа, например - гиблое дело...

 

VaStaNi
Не, колебания вокруг базовой линии вверх/вниз - это точно не SMI, а подскоки "вверх" - это точно SMI. Я вместо чтения TSC подставил число выполненных инструкций (один из счётчиков производительности; дело было на второй конфигурации, там процессор Intel Centrino) - и в результате ясно видно, что в основном между замерами процессор выполняет 84 инструкции (тем, кто соберётся проверять это по коду: rdtsc заменялось на 4 инструкции, stosb на 3 для возможности обработки >64K - в результате для вывода чисел из двух цифр действительно будет 84 команды), но каждый 2580-й замер (впрочем, один раз интервал составил 2579 замеров) резко подскакивает, то есть процессор выполняет какой-то дополнительный код. (Для формалистов: три следующих замера после этого показывают 102, 91 и снова 84 команд - увеличение за счёт числа выводимых цифр.) Подскакивает до величин 19468 и 19490, причём две величины строго чередуются.

 

Y_Mur
diamond

Таймер компьютера кварцевый 14,31818 МГЦ погрешность 50 ошибок на миллион (чувствуете подвох) остальные частоты получаются делением и умножением.
10 кгц=>10 000±0.5
При частоте 2 ГГц расстояние между тиками таймера будет 200 000 ±10 тиков
Плюс деление/умножение частоты вносит погрешность плюс сама инструкция RDTSC имеет дискретность от 1до 15 тиков. И того 2 00 000 ± 25 тиков Теоретическая погрешность измерения порядка ±25 тиков


Таймер SMI настраивает в БИОСе на каждые 64мс тесть с частотой 15,625 Гц
Возможные значения
00 = 1.5 ms ± 0.6 ms
01 = 16 ms ± 4 ms
10 = 32 ms ± 4 ms
11 = 64 ms ± 4 ms

Если посмотреть по цифрам из статистики VaStaNi то отклонение от среднего в основной массе проскакивают числа
0 15 25 52 64 вполне нормальный фон о котором я писал выше. Это погрешность самого таймера и измерений.
А вот бывают выбросы, когда таймер срабатывает на 900тиков позже чтобы, потом выровняться он срабатывает на 900 раньше. Вернее выравнивания нет. Следующий тик срабатывает как надо. Явно видно что что-то заморозили прерывания на 900 тактов процессора после того как разморозили прерывание сработало это и вызывает всплески в плюс а затем в минус. Завораживается не таймер, а только его прерывание. Поэтому следующее срабатывание таймера будет по расписанию.

Это SMI число срабатывание 62 на 6000 срабатываний нашего таймера.
Если таймер у нас с частотой 10 КГц то SMI в 96 раза медленнее Получаем 103,(3) гц получаем срабатывание SMI каждые 10 мс. Время которое потрачено на обработку SMI более 900 тиков. Но менее 200 000 Нужны дополнительные исследования, чтобы понять на сколько повисает. Но так как мы не пропустили не одного прерывания таймера то задержка на обработку менее 0,1 мс(200 000 тактов).

Сейчас перепроверил. Походу у нас два события SMI. У него два таймера может в этом дело. Видна какая-то закономерность но четкого порядка нет.
Два события: одно через 1,6 мс. другое через 16мс
Порядок похож на такой 16 1,6 16 1,6 но некоторые цифры выбиваются. Могли и проскочить.

Если учесть цифры diamond то обработчик SMI занимает порядка 10мк/с !!!

Выводы: SMI есть частота срабатывания в приделах 1мс время обработки 10мкс можно строить систему реального времени с бешенной частотой 1мкс!!!! При такой частоте нужно учесть SMI. Но SMI вещь не предсказуемая. И на разных машинах ведет по разному. И может проявлять и большие задержки. требуются дополнительные исследования запись бесконечном цикле значение счетчиков которые выбиваются из строя. Время замера рекомендуется увеличить с 6секунд до нескольких минут.

 

diamond
У тебя какието анамальный график. Но есть предположение, что SMI хитрым способом корректирует частоту таймер.
Если время обработки SMI гораздо дольше чем время между срабатыванием таймера то будет виден одиночный всплеск, а не двойной с отклонением в плюс и минус. Часть прерываний должны теряться. Вернее отклонения будут, но небольшими. А на уровне того шума что у тебя не разлечимы.

 

О! Точно! Действительно, есть
а) систематическое отклонение от "круглой" цифры 200000, вызванное тем, что реальная частота таймера не 10 кГц, а кратна системной частоте, а фактически даже кратна 1193181 Гц, и программируется на значение 1193181/119 = 10026.731 Гц;
б) мелкие погрешности в пределах нескольких десятков тактов;
в) эпизодические замораживания прерывания на время до 1000 тактов, проявляющиеся в паре "плюс/минус".
Вот только это не SMI. Потому что обработчик SMI - это монстр на десятки тысяч команд (на одной конкретной конфигурации 19468 - 84 = 19384, если быть точным), выполняющийся порядка одной миллисекунды и проявляющийся тремя гигантскими всплесками на втором из графиков. Потому что performance monitoring-регистры показывают, что во время нормальной работы (то есть за исключением вышеупомянутых всплесков) процессор честно исполняет только код теста и никакой другой код не выполняется (наличие всплесков типа 19468 явно свидетельствует, что вход в SMM ещё не является поводом выключать счётчики).
Кстати, чтобы не быть голословным: в архиве http://diamondz.land.ru/flashcard/irq0_work1.7z лежат измеренные числа для двух разных конфигураций, частота таймера 10 кГц, частота процессора 2 ГГц, а также модифицированные варианты, измеряющие не TSC, а число выполненных команд - два варианта, для Intel и AMD.

 

перепишите вы обработчик да и все
переключение PM -> SMI -> PM не думаю, что занимает милисекунды

 

Привет всем!
rei3er переписать - см. выше не каждый сможет и не для любой машины. Если не так, то подскажи как.
Теперь хочу ВЗЯТь СВОИ СЛОВА НАЗАД, по поводу того, что листинг выше по выкл. smi не работает. Pavia был прав видимо, и я мнение поменял. Вывод, что работает и вот мои доводы по кнопке как ориентир этог дела.
Кнопка ATX вкл/выкл заводится на мать и следовательно попадать на чипсет должна(сигнал), но досконально куда она ЕЩЕ идет электрически мы не занем... А она по видимому идет еще... на одновибратор типа или аппаратное реле времени с выдержкой около 4-5 секунд! Наблюдения таковы.
1. включили машину, после выныривания из пост проверок биоса сразу давлю кн. Эффект таков. Светодиоды клавы мулькают вспышкой и производится выключение (дело было по 2 интеловским чипсетам)
2. убиваю smi в досяре, давлю кн. - клава не реагирует и через 4-5 сек. (но точно больше чем п.1) машина выключается.
3. проблема. дос виснет после убиения smi, видимо некорректного зарубания smi...?
С этим вожусь сейчас. Еще пытаюсь листинг измерялки избавить от инструкций HLT (порбы разные с листингом...), мне кажется он тоже может вносить неравномерность замеров. Я не сильный спец в потрохах и особеннстях CPU на пердмет кешей, выполнения во времени разнл. инструкций и пр., что может повлиять на такты и замеры. Если есть у кого нить идеи, мысли на счет неправильности или наоборот применения HLT, рад буду выслушать. Спасибо!

 

ну, скажем так, если процессор поддерживает SMM, то переписать обработчик мы сможем
базовый адрес обработчика (SMBASE) SMI# известен и прописан в соответствующей документации
но он может быть изменен BIOS
т. е все, что нам остается, это написать чипсето-зависимый код, который позволит получить доступ на запись образа BIOS
получается следующий алгоритм
грузимся с какого-либо устройства, запускаем вышеназванный код, изменяем операнд JMP по 0xFFFF0 таким образом, чтобы перейти на код, выполняющий основную работу (предварительно записав его в память), генерируем RESET#
переходим на этот код
записываем код нашего обработчик SMI# по адресу SMBASE, ставим breakpoint на SMBASE и 0x4 (элемент IVT для #DB), предварительно записав в него адрес обработчика #DB
устанавливаем защиту #DB в DR6
передаем управление BIOS
любая попытка установить обработчик SMI# или #DB приведет к вызову нашего обработчика
через него можно контролировать все, что угодно

 

rei3er

Award меняет базовый адресс c 03000h:8000h на 0A000h:8000h. Собственно другии биосы это тоже должны сделоть. Ведь надо спрятоть код.
Зачем извращаться и делать отладку? База известна. Собственно сделать по коду из биоса.
Нужно только разлочить скрытую память и записать значениея.

Открытие SMRAM чепсето зависимо. Собственно у инелов все документированно. Делается через програмирование контроллера памяти.
Special_IOPort_Generate -вызов обработчика SMI для проверки. Вызов делается через порт. Вернее в Павер меноджере
в конфигурационном пространстве есть бит отвечающий за это BIOS_SMI. Специально для биоса сделали.
Так что нет проблем самому переписать SMM.

 

база известна после RESET# до установки нового значения SMBASE BIOS-ом
современные чипсеты поддерживают аппаратную защиту SMRAM через lock-бит (который, кстати, ничем кроме RESET# не сбросишь)
так вот, отладка нужна, чтобы не парится с

достаточно иметь процедуру записи в образ BIOS

 

если переписать до BIOS, то BIOS затрет наши данные
после BIOS - не получится из-за lock-бита

 

rei3er
Я непонял о каком лок бите идет речь? В контроллере памяти есть бит который можно сбросить и установить. Не вижу проблемы.