Am 01.10.2018 um 18:56 schrieb Brice Goglin:
Le 01/10/2018 à 17:27, Marco Atzeri a écrit :
Am 30.09.2018 um 20:11 schrieb Samuel Thibault:
Marco Atzeri, le dim. 30 sept. 2018 20:02:59 +0200, a ecrit:
also adding a HWLOC_DECLSPEC on the first case distances.c:347
does not solve the issue as the two declaration are not the same.
Suggestion ?
Perhaps use hwloc_uint64_t instead of uint64_t in hwloc/distances.c?
Samuel
Thanks Samuel,
it was that, in more than one place.
The attached patch allowed the compilation on cygwin64 bit.
hwloc_uint64_t is currently defined to DWORDLONG (worked fine on MinGW
and MSVC so far). I'd like to see if there's an easier way to solve this
issue by just making that definition compatible for cygwin.
I need to check, but I think there some differences
between MSVC and Cygwin on 64 bit structures.
FAIL: test-lstopo.sh
that seems due to a mix between Cygwin and Windows
############ utils/lstopo/test-lstopo.sh.log #############
Machine (3665MB total) + Package L#0
NUMANode L#0 (P#0 3665MB)
L3 L#0 (6144KB)
L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
PU L#0 (P#0)
PU L#1 (P#1)
L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
PU L#2 (P#2)
PU L#3 (P#3)
L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
PU L#4 (P#4)
PU L#5 (P#5)
L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
PU L#6 (P#6)
PU L#7 (P#7)
OpenProcess 13220 failed 5: Zugriff verweigert
Unfortunately that test script isn't easy to debug in the v2.x branch.
If that OpenProcess is where things fail, I assume that the line that
fails is "lstopo --ps". On MinGW, that code is ignored because /proc
doesn't exist. Does /proc exist on Cygwin? If so, we should just disable
that test line on Windows.
/proc exists but windows calls of course are not aware of it.
The failing message in German is coming from the Windows layer,
as my Cygwin enviroment is in English.
############################################################
And all the :
FAIL: Intel-Skylake-2xXeon6140.output
FAIL: Intel-Broadwell-2xXeon-E5-2650Lv4.output
FAIL: Intel-Haswell-2xXeon-E5-2680v3.output
FAIL: Intel-IvyBridge-12xXeon-E5-4620v2.output
FAIL: Intel-SandyBridge-2xXeon-E5-2650.output
FAIL: Intel-Westmere-2xXeon-X5650.output
FAIL: Intel-Nehalem-2xXeon-X5550.output
FAIL: Intel-Penryn-4xXeon-X7460.output
FAIL: Intel-Core-2xXeon-E5345.output
FAIL: Intel-KnightsLanding-XeonPhi-7210.output
FAIL: Intel-KnightsCorner-XeonPhi-SE10P.output
FAIL: AMD-17h-Zen-2xEpyc-7451.output
FAIL: AMD-15h-Piledriver-4xOpteron-6348.output
FAIL: AMD-15h-Bulldozer-4xOpteron-6272.output
FAIL: AMD-K10-MagnyCours-2xOpteron-6164HE.output
FAIL: AMD-K10-Istanbul-8xOpteron-8439SE.output
FAIL: AMD-K8-SantaRosa-2xOpteron-2218.output
FAIL: AMD-K8-SledgeHammer-2xOpteron-250.output
FAIL: Zhaoxin-CentaurHauls-ZXD-4600.output
FAIL: Zhaoxin-Shanghai-KaiSheng-ZXC+-FC1081.output
###########################################################
But it is not clear to me how these tests should pass.
The Laptop has a Quad Core I5
These tests use a tarball of the output of the cpuid instruction to
emulate calling cpuid on those platforms.
Go to tests/hwloc/xml, unpack one of the tarballs, and run
"/path/to/utils/lstopo/lstopo -i <path/to/the/extracted/subdir>", you
should get more information about what's failing when reading these
dumped cpuid outputs.
If it doesn't work tests/hwloc/xml/Intel-Skylake-2xXeon6140.output.log
will show the difference between the expected and obtained topology when
exported to XML.
I saw the difference, and as my machine is different from
everyone on the list none of the tests can pass.
Brice
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
_______________________________________________
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel
