On Tue, 18 Oct 2022 15:30:53 +0100 Igor Petruk <[email protected]> wrote:
>On Tue, Oct 18, 2022 at 3:19 PM Paul de Weerd <[email protected]> wrote: >> >> On Mon, Oct 17, 2022 at 09:52:05PM +0100, Igor Petruk wrote: >> | It did not quite work in acpi_attach. I assume it is either because later >> | on all GPEs are enabled and disabled multiple times. >> | Or maybe because the struct is passed to another thread almost >> | at the end of acpi_attach. >> | >> | When I added it after this line, it worked: >> | >> https://github.com/openbsd/src/blob/62d244ed99f17c1263ee095bc7d8fa1f61df02fd/sys/dev/acpi/acpi.c#L2665. >> | >> | Now the OS works very smoothly, as expected. I don't know if >> | it was an optimal place, just added it somewhere where it made >> | an approximate sense. >> >> As I have a similarly affected machine, I reached out to Igor to ask >> for his diff. After applying it to my system, I see immediate >> improvement: >> >> --- before ----------------------------------------------------------- >> interrupt total rate >> irq0/clock 9152280 399 >> irq0/ipi 40984 1 >> irq144/com0 104 0 >> irq96/acpi0 140950051 6159 >> irq145/inteldrm0 22 0 >> irq97/xhci0 22941 1 >> irq100/nvme0 41503 1 >> irq114/igc0:0 74073 3 >> irq115/igc0:1 15410 0 >> irq116/igc0:2 6582 0 >> irq117/igc0:3 26653 1 >> irq118/igc0 2 0 >> Total 150330605 6568 >> ---------------------------------------------------------------------- >> >> --- after ------------------------------------------------------------ >> interrupt total rate >> irq0/clock 1165904 399 >> irq0/ipi 80350 27 >> irq144/com0 105 0 >> irq96/acpi0 1 0 >> irq145/inteldrm0 19 0 >> irq97/xhci0 2974 1 >> irq100/nvme0 16924 5 >> irq114/igc0:0 8054 2 >> irq115/igc0:1 5278 1 >> irq116/igc0:2 35907 12 >> irq117/igc0:3 2354 0 >> irq118/igc0 2 0 >> Total 1317872 451 >> ---------------------------------------------------------------------- >> >> I'm including Igor's diff at the end of this mail (with his >> permission). I've been searching for a BIOS update for this system >> (HUNSN RS39, /var/db/acpi files available from [1]), but of course >> that's nowhere to be found. >> >> Thanks to Igor .. I'll continue searching for an updated BIOS (but I'm >> not holding my breath) >> >> Paul >> >> [1]: http://www.weirdnet.nl/openbsd/issues/2022/hunsn_rs39_acpi.tgz >> [...] >> >> --- acpi_off.diff ---------------------------------------------------- >> Index: sys/dev/acpi/acpi.c >> =================================================================== >> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v >> retrieving revision 1.418 >> diff -u -p -u -p -r1.418 acpi.c >> --- sys/dev/acpi/acpi.c 13 Sep 2022 17:14:54 -0000 1.418 >> +++ sys/dev/acpi/acpi.c 18 Oct 2022 10:04:30 -0000 >> @@ -97,6 +97,7 @@ void acpi_init_gpes(struct acpi_softc *) >> void acpi_disable_allgpes(struct acpi_softc *); >> struct gpe_block *acpi_find_gpe(struct acpi_softc *, int); >> void acpi_enable_onegpe(struct acpi_softc *, int); >> +void acpi_disable_onegpe(struct acpi_softc *, int); >> int acpi_gpe(struct acpi_softc *, int, void *); >> >> void acpi_enable_rungpes(struct acpi_softc *); >> @@ -2231,6 +2232,19 @@ acpi_enable_onegpe(struct acpi_softc *sc >> acpi_write_pmreg(sc, ACPIREG_GPE_EN, gpe>>3, en | mask); >> } >> >> +void >> +acpi_disable_onegpe(struct acpi_softc *sc, int gpe) >> +{ >> + uint8_t mask, en; >> + >> + /* Read enabled register */ >> + mask = (1L << (gpe & 7)); >> + en = acpi_read_pmreg(sc, ACPIREG_GPE_EN, gpe>>3); >> + dnprintf(50, "disabling GPE %.2x (current: %sabled) %.2x\n", >> + gpe, (en & mask) ? "en" : "dis", en); >> + acpi_write_pmreg(sc, ACPIREG_GPE_EN, gpe>>3, en & ~mask); >> +} >> + >> /* Clear all GPEs */ >> void >> acpi_disable_allgpes(struct acpi_softc *sc) >> @@ -2663,6 +2677,8 @@ acpi_thread(void *arg) >> >> /* Enable handled GPEs here */ >> acpi_enable_rungpes(sc); >> + acpi_disable_onegpe(sc, 0x6f); >> + >> splx(s); >> } >> >> ---------------------------------------------------------------------- >> >> -- >> >++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+ >> +++++++++++>-]<.>++[<------------>-]<+.--------------.[-] >> http://www.weirdnet.nl/ > >Glad to hear it worked. > >Hypothetically... I were to work on building a sysctl like: > >kern.acpi.mask_gpes=0x6f,0x42 > >for people to enjoy normal OS operation before they get their >firmware fixes, would that be a good idea? Does it have a chance >to be accepted? > >My concern mainly is the interface. I don't know if a more >generic solution for all other interrupts need to be built, >not just ACPI GPE. > >Thanks, >Igor. This diff also solves the problem on my systems. Thanks! Regarding that sysctl: Given the large number of borked ACPI tables/implementations (and unwilling/incompetent vendors) out there, I think it would be benefical to have such masking capabilities. Thanks, Sebastian
pgpZo95XPPtn5.pgp
Description: OpenPGP digital signature
