DragonFly_Stable: [diagnostic] cache_resolve

YONETANI Tomokazu qhwt+dfly at les.ath.cx
Thu Oct 28 09:49:04 PDT 2004


Hello.
I was rsync'ing gcc's CVS repository from another machine to
an SMP(Xeon * 2) DragonFly_Stable machine when I saw this message on the
console:
Oct 28 19:36:34 fred kernel: [diagnostic] cache_resolve: relinked CVS
Oct 28 19:36:34 fred kernel: [diagnostic] nlookup: relookup CVS

After seeing this message, rsync started to fail because some of directories
became inaccessible(same symptom as that reported in thread "file weirdness"
started in the middle of this month). Last time I saw this during buildworld,
unseen files and directories remained unseen across reboot and I had to force
fsck. After reboot and full fsck for all partitions, rsync finished without
a problem(yes, I noticed that I should have at least tried ncptrace/vnodeinfo
after the reboot).
The only heavy disk activities after the last installkernel were:

- make -j101 buildworld to see if the timer problem still persists
- cvsup to synch repositories for dragonfly and freebsd

This machine is supposed to be a read-only pserver/cvsupd server for
other machines in my office, so I'll be able to report again if the problem
still persists in the VFS code.

I also see below messages ocasionally during buildworld, but
so far I've never seen any obvious problems in the said diretories.

Oct 27 19:21:59 fred kernel: [diagnostic] cache_lock: blocked on 0xcecb4938 "tmp"
Oct 27 19:21:59 fred kernel: [diagnostic] cache_lock: unblocked tmp

No nullfs or unionfs filesystem on this machine.

$ uname -a
DragonFly fred 1.1-Stable DragonFly 1.1-Stable #0: Wed Oct 27 17:56:59 JST 2004     root at fred:/var/obj/home/source/dragonfly/stable/src/sys/6000R.SMP:gcc34  i386





More information about the Bugs mailing list