Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Sep 2008 11:08:49 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-acpi@freebsd.org, lists@peter.de.com
Subject:   Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE]
Message-ID:  <200809081108.50135.jhb@freebsd.org>
In-Reply-To: <20080901141216.72601dfb@dilbert.office.centralnic.com>
References:  <20080901141216.72601dfb@dilbert.office.centralnic.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809081108.50135.jhb>