Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Aug 2010 18:33:37 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-stable@FreeBSD.org
Cc:        pluknet <pluknet@gmail.com>, Andriy Gapon <avg@icyb.net.ua>
Subject:   Re: 8.1-PRERELEASE: CPU packages not detected correctly
Message-ID:  <201008271833.42133.jkim@FreeBSD.org>
In-Reply-To: <4C7835E6.6070309@icyb.net.ua>
References:  <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <FOOBAR>
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008271833.42133.jkim>