Re: [PATCH v2 2/2] alpha: disable DAC for 32-bit PCI cards on Tsunami/Typhoon

Hi Magnus!

On Mon, Aug 24, 2026 at 07:36:54PM +0200, Magnus Lindholm wrote:

The Tsunami/Typhoon Pchip's DAC ("monster window") path corrupts data
when used by 32-bit PCI cards using DAC addresses above 4 GiB, even on
cards whose DAC support is otherwise solid: the same cards work
correctly with DAC on Rawhide (MCPCIA) systems, and native 64-bit PCI
cards are unaffected on Tsunami/Typhoon itself. Corruption shows up as
64-byte chunks (one 21264 cache block) of unrelated data - typically
identifiable content belonging to other processes' concurrent DMA -
substituted into the transfer; the rate varies from none to several
kilobytes per run and has not been tied to any particular alignment.

Work around this by capping affected devices to 32-bit DMA, which
routes them through the existing scatter-gather window instead of DAC.
Conventional PCI provides no status bit to distinguish a 32-bit from a
64-bit option card, so use the presence of a 64-bit memory BAR as a
practical proxy. This covers every affected card seen so far, but is
a proxy rather than a direct test: it will also needlessly restrict a
handful of 64-bit cards that only expose 32-bit BARs (e.g. QLogic
ISP1080, ISP10160). These controllers are not known to be supported by
SRM firmware and are therefore uncommon on Alpha systems, so the
trade-off is accepted.

I don't think it is. You only need SRM-compatible device to boot
the kernel, and then you are free to use any sort of PCI mass storage
controllers supported by Linux. Personally I'm using CF card in IDE mode
as a boot device and PCI SATA controller for everything else for some
20 years. My controller is a cheap 32-bit one because UP1500 PCI is
32-bit only, but there are much more advanced 3ware 64-bit PCI-X SATA
cards still available at very affordable prices. We don't want to limit
them to 32-bit DMA addresing.

The only driver currently known to hit this is qla1280 with an
ISP1040 card and a 64-bit DMA mask, which is a common and
SRM-supported configuration on Alpha.

So it's just one unfortunate core-logic/controller combination
and should be handled as such. Obvious place to check for this is
alpha_pci_suppurted() (which ought to be named alpha_pci_dma_supported,
BTW). If we simply reject 64-bit mask, the qla1280 driver falls back
to DMA_BIT_MASK(32) - see qla1280_probe_one() function in
drivers/scsi/qla1280.c.

The patch below is compile-tested only.

Ivan.

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 955b6ca61627..d60c4c2aa8bb 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c

@@ -6,6 +6,7 @@
 #include <linux/kernel.h>
 #include <linux/mm.h>
 #include <linux/pci.h>
+#include <linux/pci_ids.h>
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/export.h>

@@ -786,6 +787,16 @@ static int alpha_pci_supported(struct device *dev, u64 mask)
 	struct pci_controller *hose;
 	struct pci_iommu_arena *arena;
 
+	/* The tsunami monster window doesn't cope well with QLogic ISP1040
+	   chipset's bus master DAC. Reject the 64-bit DMA mask request
+	   for such a card, so that the qla1280 driver falls back to
+	   32-bit DMA mask. */
+	if (pdev && mask == DMA_BIT_MASK(64) &&
+	    hwrpb->sys_type == ST_DEC_TSUNAMI &&
+	    pdev->vendor == PCI_VENDOR_ID_QLOGIC &&
+	    pdev->device == PCI_DEVICE_ID_QLOGIC_ISP1020)
+		return 0;
+
 	/* If there exists a direct map, and the mask fits either
 	   the entire direct mapped space or the total system memory as
 	   shifted by the map base */