I searched a bit more and found a few cases when other people reported this behavior:
https://marc.info/?l=openbsd-misc&m=154348280502809&w=2 https://marc.info/?l=openbsd-bugs&m=152022260714390&w=2 I applied a variation of the Thomas Merkel's patch (at the bottom) which took care of the symptoms while also reporting the masked event. I am facing a choice. This appears to be a rarely reported problem. I don't see a good reason to build any non-trivial mitigation (some variation of event rate limiting comes to mind). I can just carry a minimized patch forward for as long as I use the defective machine and rebuild GENERIC.MP as part of my weekly sysupgrade ritual. Anybody see a reason to prefer complicating the kernel? Will it stand a chance of getting committed? Any design ideas for such a workaround? Thanks Greg diff --git a/sys/dev/acpi/acpi.c b/sys/dev/acpi/acpi.c index c3871e007a3..9c069fd5314 100644 --- a/sys/dev/acpi/acpi.c +++ b/sys/dev/acpi/acpi.c @@ -2296,6 +2296,15 @@ acpi_gpe(struct acpi_softc *sc, int gpe, void *arg) struct aml_node *node = arg; uint8_t mask, en; + if (gpe == 0x2a && (sc->gpe_table[gpe].flags & GPE_LEVEL)) { + static unsigned short i; + if (i == 0) { + i++; + printf("acpi_gpe %d %s IGNORING\n", gpe, node->name); + } + return (0); + } + printf("acpi_gpe %d %s\n", gpe, node->name); dnprintf(10, "handling GPE %.2x\n", gpe); aml_evalnode(sc, node, 0, NULL, NULL);
