New: Could not insert kvm_intel on dual Xeon X5355

Bug 117301 [email protected] 1 participant 4 messages Apr 27, 2016 – Apr 29, 2016 KVM

Share & tools

[email protected]

author

2016-04-27 11:05 UTC #0 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=117301

            Bug ID: 117301
           Summary: Could not insert kvm_intel on dual Xeon X5355
           Product: Virtualization
           Version: unspecified
    Kernel Version: 3.10.0-327.13.1.el7.x86_64
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: kvm
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Created attachment 214541
--> https://bugzilla.kernel.org/attachment.cgi?id=214541&action=edit
cpuinfo dmesg

Hi,
I did fresh install of Centos7 on dual socket machine (Xeon X5355) to serve as kvm host. System is updated. kvm_intel is not loaded on boot.

# dmesg  | grep kvm
[   11.149589] kvm: CPU 0 feature inconsistency!
[   11.159752] kvm: CPU 3 feature inconsistency!
[   11.168591] kvm: CPU 3 feature inconsistency!
[   11.180506] kvm: CPU 3 feature inconsistency!
[   11.186351] kvm: CPU 3 feature inconsistency!

when I try to load it with modprobe I get:

# modprobe kvm_intel
modprobe: ERROR: could not insert 'kvm_intel': Input/output error

# lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 15
Model name:            Intel(R) Xeon(R) CPU           X5355  @ 2.66GHz
Stepping:              11
CPU MHz:               2659.993
BogoMIPS:              5320.04
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0-7

# grep 'model name' /proc/cpuinfo
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
model name : Intel(R) Xeon(R) CPU X5355 @ 2.66GHz

# dmesg  | grep microcode
[    0.000000] CPU0 microcode updated early to revision 0x6b, date = 2010-10-02
[    0.056027] CPU1 microcode updated early to revision 0x6b, date = 2010-10-02
[    0.068268] CPU2 microcode updated early to revision 0x6b, date = 2010-10-02
[    0.165019] CPU5 microcode updated early to revision 0x6b, date = 2010-10-02
[    0.692463] microcode: CPU0 sig=0x6f7, pf=0x40, revision=0x6b
[    0.692468] microcode: CPU1 sig=0x6f7, pf=0x40, revision=0x6b
[    0.692487] microcode: CPU2 sig=0x6f7, pf=0x40, revision=0x6b
[    0.692510] microcode: CPU3 sig=0x6fb, pf=0x40, revision=0x0
[    0.692521] microcode: CPU4 sig=0x6fb, pf=0x40, revision=0x0
[    0.692540] microcode: CPU5 sig=0x6f7, pf=0x40, revision=0x6b
[    0.692564] microcode: CPU6 sig=0x6fb, pf=0x40, revision=0x0
[    0.692575] microcode: CPU7 sig=0x6fb, pf=0x40, revision=0x0
[    0.692675] microcode: Microcode Update Driver: v2.00
<[email protected]>, Peter Oruba
[   16.138622] microcode: CPU3 sig=0x6fb, pf=0x40, revision=0x0
[   16.139616] microcode: CPU3 updated to revision 0xbc, date = 2010-10-03
[   16.145359] microcode: CPU4 sig=0x6fb, pf=0x40, revision=0x0
[   16.146348] microcode: CPU4 updated to revision 0xbc, date = 2010-10-03
[   16.150525] microcode: CPU6 sig=0x6fb, pf=0x40, revision=0x0
[   16.151520] microcode: CPU6 updated to revision 0xbc, date = 2010-10-03
[   16.155627] microcode: CPU7 sig=0x6fb, pf=0x40, revision=0x0
[   16.156622] microcode: CPU7 updated to revision 0xbc, date = 2010-10-03

Please let me know how I can be of more help

Best Regards
Piotr Pejas

Signature · 2 lines

You are receiving this mail because:
You are watching the assignee of the bug.

[email protected]

author

2016-04-27 11:55 UTC #1 lore raw

[Bug 117301] Could not insert kvm_intel on dual Xeon X5355

https://bugzilla.kernel.org/show_bug.cgi?id=117301

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------

     Kernel Version|3.10.0-327.13.1.el7.x86_64  |3.10.0-327.13.1.el7.x86_64,
                   |                            |4.5.2-1.el7.elrepo.x86_64

--- Comment #1 from [email protected] ---
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

Signature · 2 lines

You are receiving this mail because:
You are watching the assignee of the bug.

[email protected]

author

2016-04-28 16:51 UTC #2 lore raw

[Bug 117301] Could not insert kvm_intel on dual Xeon X5355

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=117301

Henrique de Moraes Holschuh <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #2 from Henrique de Moraes Holschuh <[email protected]> --- 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).

Signature · 2 lines

You are receiving this mail because:
You are watching the assignee of the bug.

[email protected]

author

2016-04-29 13:31 UTC #3 lore raw

[Bug 117301] Could not insert kvm_intel on dual Xeon X5355

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=117301

--- Comment #3 from [email protected] ---
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
<[email protected]>, 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

Signature · 2 lines

You are receiving this mail because:
You are watching the assignee of the bug.