After spending quite some time trying to make the qla1280 driver work
with 64-bit DMA on alpha/tsunami systems with more than 2GB RAM, I
haven't given up on finding the root cause why this doesn't work but
I propose making 32/64 bit optional in the kernel config. Many thanks
to Martin, James, Maciej, Thomas and Christoph who has take the time
to provide feedback and testing during my attempts.

Some platforms like for example the SGI Octace2, require full 64-bit
addressing in order for the qla1280 driver to work. On other systems,
like the tsunami based Alpha systems, 32-bit PCI Qlogic SCSI controllers
(like the ISP1040 series) will not work properly on systems with more
than 2GB RAM installed. For some reason the combination of using PCI DAC
cycles and the enabling the DMA "monster window" on the tsunami based
alphas will result in file system corruption with the Qlogic ISP driver.
This is not the case on other alpha systems, such as rawhide based
systems, like the Alphaserver 4100, on this platform cards like
the qlogic 32-bit PCI (ISP1040B) works fine with PCI DAC cycles and
the "monster window" enabled. In order for the qla1280 driver to work
with ISP1040 chips on tsunami based alphas the driver must be compiled
with 32-bit DMA addressing. Most SRM firmware versions allow alphas to
boot from Qlogic ISP1040 SCSI controllers and hence having a simple way
to limit DMA addressing to 32-bits is relevant.

 drivers/scsi/Kconfig   | 17 +++++++++++++++++
 drivers/scsi/qla1280.c |  2 ++
 2 files changed, 19 insertions(+)

-- 
2.49.0

On Mon, 28 Jul 2025, Magnus Lindholm wrote:

> Some platforms like for example the SGI Octace2, require full 64-bit
> addressing in order for the qla1280 driver to work. On other systems,
> like the tsunami based Alpha systems, 32-bit PCI Qlogic SCSI controllers
> (like the ISP1040 series) will not work properly on systems with more
> than 2GB RAM installed. For some reason the combination of using PCI DAC
> cycles and the enabling the DMA "monster window" on the tsunami based
> alphas will result in file system corruption with the Qlogic ISP driver.
> This is not the case on other alpha systems, such as rawhide based
> systems, like the Alphaserver 4100, on this platform cards like
> the qlogic 32-bit PCI (ISP1040B) works fine with PCI DAC cycles and
> the "monster window" enabled. In order for the qla1280 driver to work
> with ISP1040 chips on tsunami based alphas the driver must be compiled
> with 32-bit DMA addressing. Most SRM firmware versions allow alphas to
> boot from Qlogic ISP1040 SCSI controllers and hence having a simple way
> to limit DMA addressing to 32-bits is relevant.

 Given the description it seems to me it will best be handled as a quirk 
in arch/alpha/kernel/pci.c, at least in the interim.

 If it turns out a generic issue with DAC handling in the Tsunami chipset, 
then a better approach would be a generic workaround for all potentially 
affected devices, but it does not appear we have existing infrastructure 
for that.  Just setting the global DMA mask would unnecessarily cripple 
64-bit option cards as well, but it seems to me there might be something 
relevant in arch/mips/pci/fixup-sb1250.c; see `quirk_sb1250_pci_dac' and 
the comments above it.

 The situation is a bit different here as the bus is a proper 64-bit one, 
but the quirk could only limit the individual DMA mask to 32 bits for 
devices that have no 64-bit memory BARs.  I suspect there are no proper 
64-bit PCI option cards that only have I/O bars and I don't think there's 
any explicit status bit to tell 32-bit and 64-bit option cards apart.

 FWIW I was able to obtain such an option card and try it with my HiFive 
Unmatched RISC-V system, which has 16GiB of RAM.  It turned out picky 
though and despite being DEC-branded it refused to talk to a number of 
SCSI 1 CCS DEC disks, which work just fine with an Adaptec host adapter 
using the same cables and with DECstation systems they came with, but also 
break with a BusLogic MultiMaster host adapter (which seems odd as these 
host adapters have been reputably very robust).

 So I could only do limited testing with a single SCSI 2 disk that works 
everywhere, and that triggered no issues.  As I wanted to retain remote 
access to said problematic disks from the Unmatched machine I have left 
them wired to the Adaptec device, but I'll see if I can do more testing at 
my next visit to the lab around the weekend after next as I'm going to 
disassemble the Unmatched system anyway.

 HTH,

  Maciej

On Thu, Jul 31, 2025 at 11:49 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
ng a simple way
> > to limit DMA addressing to 32-bits is relevant.
>
>  Given the description it seems to me it will best be handled as a quirk
> in arch/alpha/kernel/pci.c, at least in the interim.
>
>  If it turns out a generic issue with DAC handling in the Tsunami chipset,
> then a better approach would be a generic workaround for all potentially
> affected devices, but it does not appear we have existing infrastructure
> for that.  Just setting the global DMA mask would unnecessarily cripple
> 64-bit option cards as well, but it seems to me there might be something
> relevant in arch/mips/pci/fixup-sb1250.c; see `quirk_sb1250_pci_dac' and
> the comments above it.
>
>  The situation is a bit different here as the bus is a proper 64-bit one,
> but the quirk could only limit the individual DMA mask to 32 bits for
> devices that have no 64-bit memory BARs.  I suspect there are no proper
> 64-bit PCI option cards that only have I/O bars and I don't think there's
> any explicit status bit to tell 32-bit and 64-bit option cards apart.
>

This approach would probably also work. This would mean limiting
32-bit PCI cards from using DAC/monster window DMA on Tsunami based
Alphas. In practice, I believe that there are very few 32-bit PCI cards that
are likely to be used on Alphas that have drivers which support 64-bit DMA
addressing. The only example I've found so far is the qla1280 driver.

Since not all tsunami based Alphas support more than 2GB RAM there are
even fewer examples where this will be a real problem. I'm not 100% sure
that there is a generic issue with DAC handling in the Tsunami chipset but
I'm suspecting that there is. I think that for DS20/ES40 systems using
Qlogic ISP1040 SCSI controllers would be the most likely (maybe the only)
real use case that I can think of.

I can put together a v2 patch based on  a similar approach as
`quirk_sb1250_pci_dac' mentioned above, if this is a better approach
than limiting the DMA mask on only the qlogic driver (by using a module option)

Regards

Magnus

Hi,

> >  If it turns out a generic issue with DAC handling in the Tsunami chipset,
> > then a better approach would be a generic workaround for all potentially
> > affected devices, but it does not appear we have existing infrastructure
> > for that.  Just setting the global DMA mask would unnecessarily cripple
> > 64-bit option cards as well, but it seems to me there might be something
> > relevant in arch/mips/pci/fixup-sb1250.c; see `quirk_sb1250_pci_dac' and
> > the comments above it.

I've been taking a closer look at the quirk_sb1250_pci_dac. It should indeed
be possible to implement a similar workaround on Alpha. I believe that would
require some fixes to the Alpha specific implementations in pci_iommu.c. For
one thing, the implementation does not respect 'dev->bus_dma_limit' which
is used in  the quirk_sb1250_pci_dac implementation.

I've put together a patch, and I'm testing it right now, that implements a quirk
similar to quirk_sb1250_pci_dac as well as makes stuff in pci_iommu.c take
'dev->bus_dma_limit' into consideration on Alpha. If this approach makes
sense I'll put out a new patch for review. Since this approach does not
touch the qla1280 SCSI driver, I won't send it to the linux-scsi list.

Regards

Magnus