[PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Mario Limonciello]

An issue has been reported by a number of people that corruption
was occurring on storage for desktop systems.  It's notably reported
on SATA, but the same issue also appears on NVME.

At a glance it looks like an IOMMU issue as turning off the IOMMU helps
the issue, but it's actually a problem that occurs specifically with any
IOVA addressed >58 bits.

This is because the BIOS on these systems is enabling a feature of the
root port called 'enhanced atomics' which repurposes those upper 5 bits
of address space.  That feature should only be enabled by the BIOS when
the partner device supports it, but it's instead needlessly enabled on a
number of root ports.

As some of these systems probably won't receive BIOS updates and there is
active reports of data corruption root caused to this add a quirk to
disable it on affected models, and also remove the quirk that was
introduced to work around this issue in drivers/ata.

v2:
 *  Added resume fixups for the affected AMD PCIe ports

Mario Limonciello (2):
  x86/PCI: Disable enhanced atomics on some AMD PCIe ports
  Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

 arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/ata/ahci.c   | 18 --------
 2 files changed, 99 insertions(+), 18 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Mario Limonciello]

There have been multiple reports of data corruption that can occur
with 64-bit DMA when the IOMMU is enabled. This occurs due to some
BIOSes enabling enhanced atomic operations on PCIe ports.

When enhanced atomic operations are enabled on PCIe ports for some
models, data corruption occurs when the 32-bit IOVA space is exhausted.
The problem is reported on storage devices, but can affect any device
that uses 64 bit DMA.

Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.

Cc: david.laight.linux@gmail.com
Cc: John Smith <imjohnsmith4000@gmail.com>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Niklas Cassel <cassel@kernel.org>
Cc: Roland Waltersson <roland.waltersson@netinsight.net>
Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
Reported-by: Arthur Husband <artmoty@gmail.com>
Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
Reported-by: Alvin Lim <alvinwylim@gmail.com>
Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2:
 * Apply to suspend/resume as well.
