Мы запускаем блоки RHEL 6 на HyperV с Windows Server 2012. На некоторых из наших блоков RHEL я вижу эту ошибку в / var / log / messages
kernel: Clocksource tsc unstable (delta = -62519781 ns). Enable clocksource failover by adding clocksource_failover kernel parameter.
Текущий источник часов -
[root@server ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hyperv_clocksource
И доступные источники часов -
[root@server ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hyperv_clocksource tsc acpi_pm jiffies
Мой вопрос - 1. Почему сервер жалуется на tsc, когда источником синхронизации является HyperV? 2. Какой источник синхронизации я должен выбрать в качестве аварийного?
P.S - Я знаю решение Red Hat - https://access.redhat.com/site/solutions/434883. Мне просто интересно, почему это происходит?
Для тех, у кого нет RedHat Access, решение выглядит следующим образом:
Измените источник часов на другие доступные часы в системе Сначала найдите доступные источники системных часов:
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
**** Пример результатов ниже: *
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
Затем проверьте текущий используемый источник синхронизации:
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
**** Пример результатов ниже: *
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Наконец, установите новый источник часов:
echo <new clock source selection> > /sys/devices/system/clocksource/clocksource0/current_clocksource
Чтобы сделать это изменение постоянным при перезагрузке системы, в командную строку ядра в /boot/grub/grub.conf необходимо добавить следующее:
clocksource=<clock source choice>
Жалоба заключается только в том, что он вынужден отказаться от установленного по умолчанию TSC, и у вас нет модуля для определения лучшего из них. Очевидно, он уже выбирает правильный, так что это не проблема.
Предупреждение есть только для того, чтобы вы знали, что делать, если ядро по умолчанию выбирает неправильный альтернативный источник синхронизации.
Что касается того, почему таймер TSC не производит надежный таймер, это может быть ошибкой в программном обеспечении виртуальной машины. Вы можете проверить руководство к своей виртуальной машине. Также есть ошибки в некоторых процессорах с C-State 2 и более низкими состояниями ожидания CPU, нарушающими таймер TSC. В любом случае я не думаю, что это серьезная проблема.