archive mirror
 help / color / mirror / Atom feed
From: Edward Donovan <>
To: Chris Palmer <>
Cc: Robert Hancock <>,,
	Andrew Morton <>,
	Len Brown <>,,,,,,,
Subject: Re: ASM1083 PCIx-PCI bridge interrupts - widespread problems
Date: Thu, 2 Feb 2012 14:20:54 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

(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?

  reply	other threads:[~2012-02-02 19:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2012-01-30 15:04   ` ASM1083 PCIx-PCI bridge interrupts - widespread problems Chris Palmer
2012-01-31  2:12     ` Robert Hancock
2012-01-31 12:08       ` Chris Palmer
2012-02-02 19:20         ` Edward Donovan [this message]
2012-02-02 19:28           ` Linus Torvalds
2012-02-02 20:22             ` Edward Donovan
2012-02-02 21:39               ` Clemens Ladisch
2012-02-02 22:41               ` Jeroen Van den Keybus
2012-02-03  1:59                 ` Edward Donovan
2012-02-03  8:51                   ` Müller Keve

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).