From: Niklas Cassel <cassel@kernel.org>
To: Arthur Husband <artmoty@gmail.com>
Cc: linux-ide@vger.kernel.org, dlemoal@kernel.org
Subject: Re: [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585
Date: Fri, 3 Apr 2026 10:12:41 +0200 [thread overview]
Message-ID: <ac92eQ4mKy1GSIo_@ryzen> (raw)
In-Reply-To: <20260403050418.50398-1-artmoty@gmail.com>
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
next prev parent reply other threads:[~2026-04-03 8:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 5:04 [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585 Arthur Husband
2026-04-03 7:02 ` Damien Le Moal
2026-04-03 8:12 ` Niklas Cassel [this message]
2026-04-03 8:19 ` Niklas Cassel
2026-04-03 19:17 ` [PATCH v2] ata: " Arthur Husband
2026-04-05 6:38 ` Damien Le Moal
2026-04-03 22:53 ` Arthur Husband
2026-04-06 7:30 ` Niklas Cassel
2026-04-06 20:11 ` [PATCH v3] " Arthur Husband
-- strict thread matches above, loose matches on Subject: below --
2026-04-03 5:02 [PATCH] " Arthur Husband
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac92eQ4mKy1GSIo_@ryzen \
--to=cassel@kernel.org \
--cc=artmoty@gmail.com \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox