当唯一的其他时钟源是jiffies时,clocksource总是不稳定吗?

在debugging我公司产品的BIOS不稳定的tsc问题之后,我怀疑tsc可能总是不稳定,只有其他时钟源是jiffies。

我得到了Clocksource tsc unstable (delta = -531266231 ns). 然后内核select除了TSC之外的jiffies。 唯一的两个时钟源是tsc和jiffies。 我尝试了Linux内核2.6和3.2与i386和x64。 内核说CPU实际上支持常数tsc和不变的tsc。

在检查了Linux源代码后,我发现tsc有一个CLOCKSOURCE_MUST_VERIFY标志,而jiffies没有。 我想,如果只有两个时钟源,jiffies和tsc,jiffies将成为clocksource看门狗。 然而,与tsc相比,jiffies是一个非常差的时钟源,因此我怀疑这种情况下的tsc将总是“不稳定”,因为有一个不好的监视器来validation它。

我也检查了一些其他系统工作良好,发现他们有其他的时钟资源,如Hpet或acpi_pm。

因此,如何判断tiff不稳定是由jiffies引起的还是其他地方的错误?

今天我用最小的安装测试了CentOS 6.6 i386映像。 内核默认有三个时钟源: tsc acpi_pm jiffies 。 Clocksource tsc是正在使用的。

然后我尝试了acpi=off选项,发现只有两个clocksources, tsc jiffies 。 然而,TSC并不稳定,仍然是主要的时钟源。 因此,看门狗永远不会总是否认tsc。

我在戴尔桌面上进行了上述实验。 但是,在另外一台使用我公司BIOS的硬盘驱动器中,tsc仍然不稳定(也只有两个时钟源:tsc和jiffies,但使用了jiffies)。 我怀疑是有关于BIOS的问题。 我知道我的BIOS不支持acpi,但是我不确定这是为什么。

因此,跳转到另一个问题:在BIOS中有一些配置会导致tsc不稳定吗? 我的BIOS支持Intel CPU,并且已经禁用CPU电源管理。

在Linux上 – 在用户应用程序中 – 读取时间(7) ,不要直接使用TSC,而是使用clock_gettime(2) (可能与CLOCK_REALTIME )。

如果计算机连接到Internet,请安装一些NTPD客户端守护程序。

经过一番实验,我得出了一个暂时的结论: tsc稳定性与ACPI的设定有关。 我用Aptio BIOS版本2.15.1236和标准的Linux内核3.2.68进行了测试。

起初,我在内核配置中打开了ACPI,并构建了一个acpi_pm ,其tsc效果很好(使用其他clocksource acpi_pmhpet )。 另外,即使通过在内核命令行中使用acpi=off来禁用acpi,clocksource tsc仍然可以和clocksource jiffies

第二次关闭内核配置中的ACPI。 在这个时候,clocksource tsc在构建的内核映像中是不稳定的。 唯一剩下的时钟源是jiffies

经过一些其他的实验,我怀疑当BIOS和内核都支持ACPI时,tsc只是稳定的。 我检查了一些论坛,并被告知ACPI在Linux启动命令行中即使使用acpi=off也没有完全关闭。 我公司自己的BIOS在ACPI表上有一些bug,因此在Linux内核映像中不能保持稳定的tsc。

但是,这只是我的猜测。 我希望有专家告诉我,我是对还是错。 我将尝试修复我公司BIOS的ACPI表错误,并更新我的进一步实验的结果。