Maybe this is a kernel problem, not sure yet. but booting f14 on an AMD system yields some weird stuff in dmesg.. $ dmesg| grep microcode microcode: CPU0: patch_level=0x1000065 microcode: CPU0: updated (new patch_level=0x1000083) microcode: CPU1: patch_level=0x1000065 microcode: CPU1: updated (new patch_level=0x1000083) microcode: CPU2: patch_level=0x1000065 microcode: CPU2: updated (new patch_level=0x1000083) microcode: CPU3: patch_level=0x1000065 microcode: CPU3: updated (new patch_level=0x1000083) microcode: Microcode Update Driver: v2.00 <tigran.co.uk>, Peter Oruba microcode: AMD microcode update via /dev/cpu/microcode not supported microcode: AMD microcode update via /dev/cpu/microcode not supported microcode: AMD microcode update via /dev/cpu/microcode not supported microcode: AMD microcode update via /dev/cpu/microcode not supported microcode: AMD microcode update via /dev/cpu/microcode not supported So it succeeds, then fails 5 times. What's actually doing the loading since we killed the initscript ? udev ?
updates triggered by the udev -> loading kernel's microcode module. In order to patch the "weird stuff" kernel changes are needed. :)
ucode update on AMD is supported _only_ using the firmware loader interface. So you are right, after load of the AMD ucode module the update happened when the driver called request_firmware(). Using microcode_ctl and the /dev/cpu/microcode interface is not supported by the AMD microcode loader (and this is indicated by the kernel messages).
NOTABUG for user-space. AFAIK, related upstream kernel crew is aware of the problem.
The fix for this bug: (in rawhide/f15 already) --- microcode_ctl.rules.old 2011-07-21 10:08:07.897302300 +0200 +++ microcode_ctl.rules 2011-06-30 07:56:33.000000000 +0200 @@ -1,2 +1,2 @@ KERNEL=="cpu[0-9]*", ACTION=="add", RUN+="/sbin/modprobe microcode" -KERNEL=="microcode", ACTION=="add", RUN+="/sbin/microcode_ctl -Qu" +KERNEL=="devices/platform/microcode", ACTION=="add", RUN+="/sbin/microcode_ctl -Qu"