Здравствуйте!
Вообще-то я пользую GETNOO и собственный дистр по типу SLAX 6.0
Но ядро -- 2.6.18 от openvz в версии EL5. AltLinux тоже использует что-то подобное. Посему и пишу сюда.
Проблема: занялся задачей определения точности хода RTC на компе и, соотвественно, правкой программы
hwclock. И после долгих заблуждений столькнулся с проблемой ядра 2.6.xx -- при работе ntpd оно регулярно (через 11 минут) пишет системное время в RTC. Внешне это выглядит так, как будто RTC идет очень точно, без ошибок. В ядрах 2.4.x такой фичи не было. В 2.6.18 для x86 фича не отключаема, хотя в форумах можно прочитать -- если не нравиться, то соберите без этой фичи.
Вопрос: в версии 2.6.18 от AltLinux есть такая фича или она отключена?
На мой взгляд -- не ядра это дело что-то там править в RTC. Для этого есть пользовательские программы. Если я хочу пользовать ntpd и иметь при этом контроль над ходом RTC, то в 2.6.18 без правки ядра это невозможно. Установка ntpd-демоном флага, что время ядра синхронизировано, не должно автоматом приводить к регулярной в 11-минут процедуре записи системного времени в RTC. Это -- разные вещи. По-хорошему для этого должен быть отделный флаг. По-плохому -- надо удалить вызов kernel/time.c: notify_arch_cmos_timer() в do_adjtimex() вообще. Сейчас собираюсь сделать последнее. Ибо все дистры пользуют hwclock при старте для установки системного времени. А эта программа правильно может выставить время только в том случае, когда только она сама пишет в RTC. Так что если при завершении работы системы вызывается hwclock для сохранения времени системы, то фича ядра как минимум бесполезна. Если не вызывается, то фича ядра просто вредна -- hwclock не сможет правильно установить время при старте системы.
Другие вопросы: кто пользовал HPET таймеры в 2.6.18? Насколько это помогает для мультимедиа? В конфиге от openvz и RedHat эта фича вроде как отключена. Помогает ли жить опция support clock division ?