Re: [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/3/26 16:40, Niklas Cassel wrote:
> Hallå Roland,
> 
> On Thu, Sep 03, 2026 at 01:35:40PM +0000, Roland Waltersson wrote:
>>
>> (analysis provided by Claude)
>> Hello,
>>
>> Commit 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron
>> JMB582/JMB585") makes a JMicron JMB585 unusable on our board.  I
>> believe the cause is not the quirk itself but a pre-existing gap in
>> ahci_start_fis_rx(), which the quirk newly exposes for this
>> controller.
>>
>> Hardware
>> --------
>>
>>    - congatec conga-TCR8 COM Express Type 6 module
>>      (AMD Ryzen Embedded 8000, Zen 4), BIOS TCR8R904 dated 2025-11-11
>>    - JMicron JMB585 SATA controller on our own carrier board,
>>      at PCI 0000:02:00.0
>>    - AMD-Vi IOMMU enabled, default (lazy DMA) domain type
>>
>> Symptom
>> -------
>>
>> The controller's link never comes up and the boot dies:
>>
>>    ahci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 address=0x80fffc0440 flags=0x0030]
>>    ahci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 address=0x80fffc0000 flags=0x0010]
>>    ata2: softreset failed (1st FIS failed)
>>    ata2: reset failed, giving up
>>
>> The disk never appears, so our initramfs cannot mount the rootfs and
>> switch_root panics with "Attempted to kill init!".
>>
>> Analysis
>> --------
>>
>> AHCI_HFLAG_32BIT_ONLY causes ahci_save_initial_config() to clear
>> HOST_CAP_64.  In ahci_start_fis_rx(), the upper halves of the command
>> list and FIS receive base addresses are written only when HOST_CAP_64
>> is set:
>>
>>       if (hpriv->cap & HOST_CAP_64)
>>             writel((pp->cmd_slot_dma >> 16) >> 16,
>>                    port_mmio + PORT_LST_ADDR_HI);
>>       writel(pp->cmd_slot_dma & 0xffffffff, port_mmio + PORT_LST_ADDR);
>>
>>       if (hpriv->cap & HOST_CAP_64)
>>             writel((pp->rx_fis_dma >> 16) >> 16,
>>                    port_mmio + PORT_FIS_ADDR_HI);
>>       writel(pp->rx_fis_dma & 0xffffffff, port_mmio + PORT_FIS_ADDR);
>>
>> There is no else branch, so with the quirk active PxCLBU and PxFBU are
>> never written and retain whatever firmware left in them.
>>
>> The fault addresses decompose accordingly:
>>
>>    0x80fffc0000  ->  low 0xfffc0000, high 0x00000080
>>    0x80fffc0440  ->  low 0xfffc0440, high 0x00000080
>>
>> The low halves are exactly the IOVAs dma-iommu hands out for a
>> 32-bit-masked PCI device (the allocator works downward from the top of
>> the range, so the command list and FIS receive area land just under
>> 4 GB).  The constant 0x80 in the high half is a value the kernel never
>> wrote; on this platform it places the DMA target at 512 GB, inside the
>> above-4G PCIe MMIO window.
>>
>> This also explains why booting with iommu=off does not help: without
>> the IOMMU the transfer simply goes to that MMIO address silently
>> instead of faulting, and the FIS still never arrives.
>>
>> Confirmation
>> ------------
>>
>> Reverting 105c42566a55 restores normal operation.  That is obviously
>> not a fix, since it reinstates the broken 64-bit DMA the commit exists
>> to prevent.
>>
>>
>> I have only reproduced this on 5.15.215 (the quirk reached us as
>> 4fc637dcad14 in v5.15.209); I have not tested mainline.  The
>> ahci_start_fis_rx() code above is however unchanged in current
>> mainline, so I expect any AHCI_HFLAG_32BIT_ONLY controller sitting
>> behind an IOMMU whose firmware leaves PxCLBU/PxFBU non-zero to hit the
>> same problem.
>>
>> I can test patches on this hardware.
> 
> Thank you for the detailed analysis.
> 
> I have sent a patch here:
> https://lore.kernel.org/linux-ide/20260903200349.1316460-2-cassel@kernel.org/
> 
> Which I hope will solve your problem.
> 
> 
> 
> Side note:
> While it seems like you have found a real problem for devices that actually
> need AHCI_HFLAG_32BIT_ONLY. It appears that most devices that have either
> AHCI_HFLAG_32BIT_ONLY or AHCI_HFLAG_43BIT_ONLY does not need it at all,
> which AFAICT, includes all ASMedia and JMicron SATA controllers.
> (So ideally, we should drop these for the ASMedia and JMicron SATA controllers.)
> 
> The only controller that actually seems to need it is ATA SB600.
> 
> If you look at:
> https://github.com/artmoty-dev/n5pro-jmb585-fix
> 
> It seems like adding amd_iommu=pgtbl_v2 to the kernel command line
> works around the problem (without the need for any quirk).
> 
> If this was an actual problem with JMB585, changing the AMD IOMMU
> page table format would not solve the problem.
> 
> AMD themselves have even confirmed that their IOMMU is buggy,
> and will misbehave once the 32-bit IOVA space is exhausted:
> https://lore.kernel.org/linux-ide/d49add14-c8de-4b6b-9049-4a07e5692ee9@amd.com/
> 
> And that the workaround is to use amd_iommu=pgtbl_v2.
> 
> It also explains the weirdness that the problem could not be reproduced when
> disabling the AMD IOMMU:
> https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/T/#u
> 
> So, since you have already shared that you have an AMD IOMMU enabled,
> I strongly suggest that you enable amd_iommu=pgtbl_v2 to workaround issues
> with this IOMMU. Yes, the AHCI_HFLAG_32BIT_ONLY will workaround the problem
> for your SATA controller, but you probably have other devices behind your
> IOMMU as well.
> 
> Ideally, AMD would send a patch that forces the driver to use pgtbl_v2 for
> all IOMMU versions that supports pgtbl_v2 (amd_iommu_v2_pgtbl_supported()).
> 
> 
> Kind regards,
> Niklas

