Board.KolibriOS.org

Очень хорошо. Будет замечательно, если ты сможешь протестировать выборочно несколько сборок, пока не найдёшь, в какой из них появилась проблема.

GerdtR
частота CMOS RTC может здорово плавать - прочисть материнку от пыли, смени батарейку.
транк-ядро до сих пор определяет частоту ЦП по тикам RTC, через жо 61-й порт.

лучше пользоваться таймером реального времени.
а еще лучше - прочитать настройки PLL напрямую из MSR (правда, где они там на селеронах - не знаю).

Желательно методом исключения проверить промежуточные сборки. Берем среднюю ревизию и проверяем, далее корректируем (в зависимости от получившегося результата одно из крайних значений) номер ревизии и снова берем среднее значение. Так пока не найдется ревизия, предположительно вызвавшая проблему.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Попробую проверить сборки. Хотя с моим инетом это не очень быстро. Потому ждать придётся больше.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

В сборке 3265 ещё всё как положено. В 3268 уже неправильная частота.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

Проверь еще раз - в этих ревизиях trunk ядро не менялось, а приложения правились совсем уж отношения не имеющие.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Полная ерунда. Сейчас и 3005 неверный результат показала. Скорее всего art_zh прав. Комп почищу, может вообще проблема исчезнет.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

Если это глюки RTC, тогда у тебя под виндой должно скакать системное время.

Пока надо разобраться со 101% в проге cpu. С частотой процессора и раньше были странные глюки

viewtopic.php?f=1&t=617&p=18673&hilit=CPUID#p18673

В чём разбираться? Что тут непонятного?
Показатели частоты процессора и использования процессора Колибри берёт из тиков TSC, часть тиков уходит в SMM на работу BIOS, из-за этого замеряемое количество тиков больше того, которое реально потрачено. Это относится и к частоте процессора, и к количеству тиков в секунду на программу, причём они замеряются в разное время и, соответственно, по-разному увеличиваются; в зависимости от коэффициента увеличения программа может получать и 101% от измеренной тактовой частоты, и 87% от неё же.
Для более точных значений нужно договариваться с BIOS, чтобы та не наглела, и брать на себя то, что делает SMM-код. Пишите поддержку ACPI, господа.

_________________
Сделаем мир лучше!

А почему на большинстве компьютеров всё ОК и без ACPI? Там BIOS не такой наглый просто?

Почистил комп. Проблема исчезла.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

И 101% тоже.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

BIOS тут нипричем - это нормальная девиация частоты.
Пикоамперный генератор очень чувствителен к любым паразитным сигналам. Села пылинка на контакт - уже емкость резонатора изменилась. А если это целый шмат пыли, да еще и обдуваемый вентилятором?

И ACPI тут ничем не поможет - все равно прерывание по времени завязано на тот же генератор, а значит нестабильность периода IRQ будет те же десятки-сотни микросекунд.

Проблема решается только переводом ядра на HPET - он высокостабильный и микросекундный.
Еще лучше APIC-таймер в самом процессоре.

HPET/APIC не во всех поддерживаемых Колибри процессорах есть.