On Tue, 3 May 2016, Mark Kettenis wrote: > I think the answer is that we should set CPUF_PRIMARY earlier. In fact > we can set it in the initializer of cpu_info_primary. I'll need to > check i386 as well.
Beware, i386 is weird: quoting i386/machdep.c: * Note that identifycpu() is called twice for the primary CPU: the first * is very early (right after the "OpenBSD X.Y" line) with the CPUF_PRIMARY * flag *not* set, then again later in the config sequence with CPUF_PRIMARY * set. Thus, the tests here for ((ci->ci_flags & CPUF_PRIMARY) == 0) are * actually saying "do this on the first call for each CPU". Don't change * them to use CPU_IS_PRIMARY() because then they would be done on both * calls in the SP build. Setting CPUF_PRIMARY early without doing something about the tests and/or rearranging the calls on the primary CPU will cause problems. Philip
