Strange filesystem related console output
    Kris Kennaway 
    kris at FreeBSD.org
       
    Thu Nov 29 11:57:37 PST 2007
    
    
  
Josh Paetzel wrote:
> # uname -a
> FreeBSD services.tcbug.org 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Oct 17 
> 18:54:12 UTC 2007     root at services.tcbug.org:/usr/obj/usr/src/sys/SERVICES  
> amd64
> 
> Yesterday, after many moons of reliable service I awoke to find this box had 
> spontaniously rebooted during the night.  It's a core2quad that doesn't do 
> any one particular thing, but by virtue of all the stuff running on it it 
> stays pretty busy....half dozen jails, mailserver, webserver, pgsql, mysql, 
> occassional build machine so on and so forth.  When I tried to build a 
> package with it it rebooted again about 30 seconds in to the compile....I 
> checked cpu temps, booted a live cd with the hard drive diagnostics, ran 
> memtest....hardware looks fine, which doesn't mean much of course.
> 
> Anyways, I brought the box back up, and it immediately goes in to bg_fsck + 
> gmirror rebuild contention....I try building a package again, and it 
> immediately reboots.
> 
> So I boot it in single user, set the bgfsck_delay to 12 hours and then bring 
> it back up multiuser.  It starts syncing the gmirror, I build my packages, 
> box works fine the rest of the day.....about 12 hours later the fsck starts, 
> and about 20 minutes in to it I get this spammed to the console....
> 
> fsync: giving up on dirty
> 0xffffff00614975d0: tag devfs, type VCHR
>   usecount 1, writecount 0, refcount 1755 mountedhere 0xffffff0005f4c000
>   flags ()
>   v_object 0xffffff00618541c0 ref 0 pages 42464
>   lock type devfs: EXCL (count 1) by thread 0xffffff004facb720 (pid 77517)
>       dev mirror/gm0s1f
> 
> I kept waiting for a panic or another reboot, but it never came.....today the 
> box appears to be back in action.
> 
> I can't help but think this console message is somehow related to the reboots, 
> but no idea what really happened here.
> 
> Any insight apprectiated.....more diagnostic info is always available upon 
> request.
I see this a fair bit under certain loads, it is harmless though.
Kris
    
    
More information about the freebsd-fs
mailing list