Im using a few e5 2690 v2 ( 10 Core 20 Threads ).

Using 12 threads for mining, geting about 580 h/s on Windows.
Am i doing something wrong? Anyway to speed this up? ( with Claymore i get about 740h/s ).

same picture on FX-8350

problem1: x11evo all rejects

It works for me on my 15-2400. I noticed you used  -Ofast, recommended in -O3, as per build.sh.
try with -O3 instead. Also try with -march=native, it shouldn't make a difference but I'm stretching.

Edit: Also make sure its v3.5.4, x11evo was definitely broken in 3.5.3. Also try 3.5.1, last known working version.

I will need to make a decision on releasing v3.5.4 based on the 2 reported problems.

1: x11evo all rejects

x11evo was broken in v3.5.3 so there is no regression. I have not been able to reproduce the problem
on a similar CPU. Unless this problem is bigger, seen by other users or if other algos are broken it
will not delay the release.

2. AMD CPUs exit after 50 submits

If this is a new problem in v3.5.4 it may affect the decision to release it. However, the
problem description is so unusual in that the symptoms indicate completely intentional
and normal behaviour by the program, but there is no code to make it behave like that.
It is notable it has been reported by 2 users. I don't have AMD CPUs to test with and can't
reproduce the problem on Intel. It is unlikely this will be resolved quickly. I will probably
proceed with the release unless new information points to a problem with the code.

I can provide this win .bat: cpuminer-corei7.exe -o stratum+tcp://yiimp.ccminer.org:3555 --algo="timetravel" --threads="4" --retry-pause="5" -u MHcS2Q24fk7dyyhyppToERgnfeEdKN2WcN -p c=MAC
Maybe you can get the needed info

This won't be v3.5.4 but it will provide another data point: 3rd AMD user using previous release.

Holy crap! It won't delay this release but this is a weird problem that will be difficult to debug.
Is this only with timetravel?

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

Thanks. I find no way an algo can cause the program to exit. It either returns with a share or without,
everything else is generic unless there's a crash.

OK thanks. This issue will take a long time and I'll have to develop a strategy, so no quick fix.
I will need help from AMD users preferably those who originally reported the problem and
can compile their own so I can suggest adding some debugging code for testing.