public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
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

  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