Eric Lowe wrote:
This is a good fix and it solves the problem with early gethrtime()
calls as a
result of cmn_err() calls in mp_startup(). But I do think that slave
TSC clock
synchronization could be moved even higher on the list of things done by
mp_startup(). I'm worried that, for example, if somebody were to change
cpuid_pass1() to call cmn_err() or something else that could call
gethrtime(),
then we'd run into this exact problem again. I'm wondering if procset
bitmap
setting with tsc_sync_slave() call should be the very first thing done by
mp_startup() after splx(ipltospl(LOCK_LEVEL)) call. I think MTRR sync
can be safely done after TSC sync. I'm not so sure about the syscall
handlers though. I'll take a closer look at this and will update the
bug report.
And, while you're at it you may want to add a mechanism on DEBUG kernels
to ASSERT that the TSC has been initialized before plowing through
gethrtime(). That way the next poor schmuck to add a cmn_err() call in
the startup path doesn't end up root causing the same bug again.
Yeah; in fact, I'd like to see gethrtime() not use TSC until after the proc
has synced its TSC. We have a Big Switch for when we decide to use TSC,
but it should be per-proc instead of per-system. (gethrtimef being a
pointer makes that easy to do without losing performance in the common,
post-startup case.)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
