On Fri, 8 Apr 2011, Jung-uk Kim wrote:
Log: Refactor DELAYDEBUG as it is only useful for correcting i8254 frequency.
Er, DELAYDEBUG has nothing to do with the i8254 except that the non-i8254 case was broken (mostly in unreachable code, and missing instrumentation corresponding to the getit_calls counter). Now it is more broken -- e.g., configuring DELAYDEBUG now prevents the non-i8254 timers from even being compiled. The core of DELAYDEBUG was essentially just: for (n1 = 1; n1 <= 10000000; n1 *= 10) { printf("DELAY(%d)...", n1); DELAY(n1); printf("done\n"); } This could be in an extern function, and works for any implementation of DELAY(). You observe the resulting delays and fix them if they are too short or too long (the observation can only be done fairly accurately for the 2 or 3 final delays of 1/10, 1 and 10 seconds, unless these are very inaccurate). But it is implemented as a special state in DELAY() itself, with the printfs separate from the loop, for convenience and to allow the printfs to print implementation-specific details. Perhaps the complications for the state are not useful for debugging the i8254 case now, since the i8254 has a fixed frequency and is well understood and debugged. The delay_timecounter() case doesn't even need to be debugged at this level, since if the timecounter is broken then this will be obvious from userland. But the complications are useful for the delay_tsc() case, since the TSC doesn't have a fixed frequency and is often miscalibrated. Bruce _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"