---
 arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index b301c6c8df753..79e4338e4b876 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
 	}
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
+
+/*
+ * Enhanced atomic operations can cause corruption with 64-bit IOVA
+ * on these devices.
+ */
+#define RX_ENH_ATOMIC_EN		BIT(8)
+
+static const u32 nbio_7_7_pcie_smn_addrs[] = {
+	0x111401d0,
+	0x111411d0,
+	0x111421d0,
+	0x111431d0,
+	0x111441d0,
+	0x112401d0,
+	0x112411d0,
+	0x112421d0,
+	0x112431d0,
+	0x112441d0,
+	0x112451d0,
+	0x113401d0,
+	0x114401d0,
+};
+
+static const u32 nbio_7_11_pcie_smn_addrs[] = {
+	0x112401d0,
+	0x112411d0,
+	0x112421d0,
+	0x112431d0,
+	0x112441d0,
+	0x112451d0,
+	0x113401d0,
+	0x113411d0,
+	0x113421d0,
+	0x113431d0,
+	0x113441d0,
+	0x113451d0,
+};
+
+static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
+					   const u32 *smn_addrs,
+					   size_t nr_smn_addrs)
+{
+	bool changed = false;
+	size_t i;
+	u32 data;
+	int ret;
+
+	for (i = 0; i < nr_smn_addrs; i++) {
+		ret = amd_smn_read(0, smn_addrs[i], &data);
+		if (ret)
+			continue;
+		if (!(data & RX_ENH_ATOMIC_EN))
+			continue;
+		data = data & ~RX_ENH_ATOMIC_EN;
+		ret = amd_smn_write(0, smn_addrs[i], data);
+		if (ret)
+			continue;
+		if (changed)
+			continue;
+		ret = amd_smn_read(0, smn_addrs[i], &data);
+		if (ret)
+			continue;
+		if (data & RX_ENH_ATOMIC_EN)
+			continue;
+		changed = true;
+	}
+
+	if (changed)
+		pci_info(host_bridge, "enhanced atomics disabled\n");
+}
+
+static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
+{
+	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
+				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
+}
+
+static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
+{
+	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
+				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
+}
+
+/* Phoenix, Hawk Point (NBIO 7.7) */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
+			quirk_amd_nbio_7_7_disable_enhanced_atomic);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
+			quirk_amd_nbio_7_7_disable_enhanced_atomic);
+
+/* Strix, Krackan, Strix Halo (NBIO 7.11) */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
+			quirk_amd_nbio_7_11_disable_enhanced_atomic);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
+			quirk_amd_nbio_7_11_disable_enhanced_atomic);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
+			quirk_amd_nbio_7_11_disable_enhanced_atomic);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
+			quirk_amd_nbio_7_11_disable_enhanced_atomic);
+
 #endif
 
 /*
-- 
2.43.0

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Mario Limonciello]

On 9/8/26 14:05, Mario Limonciello wrote:
> There have been multiple reports of data corruption that can occur
> with 64-bit DMA when the IOMMU is enabled. This occurs due to some
> BIOSes enabling enhanced atomic operations on PCIe ports.
> 
> When enhanced atomic operations are enabled on PCIe ports for some
> models, data corruption occurs when the 32-bit IOVA space is exhausted.
> The problem is reported on storage devices, but can affect any device
> that uses 64 bit DMA.
> 
> Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
> 
> Cc: david.laight.linux@gmail.com
> Cc: John Smith <imjohnsmith4000@gmail.com>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Niklas Cassel <cassel@kernel.org>
> Cc: Roland Waltersson <roland.waltersson@netinsight.net>
> Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
> Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
> Reported-by: Arthur Husband <artmoty@gmail.com>
> Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
> Reported-by: Alvin Lim <alvinwylim@gmail.com>
> Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---

There was a contingent of eager responders on the original issue added 
to CC.

Those of you on CC - any progress with testing this?  Does it help you?

Internal AMD team did come up with a reproducer workload that we have 
confirmed it helps.

> v2:
>   * Apply to suspend/resume as well.
> ---
>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 99 insertions(+)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index b301c6c8df753..79e4338e4b876 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
>   	}
>   }
>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
> +
> +/*
> + * Enhanced atomic operations can cause corruption with 64-bit IOVA
> + * on these devices.
> + */
> +#define RX_ENH_ATOMIC_EN		BIT(8)
> +
> +static const u32 nbio_7_7_pcie_smn_addrs[] = {
> +	0x111401d0,
> +	0x111411d0,
> +	0x111421d0,
> +	0x111431d0,
> +	0x111441d0,
> +	0x112401d0,
> +	0x112411d0,
> +	0x112421d0,
> +	0x112431d0,
> +	0x112441d0,
> +	0x112451d0,
> +	0x113401d0,
> +	0x114401d0,
> +};
> +
> +static const u32 nbio_7_11_pcie_smn_addrs[] = {
> +	0x112401d0,
> +	0x112411d0,
> +	0x112421d0,
> +	0x112431d0,
> +	0x112441d0,
> +	0x112451d0,
> +	0x113401d0,
> +	0x113411d0,
> +	0x113421d0,
> +	0x113431d0,
> +	0x113441d0,
> +	0x113451d0,
> +};
> +
> +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
> +					   const u32 *smn_addrs,
> +					   size_t nr_smn_addrs)
> +{
> +	bool changed = false;
> +	size_t i;
> +	u32 data;
> +	int ret;
> +
> +	for (i = 0; i < nr_smn_addrs; i++) {
> +		ret = amd_smn_read(0, smn_addrs[i], &data);
> +		if (ret)
> +			continue;
> +		if (!(data & RX_ENH_ATOMIC_EN))
> +			continue;
> +		data = data & ~RX_ENH_ATOMIC_EN;
> +		ret = amd_smn_write(0, smn_addrs[i], data);
> +		if (ret)
> +			continue;
> +		if (changed)
> +			continue;
> +		ret = amd_smn_read(0, smn_addrs[i], &data);
> +		if (ret)
> +			continue;
> +		if (data & RX_ENH_ATOMIC_EN)
> +			continue;
> +		changed = true;
> +	}
> +
> +	if (changed)
> +		pci_info(host_bridge, "enhanced atomics disabled\n");
> +}
> +
> +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
> +{
> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
> +				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
> +}
> +
> +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
> +{
> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
> +				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
> +}
> +
> +/* Phoenix, Hawk Point (NBIO 7.7) */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> +
> +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +
>   #endif
>   
>   /*

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Mario Limonciello]

On 9/14/26 11:57, Mario Limonciello wrote:
> 
> 
> On 9/8/26 14:05, Mario Limonciello wrote:
>> There have been multiple reports of data corruption that can occur
>> with 64-bit DMA when the IOMMU is enabled. This occurs due to some
>> BIOSes enabling enhanced atomic operations on PCIe ports.
>>
>> When enhanced atomic operations are enabled on PCIe ports for some
>> models, data corruption occurs when the 32-bit IOVA space is exhausted.
>> The problem is reported on storage devices, but can affect any device
>> that uses 64 bit DMA.
>>
>> Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
>>
>> Cc: david.laight.linux@gmail.com
>> Cc: John Smith <imjohnsmith4000@gmail.com>
>> Cc: Lennert Buytenhek <kernel@wantstofly.org>
>> Cc: Niklas Cassel <cassel@kernel.org>
>> Cc: Roland Waltersson <roland.waltersson@netinsight.net>
>> Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
>> Closes: https://lore.kernel.org/ 
>> all/178789300872.392066.15963676631650361573@gmail.com/
>> Reported-by: Arthur Husband <artmoty@gmail.com>
>> Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1- 
>> artmoty@gmail.com/
>> Reported-by: Alvin Lim <alvinwylim@gmail.com>
>> Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1- 
>> alvinwylim@gmail.com/
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
> 
> There was a contingent of eager responders on the original issue added 
> to CC.
> 
> Those of you on CC - any progress with testing this?  Does it help you?
> 
> Internal AMD team did come up with a reproducer workload that we have 
> confirmed it helps.
> 
>> v2:
>>   * Apply to suspend/resume as well.
>> ---
>>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 99 insertions(+)
>>
>> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
>> index b301c6c8df753..79e4338e4b876 100644
>> --- a/arch/x86/pci/fixup.c
>> +++ b/arch/x86/pci/fixup.c
>> @@ -886,6 +886,105 @@ static void 
>> quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
>>       }
>>   }
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, 
>> quirk_clear_strap_no_soft_reset_dev2_f0);
>> +
>> +/*
>> + * Enhanced atomic operations can cause corruption with 64-bit IOVA
>> + * on these devices.
>> + */
>> +#define RX_ENH_ATOMIC_EN        BIT(8)
>> +
>> +static const u32 nbio_7_7_pcie_smn_addrs[] = {
>> +    0x111401d0,
>> +    0x111411d0,
>> +    0x111421d0,
>> +    0x111431d0,
>> +    0x111441d0,
>> +    0x112401d0,
>> +    0x112411d0,
>> +    0x112421d0,
>> +    0x112431d0,
>> +    0x112441d0,
>> +    0x112451d0,
>> +    0x113401d0,
>> +    0x114401d0,
>> +};
>> +
>> +static const u32 nbio_7_11_pcie_smn_addrs[] = {
>> +    0x112401d0,
>> +    0x112411d0,
>> +    0x112421d0,
>> +    0x112431d0,
>> +    0x112441d0,
>> +    0x112451d0,
>> +    0x113401d0,
>> +    0x113411d0,
>> +    0x113421d0,
>> +    0x113431d0,
>> +    0x113441d0,
>> +    0x113451d0,
>> +};
>> +
>> +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
>> +                       const u32 *smn_addrs,
>> +                       size_t nr_smn_addrs)
>> +{
>> +    bool changed = false;
>> +    size_t i;
>> +    u32 data;
>> +    int ret;
>> +
>> +    for (i = 0; i < nr_smn_addrs; i++) {
>> +        ret = amd_smn_read(0, smn_addrs[i], &data);
>> +        if (ret)
>> +            continue;
>> +        if (!(data & RX_ENH_ATOMIC_EN))
>> +            continue;
>> +        data = data & ~RX_ENH_ATOMIC_EN;
>> +        ret = amd_smn_write(0, smn_addrs[i], data);
>> +        if (ret)
>> +            continue;
>> +        if (changed)
>> +            continue;
>> +        ret = amd_smn_read(0, smn_addrs[i], &data);
>> +        if (ret)
>> +            continue;
>> +        if (data & RX_ENH_ATOMIC_EN)
>> +            continue;
>> +        changed = true;
>> +    }
>> +
>> +    if (changed)
>> +        pci_info(host_bridge, "enhanced atomics disabled\n");
>> +}
>> +
>> +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev 
>> *dev)
>> +{
>> +    quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
>> +                       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
>> +}
>> +
>> +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct 
>> pci_dev *dev)
>> +{
>> +    quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
>> +                       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
>> +}
>> +
>> +/* Phoenix, Hawk Point (NBIO 7.7) */
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
>> +            quirk_amd_nbio_7_7_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
>> +            quirk_amd_nbio_7_7_disable_enhanced_atomic);
>> +
>> +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
>> +            quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
>> +            quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
>> +            quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
>> +            quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +
>>   #endif
>>   /*
> 

Bjorn,

Ping on this patch.  There are active reports of data loss from this 
BIOS bug, so I would like to get the W/A merged soon if we can.

We have an A-b from Niklas on 2/2.

Thanks,

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Bjorn Helgaas]

On Tue, Sep 08, 2026 at 02:05:59PM -0500, Mario Limonciello wrote:
> There have been multiple reports of data corruption that can occur
> with 64-bit DMA when the IOMMU is enabled. This occurs due to some
> BIOSes enabling enhanced atomic operations on PCIe ports.
> 
> When enhanced atomic operations are enabled on PCIe ports for some
> models, data corruption occurs when the 32-bit IOVA space is exhausted.
> The problem is reported on storage devices, but can affect any device
> that uses 64 bit DMA.
> 
> Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.

Can this issue happen without IOMMU?  Devices can do 64-bit DMA even
without an IOMMU being enabled.

When I asked Gemini to explain this, it suggested that "enhanced
atomics" is an AMD NBIO feature that translates PCIe AtomicOps into
native Infinity Fabric atomic transactions.  But I guess the issue
affects any DMA above 4GB, not just AtomicOps, right?

> Cc: david.laight.linux@gmail.com
> Cc: John Smith <imjohnsmith4000@gmail.com>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Niklas Cassel <cassel@kernel.org>
> Cc: Roland Waltersson <roland.waltersson@netinsight.net>
> Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
> Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
> Reported-by: Arthur Husband <artmoty@gmail.com>
> Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
> Reported-by: Alvin Lim <alvinwylim@gmail.com>
> Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> v2:
>  * Apply to suspend/resume as well.
> ---
>  arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 99 insertions(+)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index b301c6c8df753..79e4338e4b876 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
>  	}
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
> +
> +/*
> + * Enhanced atomic operations can cause corruption with 64-bit IOVA
> + * on these devices.
> + */
> +#define RX_ENH_ATOMIC_EN		BIT(8)
> +
> +static const u32 nbio_7_7_pcie_smn_addrs[] = {
> +	0x111401d0,
> +	0x111411d0,
> +	0x111421d0,
> +	0x111431d0,
> +	0x111441d0,
> +	0x112401d0,
> +	0x112411d0,
> +	0x112421d0,
> +	0x112431d0,
> +	0x112441d0,
> +	0x112451d0,
> +	0x113401d0,
> +	0x114401d0,
> +};
> +
> +static const u32 nbio_7_11_pcie_smn_addrs[] = {
> +	0x112401d0,
> +	0x112411d0,
> +	0x112421d0,
> +	0x112431d0,
> +	0x112441d0,
> +	0x112451d0,
> +	0x113401d0,
> +	0x113411d0,
> +	0x113421d0,
> +	0x113431d0,
> +	0x113441d0,
> +	0x113451d0,
> +};
> +
> +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
> +					   const u32 *smn_addrs,
> +					   size_t nr_smn_addrs)
> +{
> +	bool changed = false;
> +	size_t i;
> +	u32 data;
> +	int ret;
> +
> +	for (i = 0; i < nr_smn_addrs; i++) {
> +		ret = amd_smn_read(0, smn_addrs[i], &data);
> +		if (ret)
> +			continue;
> +		if (!(data & RX_ENH_ATOMIC_EN))
> +			continue;
> +		data = data & ~RX_ENH_ATOMIC_EN;
> +		ret = amd_smn_write(0, smn_addrs[i], data);
> +		if (ret)
> +			continue;
> +		if (changed)
> +			continue;
> +		ret = amd_smn_read(0, smn_addrs[i], &data);
> +		if (ret)
> +			continue;
> +		if (data & RX_ENH_ATOMIC_EN)
> +			continue;
> +		changed = true;
> +	}
> +
> +	if (changed)
> +		pci_info(host_bridge, "enhanced atomics disabled\n");
> +}
> +
> +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
> +{
> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
> +				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
> +}
> +
> +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
> +{
> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
> +				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
> +}
> +
> +/* Phoenix, Hawk Point (NBIO 7.7) */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> +
> +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> +
>  #endif
>  
>  /*
> -- 
> 2.43.0
> 

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Mario Limonciello]

On 9/23/26 12:12, Bjorn Helgaas wrote:
> On Tue, Sep 08, 2026 at 02:05:59PM -0500, Mario Limonciello wrote:
>> There have been multiple reports of data corruption that can occur
>> with 64-bit DMA when the IOMMU is enabled. This occurs due to some
>> BIOSes enabling enhanced atomic operations on PCIe ports.
>>
>> When enhanced atomic operations are enabled on PCIe ports for some
>> models, data corruption occurs when the 32-bit IOVA space is exhausted.
>> The problem is reported on storage devices, but can affect any device
>> that uses 64 bit DMA.
>>
>> Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
> 
> Can this issue happen without IOMMU?  Devices can do 64-bit DMA even
> without an IOMMU being enabled.

Yes; it can technically happen without IOMMU enabled as well.

The issue happens in NBIO /before/ IOMMU decodes it.

> 
> When I asked Gemini to explain this, it suggested that "enhanced
> atomics" is an AMD NBIO feature that translates PCIe AtomicOps into
> native Infinity Fabric atomic transactions.  But I guess the issue
> affects any DMA above 4GB, not just AtomicOps, right?

That explanation isn't 100% correct.  Yes; it is an NBIO feature, but 
the issue is related with how some devices interact with the upper bits 
of MWr64 TLPs.

This feature should not be enabled on any ports on these SoCs being quirked.

> 
>> Cc: david.laight.linux@gmail.com
>> Cc: John Smith <imjohnsmith4000@gmail.com>
>> Cc: Lennert Buytenhek <kernel@wantstofly.org>
>> Cc: Niklas Cassel <cassel@kernel.org>
>> Cc: Roland Waltersson <roland.waltersson@netinsight.net>
>> Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
>> Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
>> Reported-by: Arthur Husband <artmoty@gmail.com>
>> Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
>> Reported-by: Alvin Lim <alvinwylim@gmail.com>
>> Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> v2:
>>   * Apply to suspend/resume as well.
>> ---
>>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 99 insertions(+)
>>
>> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
>> index b301c6c8df753..79e4338e4b876 100644
>> --- a/arch/x86/pci/fixup.c
>> +++ b/arch/x86/pci/fixup.c
>> @@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
>>   	}
>>   }
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
>> +
>> +/*
>> + * Enhanced atomic operations can cause corruption with 64-bit IOVA
>> + * on these devices.
>> + */
>> +#define RX_ENH_ATOMIC_EN		BIT(8)
>> +
>> +static const u32 nbio_7_7_pcie_smn_addrs[] = {
>> +	0x111401d0,
>> +	0x111411d0,
>> +	0x111421d0,
>> +	0x111431d0,
>> +	0x111441d0,
>> +	0x112401d0,
>> +	0x112411d0,
>> +	0x112421d0,
>> +	0x112431d0,
>> +	0x112441d0,
>> +	0x112451d0,
>> +	0x113401d0,
>> +	0x114401d0,
>> +};
>> +
>> +static const u32 nbio_7_11_pcie_smn_addrs[] = {
>> +	0x112401d0,
>> +	0x112411d0,
>> +	0x112421d0,
>> +	0x112431d0,
>> +	0x112441d0,
>> +	0x112451d0,
>> +	0x113401d0,
>> +	0x113411d0,
>> +	0x113421d0,
>> +	0x113431d0,
>> +	0x113441d0,
>> +	0x113451d0,
>> +};
>> +
>> +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
>> +					   const u32 *smn_addrs,
>> +					   size_t nr_smn_addrs)
>> +{
>> +	bool changed = false;
>> +	size_t i;
>> +	u32 data;
>> +	int ret;
>> +
>> +	for (i = 0; i < nr_smn_addrs; i++) {
>> +		ret = amd_smn_read(0, smn_addrs[i], &data);
>> +		if (ret)
>> +			continue;
>> +		if (!(data & RX_ENH_ATOMIC_EN))
>> +			continue;
>> +		data = data & ~RX_ENH_ATOMIC_EN;
>> +		ret = amd_smn_write(0, smn_addrs[i], data);
>> +		if (ret)
>> +			continue;
>> +		if (changed)
>> +			continue;
>> +		ret = amd_smn_read(0, smn_addrs[i], &data);
>> +		if (ret)
>> +			continue;
>> +		if (data & RX_ENH_ATOMIC_EN)
>> +			continue;
>> +		changed = true;
>> +	}
>> +
>> +	if (changed)
>> +		pci_info(host_bridge, "enhanced atomics disabled\n");
>> +}
>> +
>> +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
>> +{
>> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
>> +				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
>> +}
>> +
>> +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
>> +{
>> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
>> +				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
>> +}
>> +
>> +/* Phoenix, Hawk Point (NBIO 7.7) */
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
>> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
>> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
>> +
>> +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>> +
>>   #endif
>>   
>>   /*
>> -- 
>> 2.43.0
>>

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Bjorn Helgaas]

On Wed, Sep 23, 2026 at 12:30:59PM -0500, Mario Limonciello wrote:
> On 9/23/26 12:12, Bjorn Helgaas wrote:
> > On Tue, Sep 08, 2026 at 02:05:59PM -0500, Mario Limonciello wrote:
> > > There have been multiple reports of data corruption that can occur
> > > with 64-bit DMA when the IOMMU is enabled. This occurs due to some
> > > BIOSes enabling enhanced atomic operations on PCIe ports.
> > > 
> > > When enhanced atomic operations are enabled on PCIe ports for some
> > > models, data corruption occurs when the 32-bit IOVA space is exhausted.
> > > The problem is reported on storage devices, but can affect any device
> > > that uses 64 bit DMA.
> > > 
> > > Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
> > 
> > Can this issue happen without IOMMU?  Devices can do 64-bit DMA even
> > without an IOMMU being enabled.
> 
> Yes; it can technically happen without IOMMU enabled as well.
> 
> The issue happens in NBIO /before/ IOMMU decodes it.
> 
> > When I asked Gemini to explain this, it suggested that "enhanced
> > atomics" is an AMD NBIO feature that translates PCIe AtomicOps into
> > native Infinity Fabric atomic transactions.  But I guess the issue
> > affects any DMA above 4GB, not just AtomicOps, right?
> 
> That explanation isn't 100% correct.  Yes; it is an NBIO feature, but the
> issue is related with how some devices interact with the upper bits of MWr64
> TLPs.
> 
> This feature should not be enabled on any ports on these SoCs being quirked.

What do you think of the log below?  Since it can happen without
IOMMU, I think it's better to omit it so people don't think disabling
the IOMMU is a workaround.

  x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11

  Multiple users report data corruption during 64-bit DMA transfers on
  systems with AMD NBIO 7.7 and 7.11 controllers.

  This occurs when BIOS enables AMD "enhanced atomic operations" on PCIe Root
  Ports. When enhanced atomics are enabled, any 64-bit DMA access may be
  corrupted.

  Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.


> > > Cc: david.laight.linux@gmail.com
> > > Cc: John Smith <imjohnsmith4000@gmail.com>
> > > Cc: Lennert Buytenhek <kernel@wantstofly.org>
> > > Cc: Niklas Cassel <cassel@kernel.org>
> > > Cc: Roland Waltersson <roland.waltersson@netinsight.net>
> > > Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
> > > Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
> > > Reported-by: Arthur Husband <artmoty@gmail.com>
> > > Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
> > > Reported-by: Alvin Lim <alvinwylim@gmail.com>
> > > Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > > ---
> > > v2:
> > >   * Apply to suspend/resume as well.
> > > ---
> > >   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
> > >   1 file changed, 99 insertions(+)
> > > 
> > > diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> > > index b301c6c8df753..79e4338e4b876 100644
> > > --- a/arch/x86/pci/fixup.c
> > > +++ b/arch/x86/pci/fixup.c
> > > @@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
> > >   	}
> > >   }
> > >   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
> > > +
> > > +/*
> > > + * Enhanced atomic operations can cause corruption with 64-bit IOVA
> > > + * on these devices.
> > > + */
> > > +#define RX_ENH_ATOMIC_EN		BIT(8)
> > > +
> > > +static const u32 nbio_7_7_pcie_smn_addrs[] = {
> > > +	0x111401d0,
> > > +	0x111411d0,
> > > +	0x111421d0,
> > > +	0x111431d0,
> > > +	0x111441d0,
> > > +	0x112401d0,
> > > +	0x112411d0,
> > > +	0x112421d0,
> > > +	0x112431d0,
> > > +	0x112441d0,
> > > +	0x112451d0,
> > > +	0x113401d0,
> > > +	0x114401d0,
> > > +};
> > > +
> > > +static const u32 nbio_7_11_pcie_smn_addrs[] = {
> > > +	0x112401d0,
> > > +	0x112411d0,
> > > +	0x112421d0,
> > > +	0x112431d0,
> > > +	0x112441d0,
> > > +	0x112451d0,
> > > +	0x113401d0,
> > > +	0x113411d0,
> > > +	0x113421d0,
> > > +	0x113431d0,
> > > +	0x113441d0,
> > > +	0x113451d0,
> > > +};
> > > +
> > > +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
> > > +					   const u32 *smn_addrs,
> > > +					   size_t nr_smn_addrs)
> > > +{
> > > +	bool changed = false;
> > > +	size_t i;
> > > +	u32 data;
> > > +	int ret;
> > > +
> > > +	for (i = 0; i < nr_smn_addrs; i++) {
> > > +		ret = amd_smn_read(0, smn_addrs[i], &data);
> > > +		if (ret)
> > > +			continue;
> > > +		if (!(data & RX_ENH_ATOMIC_EN))
> > > +			continue;
> > > +		data = data & ~RX_ENH_ATOMIC_EN;
> > > +		ret = amd_smn_write(0, smn_addrs[i], data);
> > > +		if (ret)
> > > +			continue;
> > > +		if (changed)
> > > +			continue;
> > > +		ret = amd_smn_read(0, smn_addrs[i], &data);
> > > +		if (ret)
> > > +			continue;
> > > +		if (data & RX_ENH_ATOMIC_EN)
> > > +			continue;
> > > +		changed = true;
> > > +	}
> > > +
> > > +	if (changed)
> > > +		pci_info(host_bridge, "enhanced atomics disabled\n");
> > > +}
> > > +
> > > +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
> > > +{
> > > +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
> > > +				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
> > > +}
> > > +
> > > +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
> > > +{
> > > +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
> > > +				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
> > > +}
> > > +
> > > +/* Phoenix, Hawk Point (NBIO 7.7) */
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
> > > +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
> > > +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
> > > +
> > > +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
> > > +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
> > > +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
> > > +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
> > > +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
> > > +
> > >   #endif
> > >   /*
> > > -- 
> > > 2.43.0
> > > 
> 

Re: [PATCH v2 1/2] x86/PCI: Disable enhanced atomics on some AMD PCIe ports

[Mario Limonciello]

On 9/23/26 13:05, Bjorn Helgaas wrote:
> On Wed, Sep 23, 2026 at 12:30:59PM -0500, Mario Limonciello wrote:
>> On 9/23/26 12:12, Bjorn Helgaas wrote:
>>> On Tue, Sep 08, 2026 at 02:05:59PM -0500, Mario Limonciello wrote:
>>>> There have been multiple reports of data corruption that can occur
>>>> with 64-bit DMA when the IOMMU is enabled. This occurs due to some
>>>> BIOSes enabling enhanced atomic operations on PCIe ports.
>>>>
>>>> When enhanced atomic operations are enabled on PCIe ports for some
>>>> models, data corruption occurs when the 32-bit IOVA space is exhausted.
>>>> The problem is reported on storage devices, but can affect any device
>>>> that uses 64 bit DMA.
>>>>
>>>> Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
>>>
>>> Can this issue happen without IOMMU?  Devices can do 64-bit DMA even
>>> without an IOMMU being enabled.
>>
>> Yes; it can technically happen without IOMMU enabled as well.
>>
>> The issue happens in NBIO /before/ IOMMU decodes it.
>>
>>> When I asked Gemini to explain this, it suggested that "enhanced
>>> atomics" is an AMD NBIO feature that translates PCIe AtomicOps into
>>> native Infinity Fabric atomic transactions.  But I guess the issue
>>> affects any DMA above 4GB, not just AtomicOps, right?
>>
>> That explanation isn't 100% correct.  Yes; it is an NBIO feature, but the
>> issue is related with how some devices interact with the upper bits of MWr64
>> TLPs.
>>
>> This feature should not be enabled on any ports on these SoCs being quirked.
> 
> What do you think of the log below?  Since it can happen without
> IOMMU, I think it's better to omit it so people don't think disabling
> the IOMMU is a workaround.
> 
>    x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11
> 
>    Multiple users report data corruption during 64-bit DMA transfers on
>    systems with AMD NBIO 7.7 and 7.11 controllers.
> 
>    This occurs when BIOS enables AMD "enhanced atomic operations" on PCIe Root
>    Ports. When enhanced atomics are enabled, any 64-bit DMA access may be
>    corrupted.
> 
>    Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models.
> 

That's great, thanks.

> 
>>>> Cc: david.laight.linux@gmail.com
>>>> Cc: John Smith <imjohnsmith4000@gmail.com>
>>>> Cc: Lennert Buytenhek <kernel@wantstofly.org>
>>>> Cc: Niklas Cassel <cassel@kernel.org>
>>>> Cc: Roland Waltersson <roland.waltersson@netinsight.net>
>>>> Reported-by: Mikael Etienne <mikael1022bzh@gmail.com>
>>>> Closes: https://lore.kernel.org/all/178789300872.392066.15963676631650361573@gmail.com/
>>>> Reported-by: Arthur Husband <artmoty@gmail.com>
>>>> Closes: https://lore.kernel.org/linux-ide/20260406222335.379935-1-artmoty@gmail.com/
>>>> Reported-by: Alvin Lim <alvinwylim@gmail.com>
>>>> Closes: https://lore.kernel.org/linux-ide/20260621100844.1224301-1-alvinwylim@gmail.com/
>>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>>>> ---
>>>> v2:
>>>>    * Apply to suspend/resume as well.
>>>> ---
>>>>    arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 99 insertions(+)
>>>>
>>>> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
>>>> index b301c6c8df753..79e4338e4b876 100644
>>>> --- a/arch/x86/pci/fixup.c
>>>> +++ b/arch/x86/pci/fixup.c
>>>> @@ -886,6 +886,105 @@ static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
>>>>    	}
>>>>    }
>>>>    DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
>>>> +
>>>> +/*
>>>> + * Enhanced atomic operations can cause corruption with 64-bit IOVA
>>>> + * on these devices.
>>>> + */
>>>> +#define RX_ENH_ATOMIC_EN		BIT(8)
>>>> +
>>>> +static const u32 nbio_7_7_pcie_smn_addrs[] = {
>>>> +	0x111401d0,
>>>> +	0x111411d0,
>>>> +	0x111421d0,
>>>> +	0x111431d0,
>>>> +	0x111441d0,
>>>> +	0x112401d0,
>>>> +	0x112411d0,
>>>> +	0x112421d0,
>>>> +	0x112431d0,
>>>> +	0x112441d0,
>>>> +	0x112451d0,
>>>> +	0x113401d0,
>>>> +	0x114401d0,
>>>> +};
>>>> +
>>>> +static const u32 nbio_7_11_pcie_smn_addrs[] = {
>>>> +	0x112401d0,
>>>> +	0x112411d0,
>>>> +	0x112421d0,
>>>> +	0x112431d0,
>>>> +	0x112441d0,
>>>> +	0x112451d0,
>>>> +	0x113401d0,
>>>> +	0x113411d0,
>>>> +	0x113421d0,
>>>> +	0x113431d0,
>>>> +	0x113441d0,
>>>> +	0x113451d0,
>>>> +};
>>>> +
>>>> +static void quirk_amd_nbio_enhanced_atomic(struct pci_dev *host_bridge,
>>>> +					   const u32 *smn_addrs,
>>>> +					   size_t nr_smn_addrs)
>>>> +{
>>>> +	bool changed = false;
>>>> +	size_t i;
>>>> +	u32 data;
>>>> +	int ret;
>>>> +
>>>> +	for (i = 0; i < nr_smn_addrs; i++) {
>>>> +		ret = amd_smn_read(0, smn_addrs[i], &data);
>>>> +		if (ret)
>>>> +			continue;
>>>> +		if (!(data & RX_ENH_ATOMIC_EN))
>>>> +			continue;
>>>> +		data = data & ~RX_ENH_ATOMIC_EN;
>>>> +		ret = amd_smn_write(0, smn_addrs[i], data);
>>>> +		if (ret)
>>>> +			continue;
>>>> +		if (changed)
>>>> +			continue;
>>>> +		ret = amd_smn_read(0, smn_addrs[i], &data);
>>>> +		if (ret)
>>>> +			continue;
>>>> +		if (data & RX_ENH_ATOMIC_EN)
>>>> +			continue;
>>>> +		changed = true;
>>>> +	}
>>>> +
>>>> +	if (changed)
>>>> +		pci_info(host_bridge, "enhanced atomics disabled\n");
>>>> +}
>>>> +
>>>> +static void quirk_amd_nbio_7_7_disable_enhanced_atomic(struct pci_dev *dev)
>>>> +{
>>>> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_7_pcie_smn_addrs,
>>>> +				       ARRAY_SIZE(nbio_7_7_pcie_smn_addrs));
>>>> +}
>>>> +
>>>> +static void quirk_amd_nbio_7_11_disable_enhanced_atomic(struct pci_dev *dev)
>>>> +{
>>>> +	quirk_amd_nbio_enhanced_atomic(dev, nbio_7_11_pcie_smn_addrs,
>>>> +				       ARRAY_SIZE(nbio_7_11_pcie_smn_addrs));
>>>> +}
>>>> +
>>>> +/* Phoenix, Hawk Point (NBIO 7.7) */
>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14E8,
>>>> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
>>>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14E8,
>>>> +			quirk_amd_nbio_7_7_disable_enhanced_atomic);
>>>> +
>>>> +/* Strix, Krackan, Strix Halo (NBIO 7.11) */
>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1507,
>>>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>>>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1507,
>>>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1122,
>>>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>>>> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1122,
>>>> +			quirk_amd_nbio_7_11_disable_enhanced_atomic);
>>>> +
>>>>    #endif
>>>>    /*
>>>> -- 
>>>> 2.43.0
>>>>
>>

[PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Mario Limonciello]

This reverts commit 105c42566a550e2d05fc14f763216a8765ee5d0e.

The issue is actually a problem with BIOS configuaration of PCIe
root ports, enabling a feature that causes problems with 64-bit
DMA.  It is fixed by adjusting the kernel adjusting the
configuration of those root ports.

Cc: Arthur Husband <artmoty@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/ata/ahci.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9b8c0935001cb..bffe50a109b88 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -68,7 +68,6 @@ enum board_ids {
 	/* board IDs for specific chipsets in alphabetical order */
 	board_ahci_al,
 	board_ahci_avn,
