On Thu, 31 Oct 2024, Magnus Lindholm wrote: > 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 think Thomas will be unhappy about disabling DAC completely for the 1040: as I infer from his response it is indeed required for his Octane to operate correctly, and which also presumably implies he does have revision C of the chip to verify your fix with. Thomas? > 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. Great! > 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? Well spotted! This predates kernel.org git history, but I was able to track the origin down with a copy of the LMO git tree, and it has always been like this since the introduction of these macros in 2.6.9 with <https://lore.kernel.org/r/20040606125728.GB31063@xxxxxx/>. This also means that the ISP_CFG0_1040A check also added in 2.6.9 with <https://lore.kernel.org/r/20040606125825.GE31063@xxxxxx/> will never match, possibly meaning that this code wasn't actually ever verified with affected 1040A hardware. This might also explain why a later change made with commit 0888f4c33128 ("[SCSI] qla1280: don't use bitfields for hardware access in isp_config") went unnoticed that changed the semantics of the workaround from keeping bursts unconditionally disabled with the 1040A to making them enabled in the absence of NVRAM. NB comments for the FIFO threshold surely are suspicious too. Christoph can you please have a look into it? It seems like something you ought to be quite familiar with if not for the passage of time. Maciej
