lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jwdxOFME0NiCmTUO9pxZb5QKZ8ZAcAF10jQqzxkqpT6g@mail.gmail.com>
Date:   Fri, 10 Jun 2022 15:17:51 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     blinkin@...il.it
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        linux-acpi <linux-acpi@...r.kernel.org>
Subject: Re: Bug report for kernel v4.15-rc8+

On Fri, Jun 10, 2022 at 11:52 AM <blinkin@...il.it> wrote:
>
> hello, any news on this?
>
> ----- Messaggio originale -----
> Da: "Thomas Gleixner" <tglx@...utronix.de>
> A: blinkin@...il.it
> Cc: "linux-kernel" <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, "Len Brown" <lenb@...nel.org>, linux-acpi@...r.kernel.org
> Inviato: Mercoledì, 11 agosto 2021 16:20:41
> Oggetto: Re: Bug report for kernel v4.15-rc8+
>
> On Wed, Aug 11 2021 at 15:51, blinkin@...il.it wrote:
> > 1) You're booting with an out of tree module
> >
> >   Uninstalled virtualbox, reproduced same behavior without the module.
> >   dmesg outputs attached with and without the workaround
> >   (dmesg_novboxdrv_clean.txt and dmesg_novboxdrv_irqaffinity0.txt)
>
> Ok.
>
> > 2) Please provide information what is consuming 90% of a CPU
> >
> >   top shows a kworker process consistently at 50% without the
> >   workaround, 60% with the workaround. No significant activity amounts
> >   from other processes.  Sometimes that 50% is split between two
> >   kworker processes for a short time.  CPU core #0 activity is a
> >   constant 60% without the workaround, 90% with the workaround
>
> That's broken. /proc/interrupts gives some hint:
>
> 1) Stock kernel
>
> >             CPU0       CPU1       CPU2       CPU3
> >    0:         10          0          0          0  IR-IO-APIC    2-edge      timer
> >    1:          0          0          0          9  IR-IO-APIC    1-edge      i8042
> >    8:          0          1          0          0  IR-IO-APIC    8-edge      rtc0
> >    9:          0     923411          0          0  IR-IO-APIC    9-fasteoi   acpi
>
> 900k ACPI interrupts right after boot
>
> >             CPU0       CPU1       CPU2       CPU3
> >    0:         10          0          0          0  IR-IO-APIC    2-edge      timer
> >    1:          0          0          0         11  IR-IO-APIC    1-edge      i8042
> >    8:          0          1          0          0  IR-IO-APIC    8-edge      rtc0
> >    9:          0    4869059          0          0  IR-IO-APIC    9-fasteoi   acpi
>
> One minute later it's 4.8M
>
> With affinity forced to CPU0 it's even more:
>
> >             CPU0       CPU1       CPU2       CPU3
> >    0:         10          0          0          0  IR-IO-APIC    2-edge      timer
> >    1:          9          0          0          0  IR-IO-APIC    1-edge      i8042
> >    8:          1          0          0          0  IR-IO-APIC    8-edge      rtc0
> >    9:    7576456          0          0          0  IR-IO-APIC    9-fasteoi   acpi
>
> 7.5M right after boot
>
> >             CPU0       CPU1       CPU2       CPU3
> >    0:         10          0          0          0  IR-IO-APIC    2-edge      timer
> >    1:         11          0          0          0  IR-IO-APIC    1-edge      i8042
> >    8:          1          0          0          0  IR-IO-APIC    8-edge      rtc0
> >    9:   10992420          0          0          0  IR-IO-APIC    9-fasteoi   acpi
>
> 10.9M after one minute. Though the delta between right after boot and 1
> minute later is in the same ballpark.
>
> Cc'ed the ACPI people for clues.

Looks like a GPE storm to me.

I would look into /sys/firmware/acpi/interrupts/* for hints.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