On Sun, Oct 30, 2022 at 11:04 AM Paul de Weerd <we...@weirdnet.nl> 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.
