On 26 May 2019 22:32:16 CEST, Mike Larkin <[email protected]> wrote: >On Sun, May 26, 2019 at 09:03:51PM +0200, Tristan Pilat wrote: >> On 26 May 2019 19:33:12 CEST, Mike Larkin <[email protected]> >wrote: >> >On Sun, May 26, 2019 at 12:00:55PM +0200, Tristan Pilat wrote: >> >> Hello OpenBSD devs! >> >> >> >> To follow up on my email to misc@, here is a bug report with the >> >thinkpad x280 running May 23rd snapshot. I'm experiencing a >slowlyness >> >problem that turns out to be related to acpi. >> >> >> >> A top -S shows an acpi0 process spinning using more than 300% of >CPU >> >making the system very slow and unusable. >> >> >> >> That said by the time I'm writing this mail I just woke the system >up >> >and everything is working smoothly. The end of the dmesg shows this >> >though : >> >> >> >> acpivideo0: unknown event 0x00 >> >> ugen0 detached >> >> umb0 detached >> >> ucom0 detached >> >> umodem0 detached >> >> sd1 detached >> >> scsibus2 detached >> >> umass0 detached >> >> uhub0 detached >> >> Starting stack trace... >> >> tsleep(ffff8000005a3460,0,ffffffff81ab9e9d,64) at tsleep+0x5b >> >> pckbc_enqueue_cmd(ffffffff81daa560,1,ffff80001ef9b03f,1,0,1) at >> >> pckbc_enqueue_cmd+0x21c >> >> pms_change_state(ffff8000005a3c00,2,0) at pms_change_state+0x1b4 >> >> pmsactivate(ffff8000005a3c00,3) at pmsactivate+0x3d >> >> config_activate_children(ffff8000005a8b80,3) at >> >> config_activate_children+0x72 >> >> pckbc_isa_activate(ffff8000005a8b80,3) at pckbc_isa_activate+0x32 >> >> config_activate_children(ffff8000005a3800,3) at >> >> config_activate_children+0x72 >> >> config_activate_children(ffff80000058f880,3) at >> >> config_activate_children+0xb9 >> >> config_activate_children(ffff8000001f5500,3) at >> >> config_activate_children+0xb9 >> >> pciactivate(ffff8000001f5500,3) at pciactivate+0x37 >> >> config_activate_children(ffff80000003c100,3) at >> >> config_activate_children+0x72 >> >> config_suspend_all(3) at config_suspend_all+0x1b6 >> >> acpi_sleep_state(ffff80000003a400,1) at acpi_sleep_state+0x1e5 >> >> acpi_sleep_task(ffff80000003a400,1) at acpi_sleep_task+0x20 >> >> acpi_thread(ffff8000001dfb20) at acpi_thread+0x1a8 >> >> end trace frame: 0x0, count: 242 >> >> End of stack trace. >> >> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" >rev >> >> 3.00/1.00 addr 1 >> >> ugen0 at uhub0 port 3 "Generic EMV Smartcard Reader" rev 2.01/1.20 >> >addr >> >> 2 >> >> usbd_free_xfer: xfer=0xfffffd8281ce01e0 not free >> >> >> > >> >Why do you claim this is ACPI related? Because it says >> >'acpi_sleep_state' in the >> >scrollback? That's just calling the device wakeup/suspend routines >and >> >has >> >really nothing to do with ACPI. >> >> I thought so because the acpi0 process was using about 300% of the >CPU all the time and after that crash my system got back reactivity. I >may be mistaken though. >> >> What could explain this behavior then? >> > >Sounds like an interrupt storm. There have been a bunch of threads >describing >this and what some people did to work around the issue (related to >thunderbolt) >in tech@/misc@ in the past year or so.
I'll have a look then, thanks and sorry for the noise. -- Tristan
