From: Scott Cheloha <scottcheloha@gmail.com>
Subject: timecounting: start system uptime at 0.0, not 1.0
To: tech@openbsd.org
Cc: patrick@openbsd.org
Date: Sun, 18 Feb 2024 18:25:19 -0600

The system uptime starts at 1.0.  We inherited this from FreeBSD [1].
My best guess is that something in FreeBSD depended (depends?) on the
uptime being non-zero during boot.

patrick@ says this causes a problem in sdmmc(4).  In particular, the
sdmmc_delay() call during sdmmc_enable() doesn't block the full 250ms.
This is because the hardclock() starts at 0.0 and executes about hz
times, rapidly, to "catch up" to 1.0.

Initializing th_offset to 0.0 fixes the problem: sdmmc_delay() blocks
for the expected duration.

ok?

[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_tc.c?annotate=1.1

        !            76: static struct timehands th0 = {
        !            77:        &dummy_timecounter,
        !            78:        0,
        !            79:        (uint64_t)-1 / 1000000,
        !            80:        0,
->      !            81:        {1, 0},
        !            82:        {0, 0},
        !            83:        {0, 0},
        !            84:        1,
        !            85:        &th1
        !            86: };

Index: kern_tc.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_tc.c,v
diff -u -p -r1.82 kern_tc.c
--- kern_tc.c	4 Feb 2023 19:19:36 -0000	1.82
+++ kern_tc.c	18 Feb 2024 00:46:22 -0000
@@ -96,7 +96,7 @@ static struct timehands th1 = {
 static struct timehands th0 = {
 	.th_counter = &dummy_timecounter,
 	.th_scale = UINT64_MAX / 1000000,
-	.th_offset = { .sec = 1, .frac = 0 },
+	.th_offset = { .sec = 0, .frac = 0 },
 	.th_generation = 1,
 	.th_next = &th1
 };
@@ -117,7 +117,7 @@ static SLIST_HEAD(, timecounter) tc_list
  * examining kernel core dumps.
  */
 volatile time_t naptime = 0;
-volatile time_t time_second = 1;
+volatile time_t time_second = 0;
 volatile time_t time_uptime = 0;
 
 static int timestepwarnings;