Re: ACPI-CA update patch for review

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Wed, Nov 29, 2006 at 09:14:18AM -0800, Matthew Dillon wrote:
> 
> :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.

Ok, I shouldn't unmap the tables returned by AcpiGetTableByIndex, as well
as those by AcpiGetTable.  Fixed it as
  http://lead.dragonflybsd.org/~y0netan1/acpi-20060912-15.diff

> :- 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.
> 
>     You could probably use tokens here, but a critical section ought to
>     work as well since ACPI functions are only called from cpu #0.

Does that apply to ioctl or sysctl support code, too?  Can you shed
some light on me to find how it's guaranteed?

Thanks.