9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 06/11/2012 10:50 Tom Lislegaard said the following:
> No problem, I'm happy to assist in debugging this.
> 
> Enabling the acpi debugging quickly fills the kernel message buffer, but it seems to be the same set of messages 
> repeating again and again so I think this is representative
> 
> https://dl.dropbox.com/u/13263820/debug_dmesg.txt

This didn't clarify things as much as I hoped, but I am inclined to think that it
is polling from userland that triggers all the processor notifications.

In any case, here is a patch to try:
http://people.freebsd.org/~avg/acpi_cpu-stable.diff

Please disable all the tunings added to loader.conf during debugging when testing
this patch.

The patch is a combination of two changes:

1.
Do not needlessly use ever-increasing resource IDs.
Rather use the IDs that are tied to Cx level IDs.
Also, release previous resources upon _CST change.

2.
Bind a thread that processes a processor _CST change notification to the target
processor and perform _CST processing in a critical section.  These should ensure
the following:
- the CPU doesn't enter an idle state and doesn't try to use Cx level parameters
  while they are being changed
- Cx level parameters are never concurrently modified when multiple notifications
  fire in a rapid succession and multiple ACPI task threads are configured
sched_bind is a heavy-weight operation, but it is OK in this context because
processor notifications should not occur too often

> And, btw, thanks for your efforts.

Thank you for all the excellent debugging and testing!

P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally.
-- 
Andriy Gapon