From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: XenServer Xen-4.5 (-rc3ish) testing Date: Tue, 9 Dec 2014 10:33:35 +0000 Message-ID: <5486CFFF.7080400@citrix.com> References: <5485F5F7.6040206@citrix.com> <5486C4FB020000780004DFBF@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5486C4FB020000780004DFBF@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List List-Id: xen-devel@lists.xenproject.org On 09/12/14 08:46, Jan Beulich wrote: >> We have certain machines which are showing reliable failure to boot >> under Xen-4.5, where they worked with 4.4. Symptoms range from the dom0 >> kernel crashing before printing anything, to complaining that the initrd >> is corrupt when attempting to decompress. This appears to be hardware >> specific. > Any chance this is C-state related, just like narrowed down to for > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html? > I.e. Westmere Xeons being affected? If not, this would seem rather > worrying to me (read: a release blocker). And even if so, a workaround > would be minimally needed. Otoh you didn't report so for earlier RCs - > was that just because the testing scope was more narrow then, or can > we imply that this is a recently introduced regression? > > Jan > I very much doubt it. We blanket set max cstate to 1 on that era of hardware, because the existing workarounds in Xen still experimentally don't work. https://github.com/xenserver/xen-4.4.pg/blob/master/detect-nehalem-c-state.patch The first system I am looking at with a view to fixing is a SandyBridge EN IBM Blade. ~Andrew