From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@bugzilla.kernel.org
Subject: [Bug 117301] Could not insert kvm_intel on dual Xeon X5355
Date: Thu, 28 Apr 2016 16:51:48 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
To: kvm@vger.kernel.org
Return-path:
Received: from mail.kernel.org ([198.145.29.136]:43693 "EHLO mail.kernel.org"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1751866AbcD1Qvw (ORCPT );
Thu, 28 Apr 2016 12:51:52 -0400
Received: from mail.kernel.org (localhost [127.0.0.1])
by mail.kernel.org (Postfix) with ESMTP id 2BF642034B
for ; Thu, 28 Apr 2016 16:51:51 +0000 (UTC)
Received: from bugzilla1.web.kernel.org (bugzilla1.web.kernel.org [172.20.200.51])
by mail.kernel.org (Postfix) with ESMTP id 551D3202F2
for ; Thu, 28 Apr 2016 16:51:49 +0000 (UTC)
In-Reply-To:
Sender: kvm-owner@vger.kernel.org
List-ID:
https://bugzilla.kernel.org/show_bug.cgi?id=117301
Henrique de Moraes Holschuh changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hmh@hmh.eng.br
--- Comment #2 from Henrique de Moraes Holschuh ---
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).
--
You are receiving this mail because:
You are watching the assignee of the bug.