https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216759
--- Comment #13 from [email protected] <[email protected]> --- 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[email protected]"
