Bug 160833 - The /dev/cpu/microcode node required by the microcode_ctl initscript is not created
The /dev/cpu/microcode node required by the microcode_ctl initscript is not c...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-utils (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
: 166210 (view as bug list)
Depends On:
Blocks: 156322
  Show dependency treegraph
 
Reported: 2005-06-17 14:39 EDT by Jean-Philippe Côté
Modified: 2015-01-04 17:20 EST (History)
9 users (show)

See Also:
Fixed In Version: RHBA-2005-534
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 10:41:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for /etc/rc.d/init.d/microcode_ctl (1.21 KB, patch)
2005-06-28 18:06 EDT, James Ralston
no flags Details | Diff
patch for microde_ctl, checks sufficient delay (340 bytes, patch)
2005-10-31 02:28 EST, kamo
no flags Details | Diff

  None (edit)
Description Jean-Philippe Côté 2005-06-17 14:39:23 EDT
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 14:47:35 EDT
A similar bug was reported for FedoraCore 3 (#157672). That's probably where the
problem stems from.
Comment 3 James Ralston 2005-06-28 18:06:55 EDT
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-13 22:20:50 EDT
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 16:59:09 EDT
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 11:02:25 EDT
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 15:24:39 EDT
I have a similar problem in FC4 (upgraded from FC3 if that is relevant).
Comment 13 Florin Andrei 2005-09-13 15:58:51 EDT
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 02:21:14 EDT
*** Bug 166210 has been marked as a duplicate of this bug. ***
Comment 15 Red Hat Bugzilla 2005-10-05 10:41:58 EDT
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 02:28:05 EST
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 18:59:57 EST
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.

Note You need to log in before you can comment on or make changes to this bug.