From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 23:08:19 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 E419C1065670 for ; Mon, 8 Sep 2008 23:08:19 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 734F08FC12 for ; Mon, 8 Sep 2008 23:08:19 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 4FA4D46AE9 for ; Tue, 9 Sep 2008 00:08:18 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id 0kI8oqEE580p for ; Tue, 9 Sep 2008 00:08:14 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id A9BDA46AA9 for ; Tue, 9 Sep 2008 00:08:14 +0100 (BST) Received: from delorean.geonosis.homeunix.org (host81-138-8-148.in-addr.btopenworld.com [81.138.8.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id 8E5F346AA5; Tue, 9 Sep 2008 00:08:12 +0100 (BST) Date: Tue, 9 Sep 2008 00:08:05 +0100 From: Oliver Peter To: John Baldwin Message-ID: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> In-Reply-To: <200809081108.50135.jhb@freebsd.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> Organization: mouhaha X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Reply-To: lists@peter.de.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 23:08:20 -0000 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? :-) Cheers, O. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish