Date: Tue, 9 Sep 2008 00:08:05 +0100 From: Oliver Peter <lists@peter.de.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John,
Thanks for your reply.
On Mon, 8 Sep 2008 11:08:49 -0400
John Baldwin <jhb@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? :-)
Cheers,
O.
--
Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174
"If it feels good, you're doing something wrong."
-- Coach McTavish
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080909000805.5dc4407c>