From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 21 16:31:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6472B16A41F for ; Mon, 21 Nov 2005 16:31:46 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id A53DC43D53 for ; Mon, 21 Nov 2005 16:31:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 2367513 for multiple; Mon, 21 Nov 2005 11:31:56 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jALGVdYh069777; Mon, 21 Nov 2005 11:31:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 21 Nov 2005 10:38:26 -0500 User-Agent: KMail/1.8.2 References: <3.0.1.32.20051121044201.00aa1490@pop.redshift.com> <0bb401c5ee9d$79ac2c50$0c02010a@svr012> In-Reply-To: <0bb401c5ee9d$79ac2c50$0c02010a@svr012> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511211038.26937.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Konstantin Prokazoff Subject: Re: poll()/select() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 16:31:46 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org