From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 23:52:46 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2451065679 for ; Sun, 6 Jul 2008 23:52:46 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id EE5808FC0A for ; Sun, 6 Jul 2008 23:52:45 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from verizon.net ([63.24.199.94]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K3L00ERAWUM5NJ0@vms173001.mailsrvcs.net> for freebsd-hackers@freebsd.org; Sun, 06 Jul 2008 17:52:01 -0500 (CDT) Date: Sun, 06 Jul 2008 18:56:12 -0400 From: Sergey Babkin Sender: root To: Murray Taylor Message-id: <48714D8C.2AD7286D@verizon.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en, ru References: <04E232FDCD9FBE43857F7066CAD3C0F15B81D2@svmailmel.bytecraft.internal> X-Mailman-Approved-At: Mon, 07 Jul 2008 00:28:44 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: massive interrupt storm 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: Sun, 06 Jul 2008 23:52:46 -0000 Murray Taylor wrote: > > Hi all, > > We have just purchased some servers with a view to > using them as firewalls within our WAN, and have discovered that > they are suject to a massive interrupt storm on IRQ17. > > systat -v is showing 59000 -> 63000 interrupts continuously > on this IRQ, and 90%->98% Interrupt CPU usage One typical reason for "interrupt storms" is this: Some device has been initialized by BIOS and has indicated an interrupt but there is no driver in the OS to handle this interrupt. PCI allows sharing of the interrupts, i.e. multiple devices show their interrupts on the same IRQ line. The interrupt is signalled by level, i.e. if any device on this IRQ has an interrupt pending, it would pull the line low. OS has no way to tell which one, other than by trying all the drivers for the devices sitting on this line. Once the driver has found that its device is the one signalling interrupt, it services it, cleans the device state, and the device lets go of the IRQ line. The trouble starts when there is some device for which there is no driver. OS runs its interrupt handler, polls each driver, each of them says "nope, not mine", teh interrupt handler exits and gets called again right away. The fix is to disable the unsupported devices in BIOS or at least collect them on some IRQ line that is not used by any supported devices. -SB