https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216759

--- Comment #13 from bob.caut...@gmail.com <bob.caut...@gmail.com> ---

As an interested party to this bug I have to raise an issue with this potential
workaround.

First though... thanks everybody who discovered and tested this... BUT

According to timecounters(4):

     kern.timecounter.tc.X.quality is an integral value, defining the quality
     of this time counter compared to others.  A negative value means this
     time counter is broken and should not be used.


Andrew's test output showed this line:

Timecounter "TSC-low" frequency 1700064513 Hz quality -100

If the workaround forces the use of TSC-low, and it's
kern.timecounter.tc.X.quality is negative, are we not advocating a workaround
with a broken timecounter as measured by the OS?

If the answer is yes (to my rhetorical question) possible follow-up questions
might then be:

- Should we trust the negative "quality" measurement? (if not, maybe it's
easier to mod the timecounter measurement code??)

- Has anyone done any longer term testing with the TSC-low timer in this
configuration to see if using that time counter effects anything else in a
running system?

Sorry to be the opposing voice here (especially because this bug affects me
too).

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Reply via email to