NetBSD Problem Report #41289

From paul@whooppee.com  Mon Apr 27 16:21:58 2009
Return-Path: <paul@whooppee.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id AFC9863C166
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 27 Apr 2009 16:21:58 +0000 (UTC)
Message-Id: <20090427162157.C5C9359FE@quicky.whooppee.com>
Date: Mon, 27 Apr 2009 09:21:57 -0700 (PDT)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@gnats.NetBSD.org
Subject: usr.sbin/cpuctl does not correctly identify new Intel CPUs
X-Send-Pr-Version: 3.95

>Number:         41289
>Category:       bin
>Synopsis:       usr.sbin/cpuctl does not correctly identify new Intel CPUs
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pgoyette
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 27 16:25:00 +0000 2009
>Closed-Date:    Sun May 17 11:33:34 +0000 2009
>Last-Modified:  Mon May 18 19:45:07 +0000 2009
>Originator:     Paul Goyette
>Release:        NetBSD 5.99.11
>Organization:
-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
>Environment:


System: NetBSD quicky.whooppee.com 5.99.11 NetBSD 5.99.11 (QUICKY (ASUS M2N32 WS) 2009-04-26 02:32:52) #0: Sat Apr 25 21:32:40 PDT 2009 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/QUICKY amd64
Architecture: x86_64
Machine: amd64
>Description:
Newest Intel processors using 45nm technology have non-zero Extended
Model numbers, and therefore are not properly identified.  Currently,
this affects the Intel Atom (Ext Model 0x01, Model 0x0c), Core i7 (Ext
Model 0x01, Model 0x0A), and Xeon MP (Ext Model 0x01, Model 0x0D).

>How-To-Repeat:
Boot a Core i7 machine and observe
bolt:paul {102} cpuctl identify 0
Cannot bind to target CPU.  Output may not accurately describe the target.
Run as root to allow binding.

cpu0: Intel Pentium III Xeon (Cascades) (686-class), 2672.81 MHz, id 0x106a5
cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features 0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX>
cpu0: features 0xbfebfbff<FXSR,SSE,SSE2,SS,HTT,TM,SBF>
cpu0: features2 0x98e3bd<SSE3,DTES64,MONITOR,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE41,SSE42,POPCNT>
cpu0: features3 0x28100800<SYSCALL/SYSRET,XD,EM64T>
cpu0: "Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz"
cpu0: D-cache 32KB 64B/line 8-way
cpu0: DTLB 64 4KB entries 4-way
cpu0: Initial APIC ID 3
cpu0: Cluster/Package ID 0
cpu0: Core ID 1
cpu0: SMT ID 1
cpu0: family 06 model 0a extfamily 00 extmodel 01


>Fix:


>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: bin-bug-people->pgoyette
Responsible-Changed-By: pgoyette@NetBSD.org
Responsible-Changed-When: Mon, 27 Apr 2009 20:18:57 +0000
Responsible-Changed-Why:
I'm working on it.


