From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 21:13:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4147816A546 for ; Tue, 19 Oct 2004 21:13:24 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id E23E843D31 for ; Tue, 19 Oct 2004 21:13:23 +0000 (GMT) (envelope-from john@baldwin.cx) Received: (qmail 21217 invoked from network); 19 Oct 2004 21:13:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 19 Oct 2004 21:13:23 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9JLDKcJ050336; Tue, 19 Oct 2004 17:13:20 -0400 (EDT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (localhost [127.0.0.1]) by zion.baldwin.cx (8.12.10/8.12.10) with ESMTP id i9JLDK8h005722; Tue, 19 Oct 2004 17:13:20 -0400 (EDT) (envelope-from john@zion.baldwin.cx) Received: from localhost (localhost [[UNIX: localhost]]) by zion.baldwin.cx (8.12.10/8.12.10/Submit) id i9JLDJgi005721; Tue, 19 Oct 2004 17:13:19 -0400 (EDT) (envelope-from john) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 19 Oct 2004 17:10:13 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410191710.13080.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: 'Robert Watson' cc: Daniel Eriksson Subject: Re: Interrupts being reported twice? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 21:13:27 -0000 On Monday 19 April 2004 11:46 am, Daniel Eriksson wrote: > Robert Watson wrote: > > I see the same problem in 4.x. Drew and I exchanged some e-mails > > comiserating over the fact that this seems to be the case on a lot of > > machines. Not that this is necessarily what you're seeing, > > but it would > > be interesting to know whether in previous configurations you see > > different symptoms of a similar problem. > > With the old configuration (a kernel from 3 or 4 days ago, ACPI disabled > (but APIC enabled since it's an SMP system), and two of the PCI cards > switched around), this is what I was getting: > > (copied from the "Current crash on today's kernel" thread) > > # vmstat -i > interrupt total rate > irq1: atkbd0 2 0 > irq0: clk 5142796 995 > irq4: sio0 1056 0 > irq6: fdc0 10 0 > irq8: rtc 658343 127 > irq13: npx0 1 0 > irq14: ata0 205255 39 > irq15: ata1 205046 39 > irq16: em0 atapci1 11635073 2251 > irq17: em1 ahc0++ 6549430 1267 > irq19: atapci4+ 442467 85 > Total 24839479 4807 > > As you can see, em0 (the source with the highest interrupt load) didn't sit > on its own ithread. Instead it shared it with the Promise SATA150 TX4 > controller. em1/ahc0/atapci2+ shared irq17, and the interrupt count on that > ithread looks about right. > > Something in this configuration has crashed my machine 3 times in 6 days, > so I'm not looking to go back unless the new config also results in > crashes. > > > Back to the current config (ACPI enabled): > What about running the kernel with DEVICE_POLLING enabled? I've seen posts > here saying it doesn't make any sense to do so in the SMP case, but I've > also seen people report that they are doing it (by modding the appropriate > file to allow the compile to finish). Does it really not make any sense > doing it in SMP, or is it a matter of insufficient testing/debugging of the > code, or are there other reasons not to do it? > > My thinking here is that if the NIC doesn't generate any interrupts, the > ithread that reports the "ghost" interrupts (atapci1+) should no longer do > that. > > Maybe the real question is: does the ithread that reports the "ghost" > interrupts actually service all the interrupts, or is 'vmstat -i' reporting > something that really doesn't consume any CPU time? The problem is in hardware, and the CPU is actually receiving interrupts from the interrupt controller for both IRQs. Each ithread is scheduled and all of your ISRs are running, though if they are for smarter devices they will return after doing an interrupt status register check. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/