Haiku has an inconsistent uptime counter

[haikupr]

On both Haiku R1/beta3 and hrev56595, the uptime counter as reported by uptime(1) and AboutSystem exhibit an inconsistent behavior. For example, a system booted circa 16:19:37 give at 16:23:06 an uptime of 4 hours and 38 minutes, this is obviously incorrect.

I initially though this could be due to a drifting clock, so I logged the value of the counter at boot time for a few days and found surprising values:

2022-11-20T07:25:21+01:00 07:25:21 up 2:39, 0 users
2022-11-20T07:30:37+01:00 07:30:37 up 2:44, 0 users
2022-11-20T07:33:50+01:00 07:33:50 up 2:47, 0 users
2022-11-20T07:35:47+01:00 07:35:47 up 2:49, 0 users
2022-11-20T07:36:20+01:00 07:36:20 up 2:50, 0 users
2022-11-20T08:02:11+01:00 08:02:11 up 3:16, 0 users
2022-11-21T07:19:51+01:00 07:19:51 up 1:17, 0 users
2022-11-21T07:21:28+01:00 07:21:28 up 1:19, 0 users
2022-11-22T06:45:39+01:00 06:45:39 up 0:01, 0 users
2022-11-22T06:49:36+01:00 06:49:36 up 0:05, 0 users
2022-11-22T10:16:27+01:00 10:16:27 up 3:32, 0 users
2022-11-23T06:45:27+01:00 06:45:27 up 0:01, 0 users
2022-11-24T08:26:08+01:00 08:26:08 up 0:01, 0 users
2022-11-24T13:44:56+01:00 13:44:56 up 5:20, 0 users
2022-11-25T12:16:57+01:00 12:16:57 up 1:49, 0 users
2022-11-25T19:03:29+01:00 19:03:29 up 8:35, 0 users
2022-11-26T16:19:37+01:00 16:19:37 up 4:34, 0 users

The log above was produced by the following script:

echo >~/config/settings/boot/launch/track-boot-uptime <<EOF
#!/bin/sh
echo `date --iso-8601=seconds` `uptime` >>/var/log/boot-uptime.log
EOF
chmod +x ~/config/settings/boot/launch/track-boot-uptime

It looks like the value of the counter is usually kept across reboots and is sometime reset to zero or another seemingly random but quite small value for no obvious cause. I expect the uptime counter be zero-set at kernel start time and monotonically tick up for every second the system runs.

Note: The above reported incorrect behavior was observed on systems running as amd64 guests under the control of a bhyve supervisor on a FreeBSD 12.1 host.

[waddlesplash]

Likely this has something to do with bhyve. Please attach a syslog.

[haikupr]

Systen logs of a boot that yield an uptime counter of "2022-11-26T18:47:26+01:00 18:47:26 up 7:02, 0 users"

[haikupr]

Haiku is started in UEFI mode with the following synthesized command:

bhyve -w -H -u -c 1 -m 2G -l bootrom,${HOME}/zoo/firmwares/BHYVE_UEFI-0.2_1,1.fd -s 0,hostbridge -s 31:0,lpc -s 29,fbuf,tcp=0.0.0.0:5904,w=800,h=600 -s 30,xhci,tablet -s 4:0,virtio-blk,/dev/zvol/zoo/haiku-nightly -s 5:0,virtio-net,tap4 haiku-nightly

On the same host I also have an Omnios guest, similarly strated, that has no issue with its uptime counter.

[haikupr]

Since the initial report I have updated the host to FreeBSD-12.4, now I usually no longer observe uptime inconsistencies. The latest occurred on 2022-12-21 (eight days after the update to 12.4), but none were seen up to today. I surmise there was some sort of interaction between the host, the hypervisor and Haiku that was resolved in Haiku's source tree between December 21st and 24th.

[...]
2022-12-12T19:06:19+01:00 19:06:19 up 0:00, 0 users
2022-12-13T13:22:40+01:00 13:22:40 up 0:00, 0 users
2022-12-13T13:29:25+01:00 13:29:25 up 0:00, 0 users
2022-12-13T15:01:01+01:00 15:01:01 up 0:00, 0 users
2022-12-13T15:01:57+01:00 15:01:57 up 0:00, 0 users
2022-12-13T15:04:02+01:00 15:04:02 up 0:00, 0 users
2022-12-13T15:17:40+01:00 15:17:41 up 0:00, 0 users
2022-12-13T16:47:56+01:00 16:47:56 up 0:13, 0 users
2022-12-13T16:55:55+01:00 16:55:55 up 0:00, 0 users
2022-12-13T17:00:53+01:00 17:00:54 up 0:00, 0 users
2022-12-13T17:20:22+01:00 17:20:23 up 0:00, 0 users
2022-12-13T18:26:42+01:00 18:26:42 up 0:00, 0 users
2022-12-13T18:36:45+01:00 18:36:45 up 0:00, 0 users
2022-12-14T12:42:39+01:00 12:42:39 up 0:01, 0 users
2022-12-17T14:51:21+01:00 14:51:21 up 0:00, 0 users
2022-12-21T15:24:42+01:00 15:24:42 up 0:24, 0 users
2022-12-24T20:08:47+01:00 20:08:47 up 0:01, 0 users
2022-12-24T20:49:53+01:00 20:49:53 up 0:01, 0 users
2022-12-29T12:00:31+01:00 12:00:31 up 0:01, 0 users
2022-12-29T12:45:54+01:00 12:45:54 up 0:00, 0 users
2022-12-31T19:03:30+01:00 19:03:30 up 0:01, 0 users
[...]

I think this ticket can now be closed.

[waddlesplash]

I don't see any commits in that timeframe which seem like probable explanations. But thanks for testing.