From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758210Ab0IGUEi (ORCPT ); Tue, 7 Sep 2010 16:04:38 -0400 Received: from terminus.zytor.com ([198.137.202.10]:42250 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754645Ab0IGUEg (ORCPT ); Tue, 7 Sep 2010 16:04:36 -0400 Message-ID: <4C869AA3.6000103@zytor.com> Date: Tue, 07 Sep 2010 13:03:47 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2 MIME-Version: 1.0 To: Peter P Waskiewicz Jr CC: Ingo Molnar , Andi Kleen , "tglx@linutronix.de" , "mingo@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: [PATCH] [arch-x86] Allow SRAT integrity check to be skipped References: <20100901213318.19353.54619.stgit@localhost.localdomain> <20100902065731.GB29972@elte.hu> <20100902100308.GA17167@basil.fritz.box> <20100903063934.GA25863@elte.hu> <1283888337.18468.9.camel@pjaxe> In-Reply-To: <1283888337.18468.9.camel@pjaxe> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/07/2010 12:38 PM, Peter P Waskiewicz Jr wrote: > > It's one SKU of a Nehalem-EX system. The BIOS for that SKU has an issue > with resolving SRAT hotplug enumeration, and screws up the table. Other > SKU's of this same platform do not have the issue. Efforts are underway > to get this BIOS fixed, but in the meantime, there's nothing for users > to work around the bug (aside from disabling memory hotplug in the > BIOS). Another platform almost shipped with the same symptoms, but > caught it and had it fixed before it shipped (didn't catch it early > because Windows wasn't failing, and most of the testing on that platform > was done under Windows). > > I agree with Andi that adding DMI strings would be overkill and would > leave clutter once the BIOS is fixed. I look at this patch as a > stop-gap measure for people to fall back on until a newer BIOS is > available to correct the NUMA enumeration issues. Without it, we have > nothing to point users to when they run into this, waiting for a new > BIOS. > No, this is exactly the kind of stuff for which a DMI match is ideal. A specific system with bounded propagation of the problem. Thus, the DMI match acts as a whitelist -- "we know this system and it is safe to activate this hack on it." This is a very good thing. If this is a production BIOS it should have this information. -hpa