https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270816
--- Comment #10 from [email protected] --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b941d1c64e58708c93621cc07ed1c8e5e709cd48 commit b941d1c64e58708c93621cc07ed1c8e5e709cd48 Author: Marius Strobl <[email protected]> AuthorDate: 2026-02-02 21:30:42 +0000 Commit: Marius Strobl <[email protected]> CommitDate: 2026-02-02 21:57:56 +0000 sym(4): Map HCB memory as uncacheable also on x86 As part of making the chip-specific mix and match of different accesses (DMA/bus space) work as desired, the intent is to map the HCB memory as uncacheable. Prior to VM_MEMATTR_*, the !x86 way of indicating this to bus_dmamem_alloc(9) was BUS_DMA_COHERENT. Then later on in 2db99100a4, BUS_DMA_NOCACHE was hooked up to VM_MEMATTR_UNCACHEABLE for x86. As it turns out, still as of today bus_dmamem_alloc(9) differs in this regard across architectures. On arm, it still supports BUS_DMA_COHERENT only for requesting uncacheable DMA and x86 still uses BUS_DMA_NOCACHE only. On arm64 and riscv, BUS_DMA_COHERENT seems to effectively be an alias for BUS_DMA_NOCACHE. Thus, allocate the HCB memory with BUS_DMA_COHERENT | BUS_DMA_NOCACHE, so we get uncacheable memory on all architectures including x86 and so loads and stores from/to HCB won't get reordered. However, even on x86 we still need to use at least compiler barriers to achieve the desired program order. This change should also fix panics due to out-of-sync data seen with FreeBSD VMs on top of OpenStack and HBAs of type lsiLogic as a result of loads and stores getting reordered. [1] While at it: - Nuke the unused SYM_DRIVER_NAME macro. - Remove unused/redundant HCB members and correct a comment typo. PR: 270816 [1] MFC after: 3 days sys/dev/sym/sym_hipd.c | 46 +++++++++++++++++++--------------------------- 1 file changed, 19 insertions(+), 27 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
