Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160833 - The /dev/cpu/microcode node required by the microcode_ctl initscript is not created
Summary: The /dev/cpu/microcode node required by the microcode_ctl initscript is not c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-utils
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
: 166210 (view as bug list)
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
 
Reported: 2005-06-17 18:39 UTC by Jean-Philippe Côté
Modified: 2015-01-04 22:20 UTC (History)
9 users (show)

Fixed In Version: RHBA-2005-534
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 14:41:58 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch for /etc/rc.d/init.d/microcode_ctl (deleted)
2005-06-28 22:06 UTC, James Ralston
no flags Details | Diff
patch for microde_ctl, checks sufficient delay (deleted)
2005-10-31 07:28 UTC, kamo
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:534 qe-ready SHIPPED_LIVE kernel-utils bug fix update 2005-10-05 04:00:00 UTC

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.


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