On Tue, Nov 1, 2022 at 1:25 PM Igor Petruk <[email protected]> wrote: > > On Sun, Oct 30, 2022 at 11:04 AM Paul de Weerd <[email protected]> wrote: > > > > On Fri, Oct 28, 2022 at 01:15:08PM +0200, Sebastian Oswald wrote: > > | >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. > > > > How would a regular user know which GPEs to mask? This time, it's > > 0x6f, but what will it be on the next poor implementation? > > > > I don't have an answer, but I think there's more to it than just > > saying "mask these GPEs". > > > > Paul > > > > -- > > >++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+ > > +++++++++++>-]<.>++[<------------>-]<+.--------------.[-] > > http://www.weirdnet.nl/ > > This is a good point Paul, it is not trivial. In this thread we > had to resort to adding printfs to the custom kernel build. > > However, next users can find this as a "known problem" of > particular hardware in mailings lists, forums and at > extremely low cost verify if it helps. > > Currently, due to lack of fix in the kernel or in the hardware, > the OpenBSD user has to do the following: > > * Figure out that this is the root cause > * Switch to current > * Learn how to compile OpenBSD from sources > * Get the sources, apply the patch, build the kernel, > the base system, xenocara > * Maintain updates manually by refetching the source > code and re-applying the patch > * Face the consequence of current source based > instability and packages being occasionaly out of sync > > If there was a mitigation (like in Linux and FreeBSD that > users do use for imperfect hardware) - everyone could > just use normal stable OpenBSD. > > I'd argue that the pain of figuring out what is the GPE and > adding a config line is uncomparable to the cost of the current > experience right now. > > For example due to the use of > current, the application I am developing right now suddenly > broke with "unable to allocate page guard" purely after > another kernel+base+xenocara rebuild (that gook many hours). > I don't know where to even look for the problem. > This ruins otherwise perfect OpenBSD experience.
On a related note, I've posted a question in the Intel community forum, feel free to comment https://community.intel.com/t5/Intel-NUCs/APCI-GPE-0x6F-Interrupt-Storm-under-OpenBSD/td-p/1426755 Thanks, Igor.
