All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Dutile <ddutile@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Don Zickus <dzickus@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Asit Mallick <asit.k.mallick@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v4] irq: add quirk for broken interrupt remapping on 55XX chipsets
Date: Thu, 04 Apr 2013 13:27:18 -0400	[thread overview]
Message-ID: <515DB7F6.8010502@redhat.com> (raw)
In-Reply-To: <CAE9FiQUq8m_2fpyRrLweCZwR7cqFBfbZrt9ZeK-PVL3Puxjp0g@mail.gmail.com>

On 04/04/2013 12:16 PM, Yinghai Lu wrote:
> On Thu, Apr 4, 2013 at 8:08 AM, Neil Horman<nhorman@tuxdriver.com>  wrote:
>> A few years back intel published a spec update:
>> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>>
>> For the 5520 and 5500 chipsets which contained an errata (specificially errata
>> 53), which noted that these chipsets can't properly do interrupt remapping, and
>> as a result the recommend that interrupt remapping be disabled in bios.  While
>> many vendors have a bios update to do exactly that, not all do, and of course
>> not all users update their bios to a level that corrects the problem.  As a
>> result, occasionally interrupts can arrive at a cpu even after affinity for that
>> interrupt has be moved, leading to lost or spurrious interrupts (usually
>> characterized by the message:
>> kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)
>>
>> There have been several incidents recently of people seeing this error, and
>> investigation has shown that they have system for which their BIOS level is such
>> that this feature was not properly turned off.  As such, it would be good to
>> give them a reminder that their systems are vulnurable to this problem.
>>
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>> CC: Prarit Bhargava<prarit@redhat.com>
>> CC: Don Zickus<dzickus@redhat.com>
>> CC: Don Dutile<ddutile@redhat.com>
>> CC: Bjorn Helgaas<bhelgaas@google.com>
>> CC: Asit Mallick<asit.k.mallick@intel.com>
>> CC: David Woodhouse<dwmw2@infradead.org>
>> CC: linux-pci@vger.kernel.org
>> ---
>>
>> Change notes:
>>
>> v2)
>>
>> * Moved the quirk to the x86 arch, since consensus seems to be that the 55XX
>> chipset series is x86 only.  I decided however to keep the quirk as a regular
>> quirk, not an early_quirk.  Early quirks have no way currently to determine if
>> BIOS has properly disabled the feature in the iommu, at least not without
>> significant hacking, and since its quite possible this will be a short lived
>> quirk, should Don Z's workaround code prove successful (and it looks like it may
>> well), I don't think that necessecary.
>>
>> * Removed the WARNING banner from the quirk, and added the HW_ERR token to the
>> string, I opted to leave the newlines in place however, as I really couldnt
>> find a way to keep the text on a single line is still legible from a code
>> perspective.  I think theres enough language in there that using cscope on just
>> about any substring however will turn it up, and again, this may be a short
>> lived quirk.
>>
>> v3)
>>
>> * Removed defines from pci_ids.h, and used direct id values as per request from
>> Bjorn.
>>
>> v4)
>>
>> * Converted pr_warn to WARN_TAINT(TAINT_FIRMWARE_WORKAROUND) as per David
>> Woodhouse
>> ---
>>   arch/x86/kernel/quirks.c | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
>> index 26ee48a..eb0785d 100644
>> --- a/arch/x86/kernel/quirks.c
>> +++ b/arch/x86/kernel/quirks.c
>> @@ -5,6 +5,7 @@
>>   #include<linux/irq.h>
>>
>>   #include<asm/hpet.h>
>> +#include "../../../drivers/iommu/irq_remapping.h"
>>
>>   #if defined(CONFIG_X86_IO_APIC)&&  defined(CONFIG_SMP)&&  defined(CONFIG_PCI)
>>
>> @@ -567,3 +568,20 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F5,
>>                          quirk_amd_nb_node);
>>
>>   #endif
>> +
>> +static void intel_remapping_check(struct pci_dev *dev)
>> +{
>> +       u8 revision;
>> +
>> +       pci_read_config_byte(dev, PCI_REVISION_ID,&revision);
>> +
>> +       WARN_TAINT(((revision == 0x13)&&  irq_remapping_enabled),
>> +                  TAINT_FIRMWARE_WORKAROUND,
>> +                   "This system BIOS has enabled interrupt remapping\n"
>> +                   "on a chipset that contains an erratum making that\n"
>> +                   "feature unstable.  Please reboot with nointremap\n"
>> +                   "added to the kernel command line and contact\n"
>> +                   "your BIOS vendor for an update");
>> +}
>> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3406, intel_remapping_check);
>> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3403, intel_remapping_check);
>
> No, you only address my one request, move to arch/x86 directory.
>
> You need to move the quirk to early_quirk to append nointremap to
> avoid extra rebooting.
>
> Thanks
>
> Yinghai
The pci-dev's of all the (minimally, root, 5500-chipset) pci-dev's are known/scanned/created by that time?


  reply	other threads:[~2013-04-04 17:27 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 17:17 [PATCH] irq: add quirk for broken interrupt remapping on 55XX chipsets Neil Horman
2013-03-01 18:20 ` Yinghai Lu
2013-03-01 19:29   ` Neil Horman
2013-03-02  2:28   ` Jiang Liu
2013-03-02 15:59 ` Andreas Mohr
2013-03-04 13:24   ` Don Dutile
2013-03-10  1:11     ` Prarit Bhargava
2013-03-02 16:21 ` Prarit Bhargava
2013-03-02 20:13   ` Neil Horman
2013-03-04 19:04 ` [PATCH v2] " Neil Horman
2013-03-09 20:49   ` Neil Horman
2013-03-09 22:20     ` Myron Stowe
2013-03-11  1:31       ` Don Dutile
2013-03-11 11:25       ` Neil Horman
2013-03-11 12:17         ` Prarit Bhargava
2013-04-03 23:53   ` Bjorn Helgaas
2013-04-04 11:17     ` Neil Horman
2013-04-04 14:27     ` David Woodhouse
     [not found]       ` <1365085649.28127.66.camel-W2I5cNIroUsVm/YvaOjsyQ@public.gmane.org>
2013-04-04 14:50         ` Neil Horman
2013-04-04 14:50           ` Neil Horman
2013-04-04 14:57           ` Bjorn Helgaas
2013-04-04 15:39             ` Neil Horman
     [not found]               ` <20130404153905.GB3403-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2013-04-04 17:14                 ` Bjorn Helgaas
2013-04-04 17:14                   ` Bjorn Helgaas
2013-04-04 17:51                   ` Neil Horman
     [not found]                     ` <20130404175117.GC3403-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2013-04-04 18:41                       ` Bjorn Helgaas
2013-04-04 18:41                         ` Bjorn Helgaas
2013-04-04 20:02                         ` Neil Horman
2013-04-04 13:54 ` [PATCH v3] " Neil Horman
2013-04-04 15:08 ` [PATCH v4] " Neil Horman
2013-04-04 16:16   ` Yinghai Lu
2013-04-04 17:27     ` Don Dutile [this message]
2013-04-04 17:40       ` Yinghai Lu
2013-04-04 20:04         ` Neil Horman
2013-04-04 20:33           ` Bjorn Helgaas
2013-04-04 21:11             ` Yinghai Lu
2013-04-05  0:24               ` Neil Horman
2013-04-05 19:25 ` [PATCH v5] " Neil Horman
2013-04-05 19:29   ` Neil Horman
2013-04-05 19:31 ` [PATCH v6] " Neil Horman
2013-04-05 23:37   ` Yinghai Lu
2013-04-06  1:55   ` Bjorn Helgaas
2013-04-08 15:29     ` Don Dutile
2013-04-08 17:17       ` Bjorn Helgaas
2013-04-08 17:42         ` Neil Horman
2013-04-09 10:08           ` Joerg Roedel
2013-04-15 11:18 ` [PATCH v7] " Neil Horman
2013-04-15 15:30   ` Bjorn Helgaas
2013-04-15 16:28     ` Neil Horman
2013-04-15 16:28 ` [PATCH v8] " Neil Horman
2013-04-15 22:41 ` [PATCH v9] " Neil Horman
2013-04-15 23:02   ` Yinghai Lu
2013-04-16  0:43     ` Neil Horman
2013-04-16  6:20   ` Arkadiusz Miskiewicz
2013-04-16 10:24   ` Joerg Roedel
2013-04-16 13:07     ` Neil Horman
2013-04-16 13:35     ` Neil Horman
2013-04-16 16:37       ` Joerg Roedel
2013-04-16 17:25         ` Neil Horman
2013-04-16 20:38 ` [PATCH v10] " Neil Horman
2013-04-16 22:08   ` Don Dutile
2013-04-18 15:02   ` Joerg Roedel
2013-04-18 17:00     ` Neil Horman

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=515DB7F6.8010502@redhat.com \
    --to=ddutile@redhat.com \
    --cc=asit.k.mallick@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=prarit@redhat.com \
    --cc=yinghai@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.