2008/2/28, Yuri Pankov :
> Hi,
>
> I'm trying to understand the cause of following panic.
>
> panic: Trying sleep, but thread marked as sleeping prohibited
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> panic() at panic+0x17d
> sleepq_add() at sleepq_add+0x2e1
> _sx_slock_hard() at _sx_slock_hard+0x15d
> _sx_slock() at _sx_slock+0xc1
> pfind() at pfind+0x24
> saa_intr() at saa_intr+0x313
> ithread_loop() at ithread_loop+0xda
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffac3c0d30, rbp = 0 ---
>
> Can someone enlighten me on what is causing the panic and is it ok to
> use pfind() in interrupt handler (I have very limited understanding of
> kernel internals)?
>
> Code in question (taken from saa driver
> http://freebsd.ricin.com/ports/distfiles/kbtv-1.92.tbz) can be found at
> http://www.pastebin.ca/921830


ithreads cannot perform unbound sleeps and pfind() needs to access to
allproc_lock which is a sx lock and *performs* an unbound sleep, so
there is a mismatch.

Btw, it sounds like allproc_lock and other similar locks are just
using an sx lock for *legacy*, they should be probabilly converted to
rwlock.
It also imposes little problems in the TTY layer, for example, where I
saw you need to use a unbounded sleeping primitive because of
processes locks acquisitions.

A nice janitor task would be to convert these sx locks into rw and see
what happens.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"