acquiring duplicate lock of same type: "sleepq chain" [was: tmpfs
on contemporary -current: panic: locked against myself]
Nikolay Pavlov
qpadla at gmail.com
Tue Oct 30 03:17:27 PDT 2007
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 @ /usr/src/sys/kern/subr_sleepqueue.c:781
2nd sleepq chain @ /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. <<<-----------------------------------
======================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071030/e2dad7b6/attachment.pgp
More information about the freebsd-current
mailing list