From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:33:52 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 CDCE510656AD; Fri, 27 Aug 2010 22:33:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 27 Aug 2010 18:33:37 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> In-Reply-To: <4C7835E6.6070309@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271833.42133.jkim@FreeBSD.org> Cc: pluknet , Andriy Gapon 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:33:52 -0000 On Friday 27 August 2010 06:02 pm, Andriy Gapon wrote: > 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). If you are really up to this, it has to be a two-pass process. Even then, the dmesg won't be pretty because the topology can only be "announced" after all APs have been started. I mean, nobody's going to like to see a message like this from dmesg output: ... ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 --- >8 --- Snip several hundred lines! --- >8 --- SMP: AP CPU #1 Launched! FreeBSD/SMP: 1 package(s) x 2 core(s) Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 ... In fact, I implemented something like that while I was writing the patch but I discarded it for an obvious reason. ;-) Also, don't forget jhb's work based on ACPI affinity tables. Jung-uk Kim