From: Magnus Lindholm <linmag7@gmail.com>
To: richard.henderson@linaro.org, mattst88@gmail.com,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org
Cc: Magnus Lindholm <linmag7@gmail.com>
Subject: [PATCH v2 0/2] alpha: disable DAC for 32-bit PCI cards on Tsunami/Typhoon
Date: Mon, 24 Aug 2026 19:36:52 +0200 [thread overview]
Message-ID: <20260824181126.3559638-1-linmag7@gmail.com> (raw)
This is a follow-up to a patch I posted last year (Sep 2025, "[PATCH
0/1] alpha: disable DAC for 32-bit PCI on tsunami"), which was not
merged.
Changes since v1:
- Split into two patches: generic bus_dma_limit plumbing (1/2) and
the Tsunami policy itself (2/2).
- Rebased onto current mainline (pci_iommu.c's DMA-mapping API moved
from map_page()/virtual addresses to map_phys()/phys_addr_t
- bus_dma_limit is now treated as a numeric address ceiling rather
than a bitmask: the DAC path in pci_map_single_1()/sg_fill() is
bound-checked against it directly, instead of folding it into the
DAC capability test in pci_dac_dma_supported() (which is otherwise
unchanged). Fixed a NULL-pointer dereference this exposed on
no-IOMMU machines once that bound check could fail.
- Use ST_DEC_TSUNAMI instead of the raw sys_type value 34.
Boot tested on an AlphaServer ES40 (Tsunami) with a QLogic ISP1040B
controller.
Original background, still accurate:
I've spent quite some time trying to make the qla1280 driver work
with 64-bit DMA on Alpha/Tsunami systems with more than 2GB RAM. Many
thanks to Martin, James, Maciej, Thomas and Christoph who took the
time to provide feedback and testing during my attempts.
This is what I've concluded:
* The ISP1040B (32-bit card) works with a 64-bit DMA mask on a 21164
Rawhide machine - the card itself supports DAC, even though the
data sheet doesn't officially claim support until rev C (as Thomas
Bogendoerfer pointed out earlier).
* The ISP1080 (64-bit PCI slot/card) works with a 64-bit DMA mask on
a 21264 Tsunami machine - so the monster window itself works fine
on Tsunami.
* Data gets corrupted on Alpha/Tsunami specifically when DAC/monster
window is used by a 32-bit PCI card. The amount corrupted varies a
lot between runs, from none at all to several kilobytes out of 20MB
transferred. When it happens, it's always in 64-byte chunks, which
coincides with the 21264's cache block size. Manual inspection of
the corrupted data shows it's memory content from other active
processes doing DMA on other drives/controllers at the time.
The fix is unchanged from the original posting: limit 32-bit PCI
cards from using DAC/monster window DMA on Tsunami based Alphas, by
setting bus_dma_limit to DMA_BIT_MASK(32) for devices that have no
64-bit memory BAR. There are 64-bit PCI cards that only have 32-bit
memory BARs, like the QLogic ISP1080 and ISP10160 SCSI controllers;
these will be needlessly constrained even though they work correctly
on Tsunami. I believe this is an acceptable trade-off, since those
controllers are not known to be supported by SRM firmware and are
therefore uncommon on Alpha systems.
In practice there are very few 32-bit PCI cards likely to be used on
Alpha with drivers that request 64-bit DMA addressing. The only
example I've found is the qla1280 driver with an ISP1040 controller,
which is supported by most SRM firmware versions and hence fairly
common on Alpha systems.
Magnus Lindholm (2):
alpha: respect dev->bus_dma_limit as the effective DMA address ceiling
alpha: disable DAC for 32-bit PCI cards on Tsunami/Typhoon
arch/alpha/kernel/pci.c | 22 ++++++++++++++++++++++
arch/alpha/kernel/pci_iommu.c | 22 ++++++++++++++++------
2 files changed, 38 insertions(+), 6 deletions(-)
--
2.53.0
next reply other threads:[~2026-08-24 18:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 17:36 Magnus Lindholm [this message]
2026-08-24 17:36 ` [PATCH v2 1/2] alpha: respect dev->bus_dma_limit as the effective DMA address ceiling Magnus Lindholm
2026-08-24 17:36 ` [PATCH v2 2/2] alpha: disable DAC for 32-bit PCI cards on Tsunami/Typhoon Magnus Lindholm
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824181126.3559638-1-linmag7@gmail.com \
--to=linmag7@gmail.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
all inboxes | Powered by JetHome®