microuptime() went backwards.

[Bjoern A. Zeeb]

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
> it.

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
clock connected).
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
solution.

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
twice :(

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
the messages.

For more information you may check the ml archives and search (closed)
PRs on the topic.

-- 
Greetings

Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/