From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karol Kozimor Subject: Re: [20030321] Failed to acquire semaphore Date: Tue, 25 Mar 2003 23:01:54 +0100 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <20030325220154.GA19516@hell.org.pl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Return-path: Content-Disposition: inline In-Reply-To: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: "Grover, Andrew" Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.org Thus wrote Grover, Andrew: > Hiya -- can you (or someone else experiencing the same problem - I know > there are a few) stick a WARN_ON(1) where that error message is > happening, and turn on CONFIG_KALLSYMS, so we can get a stack trace? Sure, here it goes (WARN_ONs inserted before the coresponding functions): #v+ Badness in acpi_os_wait_semaphore at drivers/acpi/osl.c:896 Call Trace: [] acpi_os_wait_semaphore+0x10c/0x1de [] acpi_ut_acquire_mutex+0x94/0x18c [] acpi_ut_trace+0x28/0x2c [] acpi_disable_gpe+0x31/0xa2 [] acpi_ec_gpe_handler+0x15/0x27 [] acpi_ev_gpe_dispatch+0x19e/0x1df [] acpi_ev_gpe_detect+0x174/0x17c [] acpi_ev_sci_xrupt_handler+0x37/0x4d [] acpi_irq+0xc/0xe [] handle_IRQ_event+0x38/0x5c [] acpi_irq+0x0/0xe [] do_IRQ+0x72/0xc8 [] common_interrupt+0x18/0x20 [] acpi_os_write_port+0x2d/0x47 [] acpi_hw_low_level_write+0xef/0xf9 [] acpi_ut_acquire_mutex+0xc0/0x18c [] acpi_hw_enable_gpe+0x43/0x48 [] acpi_enable_gpe+0x71/0xa7 [] acpi_ec_gpe_query+0xbf/0x122 [] acpi_os_execute_deferred+0x39/0x75 [] worker_thread+0x1a4/0x262 [] acpi_os_execute_deferred+0x0/0x75 [] default_wake_function+0x0/0x12 [] ret_from_fork+0x6/0x14 [] default_wake_function+0x0/0x12 [] worker_thread+0x0/0x262 [] kernel_thread_helper+0x5/0xb osl-0898 [24] os_wait_semaphore : Failed to acquire semaphore[cffec740|1|0], AE_TIME Badness in acpi_ut_acquire_mutex at drivers/acpi/utilities/utmisc.c:741 Call Trace: [] acpi_ut_acquire_mutex+0xf4/0x18c [] acpi_ut_trace+0x28/0x2c [] acpi_disable_gpe+0x31/0xa2 [] acpi_ec_gpe_handler+0x15/0x27 [] acpi_ev_gpe_dispatch+0x19e/0x1df [] acpi_ev_gpe_detect+0x174/0x17c [] acpi_ev_sci_xrupt_handler+0x37/0x4d [] acpi_irq+0xc/0xe [] handle_IRQ_event+0x38/0x5c [] acpi_irq+0x0/0xe [] do_IRQ+0x72/0xc8 [] common_interrupt+0x18/0x20 [] acpi_os_write_port+0x2d/0x47 [] acpi_hw_low_level_write+0xef/0xf9 [] acpi_ut_acquire_mutex+0xc0/0x18c [] acpi_hw_enable_gpe+0x43/0x48 [] acpi_enable_gpe+0x71/0xa7 [] acpi_ec_gpe_query+0xbf/0x122 [] acpi_os_execute_deferred+0x39/0x75 [] worker_thread+0x1a4/0x262 [] acpi_os_execute_deferred+0x0/0x75 [] default_wake_function+0x0/0x12 [] ret_from_fork+0x6/0x14 [] default_wake_function+0x0/0x12 [] worker_thread+0x0/0x262 [] kernel_thread_helper+0x5/0xb utmisc-0744 [23] ut_acquire_mutex : Thread 0 could not acquire Mutex [ACPI_MTX_Events] AE_TIME #v- As I said, it happens both on 2.4.21-pre5-acpi20030321, and 2.5.65-acpi20030321. It doesn't neither on vanilla 2.5.65 (but there's the GPE bug), nor on acpi20021212. HTH. Best regards, -- Karol 'sziwan' Kozimor sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en