On Tue, 5 Nov 2024, Thomas Bogendoerfer wrote: > On Mon, 4 Nov 2024 21:52:36 +0000 (GMT) > "Maciej W. Rozycki" <macro@xxxxxxxxxxx> wrote: > > > On Mon, 4 Nov 2024, Magnus Lindholm wrote: > > > > > Use dma_get_required_mask() to determine an acceptable DMA_BIT_MASK > > > since on some platforms, qla1040 cards do not work with a 64-bit > > > mask. For example, on alpha systems with more than 2GB ram a 64-bit DMA mask > > > will result in filesystem corruption, but a 64-bit mask is required on > > > IP30/MIPS. > > > > This is missing the point, you get filesystem corruption because *your > > card* does not support 64-bit DMA addressing and not because your Alpha > > system has an issue with it. > > I've checked one of my Octane boards and there are ISP1040B chips on > the board, so even ISP1040B is able to address 64bits. > > How does the memory map look for more and 2GB ram on the ES40 ? Memory is added linearly from 0 up to 32GiB in the host address space, but that that's not how it's addressed from the PCI side by DMA masters. Here's how Linux sets up PCI DMA decoding windows with the Tsunami/Typhoon chipset: * Note: Window 3 is scatter-gather only * * Window 0 is scatter-gather 8MB at 8MB (for isa) * Window 1 is scatter-gather (up to) 1GB at 1GB * Window 2 is direct access 2GB at 2GB (window 3 is not enabled by Linux). Windows 0-2 decode up to 2GiB each anywhere in the 32-bit PCI DMA address space and map to memory anywhere in the host 32GiB address space (SG requests do this via IOMMU). Window 3 can work the same as windows 0-2 or decode 4GiB anywhere in the low 32GiB of the PCI DMA address space. The monster window previously mentioned maps 32GiB of host address space directly at 1TiB in the PCI DMA address space. Maciej
