http://bugzilla.kernel.org/show_bug.cgi?id=13751
--- Comment #25 from Bjorn Helgaas <[email protected]> 2009-07-24 23:00:21 --- Created an attachment (id=22482) --> (http://bugzilla.kernel.org/attachment.cgi?id=22482) patch to bind ACPI workqueue threads to CPU 0 In my limited testing, this patch was enough to avoid the crash. My testing showed that the crash happens when we run acpi_ev_notify_dispatch() or acpi_ev_asynch_execute_gpe_method() on CPU 1, so I suspect there's some AML that assumes it is running on CPU 0. There are several ways we might work around this, and I don't know what is best. This patch binds singlethread workqueues such as kacpid, kacpi_notify, and kacpi_hotplug to the current CPU when the workqueue is created. That might be nice for some drivers because a workqueue thread can be placed close to a device, but other applications might not want the thread bound to a CPU at all. Another approach would be to use set_cpus_allowed() to switch to CPU 0 inside acpi_os_execute_deferred(). That avoids the crash, too, but means more work on every deferred execution. And it would be nice to have a visible indication of this requirement so we don't accidentally break it in the future. I'll attach DMI information that we could use for some sort of quirk. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
