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.
