Download raw body.
timecounting: start system uptime at 0.0, not 1.0
On Sun, Feb 18, 2024 at 06:25:19PM -0600, Scott Cheloha wrote:
> 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?
I can't judge why it's at 1.0 and not 0.0, but a tsleep() during HW init
not waiting for as long as we asked it to wait for... can wreak heavoc.
This works for me, ok patrick@ FWIW
> [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;
timecounting: start system uptime at 0.0, not 1.0