On Thu, Oct 06, 2022 at 11:49:52AM +0100, Igor Petruk wrote: > On Thu, Oct 6, 2022 at 10:04 AM Igor Petruk <[email protected]> wrote: > > > > On Wed, Oct 5, 2022 at 9:18 PM Mike Larkin <[email protected]> wrote: > > > > > > On Wed, Oct 05, 2022 at 12:55:33PM -0700, Mike Larkin wrote: > > > > On Wed, Oct 05, 2022 at 01:20:47PM +0100, [email protected] wrote: > > > > > >Synopsis: Intel NUC 11 is very slow, acpi0 kernel thread always > > > > > >take 100% > > > > > >Category: system, kernel, amd64 > > > > > >Environment: > > > > > System : OpenBSD 7.2 > > > > > Details : OpenBSD 7.2-current (GENERIC.MP) #767: Tue Oct 4 > > > > > 23:38:08 MDT 2022 > > > > > > > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > Architecture: OpenBSD.amd64 > > > > > Machine : amd64 > > > > > >Description: > > > > > The system is impossible to use, UI rendering lags in seconds. > > > > > The acpi0 is spinning even if no XOrg is running. > > > > > >How-To-Repeat: > > > > > Install OpenBSD on Intel NUC Gen 11, Core i7, Iris Xe > > > > > Graphics. > > > > > Working in console is tolerable, but any UI, including fvwm > > > > > is already lagging. > > > > > Gnome and XFce4 are almost frozen. Stable vs snapshot, > > > > > hyperthreading vs no, noatime - nothing helps much. > > > > > >Fix: > > > > > Not aware of any > > > > > > > > > > > > > Third time we've seen stuck GPEs in the last few weeks. > > > > > > > > Try changing this line in acpi_gpe_task: > > > > > > > > dnprintf(10, "handle gpe: %x\n", gpe); > > > > > > > > to > > > > printf("handle gpe: %x\n", gpe); > > > > > > > > and see what gpe is firing over and over. It will be in dmesg. > > > > > > > > Then maybe we can track it down. > > > > > > > > -ml > > > > > > After comparing the previous report and this, I'm certain they are the > > > same > > > and you're going to see 6F as the culprit. > > > > Thanks for looking into this. > > > > I've done it. You are right, it prints a bunch of 6Fs. The system is > > even slower, which is expected due to printing in the logs. >
Yes, that is expected. > I've looked at the previous threads on this issue. One explanation was > that it was a buggy hardware, e.g. cheap motherboard. In my case this > is Intel NUC. I've just upgraded the BIOS from Feb 2022 version to Aug > 16th, 2022 version from > https://www.intel.com/content/www/us/en/download/19698/bios-update-tntgl357.html. > > The problem persists. I've seen in other OSs there are indeed some > mitigations available, whether via writing to `/sys`, sysctl or kernel > boot options to block the interrupt. It might be a useful feature for > OpenBSD to mitigate issues like this until a proper fix on either side > (hardware or kernel) is implemented. > > Thanks, > Igor. > Yeah, maybe something like that.
