From: Ricardo Ribalda <ribalda@chromium.org>
To: Andrea Righi <andrea.righi@canonical.com>
Cc: virtualization@lists.linux.dev, stevensd@chromium.org,
"mst@redhat.com" <mst@redhat.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: ACPI timeouts when enabling KASAN
Date: Sat, 13 Apr 2024 09:39:09 +0200 [thread overview]
Message-ID: <CANiDSCuikv8Lw3x27qQnyNh=tBSkmcvYkUjaqL=8uMqLmn2A6w@mail.gmail.com> (raw)
In-Reply-To: <Zhoeec0lfVEPmGj0@gpd>
On Sat, 13 Apr 2024 at 07:56, Andrea Righi <andrea.righi@canonical.com> wrote:
>
> On Fri, Apr 12, 2024 at 11:43:22PM +0200, Ricardo Ribalda wrote:
> > Hi
>
> Hi Ricardo,
Hi Andrea!
>
> >
> > I am using virtme to do some CI around linux-media.
> >
> > Everything works as expected, but when I enable KASAN, I am starting
> > to get a lot of timeouts when the Method _PRT is executed. Eg:
> >
> > [ 56.335875] ACPI Error: Aborting method \_SB.PCI0._PRT due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20230628/psparse-529)
> > [ 56.529826] ACPI Error: Method execution failed \_SB.PCI0._PRT due
> > to previous error (AE_AML_LOOP_TIMEOUT) (20230628/uteval-68)
> > [ 56.532391] virtio-pci 0000:00:02.0: can't derive routing for PCI INT A
> > [ 56.532823] virtio-pci 0000:00:02.0: PCI INT A: no GSI
> > [ 86.877471] ACPI Error: Aborting method \_SB.PCI0._PRT due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20230628/psparse-529)
> > [ 87.073854] ACPI Error: Method execution failed \_SB.PCI0._PRT due
> > to previous error (AE_AML_LOOP_TIMEOUT) (20230628/uteval-68)
> > [ 87.075550] virtio-pci 0000:00:04.0: can't derive routing for PCI INT A
> > [ 87.075810] virtio-pci 0000:00:04.0: PCI INT A: no GSI
> >
> > 0000:00:04.0 and 0000:00:02.0 are virtio devices (console and 9p-filesystem)
> >
> > If I increase the timeout (ACPI_MAX_LOOP_TIMEOUT), then the Method is
> > always executed, but it is very annoying that I have to wait more than
> > 5 minutes to start the vm.
> >
> > Despite not having kvm enabled, the machine is quite decent, so I
> > would expect that it could run that method relatively fast.
> >
> > Do you have any hint of what I should be looking at?
>
> I'm wondering if it's a microvm-related issue...
>
> Can you try to add --disable-microvm to your virtme command line and see
> if it makes any difference?
I get the same results :(. BTW, this is the service that I think it is
taking lots of time:
Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table
{
Local0 = Package (0x80){}
Local1 = Zero
While ((Local1 < 0x80))
{
Local2 = (Local1 >> 0x02)
Local3 = ((Local1 + Local2) & 0x03)
If ((Local3 == Zero))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKD,
Zero
}
}
If ((Local3 == One))
{
If ((Local1 == 0x04))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKS,
Zero
}
}
Else
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKA,
Zero
}
}
}
If ((Local3 == 0x02))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKB,
Zero
}
}
If ((Local3 == 0x03))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKC,
Zero
}
}
Local4 [Zero] = ((Local2 << 0x10) | 0xFFFF)
Local4 [One] = (Local1 & 0x03)
Local0 [Local1] = Local4
Local1++
}
Return (Local0)
}
}
>
> Thanks,
> -Andrea
>
> >
> > Thanks!
> >
> > ```
> > # virtme-ng --version
> > virtme-ng 1.23
> > # qemu-system-amd64 --version
> > QEMU emulator version 8.2.1 (Debian 1:8.2.1+ds-2)
> > Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers
> > # git describe
> > v6.9-rc3-208-g586b5dfb51b96
> >
> > # virtme-configkernel --defconfig --arch x86_64
> > # scripts/config -e KASAN
> > # make olddefconfig
> > # make all -j 256
> > # virtme-run --kdir . --mods=auto --show-command --show-boot-console
> > --verbose --cpus 2 --memory 4G --script-sh "echo HelloWorld"
> > ```
> >
> >
> >
> > --
> > Ricardo Ribalda
> > Software Engineer
> > ribalda@google.com
--
Ricardo Ribalda
parent reply other threads:[~2024-04-13 7:39 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <Zhoeec0lfVEPmGj0@gpd>]
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='CANiDSCuikv8Lw3x27qQnyNh=tBSkmcvYkUjaqL=8uMqLmn2A6w@mail.gmail.com' \
--to=ribalda@chromium.org \
--cc=andrea.righi@canonical.com \
--cc=linux-acpi@vger.kernel.org \
--cc=mst@redhat.com \
--cc=stevensd@chromium.org \
--cc=virtualization@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).