kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE]

John Baldwin jhb at freebsd.org
Tue Sep 9 21:04:32 UTC 2008


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 <jhb at freebsd.org> 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


More information about the freebsd-acpi mailing list