Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754730AbYK0VoB (ORCPT ); Thu, 27 Nov 2008 16:44:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753115AbYK0Vns (ORCPT ); Thu, 27 Nov 2008 16:43:48 -0500 Received: from terminus.zytor.com ([198.137.202.10]:46624 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753008AbYK0Vnr (ORCPT ); Thu, 27 Nov 2008 16:43:47 -0500 Message-ID: <492F1462.4020803@zytor.com> Date: Thu, 27 Nov 2008 13:42:58 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Arjan van de Ven CC: Ingo Molnar , Yinghai Lu , Linux Kernel Mailing List , Linus Torvalds , NetDev , x86@kernel.org, Andrew Morton , "Theodore Ts'o" , Alan Cox , jesse Barnes Subject: Re: oops/warning report for the week of November 26, 2008 References: <492DD792.6080302@linux.intel.com> <20081127115236.GE29013@elte.hu> <492EE087.80708@linux.intel.com> <20081127201836.GA16869@elte.hu> <20081127122800.45fc0b1a@linux.intel.com> In-Reply-To: <20081127122800.45fc0b1a@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1470 Lines: 38 Arjan van de Ven wrote: > > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c > index 1159e26..0044e61 100644 > --- a/arch/x86/kernel/cpu/mtrr/main.c > +++ b/arch/x86/kernel/cpu/mtrr/main.c > @@ -1567,6 +1567,8 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn) > * Make sure we only trim uncachable memory on machines that > * support the Intel MTRR architecture: > */ > + if (!cpu_has_mtrr) > + return 0; > if (!is_cpu(INTEL) || disable_mtrr_trim) > return 0; > rdmsr(MTRRdefType_MSR, def, dummy); Okay... is_cpu() here is defined as: #define is_cpu(vnd) (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd) ... so an MTRR interface has been identified. Therefore testing cpu_has_mtrr is redundant. As far as use_intel() versus is_cpu(INTEL), it looks to me as though the two are identical in the current code -- mtrr_if->vendor is never set in the generic code, and so defaults to 0 - meaning X86_VENDOR_INTEL. All in all, it looks like the vendor ID stuff is a bad case of "works by accident" in the MTRR code, however, *given the current code* I conclude that is_cpu(INTEL) == use_intel() and that neither can be true without MTRRs enabled. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/