From: Lennert Buytenhek <kernel@wantstofly.org>
To: Mikael Etienne <mikael1022bzh@gmail.com>
Cc: cassel@kernel.org, mario.limonciello@amd.com,
roland.waltersson@netinsight.net, artmoty@gmail.com,
linux-ide@vger.kernel.org, david.laight.linux@gmail.com,
alvinwylim@gmail.com
Subject: Re: [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585
Date: Sat, 5 Sep 2026 17:13:05 +0300 [thread overview]
Message-ID: <apwjcf0zeP3CKq_g@wantstofly.org> (raw)
In-Reply-To: <178854093896.541085.18395405788748617410@gmail.com>
On Fri, Sep 04, 2026 at 11:55:38PM +0700, Mikael Etienne wrote:
> 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:
[...]
To echo what Niklas said, the DMA problem I was seeing a while ago with
the ASM106x was purely an issue with the ARM106x itself, that is, a
device-internal IOVA address width restriction, and had nothing to do
with the IOMMU in my system.
I was seeing AMD IOMMU I/O page faults in my particular case, but only
because the system I originally encountered the issue in was an AMD-based
system where the ASM106x happened to be behind an (AMD) IOMMU which was
by default enabled in an isolating fashion, and the device was indeed
causing I/O page faults, due to an IOVA address with restriction in the
device itself, and the AMD IOMMU correctly signaled those I/O page faults,
and the AMD IOMMU was not at fault for the device causing those I/O page
faults, and I did subsequently reproduce the issue on an Intel-based
system, where the ASM106x was causing the exact same I/O page faults --
that is, after the Intel IOMMU was manually enabled, which it wasn't
(and maybe still isn't?) by default.
In other words, I think that the issue I was seeing with the ASM106x
should probably be left out of consideration in the context of the current
discussion, where it appears from a distance that the (AMD) IOMMU in the
reporter's system is somehow implicated in the corruption and misbehavior
they are seeing.
next prev parent reply other threads:[~2026-09-05 14:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 13:35 [PATCH] ahci: force 32-bit DMA for JMicron JMB582/JMB585 Roland Waltersson
2026-09-03 21:40 ` Niklas Cassel
2026-09-03 22:36 ` Mario Limonciello
2026-09-04 5:20 ` Roland Waltersson
2026-09-04 11:14 ` Niklas Cassel
2026-09-04 12:38 ` Mario Limonciello
2026-09-04 12:50 ` Niklas Cassel
2026-09-04 16:55 ` Mikael Etienne
2026-09-05 11:38 ` Alvin Lim
2026-09-05 12:26 ` Mario Limonciello
2026-09-05 14:13 ` Lennert Buytenhek [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-03 5:04 Arthur Husband
2026-04-03 7:02 ` Damien Le Moal
2026-04-03 8:12 ` Niklas Cassel
2026-04-03 8:19 ` Niklas Cassel
2026-04-03 5:02 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=apwjcf0zeP3CKq_g@wantstofly.org \
--to=kernel@wantstofly.org \
--cc=alvinwylim@gmail.com \
--cc=artmoty@gmail.com \
--cc=cassel@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mikael1022bzh@gmail.com \
--cc=roland.waltersson@netinsight.net \
/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