我们在 HyperV 上运行 RHEL 6 系统,使用的是 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. 当时钟源是 HyperV 时,为什么服务器会抱怨 tsc? 2. 我应该选择哪个时钟源作为故障转移?
PS-我知道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>
答案1
投诉只是它必须从默认的 TSC 中恢复,而您没有模块来检测最佳的 TSC。显然它已经选择了正确的 TSC,所以这不是问题。
这个警告只是为了让你知道如果内核默认选择了错误的替代时钟源该怎么做。
至于为什么 TSC 计时器没有产生可靠的计时器,这可能是虚拟机软件中的一个错误。您可能需要查看虚拟机手册。某些处理器中也存在勘误表,其中 C 状态 2 和较低的 CPU 空闲状态会干扰 TSC 计时器。无论如何,我认为这不是一个主要问题。