On Tue, 27 Sep 2022 08:03:59 -0700 Mike Larkin <mlar...@nested.page> wrote:
>On Tue, Sep 27, 2022 at 11:02:50AM +0200, Sebastian Oswald wrote: >> On Mon, 26 Sep 2022 17:57:23 -0700 >> Mike Larkin <mlar...@nested.page> wrote: >> >> >On Mon, Sep 26, 2022 at 05:40:04PM +0200, Sebastian Oswald wrote: >> >> >Synopsis: High interrupt load from acpi0 on Intel N5105 platform >> >> >Category: system >> >> >Environment: >> >> System : OpenBSD 7.1 >> >> Details : OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 >> >> 18:03:57 MDT 2022 >> >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> >> >> Architecture: OpenBSD.amd64 >> >> Machine : amd64 >> >> >> >> >Description: >> >> On multiple (3), freshly installed systems based on Jasper Lake >> >> Celeron N5105 platform, CPU0 has high interrupt rate at idle. >> >> >> >> >How-To-Repeat: >> >> Installed 7.1 from current usb image, reboot. >> >> >> >> # top | head -n6 >> >> load averages: 0.99, 0.97, 0.92 a-vpn1.gassner.lan 17:38:58 >> >> 26 processes: 25 idle, 1 on processor up 8:01 >> >> CPU0 states: 0.0% user, 0.0% nice, 14.3% sys, 0.5% spin, 77.0% intr, >> >> 8.3% idle >> >> CPU1 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, >> >> 99.9% idle >> >> CPU2 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, >> >> 99.9% idle >> >> CPU3 states: 0.1% user, 0.0% nice, 0.0% sys, 0.1% spin, 0.0% intr, >> >> 99.9% idle >> >> >> >> >> >> This output is from a freshly rebooted system; rates for irq96/acpi are >> >> always way above 8000: >> >> >> >> # vmstat -i >> >> interrupt total rate >> >> irq0/clock 20105 394 >> >> irq0/ipi 8656 169 >> >> irq144/com0 86 1 >> >> irq96/acpi0 445306 8731 >> >> irq145/inteldrm0 1137 22 >> >> irq100/nvme0 33913 664 >> >> irq114/igc0:0 74 1 >> >> irq115/igc0:1 222 4 >> >> irq116/igc0:2 41 0 >> >> irq117/igc0:3 34 0 >> >> irq118/igc0 2 0 >> >> Total 509576 9991 >> >> >> > >> >Could be stuck GPE. >> > >> >In acpi.c, around line 2273: >> > >> > dnprintf(10, "handling GPE %.2x\n", gpe); >> > >> >change that to >> > >> > printf("handling GPE %.2x\n", gpe); >> > >> >And see which GPE keeps firing. It's likely gonna make the system somewhat >> >slower since you'll be spamming dmesg like crazy. >> > >> >then report back what GPE you found firing. >> >> Thank you for the quick reply. >> >> With that patch applied, immediately during boot stdout gets spammed >> with "handling GPE 6f". >> >> From doing a quick search, this seems to be usually caused by a broken >> ACPI implementation on the BIOS side? >> I already contacted the vendor to check for a newer BIOS version. >> >> In the meantime or if there isn't any patched BIOS available, is there >> a way to find out what event '6f' correlates to and disable/ignore >> handling of that interrupt? >> > ><snip> > >Seems to be a common problem with this machine, not only on OpenBSD. Google >_L6F GPE AL6F and you'll see that everyone else with the issue needed to >hack their AML or get a BIOS update. Looks like shoddy AML from AMIbios. > >If you want to disable it, you'll need to do that in the GPE handler in >acpi.c. > >-ml Yes, I also found a bunch on this topic, usually for other cheap Mainboards (mostly asrock). I don't have high hopes to get a patched BIOS from the vendor of those appliances, so I started looking into ways of 'fixing' (ignoring) that GPE on the OS side. Apparently most OSes have some way to override the DSDT; e.g. FreeBSD can override the AML at boot pretty easily: https://docs.freebsd.org/en/books/handbook/config/#_overriding_the_default_aml Is there any such mechanism in OpenBSD? /var/db/acpi/DSDT.2 on these systems actually contains the same code as mentioned here: https://forums.freebsd.org/threads/disabling-gpe6-gpe-flooding-prevention.56963/#post-324358 (interestingly, FreeBSD doesn't show the same behavior; total interrupt rate according to 'vmstat -i' is <100 at idle) Otherwise, how could disabling that GPE in acpi.c look like? Sorry to bother you with that, I'm merely a sysadmin with some very rudimentary coding skills (i.e. I can roughly follow what some code might be doing as long as it isn't too complex). Thanks, Sebastian
pgpLz0n1tJ0Wq.pgp
Description: OpenPGP digital signature