From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 21:43:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8AA521065696; Fri, 27 Aug 2010 21:43:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 17:43:26 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> In-Reply-To: <4C782D3B.6020407@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271743.29393.jkim@FreeBSD.org> Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 21:43:37 -0000 On Friday 27 August 2010 05:25 pm, Andriy Gapon wrote: > on 27/08/2010 23:18 pluknet said the following: > > First, sorry for late replay, and thanks Andriy for kicking me ;) > > > > Something really weird there . > > topo_probe_0xb() falls early on 1st iteration back to > > topo_probe_0x4(). topo_probe_0x4() returns incorrect data as > > well. > > > > topo_probe: cpu_high = b > > topo_probe: cpu_vendor_id = 8086 > > topo_probe_0xb: i = 0, p[1] = 0 > > topo_probe_0x4: cpu_procinfo = 200800 > > topo_probe_0x4: cpu_logical = 32 > > topo_probe_0x4: i = 0, type = 1 > > topo_probe_0x4: i = 0, level = 1 > > topo_probe_0x4: i = 0, logical = 1 > > topo_probe_0x4: i = 0, cores = 16 > > topo_probe_0x4: i = 1, type = 2 > > topo_probe_0x4: i = 1, level = 1 > > topo_probe_0x4: i = 1, logical = 1 > > topo_probe_0x4: i = 1, cores = 16 > > topo_probe_0x4: i = 2, type = 3 > > topo_probe_0x4: i = 2, level = 2 > > topo_probe_0x4: i = 2, logical = 1 > > topo_probe_0x4: i = 2, cores = 16 > > topo_probe#1: mp_ncpus = 3 > > topo_probe#1: cpu_cores = 1 > > topo_probe#1: cpu_logical = 32 > > topo_probe#1: hyperthreading_cpus = 32 > > topo_probe#2: mp_ncpus = 3 > > topo_probe#2: cpu_cores = 1 > > topo_probe#2: cpu_logical = 32 > > topo_probe#2: hyperthreading_cpus = 32 > > My interpretation: > > 1. Current (unpatched) code reports correct results either by a > chance or because Jeff knows some magic patterns. > cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb, > but CPUID.(EAX=11, ECX=0):EBX == 0, > which means that we should fallback to 0x4 method. > But the code doesn't do that and instead simply sets cpu_logical to > 1 and cpu_cores stays zero, which is later translated to mp_ncpus, > which happens to match the reality. > > 2. Intel reports correct results, because it properly probes the > topology. It binds to each of the logical processors available and > checks their APIC IDs against masks and builds topology info. > > 3. Patched code works incorrectly, because essentially it only > calculates masks for CPU (and cache, for some reason) topology > building. Instead of checking IDs against those masks, the code > assumes numbers of cores and threads are at their maximum values > allowed by the masks[*]. But that is not true and the numbers do > not add up and we get that strange incorrect result. Yes, your interpretation is correct, I believe. > Things like that probably do not happen with real hardware much, > but they could. AFAIK, it never happened on a real hardware. > The only way to deal with this is by following the correct procedure > instead of making assumptions based on BSP. But that may be hard. Feel free to rewrite the patch. I never intended to commit the patch, any way. If I ever did, it was a year ago. :-) > [*] E.g. that page says: > CPUID.1:EBX[23:16] represents the maximum number of addressable IDs > (initial APIC ID) that can be assigned to logical processors in a > physical package. The value may not be the same as the number of > logical processors that are present in the hardware of a physical > package. The value of (1 + (CPUID.(EAX=4, ECX=0):EAX[31:26] )) > represents the maximum number of addressable IDs (Core_ID) that can > be used to enumerate different processor cores in a physical > package. The value also can be different than the actual number of > processor cores that are present in the hardware of a physical > package. Yes, I already know that. Jung-uk Kim