From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel CPUs
Date: Tue, 28 Apr 2009 10:06:52 +1000

 hmm, i thought i send a PR about this already, but apparently not.

 this is an ugly patch i've been using... it needs work before i was
 even going to consider commiting it however..


 .mrg.


 Index: arch/i386.c
 ===================================================================
 RCS file: /cvsroot/src/usr.sbin/cpuctl/arch/i386.c,v
 retrieving revision 1.16
 diff -p -r1.16 i386.c
 *** arch/i386.c	16 Mar 2009 12:25:40 -0000	1.16
 --- arch/i386.c	28 Apr 2009 00:06:24 -0000
 *************** struct cpu_cpuid_nameclass {
 *** 133,139 ****
   		void (*cpu_setup)(struct cpu_info *);
   		void (*cpu_probe)(struct cpu_info *);
   		void (*cpu_info)(struct cpu_info *);
 ! 	} cpu_family[CPU_MAXFAMILY - CPU_MINFAMILY + 1];
   };

   static const struct x86_cache_info intel_cpuid_cache_info[] = INTEL_CACHE_INFO;
 --- 133,139 ----
   		void (*cpu_setup)(struct cpu_info *);
   		void (*cpu_probe)(struct cpu_info *);
   		void (*cpu_info)(struct cpu_info *);
 ! 	} cpu_family[CPU_MAXFAMILY - CPU_MINFAMILY + 1 /* XXX */ + 1];
   };

   static const struct x86_cache_info intel_cpuid_cache_info[] = INTEL_CACHE_INFO;
 *************** const struct cpu_cpuid_nameclass i386_cp
 *** 303,308 ****
 --- 303,323 ----
   			NULL,
   			intel_family_new_probe,
   			NULL,
 + 		},
 + 		/* Extended Model 1, Family 6 */
 + 		{
 + 			CPUCLASS_686,
 + 			{
 + 				0, 0, 0, 0, 0, 0, 0,
 + 				"Core2 (Yorkfield)",
 + 				0, 0, 
 + 				"Core2 (Wolfdale)",
 + 				0, 0, 0, 0, 0,
 + 				"Core2"	/* Default */
 + 			},
 + 			NULL,
 + 			intel_family_new_probe,
 + 			NULL,
   		} }
   	},
   	{
 *************** identifycpu(const char *cpuname)
 *** 1183,1189 ****
   {
   	const char *name, *modifier, *vendorname, *brand = "";
   	int class = CPUCLASS_386, i, xmax;
 ! 	int modif, family, model;
   	const struct cpu_cpuid_nameclass *cpup = NULL;
   	const struct cpu_cpuid_family *cpufam;
   	const char *feature_str[5];
 --- 1198,1204 ----
   {
   	const char *name, *modifier, *vendorname, *brand = "";
   	int class = CPUCLASS_386, i, xmax;
 ! 	int modif, family, model, extmodel;
   	const struct cpu_cpuid_nameclass *cpup = NULL;
   	const struct cpu_cpuid_family *cpufam;
   	const char *feature_str[5];
 *************** identifycpu(const char *cpuname)
 *** 1216,1221 ****
 --- 1231,1237 ----
   		family = CPUID2FAMILY(ci->ci_signature);
   		if (family < CPU_MINFAMILY)
   			errx(1, "identifycpu: strange family value");
 + 		extmodel = CPUID2EXTMODEL(ci->ci_signature);
   		model = CPUID2MODEL(ci->ci_signature);

   		for (i = 0; i < xmax; i++) {
 *************** identifycpu(const char *cpuname)
 *** 1242,1248 ****
   			cpu_vendor = cpup->cpu_vendor;
   			vendorname = cpup->cpu_vendorname;
   			modifier = modifiers[modif];
 ! 			if (family > CPU_MAXFAMILY) {
   				family = CPU_MAXFAMILY;
   				model = CPU_DEFMODEL;
   			} else if (model > CPU_MAXMODEL)
 --- 1258,1270 ----
   			cpu_vendor = cpup->cpu_vendor;
   			vendorname = cpup->cpu_vendorname;
   			modifier = modifiers[modif];
 ! 			if (cpu_vendor == CPUVENDOR_INTEL) {
 ! 				/* XXX */
 ! 				if (extmodel == 1 && family == 6) {
 ! 					family = CPU_MAXFAMILY + 1;
 ! 					model = CPUID2STEPPING(ci->ci_signature);
 ! 				}
 ! 			} else if (family > CPU_MAXFAMILY) {
   				family = CPU_MAXFAMILY;
   				model = CPU_DEFMODEL;
   			} else if (model > CPU_MAXMODEL)

From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@NetBSD.org
Cc: pgoyette@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel
 CPUs
Date: Mon, 27 Apr 2009 17:25:26 -0700 (PDT)

 On Tue, 28 Apr 2009, matthew green wrote:

 > The following reply was made to PR bin/41289; it has been noted by GNATS.
 >
 > From: matthew green <mrg@eterna.com.au>
 > To: gnats-bugs@NetBSD.org
 > Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 > Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel CPUs
 > Date: Tue, 28 Apr 2009 10:06:52 +1000
 >
 > hmm, i thought i send a PR about this already, but apparently not.
 >
 > this is an ugly patch i've been using... it needs work before i was
 > even going to consider commiting it however..

 Yeah, that's a bit ugly and it assumes that family 6 is the only one
 that will ever have extended models.

 I was thinking more along the lines of adding a pointer to the existing 
 entries.  This would point to an array of arbitrary number of

  	struct ext_model_names {
  		int ext_model;
  		const char *ext_name[MAX_MODEL];
  	}

 (with the end of array indicated by ext_model == 0).

 Then the probe routine can check the extended model (in pseudocode)

  	if (CPUID2EXTMODEL(xxx) != 0)
  		if (ext_model_ptr != NULL)
  			scan thru *ext_model_ptr for matching ext_model
  			select proper name
  		else
  			/* extended id, but no extension names */
  			use a default value
  	else
  		do-what-we-do-already



 >
 >
 > .mrg.
 >
 >
 > Index: arch/i386.c
 > ===================================================================
 > RCS file: /cvsroot/src/usr.sbin/cpuctl/arch/i386.c,v
 > retrieving revision 1.16
 > diff -p -r1.16 i386.c
 > *** arch/i386.c	16 Mar 2009 12:25:40 -0000	1.16
 > --- arch/i386.c	28 Apr 2009 00:06:24 -0000
 > *************** struct cpu_cpuid_nameclass {
 > *** 133,139 ****
 >   		void (*cpu_setup)(struct cpu_info *);
 >   		void (*cpu_probe)(struct cpu_info *);
 >   		void (*cpu_info)(struct cpu_info *);
 > ! 	} cpu_family[CPU_MAXFAMILY - CPU_MINFAMILY + 1];
 >   };
 >
 >   static const struct x86_cache_info intel_cpuid_cache_info[] = INTEL_CACHE_INFO;
 > --- 133,139 ----
 >   		void (*cpu_setup)(struct cpu_info *);
 >   		void (*cpu_probe)(struct cpu_info *);
 >   		void (*cpu_info)(struct cpu_info *);
 > ! 	} cpu_family[CPU_MAXFAMILY - CPU_MINFAMILY + 1 /* XXX */ + 1];
 >   };
 >
 >   static const struct x86_cache_info intel_cpuid_cache_info[] = INTEL_CACHE_INFO;
 > *************** const struct cpu_cpuid_nameclass i386_cp
 > *** 303,308 ****
 > --- 303,323 ----
 >   			NULL,
 >   			intel_family_new_probe,
 >   			NULL,
 > + 		},
 > + 		/* Extended Model 1, Family 6 */
 > + 		{
 > + 			CPUCLASS_686,
 > + 			{
 > + 				0, 0, 0, 0, 0, 0, 0,
 > + 				"Core2 (Yorkfield)",
 > + 				0, 0,
 > + 				"Core2 (Wolfdale)",
 > + 				0, 0, 0, 0, 0,
 > + 				"Core2"	/* Default */
 > + 			},
 > + 			NULL,
 > + 			intel_family_new_probe,
 > + 			NULL,
 >   		} }
 >   	},
 >   	{
 > *************** identifycpu(const char *cpuname)
 > *** 1183,1189 ****
 >   {
 >   	const char *name, *modifier, *vendorname, *brand = "";
 >   	int class = CPUCLASS_386, i, xmax;
 > ! 	int modif, family, model;
 >   	const struct cpu_cpuid_nameclass *cpup = NULL;
 >   	const struct cpu_cpuid_family *cpufam;
 >   	const char *feature_str[5];
 > --- 1198,1204 ----
 >   {
 >   	const char *name, *modifier, *vendorname, *brand = "";
 >   	int class = CPUCLASS_386, i, xmax;
 > ! 	int modif, family, model, extmodel;
 >   	const struct cpu_cpuid_nameclass *cpup = NULL;
 >   	const struct cpu_cpuid_family *cpufam;
 >   	const char *feature_str[5];
 > *************** identifycpu(const char *cpuname)
 > *** 1216,1221 ****
 > --- 1231,1237 ----
 >   		family = CPUID2FAMILY(ci->ci_signature);
 >   		if (family < CPU_MINFAMILY)
 >   			errx(1, "identifycpu: strange family value");
 > + 		extmodel = CPUID2EXTMODEL(ci->ci_signature);
 >   		model = CPUID2MODEL(ci->ci_signature);
 >
 >   		for (i = 0; i < xmax; i++) {
 > *************** identifycpu(const char *cpuname)
 > *** 1242,1248 ****
 >   			cpu_vendor = cpup->cpu_vendor;
 >   			vendorname = cpup->cpu_vendorname;
 >   			modifier = modifiers[modif];
 > ! 			if (family > CPU_MAXFAMILY) {
 >   				family = CPU_MAXFAMILY;
 >   				model = CPU_DEFMODEL;
 >   			} else if (model > CPU_MAXMODEL)
 > --- 1258,1270 ----
 >   			cpu_vendor = cpup->cpu_vendor;
 >   			vendorname = cpup->cpu_vendorname;
 >   			modifier = modifiers[modif];
 > ! 			if (cpu_vendor == CPUVENDOR_INTEL) {
 > ! 				/* XXX */
 > ! 				if (extmodel == 1 && family == 6) {
 > ! 					family = CPU_MAXFAMILY + 1;
 > ! 					model = CPUID2STEPPING(ci->ci_signature);
 > ! 				}
 > ! 			} else if (family > CPU_MAXFAMILY) {
 >   				family = CPU_MAXFAMILY;
 >   				model = CPU_DEFMODEL;
 >   			} else if (model > CPU_MAXMODEL)
 >
 >

 -------------------------------------------------------------------------
 |   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
 | Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
 | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
 | Kernel Developer |                          | pgoyette at netbsd.org  |
 -------------------------------------------------------------------------

From: ad@netbsd.org
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel CPUs
Date: Tue, 28 Apr 2009 08:26:33 +0000

 One thing stikes me about this. If we get a text string out of the CPU, why
 bother trying to pretty-print further?

From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@NetBSD.org
Cc: pgoyette@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel
 CPUs
Date: Tue, 28 Apr 2009 04:52:29 -0700 (PDT)

 On Tue, 28 Apr 2009, ad@netbsd.org wrote:

 > One thing stikes me about this. If we get a text string out of the CPU, why
 > bother trying to pretty-print further?

 Hmm, good question.  I'd always thought that the text string was 
 actually loaded into the CPU by BIOS, but I just checked the spec, and 
 that doesn't seem to be true.  (Maybe it is true for AMD processors, I 
 really don't know anymore.)  Regardless, as I see it, we've always tried 
 to make our own determination.


 -------------------------------------------------------------------------
 |   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
 | Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
 | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
 | Kernel Developer |                          | pgoyette at netbsd.org  |
 -------------------------------------------------------------------------

From: matthew green <mrg@eterna.com.au>
To: ad@netbsd.org
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel CPUs
Date: Wed, 29 Apr 2009 03:00:39 +1000

    One thing stikes me about this. If we get a text string out of the CPU, why
    bother trying to pretty-print further?


 yes please :-)



 .mrg.

From: matthew green <mrg@eterna.com.au>
To: paul@whooppee.com
Cc: pgoyette@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
    gnats-bugs@NetBSD.org
Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel CPUs
Date: Wed, 29 Apr 2009 07:02:04 +1000


    > One thing stikes me about this. If we get a text string out of the CPU, why
    > bother trying to pretty-print further?

    Hmm, good question.  I'd always thought that the text string was 
    actually loaded into the CPU by BIOS, but I just checked the spec, and 
    that doesn't seem to be true.  (Maybe it is true for AMD processors, I 
    really don't know anymore.)  Regardless, as I see it, we've always tried 
    to make our own determination.


 my reading of the intel or amd manual a month or so ago said that
 the bios is expected to load 48 chars for the cpuid string.  i don't
 recall which off hand, but i think intel.


 .mrg.

From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: re: bin/41289: usr.sbin/cpuctl does not correctly identify new Intel
 CPUs
Date: Tue, 28 Apr 2009 14:15:00 -0700 (PDT)

 On Tue, 28 Apr 2009, matthew green wrote:

 >    > One thing stikes me about this. If we get a text string out of the CPU, why
 >    > bother trying to pretty-print further?
 >
 >    Hmm, good question.  I'd always thought that the text string was
 >    actually loaded into the CPU by BIOS, but I just checked the spec, and
 >    that doesn't seem to be true.  (Maybe it is true for AMD processors, I
 >    really don't know anymore.)  Regardless, as I see it, we've always tried
 >    to make our own determination.
 >
 >
 > my reading of the intel or amd manual a month or so ago said that
 > the bios is expected to load 48 chars for the cpuid string.  i don't
 > recall which off hand, but i think intel.

 Actually, I recall that same expectation, but it was from reading the 
 AMD manuals a long time ago (when I got my first AMD Famile 10h CPU).

 The Intel manual seems somewhat unclear on how those 48-bytes get 
 loaded.

 Regardless, I'm in the process of test-compiling a first-draft update 
 that will

 1. Properly identify the Extended Models within a family
 2. Properly identify several new Intel cache descriptors (including
     some that are 6-way, 12-way, and 24-way associative!)
 3. Split the Intel features2 line to avoid excessive line length

 It should be ready for review later tonight or early tomorrow.

 Suggestions for which list(s) on which I should post the request-for- 
 review would be appreciated!  This is a /usr/sbin utility, but might 
 more reasonably fit into tech-kern than tech-user?


 -------------------------------------------------------------------------
 |   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
 | Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
 | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
 | Kernel Developer |                          | pgoyette at netbsd.org  |
 -------------------------------------------------------------------------

State-Changed-From-To: open->analyzed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Tue, 28 Apr 2009 23:29:50 +0000
State-Changed-Why:
I have a fix, pending comment/review on tech-userlevel@


From: Paul Goyette <pgoyette@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41289 CVS commit: src
Date: Wed, 13 May 2009 22:25:51 +0000

 Module Name:	src
 Committed By:	pgoyette
 Date:		Wed May 13 22:25:51 UTC 2009

 Modified Files:
 	src/sys/arch/x86/include: cacheinfo.h specialreg.h
 	src/usr.sbin/cpuctl/arch: i386.c

 Log Message:
 1. Extend CPU probe of Intel processors to handle extended-models.  This
    allows us to properly identify new Intel 45nm processors, Core i7,
    Atom, and the 45nm Xeon MP.

 2. Properly decode several new Intel cache descriptors, as listed in the
    most recent (March 2009) edition of Intel's Application Note 485.

 3. Convert decode of the various features masks to use the newly added
    snprintb_m(3) routine.

 Addresses my PR bin/41289
 Addresses my PR bin/41290


 To generate a diff of this commit:
 cvs rdiff -u -r1.10 -r1.11 src/sys/arch/x86/include/cacheinfo.h
 cvs rdiff -u -r1.33 -r1.34 src/sys/arch/x86/include/specialreg.h
 cvs rdiff -u -r1.17 -r1.18 src/usr.sbin/cpuctl/arch/i386.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: analyzed->closed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Sun, 17 May 2009 11:33:34 +0000
State-Changed-Why:
Fixed.


From: Manuel Bouyer <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41289 CVS commit: [netbsd-5] src
Date: Mon, 18 May 2009 19:43:56 +0000

 Module Name:	src
 Committed By:	bouyer
 Date:		Mon May 18 19:43:56 UTC 2009

 Modified Files:
 	src/sys/arch/x86/include [netbsd-5]: cacheinfo.h
 	src/usr.sbin/cpuctl/arch [netbsd-5]: i386.c

 Log Message:
 Pull up following revision(s) (requested by pgoyette in ticket #761):
 	sys/arch/x86/include/cacheinfo.h: revisions 1.11, 1.12
 	usr.sbin/cpuctl/arch/i386.c: revisions 1.18, 1.19 via patch
 1. Extend CPU probe of Intel processors to handle extended-models.  This
     allows us to properly identify new Intel 45nm processors, Core i7,
     Atom, and the 45nm Xeon MP.
 2. Properly decode several new Intel cache descriptors, as listed in the
     most recent (March 2009) edition of Intel's Application Note 485.
 Addresses my PR bin/41289
 Addresses my PR bin/41290


 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.9.8.1 src/sys/arch/x86/include/cacheinfo.h
 cvs rdiff -u -r1.13.2.2 -r1.13.2.3 src/usr.sbin/cpuctl/arch/i386.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search