| |||||||||||||
Concurrency-managed workqueuesConcurrency-managed workqueuesPosted Oct 8, 2009 14:16 UTC (Thu) by nix (subscriber, #2304)Parent article: Concurrency-managed workqueues
The ACPI code had bound a workqueue thread to CPU 0 because some operations corrupt the system if run anywhere elseIs this just BIOSes being their usual malevolently incompetent selves, or is there a rational reason for this requirement? Because my first impression when reading this was 'WTF WTF WTF'...
(Log in to post comments)
Concurrency-managed workqueues Posted Oct 8, 2009 14:27 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
On some HPs, at least, certain ACPI operations trigger SMIs that then appear to be run on the CPU that triggered the SMI. HP's SMI handler seems to fail to restore CPU state if it runs on anything other than CPU 0.
Concurrency-managed workqueues Posted Oct 8, 2009 17:16 UTC (Thu) by mebrown (subscriber, #7960) [Link]
This is also true for Dell SMI implementation, so I'd assume that this is widely true or some kind of limitation of SMI. If you trigger a SMI from any CPU other than CPU #0, you get all kinds of interesting fireworks and possibly random memory locations overwritten.
Concurrency-managed workqueues Posted Oct 9, 2009 10:02 UTC (Fri) by nix (subscriber, #2304) [Link]
Ah. SMI. Malevolently incompetent by default, then. :/
(ACPI triggering SMI. What a nice way to take a kernel-controls-all VM executor and throw you into the undefeined-behaviour swamp again. Sigh.)
Concurrency-managed workqueues Posted Oct 19, 2009 0:13 UTC (Mon) by vonbrand (subscriber, #4458) [Link] "Simply Malevolently Incompetent"?
|
|||||||||||||