Bug 1022051 - dmesg: microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin
dmesg: microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-22 10:41 EDT by Orca Lonsdale
Modified: 2013-10-30 06:24 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-30 06:24:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg for the F18 Live CD kernel (60.17 KB, text/plain)
2013-10-24 15:28 EDT, Orca Lonsdale
no flags Details
rpm grep kernel with the F18 Live CD (189 bytes, text/plain)
2013-10-24 15:29 EDT, Orca Lonsdale
no flags Details
F19Live dmesg (58.99 KB, text/plain)
2013-10-24 15:30 EDT, Orca Lonsdale
no flags Details
kernel F19 Live CD (187 bytes, text/plain)
2013-10-24 15:31 EDT, Orca Lonsdale
no flags Details
F19 Up2Date dmesg (2.43 MB, text/plain)
2013-10-24 15:32 EDT, Orca Lonsdale
no flags Details
F19 Up2Date kernel (336 bytes, text/plain)
2013-10-24 15:33 EDT, Orca Lonsdale
no flags Details

  None (edit)
Description Orca Lonsdale 2013-10-22 10:41:04 EDT
Description of problem: On a Toshiba C40D-A108 with A4-5000/HD8330/8GB Ram and Fedora 19, this is what dmesg comes up with.
(And as a consequence?) kvm: disabled by bios / No AGP bridge found

Version-Release number of selected component (if applicable):
kernel-3.11.4-201.fc19.x86_64


How reproducible:
Startup with newest kernel

Steps to Reproduce:
1. Install Fedora 19
2. Run $ sudo yum update
3. Restart

Actual results:
In dmesg: it says somewhere in time:
microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin

Expected results:
Not that error message

Additional info:
Latest microcode I *can* find is fam15h.bin on
http://www.amd64.org/microcode.html

I have no AGP bridge, IOMMU doesn't work, virtualisation doesn't work, laptop is slow 'as hell'! (unless I put kernelparm iommu=memaper=3 or iommu=noaperture. are those things related?)
Comment 1 Josh Boyer 2013-10-22 10:54:21 EDT
Does this start with a particular kernel, or has it always happened with any f19 kernel?

I'm not really sure the microcode error message is a result of your other issues.  Have you verified in the firmware that VT is enabled?

Can you attach the output of dmesg from a fresh boot (and dmesg from a "working" kernel if there is such a thing for you)?
Comment 2 Orca Lonsdale 2013-10-24 15:28:00 EDT
Created attachment 815902 [details]
dmesg for the F18 Live CD kernel
Comment 3 Orca Lonsdale 2013-10-24 15:29:29 EDT
Created attachment 815903 [details]
rpm grep kernel with the F18 Live CD
Comment 4 Orca Lonsdale 2013-10-24 15:30:21 EDT
Created attachment 815904 [details]
F19Live dmesg
Comment 5 Orca Lonsdale 2013-10-24 15:31:01 EDT
Created attachment 815905 [details]
kernel F19 Live CD
Comment 6 Orca Lonsdale 2013-10-24 15:32:01 EDT
Created attachment 815906 [details]
F19 Up2Date dmesg
Comment 7 Orca Lonsdale 2013-10-24 15:33:45 EDT
Created attachment 815907 [details]
F19 Up2Date kernel

F19 Up2Date = F19 install from netinstall.iso with most recent "sudo yum update".
Comment 8 Orca Lonsdale 2013-10-24 15:39:37 EDT
1. It has happened with F18Live, F19Live and F19current kernels, see attachments.

2. How do I 'verify in the firmware that VT is enabled'? The BIOS has no mention of virtualisation anywhere in its menus.
If the BIOS doesn't enable kvm, isn't it possible to let the linux boot process have it enabled?

3. see attachments.
Comment 9 Orca Lonsdale 2013-10-24 15:51:38 EDT
Searching for info on how to check 'firmware', I found
http://www.fclose.com/2497/how-to-find-out-the-firmware-version-in-linux/
which makes me think that with 'firmware' you ment 'BIOS':

# dmidecode -s bios-version
1.10

On the Toshiba website there's no BIOS update available.
http://pc.toshiba-asia.com/sg/support/drivers 
Notebook | Satellite | C40D | Windows 8 | serial# 5D149793C | BIOS
(the unit came from Singapore with Windows 8 pre-installed).

It strikes me as quite odd (and very disappointing) that Toshiba makes a notebook with an AMD 4A-5000 and then cripples it in such a way that it is *not* fit for virtualisation.
Comment 10 Orca Lonsdale 2013-10-24 18:37:16 EDT
Apparently the C40D is not 'crippled'. After installing (...cough) Windows 8 and running the tool 'Coreinfo.exe -v' it gives the output:

AMD A4-5000 APU with Radeon(TM) HD Graphics    
AMD64 Family 22 Model 0 Stepping 1, AuthenticAMD
HYPERVISOR	-	Hypervisor is present
SVM       	*	Supports AMD hardware-assisted virtualization
NP        	*	Supports AMD nested page tables (SLAT)
Comment 11 Orca Lonsdale 2013-10-27 16:10:35 EDT
Just adding some more observations:

The above listing of "Coreinfo.exe -v" shows that, although SVM and NP (SLAT) are available (*), the hypervisor is not present (-). This makes that one can only operate virtual machines through emulation.

In Windows 8 I found a 'built-in' way to check the availability of virtualization. Go to: 

"Start" | "System" | "Performance Information and Tools" | 
     "Advanced Tools" | "View advanced system details in System Information"

There it says:

Hyper-V - VM Monitor Mode Extensions                      Yes
Hyper-V - Second Level Address Translation Extensions     Yes
Hyper-V - Virtualization Enabled in Firmware              No
Hyper-V - Data Execution Protection                       Yes

So, it seems that although all conditions are favourable for virtualization, the people at Toshiba in their infinite wisdom decided to just disable it anyway.

So, is this even a bug at all?
Or should (if possible) the Linux kernel/firmware replace that piece of the BIOS firmware with one that enables virtualization? 
And was that maybe what amd-ucode/microcode_amd_fam16h.bin was (partly) intended for?
And does amd-ucode/microcode_amd_fam16h.bin even exist at all?
Comment 12 Josh Boyer 2013-10-28 09:19:09 EDT
(In reply to Orca Lonsdale from comment #11)
> So, is this even a bug at all?

Possibly for the slow performance if that issue is on the _host_, and not in a guest.  If it's in a guest, then no it isn't a bug.

> Or should (if possible) the Linux kernel/firmware replace that piece of the
> BIOS firmware with one that enables virtualization? 

The kernel cannot override that firmware setting.

> And was that maybe what amd-ucode/microcode_amd_fam16h.bin was (partly)
> intended for?

No.  That's just misleading.  A while ago, the AMD microcode loading in the kernel was changed to use a per-CPU family method.  Your CPU is in the 16h family (because it's new), so it tries to load that class of firmware if it exists.  It doesn't exist because AMD hasn't released any microcode updates for that family of CPU.

> And does amd-ucode/microcode_amd_fam16h.bin even exist at all?

Not that I'm aware of.  If it did, it would be provided by the microcode_ctl package (or linux-firmware package on newer releases of Fedora).
Comment 13 Orca Lonsdale 2013-10-30 06:24:42 EDT
So the hardware doesn't allow hardware virtualisation at all and this isn't a bug.
Thanks, and sorry, for your time.

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