Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Feb 2002 21:17:34 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        David Greenman <dg@root.com>
Cc:        <bugs@FreeBSD.ORG>
Subject:   Re: [legg@iastate.edu: Serious exception in FreeBSD found]
Message-ID:  <20020206210601.Y2405-100000@gamplex.bde.org>
In-Reply-To: <20020205161313.B19463@nexus.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Feb 2002, David Greenman wrote:

> ----- Forwarded message from Tim Legg <legg@iastate.edu> -----
> ...
> The tar file was being produced when the ttyv0 was being filled with
> messages.  Here is an example:
>
> Feb 5 17:43:56 pc047113 /kernal: microuptime() went backwards (1550895.778303 -> 1550895.-694593171)
> Feb 5 17:43:56 pc047113 /kernal: microuptime() went backwards (1550895.839382 -> 1550895.832517)
> Feb 5 17:43:56 pc047113 /kernal: microuptime() went backwards (1550895.291637 -> 1550895.274690)

I fixed the one cause of negative tv_usec's recently (rev.1.111 of
kern_tc.c and rev.1.105.2.7 of kern_clock.c), but this tends to make
the spew of error messages worse if the timecounter actually goes
backwards.  Previously the timestamp comparisons were confused enough
by the invalid tv_usec's to limit the spew.  Since tv_usec went negative,
we almost know that timecounter update was delayed for more than
(1 - 1/hz) seconds.  This can only happen if there are serious interrupt
latency bugs elsewhere.

> This made my /var/log/messages extremely huge very quickly.  My
> /var/log/messages was growing at a rate of approximately 70,000 lines per
> minute.

This is another example of why non-critical kernel printfs should be
rate-limited.  The "vm_fault: pager read error" regularly fills up
my /var when I abuse nfs (run make install on the server).

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020206210601.Y2405-100000>