-	board_ahci_jmb585,
 	board_ahci_mcp65,
 	board_ahci_mcp77,
 	board_ahci_mcp89,
@@ -213,15 +212,6 @@ static const struct ata_port_info ahci_port_info[] = {
 		.udma_mask	= ATA_UDMA6,
 		.port_ops	= &ahci_avn_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_mcp65] = {
 		AHCI_HFLAGS	(AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
 				 AHCI_HFLAG_YES_NCQ),
@@ -954,14 +944,6 @@ static const struct pci_device_id ahci_pci_tbl[] = {
 		/* Elkhart Lake AHCI */
 		PCI_VDEVICE(INTEL, 0x4b63),
 		.driver_data = board_ahci_pcs_quirk,
-	}, {
-		/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
-		PCI_VDEVICE(JMICRON, 0x0582),
-		.driver_data = board_ahci_jmb585,
-
-	}, {
-		PCI_VDEVICE(JMICRON, 0x0585),
-		.driver_data = board_ahci_jmb585,
 	}, {
 		/* JMicron 360/1/3/5/6, match class to avoid IDE function */
 		PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID),
-- 
2.43.0

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Niklas Cassel]

On Tue, Sep 08, 2026 at 02:06:00PM -0500, Mario Limonciello wrote:
> This reverts commit 105c42566a550e2d05fc14f763216a8765ee5d0e.
> 
> The issue is actually a problem with BIOS configuaration of PCIe
> root ports, enabling a feature that causes problems with 64-bit
> DMA.  It is fixed by adjusting the kernel adjusting the
> configuration of those root ports.
> 
> Cc: Arthur Husband <artmoty@gmail.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

