使用 adjtimex 检查 11 分钟内核模式的状态

使用 adjtimex 检查 11 分钟内核模式的状态

我有一个 Debian Buster 系统,其内核编译时没有使用CONFIG_RTC_SYSTOHC11 分钟内核模式,因为我不希望打开 11 分钟内核模式。然而,我想检查一下这个改变是否真的有效。

所以我检查了命令status输出中的字段adjtimex --print。该status字段是245770b110000000000001

根据此处的手册页 -https://linux.die.net/man/8/adjtimex,似乎该字段64的位statusnot 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 分钟更新一次;如果没有,那就不会了。statusadjtimex

每隔 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分钟模式调整也不通过其他任何东西

相关内容