On Wed, 30 Oct 2024, Magnus Lindholm wrote:
> Thanks for your reply, I guess this suggests that this is an
> alpha-platform specific problem then? I can run the QL1040 card fine
> with the original qla1280.c driver ( in a 64-bit slot on the ES40 )
> just as long as I don't put more than 2GB ram in the system, this is
> when I start seeing the issues with file system corruption. As soon as
> S/G buffers are allocated on addresses above 32-bit, the QL1040 cannot
> deal with this, unless enforcing a DMA_BIT_MASK(32). The same card
> runs fine under Tru64 UNIX on the same system, however, I don't know
> how the Tru64 driver sets the DMA mask, if it enables full 64-bit
> addressing or not.
I find this interesting. Documentation for the Tsunami chipset indicates
DAC support[1]:
"In case of a PCI dual-address cycle command, the high-order PCI address
bits <63:40> are compared to the constant value 0x0000_01 (that is, bit
<40> = 1; all other bits = 0). If these bits match, a monster window hit
has occurred and the low-order PCI address bits <34:0> are used unchanged
as the system address bits <34:0>. PCI address bits <39:35> are ignored.
The high-order 32 PCI address bits are available on b_ad<31:0> in the
second cycle of a DAC, and also on b_ad<63:32> in the first cycle of a DAC
if b_req64_l is asserted."
and I can see it handled in arch/alpha/kernel/pci_iommu.c; allocations can
be handed out with the TSUNAMI_DAC_OFFSET bit set. You might be able to
see if it triggers by defining DEBUG_ALLOC to 2 and checking messages from
DMA mappings in the kernel log.
I did a little research however and discovered that the DAC capability is
documented in the ISP1040C datasheet, but not in the ISP1040B one. So it
seems to me like it's the matter of the chip revision. I've skimmed over
the driver and as far as I can tell there's everything supplied there to
get this sorted now.
References:
[1] "Tsunami/Typhoon 21272 Chipset Hardware Reference Manual", Revision
4.0, Compaq Computer Corporation, Order Number: DS-0025A-TE, 21
October 1999, Section 10.1.4.4 "Monster Window DMA Address
Translation", p. 10-13
Maciej
