Bug 542215

Summary: firmware.sh is out of step with microcode-ctl
Product: [Fedora] Fedora Reporter: Michael Breuer <mbreuer>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: harald
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-25 07:49:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Proposed firmware.sh none

Description Michael Breuer 2009-11-28 16:55:39 EST 
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 07:56:38 EST 
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 08:04:43 EST 
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 14:13:13 EST 
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 09:22:57 EDT 
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