This thread has 'drifted' from bfs to microcode.
I posted a PS about this on another post to the lkml crowd, and just got this reply:
> >Just a note: the intel microcode is loaded by a kernel-initiated
> >firmware request these days. There is no (broken) init script on
> >recent systems, to (rather mindlessly) fiddle around in userspace with
> >kernel internals.
> That has to be a good deal in general, but it leaves us AMD users swinging
> in a strong breeze. That microcode loading was in the kernel until sometime
> in the 2.6.20ish time frame, I can recall scanning dmesg's where it was
> loaded by about line 75 in past history. Now its just an afterthought.
Well, I don't know what your script does but it should simply
$ modprobe microcode
and the module should figure it out itself which microcode to load,
So, since it doesn't hurt to do it all over again, I tried that, and got this in dmsg:
microcode: CPU0: patch_level=0x01000083
microcode: CPU1: patch_level=0x01000083
microcode: CPU2: patch_level=0x01000083
microcode: CPU3: patch_level=0x01000083
microcode: Microcode Update Driver: v2.00 <email@example.com
>, Peter Oruba
So that whole /etc/init.d/microcode_ctl script can be blown away and replaced with:
and it should Just Work(TM) on all x86 like architectures.
I see that the mods to my own script were blown away, and replaced with what looked like the original code just in the last 24 hours by synaptic but I haven't rebooted to see if it worked. Dubious since the cause of the failure, the check for kernel minor version >29, has been reinstated. I nuked it all in favor of the above 2 liner.
I seems to me that this 'microcode_ctl' is some sort of an attempt to reinvent the wheel that has already been better invented.