public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, suravee.suthikulpanit@amd.com, will@kernel.org,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: iommu: flood of ahci 0000:e6:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0055 address=0xa14a4000 flags=0x0070]
Date: Wed, 5 Feb 2025 14:36:37 +0100	[thread overview]
Message-ID: <Z6NpZcbE6fiIkSGh@Red> (raw)
In-Reply-To: <42a8ca6f-a881-4b4c-9ddb-bf3f2bc6f539@arm.com>

Le Mon, Feb 03, 2025 at 01:01:45PM +0000, Robin Murphy a écrit :
> On 2025-02-03 9:05 am, Corentin Labbe wrote:
> > Hello
> > 
> > I have a supermicro server which is flooded of kernel message:
> > ahci 0000:e6:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0055 address=0xa14a4000 flags=0x0070]
> > 
> > The server works perfectly anyway.
> > It happens with official ubuntu kernel vmlinuz-6.8.0-51-generic.
> > I tried also a custom 6.12.6, same problem.
> > 
> > I tried to update bios, no change.
> > I tried iommu=soft, no change.
> > 
> > I dont know what to do next.
> > 
> > Regards
> > 
> 
> > IOMMU group 83 e6:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe 2.0 x2 4-port SATA 6 Gb/s RAID Controller [1b4b:9230] (rev 11)
> 
> Wow, a Marvell SATA controller doing something other than the usual 
> phantom function quirk, that's a nice change :D
> 
> I'd guess that firmware has left it running for something like legacy 
> IDE emulation (if that's still a thing?) or its own soft-RAID driver, 
> but neglected to declare an IVMD entry to described the reserved memory 
> region(s) it's using for that. A smoking gun would be if 0xa14a4000 
> matches some firmware-reserved PA in the system memory map. In that 
> case, if you're lucky you might have some firmware/BIOS option to 
> disable fancy behaviour and leave it in plain AHCI mode. Otherwise, 
> booting with "iommu.passthrough=1" (or the even bigger hammer of 
> "amd_iommu=off") should at least allow you to ignore the issue.
> 

Hello

Thanks for your help

There was no AHCI option in the BIOS (appart hotplug enable).

Adding iommu.passthrough=1 lead to absence of thoses messages.

Unfortunatly, my example is not correct, the address is mostly random:
dmesg |grep IO_PAGE_FAULT | grep -o 'address=0x[0-9a-f]*' | sort | uniq -c | wc -l
9297

dmesg |grep IO_PAGE_FAULT | grep -o 'address=0x[0-9a-f]*' | sort | uniq -c | head
      2 address=0x1101f000
      2 address=0x1101f004
      3 address=0x1102f000
      1 address=0x1102f004
      2 address=0x1102f008
      2 address=0x1102f010
      2 address=0x11043000
      2 address=0x11043004
      1 address=0x11047000
      1 address=0x11047004

dmesg |grep IO_PAGE_FAULT | grep -o 'address=0x[0-9a-f]*' | sort | uniq -c | tail
      2 address=0xfffffffffe751004
      2 address=0xfffffffffe7e6000
      2 address=0xfffffffffe7e6004
      4 address=0xfffffffffe823000
      3 address=0xfffffffffe823004
      2 address=0xfffffffffe830000
      2 address=0xfffffffffe830004
      3 address=0xfffffffffe833000
      1 address=0xfffffffffe833004
      1 address=0xfffffffffe833008

But the domain/flags are always the same

Full dmesg (without IOMMU messages) https://kernel.montjoie.ovh/dmesg.0

The server is doing qemu GPU passthough via VFIO.
I believe (aka I need to re-verify) that message start whatever qemu starts or not.

Thanks
Regards

  reply	other threads:[~2025-02-05 13:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03  9:05 iommu: flood of ahci 0000:e6:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0055 address=0xa14a4000 flags=0x0070] Corentin Labbe
2025-02-03 13:01 ` Robin Murphy
2025-02-05 13:36   ` Corentin Labbe [this message]
2025-02-05 18:53     ` Robin Murphy
2025-02-05 12:03 ` Vasant Hegde
2025-02-05 13:41   ` Corentin Labbe

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=Z6NpZcbE6fiIkSGh@Red \
    --to=clabbe.montjoie@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@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