All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.