So regarding

https://lore.kernel.org/linux-ide/d49add14-c8de-4b6b-9049-4a07e5692ee9@amd.com/ 
yes it should be a BIOS issue.

But I'm /trying/ to come up with a patch that could help to change some 
registers that would help without a BIOS update.

Can you please confirm a few things?

1. PCI topology of the system (I specifically want lspci -ttvvnn)
2. F/M/R from /proc/cpuinfo
3. Turn on  amd_smn_debugfs_enable=1 on kernel command line.
Then use debugfs to get me the outputs from the SMN reads of these 
registers:


        0x111401d0,
        0x111411d0,
        0x111421d0,
        0x111431d0,
        0x111441d0,
        0x112401d0,
        0x112411d0,
        0x112421d0,
        0x112431d0,
        0x112441d0,
        0x112451d0,
        0x113401d0,
        0x114401d0,

Something like this might work.

sudo bash <<'EOF'
set -euo pipefail

if ! mountpoint -q /sys/kernel/debug; then
     mount -t debugfs debugfs /sys/kernel/debug
fi

dir=/sys/kernel/debug/x86/amd_smn
test -d "$dir" || {
     echo "Missing $dir; verify CONFIG_DEBUG_FS and 
amd_smn_debugfs_enable=1"
     exit 1
}

addresses=(
     0x111401d0
     0x111411d0
     0x111421d0
     0x111431d0
     0x111441d0
     0x112401d0
     0x112411d0
     0x112421d0
     0x112431d0
     0x112441d0
     0x112451d0
     0x113401d0
     0x114401d0
)

printf '0\n' > "$dir/node"

for address in "${addresses[@]}"; do
     printf '%s\n' "$address" > "$dir/address"

     old=$(cat "$dir/value")
     [[ $old =~ ^0x[[:xdigit:]]{8}$ ]] || {
         echo "$address: invalid read: $old"
         exit 1
     }

     printf '%s: %s -> %s\n' "$address" "$old" "$readback"
done
EOF