# Workaround for hardware bug on ASM1083 PCIe-PCI bridge?

## tholin

I unfortunatly got an ASUS P8P67 PRO mobo with a (probaby) defect ASM1083 PCIe-PCI bridge chipset. More info about that here: https://lkml.org/lkml/2012/1/30/216

I'm trying to come up with some workaround for the problem. I have a soundblaster live soundcard connected to the pci slot and it shares irq with an onboard AHCI controller. When the bridge poops out the kernel starts polling the irq. That works fine for the soundcard (it's slow) but reading from the disk is too slow.

The first workaround I considered was somehow reroute the irq so the AHCI controller would get another one. It doesn't look like that's possible. I find no config option about that in bios. Just the ability to disable the AHCI controller. Is there something that can be done in software or are the wires hardwired?

Another possible workaround would be to get the AHCI controller to use MSI(message signed interrupts). My other two AHCI controller use MSI but not that one. Looking in drivers/ata/ahci.c I can't see any blacklisting for my controllers. The call to pci_enable_msi(pdev) can fail and in that case it falls back to using pci_intx. Looking at drivers/pci/msi.c it seems like it checks for an MSI capability flag before enabling MSI. lspci lists MSI capability for my other two AHCI controller but not for the one I need. Why is that? According to some spec I found "Legacy Endpoints may support IO transactions, and may support locked transaction semantics as a completer but not as a requester. Interrupt-capable legacy devices may support legacy style interrupt generation using message requests but must also support MSI generation using memory write transactions. Legacy devices are not required to support 64-bit memory addressing capability. PCI Express (native) End-points must not support IO or locked transaction semantics and must support MSI style interrupt generation". The problematic controller is an "Express (v1) Legacy Endpoint" so I guess it should support MSI. Is it also dodgy? Could I force MSI on somehow?

A third workaround would be to patch up the kernel so it stops polling the irq and goes back enabling irq after a while. The faulty bridge is only stuck until the next interrupt. There is a patch for doing that on the LKML but it wasn't thread safe and never got cleaned up. I guess there is no way to forcefully renable irq from userspace?

The last workaround is the one I want to avoid. Buy another SATA controller or another soundcard. The integrated soundcard is so noisy I don't want to use it.

http://pastebin.com/WYbJLnWc

Here is a paste of lspci -vvvvnn, lspci -t and /proc/interrupts

The PCI Soundblaster card share irq 19 with the 05:00.0 JMicron SATA controller and doesn't use MSI

09:00.0 Marvell SATA controller and 00:1f.2 Intel SATA controller use MSI.

----------

