Bug 542215 - firmware.sh is out of step with microcode-ctl
Summary: firmware.sh is out of step with microcode-ctl
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-28 21:55 UTC by Michael Breuer
Modified: 2010-06-25 11:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-25 11:49:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Proposed firmware.sh (823 bytes, text/plain)
2010-01-05 13:04 UTC, Harald Hoyer
no flags Details

Description Michael Breuer 2009-11-28 21:55:39 UTC
Description of problem:

modprobe microcode results in error messages:

Nov 28 16:32:14 mail kernel: microcode: CPU0 sig=0x106a5, pf=0x2, revision=0x11
Nov 28 16:32:14 mail kernel: platform microcode: firmware: requesting intel-ucode/06-1a-05

(repeat for each cpu).

microcode_ctl -f <file> may or may not be loading the correct file - there is no easy way to see.

A few obvious issues:

1) microcode-ctl intel firmware is stored generically in /lib/firmware/microcode.dat. firmware.sh is looking for intel-ucode/06-1a-05 in various places including /lib/firmware.
2) Assuming you've got the correct microcode stored in /lib/intel-ucode/06-1a-05, the script then tries to set the 'loading" indicator at /sys/devices/platform/microcode/firmware/microcode/loading. That doesn't exist. Looking at the kernel driver, it doesn't look like it's even used anymore.

When I comment out the "loading" lines and override the FIRMWARE variable with /lib/firmware/microcode.dat and then modprobe microcode, I get log messages that suggest success:

Nov 28 16:52:47 mail kernel: microcode: CPU0 sig=0x106a5, pf=0x2, revision=0x11
Nov 28 16:52:47 mail kernel: platform microcode: firmware: requesting intel-ucode/06-1a-05

repeated for each cpu

Version-Release number of selected component (if applicable):
udev-147-2.fc13.x86_64

Was also true for fc12 versions - dk about 11.
How reproducible:
totally

Comment 1 Harald Hoyer 2010-01-05 12:56:38 UTC
1) the kernel requests the file, so it should be present in the file system with that name. Maybe a softlink should be provided by the package which provides micocode.dat.

2) I will fix the script to test for the existence of the "loading" file first.

Comment 2 Harald Hoyer 2010-01-05 13:04:43 UTC
Created attachment 381748 [details]
Proposed firmware.sh

Please add a symlink to the firmware file in /lib/firmware and test this firmware.sh script, if it fixes your problems.

Comment 3 Michael Breuer 2010-02-04 19:13:13 UTC
Fixed - however now that the firmware is found, the loading is unacceptably slow.

There are at least two other bugs open for that, so I'd say let's close this one.

The others:

https://bugzilla.redhat.com/show_bug.cgi?id=561824
https://bugzilla.redhat.com/show_bug.cgi?id=560031

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Bug Zapper 2010-03-15 13:22:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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