Acked-by: Niklas Cassel <cassel@kernel.org>

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Bjorn Helgaas]

[+cc Roland, snoep]

On Tue, Sep 08, 2026 at 02:06:00PM -0500, Mario Limonciello wrote:
> This reverts commit 105c42566a550e2d05fc14f763216a8765ee5d0e.
> 
> The issue is actually a problem with BIOS configuaration of PCIe
> root ports, enabling a feature that causes problems with 64-bit
> DMA.  It is fixed by adjusting the kernel adjusting the
> configuration of those root ports.

I'm a little concerned about doing this revert for v7.3:

  - The AMD issue should affect any SATA controller, but 105c42566a55
    ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") is very
    specific about JMicron JMB582/JMB585.

  - The BIOS configuration change only affects AMD NBIO 7.7 and 7.11
    but the original posting [1] of 105c42566a55 ("ata: ahci: force
    32-bit DMA for JMicron JMB582/JMB585") mentions Raspberry Pi,
    which isn't AMD (the Raspberry Pi mention was removed before
    105c42566a55 was merged).

  - There are reports of problems on Raspberry Pi 5 JMB585 [2], [3]
    that don't seem completely resolved.

  - The revert doesn't seem like it fixes a problem, so I don't know
    that I can justify it as post-rc1 material for v7.3; maybe the ATA
    folks should take it for v7.4?

