Re: calcru: runtime went backwards (and lock order reversal)

On 6/6/08, Gardner Bell <gbell72_at_rogers.com> wrote:
> Hello,
>
> I'm seeing the following printed on my screen after my system became
> unresponsive while background fsck was running for ~10 mins or so.
> Previous to this, my machine crashed after a power outage in my
> neighborhood.
>
> Copyright (c) 1992-2008 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994
>         The Regents of the University of California. All rights
> reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.0-CURRENT #0: Wed May 28 10:43:47 EDT 2008
>     root_at_home:/usr/obj/usr/src/sys/TYAN
>
> lock order reversal:
>  1st 0xffffff0001282430 snaplk (snaplk) _at_
> /usr/src/sys/kern/vfs_vnops.c:292
>  2nd 0xffffff0001750270 ufs (ufs) _at_
> /usr/src/sys/ufs/ffs/ffs_snapshot.c:1578

I'd guess the lock order reversal is more significant than the
"runtime went backwards" messages. See
http://gireeshdn.blogspot.com/2006/12/lock-order-reversals-courtesy-freebsd.html
for more information about what it indicates.

> KDB: stack backtrace:
[...]
> calcru: runtime went backwards from 33275 usec to 290 usec for pid 999
> (csh)
> calcru: runtime went backwards from 469322 usec to 3929 usec for pid
> 999 (csh)
> calcru: runtime went backwards from 13323 usec to 109 usec for pid 998
> (su)
[...etc.]

The "runtime went backwards" errors are common and probably indicate a
problem servicing interrupts, either because of a driver problem or a
hardware problem. For example, on some motherboards, the Intel
SpeedStep implementation is buggy and can cause this error. Often,
changing the method used to update the system clock will solve the
problem. A Google search will give you lots of suggestions.

- Bob