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.