What if I just merge patch [1/2] ("x86/PCI: Disable enhanced atomics
on AMD NBIO 7.7 and 7.11") for v7.3?  Would that leave anything
broken?

[1] https://lore.kernel.org/all/20260403050225.50186-1-artmoty@gmail.com/t/#u)
[2] https://forum.radxa.com/t/repeated-ext4-metadata-corruption-on-raspberry-pi-5-with-penta-sata-hat-jmb585-despite-healthy-ssds-and-raid1/31393/10
[3] https://forums.raspberrypi.com/viewtopic.php?p=2386959#p2386959

> Cc: Arthur Husband <artmoty@gmail.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>  drivers/ata/ahci.c | 18 ------------------
>  1 file changed, 18 deletions(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 9b8c0935001cb..bffe50a109b88 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -68,7 +68,6 @@ enum board_ids {
>  	/* board IDs for specific chipsets in alphabetical order */
>  	board_ahci_al,
>  	board_ahci_avn,
> -	board_ahci_jmb585,
>  	board_ahci_mcp65,
>  	board_ahci_mcp77,
>  	board_ahci_mcp89,
> @@ -213,15 +212,6 @@ static const struct ata_port_info ahci_port_info[] = {
>  		.udma_mask	= ATA_UDMA6,
>  		.port_ops	= &ahci_avn_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_mcp65] = {
>  		AHCI_HFLAGS	(AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
>  				 AHCI_HFLAG_YES_NCQ),
> @@ -954,14 +944,6 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>  		/* Elkhart Lake AHCI */
>  		PCI_VDEVICE(INTEL, 0x4b63),
>  		.driver_data = board_ahci_pcs_quirk,
> -	}, {
> -		/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
> -		PCI_VDEVICE(JMICRON, 0x0582),
> -		.driver_data = board_ahci_jmb585,
> -
> -	}, {
> -		PCI_VDEVICE(JMICRON, 0x0585),
> -		.driver_data = board_ahci_jmb585,
>  	}, {
>  		/* JMicron 360/1/3/5/6, match class to avoid IDE function */
>  		PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID),
> -- 
> 2.43.0
> 

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Mario Limonciello]

On 9/25/26 14:42, Bjorn Helgaas wrote:
> [+cc Roland, snoep]
> 
> On Tue, Sep 08, 2026 at 02:06:00PM -0500, Mario Limonciello wrote:
>> This reverts commit 105c42566a550e2d05fc14f763216a8765ee5d0e.
>>
>> The issue is actually a problem with BIOS configuaration of PCIe
>> root ports, enabling a feature that causes problems with 64-bit
>> DMA.  It is fixed by adjusting the kernel adjusting the
>> configuration of those root ports.
> 
> I'm a little concerned about doing this revert for v7.3:
> 
>    - The AMD issue should affect any SATA controller, but 105c42566a55
>      ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") is very
>      specific about JMicron JMB582/JMB585.
> 
>    - The BIOS configuration change only affects AMD NBIO 7.7 and 7.11
>      but the original posting [1] of 105c42566a55 ("ata: ahci: force
>      32-bit DMA for JMicron JMB582/JMB585") mentions Raspberry Pi,
>      which isn't AMD (the Raspberry Pi mention was removed before
>      105c42566a55 was merged).
> 
>    - There are reports of problems on Raspberry Pi 5 JMB585 [2], [3]
>      that don't seem completely resolved.
> 
>    - The revert doesn't seem like it fixes a problem, so I don't know
>      that I can justify it as post-rc1 material for v7.3; maybe the ATA
>      folks should take it for v7.4?
> 
> What if I just merge patch [1/2] ("x86/PCI: Disable enhanced atomics
> on AMD NBIO 7.7 and 7.11") for v7.3?  Would that leave anything
> broken?
> 
> [1] https://lore.kernel.org/all/20260403050225.50186-1-artmoty@gmail.com/t/#u)
> [2] https://forum.radxa.com/t/repeated-ext4-metadata-corruption-on-raspberry-pi-5-with-penta-sata-hat-jmb585-despite-healthy-ssds-and-raid1/31393/10
> [3] https://forums.raspberrypi.com/viewtopic.php?p=2386959#p2386959
> 
>> Cc: Arthur Husband <artmoty@gmail.com>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

I think we should let Niklas speak up here because there was 
confirmation on this thread it's an AMD only issue.

https://lore.kernel.org/all/ap6RyP28fxXNjRWS@ryzen/


>> ---
>>   drivers/ata/ahci.c | 18 ------------------
>>   1 file changed, 18 deletions(-)
>>
>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>> index 9b8c0935001cb..bffe50a109b88 100644
>> --- a/drivers/ata/ahci.c
>> +++ b/drivers/ata/ahci.c
>> @@ -68,7 +68,6 @@ enum board_ids {
>>   	/* board IDs for specific chipsets in alphabetical order */
>>   	board_ahci_al,
>>   	board_ahci_avn,
>> -	board_ahci_jmb585,
>>   	board_ahci_mcp65,
>>   	board_ahci_mcp77,
>>   	board_ahci_mcp89,
>> @@ -213,15 +212,6 @@ static const struct ata_port_info ahci_port_info[] = {
>>   		.udma_mask	= ATA_UDMA6,
>>   		.port_ops	= &ahci_avn_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_mcp65] = {
>>   		AHCI_HFLAGS	(AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
>>   				 AHCI_HFLAG_YES_NCQ),
>> @@ -954,14 +944,6 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>>   		/* Elkhart Lake AHCI */
>>   		PCI_VDEVICE(INTEL, 0x4b63),
>>   		.driver_data = board_ahci_pcs_quirk,
>> -	}, {
>> -		/* JMicron JMB582/585: force 32-bit DMA (broken 64-bit implementation) */
>> -		PCI_VDEVICE(JMICRON, 0x0582),
>> -		.driver_data = board_ahci_jmb585,
>> -
>> -	}, {
>> -		PCI_VDEVICE(JMICRON, 0x0585),
>> -		.driver_data = board_ahci_jmb585,
>>   	}, {
>>   		/* JMicron 360/1/3/5/6, match class to avoid IDE function */
>>   		PCI_DEVICE(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID),
>> -- 
>> 2.43.0
>>

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Niklas Cassel]

On Fri, Sep 25, 2026 at 03:01:39PM -0500, Mario Limonciello wrote:
> On 9/25/26 14:42, Bjorn Helgaas wrote:
> > 
> > What if I just merge patch [1/2] ("x86/PCI: Disable enhanced atomics
> > on AMD NBIO 7.7 and 7.11") for v7.3?  Would that leave anything
> > broken?
> > 
> > [1] https://lore.kernel.org/all/20260403050225.50186-1-artmoty@gmail.com/t/#u)
> > [2] https://forum.radxa.com/t/repeated-ext4-metadata-corruption-on-raspberry-pi-5-with-penta-sata-hat-jmb585-despite-healthy-ssds-and-raid1/31393/10
> > [3] https://forums.raspberrypi.com/viewtopic.php?p=2386959#p2386959
> > 
> > > Cc: Arthur Husband <artmoty@gmail.com>
> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> 
> I think we should let Niklas speak up here because there was confirmation on
> this thread it's an AMD only issue.
> 
> https://lore.kernel.org/all/ap6RyP28fxXNjRWS@ryzen/

1) The original reporter mentioned that he had never seen any issues on
   Raspberry Pi, the commit message was AI generated.

2) The problem "repeated-ext4-metadata-corruption" appears to be a problem
   with NCQ on a specific drive. I asked that person for more tests, but
   he did not to once turning off NCQ solved his problem.

3) The quirk actually introduced a bunch of problems on Raspberry Pi,
   because libata did not clear upper 64 bit addresses. This has since
   been fixed in commit 82e47533221d ("ata: libahci: clear PxCLBU and
   PxFBU for AHCI_HFLAG_32BIT_ONLY")

4) People had been using this AHCI controller for years (including on
   Raspberry Pi) without seeing any issues (until the quirk was
   introduced).

5) The people who were complaining about data corruption could be
   identified to all use AMD systems.

6) These people complained that it broke directly for any address > 32 bit.
   For the JMicron (instead of ASMedia), it breaks for any address > 43 bit.
   I have a hard time believing that the controller is so broken that the
   set the 64-bit DMA addresses supported bit in the AHCI CAP register,
   but does not support a single bit more than 32 bit.

