ACPI-CA update patch for review
qhwt+dfly at les.ath.cx
Sun Jan 7 03:09:51 PST 2007
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
I also updated to use the most recent version of ACPI-CA code.
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).
More information about the Submit