| |||||||||||||
Concurrency-managed workqueuesConcurrency-managed workqueuesPosted Oct 8, 2009 14:27 UTC (Thu) by mjg59 (subscriber, #23239)In reply to: Concurrency-managed workqueues by nix Parent article: Concurrency-managed workqueues
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.
(Log in to post comments)
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"?
|
|||||||||||||