7) For all AHCI controllers with these quirks (except for an old ATI
   one), we have gotten an errata from the manufacturer.
   We have never seen any errata for this controller.


All in all, I am 100% confident to revert the patch.
But, I don't care if it goes into 7.3 or 7.4.

Just say the word and I can pick it up for 7.4 instead.


Kind regards,
Niklas

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Bjorn Helgaas]

On Sat, Sep 26, 2026 at 05:02:03PM +0200, Niklas Cassel wrote:
> On Fri, Sep 25, 2026 at 03:01:39PM -0500, Mario Limonciello wrote:
> > On 9/25/26 14:42, Bjorn Helgaas wrote:
> > > 
> > > What if I just merge patch [1/2] ("x86/PCI: Disable enhanced atomics
> > > on AMD NBIO 7.7 and 7.11") for v7.3?  Would that leave anything
> > > broken?
> > > 
> > > [1] https://lore.kernel.org/all/20260403050225.50186-1-artmoty@gmail.com/t/#u)
> > > [2] https://forum.radxa.com/t/repeated-ext4-metadata-corruption-on-raspberry-pi-5-with-penta-sata-hat-jmb585-despite-healthy-ssds-and-raid1/31393/10
> > > [3] https://forums.raspberrypi.com/viewtopic.php?p=2386959#p2386959
> > > 
> > > > Cc: Arthur Husband <artmoty@gmail.com>
> > > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > 
> > I think we should let Niklas speak up here because there was confirmation on
> > this thread it's an AMD only issue.
> > 
> > https://lore.kernel.org/all/ap6RyP28fxXNjRWS@ryzen/
> 
> 1) The original reporter mentioned that he had never seen any issues on
>    Raspberry Pi, the commit message was AI generated.
> 
> 2) The problem "repeated-ext4-metadata-corruption" appears to be a problem
>    with NCQ on a specific drive. I asked that person for more tests, but
>    he did not to once turning off NCQ solved his problem.
> 
> 3) The quirk actually introduced a bunch of problems on Raspberry Pi,
>    because libata did not clear upper 64 bit addresses. This has since
>    been fixed in commit 82e47533221d ("ata: libahci: clear PxCLBU and
>    PxFBU for AHCI_HFLAG_32BIT_ONLY")
> 
> 4) People had been using this AHCI controller for years (including on
>    Raspberry Pi) without seeing any issues (until the quirk was
>    introduced).
> 
> 5) The people who were complaining about data corruption could be
>    identified to all use AMD systems.
> 
> 6) These people complained that it broke directly for any address > 32 bit.
>    For the JMicron (instead of ASMedia), it breaks for any address > 43 bit.
>    I have a hard time believing that the controller is so broken that the
>    set the 64-bit DMA addresses supported bit in the AHCI CAP register,
>    but does not support a single bit more than 32 bit.
> 
> 7) For all AHCI controllers with these quirks (except for an old ATI
>    one), we have gotten an errata from the manufacturer.
>    We have never seen any errata for this controller.
> 
> 
> All in all, I am 100% confident to revert the patch.
> But, I don't care if it goes into 7.3 or 7.4.
> 
> Just say the word and I can pick it up for 7.4 instead.

