From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 21:25:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE16106566C; Fri, 27 Aug 2010 21:25:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AEC308FC1E; Fri, 27 Aug 2010 21:25:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA24908; Sat, 28 Aug 2010 00:25:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op6QG-0003Sl-Mf; Sat, 28 Aug 2010 00:25:16 +0300 Message-ID: <4C782D3B.6020407@icyb.net.ua> Date: Sat, 28 Aug 2010 00:25:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: pluknet References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jung-uk Kim 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:25:20 -0000 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. Things like that probably do not happen with real hardware much, but they could. 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. [*] 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. -- Andriy Gapon