lkml.org 
[lkml]   [2013]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] irq: add quirk for broken interrupt remapping on 55XX chipsets
    On 03/11/2013 07:25 AM, Neil Horman wrote:
    > On Sat, Mar 09, 2013 at 03:20:57PM -0700, Myron Stowe wrote:
    >> On Sat, Mar 9, 2013 at 1:49 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
    >>> On Mon, Mar 04, 2013 at 02:04:19PM -0500, Neil Horman 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: linux-pci@vger.kernel.org
    >>>>
    >>> Ping, anyone want to Ack/Nack this?
    >>
    >> Don's comment earlier seems to imply that this is a short term fix and
    >> that a more long term fix may be coming soon. If that is the case
    >> wouldn't we want to wait for the long term fix and just pull that in?
    >>
    >> Myron
    >>
    > As Don and Prarit have mentioned, an alternate change is being worked on and
    > tested that may work around this issue, but we're not yet sure that it will, and
    > we're not sure of the time frame for this fix. Normally I would agree, that it
    > would be easier just to wait for the long term fix, but as Prarit noted, since
    > this hardware is in fact broken, I would rather do a both approach. Its fine if
    > this gets reverted tomorrow with a longer term fix as far as I'm concerned, its
    > just caused enough problems already that I'd like to see it in place until the
    > better solution arrives.

    I agree with Neil on this. While vendors are supposed to fix their BIOSes,
    experience has shown that not all vendors will fix their BIOSes for a problem
    like this.

    Ack this quirk.

    P.

    > Neil
    >
    >



    \
     
     \ /
      Last update: 2013-03-11 14:02    [W:3.166 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site