That all sounds good.  How about if I ask Linus to pull Mario's AMD
SMN fix for v7.3, since that seems to be PCI-related, and then you can
decide how/when to take the quirk revert, since that seems to be
ATA-related?

I'll ask Linus to pull the AMD SMN fix today, so you could still
revert the quirk for v7.3 also if you wanted.  It sounds like there
might be more details that could be included in the quirk revert,
e.g., the fact that the quirk caused issues on Raspberry Pi and the
fact that the problem the quirk address was fixed by commit X.

Re: [PATCH v2 2/2] Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"

[Niklas Cassel]

On Sat, Sep 26, 2026 at 11:26:25AM -0500, Bjorn Helgaas wrote:
> That all sounds good.  How about if I ask Linus to pull Mario's AMD
> SMN fix for v7.3, since that seems to be PCI-related, and then you can
> decide how/when to take the quirk revert, since that seems to be
> ATA-related?

Sounds good, I will queue it for for 7.4 sometime next week.


Kind regards,
Niklas

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Mario Limonciello]

On 9/8/26 2:05 PM, Mario Limonciello wrote:
> An issue has been reported by a number of people that corruption
> was occurring on storage for desktop systems.  It's notably reported
> on SATA, but the same issue also appears on NVME.
> 
> At a glance it looks like an IOMMU issue as turning off the IOMMU helps
> the issue, but it's actually a problem that occurs specifically with any
> IOVA addressed >58 bits.
> 
> This is because the BIOS on these systems is enabling a feature of the
> root port called 'enhanced atomics' which repurposes those upper 5 bits
> of address space.  That feature should only be enabled by the BIOS when
> the partner device supports it, but it's instead needlessly enabled on a
> number of root ports.
> 
> As some of these systems probably won't receive BIOS updates and there is
> active reports of data corruption root caused to this add a quirk to
> disable it on affected models, and also remove the quirk that was
> introduced to work around this issue in drivers/ata.
> 
> v2:
>   *  Added resume fixups for the affected AMD PCIe ports
> 
> Mario Limonciello (2):
>    x86/PCI: Disable enhanced atomics on some AMD PCIe ports
>    Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
> 
>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>   drivers/ata/ahci.c   | 18 --------
>   2 files changed, 99 insertions(+), 18 deletions(-)
> 

Gentle ping on this series.

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Niklas Cassel]

On Sun, Sep 20, 2026 at 11:52:08PM -0500, Mario Limonciello wrote:
> On 9/8/26 2:05 PM, Mario Limonciello wrote:
> > An issue has been reported by a number of people that corruption
> > was occurring on storage for desktop systems.  It's notably reported
> > on SATA, but the same issue also appears on NVME.
> > 
> > At a glance it looks like an IOMMU issue as turning off the IOMMU helps
> > the issue, but it's actually a problem that occurs specifically with any
> > IOVA addressed >58 bits.
> > 
> > This is because the BIOS on these systems is enabling a feature of the
> > root port called 'enhanced atomics' which repurposes those upper 5 bits
> > of address space.  That feature should only be enabled by the BIOS when
> > the partner device supports it, but it's instead needlessly enabled on a
> > number of root ports.
> > 
> > As some of these systems probably won't receive BIOS updates and there is
> > active reports of data corruption root caused to this add a quirk to
> > disable it on affected models, and also remove the quirk that was
> > introduced to work around this issue in drivers/ata.
> > 
> > v2:
> >   *  Added resume fixups for the affected AMD PCIe ports
> > 
> > Mario Limonciello (2):
> >    x86/PCI: Disable enhanced atomics on some AMD PCIe ports
> >    Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
> > 
> >   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
> >   drivers/ata/ahci.c   | 18 --------
> >   2 files changed, 99 insertions(+), 18 deletions(-)
> > 
> 
> Gentle ping on this series.

I can pick up patch 2/2, but want to wait until patch 1/2 has been picked
up either by Bjorn, or one of the x86 maintainers.


Kind regards,
Niklas

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Mario Limonciello]

