Re: ACPI-CA update patch for review

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Sat, Dec 02, 2006 at 12:17:14AM +0900, YONETANI Tomokazu wrote:
> On Fri, Dec 01, 2006 at 04:01:04PM +0900, YONETANI Tomokazu wrote:
> > > I copied by hand the ones i can see from boot -v with the options
> > > you suggested:
> > [dmesg output]
> > 
> > I'm afraid ACPI_LV_VERBOSE in debug.acpi.level wasn't enough to give us
> > extra information.  Can you use the following two lines instead of the
> > ones I wrote in the previous message?
> >   debug.acpi.layer="ACPI_TABLES ACPI_EVENTS ACPI_NAMESPACE"
> >   debug.acpi.level="ACPI_LV_FUNCTIONS ACPI_LV_INFO"
> > 
> > Judging from the dmesg output above and the one from older module, I think
> > it's in the middle of AcpiInitializeTables(); or one of calls to
> > AcpiInstallAddressSpaceHandler().  The "acpi_bus_number:" messages are
> > displayed during the third call to it.
> 
> Ok, I saw a similar lock up on a machine I haven't updated since October --
> before troubling your hand by writing down many function names, can you
> try rebuilding your acpi driver with an environment variable
> ACPI_USE_LOCAL_CACHE=yes ?

Turned out that an extra crit_exit() in objcache_reclaimlist() appears
to be the cause of this lock up, and the machine now boots up fine
without ACPI_USE_LOCAL_CACHE.
I also updated to use the most recent version of ACPI-CA code.
  http://les.ath.cx/DragonFly/acpi-20061109-17.diff

Still TODO items:
 - `can't fetch resources for XXXX - AE_TYPE` messages.
 - `AE_TIME, Could not acquire Global Lock` messages. (reported by victor@)
 - make AcpiOs*Lock() interface callable from interrupt context or
   idle thread (if possible).

Cheers.