Hi all, In terms of finding issues like this, might it be worth adding a dynamic trace point in this section of code so people could more easily identify what acpi interrupt is being called so often.
Then the user could make their own patch, or if openBSD decides to implement a way of dynamically masking troublesome ones on specific platforms like these NUC or similar devices? Cheers On Thu, 19 Jan 2023, 06:51 Theo de Raadt, <dera...@openbsd.org> wrote: > Remco <re...@dpub.nl> wrote: > > > On 1/16/23 03:01, Bradley Latus wrote: > > > Hello Stuart, > > > I noticed that someone else had a similar issue on the openbsd-bugs > > > list.. > > > https://marc.info/?l=openbsd-bugs&m=166497715729842&w=2 > > > I was able to apply a patch I found from another user (Joe Miller) > > > which masks out > > > GPE_L6F messages and the problem was resolved. > > > https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365 > > > https://news.ycombinator.com/item?id=33279037 > > > After applying his patch (removing the additional printing parts) > > > My system was restored to what should be expected. > > > > > > > I can confirm the issue, cpu0 mainly busy with something ACPI related, > > cpu1 spinning a lot, the whole system being slow, barely usable. > > > > Applying the patch to mask/ignore the offending interrupt appears to > > solve the problem for me. > > that's great, we'll commit this diff and break ten times as many other > machines that use that specific pin for a different reason > >
