- I booted kernels both with and without EARLY_AP_STARTUP with the included
test callouts (which I will remove for the actual commit).
One oddity is that the timers actually fire about 1 second too early.
That is, sbinuptime() is about 1 second when the test SYSINIT runs,
but the time base that the delta is added to is pulled from
DPCPU_GET(hardclocktime) which is 0. So sample output:
CALLOUT: uptime at test start: 4294988770
CALLOUT: time when starting: 4295388202
CALLOUT: 1 second fired at 5417817195
CALLOUT: 2 second fired at 8671043041
CALLOUT: 4 second fired at 17283412636
CALLOUT: 10 second fired at 42952326079
If you examine the values in hex you get 0x1000053e2 for the test start
and 0x100066c2a when the timers start. The first callout fires about a
quarter of a second later at 0x142ed546b. The remaining callouts are
all about a second early: 0x204d59de1, 0x4062bf29c, and 0xa00287bbf.
I could "fix" this by patching callout_when() to use sbinuptime() as
the time base instead of DPCPU_GET() before timer interrupts are
initialized, or we could just let it be?
Also, I had originally suggested to still panic in the sleepq code
for thread0, so if that is desired I can restrict the panic that this
removes to only be for thread0.
Finally, callout_reset() that is too early should panic due to
cc_inited == 0 check in callout_reset_sbt_on(), so need to add a new
check for that.