Red Hat Bugzilla – Bug 193241
Microcode device /dev/cpu/microcode doesn't exist?
Last modified: 2007-11-30 17:11:33 EST
Description of problem: > service microcode_ctl start Applying Intel CPU microcode update: /etc/init.d/microcode_ctl: microcode device /dev/cpu/microcode doesn't exist? > And yepp, the script is correct: > ls -l /dev/cpu* ls: /dev/cpu*: No such file or directory > WHY is this the case?! CPU is: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 3.06GHz stepping : 9 cpu MHz : 3066.228 cache size : 512 KB [...] Version-Release number of selected component (if applicable): microcode_ctl-1.13-1.30 How reproducible: Everytime, see above. Actual results: Microcode device /dev/cpu/microcode doesn't exist. Expected results: Existing microcode device /dev/cpu/microcode or similar ;-) Additional info: Maybe this bug is assigned to the wrong component, reassign to kernel, udev or whatever fits if needed - thank you.
I need to know the version of the kernel that you are running this against so that I can try to track down why that device does not exist. Please let me know.
2.6.17-1.2293_FC6 - which is pretty old now. But it was up2date when I wrote this bug report...
It seems that the microcode module is not created in fc6. Something might have changed since fc5 to make the decision to remove the module? config-2.6.18-1.2798.fc6: # CONFIG_MICROCODE is not set config-2.6.20-1.2933.fc6: # CONFIG_MICROCODE is not set
PING?
This is a potential bug in the kernel config. Both in xen and non-xen kernels (in the case of Xen, the hypervisor needs a fix to do microcode updates...and even then, it's implemented incorrectly wrt. how it should be done in Xen, but that requires a complete re-architecting of Xen itself to fix). Jon.
Well...it isn't of belong to me. Novell has microcode_ctl working with and without Xen, so why aren't we able? I'm not sure, what you would like to hear from me but: This is no notabug, no cantfix, no wontfix...but: Assigned :)
Yes, but it's not a bug in the microcode package. It's a "bug" in the kernel/hypervisor. Note that I'm not saying it doesn't work, I'm saying that the Xen implementation of microcode updates is known to be insufficient in the longer term - it works, but I've been told that, once the CPU is in VT mode, that you should not be trying to update the microcode after that...it should be done in the hypervisor well before booting the first DomU or even Dom0. It's not a Novell-vs-RedHat thing. It's just that Xen will need some tweaking in future to handle this IMO. Jon.
$ grep CONFIG_MICROCODE /boot/config-2.6.23-0.157.rc4.git2 CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y $