ACPICA: Convert acpi_gbl_hardware lock back to an acpi_raw_spinlock
We hit the following bug with -RT: |BUG: scheduling while atomic: swapper/7/0/0x00000002 |Pid: 0, comm: swapper/7 Not tainted 3.6.11-rt28.19.el6rt.x86_64.debug #1 |Call Trace: | rt_spin_lock+0x16/0x40 | __schedule_bug+0x67/0x90 | __schedule+0x793/0x7a0 | acpi_os_acquire_lock+0x1f/0x23 | acpi_write_bit_register+0x33/0xb0 | rt_spin_lock_slowlock+0xe5/0x2f0 | acpi_idle_enter_bm+0x8a/0x28e … As the acpi code disables interrupts in acpi_idle_enter_bm, and calls code that grabs the acpi lock, it causes issues as the lock is currently in RT a sleeping lock. The lock was converted from a raw to a sleeping lock due to some previous issues, and tests that showed it didn't seem to matter. Unfortunately, it did matter for one of our boxes. This patch converts the lock back to a raw lock. I've run this code on a few of my own machines, one being my laptop that uses the acpi quite extensively. I've been able to suspend and resume without issues. [ tglx: Made the change exclusive for acpi_gbl_hardware_lock ] Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1360765565.23152.5.camel@gandalf.local.homeSigned-off-by: Thomas Gleixner <tglx@linutronix.de> [bigeasy: shorten the backtrace, use the type acpi_raw_spinlock incl. accessor] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Showing
Please register or sign in to comment