From hatanou@ryoko.infolab.ne.jp  Thu Jan  5 01:47:38 2006
Return-Path: <hatanou@ryoko.infolab.ne.jp>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6B9ED16A41F
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  5 Jan 2006 01:47:38 +0000 (GMT)
	(envelope-from hatanou@ryoko.infolab.ne.jp)
Received: from ryoko.infolab.ne.jp (okbnat.infolab.ne.jp [210.166.231.67])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EB77943D7C
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  5 Jan 2006 01:47:27 +0000 (GMT)
	(envelope-from hatanou@ryoko.infolab.ne.jp)
Received: from ryoko.infolab.ne.jp (localhost [127.0.0.1])
	by ryoko.infolab.ne.jp (8.13.4/8.13.4) with ESMTP id k051lOSN000866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 5 Jan 2006 10:47:24 +0900 (JST)
	(envelope-from hatanou@ryoko.infolab.ne.jp)
Received: (from hatanou@localhost)
	by ryoko.infolab.ne.jp (8.13.4/8.13.4/Submit) id k051lOpZ000865;
	Thu, 5 Jan 2006 10:47:24 +0900 (JST)
	(envelope-from hatanou)
Message-Id: <200601050147.k051lOpZ000865@ryoko.infolab.ne.jp>
Date: Thu, 5 Jan 2006 10:47:24 +0900 (JST)
From: HATANOU Tomomi <hatanou@infolab.ne.jp>
Reply-To: HATANOU Tomomi <hatanou@infolab.ne.jp>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: L2/L3 cache of some IA32 CPUs not properly recognized.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         91328
>Category:       i386
>Synopsis:       [identcpu] [patch] L2/L3 cache of some IA32 CPUs not properly recognized.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    netchild
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 05 01:50:06 GMT 2006
>Closed-Date:    Fri Mar 03 18:55:35 GMT 2006
>Last-Modified:  Fri Mar 03 18:55:35 GMT 2006
>Originator:     HATANOU Tomomi
>Release:        FreeBSD 7.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD ryoko.infolab.ne.jp 7.0-CURRENT FreeBSD 7.0-CURRENT #13: Thu Jan 5 09:51:40 JST 2006 hatanou@ryoko.infolab.ne.jp:/usr/local/obj/usr/src/sys/CF-R3E i386
Machine:
1) Panasonic CF-R3E (Pentium-M 733 based micro notebook)
2) ASUS P2B-D with 2 x 700MHz Pentium-III

>Description:
As far as I know,

1) Pentium-M 733 (dothan core, ULV)
  L2 cache is not recognized.

2) Pentium-III w/ 256k L2
  L2 cache size is wrongly recognized as 128k.

>How-To-Repeat:
Boot verbosely, or view vm.stats.pagequeue.* sysctl variables.

>Fix:
Apply this patch to src/sys/i386/i386/identput.c

--- /sys/i386/i386/identcpu.c.orig	Tue Jan  3 23:43:38 2006
+++ /sys/i386/i386/identcpu.c	Thu Jan  5 10:33:46 2006
@@ -1344,6 +1344,12 @@
 	case 0x45:
 		printf("\n2nd-level cache: 2-MB, 4-way set associative, 32 byte line size");
 		break;
+	case 0x46:
+		printf("\n3rd-level cache: 4-MB, 4-way set associative, 64 byte line size");
+		break;
+	case 0x47:
+		printf("\n3rd-level cache: 8-MB, 8-way set associative, 64 byte line size");
+		break;
 	case 0x50:
 		printf("\nInstruction TLB: 4-KB, 2-MB or 4-MB pages, fully associative, 64 entries");
 		break;
@@ -1383,6 +1389,9 @@
 	case 0x72:
 		printf("\nTrace cache: 32K-uops, 8-way set associative");
 		break;
+	case 0x78:
+		printf("\n2nd-level cache: 1-MB, 4-way set associative, 64-byte line size");
+		break;
 	case 0x79:
 		printf("\n2nd-level cache: 128-KB, 8-way set associative, sectored cache, 64-byte line size");
 		break;
@@ -1395,6 +1404,12 @@
 	case 0x7c:
 		printf("\n2nd-level cache: 1-MB, 8-way set associative, sectored cache, 64-byte line size");
 		break;
+	case 0x7d:
+		printf("\n2nd-level cache: 2-MB, 8-way set associative, 64-byte line size");
+		break;
+	case 0x7f:
+		printf("\n2nd-level cache: 512-KB, 2-way set associative, 64-byte line size");
+		break;
 	case 0x82:
 		printf("\n2nd-level cache: 256-KB, 8-way set associative, 32 byte line size");
 		break;
