On Thursday 28 February 2008 09:04:55 am Attilio Rao wrote: > 2008/2/28, Yuri Pankov <[EMAIL PROTECTED]>: > > 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.
It would break. We hold these locks across malloc and other stuff in fork, etc. They are sx because of that, not for r/w semantics. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"