Re: убегает время
В сообщении от 10 Август 2007 14:02 Andrey Melnikoff написал(a): > Попался мне тут интересный фифект - если менять clocksource в момент > загрузки Xов с nvidia драйвером - то в 99% случаев - полный вис. > Если указать нужный source при загрузке - всё норма А зачем это делать на лету? А главное как? Через /proc какой-нибудь? -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Max Dmitrichenko <[EMAIL PROTECTED]> wrote: > В сообщении от 9 Август 2007 13:55 Stanislav Maslovski написал(a): > > On Thu, Aug 09, 2007 at 12:00:09PM +0400, Max Dmitrichenko wrote: > > > В сообщении от 8 Август 2007 17:17 Stanislav Maslovski написал(a): > > > > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. > > > > > Что это может быть? > > > > > > > > Другая причина - нестабильный/плохо откалиброванный time source. > > > > На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer. > > > > dmesg скажет, какой time source используется. > > > > > > $ dmesg > > > ... > > > Time: tsc clock source installed > > > ... > > > > > > С какого дуба он упал, если выбрал в качестве источника времени такты > > > процессора?! > > > > TSC выбирается по-умолчанию, так как это дешевый clock source с разрешением > > порядка наносекунд. > Хрен знает что у них там такое в timekeeping, но clocksource=acpi_pm помог. JFYI: Попался мне тут интересный фифект - если менять clocksource в момент загрузки Xов с nvidia драйвером - то в 99% случаев - полный вис. Если указать нужный source при загрузке - всё нормально. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
В сообщении от 10 Август 2007 01:14 Stanislav Maslovski написал(a): > clock_gettime(), вообще-то, задумывался с наносекундным разрешением. > Посмотрите, что у Вас выдаст этот пример для разных clock source в ядре: > > У меня: > > CLOCK_REALTIME res: 0.1 sec. > CLOCK_MONOTONIC res:0.1 sec. > CLOCK_PROCESS_CPUTIME_ID res: 0.1 sec. > CLOCK_THREAD_CPUTIME_ID res:0.1 sec. > > Понятно, что наносекндная точность лишь постулируется, но тем не менее. К сожалению под рукой только sarge с ядром 2.6.12. Дома на etch попробую. А в sarge чуть меньше милисекунды. 0.000998. Стало быть подпилили таймеры в новых ядрах. Приятно... будем знать. ЗЫ: Можно на ты. Здесь все свои :) -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Thu, Aug 09, 2007 at 06:53:10PM +0400, Max Dmitrichenko wrote:
> В сообщении от 9 Август 2007 13:55 Stanislav Maslovski написал(a):
> > On Thu, Aug 09, 2007 at 12:00:09PM +0400, Max Dmitrichenko wrote:
> > > В сообщении от 8 Август 2007 17:17 Stanislav Maslovski написал(a):
> > > > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит.
> > > > > Что это может быть?
> > > >
> > > > Другая причина - нестабильный/плохо откалиброванный time source.
> > > > На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer.
> > > > dmesg скажет, какой time source используется.
> > >
> > > $ dmesg
> > > ...
> > > Time: tsc clock source installed
> > > ...
> > >
> > > С какого дуба он упал, если выбрал в качестве источника времени такты
> > > процессора?!
> >
> > TSC выбирается по-умолчанию, так как это дешевый clock source с разрешением
> > порядка наносекунд.
>
> Хрен знает что у них там такое в timekeeping, но clocksource=acpi_pm помог.
>
> Интересно, а зачем для gettimeofday источник точнее чем микросекунды?
Теоретически, в POSIX есть nanosleep(). Теоретически =)
> Ещё, что любопытно,
> разрешение у POSIX Realtime Timers вообще совпадает с jiffies, хотя не
> понятно, почему
> бы clock_gettime не использовать более точные источники, чем jiffies.
clock_gettime(), вообще-то, задумывался с наносекундным разрешением.
Посмотрите, что у Вас выдаст этот пример для разных clock source в ядре:
===
#include
#include
#include
#include
struct timespec res;
int main()
{
syscall(__NR_clock_getres, CLOCK_REALTIME, &res);
printf("CLOCK_REALTIME res:\t\t%ld.%09ld sec.\n", (long)res.tv_sec,
(long)res.tv_nsec);
syscall(__NR_clock_getres, CLOCK_MONOTONIC, &res);
printf("CLOCK_MONOTONIC res:\t\t%ld.%09ld sec.\n", (long)res.tv_sec,
(long)res.tv_nsec);
syscall(__NR_clock_getres, CLOCK_PROCESS_CPUTIME_ID, &res);
printf("CLOCK_PROCESS_CPUTIME_ID res:\t%ld.%09ld sec.\n",
(long)res.tv_sec, (long)res.tv_nsec);
syscall(__NR_clock_getres, CLOCK_THREAD_CPUTIME_ID, &res);
printf("CLOCK_THREAD_CPUTIME_ID res:\t%ld.%09ld sec.\n",
(long)res.tv_sec, (long)res.tv_nsec);
return 0;
}
===
У меня:
CLOCK_REALTIME res: 0.1 sec.
CLOCK_MONOTONIC res:0.1 sec.
CLOCK_PROCESS_CPUTIME_ID res: 0.1 sec.
CLOCK_THREAD_CPUTIME_ID res:0.1 sec.
Понятно, что наносекндная точность лишь постулируется, но тем не менее.
--
Stanislav
Re: убегает время
В сообщении от 9 Август 2007 13:55 Stanislav Maslovski написал(a): > On Thu, Aug 09, 2007 at 12:00:09PM +0400, Max Dmitrichenko wrote: > > В сообщении от 8 Август 2007 17:17 Stanislav Maslovski написал(a): > > > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. > > > > Что это может быть? > > > > > > Другая причина - нестабильный/плохо откалиброванный time source. > > > На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer. > > > dmesg скажет, какой time source используется. > > > > $ dmesg > > ... > > Time: tsc clock source installed > > ... > > > > С какого дуба он упал, если выбрал в качестве источника времени такты > > процессора?! > > TSC выбирается по-умолчанию, так как это дешевый clock source с разрешением > порядка наносекунд. Хрен знает что у них там такое в timekeeping, но clocksource=acpi_pm помог. Интересно, а зачем для gettimeofday источник точнее чем микросекунды? Ещё, что любопытно, разрешение у POSIX Realtime Timers вообще совпадает с jiffies, хотя не понятно, почему бы clock_gettime не использовать более точные источники, чем jiffies. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Thu, Aug 09, 2007 at 01:55:14PM +0400, Stanislav Maslovski wrote: > > > > С какого дуба он упал, если выбрал в качестве источника времени такты > > процессора?! > > TSC выбирается по-умолчанию, так как это дешевый clock source с разрешением > порядка наносекунд. > У PM-Timer-а разрешение порядка 0.3 мкс. Но зато он тактируется от генератора, > более стабильного, чем процессорный CLK (от того же, что и старый добрый PIT). > У PIT разрешение хуже - порядка 1 мкс. > > Из всех clock source самый нестабильный - Local APIC Timer. А он может > использоваться вместо > PIT для генерации timer interrupts, к которым привязаны jiffies и отсчет > времени. > Тем не менее, IMO, основная проблема в старых ядрах - коррекция при > подозрении на потерянное > прерывание. Можно только порадоваться, что всю эту кучу мусора наконец-то > выкинули... В догонку: еще стоит сказать, что TSC (или PM-Timer) используются в старом коде лишь для интерполяции, т.е. для определения времени в моменты между соседними timer interrupts. Общий же темп времени задается темпом этих прерываний. -- Stanislav
Re: убегает время
On Thu, Aug 09, 2007 at 12:00:09PM +0400, Max Dmitrichenko wrote: > В сообщении от 8 Август 2007 17:17 Stanislav Maslovski написал(a): > > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. > > > Что это может быть? > > > > Другая причина - нестабильный/плохо откалиброванный time source. > > На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer. > > dmesg скажет, какой time source используется. > > $ dmesg > ... > Time: tsc clock source installed > ... > > С какого дуба он упал, если выбрал в качестве источника времени такты > процессора?! TSC выбирается по-умолчанию, так как это дешевый clock source с разрешением порядка наносекунд. У PM-Timer-а разрешение порядка 0.3 мкс. Но зато он тактируется от генератора, более стабильного, чем процессорный CLK (от того же, что и старый добрый PIT). У PIT разрешение хуже - порядка 1 мкс. Из всех clock source самый нестабильный - Local APIC Timer. А он может использоваться вместо PIT для генерации timer interrupts, к которым привязаны jiffies и отсчет времени. Тем не менее, IMO, основная проблема в старых ядрах - коррекция при подозрении на потерянное прерывание. Можно только порадоваться, что всю эту кучу мусора наконец-то выкинули... -- Stanislav
Re: убегает время
В сообщении от 8 Август 2007 17:17 Stanislav Maslovski написал(a): > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. > > Что это может быть? > > Другая причина - нестабильный/плохо откалиброванный time source. > На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer. > dmesg скажет, какой time source используется. $ dmesg ... Time: tsc clock source installed ... С какого дуба он упал, если выбрал в качестве источника времени такты процессора?! Пошел пялится в kernel-parameters.txt -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 06:34:37PM +0400, Stanislav Maslovski wrote: > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata1.00: cmd 35/00:48:fb:28:1e/00:01:00:00:00/e0 tag 0 cdb 0x0 data > > 167936 out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > ata1: port is slow to respond, please be > > > > После этого бутнул удаленно по питанию, > > Гугл выдает вот это: > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/37382 > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64587 Это я нашел.. но разбираться буду позже, наверное. Сейчас взлетело и вроде летит нормально. Удовлетворюсь пока что этим :) Еще раз спасибо за помощь. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Wed, Aug 08, 2007 at 05:03:42PM +0300, Alexander Burnos wrote: [ скипнуто ] > В итоге перезагрузил сервер, подниматься не захотел, на serial console > увидел обрывок вот такого вот: > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata1.00: cmd 35/00:48:fb:28:1e/00:01:00:00:00/e0 tag 0 cdb 0x0 data > 167936 out > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > ata1: port is slow to respond, please be > > После этого бутнул удаленно по питанию, Гугл выдает вот это: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/37382 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64587
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 05:33:33PM +0400, Stanislav Maslovski wrote: > > Потому как вот прямо сейчас наблюдаю > > "залипания" сервера и последующие всплески la до 80-90. И это явно не > > процессы ее грузят. > > Что-то с железом.. А что Вы говорили про nforce2/amd64? На 2.6 ядрах > > apic барахлит или что-то еще? > > См. мой ответ to Max Dmitrichenko. Спасибо за очень толковые ответы. В итоге перезагрузил сервер, подниматься не захотел, на serial console увидел обрывок вот такого вот: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd 35/00:48:fb:28:1e/00:01:00:00:00/e0 tag 0 cdb 0x0 data 167936 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be После этого бутнул удаленно по питанию, 10:02:52 up 47 min, 2 users, load average: 0.45, 0.36, 0.24 ntpdate -q pool.ntp.org server 64.142.114.146, stratum 2, offset -0.096367, delay 0.06238 8 Aug 10:03:11 ntpdate[21760]: adjust time server 64.142.114.146 offset -0.096367 sec Пока что полет нормальный. apic/lapic не выключал. Посмотрим что скажет под нагрузкой. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Wed, Aug 08, 2007 at 03:41:42PM +0300, Alexander Burnos wrote: > Hello! > > On Wed, Aug 08, 2007 at 04:34:10PM +0400, Stanislav Maslovski wrote: > > > root#billy[0]~>ntpdate pool.ntp.org > > > 8 Aug 08:19:25 ntpdate[17702]: adjust time server 141.82.30.251 offset > > > -0.007811 sec > > > root#billy[0]~>echo "0.0 0 0.0" >/etc/adjtime > > > root#billy[0]~>hwclock --systohc --utc > > > > > > Все прошло успешно. Наблюдаю как будет себя вести.. > > > > > > Только вот все равно машина себя как-то странно ведет. Вроде как > > > подмирает переодически. > > > Попробую при буте noapic сделать, только вот непонятно почему она раньше > > > работала безпроблемно, а тут вдруг выдала. > > > > Еще бы батареечку проверить не мешало бы ;) (см. в сторону sensors) > > Кажется мне, не в ней дело. Это в качестве задела на будущее ;) > Потому как вот прямо сейчас наблюдаю > "залипания" сервера и последующие всплески la до 80-90. И это явно не > процессы ее грузят. > Что-то с железом.. А что Вы говорили про nforce2/amd64? На 2.6 ядрах > apic барахлит или что-то еще? См. мой ответ to Max Dmitrichenko. -- Stanislav
Re: убегает время
On Wed, Aug 08, 2007 at 04:28:22PM +0400, Max Dmitrichenko wrote: > В сообщении от 8 Август 2007 09:33 Stanislav Maslovski написал(a): > > On Wed, Aug 08, 2007 at 02:07:48AM +0300, Alexander Burnos wrote: > > Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно > > велико (по модулю): > > > > # ntpdate pool.ntp.org > > # echo "0.0 0 0.0" >/etc/adjtime > > # hwclock --systohc --utc > > > > Материнка случаем не NForce2? > > У меня тоже на одной машинке уезажет время. На несколько часов в сутки. > ntp никакого нет, но мне почему-то кажется, что это все равно не порядок :) > > Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. > Что это может быть? Старый timekeeping код в ядре (< 2.6.21) ужасен. Особенно, в части коррекции jiffies, когда есть подозрение на потерянное прерывание. Обычно проявляется в том, что время плывет, когда нагрузка на ввод/вывод велика: работающие usb принтеры и пр. Другая причина - нестабильный/плохо откалиброванный time source. На PC выбирать имеет смысл из HPET (если есть) или ACPI PM-Timer. dmesg скажет, какой time source используется. -- Stanislav
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 04:34:10PM +0400, Stanislav Maslovski wrote: > > root#billy[0]~>ntpdate pool.ntp.org > > 8 Aug 08:19:25 ntpdate[17702]: adjust time server 141.82.30.251 offset > > -0.007811 sec > > root#billy[0]~>echo "0.0 0 0.0" >/etc/adjtime > > root#billy[0]~>hwclock --systohc --utc > > > > Все прошло успешно. Наблюдаю как будет себя вести.. > > > > Только вот все равно машина себя как-то странно ведет. Вроде как > > подмирает переодически. > > Попробую при буте noapic сделать, только вот непонятно почему она раньше > > работала безпроблемно, а тут вдруг выдала. > > Еще бы батареечку проверить не мешало бы ;) (см. в сторону sensors) Кажется мне, не в ней дело. Потому как вот прямо сейчас наблюдаю "залипания" сервера и последующие всплески la до 80-90. И это явно не процессы ее грузят. Что-то с железом.. А что Вы говорили про nforce2/amd64? На 2.6 ядрах apic барахлит или что-то еще? -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Wed, Aug 08, 2007 at 03:22:13PM +0300, Alexander Burnos wrote: > Hello! > > On Wed, Aug 08, 2007 at 02:58:19PM +0300, Alexander Burnos wrote: > > On Wed, Aug 08, 2007 at 12:40:10PM +0400, Stanislav Maslovski wrote: > > > > root#billy[0]~>hwclock --debug --systohc --utc > > > > hwclock from util-linux-2.12p > > > > hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. > > > > No usable clock interface found. > > > > Cannot access the Hardware Clock via any known method. > > > > root#billy[0]~>modprobe -l | g rtc > > > > root#billy[0]~> > > > > > > > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > > > > # CONFIG_HPET_EMULATE_RTC is not set > > > > CONFIG_RTC=y > > > > CONFIG_HPET_RTC_IRQ=y > > > > # CONFIG_RTC_CLASS is not set > > > > root#billy[0]/usr/src> > > > > > > ls -l /dev/rtc ? > > ls: /dev/rtc: No such file or directory > > > udev ? > > Нету, но ядро 2.6. > > Поставил udev, девайс создан. > > root#billy[0]~>ntpdate pool.ntp.org > 8 Aug 08:19:25 ntpdate[17702]: adjust time server 141.82.30.251 offset > -0.007811 sec > root#billy[0]~>echo "0.0 0 0.0" >/etc/adjtime > root#billy[0]~>hwclock --systohc --utc > > Все прошло успешно. Наблюдаю как будет себя вести.. > > Только вот все равно машина себя как-то странно ведет. Вроде как > подмирает переодически. > Попробую при буте noapic сделать, только вот непонятно почему она раньше > работала безпроблемно, а тут вдруг выдала. Еще бы батареечку проверить не мешало бы ;) (см. в сторону sensors) -- Stanislav
Re: убегает время
В сообщении от 8 Август 2007 09:33 Stanislav Maslovski написал(a): > On Wed, Aug 08, 2007 at 02:07:48AM +0300, Alexander Burnos wrote: > Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно > велико (по модулю): > > # ntpdate pool.ntp.org > # echo "0.0 0 0.0" >/etc/adjtime > # hwclock --systohc --utc > > Материнка случаем не NForce2? У меня тоже на одной машинке уезажет время. На несколько часов в сутки. ntp никакого нет, но мне почему-то кажется, что это все равно не порядок :) Чипсет 865. Проц - P4 2.6 с включенным HT. /dev/rtc есть. udev стоит. Что это может быть? -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 02:58:19PM +0300, Alexander Burnos wrote: > On Wed, Aug 08, 2007 at 12:40:10PM +0400, Stanislav Maslovski wrote: > > > root#billy[0]~>hwclock --debug --systohc --utc > > > hwclock from util-linux-2.12p > > > hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. > > > No usable clock interface found. > > > Cannot access the Hardware Clock via any known method. > > > root#billy[0]~>modprobe -l | g rtc > > > root#billy[0]~> > > > > > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > > > # CONFIG_HPET_EMULATE_RTC is not set > > > CONFIG_RTC=y > > > CONFIG_HPET_RTC_IRQ=y > > > # CONFIG_RTC_CLASS is not set > > > root#billy[0]/usr/src> > > > > ls -l /dev/rtc ? > ls: /dev/rtc: No such file or directory > > udev ? > Нету, но ядро 2.6. Поставил udev, девайс создан. root#billy[0]~>ntpdate pool.ntp.org 8 Aug 08:19:25 ntpdate[17702]: adjust time server 141.82.30.251 offset -0.007811 sec root#billy[0]~>echo "0.0 0 0.0" >/etc/adjtime root#billy[0]~>hwclock --systohc --utc Все прошло успешно. Наблюдаю как будет себя вести.. Только вот все равно машина себя как-то странно ведет. Вроде как подмирает переодически. Попробую при буте noapic сделать, только вот непонятно почему она раньше работала безпроблемно, а тут вдруг выдала. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 04:11:25PM +0400, Alexander GQ Gerasiov wrote: > > > > root#billy[0]~>hwclock --debug --systohc --utc > > > > hwclock from util-linux-2.12p > > > > hwclock: Open of /dev/rtc failed, errno=2: No such file or > > > > directory. No usable clock interface found. > > > > Cannot access the Hardware Clock via any known method. > > > > root#billy[0]~>modprobe -l | g rtc > > > > root#billy[0]~> > > > > > > > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > > > > # CONFIG_HPET_EMULATE_RTC is not set > > > > CONFIG_RTC=y > > > > CONFIG_HPET_RTC_IRQ=y > > > > # CONFIG_RTC_CLASS is not set > > > > root#billy[0]/usr/src> > > > > > > ls -l /dev/rtc ? > > > > ls: /dev/rtc: No such file or directory > > > > > udev ? > > > > Нету, но ядро 2.6. > Ты, конечно ценитель %) Честное слово, еще не возникала необходимость udev юзать. Как-то все без него летало, ну и ладно. Слыхать слыхивал, руками не трогал :) Даже неудобно как-то :) > Либо используй удев, либо таки создай устройство сам. Уже поставил. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
На Wed, 8 Aug 2007 14:58:19 +0300 Alexander Burnos <[EMAIL PROTECTED]> записано: > Hello! > > On Wed, Aug 08, 2007 at 12:40:10PM +0400, Stanislav Maslovski wrote: > > > root#billy[0]~>hwclock --debug --systohc --utc > > > hwclock from util-linux-2.12p > > > hwclock: Open of /dev/rtc failed, errno=2: No such file or > > > directory. No usable clock interface found. > > > Cannot access the Hardware Clock via any known method. > > > root#billy[0]~>modprobe -l | g rtc > > > root#billy[0]~> > > > > > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > > > # CONFIG_HPET_EMULATE_RTC is not set > > > CONFIG_RTC=y > > > CONFIG_HPET_RTC_IRQ=y > > > # CONFIG_RTC_CLASS is not set > > > root#billy[0]/usr/src> > > > > ls -l /dev/rtc ? > > ls: /dev/rtc: No such file or directory > > > udev ? > > Нету, но ядро 2.6. Ты, конечно ценитель %) Либо используй удев, либо таки создай устройство сам. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 12:40:10PM +0400, Stanislav Maslovski wrote: > > root#billy[0]~>hwclock --debug --systohc --utc > > hwclock from util-linux-2.12p > > hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. > > No usable clock interface found. > > Cannot access the Hardware Clock via any known method. > > root#billy[0]~>modprobe -l | g rtc > > root#billy[0]~> > > > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > > # CONFIG_HPET_EMULATE_RTC is not set > > CONFIG_RTC=y > > CONFIG_HPET_RTC_IRQ=y > > # CONFIG_RTC_CLASS is not set > > root#billy[0]/usr/src> > > ls -l /dev/rtc ? ls: /dev/rtc: No such file or directory > udev ? Нету, но ядро 2.6. > > > > > Материнка случаем не NForce2? > > NForce точно, NForce2 именно ли - не знаю, lspci не показывает, в dmesg > > не вижу. Машина удаленная. Как можно точно проверить? > > На NForce такое наблюдалось c 2.6 ядрами, workaround - "noapic" в опциях ядра. Спасибо, попробую. > У Вас не amd64 случаем? Железо точно не менялось? amd64, Вы просто телепат :) Простите что приходится выпытывать из меня все. Железо точно не менялось, даже не было ребута. Все началось внезапно. > Сделайте-ка вот что: > > # while true; do cat /proc/interrupts; sleep 1; done > > шквала прерываний нигде не видим? Нет, вроде все в норме, соизмеримо с другими аналогичными серверами. Я, конечно, бутну его с noapic и, кажется мне, что проблема должна исчезнуть. Но хотелось бы понять ее природу, пока она воспроизводима. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
On Wed, Aug 08, 2007 at 10:44:56AM +0300, Alexander Burnos wrote: [ скипнуто ] > root#billy[0]~>hwclock --systohc --utc > Cannot access the Hardware Clock via any known method. > Use the --debug option to see the details of our search for an access > method. > root#billy[0]~>hwclock --debug --systohc --utc > hwclock from util-linux-2.12p > hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. > No usable clock interface found. > Cannot access the Hardware Clock via any known method. > root#billy[0]~>modprobe -l | g rtc > root#billy[0]~> > > root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 > # CONFIG_HPET_EMULATE_RTC is not set > CONFIG_RTC=y > CONFIG_HPET_RTC_IRQ=y > # CONFIG_RTC_CLASS is not set > root#billy[0]/usr/src> ls -l /dev/rtc ? udev ? > > > Материнка случаем не NForce2? > > NForce точно, NForce2 именно ли - не знаю, lspci не показывает, в dmesg > не вижу. Машина удаленная. Как можно точно проверить? На NForce такое наблюдалось c 2.6 ядрами, workaround - "noapic" в опциях ядра. У Вас не amd64 случаем? Железо точно не менялось? Сделайте-ка вот что: # while true; do cat /proc/interrupts; sleep 1; done шквала прерываний нигде не видим? -- Stanislav
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 10:10:32AM +0400, Stanislav Maslovski wrote: > В догонку: > Если дело было не в слишком большой разнице во времени на момент (ре)старта > сервера, то проверьте настройки ntpd. Попробуйте удалить/обнулить drift файл > ntpd. Где-то в /var/lib/ntp/... Ессно, ntpd надо бы стопануть перед/стартануть > после. Нет, тут с рестартом ничего связано не было, увы. Кстати, забыл сказать, вместе с ростом offset'а времени также на сервере были и всплески load'а очень резкие. Вроде как la 0.9, через пару секунд la 30 и сразу же начинает спадать. Причину всплесков я на тот момент не увидел, но вплески вроде как ушли, а время убегать продолжило. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
Hello! On Wed, Aug 08, 2007 at 09:33:11AM +0400, Stanislav Maslovski wrote: > > На одном из серверов (sarge) стало убегать время. Началось это буквально > > сегодня. > > Стоит и запущен openntpd. > > Синхронизирую ntpdate'ом, за час время уходит на 20-30 секунд. > > ntpdate -q pool.ntp.org > > server 91.102.248.122, stratum 3, offset 22.093132, delay 0.14041 > > 7 Aug 19:02:41 ntpdate[16255]: step time server 91.102.248.122 offset > > 22.093132 sec > > Вот такое набежало примерно за час после очередной синхронизации. > > Куда бы посмотреть, что это может быть? > > Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно > велико (по модулю): Было так: root#billy[0]~>cat /etc/adjtime 0.00 110300 0.00 110300 UTC > # ntpdate pool.ntp.org > # echo "0.0 0 0.0" >/etc/adjtime > # hwclock --systohc --utc > root#billy[0]~>ntpdate pool.ntp.org 8 Aug 03:39:59 ntpdate[13406]: step time server 88.198.44.10 offset 717.269688 sec Это уже за ночь набежало. root#billy[0]~>hwclock --systohc --utc Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. root#billy[0]~>hwclock --debug --systohc --utc hwclock from util-linux-2.12p hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. No usable clock interface found. Cannot access the Hardware Clock via any known method. root#billy[0]~>modprobe -l | g rtc root#billy[0]~> root#billy[0]/usr/src>grep -i rtc /boot/config-2.6.20.1 # CONFIG_HPET_EMULATE_RTC is not set CONFIG_RTC=y CONFIG_HPET_RTC_IRQ=y # CONFIG_RTC_CLASS is not set root#billy[0]/usr/src> > Материнка случаем не NForce2? NForce точно, NForce2 именно ли - не знаю, lspci не показывает, в dmesg не вижу. Машина удаленная. Как можно точно проверить? -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: убегает время
08.08.07, Stanislav Maslovski <[EMAIL PROTECTED]> написал(а): > > On Wed, Aug 08, 2007 at 09:33:11AM +0400, Stanislav Maslovski wrote: > > On Wed, Aug 08, 2007 at 02:07:48AM +0300, Alexander Burnos wrote: > > > Приветствую! > > > > > > На одном из серверов (sarge) стало убегать время. Началось это > буквально > > > сегодня. > > > Стоит и запущен openntpd. > > > > > > Синхронизирую ntpdate'ом, за час время уходит на 20-30 секунд. > > > > > > ntpdate -q pool.ntp.org > > > server 91.102.248.122, stratum 3, offset 22.093132, delay 0.14041 > > > 7 Aug 19:02:41 ntpdate[16255]: step time server 91.102.248.122 offset > 22.093132 sec > > > > > > Вот такое набежало примерно за час после очередной синхронизации. > > > > > > Куда бы посмотреть, что это может быть? > > > > Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно > > велико (по модулю): > > > > # ntpdate pool.ntp.org > > # echo "0.0 0 0.0" >/etc/adjtime > > # hwclock --systohc --utc > > > > Материнка случаем не NForce2? > > В догонку: > Если дело было не в слишком большой разнице во времени на момент > (ре)старта > сервера, то проверьте настройки ntpd. Попробуйте удалить/обнулить drift > файл > ntpd. Где-то в /var/lib/ntp/... Ессно, ntpd надо бы стопануть > перед/стартануть > после. > > -- > Stanislav > > А у меня просто время накручивается само по себе в Etch. Где крутить?
Re: убегает время
On Wed, Aug 08, 2007 at 09:33:11AM +0400, Stanislav Maslovski wrote: > On Wed, Aug 08, 2007 at 02:07:48AM +0300, Alexander Burnos wrote: > > Приветствую! > > > > На одном из серверов (sarge) стало убегать время. Началось это буквально > > сегодня. > > Стоит и запущен openntpd. > > > > Синхронизирую ntpdate'ом, за час время уходит на 20-30 секунд. > > > > ntpdate -q pool.ntp.org > > server 91.102.248.122, stratum 3, offset 22.093132, delay 0.14041 > > 7 Aug 19:02:41 ntpdate[16255]: step time server 91.102.248.122 offset > > 22.093132 sec > > > > Вот такое набежало примерно за час после очередной синхронизации. > > > > Куда бы посмотреть, что это может быть? > > Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно > велико (по модулю): > > # ntpdate pool.ntp.org > # echo "0.0 0 0.0" >/etc/adjtime > # hwclock --systohc --utc > > Материнка случаем не NForce2? В догонку: Если дело было не в слишком большой разнице во времени на момент (ре)старта сервера, то проверьте настройки ntpd. Попробуйте удалить/обнулить drift файл ntpd. Где-то в /var/lib/ntp/... Ессно, ntpd надо бы стопануть перед/стартануть после. -- Stanislav
Re: убегает время
On Wed, Aug 08, 2007 at 02:07:48AM +0300, Alexander Burnos wrote: > Приветствую! > > На одном из серверов (sarge) стало убегать время. Началось это буквально > сегодня. > Стоит и запущен openntpd. > > Синхронизирую ntpdate'ом, за час время уходит на 20-30 секунд. > > ntpdate -q pool.ntp.org > server 91.102.248.122, stratum 3, offset 22.093132, delay 0.14041 > 7 Aug 19:02:41 ntpdate[16255]: step time server 91.102.248.122 offset > 22.093132 sec > > Вот такое набежало примерно за час после очередной синхронизации. > > Куда бы посмотреть, что это может быть? Проверьте, что у Вас в /etc/adjtime. Если первое число пододозрительно велико (по модулю): # ntpdate pool.ntp.org # echo "0.0 0 0.0" >/etc/adjtime # hwclock --systohc --utc Материнка случаем не NForce2? -- Stanislav
