Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAFv23QmH4ooXJzX9A0CBObrETZgb9sT4dfh03NZA--fKfZnHDA@mail.gmail.com>
 <87fsixz8cb.wl-maz@kernel.org>
In-Reply-To: <87fsixz8cb.wl-maz@kernel.org>
From:   AceLan Kao <acelan.kao@canonical.com>
Date:   Wed, 20 Jul 2022 10:53:37 +0800
Message-ID: <CAFv23Q=O29J4K_bdTi_SuThsEZN_SFNNz+bBPQSA+RGCANm6=w@mail.gmail.com>
Subject: Re: There are not enough CPU0 APIC IRQs while doing IRQ migration
 during S3
To:     Marc Zyngier <maz@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
        Kai-Heng Feng <kai.heng.feng@canonical.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Marc Zyngier <maz@kernel.org> =E6=96=BC 2022=E5=B9=B47=E6=9C=8819=E6=97=A5 =
=E9=80=B1=E4=BA=8C =E4=B8=8B=E5=8D=886:48=E5=AF=AB=E9=81=93=EF=BC=9A
>
> [- Jason]
>
> On Tue, 19 Jul 2022 06:55:21 +0100,
> AceLan Kao <acelan.kao@canonical.com> wrote:
> >
> > HI all,
> >
> > I encountered an issue while doing S3, it shows below message and then
> > failed to enter S3
> > [  106.731140] CPU 31 has 116 vectors, 85 available. Cannot disable CPU
> > [  106.731551] ACPI: \_PR_.C01F: Found 2 idle states
> > [  106.732610] Error taking CPU31 down: -28
> > [  106.732612] Non-boot CPUs are not disabled
> >
> > CPU: AMD Ryzen Threadripper PRO 3955WX 16-Cores
> > Kernel: v5.19-rc7
> > There are 5 PCI to 4 type-c ports USB cards on the machine, and It
> > wouldn't lead to the issue if only 4 cards are plugged. So, it looks
> > like it can't handle 5 cards, and failed on the IRQ migration.
> >
> > The workaround provided by kaiheng is to release the irq while
> > suspending and request irq while resuming.
> > I'm wondering do we have a better solution for this kind of issue?
> > Thanks.
> >
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index edc6881c8a1b..91c79b21cb57 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -17,6 +17,7 @@
> > #include <linux/slab.h>
> > #include <linux/dmi.h>
> > #include <linux/dma-mapping.h>
> > +#include <linux/suspend.h>
> >
> > #include "xhci.h"
> > #include "xhci-trace.h"
> > @@ -1079,6 +1080,9 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_w=
akeup)
> >                                __func__);
> >        }
> >
> > +       if (pm_suspend_via_firmware())
> > +               xhci_cleanup_msix(xhci);
>
> I'm a bit clueless when it comes to the combination of x86 and xhci,
> but doesn't this prevent resuming on a xhci interrupt?
The PCI cards provide 4 type-c USB ports, and in the beginning we
found that removing one PCI card fixed the issue, so we were trying to
fix the issue in xhci driver.
The USB ports on the PCI cards can't resume the system from S3 even
without the workaround,
but the USB ports on the rear panel of the motherboard still work with
the workaround.