public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Olaf Dabrunz <od@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jon Masters <jonathan@jonmasters.org>,
	Stefan Assmann <sassmann@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting
Date: Tue, 03 Jun 2008 19:35:05 -0700	[thread overview]
Message-ID: <m1tzgauduu.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <12124107071847-git-send-email-od@suse.de> (Olaf Dabrunz's message of "Mon, 2 Jun 2008 14:45:00 +0200")

Olaf Dabrunz <od@suse.de> writes:

> These patches are against linux-2.6-tip, auto-x86-next.
>
> When IRQ lines on secondary or higher IO-APICs are masked (as done by
> RT and others), many chipsets redirect IRQs on this line to the PIC, and
> thereby regularly to the first IO-APIC in the system. This causes
> spurious interrupts and can lead to disabled IRQ lines.

Sounds like good problem tracking.

> Disabling this "boot interrupt" (as it is mostly used to supply all
> IRQs to the legacy PIC during boot) is chipset-specific, and not
> possible for all chips. This patchset disables the boot interrupt on
> chipsets where this is possible and where we know how to do it.

I know to work around a similar issue we disable the interrupt inputs
on the PIC.  Is that not enough?  In particular what is enabled and
what is disabled when these interrupts are coming in.

> When disabling the boot interrupt is not possible, the patches tell the
> IRQ code to always use the redirected interrupt line (on the first
> IO-APIC) instead of the "original" line on the secondary (tertiary ...)
> IO-APIC. The original line remains masked, and IRQs always appear on
> the boot interrupt line on the first IO-APIC instead.

In general we should not be disabling interrupts, especially in the
mainline kernel.  Artificially increasing interrupt sharing just so
you can be certain of disabling the interrupt line seems to be the
wrong approach.

Much better would be to get everything off of the shared boot
interrupt line, so you can disable that, if that is possible.

For the mainstream kernel I expect we can even teach the drivers
not to call disable_irq.  As a function of last resort to deal
with screaming irqs, disable_irq seems reasonable.  Using disable_irq
on a regular basis appears to be asking for a trouble (as you have
found).

As for the question about MSI.  Good MSI implementations have a mask
bit so we should be able to disable those reliably.  For other MSI
implementations we disable both the mask bit and the pci_intx
capability.  So there should be no way for the irq to leave the
device.  But it hardware is strange sometimes.

That said have you tried clearing the PCI_COMMAND_INTX_DISABLE bit
of the PCI_COMMAND register to mask the boot interrupts?  I expect
that would work on quite a lot of modern hardware.

Eric

  parent reply	other threads:[~2008-06-04  2:41 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02 12:45 [PATCH 0/7] Boot IRQ quirks and rerouting Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 1/7] add kernel cmdline option to disable pci-irq quirks Olaf Dabrunz
2008-06-03 10:13   ` Thomas Gleixner
2008-06-03 17:00     ` Stefan Assmann
2008-06-02 12:45 ` [PATCH 2/7] reroute PCI interrupt to legacy boot interrupt equivalent Olaf Dabrunz
2008-06-03 10:37   ` Thomas Gleixner
2008-06-03 22:59     ` Randy Dunlap
2008-06-12 14:14     ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 3/7] disable legacy boot interrupt generation Olaf Dabrunz
2008-06-03 10:40   ` Thomas Gleixner
2008-06-02 12:45 ` [PATCH 4/7] disable broadcomm " Olaf Dabrunz
2008-06-03 10:46   ` Thomas Gleixner
2008-06-03 15:46   ` Jon Masters
2008-06-03 15:59     ` Olaf Dabrunz
2008-06-03 16:05       ` Jon Masters
2008-06-03 17:27         ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 5/7] disable AMD/ATI " Olaf Dabrunz
2008-06-03 10:54   ` Thomas Gleixner
2008-06-12 14:14     ` Olaf Dabrunz
2008-06-02 12:45 ` [PATCH 6/7] disable pci legacy boot irq quirks on noapic boot Olaf Dabrunz
2008-06-03 10:55   ` Thomas Gleixner
2008-06-02 12:45 ` [PATCH 7/7] bootirqquirk= parameter to enable bootirq quirks for additional chips Olaf Dabrunz
2008-06-03 10:56   ` Thomas Gleixner
2008-06-04 10:06     ` Olaf Dabrunz
2008-06-02 16:43 ` [PATCH 0/7] Boot IRQ quirks and rerouting Olaf Dabrunz
2008-06-03 10:11 ` Thomas Gleixner
2008-06-03 17:08   ` Olaf Dabrunz
2008-06-03 10:21 ` Olaf Dabrunz
2008-06-03 15:52 ` Jon Masters
2008-06-03 16:17   ` Stefan Assmann
2008-06-03 16:56   ` Olaf Dabrunz
2008-06-04  2:35 ` Eric W. Biederman [this message]
2008-06-04  9:49   ` Stefan Assmann
2008-06-04 10:45     ` Eric W. Biederman
2008-06-04 11:33       ` Stefan Assmann
2008-06-04 15:52         ` Maciej W. Rozycki
2008-06-04 16:08           ` Thomas Gleixner
2008-06-04 17:18             ` Maciej W. Rozycki
2008-06-04 17:33               ` Thomas Gleixner
2008-06-04 17:53                 ` Maciej W. Rozycki
2008-06-04 18:35                   ` Thomas Gleixner
2008-06-04 18:51                     ` Maciej W. Rozycki
2010-02-16  0:30           ` Yuhong Bao
2008-06-04 18:57         ` Jon Masters
2008-06-04 19:19           ` Maciej W. Rozycki
2008-06-04 19:59             ` Jon Masters
2008-06-04 22:07               ` Maciej W. Rozycki
2008-06-04 22:27                 ` Jon Masters
2008-06-04 23:08                   ` Maciej W. Rozycki
2008-06-04 11:37       ` Olaf Dabrunz
2008-06-04 18:44     ` Jon Masters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1tzgauduu.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jonathan@jonmasters.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=od@suse.de \
    --cc=sassmann@suse.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox