Re: [REGRESSION] Silent SATA read corruption with dma-iommu on AMD 600-series AHCI (6.19 good, 7.0+ bad)

On 8/28/26 10:24, Mikael Etienne wrote:
> On 8/28/2026 6:22 PM, Limonciello, Mario wrote:
>> BUT the issue internally does show the issue is specificially once the
>> 32-bit IOVA space is exhausted.
>>
>> Unfortunately; the solution is currently a BIOS change in how the type
>> bytes of the IOVA is handled.
> 
> Hi Mario,
> 
> Thanks -- the 32-bit IOVA exhaustion detail is the first thing that explains
> the timing I see. My failure takes 3h25m of sustained reads to appear, and a
> reboot clears it completely with the same kernel and the same on-disk data.
> "Low IOVA space works, high IOVA space does not, and a reboot starts from an
> empty low space again" fits that exactly.
> 
> The ASM1166 write-up you linked is also a very close match: a controller that
> advertises CAP.S64A but cannot actually reach above 4 GB. My SATA controller is
> the AMD 600-series chipset one (1022:43f6), which is Promontory/ASMedia silicon,
> and it likewise advertises 64bit in its AHCI flags.
> 
> Firmware, since you mention a BIOS fix: I am already on the latest available for
> this board.
> 
>    Gigabyte X870I AORUS PRO ICE
>    BIOS FB1c, 2026-07-21, AMI, platform firmware revision 5.41
>    AGESA!V9 ComboAm5PI 1.3.0.1c
>    CPU microcode 0x0a70520a
> 
> So whatever BIOS-side change you have internally is either not in AGESA
> 1.3.0.1c, or not sufficient on this board.

It's not in any AGESA release yet.  This is very fresh information I am 
sharing that we have root caused the issue and have a proposed 
modification.  It will take a while to make it through the process 
machinery.
> 
> On the bisection: before committing to two weeks, I would like to try making the
> reproducer fast. If the trigger really is 32-bit IOVA exhaustion, then booting
> with iommu.forcedac=1 alone should hand out high IOVAs immediately and fail in
> minutes rather than after 3h25m. If that works, a v6.19..v7.0 bisection becomes
> an evening rather than a fortnight, and you would also have a reproducer that is
> practical to run in a lab.

We do have a reproducer in our lab environment that will rapidly 
allocate and trip this issue which is how we could analyze it and root 
cause it.

> 
> I will try that tonight, with all services stopped, then the
> amd_iommu=pgtbl_v2 iommu.forcedac=1 combination Vasant asked for. I will report
> bytes re-read, wall time and workload rather than a verdict.
> 
> If you already know that forcedac alone will not behave that way, please tell me
> and I will not waste the evening on it.
> 
> And to be straight about the rest: this is a production home server, so a
> two-week bisection is a real cost for me. The reproducer is three lines of fio.
> If you can run it on comparable hardware in your lab, that would very likely be
> faster than me doing it here -- and I am happy to run any specific kernel or
> debug patch you want in the meantime.

I don't yet have any confirmation we can patch this at runtime.  If I do 
come up with a way to do that which works will let you know.

By chance did this issue coincide with you switching from something 
different to the Ryzen 7 8700G?  For example switching from Raphael or 
Granite Ridge parts to that Phoenix part.