microuptime() went backwards.
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Fri May 9 07:28:46 PDT 2003
On Thu, 8 May 2003, Junwen Lai wrote:
> > May 8 20:01:51 FeliX /kernel: microuptime() went backwards (39515.922679 -> 15.898650)
> this happens when you change the system time, either by running "time"
> explicitly or using something like ntptime. Not a big deal, just ignore
I still can reproduce it by doing heavy disk IO, eg. nightly backups
to my amanda server. This happens w/ and w/o ntpd running (external
Suggestions from other PRs with apm etc. didn't help. Someone said
it's because of the VIA chipset but changing the motherboard is not a
The time I first saw it was the first time of greater moves around
filesystems after I turned softupdates on.
Further more - before I had the external clock - I had times the next
morning in the range from yesterday eve to the day high noon.
I still sometimes have probs with nightly periodic scripts running
At the moment this is a 4.7-STABLE box. I will update to 5-CURRENT
once I find the time and see. I haven't checked the peace of code
around thos messages there nbut at least someone removed or changed
the 'microuptime() went backwards' log messages from what I could see.
One last note: the problem here is that when logging kern.* to syslog
the microuptime() went backwards warnings may produce a huge amount of
log data (up to 50MB) and thus will also add some more disc IO so this
may make the situation even worse. I didn't rebuild may latest kernels
with some rate limiting for those logs included. I may help to exclude
the '(39515.922679 -> 15.898650)' from logging so syslog can aggregate
For more information you may check the ml archives and search (closed)
PRs on the topic.
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
More information about the freebsd-hackers