This appears to be an issue with the new kernel lock detection code -
tentatively moving this bug to the kernel component.
Please tell us :
o Is this a multiprocessor machine ? How many processors ?
(perhaps the output of /proc/cpuinfo might be useful)
o Is there any degradation in named performance - ie. does the named process
actually lock up / hang or is there just the kernel stack dump and the
'possible circular locking dependency detected' log message ?
If named is locking up, please enable named debugging:
1. Ensure named.conf puts the named.run log in a writable directory,
eg.:
'logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};'
2. Turn on named debugging from the command line with named running:
# rndc trace 99
3. Then send us both the $ROOTDIR/var/named/data/named.run file
(where $ROOTDIR may be set in /etc/sysconfig/named) and the
/var/log/messages containing the kernel lock detection message
from the same time.
Then we should be able to determine what named is doing to cause this
kernel lock detection mechanism to trigger.
If named is not locking up, then it appears to be a false alarm raised
by the new kernel lock detection code.

I have not seen named locking up. I just figured it would be important to post
the bug. processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping : 12
cpu MHz : 501.147
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips : 1004.78
This is a single processor machine. This output is from the last kernel I used
and is currently tainted (the original bug report was not tainted).