From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 9 21:04:32 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554E81065670 for ; Tue, 9 Sep 2008 21:04:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E09C48FC1A for ; Tue, 9 Sep 2008 21:04:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m89L4CIg008827; Tue, 9 Sep 2008 17:04:25 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: lists@peter.de.com Date: Tue, 9 Sep 2008 14:24:16 -0400 User-Agent: KMail/1.9.7 References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> In-Reply-To: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809091424.16302.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 09 Sep 2008 17:04:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8162/Thu Sep 4 12:38:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 21:04:32 -0000 On Monday 08 September 2008 07:08:05 pm Oliver Peter wrote: > Hi John, > > Thanks for your reply. > > On Mon, 8 Sep 2008 11:08:49 -0400 > John Baldwin wrote: > > > On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > > > Hi, > > > > > > For about 6 weeks I'm suffering an interrupt storm on my production > > > machine which is running 7.0-RELEASE-p3/amd64. > > > > > > The kernel is flooding my syslog with the following messages[1]. > > > A full dmesg can be found here[2]. > > > > > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > > > to disable apic during boot time but that's a bad idea because it > > > seems that the SATA2 onboard controller has to have apic loaded - > > > please correct me if I'm wrong. > > > > > > /boot/loader.conf: > > > hint.apic.0.disabled="1" > > > > > > Doesn't work for me. > > > > > > Btw. I think it's worth it to have a little note in that part of > > > the documentation which says something about possible failures > > > during the boot time. > > > > > > Thanks for any suggestions. > > > > There are two possible causes of an interrupt storm: 1) some device > > is actually using IRQ 22 but FreeBSD thinks it is using something > > else. This doesn't happen very often as it is generally a bug in the > > BIOS and one of the tables it generates. This used to happen more > > often in older versions of FreeBSD that had bugs or limitations in > > the code that figured out which IRQ PCI devices used. > > How can I find out exactly which device is using IRQ 22? > Maybe I can disable it - i.e. USB is not needed at all. > > > 2) There is a > > bug in the driver for one of the devices on IRQ 22. In this case the > > only device you have on IRQ is atapci0, so it may be a bug in the > > ata(4) driver, possibly. You could check to see if the interrupt > > handler for the Linux driver for your chipset has extra logic > > (currently ata(4) doesn't have any chipset-specific logic for > > interrupt handlers AFAIK). Also, you could try examining the > > interrupt status register of your controller when you are getting > > storms to see if there is a condition set that isn't being cleared by > > ata's interrupt handler. > > ... of course I could do that - but could you please be so kind and > explain how to do that? :-) Well, you could start by adding a printf to ata's interrupt handler, but that would result in a flood on your screen. You could maybe use a KTR instead, but only do it if the interrupt handler doesn't find any work to do (e.g. no pending request) perhaps. I think the ATA interrrupt handler already reads a status register of some sort, but I could be wrong. -- John Baldwin