Date: Mon, 21 Nov 2005 10:38:26 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Konstantin Prokazoff <kprokazov@svr.kiev.ua> Subject: Re: poll()/select() Message-ID: <200511211038.26937.jhb@freebsd.org> In-Reply-To: <0bb401c5ee9d$79ac2c50$0c02010a@svr012> References: <3.0.1.32.20051121044201.00aa1490@pop.redshift.com> <0bb401c5ee9d$79ac2c50$0c02010a@svr012>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote: > Thanks for comment, > > I think, after kernel inspection, problem (maybe) in preemption. While > syscall to poll or select holds sellock, and if another thread (process) > tries to syscall or we have taken interrupt (where handler use > selrecord/selwakeup too), kernel will deadlock. > I have this situation cause to INTR_FAST interrupt handler in device > driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem > 100% repetitive. > Another way to avoid such deadlock - provide different kthread/ithreads > for select/poll mechanism. You can't call selwakeup() from an INTR_FAST handler. Try removing INTR_FAST and see if it fixes your issue. If you want to use INTR_FAST, then realize that you can only use spin mutexes in your handler, and that any more complicated work like selwakeup() that uses regular mutexes will have to be deferred either by using a swi handler or dispatching a task to the Fast taskqueue. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511211038.26937.jhb>