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 <[email protected]> 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.
