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

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

[Arthur Husband]

The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA
support via the S64A bit in the AHCI CAP register, but their 64-bit DMA
implementation is defective. Under sustained I/O, DMA transfers targeting
addresses above 4GB silently corrupt data — writes land at incorrect
memory addresses with no errors logged.

This has been confirmed on multiple platforms (Minisforum N5 Pro,
Raspberry Pi, Unraid, Proxmox, TrueNAS) and is consistent with the
controller truncating or mishandling upper address bits during 64-bit
DMA transactions.

The failure pattern is identical to the ASMedia ASM1062 (commit
edb96a15dc18), which also falsely advertised 64-bit DMA and was fixed
with AHCI_HFLAG_32BIT_ONLY.

On the Minisforum N5 Pro specifically, the combination of the JMB585's
broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes
silent data corruption that is only detectable via checksumming
filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA
space is exhausted and the kernel transparently switches to 64-bit DMA
addresses.

Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585
(0x0585) before the generic JMicron class match, using a new board type
that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior)
with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks.

Investigation and patch development assisted by Claude (Anthropic AI).

Signed-off-by: Arthur Husband <artmoty@gmail.com>
---
 drivers/ata/ahci.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index XXXXXXX..XXXXXXX 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -51,6 +51,7 @@ enum board_ids {
 	board_ahci,
 	board_ahci_43bit_dma,
 	board_ahci_ign_iferr,
+	board_ahci_jmb585,
 	board_ahci_no_debounce_delay,
 	board_ahci_no_msi,
 	/*
@@ -115,6 +116,14 @@ static const struct ata_port_info ahci_port_info[] = {
 		.udma_mask	= ATA_UDMA6,
 		.port_ops	= &ahci_ops,
 	},
+	/* 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),
+		.flags		= AHCI_FLAG_COMMON,
+		.pio_mask	= ATA_PIO4,
+		.udma_mask	= ATA_UDMA6,
+		.port_ops	= &ahci_ops,
+	},
 	[board_ahci_no_debounce_delay] = {
 		.flags		= AHCI_FLAG_COMMON,
 		.link_flags	= ATA_LFLAG_NO_DEBOUNCE_DELAY,
@@ -XXX,7 +XXX,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
 	...

-	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
+	/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
+	{ PCI_VDEVICE(JMICRON, 0x0582), board_ahci_jmb585 },
+	{ PCI_VDEVICE(JMICRON, 0x0585), board_ahci_jmb585 },
+
+	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
 	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
 	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },

--

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

[Arthur Husband]

The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA
support via the S64A bit in the AHCI CAP register, but their 64-bit DMA
implementation is defective. Under sustained I/O, DMA transfers targeting
addresses above 4GB silently corrupt data — writes land at incorrect
memory addresses with no errors logged.

This has been confirmed on multiple platforms (Minisforum N5 Pro,
Raspberry Pi, Unraid, Proxmox, TrueNAS) and is consistent with the
controller truncating or mishandling upper address bits during 64-bit
DMA transactions.

The failure pattern is identical to the ASMedia ASM1062 (commit
edb96a15dc18), which also falsely advertised 64-bit DMA and was fixed
with AHCI_HFLAG_32BIT_ONLY.

On the Minisforum N5 Pro specifically, the combination of the JMB585's
broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes
silent data corruption that is only detectable via checksumming
filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA
space is exhausted and the kernel transparently switches to 64-bit DMA
addresses.

Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585
(0x0585) before the generic JMicron class match, using a new board type
that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior)
with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks.

Investigation and patch development assisted by Claude (Anthropic AI).

Signed-off-by: Arthur Husband <artmoty@gmail.com>
---
 drivers/ata/ahci.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index XXXXXXX..XXXXXXX 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -51,6 +51,7 @@ enum board_ids {
 	board_ahci,
 	board_ahci_43bit_dma,
 	board_ahci_ign_iferr,
+	board_ahci_jmb585,
 	board_ahci_no_debounce_delay,
 	board_ahci_no_msi,
 	/*
@@ -115,6 +116,14 @@ static const struct ata_port_info ahci_port_info[] = {
 		.udma_mask	= ATA_UDMA6,
 		.port_ops	= &ahci_ops,
 	},
+	/* 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),
+		.flags		= AHCI_FLAG_COMMON,
+		.pio_mask	= ATA_PIO4,
+		.udma_mask	= ATA_UDMA6,
+		.port_ops	= &ahci_ops,
+	},
 	[board_ahci_no_debounce_delay] = {
 		.flags		= AHCI_FLAG_COMMON,
 		.link_flags	= ATA_LFLAG_NO_DEBOUNCE_DELAY,
@@ -XXX,7 +XXX,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
 	...

-	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
+	/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
+	{ PCI_VDEVICE(JMICRON, 0x0582), board_ahci_jmb585 },
+	{ PCI_VDEVICE(JMICRON, 0x0585), board_ahci_jmb585 },
+
+	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
 	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
 	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },

--

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

[Damien Le Moal]

On 4/3/26 14:04, Arthur Husband wrote:
> The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA
> support via the S64A bit in the AHCI CAP register, but their 64-bit DMA
> implementation is defective. Under sustained I/O, DMA transfers targeting
> addresses above 4GB silently corrupt data — writes land at incorrect
> memory addresses with no errors logged.
> 
> This has been confirmed on multiple platforms (Minisforum N5 Pro,
> Raspberry Pi, Unraid, Proxmox, TrueNAS) and is consistent with the
> controller truncating or mishandling upper address bits during 64-bit
> DMA transactions.
> 
> The failure pattern is identical to the ASMedia ASM1062 (commit
> edb96a15dc18), which also falsely advertised 64-bit DMA and was fixed
> with AHCI_HFLAG_32BIT_ONLY.
> 
> On the Minisforum N5 Pro specifically, the combination of the JMB585's
> broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes
> silent data corruption that is only detectable via checksumming
> filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA
> space is exhausted and the kernel transparently switches to 64-bit DMA
> addresses.
> 
> Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585
> (0x0585) before the generic JMicron class match, using a new board type
> that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior)
> with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks.
> 
> Investigation and patch development assisted by Claude (Anthropic AI).

We do not do advertisement for commercial software. So please drop this.

> 
> Signed-off-by: Arthur Husband <artmoty@gmail.com>
> ---
>  drivers/ata/ahci.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index XXXXXXX..XXXXXXX 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -51,6 +51,7 @@ enum board_ids {
>  	board_ahci,
>  	board_ahci_43bit_dma,
>  	board_ahci_ign_iferr,
> +	board_ahci_jmb585,

Please move this entry down in the chipset specific section of the enum.

Other than this, looks OK to me. Thanks for the detailed commit message.

>  	board_ahci_no_debounce_delay,
>  	board_ahci_no_msi,
>  	/*
> @@ -115,6 +116,14 @@ static const struct ata_port_info ahci_port_info[] = {
>  		.udma_mask	= ATA_UDMA6,
>  		.port_ops	= &ahci_ops,
>  	},
> +	/* 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),
> +		.flags		= AHCI_FLAG_COMMON,
> +		.pio_mask	= ATA_PIO4,
> +		.udma_mask	= ATA_UDMA6,
> +		.port_ops	= &ahci_ops,
> +	},
>  	[board_ahci_no_debounce_delay] = {
>  		.flags		= AHCI_FLAG_COMMON,
>  		.link_flags	= ATA_LFLAG_NO_DEBOUNCE_DELAY,
> @@ -XXX,7 +XXX,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>  	...
> 
> -	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
> +	/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
> +	{ PCI_VDEVICE(JMICRON, 0x0582), board_ahci_jmb585 },
> +	{ PCI_VDEVICE(JMICRON, 0x0585), board_ahci_jmb585 },
> +
> +	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
>  	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>  	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },
> 
> --


-- 
Damien Le Moal
Western Digital Research

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

[Niklas Cassel]

On Thu, Apr 02, 2026 at 10:04:18PM -0700, Arthur Husband wrote:
> The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA
> support via the S64A bit in the AHCI CAP register, but their 64-bit DMA
> implementation is defective. Under sustained I/O, DMA transfers targeting
> addresses above 4GB silently corrupt data — writes land at incorrect
> memory addresses with no errors logged.
> 
> This has been confirmed on multiple platforms (Minisforum N5 Pro,
> Raspberry Pi, Unraid, Proxmox, TrueNAS) and is consistent with the
> controller truncating or mishandling upper address bits during 64-bit
> DMA transactions.

This does not make sense to me (probably because it is AI generated).

What is a platform here? Rasperry Pi is a SBC, TrueNAS is a Linux distro
based on Debian.

I would just drop this whole paragraph.


> 
> The failure pattern is identical to the ASMedia ASM1062 (commit
> edb96a15dc18), which also falsely advertised 64-bit DMA and was fixed
> with AHCI_HFLAG_32BIT_ONLY.

Please use the normal kernel style to reference commits, i.e.:
"commit '12 character SHA1' (description)"

git --no-pager show -s --abbrev-commit --abbrev=12 --pretty=format:"%h (\"%s\")%n"

Also, the SHA1 you are referencing does not exist in mainline.

Most likely you are thinking of:
commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia
ASM1061 controllers")

However, this commit uses flag AHCI_HFLAG_43BIT_ONLY
(and not AHCI_HFLAG_32BIT_ONLY as claimed by AI).


> 
> On the Minisforum N5 Pro specifically, the combination of the JMB585's
> broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes
> silent data corruption that is only detectable via checksumming
> filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA

We don't usually mention out of tree filesystems (ZFS) in our commit logs.


Thank you for the patch!


Kind regards,
Niklas

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

[Niklas Cassel]

Hello Arthur,

Please also prefix your subject with "ata: "
(I know that we have not always been consistent with this historically.)

i.e.
ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585


Kind regards,
Niklas

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

[Roland Waltersson]

(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.

Thanks,
Roland Waltersson

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

[Niklas Cassel]

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

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

[Mario Limonciello]

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

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

[Roland Waltersson]

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 \
>          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")"
> done
0x111401d0: 0x00000100
0x111411d0: 0x00000000
0x111421d0: 0x00000100
0x111431d0: 0x00000100
0x111441d0: 0x00000000
0x112401d0: 0x00000100
0x112411d0: 0x00000100
0x112421d0: 0x00000100
0x112431d0: 0x00000100
0x112441d0: 0x00000100
0x112451d0: 0x00000100
0x113401d0: 0x00000100
0x114401d0: 0x00000100

admin@swnc-np:NCA ~ $ lspci -ttvvnn
-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14e8]
           +-00.2  Advanced Micro Devices, Inc. [AMD] Device [1022:14e9]
           +-01.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ea]
           +-01.3-[01]----00.0  Intel Corporation Ethernet Controller I226-V [8086:125c]
           +-01.4-[02]----00.0  JMicron Technology Corp. JMB58x AHCI SATA controller [197b:0585]
           +-02.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ea]
           +-02.1-[03]----00.0  Intel Corporation I210 Gigabit Backplane Connection [8086:1537]
           +-02.2-[04]----00.0  Intel Corporation I210 Gigabit Backplane Connection [8086:1537]
           +-02.3-[05]----00.0  Intel Corporation I210 Gigabit Backplane Connection [8086:1537]
           +-02.4-[06]----00.0  Intel Corporation I210 Gigabit Backplane Connection [8086:1537]
           +-03.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ea]
           +-04.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ea]
           +-08.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ea]
           +-08.1-[07]--+-00.0  Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 [1002:1900]
           |            +-00.2  Advanced Micro Devices, Inc. [AMD] Family 19h (Model 74h) CCP/PSP 3.0 Device [1022:15c7]
           |            +-00.3  Advanced Micro Devices, Inc. [AMD] Device [1022:15b9]
           |            +-00.4  Advanced Micro Devices, Inc. [AMD] Device [1022:15ba]
           |            +-00.5  Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2]
           |            \-00.6  Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller [1022:15e3]
           +-08.2-[08]--+-00.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ec]
           |            \-00.1  Advanced Micro Devices, Inc. [AMD] AMD IPU Device [1022:1502]
           +-08.3-[09]--+-00.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14ec]
           |            +-00.3  Advanced Micro Devices, Inc. [AMD] Device [1022:15c0]
           |            \-00.4  Advanced Micro Devices, Inc. [AMD] Device [1022:15c1]
           +-14.0  Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b]
           +-14.3  Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e]
           +-18.0  Advanced Micro Devices, Inc. [AMD] Device [1022:14f0]
           +-18.1  Advanced Micro Devices, Inc. [AMD] Device [1022:14f1]
           +-18.2  Advanced Micro Devices, Inc. [AMD] Device [1022:14f2]
           +-18.3  Advanced Micro Devices, Inc. [AMD] Device [1022:14f3]
           +-18.4  Advanced Micro Devices, Inc. [AMD] Device [1022:14f4]
           +-18.5  Advanced Micro Devices, Inc. [AMD] Device [1022:14f5]
           +-18.6  Advanced Micro Devices, Inc. [AMD] Device [1022:14f6]
           \-18.7  Advanced Micro Devices, Inc. [AMD] Device [1022:14f7]

Cpuinfo:

vendor_id       : AuthenticAMD
cpu family      : 25
model           : 117
model name      : AMD Ryzen 5 PRO 8640U w/ Radeon 760M Graphics

BIOS is congatec TCR8R904

________________________________________
From: Mario Limonciello <mario.limonciello@amd.com>
Sent: Friday, September 4, 2026 12:36 AM
To: Niklas Cassel <cassel@kernel.org>; Roland Waltersson <roland.waltersson@netinsight.net>
Cc: artmoty@gmail.com <artmoty@gmail.com>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; David Laight <david.laight.linux@gmail.com>
Subject: Re: [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585
 
*EXTERNAL EMAIL*- Use caution before opening links or attachments

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

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

[Niklas Cassel]

Hello Mario,

On Fri, Sep 04, 2026 at 05:20:06AM +0000, Roland Waltersson wrote:
> 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 \
> >          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")"
> > done
> 0x111401d0: 0x00000100
> 0x111411d0: 0x00000000
> 0x111421d0: 0x00000100
> 0x111431d0: 0x00000100
> 0x111441d0: 0x00000000
> 0x112401d0: 0x00000100
> 0x112411d0: 0x00000100
> 0x112421d0: 0x00000100
> 0x112431d0: 0x00000100
> 0x112441d0: 0x00000100
> 0x112451d0: 0x00000100
> 0x113401d0: 0x00000100
> 0x114401d0: 0x00000100

Just to clarify, Roland is not one of the people who has been complaining
about silent corruption after exhausting the 32-bit IOVA space.

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/
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/
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/
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/
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/
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.


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.


Kind regards,
Niklas

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

[Mario Limonciello]

On 9/4/26 06:14, Niklas Cassel wrote:
> Hello Mario,
> 
> On Fri, Sep 04, 2026 at 05:20:06AM +0000, Roland Waltersson wrote:
>> 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 \
>>>           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")"
>>> done
>> 0x111401d0: 0x00000100
>> 0x111411d0: 0x00000000
>> 0x111421d0: 0x00000100
>> 0x111431d0: 0x00000100
>> 0x111441d0: 0x00000000
>> 0x112401d0: 0x00000100
>> 0x112411d0: 0x00000100
>> 0x112421d0: 0x00000100
>> 0x112431d0: 0x00000100
>> 0x112441d0: 0x00000100
>> 0x112451d0: 0x00000100
>> 0x113401d0: 0x00000100
>> 0x114401d0: 0x00000100
> 
> Just 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/
> 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/
> 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/
> 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/
> 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/
> 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.

> 
> 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).

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

[Niklas Cassel]

On Fri, Sep 04, 2026 at 07:38:06AM -0500, Mario Limonciello wrote:
> On 9/4/26 06:14, Niklas Cassel wrote:
> > 
> > 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).

No stress with regards to JMB582/585. We will keep the quirk as long as it
is needed to avoid the AMD IOMMU issue, but please CC me if you send out a
fix.

It is probably worse for those like Mikael Etienne, who is using an AMD 600
Series Chipset SATA Controller [1022:43f6], since for those SATA controllers,
we do not have a 32-bit only quirk that hides/workarounds the problem.


Kind regards,
Niklas

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

[Mikael Etienne]

Hi Niklas,

You asked whether there might be different versions of the AMD IOMMU. Here is my
full identification, so this can be compared rather than guessed:

  CPU        : AMD Ryzen 7 8700G w/ Radeon 780M (Phoenix), family 25, model 117,
               stepping 2
  Controller : AMD 600 Series Chipset SATA Controller [1022:43f6]
  Table      : ACPI IVRS v02 (AMD / AmdTable)
  IVHD       : AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x0
  Kernel     : 7.1.x, Fedora 44

The EFR field is probably the most direct discriminant. If Arthur, Alvin and
Lennert posted the same line, the "different IOMMU versions" hypothesis could be
tested immediately, with no extra hardware:

  journalctl -k -b | grep -E "IVHD EFR|IVRS"

That would be particularly worth it for Alvin, since iommu=pt is insufficient
for him while it is completely clean for me -- that is the only divergence
between our reports.

I cannot be your tester for point 1, unfortunately: I have neither a JMB582/585
nor an Intel or ARM IOMMU. The reproducer you quoted is current; one
clarification, fio verifies its own CRC32C, so the result does not depend on the
underlying filesystem.

On your point 2: I am working with Mario on the AMD IOMMU side. I have committed
to testing on my 600-series and reporting the outcome in the regression thread,
positive or negative. I cannot give a date -- the machine is under maintenance
work -- but I will report either way.

Kind regards,
Mikael Etienne

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

[Alvin Lim]

On Fri, Sep 04, 2026 at 11:55:38PM +0700, Mikael Etienne wrote:
> That would be particularly worth it for Alvin, since iommu=pt is
> insufficient for him while it is completely clean for me -- that is the
> only divergence between our reports.

There is no divergence, and the fault is mine. I owe the thread an
apology.

My writeup stated that iommu=pt is insufficient. I never tested it. I have
no data on iommu=pt on this machine in either direction, and I am not now
claiming the opposite either -- only that the statement was not mine to
make and should be disregarded wherever it has been read.

The cause was poor discipline in my own record keeping. My incident notes
recorded some things I had measured and some things I had picked up from
other people's reports about other hardware, and by the time I wrote them
up for publication the distinction had been lost. The published page then
read as though all of it were my own result. That is how an untested
claim ended up being cited on this list, and it is a fair description of
what went wrong.

I am cleaning that up now. The rewritten page contains only what I
personally tested and observed on this machine, plus an explicit section
listing what I did not test, so nobody has to guess which is which. The
previous version stays in git history rather than being quietly replaced.

What I actually observed
------------------------

  Controller : ASMedia ASM1166 [1b21:1166] rev 02, all 6 SATA bays
  Kernel     : 7.0.6-2-pve (Proxmox) at the time of the corruption
  IVHD       : AMD-Vi: Using global IVHD EFR:0x246577efa2054ada, EFR2:0x0

(Full platform details are at the end of this mail, in case they help
with deciding who tests what.)

Symptom, with the IOMMU enabled: silent non-deterministic read corruption
on every SATA disk. A single isolated read was often clean; six concurrent
reads of one file returned six different md5s. SMART clean, no link
resets, no MCE. NVMe on the same host was unaffected. On-disk data turned
out to be intact -- it was entirely a read-path problem.

The fix I applied was amd_iommu=off, and nothing else. The machine's RAM
was later changed, so it has now run under that single parameter at two
different physical address ranges:

  2026-06-17 -> 2026-08-01   45 days   32 GB   (30 GiB visible)
  2026-08-01 -> 2026-09-05   35 days   96 GB   (92 GiB visible)

Kernel error lines on this host, same grep either side of the fix:

  2026-06-15 -> 06-17 16:00   (~2.5 days)    4240
  2026-06-17 16:00 -> now     (80 days)         0

Zero corruption to date in both memory configurations.

One further correction I have to make, because it wrongly closed off a
test. My writeup said this part lacks GIOSup, so amd_iommu=pgtbl_v2 could
not work. I read that off the "Extended features" boot line and treated
the absence of the name there as absence of the feature. Decoding the
register instead, bit 48 (GIOSUP) and bit 4 (GT) are both set here, so on
my reading of amd_iommu_v2_pgtbl_supported() it should be available on
this box. I have not tested pgtbl_v2 either -- I have only established
that my stated reason for ruling it out was invalid.

What I did NOT test on this machine
-----------------------------------

  - iommu=pt
  - amd_iommu=pgtbl_v2
  - iommu.forcedac=1
  - any other kernel version
  - the 32-bit DMA quirk itself; no kernel was ever built with it
  - which DMA addresses were actually in play; never instrumented, so I
    cannot say whether the failing addresses were above or below 4 GB
  - any controller other than this ASM1166, and any non-AMD platform

I know the symptom, I know amd_iommu=off removes it, and I know this
controller handles physical addresses far above 4 GB without error. I do
not know the mechanism, and I should not have implied otherwise.

Accordingly, please treat my ASM1166 patch as withdrawn:

  https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/

I never built or ran a kernel with that quirk, and the submission did not
disclose that. Its premise -- that the controller cannot address above
4 GB -- is contradicted by the 80 days above.

The submission also carried a Fixes: tag naming commit 3bf614106094
("ata: ahci: add identifiers for ASM2116 series adapters"), together with
Cc: stable@vger.kernel.org. That Fixes tag was wrong, and I want to be
clear why rather than leave it as an assertion.

ahci_pci_tbl ends with a generic catch-all,
PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) -> board_ahci,
which is present in v5.10 and v6.1, both well before that commit. So the
ASM1166 already bound to board_ahci through the catch-all, and adding its
explicit ID did not change how it was handled. Nothing about DMA differed
before and after, so there was no regression for that commit to have
introduced.

That matters because of what the two tags do together: Fixes: is what the
stable tooling reads to decide which series a backport applies to, so with
Cc: stable@ beside it the pair would have aimed an untested patch at every
stable series containing that commit. Nothing came of it, because the
patch was never applied. It should not have been there all the same.

What I can offer as a test platform
-----------------------------------

Setting this out in full, so nobody has to reconstruct it from earlier
messages when deciding who should test what.

  Board      : AOOSTAR WTR MAX (6-bay mini NAS)
  CPU        : AMD Ryzen 7 PRO 8845HS (Zen 4)
  IOMMU      : AMD. EFR 0x246577efa2054ada, EFR2 0x0
               GIOSup (bit 48) and GT (bit 4) both set
  SATA       : one ASMedia ASM1166 [1b21:1166] rev 02, 6 ports,
               6 HDDs, 98 TB total, 2-3 TB free per filesystem
  NVMe       : present, on separate controllers, never affected
  OS         : Proxmox VE (Debian). Kernel 7.0.14-14-pve now;
               7.0.6-2-pve when the corruption happened
  Current    : running amd_iommu=off since 2026-06-17

What I do NOT have, so please do not wait on me for it: no JMicron
JMB582/585, no Intel or ARM IOMMU machine, and no SATA controller other
than this ASM1166. The JMB585-plus-Intel/ARM test asked for earlier in
this thread is not one I can run.

What I can do:

  - any boot parameter combination: amd_iommu=pgtbl_v2, iommu.forcedac=1,
    iommu=pt, or back to amd_iommu=off
  - older kernels from the Proxmox archive
  - build and run a custom kernel, if a patch needs testing
  - run the fio crc32c canary; there is room for a 256 GB canary and I can
    leave verification looping overnight

One constraint, stated up front rather than discovered later: this is a
live NAS and the affected controller carries real data, including a Ceph
OSD. Any test with the IOMMU re-enabled needs a scheduled window with the
filesystems unmounted and that OSD stopped. I would write the canary first
under amd_iommu=off, through the path I know is good, and then run
verify-only passes in the test configuration, so nothing is ever written
through a path under suspicion.

So: tell me which test would actually be useful and I will run it and
report the result either way, including a negative one. I would rather
spend the window on the question you want answered than guess at it.

Alvin Lim

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

[Mario Limonciello]

< snip >

> So: tell me which test would actually be useful and I will run it and
> report the result either way, including a negative one. I would rather
> spend the window on the question you want answered than guess at it.
> 
> Alvin Lim

Two things:

1. lspci -ttvvnn
2. 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\n' "$address" "$old"
done
EOF