Dmesg output at boot. Could not acquire Global Lock, AE_NO_GLOBAL_LOCK This is the stack trace: ACPI: Subsystem revision 20050408 [<c02584ae>] acpi_ev_acquire_global_lock+0x40/0x111 [<c026264d>] acpi_ex_acquire_global_lock+0x3f/0x85 [<c025b847>] acpi_ex_read_data_from_field+0x1a7/0x1fd [<c0267908>] acpi_ns_get_type+0x79/0x86 [<c02636ca>] acpi_ex_resolve_node_to_value+0x216/0x2f8 [<c025c4cd>] acpi_ex_resolve_to_value+0xad/0xf8 [<c0252f0d>] acpi_ds_get_predicate_value+0xb5/0x1fc [<c0271c93>] acpi_ut_trace_ptr+0x2c/0x30 [<c02536de>] acpi_ds_exec_end_op+0x4ae/0x530 [<c026aaf1>] acpi_ps_parse_loop+0x69e/0xa3e [<c026af50>] acpi_ps_parse_aml+0xbf/0x2cb [<c026b8e6>] acpi_psx_execute+0x1e2/0x290 [<c02673d9>] acpi_ns_execute_control_method+0xdf/0xfe [<c02672c5>] acpi_ns_evaluate_by_handle+0xe2/0x117 [<c026705b>] acpi_ns_evaluate_relative+0x14b/0x1a6 [<c0272092>] acpi_ut_evaluate_object+0x50/0x1ec [<c0250500>] acpi_os_wait_semaphore+0x184/0x196 [<c025a4de>] acpi_ev_match_prw_and_gpe+0x46/0x109 [<c02695fd>] acpi_ns_walk_namespace+0xc0/0x187 [<c025acfe>] acpi_ev_create_gpe_block+0x145/0x241 [<c025a498>] acpi_ev_match_prw_and_gpe+0x0/0x109 [<c02731ec>] acpi_ut_acquire_mutex+0x9c/0xe3 [<c025aeab>] acpi_ev_gpe_initialize+0xb1/0x226 [<c02569d5>] acpi_ev_initialize_events+0x8d/0xda [<c0273ae6>] acpi_enable_subsystem+0x127/0x18a [<c0715c10>] acpi_bus_init+0x35/0xdf [<c0715d30>] acpi_init+0x76/0xe8 [<c06fe8db>] do_initcalls+0x2b/0xc0 [<c07270aa>] sock_init+0x2a/0x40 [<c01002a0>] init+0x0/0x110 [<c01002cf>] init+0x2f/0x110 [<c0101378>] kernel_thread_helper+0x0/0x18 [<c010137d>] kernel_thread_helper+0x5/0x18 exutils-0229 [21] ex_acquire_global_lock: Could not acquire Global Lock, AE_NO_GLOBAL_LOCK evgpeblk-1016 [06] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x9 evgpeblk-1024 [06] ev_create_gpe_block : Found 7 Wake, Enabled 0 Runtime GPEs in this block
Created attachment 5595 [details] acpidmp output The error message is invoked when executing one _PRW method.
The _PRW methods are executed during GPE initialization, before the global lock support is initialized. Perhaps the solution will be to initialize the global lock (and enable SCI) before the GPE initialization. This will require further investigation.
I think we can move the initialization of the SCI and Global Lock to before the event initialization. We may need to be careful that all GPEs are disabled at the moment the SCI is enabled.
Looks like some code restructuring will be required. The new event initialization sequence will be something like below; note that the two key parts are 1) disabling of all events before SCI is enabled, and 2) enabling the Global Lock support before the _PRW methods are run and the GPE initialization is completed. Init all GPE/event data structures Disable (in HW) all GPEs and fixed events Install SCI handler, enable SCI (all events are disabled) Install global lock handler, enable GL event enable other appropriate fixed events run GPE _PRW methods enable appropriate GPEs
Fixed in 20051102: Modified the subsystem initialization sequence to improve GPE support. The GPE initialization has been split into two parts in order to defer execution of the _PRW methods (Power Resources for Wake) until after the hardware is fully initialized and the SCI handler is installed. This allows the _PRW methods to access fields protected by the Global Lock. This will fix systems where a NO_GLOBAL_LOCK exception has been seen during initialization.
ACPICA 20050127 shipped in Linux-2.6.16-rc1-git6 -- closing.
20060127 that is