Bug 117301
Summary: | Could not insert kvm_intel on dual Xeon X5355 | ||
---|---|---|---|
Product: | Virtualization | Reporter: | piotr.pejas |
Component: | kvm | Assignee: | virtualization_kvm |
Status: | NEW --- | ||
Severity: | normal | CC: | hmh |
Priority: | P1 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 3.10.0-327.13.1.el7.x86_64, 4.5.2-1.el7.elrepo.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | cpuinfo dmesg |
Description
piotr.pejas
2016-04-27 11:05:10 UTC
Same result on latest kernel: # uname -a Linux XXX 4.5.2-1.el7.elrepo.x86_64 #1 SMP Wed Apr 20 15:17:10 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux You have a mixed-stepping hardware configuration: signatures 0x6f7 -- stepping B3 and 0x6fb -- stepping G0. I was not even aware this was a supported configuration, although re-reading the exact language in the data sheet for the Xeon 5300, it *is* supported. However, a Google search found an Intel Product Change Notification, numbers PCN 107893-00 and PCN 107467-00, which are *quite clear* that it is indeed supported, *but that it requires an updated BIOS and microcode on both processors*. It is not just the microcode, the BIOS has to set some MSR registers on the processors to enable cross-stepping compatibility (likely it dumbs down the 0x6fb one). So, there you have it: the motherboard BIOS did not initialize the microcode of the 0x6fb processor (it is at revision 0), therefore it seems safe to assume it does not support your hardware configuration. Update that BIOS. After you do that, you also need to ensure the Linux early microcode update will also attempt to update that second processor: from the logs, it is being updated too late (by the late microcode update). Ensure both microcode updates are present in the early initramfs created by dracut... if it still doesn't work, we have a bug in the Linux early microcode loader. Now, I have to fix some userspace that mistakenly assumes such mixed-stepping configurations are illegal... (iucode-tool, I don't think it is used by Fedora, RHEL and CentOS, though). Thank you for your attention to this matter. I have latest BIOS. Unfortunately I can not find CHANGELOG so I don't know if G0 steeping (SLAEG) is supported and does what is needed for proper initialization. DMI: Apple Computer, Inc. MacPro2,1/Mac-F4208DC8, BIOS MP21.88Z.007F.B06.0707021348 07/02/07 I've got linux early microcode update to update both cpu's: # dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x6b, date = 2010-10-02 [ 0.056030] CPU1 microcode updated early to revision 0x6b, date = 2010-10-02 [ 0.068270] CPU2 microcode updated early to revision 0x6b, date = 2010-10-02 [ 0.081025] CPU3 microcode updated early to revision 0x6b, date = 2010-10-02 [ 0.093019] CPU4 microcode updated early to revision 0xbc, date = 2010-10-03 [ 0.170019] CPU5 microcode updated early to revision 0xbc, date = 2010-10-03 [ 0.187019] CPU6 microcode updated early to revision 0xbc, date = 2010-10-03 [ 0.204019] CPU7 microcode updated early to revision 0xbc, date = 2010-10-03 [ 0.710545] microcode: CPU0 sig=0x6f7, pf=0x40, revision=0x6b [ 0.710555] microcode: CPU1 sig=0x6f7, pf=0x40, revision=0x6b [ 0.710565] microcode: CPU2 sig=0x6f7, pf=0x40, revision=0x6b [ 0.710577] microcode: CPU3 sig=0x6f7, pf=0x40, revision=0x6b [ 0.710588] microcode: CPU4 sig=0x6fb, pf=0x40, revision=0xbc [ 0.710600] microcode: CPU5 sig=0x6fb, pf=0x40, revision=0xbc [ 0.710611] microcode: CPU6 sig=0x6fb, pf=0x40, revision=0xbc [ 0.710623] microcode: CPU7 sig=0x6fb, pf=0x40, revision=0xbc [ 0.710670] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba via intel-ucode.img https://wiki.archlinux.org/index.php/microcode but problem persists: [ 103.470656] kvm: CPU 0 feature inconsistency! I will replace one CPU too match steeping of the second one, probably will go with G0 those are easily available and quiet inexpensive. Thank you. PS IMO we can close this bug |