我有一个 Debian Buster 系统,其内核编译时没有使用CONFIG_RTC_SYSTOHC
11 分钟内核模式,因为我不希望打开 11 分钟内核模式。然而,我想检查一下这个改变是否真的有效。
所以我检查了命令status
输出中的字段adjtimex --print
。该status
字段是24577
或0b110000000000001
。
根据此处的手册页 -https://linux.die.net/man/8/adjtimex,似乎该字段64
的位status
是not set
,根据这里:https://access.redhat.com/solutions/55432表示已11-minute mode
开启。
CONFIG_RTC_SYSTOHC
这与我使用as编译内核时的预期相矛盾not set
。如何可靠地检查 11 分钟模式是否确实关闭,或者我是否adjtimex
错误地解释了输出?
答案1
(只是为了消除阅读此答案的任何人可能会产生的困惑:当 Linux 运行时,(通常)有两个时钟:“主”时钟是系统时钟,通常基于 CPU。另一个时钟是持久硬件时钟(RTC)。当系统关闭时,系统时钟会丢失其时间,只有持久硬件时钟保持正确的挂钟时间。)
该字段的64
位的主要含义是“系统时钟是否正在被NTP或其他时间源同步”。 11 分钟模式过去与此紧密耦合:如果系统时钟正在同步,则 RTC 将每 11 分钟更新一次;如果系统时钟正在同步,则 RTC 将每 11 分钟更新一次;如果没有,那就不会了。status
adjtimex
每隔 11 分钟禁用系统时钟到 RTC 传输的选项CONFIG_RTC_SYSTOHC
是后来添加的。
禁用CONFIG_RTC_SYSTOHC
会切断系统时钟同步和 RTC 11 分钟更新之间的连接。可以查看相关的内核源码,在Debian Buster的标准4.19.xx内核中就是这个sync_rtc_clock()
函数kernel/time/ntp.c 第 #532 行。您可以看到,当CONFIG_RTC_SYSTOHC
未设置时,函数会提前返回而不执行任何操作:
static void sync_rtc_clock(void)
{
unsigned long target_nsec;
struct timespec64 adjust, now;
int rc;
if (!IS_ENABLED(CONFIG_RTC_SYSTOHC)) <--- If CONFIG_RTC_SYSTOHC is not enabled,
return; <--- return immediately.
ktime_get_real_ts64(&now);
adjust = now;
if (persistent_clock_is_local)
adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
/*
* The current RTC in use will provide the target_nsec it wants to be
* called at, and does rtc_tv_nsec_ok internally.
*/
rc = rtc_set_ntp_time(adjust, &target_nsec);
if (rc == -ENODEV)
return;
sched_sync_hw_clock(now, target_nsec, rc);
}
换句话说,禁用实际上CONFIG_RTC_SYSTOHC
会导致11-minute mode
无操作。
更具实验性的是,您可以使用内核分析工具在 11 分钟的合适倍数内监视该rtc_set_time()
函数,并查看调用它的频率。如果你发现答案是0次,你就知道硬件RTC时钟没有被11分钟模式调整也不通过其他任何东西。