Bug 145608 – microcode_ctl uses wrong device path

Bug 145608 - microcode_ctl uses wrong device path

Summary:	microcode_ctl uses wrong device path

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 4
Classification:	Red Hat
Component:	kernel-utils (Show other bugs)
Sub Component:
Version:	4.0
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Dave Jones
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:	137160
	Show dependency tree / graph

Reported:	2005-01-19 20:53 EST by blbooth
Modified:	2015-01-04 17:15 EST (History)
CC List:	7 users (show)

See Also:
Fixed In Version:	RHBA-2005-229
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-06-09 08:26:15 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)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description blbooth 2005-01-19 20:53:11 EST

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-19 23:12:30 EST

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 04:19:06 EST

ok, back to /dev/cpu/0/microcode then...

Comment 3 Dave Jones 2005-01-20 14:06:13 EST

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 10:08:25 EST

2.4-13.1.56 should have this fixed.

Comment 8 Brock Organ 2005-03-08 17:25:59 EST

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 17:45:59 EST

fixed in .60 (building now)

Comment 10 Jay Turner 2005-03-17 09:29:58 EST

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 08:44:02 EDT

Verified in U1. The bug is fixed.

Comment 13 Tim Powers 2005-06-09 08:26:15 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-229.html

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