Bug 145608 - microcode_ctl uses wrong device path
Summary: microcode_ctl uses wrong device path
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-utils   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 137160
TreeView+ depends on / blocked
 
Reported: 2005-01-20 01:53 UTC by blbooth
Modified: 2015-01-04 22:15 UTC (History)
7 users (show)

Fixed In Version: RHBA-2005-229
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-09 12:26:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:229 normal SHIPPED_LIVE kernel-utils bug fix update 2005-06-09 04:00:00 UTC

Description blbooth 2005-01-20 01:53:11 UTC 
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)
Comment 1 Dave Jones 2005-01-20 04:12:30 UTC 
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.
Comment 2 Harald Hoyer 2005-01-20 09:19:06 UTC 
ok, back to /dev/cpu/0/microcode then...
Comment 3 Dave Jones 2005-01-20 19:06:13 UTC 
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.
Comment 5 Dave Jones 2005-02-18 15:08:25 UTC 
2.4-13.1.56 should have this fixed.
Comment 8 Brock Organ 2005-03-08 22:25:59 UTC 
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 ...
Comment 9 Dave Jones 2005-03-08 22:45:59 UTC 
fixed in .60 (building now)
Comment 10 Jay Turner 2005-03-17 14:29:58 UTC 
Fix confirmed with kernel-utils-2.4-13.1.61 which is included in the latest U1
builds.
Comment 12 Evgeny Larin 2005-04-26 12:44:02 UTC 
Verified in U1. The bug is fixed.
Comment 13 Tim Powers 2005-06-09 12:26:15 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-229.html
Note You need to log in before you can comment on or make changes to this bug.