aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/msi.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2007-04-03 01:41:49 -0600
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-04-03 14:02:49 -0700
commit348e3fd19487534d9d4dd70c3ad0b751afd35792 (patch)
tree0f5bf833203f18873595d19e53d6466e1878c66c /drivers/pci/msi.c
parent59117d3f4e3f5a7980353d2f476e516c758ce921 (diff)
downloadkernel_samsung_smdk4412-348e3fd19487534d9d4dd70c3ad0b751afd35792.zip
kernel_samsung_smdk4412-348e3fd19487534d9d4dd70c3ad0b751afd35792.tar.gz
kernel_samsung_smdk4412-348e3fd19487534d9d4dd70c3ad0b751afd35792.tar.bz2
[PATCH] msi: synchronously mask and unmask msi-x irqs.
This is a simplified and actually more comprehensive form of a bug fix from Mitch Williams <mitch.a.williams@intel.com>. When we mask or unmask a msi-x irqs the writes may be posted because we are writing to memory mapped region. This means the mask and unmask don't happen immediately but at some unspecified time in the future. Which is out of sync with how the mask/unmask logic work for ioapic irqs. The practical result is that we get very subtle and hard to track down irq migration bugs. This patch performs a read flush after writes to the MSI-X table for mask and unmask operations. Since the SMP affinity is set while the interrupt is masked, and since it's unmasked immediately after, no additional flushes are required in the various affinity setting routines. The testing by Mitch Williams on his especially problematic system should still be valid as I have only simplified the code, not changed the functionality. We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io, pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this problem when the hardware they driver is plugged into the right slot. Given the difficulty of reproducing this bug and tracing it down to anything that even remotely resembles a cause, even if people are being affected we aren't likely to see many meaningful bug reports, and the people who see this bug aren't likely to be able to reproduce this bug in a timely fashion. So it is best to get this problem fixed as soon as we can so people don't have problems. Then if people do have a kernel message stating "No irq for vector" we will know it is yet another novel cause that needs a complete new investigation. Cc: Greg KH <greg@kroah.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Mitch Williams <mitch.a.williams@intel.com> Acked-by: "Siddha, Suresh B" <suresh.b.siddha@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/pci/msi.c')
-rw-r--r--drivers/pci/msi.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad33e01..435c195 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -94,6 +94,7 @@ static void msi_set_mask_bit(unsigned int irq, int flag)
int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
writel(flag, entry->mask_base + offset);
+ readl(entry->mask_base + offset);
break;
}
default: