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. - BobReceived on Fri Jun 06 2008 - 20:51:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:31 UTC