Re: [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585
From: Mario Limonciello <mario.limonciello@amd.com>
Date: 2026-09-04 12:38:19
On 9/4/26 06:14, Niklas Cassel wrote:
Hello Mario, On Fri, Sep 04, 2026 at 05:20:06AM +0000, Roland Waltersson wrote:quoted
Here are some debug printouts. Note that I am on 5.15 so amd_smn_debugfs_enable is not available - I printed the registers anyway: root@maglin25:NCA ~ # root=00:00.0 root@maglin25:NCA ~ # lspci -nn -s $root # sanity-check: must be a 1022: AMD root complex 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:14e8] root@maglin25:NCA ~ # root@maglin25:NCA ~ # for a in 0x111401d0 0x111411d0 0x111421d0 0x111431d0 0x111441d0 \quoted
0x112401d0 0x112411d0 0x112421d0 0x112431d0 0x112441d0 0x112451d0 \ 0x113401d0 0x114401d0; do setpci -s $root 60.l=$a v1=$(setpci -s $root 64.l) setpci -s $root 60.l=$a v2=$(setpci -s $root 64.l) printf '%s: 0x%s%s\n' "$a" "$v1" "$([ "$v1" = "$v2" ] || echo " MISMATCH 0x$v2")" done0x111401d0: 0x00000100 0x111411d0: 0x00000000 0x111421d0: 0x00000100 0x111431d0: 0x00000100 0x111441d0: 0x00000000 0x112401d0: 0x00000100 0x112411d0: 0x00000100 0x112421d0: 0x00000100 0x112431d0: 0x00000100 0x112441d0: 0x00000100 0x112451d0: 0x00000100 0x113401d0: 0x00000100 0x114401d0: 0x00000100Just to clarify, Roland is not one of the people who has been complaining about silent corruption after exhausting the 32-bit IOVA space.
Got it.
Roland complained that the AHCI_HFLAG_32BIT_ONLY quirk is making his JMB585 SATA controller not even detect his drive when probing the driver, so he can't even mount his filesystem. So this is a separate issue. You should probably reach out to someone who has seen the 32-bit IOVA space exhaustion issue, i.e.: Mikael Etienne - issue with addresses larger than 32-bit on AMD SATA controller https://lore.kernel.org/linux-ide/178789300872.392066.15963676631650361573@gmail.com/ (local) He claims that he cannot reproduce the corruption when using iommu=pt or Arthur Husband - issue with addresses larger than 32-bit on JMicron JMB585 https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/ (local) His github claims that he cannot reproduce the corruption when using amd_iommu=pgtbl_v2 https://github.com/artmoty-dev/n5pro-jmb585-fix or Alvin Lim - issue with addresses larger than 32-bit for ASMedia ASM1166 https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/ (local) His github claims that he cannot reproduce it with amd_iommu=off https://github.com/Alvinwylim/asm1166-iommu-dma-corruption but it also claims that iommu=pt is insufficient. Note that we never merged this patch, because we never to any confirmation from ASMedia that the controller was at fault. I don't know why Alvin claimed that iommu=pt was insufficient, but for Mikael the problem was not reproducible with iommu=pt. Could there perhaps be different versions of the AMD IOMMU? The only thing that I have seen in common so far, is that all bug reports, JMicron JMB582/585 / ASMedia ASM1166 / AMD SATA controller, have been using an AMD IOMMU. Note that there is one separate problem, Lennert Buytenhek actually got AMD IOMMU page faults, rather than silent corruption: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/ (local) This was actually verified by ASMedia to be a controller issue that they only support 43-bit DMA, and they provided a list of affected controllers: https://lore.kernel.org/linux-ide/ZbopwKZJAKQRA4Xv@x1-carbon/ (local) Note that these controllers where quirked with 43-bit DMA, and that ASM1166 - which Alvin had issues with even for 32-bit addresses - was not in that list. Knowing what we know now, we would never have accepted the 32-bit only DMA quirk for the JMicron JMB582/585 controllers, without at least seeing a single bug report from a user with an Intel or ARM IOMMU.
Thanks for sharing all of these.
quoted hunk ↗ jump to hunk
We probably want to send a patch that drops the JMicron JMB582/585 32-bit DMA quirk. But first we want: 1) Someone with an JMicron JMB582/585 + Intel IOMMU or ARM IOMMU running in enforcing mode, to run the reproducer written by Mikael: #### fio, io_uring engine (libaio not tested yet). Write the canary once: fio --name=canary --filename=/srv/12to/.sata-canary --size=256G --bs=128k \ --ioengine=io_uring --direct=1 --iodepth=32 \ --verify=crc32c --verify_interval=4096 --rw=write \ --do_verify=0 --fsync_on_close=1 Then loop the verification until it fails: while :; do fio --name=canary --filename=/srv/12to/.sata-canary --size=256G --bs=128k \ --ioengine=io_uring --direct=1 --iodepth=32 \ --verify=crc32c --verify_interval=4096 --rw=write \ --verify_only=1 --verify_fatal=1 || break done The reboot-without-rewrite protocol: when it fails, reboot and re-run only the verification loop above. The canary file is never rewritten. It verifies clean. #### With the 32-bit only quirk dropped:diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 58f512f8952a..1cee901f8e72 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c@@ -215,8 +214,7 @@ static const struct ata_port_info ahci_port_info[] = { }, /* JMicron JMB582/585: 64-bit DMA is broken, force 32-bit */ [board_ahci_jmb585] = { - AHCI_HFLAGS (AHCI_HFLAG_IGN_IRQ_IF_ERR | - AHCI_HFLAG_32BIT_ONLY), + AHCI_HFLAGS (AHCI_HFLAG_IGN_IRQ_IF_ERR), .flags = AHCI_FLAG_COMMON, .pio_mask = ATA_PIO4, .udma_mask = ATA_UDMA6,To verify that this is actually not a SATA controller problem. 2) A fix for the AMD IOMMU driver to be merged, and backported to stable, such that us writing a fix that drops the 32-bit only DMA quirk for JMicron JMB582/585, which when backported to stable, will not cause users with an AMD IOMMU to silently get their filesystem corrupted.
Right now what I'm thinking of doing is a quirk in arch/x86/pci/fixup.c to set the registers that could influence this issue. An alternative may be some quirks to the AMD IOMMU driver to avoid using the upper 5 bits for the IOVA allocations (making it 59 bit).