From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 16:01:51 2003 Return-Path: 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 C4B3737B401 for ; Thu, 5 Jun 2003 16:01:51 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 005AE43F75 for ; Thu, 5 Jun 2003 16:01:50 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h55N1ikA034542; Thu, 5 Jun 2003 17:01:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Jun 2003 17:01:34 -0600 (MDT) Message-Id: <20030605.170134.132933173.imp@bsdimp.com> To: dmlb@dmlb.org From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: interrupt handlers in -current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2003 23:01:52 -0000 In message: Duncan Barclay writes: : This is more of a confirmation of my understanding than anything else. : In -current, should an interrupt thread be created you set up an interrupt : handler? If so, then I'd better check my code because I haven't got one! No. Just because we handle interrupts in a thread doesn't mean client devices need to create a thread. The thread is creted automatically and the routine passed to bus_setup_intr() is then called when an interrupt happens. You can create threads, taskqueues and other things, but those aren't required. : If a PCI device generates an interrupt and there is no handler does the : kernel report a stary interrupt? You'll likely see an interrupt storm. Since the PCI device generates a level interrupt, the ISRs are run and the level interrupt is still high, so another interrupt is generated, etc. on 4.x this was fatal, but on 5.x the system can continue to run in a degraded manner. : -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. : I'm transmitting packets but my handler isn't being called to clean up the : DMA. So you are doing bus_setup_intr() and that routine is never called? What does vmstat say? I'd expect to see something like: % vmstat -i uhci0 irq10 26083 1 # cause the interrupt to happen % vmstat -i uhci0 irq10 26026083 2683 # eg, a huge number all of a sudden (all[*] irq 10's are reported on the uhci device in vmstat, so don't let that get you confused). It may also be the case that the interrupt for this isn't being properly routed. 5.1-BETA has a bug that, for some laptop machines, interrupts aren't properly routed. 5.1-RELEASE has fixed this. Warner