On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote: > the term "runaway ACPI" is not the best. What is probably happening > is a stuck interrupt. > > We continue to fight these. Some of them are BIOS bugs, some are > undocumented behaviours, sometimes AML parse errors in setting things > up, and potentially a few are due to incorrect resume sequencing. > The suspend/resume specification is weak, and getting even weaker as > time goes by and newer machines come out which are poorly tested by > even the mainstream OS vendors. > > Jonathan Thornburg <jthorn4...@gmail.com> wrote: > > > After more experimentation, I find that the runaway ACPI process occurs > > every time I suspend/resume (Fn-backspace). (The system resumes fine > > apart from the runaway ACPI process.) > > > > Is there any to kill or reset the kernel ACPI process short of rebooting? > > /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. > > No you cannot kill kernel threads... > > > I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined > > in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything > > interesting. Are there any other particularly useful debugging things > > I should explore to help track down the problem? > > There are a few people who have experience with this. Maybe one of > them will mail you privately. >
If you build an ACPI_DEBUG kernel and zzz/un-zzz from the text console (not X), you might see what GPE is stuck. it will probably be spewing tons of debug output but maybe you can see which GPE it is. -ml
