ACPI-CA update patch for review

[Matthew Dillon]

:Some known issues:
:- a warning upon reboot which looks like this:
:
:  AcpiOsUnmapMemory: Warning, broken ACPI, bad unmap: 0xc5e1ee00/00000040
:
:  IIRC, I've never seen this before updating my patch from 20060707 to
:  20060912, so I may have done something stupid while dealing with the
:  changes with regard to Table Manager.  I'm investigating this.

    I added sanity checks to our AcpiOsMapMemory() and AcpiOsUnmapMemory()
    procedures.  The code tracks all requests and matches unmaps up against
    prior mappings.

:- hand-rolled locking code in AcpiOs{Acquire,Release}Lock() functions:
:  ACPI-CA code has been rewritten in 20060623 to make these functions
:  to be used as spinlock functions, and called from many places where
:  they weren't before.  Since our implementation of these locking functions
:  used lockmgr lock, which cannot be called from cpu_idle(), this led to
:  a panic(mainly when my laptop wakes up from sleep state).  After struggling
:  with other locking primitives, I ended up with critical section and
:  special-cased the idlethread.  I believed this shouldn't make the situation
:  worse, as ACPI functions called from cpu_idle_hook code in acpi_cpu did
:  not using locking before.  But I'm open to a better implementation,
:  especially how to deal with locking when called from idlethread.
:
:- new ACPI-CA code may be released soon, as 20060912 is more than 2-months
:  old now
:
:  absolutely :)
:
:Regards.

    You could probably use tokens here, but a critical section ought to
    work as well since ACPI functions are only called from cpu #0.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>