|Summary:||The /dev/cpu/microcode node required by the microcode_ctl initscript is not created|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Jean-Philippe Côté <webmaster>|
|Component:||kernel-utils||Assignee:||Dave Jones <davej>|
|Status:||CLOSED ERRATA||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||brianm, cch1, dvd, jos, kamo, pb, pfrields, ralston, vvalenti|
|Fixed In Version:||RHBA-2005-534||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-10-05 14:41:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jean-Philippe Côté 2005-06-17 18:39:23 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: If I run the following command: service microcode_ctl start I get an error saying that /dev/cpu/microcode isn't available. This, most notably, happens at boot up. If I add the following lines to the initscript, everything works fine: mkdir -p `dirname $DEVICE` mknod -m 600 $DEVICE c 10 184 Version-Release number of selected component (if applicable): kernel-utils 2.4 13.1.66 How reproducible: Always Steps to Reproduce: service microcode_ctl start Additional info:
Comment 1 Jean-Philippe Côté 2005-06-17 18:47:35 UTC
A similar bug was reported for FedoraCore 3 (#157672). That's probably where the problem stems from.
Comment 3 James Ralston 2005-06-28 22:06:55 UTC
Created attachment 116092 [details] patch for /etc/rc.d/init.d/microcode_ctl Nope, that's not the problem. In RHEL4 U1, udev correctly creates the /etc/cpu/microcode device file when the microcode module is loaded. The problem is that /etc/rc.d/init.d/microcode_ctl tests for the presence of the device file *before* it attempts to modprobe the microcode module. As a result, if the microcode module isn't already loaded (and it won't be, if the system's booting up), /etc/rc.d/init.d/microcode_ctl doesn't find the /etc/cpu/microcode device file, and bombs out. Here's a patch for /etc/rc.d/init.d/microcode_ctl that fixes the problem. (I think this operation ordering makes the most sense.)
Comment 7 David Van Duzer 2005-07-14 02:20:50 UTC
I've tried this patch, but I am still getting the same microcode device /dev/cpu/microcode doesn't exist? error on boot. It seems there is a significant delay (more than 3 seconds) in udev creating the device files, so I'm making the script sleep for 4 seconds after the modprobe command. I'm sure there's a more efficient way to handle this. Using: udev-039-10.8.EL4 hotplug-2004_04_01-7.5
Comment 9 James Ralston 2005-08-19 20:59:09 UTC
I think the significant delay is startup-specific. If you run "modprobe microcode" on quiescent system, it only takes a fraction of a second for the device node to appear. Probably a better way to handle it is to keep running "usleep 250000" until the device node appears, with a reasonable timeout (e.g., 10 seconds) before aborting.
Comment 11 Peter Bieringer 2005-08-26 15:02:25 UTC
This happen to me also here on an RHEL4 system. 2 issues: 1) without the patch #116092, such message is been shown, without, it quits quietly which is ok, because it's an Athlon CPU. 2) related to #9: there is already a delay included in the script: lt=0 while [ ! -c $DEVICE ]; do lt=$[lt+1]; [ $lt -gt 5 ] && break; sleep 1; done Anyway, looks like since introducing udev and its asynchron device creation this rises up to a common problem, it hit me also loading a framebuffer module and try to execute fbset after the modprobe call in a script...
Comment 12 Chris Hapgood 2005-08-31 19:24:39 UTC
I have a similar problem in FC4 (upgraded from FC3 if that is relevant).
Comment 13 Florin Andrei 2005-09-13 19:58:51 UTC
I was able to fix this issue on FC4 by creating the executable file named /etc/sysconfig/modules/microcode.modules with the following content: #!/bin/sh /sbin/modprobe microcode After that microcode_ctl works fine when booting up.
Comment 14 Dave Jones 2005-09-14 06:21:14 UTC
*** Bug 166210 has been marked as a duplicate of this bug. ***
Comment 15 Red Hat Bugzilla 2005-10-05 14:41:58 UTC
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-534.html
Comment 16 kamo 2005-10-31 07:28:05 UTC
Created attachment 120554 [details] patch for microde_ctl, checks sufficient delay The delay of 5 seconds is insufficient on my Dell PowerEdge 1850 with RHEL ES4 update2 (includes kernel-utils-2.4-13.1.69). I tried several times with this patch, it needs 11 seconds.
Comment 17 Vince Valenti 2006-02-02 23:59:57 UTC
I also have a Dell PowerEdge 1850 and 5 seconds wasn't enough. With kamo's patch, I did three test boots and it took either 9 or 10 seconds. The 1850 has two Intel Xeon 3.2Ghz CPUs. I also have a PowerEdge 850 and it seems to work fine on that with the 5 second delay.