Description of problem: Loading the microcode kernel module creates /dev/microcode and the symlink /dev/cpu/microcode, but /etc/init.d/microcode_ctl looks for /dev/cpu/0/microcode, and then exits when the device isn't found. Changing DEVICE in /etc/init.d/microcode_ctl fixes the problem. Steps to Reproduce: 1. modprobe microcode 2. /etc/init.d/microcode_ctl start Actual results: /etc/init.d/microcode_ctl: microcode device /dev/cpu/0/microcode doesn't exist? Additional info: Confirmed on two different single CPU systems (Celeron-Mendocino and Pentium Pro)
harald, microcode_ctl is the *only* thing that uses this dev node, so this can't break anything else -- Can we kill the symlinks, and just put the device nodes directly in the directories please ? sidenote: this does actually work fine for me, so I've no idea why it broke in testing, but the current behaviour is clearly suboptimal. I can only think that the /dev/microcode was something that we shipped many many years ago, but as I mentioned above, nothing else uses it, so we don't need to worry about back compatability. The correct location would be /dev/cpu/microcode, which is a) what we've done in FC4, and b) what is set upstream. However if we change to that, we'll also have to do a kernel-utils errata in parallel.
ok, back to /dev/cpu/0/microcode then...
just to be sure we're on the same page -- /dev/cpu/microcode is fine for FC4 and should stay that way. Sadly I didn't get to make the necessary changes in RHEL4 before we froze.
2.4-13.1.56 should have this fixed.
this doesn't to appear to be fixed in kernel-utils-2.4-13.1.57, as /etc/init.d/microcode_ctl still shows: > DEVICE=/dev/cpu/0/microcode instead of expected (from comment #1): > DEVICE=/dev/cpu/microcode ... changing status to FAILS_QA ...
fixed in .60 (building now)
Fix confirmed with kernel-utils-2.4-13.1.61 which is included in the latest U1 builds.
Verified in U1. The bug is fixed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-229.html