Machine (11GB total) + Package L#0
NUMANode L#0 (P#0 11GB)
L3 L#0 (16MB)
L2 L#0 (512KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
PU L#0 (P#0)
PU L#1 (P#1)
L2 L#1 (512KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
PU L#2 (P#2)
PU L#3 (P#3)
L2 L#2 (512KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
PU L#4 (P#4)
PU L#5 (P#5)
L2 L#3 (512KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
PU L#6 (P#6)
PU L#7 (P#7)
L3 L#1 (16MB)
L2 L#4 (512KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
PU L#8 (P#8)
PU L#9 (P#9)
L2 L#5 (512KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
PU L#10 (P#10)
PU L#11 (P#11)
L2 L#6 (512KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
PU L#12 (P#12)
PU L#13 (P#13)
L2 L#7 (512KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
PU L#14 (P#14)
PU L#15 (P#15)

[QUOTE=Prime95;522641]Although it will prove nothing if it succeeds, try running hwloc's stand-alone program called lstopo or lstopo-no-graphics from [url]https://www.open-mpi.org/software/hwloc/v2.0/[/url][/QUOTE]

Is there a way to compare the hwloc-reported topology on Windows with that given by hwloc (or simply in /proc/cpuinfo) on a same-CPU Linux system?

Since I'm tinkering with the boxes now, I just reproduced the problem with Windows 7, which strictly speaking neither MS nor AMD support with Zen 2 CPUs.

The interesting thing is, the first time I tried running 4 cores, 4 workers with a 3600, I got a load of "Error setting affinity to core #xyz. There are 6 cores." messages on screen, before Windows reported an application error. Nothing in log after hwloc. Subsequent runs just went to the application error without those affinity messages, presumably due to something written in config files after 1st run.

Might take some time but I'm going to drop in a 2600 shortly to see if that is also affected. I didn't get any testers on the other forum I posted on.

2600 temporarily installed. I tried 4 cores, 4 workers, and it crashed just like it did on 3600 and 3700X. Since it was mentioned earlier in the thread, I also tried 2 cores 2 workers, and it also gave a load of affinity errors but completed without crashing. The errors didn't appear in the log, but as it didn't crash I was able to copy and save it in attached text file.

So new information right now is:
It also happens in Windows 7, not just Windows 10.
It also happens with Zen+ CPU, not limited to Zen 2.

I have a crazy idea to try out, back shortly :)

Edit: and the results are in. I went into the bios and disabled half the cores, so it is running in 3+0 configuration. One CCX. Tried a bench with 2 core 2 workers, ran fine, no errors. Similar 3c3w. Is there something about splitting work across CCX that is causing the problem?

After it crashes without an error message, have you checked the Windows Event Viewer to see the code reported by the application crash?

I don't have a Zen 2 to test on, but would the recent fix in 29.8b6 apply to the issues in this thread?

[QUOTE=hansl;523934]I don't have a Zen 2 to test on, but would the recent fix in 29.8b6 apply to the issues in this thread?[/QUOTE]

Yes. The bug was in prime95 running on a CPU with multiple L3 caches. The benchmark code that makes sure a worker's threads are all running in the same L3 cache was flawed.

[QUOTE=Prime95;523965]Yes. The bug was in prime95 running on a CPU with multiple L3 caches. The benchmark code that makes sure a worker's threads are all running in the same L3 cache was flawed.[/QUOTE]

Is this an extension to the core-affinity considerations? I.e. do various cores statically map to a given L3 cache, or is that mapping something the OS can fiddle at runtime?

[QUOTE=ewmayer;524051]Is this an extension to the core-affinity considerations? I.e. do various cores statically map to a given L3 cache, or is that mapping something the OS can fiddle at runtime?[/QUOTE]

Maybe the OS is smart enough to group different threads from the same process into the same L3 cache -- or maybe not. Hwloc libraries give you enough control to ensure this happens.