[lkml]   [2012]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ASM1083 PCIx-PCI bridge interrupts - widespread problems
    (I'm just a bystander here, but interested, since I've been asked
    about it a few times)

    On Tue, Jan 31, 2012 at 7:08 AM, Chris Palmer <> wrote:
    > On 31/01/2012 02:12, Robert Hancock wrote:
    >> On 01/30/2012 09:04 AM, Chris Palmer wrote:
    >>> Linus et al
    >>> For about 6 months many users have been having interrupt problems
    >>> with PCI boards, but it hasn't been
    >>> easy trying to find where the problem may be. However, it is now
    >>> looking likely that the problem lies
    >>> in the ASM1083 PCIe-PCI bridge chipset, as used by Asus in many
    >>> Sandybridge and AMD boards.
    >>> My original bug report is:
    >>>  (Sandybridge)
    >>> and there several other similar ones. However there is also extensive
    >>> investigation in the following thread:
    >>>  (AMD)
    >>> There have also been reports of Windows users having similar problems.
    >>> This problem prevents use of PCI boards in any motherboard with that
    >>> bridge chipset - including most
    >>> ASUS boards. At the moment though we don't know whether the chipset
    >>> or drivers are faulty, and if a
    >>> workaround is possible.
    >>> At the moment my bug is assigned to drivers_network, but this doesn't
    >>> look appropriate.
    >>> Hoping someone can help...
    >> If the analysis posted in the "Unhandled IRQs on AMD E-450" thread is
    >> correct, then it sounds like the bridge chip is delaying PCIe INTx
    >> deassert messages. In that case there isn't much the kernel is likely
    >> to be able to fix it properly, at least not without input from ASMedia
    >> or someone else with detailed knowledge of the chip.
    >> The workaround posted in that thread (switching to IRQ polling mode on
    >> the interrupt for some period of time after a screaming IRQ is
    >> detected) might be a workaround, but definitely would be considered a
    >> hack.
    >> Do you have a source/link for people having issues with this on
    >> Windows? I wouldn't be surprised though - I doubt Windows has any
    >> special handling for unhandled IRQs so likely it just hammers the IRQ
    >> handler until the IRQ gets deasserted. In that case the only thing a
    >> user might notice would be poor performance whenever the devices
    >> behind that bridge raise interrupts.
    > Nothing definitive about Windows, but Edward found this discussion. It's
    > a bit emotive, but suggests the problem may be manifesting itself there too:
    > Chris

    If we end up helpless with this chip, will we at least warn the user
    that it's known to be buggy? I dont' know if there's a standard
    procedure when documenting bad hardware.

    I've CC'd a few more people who have reported this, and Clemens, who
    got to the bottom of it.



    >>> On 09/09/2011 00:51, Andrew Morton wrote:
    >>>> On Thu, 08 Sep 2011 12:28:40 +0100
    >>>> Chris Palmer<>  wrote:
    >>>>> Andrew
    >>>>> I'm writing to ask if you could cast a quick eye over the following
    >>>>> bugs, to give an opinion on where they should be assigned. Mine has
    >>>>> been
    >>>>> reassigned to Network Drivers but I'm not convinced that is right,
    >>>>> and I
    >>>>> think the problem is wider than that.
    >>>>> In summary, interrupt handling for *PCI boards with ASUS Sandybridge
    >>>>> motherboards* seems to be broken.
    >>>>> It has been seen with network and non-network PCI boards. PCIx network
    >>>>> boards work OK. And all reports are for ASUS motherboards.
    >>>>> My bug report is
    >>>>> Others that I know of are:
    >>>>> I'm now on kernel 3.0.4 with the problem still there. The only thing
    >>>>> that seems to make a difference is acpi=off (although one person
    >>>>> reported that it merely changed it from minutes to days before
    >>>>> occurring).
    >>>>> I'd appreciate anything you could do to move this in the right
    >>>>> direction...
    >>>> Most likely ACPI, I expect.  I think that's
    >>>> DNS is dead at
    >>>> present and I can't check.
    >>>> Len, can you suggest how to triage these please?
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-02-02 20:23    [W:0.030 / U:32.368 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site