On 9/22/26 04:49, Niklas Cassel wrote:
> On Sun, Sep 20, 2026 at 11:52:08PM -0500, Mario Limonciello wrote:
>> On 9/8/26 2:05 PM, Mario Limonciello wrote:
>>> An issue has been reported by a number of people that corruption
>>> was occurring on storage for desktop systems.  It's notably reported
>>> on SATA, but the same issue also appears on NVME.
>>>
>>> At a glance it looks like an IOMMU issue as turning off the IOMMU helps
>>> the issue, but it's actually a problem that occurs specifically with any
>>> IOVA addressed >58 bits.
>>>
>>> This is because the BIOS on these systems is enabling a feature of the
>>> root port called 'enhanced atomics' which repurposes those upper 5 bits
>>> of address space.  That feature should only be enabled by the BIOS when
>>> the partner device supports it, but it's instead needlessly enabled on a
>>> number of root ports.
>>>
>>> As some of these systems probably won't receive BIOS updates and there is
>>> active reports of data corruption root caused to this add a quirk to
>>> disable it on affected models, and also remove the quirk that was
>>> introduced to work around this issue in drivers/ata.
>>>
>>> v2:
>>>    *  Added resume fixups for the affected AMD PCIe ports
>>>
>>> Mario Limonciello (2):
>>>     x86/PCI: Disable enhanced atomics on some AMD PCIe ports
>>>     Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
>>>
>>>    arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>>    drivers/ata/ahci.c   | 18 --------
>>>    2 files changed, 99 insertions(+), 18 deletions(-)
>>>
>>
>> Gentle ping on this series.
> 
> I can pick up patch 2/2, but want to wait until patch 1/2 has been picked
> up either by Bjorn, or one of the x86 maintainers.
> 
> 
> Kind regards,
> Niklas

I think it would be better that this all goes through one tree so we 
don't end up with a situation that someone has the revert but not the fix.

So maybe better to leave an A-b tag on 2/2 and then let pci or tip pick 
up the series.

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Mario Limonciello]

On 9/20/26 23:52, Mario Limonciello wrote:
> On 9/8/26 2:05 PM, Mario Limonciello wrote:
>> An issue has been reported by a number of people that corruption
>> was occurring on storage for desktop systems.  It's notably reported
>> on SATA, but the same issue also appears on NVME.
>>
>> At a glance it looks like an IOMMU issue as turning off the IOMMU helps
>> the issue, but it's actually a problem that occurs specifically with any
>> IOVA addressed >58 bits.
>>
>> This is because the BIOS on these systems is enabling a feature of the
>> root port called 'enhanced atomics' which repurposes those upper 5 bits
>> of address space.  That feature should only be enabled by the BIOS when
>> the partner device supports it, but it's instead needlessly enabled on a
>> number of root ports.
>>
>> As some of these systems probably won't receive BIOS updates and there is
>> active reports of data corruption root caused to this add a quirk to
>> disable it on affected models, and also remove the quirk that was
>> introduced to work around this issue in drivers/ata.
>>
>> v2:
>>   *  Added resume fixups for the affected AMD PCIe ports
>>
>> Mario Limonciello (2):
>>    x86/PCI: Disable enhanced atomics on some AMD PCIe ports
>>    Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
>>
>>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>   drivers/ata/ahci.c   | 18 --------
>>   2 files changed, 99 insertions(+), 18 deletions(-)
>>
> 
> Gentle ping on this series.

I didn't include it on the series while we were getting alignment, but 
when committing this should include

Cc: stable@vger.kernel.org

If it needs to spin for any reason, I'll include that on v3.

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Bjorn Helgaas]

On Tue, Sep 08, 2026 at 02:05:58PM -0500, Mario Limonciello wrote:
> An issue has been reported by a number of people that corruption
> was occurring on storage for desktop systems.  It's notably reported
> on SATA, but the same issue also appears on NVME.
> 
> At a glance it looks like an IOMMU issue as turning off the IOMMU helps
> the issue, but it's actually a problem that occurs specifically with any
> IOVA addressed >58 bits.
> 
> This is because the BIOS on these systems is enabling a feature of the
> root port called 'enhanced atomics' which repurposes those upper 5 bits
> of address space.  That feature should only be enabled by the BIOS when
> the partner device supports it, but it's instead needlessly enabled on a
> number of root ports.
> 
> As some of these systems probably won't receive BIOS updates and there is
> active reports of data corruption root caused to this add a quirk to
> disable it on affected models, and also remove the quirk that was
> introduced to work around this issue in drivers/ata.
> 
> v2:
>  *  Added resume fixups for the affected AMD PCIe ports
> 
> Mario Limonciello (2):
>   x86/PCI: Disable enhanced atomics on some AMD PCIe ports
>   Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
> 
>  arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/ata/ahci.c   | 18 --------
>  2 files changed, 99 insertions(+), 18 deletions(-)

Applied to pci/for-linus for v7.3, thanks!

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Mario Limonciello]

On 9/23/26 13:36, Bjorn Helgaas wrote:
> On Tue, Sep 08, 2026 at 02:05:58PM -0500, Mario Limonciello wrote:
>> An issue has been reported by a number of people that corruption
>> was occurring on storage for desktop systems.  It's notably reported
>> on SATA, but the same issue also appears on NVME.
>>
>> At a glance it looks like an IOMMU issue as turning off the IOMMU helps
>> the issue, but it's actually a problem that occurs specifically with any
>> IOVA addressed >58 bits.
>>
>> This is because the BIOS on these systems is enabling a feature of the
>> root port called 'enhanced atomics' which repurposes those upper 5 bits
>> of address space.  That feature should only be enabled by the BIOS when
>> the partner device supports it, but it's instead needlessly enabled on a
>> number of root ports.
>>
>> As some of these systems probably won't receive BIOS updates and there is
>> active reports of data corruption root caused to this add a quirk to
>> disable it on affected models, and also remove the quirk that was
>> introduced to work around this issue in drivers/ata.
>>
>> v2:
>>   *  Added resume fixups for the affected AMD PCIe ports
>>
>> Mario Limonciello (2):
>>    x86/PCI: Disable enhanced atomics on some AMD PCIe ports
>>    Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
>>
>>   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>   drivers/ata/ahci.c   | 18 --------
>>   2 files changed, 99 insertions(+), 18 deletions(-)
> 
> Applied to pci/for-linus for v7.3, thanks!

Thanks!  Could you add to the commits:

Cc: stable@vger.kernel.org

We should take this back to any non EoL kernel as well.

Re: [PATCH v2 0/2] Fix for storage corruption w/ AMD IOMMU on 64-bit addressing

[Bjorn Helgaas]

On Wed, Sep 23, 2026 at 01:39:46PM -0500, Mario Limonciello wrote:
> On 9/23/26 13:36, Bjorn Helgaas wrote:
> > On Tue, Sep 08, 2026 at 02:05:58PM -0500, Mario Limonciello wrote:
> > > An issue has been reported by a number of people that corruption
> > > was occurring on storage for desktop systems.  It's notably reported
> > > on SATA, but the same issue also appears on NVME.
> > > 
> > > At a glance it looks like an IOMMU issue as turning off the IOMMU helps
> > > the issue, but it's actually a problem that occurs specifically with any
> > > IOVA addressed >58 bits.
> > > 
> > > This is because the BIOS on these systems is enabling a feature of the
> > > root port called 'enhanced atomics' which repurposes those upper 5 bits
> > > of address space.  That feature should only be enabled by the BIOS when
> > > the partner device supports it, but it's instead needlessly enabled on a
> > > number of root ports.
> > > 
> > > As some of these systems probably won't receive BIOS updates and there is
> > > active reports of data corruption root caused to this add a quirk to
> > > disable it on affected models, and also remove the quirk that was
> > > introduced to work around this issue in drivers/ata.
> > > 
> > > v2:
> > >   *  Added resume fixups for the affected AMD PCIe ports
> > > 
> > > Mario Limonciello (2):
> > >    x86/PCI: Disable enhanced atomics on some AMD PCIe ports
> > >    Revert "ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585"
> > > 
> > >   arch/x86/pci/fixup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
> > >   drivers/ata/ahci.c   | 18 --------
> > >   2 files changed, 99 insertions(+), 18 deletions(-)
> > 
> > Applied to pci/for-linus for v7.3, thanks!
> 
> Thanks!  Could you add to the commits:
> 
> Cc: stable@vger.kernel.org
> 
> We should take this back to any non EoL kernel as well.

Done :)