@@ -1591,6 +1606,30 @@
 			*ways = 4;
 		}
 		break;
+	case 0x46:
+		/* 3rd-level cache: 4-MB, 4-way set associative,
+		 * 64 byte line size */
+		if (*size < 4096) {
+			*size = 4096;
+			*ways = 4;
+		}
+		break;
+	case 0x47:
+		/* 3rd-level cache: 8-MB, 8-way set associative,
+		 * 64 byte line size */
+		if (*size < 8192) {
+			*size = 8192;
+			*ways = 8;
+		}
+		break;
+	case 0x78:
+		/* 2nd-level cache: 1-MB, 4-way set associative,
+		 * 64-byte line size */
+		if (*size < 1024) {
+			*size = 1024;
+			*ways = 4;
+		}
+		break;
 	case 0x79:
 		/* 2nd-level cache: 128-KB, 8-way set associative,
 		 * sectored cache, 64-byte line size */
@@ -1623,11 +1662,27 @@
 			*ways = 8;
 		}
 		break;
+	case 0x7d:
+		/* 2nd-level cache: 2-MB, 8-way set associative,
+		 * 64-byte line size */
+		if (*size < 2048) {
+			*size = 2048;
+			*ways = 8;
+		}
+		break;
+	case 0x7f:
+		/* 2nd-level cache: 512-KB, 2-way set associative,
+		 * 64-byte line size */
+		if (*size < 512) {
+			*size = 512;
+			*ways = 2;
+		}
+		break;
 	case 0x82:
 		/* 2nd-level cache: 256-KB, 8-way set associative,
 		 * 32 byte line size */
-		if (*size < 128) {
-			*size = 128;
+		if (*size < 256) {
+			*size = 256;
 			*ways = 8;
 		}
 		break;

>Release-Note:
>Audit-Trail:

From: Alexander Leidinger <netchild@FreeBSD.org>
To: bug-followup@FreeBSD.org, hatanou@infolab.ne.jp
Cc:  
Subject: Re: i386/91328: [identcpu] [patch] L2/L3 cache of some IA32 CPUs
 not properly recognized.
Date: Sun, 5 Feb 2006 17:31:16 +0100

 Hi,
 
 the patch contains "3rd-level" entries. Is this a typo or by purpose?
 
 If yes, I'm not sure if the page coloring algorithm was designed to be
 tuned to the 3rd-level cache size or not. It's not unreasonable to
 think it was designed for the highest cache level, but I don't know.
 
 The 0x82 case (patch: cache size 128 -> 256) is already done in current
 independently from your submission.
 
 Bye,
 Alexander.
 
 -- 
            Intel: where Quality is job number 0.9998782345!
 http://www.Leidinger.net                       Alexander @ Leidinger.net
   GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
 WL http://www.amazon.de/exec/obidos/registry/1FZ4DTHQE9PQ8/ref=wl_em_to/

From: HATANOU Tomomi <hatanou@infolab.ne.jp>
To: Alexander Leidinger <netchild@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, hatanou@infolab.ne.jp
Subject: Re: i386/91328: [identcpu] [patch] L2/L3 cache of some IA32 CPUs not properly recognized.
Date: Mon, 06 Feb 2006 11:00:47 +0900

 Hi, thank you for your response.
 
 >the patch contains "3rd-level" entries. Is this a typo or by purpose?
 
 Not typos, but I haven't any specific purpose.
 
 I simply added lacked entries seeing intel AP-485
 document without much thought, because identcpu.c 1.154
 already had 3rd-level cache entry, such as 0x22 case.
 
 I'm not familiar with page colouring algorithm.
 If these L3 entries are harmful, please ignore them.
 
 cf.
 Intel Processor Identification and the CPUID Instruction
   Application Note 485
 http://developer.intel.com/design/xeon/applnots/241618.htm
 
 Oh, now I can see this document is updated on January
 2006.  More new descriptors are defined...
 --
 HATANOU Tomomi.
State-Changed-From-To: open->closed 
State-Changed-By: netchild 
State-Changed-When: Fri Mar 3 18:55:02 UTC 2006 
State-Changed-Why:  
Committed. Thanks. 


Responsible-Changed-From-To: freebsd-i386->netchild 
Responsible-Changed-By: netchild 
Responsible-Changed-When: Fri Mar 3 18:55:02 UTC 2006 
Responsible-Changed-Why:  
Committed. Thanks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=91328 
>Unformatted:
