on 02/09/2010 11:25 Andriy Gapon said the following:
on 01/09/2010 21:26 Jung-uk Kim said the following:
On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote:
[3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and
my patch won't work on them. If anyone has a Bulldozer sample,
on 01/09/2010 21:26 Jung-uk Kim said the following:
On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote:
[3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and
my patch won't work on them. If anyone has a Bulldozer sample,
please look into it.
I checked AMD website today and
On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote:
[3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and
my patch won't work on them. If anyone has a Bulldozer sample,
please look into it.
I checked AMD website today and found out a new CPUID Spec. Rev. 2.34
was just
Oops, the patch had a small mistake.
I've put it here now, just in case I'll want to fix/cleanup anything else:
http://people.freebsd.org/~avg/intel-cpu-topo.diff
on 28/08/2010 23:22 Andriy Gapon said the following:
So, here is my take on the problem.
The attached patch is against sources in
on 28/08/2010 01:02 Andriy Gapon said the following:
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
on 19/08/2010 20:26 Jung-uk Kim said the following:
One thing I am not sure is whether those CPUID instructions are
executed on *real* CPUs or translated in HVM. On top of that, I am
not even sure they will be executed on *correct* cores. I bet they
won't.
Hmm, I have an impression that
On Friday 27 August 2010 01:33 pm, Andriy Gapon wrote:
on 19/08/2010 20:26 Jung-uk Kim said the following:
One thing I am not sure is whether those CPUID instructions are
executed on *real* CPUs or translated in HVM. On top of that, I
am not even sure they will be executed on *correct*
on 27/08/2010 22:36 Jung-uk Kim said the following:
Now, back to my original question. My point was, we should never
trust any CPUIDs on emulated CPU if they are translated. What should
happen if you have four physical cores and you assign just one for
VirtualBox, for example? What
On Friday 27 August 2010 03:47 pm, Andriy Gapon wrote:
on 27/08/2010 22:36 Jung-uk Kim said the following:
Now, back to my original question. My point was, we should never
trust any CPUIDs on emulated CPU if they are translated. What
should happen if you have four physical cores and you
On 19 August 2010 20:56, pluknet pluk...@gmail.com wrote:
On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote:
on 10/08/2010 19:55 pluknet said the following:
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The patch should apply fine on both sys/amd64/amd64/mp_machdep.c
on 27/08/2010 23:15 Jung-uk Kim said the following:
I quickly looked over Xen sources. It seems the CPUID instruction is
translated by this code:
http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c
For HVM case, this is how the CPUID_HTT_CORES is set:
185 case
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 =
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().
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
On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote:
I still don't get your point.
My point is that if the Intel's code gets the topology right, then
the hardware is emulated properly and the problem is with the
patch.
What is your point? :)
My point is right topology means nothing in this
on 28/08/2010 01:03 Jung-uk Kim said the following:
On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote:
I still don't get your point.
My point is that if the Intel's code gets the topology right, then
the hardware is emulated properly and the problem is with the
patch.
What is your point?
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
on 28/08/2010 01:33 Jung-uk Kim said the following:
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
On Friday 27 August 2010 06:46 pm, Andriy Gapon wrote:
on 28/08/2010 01:33 Jung-uk Kim said the following:
Also, don't forget jhb's work based on ACPI affinity tables.
Not sure how they are applicable here.
Only SRAT is implemented ATM but SLIT should provide CPU affinity
information
on 19/08/2010 22:15 pluknet said the following:
On 19 August 2010 21:27, Andriy Gapon a...@icyb.net.ua wrote:
on 19/08/2010 19:56 pluknet said the following:
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class
CPU)
Origin = GenuineIntel Id = 0x106a5 Family = 6
on 10/08/2010 19:55 pluknet said the following:
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and
sys/i386/i386/mp_machdep.c.
http://people.freebsd.org/~jkim/mp_machdep2.diff
Hi.
Just checked on Xen HVM
On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote:
on 10/08/2010 19:55 pluknet said the following:
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and
sys/i386/i386/mp_machdep.c.
On Thursday 19 August 2010 12:56 pm, pluknet wrote:
On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote:
on 10/08/2010 19:55 pluknet said the following:
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The patch should apply fine on both
sys/amd64/amd64/mp_machdep.c and
on 19/08/2010 19:56 pluknet said the following:
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class
CPU)
Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5
On 19 August 2010 21:27, Andriy Gapon a...@icyb.net.ua wrote:
on 19/08/2010 19:56 pluknet said the following:
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class
CPU)
Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5
On 19 August 2010 21:26, Jung-uk Kim j...@freebsd.org wrote:
On Thursday 19 August 2010 12:56 pm, pluknet wrote:
On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote:
on 10/08/2010 19:55 pluknet said the following:
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The
On Thursday 19 August 2010 03:30 pm, pluknet wrote:
On 19 August 2010 21:26, Jung-uk Kim j...@freebsd.org wrote:
On Thursday 19 August 2010 12:56 pm, pluknet wrote:
On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote:
on 10/08/2010 19:55 pluknet said the following:
On 16 July
On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote:
The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and
sys/i386/i386/mp_machdep.c.
http://people.freebsd.org/~jkim/mp_machdep2.diff
Hi.
Just checked on Xen HVM with 3 cores.
1) 8.1 unmodified:
FreeBSD/SMP:
Oliver Fromme wrote:
Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
I patched topo_probe() so it calls topo_probe_0x4() after
topo_probe_0xb() if cpu_cores is still 0. I think this
is a better
David Xu wrote:
Do you have patch for i386 branch ? I want to test.
On my Pentium-D machine:
$ sysctl kern.sched.topology_spec
kern.sched.topology_spec: groups
group level=1 cache-level=0
cpu count=2 mask=0x30, 1/cpu
flags/flags
children
group level=3
On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote:
Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
I patched topo_probe() so it calls topo_probe_0x4() after
topo_probe_0xb() if cpu_cores
On 15 July 2010 23:18, Jung-uk Kim j...@freebsd.org wrote:
On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called.
On Thursday 15 July 2010 09:34 pm, David Xu wrote:
Jung-uk Kim wrote:
On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote:
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote:
on 14/07/2010 17:14 Oliver Fromme said the following:
In a machine installed yesterday, 8.1-PRERELEASE
On Friday 16 July 2010 03:55 am, Jeremy Chadwick wrote:
On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote:
Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
I patched topo_probe() so it
On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010
| [...]
| CPU:
Andriy Gapon wrote:
Could you please try to do the following?
1. Fetch topo-12212009.tar from the top of this page:
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
2. Untar it and apply this patch to the code:
on 15/07/2010 14:58 Oliver Fromme said the following:
Andriy Gapon wrote:
Could you please try to do the following?
1. Fetch topo-12212009.tar from the top of this page:
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
2. Untar it and
Andriy Gapon wrote:
on 15/07/2010 14:58 Oliver Fromme said the following:
Andriy Gapon wrote:
Could you please try to do the following?
1. Fetch topo-12212009.tar from the top of this page:
Andriy Gapon wrote:
on 15/07/2010 14:58 Oliver Fromme said the following:
Andriy Gapon wrote:
Could you please try to do the following?
1. Fetch topo-12212009.tar from the top of this page:
on 15/07/2010 15:27 Oliver Fromme said the following:
Unfortunately, it didn't change. Kernel output during boot
is still the same; it displays 1 package x 8 cores.
If you are sure that everything is done correctly (patch really applied, kernel
really rebuilt and reinstalled, and reboot was to
Andriy Gapon wrote:
on 15/07/2010 15:27 Oliver Fromme said the following:
Unfortunately, it didn't change. Kernel output during boot
is still the same; it displays 1 package x 8 cores.
If you are sure that everything is done correctly (patch really applied,
kernel
really rebuilt
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called. But the cpuid 0xb instruction doesn't seem to
return useful data: All values are zero already in the
first level, so cpu_cores remains 0.
Back in topo_probe(), there is a
On Thursday, July 15, 2010 1:56:11 pm Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called. But the cpuid 0xb instruction doesn't seem to
return useful data: All values are zero already in the
first
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called. But the cpuid 0xb instruction doesn't seem to
return useful data: All values are zero already in the
first level,
On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called. But the cpuid 0xb instruction doesn't seem to
return
Jung-uk Kim wrote:
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
I patched topo_probe() so it calls topo_probe_0x4() after
topo_probe_0xb() if cpu_cores is still 0. I think this
is a better fallback procedure. With
Jung-uk Kim wrote:
On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote:
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote:
on 14/07/2010 17:14 Oliver Fromme said the following:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010
| [...]
| CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class
CPU)
|
On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010
| [...]
| CPU:
pluknet pluk...@gmail.com wrote:
On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul
On Wed, Jul 14, 2010 at 04:44:05PM +0200, Oliver Fromme wrote:
pluknet pluk...@gmail.com wrote:
On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
Jeremy Chadwick wrote:
Can you also provide the output of acpidump -dt? This will probably
be quite long (possibly 300KB or more), so you may want to put it up on
the web somewhere.
http://www.secnetix.de/olli/tmp/acpidump-dt.txt
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH
on 14/07/2010 17:14 Oliver Fromme said the following:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010
| [...]
| CPU: Intel(R) Xeon(R)
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote:
on 14/07/2010 17:14 Oliver Fromme said the following:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
package correctly:
| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue
on 15/07/2010 00:40 Jung-uk Kim said the following:
It's funny that I actually wrote a convenience script (and cleaned up
today):
http://people.freebsd.org/~jkim/cpu_topology-12212009.sh
BTW, current topology detection code is not optimal for some Intel
processors if my memory serves.
On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote:
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote:
on 14/07/2010 17:14 Oliver Fromme said the following:
In a machine installed yesterday, 8.1-PRERELEASE doesn't
seem to detect the number of CPU packages vs. cores per
56 matches
Mail list logo
