[Bug 678097] New: Deadlock after: ACPI Error: [CB04] Namespace lookup failure, AE_ALREADY_EXISTS
https://bugzilla.novell.com/show_bug.cgi?id=678097 https://bugzilla.novell.com/show_bug.cgi?id=678097#c0 Summary: Deadlock after: ACPI Error: [CB04] Namespace lookup failure, AE_ALREADY_EXISTS Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: x86 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: trenn@novell.com QAContact: qa@suse.de Found By: --- Blocker: --- Created an attachment (id=418291) --> (http://bugzilla.novell.com/attachment.cgi?id=418291) acpidump - I double checked dynamically loaded SSDT[2-5]s, CB04 only shows up in the \_SB_.AMW0.WMCA function in the DSDT User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10) Gecko/20110121 Firefox/4.0b10 On this machine the acpi wmi method \_SB_.AMW0.WMCA is called frequently (about every second?) when acer-wmi driver is loaded. acer-wmi driver exports software rfkill interfaces to switch off bluetooth/wlan. I could trigger this bug by doing: rfkill block 1 which I expect causes the WMCA function to get called in parallel triggering the issue. Acpica already points to a firmware bug (method must be defined NotSerialized?), the full error log I get is: ACPI Error: [CB04] Namespace lookup failure, AE_ALREADY_EXISTS (20101013/dsfield-143) ACPI Error: Method parse/execution failed [\_SB_.AMW0.WMCA] (Node ffff8800b8b034e8), AE_ALREADY_EXISTS (20101013/psparse-537) ACPI: Marking method WMCA as Serialized because of AE_ALREADY_EXISTS error This looks harmless and expected, but acpica seems to get stuck in a deadlock. The rfkill blocks and is not "killable", even not with -9. echo w >/proc/sysrq-trigger # (show-blocked-tasks(W)) reveals: SysRq : Show Blocked State task PC stack pid father worker/1:0 D 0000000000000001 0 8341 2 0x00000000 ffff880096413a40 0000000000000046 ffff8800964139e8 0000000000012640 ffff880096413fd8 0000000000012640 ffff880096413fd8 ffff880096413fd8 ffff880090f6e8b0 0000000000012640 0000000000012640 ffff880096412000 all Trace: [<ffffffff81521ffd>] schedule_timeout+0x28d/0x310 [<ffffffff81523035>] __down_timeout+0x65/0xb0 [<ffffffff8107f72c>] down_timeout+0x5c/0x70 [<ffffffff812ba026>] acpi_os_wait_semaphore+0x8e/0x130 [<ffffffff812d2373>] acpi_ex_system_wait_mutex+0x3b/0x84 [<ffffffff812c76a4>] acpi_ds_begin_method_execution+0xdf/0x16f [<ffffffff812df024>] acpi_ps_execute_method+0x39/0x2dd [<ffffffff812d90a3>] acpi_ns_evaluate+0x183/0x2c5 [<ffffffff812d89a9>] acpi_evaluate_object+0x158/0x298 [<ffffffffa01d5f85>] wmi_evaluate_method+0x115/0x150 [wmi] [<ffffffffa02a41ae>] WMI_execute_u32+0x4e/0xa0 [acer_wmi] [<ffffffffa02a4681>] get_u32+0x71/0xf0 [acer_wmi] [<ffffffffa02a4885>] acer_rfkill_update+0x35/0xa0 [acer_wmi] [<ffffffff81074630>] process_one_work+0x110/0x490 [<ffffffff81075345>] worker_thread+0x165/0x340 [<ffffffff81079956>] kthread+0x96/0xa0 [<ffffffff81003d74>] kernel_thread_helper+0x4/0x10 fkill D 0000000000000001 0 8780 6316 0x00000004 ffff8800adb0bad8 0000000000000082 000000000001c000 0000000000012640 ffff8800adb0bfd8 0000000000012640 ffff8800adb0bfd8 ffff8800adb0bfd8 ffff880037b4e6f0 0000000000012640 0000000000012640 ffff8800adb0a000 all Trace: [<ffffffff81521ffd>] schedule_timeout+0x28d/0x310 [<ffffffff81523035>] __down_timeout+0x65/0xb0 [<ffffffff8107f72c>] down_timeout+0x5c/0x70 [<ffffffff812ba026>] acpi_os_wait_semaphore+0x8e/0x130 [<ffffffff812d2373>] acpi_ex_system_wait_mutex+0x3b/0x84 [<ffffffff812c76a4>] acpi_ds_begin_method_execution+0xdf/0x16f [<ffffffff812df024>] acpi_ps_execute_method+0x39/0x2dd [<ffffffff812d90a3>] acpi_ns_evaluate+0x183/0x2c5 [<ffffffff812d89a9>] acpi_evaluate_object+0x158/0x298 [<ffffffffa01d5f85>] wmi_evaluate_method+0x115/0x150 [wmi] [<ffffffffa02a41ae>] WMI_execute_u32+0x4e/0xa0 [acer_wmi] [<ffffffffa02a424b>] WMID_set_u32+0x4b/0xf0 [acer_wmi] [<ffffffffa02a4389>] set_u32+0x99/0xc0 [acer_wmi] [<ffffffffa02a4486>] acer_rfkill_set+0x16/0x30 [acer_wmi] [<ffffffffa00e8f60>] rfkill_set_block+0x80/0x100 [rfkill] [<ffffffffa00e935f>] rfkill_fop_write+0x12f/0x150 [rfkill] [<ffffffff81152406>] vfs_write+0xc6/0x180 [<ffffffff8115271e>] sys_write+0x4e/0x90 [<ffffffff81002f8b>] system_call_fastpath+0x16/0x1b [<00007fd1a64280f0>] 0x7fd1a64280f0 Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c1
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c2
--- Comment #2 from Robert Moore
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c3
--- Comment #3 from Robert Moore
Just an idea (not looked at how complicated this would be), but if a function that creates fields (or similar objects) has to be set "Serialized", a compile time check could be added pointing to such (very nasty) firmware bugs?
I've opened an ACPICA bugzilla so that we can look at this suggestion. It would be nice to have iASL automatically mark the method serialized, perhaps with a warning or remark. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c4
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c5
Joey Lee
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c6
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=678097
https://bugzilla.novell.com/show_bug.cgi?id=678097#c7
Swamp Workflow Management
participants (1)
-
bugzilla_noreply＠novell.com