[ ...combining two emails... ] On Sep 13, 2011, at 9:49 AM, Brett Glass wrote: > If that's indeed the case, the kernel must be doing the math wrong.
While there have undoubtedly have been kernel bugs with timekeeping (and there may be more still present), it's not uncommon for hardware issues to cause one or more of the available time sources to be broken. On a good day, the clock source is broken obviously enough that the kernel notices it during testing during boot and gives it a negative quality score. Other times, the clock becomes broken only after the box suspends and resumes from an ACPI S# state, or does frequency changes for power/thermal management, etc. > Ironically, it was the kernel that selected the ACPI timer, scoring it higher > than the timestamp counter as a clock source. Perhaps code should be added to > ensure that the timer is not chosen if it rolls over in less than a second, > since this clearly leads to imprecision and missed rollovers. The kernel attempts to notice problems when it probes for the various clocks during boot (ie, dev/acpica/acpi_hpet.c, dev/acpica/acpi_timer.c, etc); for ACPI, see acpi_timer_probe() & acpi_timer_test(). Regards, -- -Chuck _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
