Messages in this thread | | | From | Edward Donovan <> | Date | Thu, 2 Feb 2012 14:20:54 -0500 | Subject | Re: 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 <chris.palmer@pobox.com> 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: >>> https://bugzilla.kernel.org/show_bug.cgi?id=38632 (Sandybridge) >>> >>> and there several other similar ones. However there is also extensive >>> investigation in the following thread: >>> http://www.gossamer-threads.com/lists/linux/kernel/1466185 (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: > > http://forums.planetz.com/viewtopic.php?f=19&t=30557&sid=00d319732500eaf99c586b73060a9602 > > 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.
Thanks,
Ed
>>> On 09/09/2011 00:51, Andrew Morton wrote: >>> >>>> On Thu, 08 Sep 2011 12:28:40 +0100 >>>> Chris Palmer<chris.palmer@pobox.com> 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 >>>>> >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=38632 >>>>> >>>>> Others that I know of are: >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=713351 >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=35332 >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=34242 >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=32242 >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=39122 >>>>> >>>>> >>>>> 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 >>>> acpi-config-interrupts@bugzilla.kernel.org. kernel.org 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |