On Wed, Sep 28, 2022 at 10:38:43AM +0200, Sebastian Oswald wrote: > On Tue, 27 Sep 2022 08:03:59 -0700 > Mike Larkin <[email protected]> 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 <[email protected]> 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 > >> >> [email protected]:/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?
no > /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). > I'm not sure this is a beginner task. But you could write a function like acpi_enable_onegpe and instead make it clear the gpe and then call that from acpi_attach. Generally, it's not worth the effort trying to fix broken hardware like this. Because how do you know there isn't other brokenness elsewhere? > Thanks, > Sebastian
