Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932712AbZJ1Iab (ORCPT ); Wed, 28 Oct 2009 04:30:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932656AbZJ1Iaa (ORCPT ); Wed, 28 Oct 2009 04:30:30 -0400 Received: from borg.medozas.de ([188.40.89.202]:60157 "EHLO borg.medozas.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932652AbZJ1Iaa (ORCPT ); Wed, 28 Oct 2009 04:30:30 -0400 Date: Wed, 28 Oct 2009 09:30:33 +0100 (CET) From: Jan Engelhardt To: Yuhong Bao cc: macro@linux-mips.org, davej@redhat.com, linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com Subject: RE: [X86] Fix up silly i1586 boot message. In-Reply-To: Message-ID: References: <20080528165713.GA412@redhat.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1154 Lines: 26 On Wednesday 2009-10-28 04:08, Yuhong Bao wrote: > > >> Intel started it first with picking up a ridiculous number for the family >> ID for the P4 line. There is no technical justification for not keeping >> these numbers consecutive. Once one knows that there are 4 bits for the family field, 15 is not such a strange value - it is the last value, one could take it as "reserved, and look elsewhere". >[...] Intel has assigned family 7 for the original Itanium processor >[...] there was a bug in original NT 4 truncating family IDs >returned by CPUID [...] That would explain why Intel still shows an oldfashioned family=6 on many contemporary processors (e.g. core i7). BUT, AMD64 processors have family=15 "almost throughout", and so seem to have at least some Intel models. So that tells us that either NT4 works, or nobody uses NT4 on fam15s. -- 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/