Messages in this thread |  | | | Date | Wed, 6 Aug 2008 17:56:20 +0200 | | From | "Dmitry Adamushko" <> | | Subject | Re: [patch 3/5] [PATCH 3/5] x86: Run Intel ucode-updates via workqueue. |
| |
2008/8/6 Arjan van de Ven <arjan@infradead.org>: > On Wed, 6 Aug 2008 17:21:20 +0200 > Peter Oruba <peter.oruba@amd.com> wrote: > > [ no description or reason ] > > Why is this?
More details are available here.
I've also suggested to do ucode-updates as early as possible from start_secondary() (or whatever low-level code).
The second patch (do via workqueue) was just a proof-of-concept (to show that it does fix a crash).
> > I'm not very happy about this.. it means practically that this stuff > *has* to run late. Probably later than we want to.
Currently, it runs from cpu-hotplug-notifier(CPU_ONLINE, ...) [ and crashes with .26+ due to a reason you may find via the aforementioned link ] - by this moment, at least kernel threads may running on this cpu -- so it's not that early.
> (Like.. we may want to redo the microcode during resume.. which is > not a schedulable context)
I'm not sure what's "schedulable context" here terms but the existing code makes use of set_cpus_allowed_ptr() which means a caller expects to be able to be migrated onto a target cpu and do ucode-update while running on it.
Moreover, the way set_cpus_allowed_ptr() is used there seems to be race wrt. sched_setaffinity().
-- Best regards, Dmitry Adamushko
|  |