John Baldwin wrote:
On Monday 02 February 2009 7:33:08 am Nikola Knežević wrote:
On 30 Jan 2009, at 18:11 , Nikola Knežević wrote:
This is the message buffer:
Unread portion of the kernel message buffer:
panic: blockable sleep lock (sleep mutex) 16 @ /usr/src/sys/vm/
uma_core.c:1834
Any hints where I should search for the cause?
Ok, I solved this problem. I had a critical_enter/exit surrounding
code which was calling a lot of mallocs. Now, I'm getting another
message, which doesn't make any sense:
---8<---
--- trap 0, rip = 0, rsp = 0xffffffff87834d30, rbp = 0 ---
uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
exclusive sleep mutex click_instance r = 0 (0xffffff00051b4540) locked
@ sched.cc:441
--->8---
It says "non-sleepable locks", yet it classifies click_instance as
sleep mutex. I think witness code should emit messages which are more
clear.
It is confusing, but you can't do an M_WAITOK malloc while holding a mutex.
Basically, sleeping actually means calling "*sleep() (such as mtx_sleep()) or
cv_*wait*()". Blocking on a mutex is not sleeping, it's "blocking". Some
locks (such as sx(9)) do "sleep" when you contest them. In the scheduler,
sleeping and blocking are actually quite different (blocking uses turnstiles
that handle priority inversions via priority propagation, sleeping uses sleep
queues which do not do any of that). The underyling idea is that mutexes
should be held for "short" periods of time, and that any sleeps are
potentially unbounded. Holding a mutex while sleeping could result in a
mutex being held for a long time.
the locking overview page
man 9 locking
tries to explain this..
I've been pestering John to proofread it and make suggestiosn for a
while now.
(nag nag)
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
