acquiring duplicate lock of same type: "sleepq chain" [was: tmpfs on contemporary -current: panic: locked against myself]

On Monday 29 October 2007 06:29:27 LI Xin wrote:
> Can not reproduce here.  Could you please confirm that this still
> persists for latest RELENG_7?

Well i am not able to reproduce it on my VMware box. However i'll try to do 
it later on my real box.

I have another interesting report regarding RELENG_7. I don't know is this 
a bug or not, but... While testing tmpfs with postmark with a lot of 
swapping on purpose i have got this panic:

root_at_orion-vm:~# kgdb -q -n 0 /boot/kernel/kernel.symbols                                                                                                                    
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
Undefined symbol "ps_pglobal_lookup"]

Unread portion of the kernel message buffer:
acquiring duplicate lock of same type: "sleepq chain"
 1st sleepq chain _at_ /usr/src/sys/kern/subr_sleepqueue.c:781
 2nd sleepq chain _at_ /usr/src/sys/vm/vm_glue.c:770
KDB: stack backtrace:
db_trace_self_wrapper(c0a9d415,cbd43be4,c078584e,c0a9f7cf,c0a9e2be,...) at 
db_trace_self_wrapper+0x26
kdb_backtrace(c0a9f7cf,c0a9e2be,c0abbe42,302,cbd43bd0,...) at 
kdb_backtrace+0x29
witness_checkorder(c0bb4db0,9,c0abbe42,302,9,...) at 
witness_checkorder+0x6de
_thread_lock_flags(c0bae590,0,c0abbe42,302,cbd43c44,...) at 
_thread_lock_flags+0x47
kick_proc0(c0bb4bb8,1,c0a9b2c7,1d3,c2c7f000,...) at kick_proc0+0x2a
setrunnable(c2c7f000,1,c0a9e012,26b) at setrunnable+0xbb
sleepq_resume_thread(c0bb0384,0,c0a9e012,30d,e40e5,...) at 
sleepq_resume_thread+0x259
sleepq_timeout(c2c7f000,0,c0a9bb75,ef,0,...) at sleepq_timeout+0xc0
softclock(0,0,c0a97551,471,c292a6e4,...) at softclock+0x266
ithread_loop(c290a270,cbd43d38,c0a972c5,314,c290b550,...) at 
ithread_loop+0x1b5
fork_exit(c0732ad0,c290a270,cbd43d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xcbd43d70, ebp = 0 ---
KDB: enter: witness_checkorder
panic: from debugger
cpuid = 0
KDB: stack backtrace:
Uptime: 15m52s
Physical memory: 243 MB
Dumping 79 MB: 64 48 32 16

#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xc074e0ce in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc074e38b in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc048cc27 in db_panic (addr=Could not find the frame base 
for "db_panic".
) at /usr/src/sys/ddb/db_command.c:433
#4  0xc048d615 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401
#5  0xc048ed85 in db_trap (type=3, code=0) 
at /usr/src/sys/ddb/db_main.c:222
#6  0xc0775026 in kdb_trap (type=3, code=0, tf=0xcbd43b54) 
at /usr/src/sys/kern/subr_kdb.c:502
#7  0xc0a0407b in trap (frame=0xcbd43b54) 
at /usr/src/sys/i386/i386/trap.c:621
#8  0xc09e9a6b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#9  0xc07751a2 in kdb_enter (msg=0xc0a378b0 "witness_checkorder") at 
cpufunc.h:60
#10 0xc0785863 in witness_checkorder (lock=0xc0bb4db0, flags=9, 
file=0xc0abbe42 "/usr/src/sys/vm/vm_glue.c", line=770) 
at /usr/src/sys/kern/subr_witness.c:1124
#11 0xc0743227 in _thread_lock_flags (td=0xc0bae590, opts=0, 
file=0xc0abbe42 "/usr/src/sys/vm/vm_glue.c", line=770) 
at /usr/src/sys/kern/kern_mutex.c:486
#12 0xc095789a in kick_proc0 () at /usr/src/sys/vm/vm_glue.c:770
#13 0xc075633b in setrunnable (td=0xc2c7f000) 
at /usr/src/sys/kern/kern_synch.c:496
#14 0xc077c589 in sleepq_resume_thread (sq=0xc28fd150, td=0xc2c7f000, 
pri=-1) at /usr/src/sys/kern/subr_sleepqueue.c:660
#15 0xc077c7b0 in sleepq_timeout (arg=0xc2c7f000) 
at /usr/src/sys/kern/subr_sleepqueue.c:789
#16 0xc075fe36 in softclock (dummy=0x0) 
at /usr/src/sys/kern/kern_timeout.c:274
#17 0xc0732c85 in ithread_loop (arg=0xc290a270) 
at /usr/src/sys/kern/kern_intr.c:1036
#18 0xc0730148 in fork_exit (callout=0xc0732ad0 <ithread_loop>, 
arg=0xc290a270, frame=0xcbd43d38) at /usr/src/sys/kern/kern_fork.c:796
#19 0xc09e9ae0 in fork_trampoline () 
at /usr/src/sys/i386/i386/exception.s:205

But I should mention that before the panic there was a lot of 
"swap zone exhausted, increase kern.maxswzone" messages, so i don't know 
whether this is a disired behavior or not.

In my fstab i have this line:
tmpfs     /tmp    tmpfs rw    0 0  

root_at_orion-vm:~# uname -a
FreeBSD orion-vm 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Mon Oct 29 11:12:58 UTC 
2007     root_at_orion-vm:/usr/obj/usr/src/sys/DEBUG  i386

postmark configuration is:
The base number of files is 50000
Transactions: 10000
Files range between 500 bytes and 9.77 kilobytes in size
Working directory: /usr/home/quetzal
1000 subdirectories will be used
Block sizes are: read=512 bytes, write=512 bytes
Biases are: read/append=5, create/delete=5
Using Unix buffered file I/O
Random number generator seed is 42
Report format is verbose.

root_at_orion-vm:~# swapinfo                                                                                                                                                    
Device          512-blocks     Used    Avail Capacity
/dev/ad0s1b        1048576        0  1048576     0%

hw.physmem: 255221760
hw.usermem: 212406272
hw.realmem: 268435456



-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------    
======================================================================