From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:02:18 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 A9BF51065693; Fri, 27 Aug 2010 22:02:18 +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 B5B168FC0C; Fri, 27 Aug 2010 22:02:17 +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 BAA25311; Sat, 28 Aug 2010 01:02:16 +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 1Op703-0003WI-Mg; Sat, 28 Aug 2010 01:02:15 +0300 Message-ID: <4C7835E6.6070309@icyb.net.ua> Date: Sat, 28 Aug 2010 01:02:14 +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: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> In-Reply-To: <201008271743.29393.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 22:02:18 -0000 on 28/08/2010 00:43 Jung-uk Kim said the following: >> 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. :-) :-) BTW, it may be not that hard. It seems that 0x4 topology building involves knowing the masks and we already have that data (just interpreted differently), and APIC IDs of the CPUs and it seems that we also have that. We don't need to bind to CPUs to learn their IDs, we can just iterate over cpu_apic_ids[]. The only problem is that currently topo_probe() is called before assign_cpu_ids() which populates cpu_apic_ids. assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value. So, either cpu_apic_ids could be split out or alternatively we could use cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present and cpu_disabled entries). -- Andriy Gapon