HI, I don't have a QLA1040 revC to test with, but I've put together a much smaller patch which just limits the DMA_BIT_MASK to 32-bit on 1020/1040 cards this should at least not break anything while fixing the most urgent problems with file system corruption on some combination of hardware/memory. Thanks for the pointers to tsunami chipsets though, I'll try to enable some debugging to see what's going on when I hit this problem with the qlogic card. I'll clean up the chip revision reporting code to see if I can improve things there, this will be as a separate patch then. I have one question regarding the hardware revision on 1040 chips, according to qla1280.h we have this: #define ISP_CFG0_HWMSK 0x000f /* Hardware revision mask */ #define ISP_CFG0_1020 BIT_0 /* ISP1020 */ #define ISP_CFG0_1020A BIT_1 /* ISP1020A */ #define ISP_CFG0_1040 BIT_2 /* ISP1040 */ #define ISP_CFG0_1040A BIT_3 /* ISP1040A */ #define ISP_CFG0_1040B BIT_4 /* ISP1040B */ #define ISP_CFG0_1040C BIT_5 /* ISP1040C */ But when I examine the register it looks more like: #define ISP_CFG0_HWMSK 0x000f /* Hardware revision mask */ #define ISP_CFG0_1020 1 /* ISP1020 * #define ISP_CFG0_1020A 2 /* ISP1020A */ #define ISP_CFG0_1040 3 /* ISP1040 */ #define ISP_CFG0_1040A 4 /* ISP1040A */ #define ISP_CFG0_1040B 5 /* ISP1040B */ #define ISP_CFG0_1040C 6 /* ISP1040C */ Which is consistent with how NetBSD does things in their ISP driver. Also, in this case the HWMSK actually works for filtering out the hardware revision part of the CFG0 register, since it would actually require a 6-bit mask to match the current definitions in qla1280.c, right? Magnus On Thu, Oct 31, 2024 at 8:37 AM Maciej W. Rozycki <macro@xxxxxxxxxxx> wrote: > 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 >
