On Wed, 19 Dec 2001, Matthew Dillon wrote: > I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks > running in parallel): > > microuptime() went backwards (44525.3954411 -> 44524.563978) > microuptime() went backwards (57425.4282241 -> 57424.766121) > microuptime() went backwards (57425.4282241 -> 57424.845844) > microuptime() went backwards (60724.4427887 -> 60724.686232) > microuptime() went backwards (60724.4427887 -> 60724.768808) > microuptime() went backwards (61685.4418845 -> 61685.102724) > microuptime() went backwards (61924.3906516 -> 61924.246151) > microuptime() went backwards (62344.3800035 -> 62344.415407) > > Anyone know what's up?
This has been asked on just about every FreeBSD list since the printf was added. Use the archives, man! :) This is when you have a device generating too much interrupt latency -- enough to stall the RTC. Usually the offender is video cards, but in this case it could be your IDE controller. The usual fix is to try changing timecounters; sysctl kern.timecounter.hardware tells you what you're currently using. If you're on CURRENT, it's probably using ACPI. If you want to override it back to TSC, put 'hint.acpi_timer.0.disabled="1"' in your /boot/device.hints. Also try compiling with or without apm since this influences the timecounter as well (although if you're on SMP you might be stuck with the i8254). phk can clarify. :) Doug White | FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
