Great job Joblo,
v.3.3.5 working like charm on Gainestown Xeon's with cpuminer-sse2.exe build.
Checking CPU capatibility...
Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
CPU features: SSE2 AVX AVX2
SW built on Jun 5 2016 with GCC 5.3.0
Build features: SSE2
Algo features: SSE2 AES
AES not available, starting mining with SSE2 optimizations...
Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 157. (Read 444040 times)
June 06, 2016, 11:10:34 AM
June 06, 2016, 10:55:00 AM
Cryptonight update.
As previously mentioned cryptonight is broken on Windows from v3.3 to present. Prior to that Windows was
not supported. Linux is not affected.
I have localized the problem to a simple function call that goes bad and crashes the miner. The line before
the call is executed but the first line of the called function is never reached.
This is a simple call to a constant function, nothing fancy, no algo-gate function pointers, just a basic call to the hash
function. It is the exact same code that runs fine on Linux. There are no OS hooks anywhere to be found.
It was first discovered in the CMB prebuilt binaries but I can easilly reproduce it with a different compiler version.
It's difficult to wrap my head around this kind of problem, especially when it's OS specific. The crash suggests the
function address was invalid. It seems either the compiler messed up linking the function address or it got overwritten
after compilation. c/c++ always scares me with the lack of built in buffer overflow protection. I'm not used to working
without a net. But even if there is a buffer overflow corrupting a function why only on Windows?
I'll review all the data defined in that file for anything suspicious but after that I'll be pretty stuck.
As previously mentioned cryptonight is broken on Windows from v3.3 to present. Prior to that Windows was
not supported. Linux is not affected.
I have localized the problem to a simple function call that goes bad and crashes the miner. The line before
the call is executed but the first line of the called function is never reached.
This is a simple call to a constant function, nothing fancy, no algo-gate function pointers, just a basic call to the hash
function. It is the exact same code that runs fine on Linux. There are no OS hooks anywhere to be found.
It was first discovered in the CMB prebuilt binaries but I can easilly reproduce it with a different compiler version.
It's difficult to wrap my head around this kind of problem, especially when it's OS specific. The crash suggests the
function address was invalid. It seems either the compiler messed up linking the function address or it got overwritten
after compilation. c/c++ always scares me with the lack of built in buffer overflow protection. I'm not used to working
without a net. But even if there is a buffer overflow corrupting a function why only on Windows?
I'll review all the data defined in that file for anything suspicious but after that I'll be pretty stuck.
June 06, 2016, 10:35:56 AM
Current cpuminer-opt 3.3.5 falsefully reports that my core 2 quad has AVX and AVX2: https://asciinema.org/a/d6mad2jp2m4ykgyqiiztpsv41
Cut and paste error, do you want to try the debug load? It has a complete rewrite of the features list
and a couple of other related fixes.
What the hell, I'll post the link here. It should only be used for testing purposes.
https://drive.google.com/file/d/0B0lVSGQYLJIZeUFMM1VRdHNVbDg/view?usp=sharing
June 06, 2016, 09:54:53 AM
Current cpuminer-opt 3.3.5 falsefully reports that my core 2 quad has AVX and AVX2: https://asciinema.org/a/d6mad2jp2m4ykgyqiiztpsv41
June 06, 2016, 09:25:11 AM
I'm volunteering for testing.
Can test on AMD (SSE2, no AVX) both Windows and Linux, aswell on Core i7-4790K (AVX) on Linux and AMD FX-7600P (AVX) on Windows.
Thanks, check your PM.
June 06, 2016, 04:54:52 AM
I am preparing a debug build to test some changes and collect more data.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.
AVX2 is should be fixed. I tested AVX2 on a Sandybridge.
AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.
I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.
GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.
I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.
Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.
AVX2 is should be fixed. I tested AVX2 on a Sandybridge.
AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.
I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.
GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.
I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.
Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.
I'm volunteering for testing.
Can test on AMD (SSE2, no AVX) both Windows and Linux, aswell on Core i7-4790K (AVX) on Linux and AMD FX-7600P (AVX) on Windows.
June 05, 2016, 09:24:11 PM
Bad choice of words, sorry.
June 05, 2016, 09:18:13 PM
That's not what you said earlier but you are now correct and I have already made the change.
You might have a case of selective memory, because this is exactly what I said earlier:
See that "CPU supports AVX: yes"? That's a bug in has_avx(). For some reason the code you inherited returns yes if CPU either has AVX or OSXSAVE flag.
Bolded the "or" for you.
Faulty maybe, but not selective.
As it turns out (bitwize) anding them and testing for zero doesn't work either. Have to test each bit seperately.
June 05, 2016, 07:48:49 PM
cpuminer-opt v3.3.5 is available.
Fixed hodl on Windows with non-AES CPUs. New build procedure for Windows, see README.md.
This fix is only significant for Windows users who compile their own on non-AES CPUs. Cryptomining
Blog does not build binaries for non-AES CPUs.
Rewrote CPU capabilities check to provide more info and be less verbose. It is implemented in permissive
mode meaning that mining will always be attempted. The miner may crash or perform at less than optimum.
This should close any remaining issues for now. It is recommended that all users upgrade even those who don't
like to update every release.
Download source:
https://drive.google.com/file/d/0B0lVSGQYLJIZVVp5aGxFVm1qVE0
Check CMB or OP for Windows binaries availability.
Fixed hodl on Windows with non-AES CPUs. New build procedure for Windows, see README.md.
This fix is only significant for Windows users who compile their own on non-AES CPUs. Cryptomining
Blog does not build binaries for non-AES CPUs.
Rewrote CPU capabilities check to provide more info and be less verbose. It is implemented in permissive
mode meaning that mining will always be attempted. The miner may crash or perform at less than optimum.
This should close any remaining issues for now. It is recommended that all users upgrade even those who don't
like to update every release.
Download source:
https://drive.google.com/file/d/0B0lVSGQYLJIZVVp5aGxFVm1qVE0
Check CMB or OP for Windows binaries availability.
Cryptomining Blog has now included an SSE2 build.
http://cryptomining-blog.com/wp-content/download/cpuminer-opt-3-3-5-windows.zip
June 05, 2016, 07:45:52 PM
It crashes with Cryptonight. I have an i7 4770K.
What file or self compile? Can you post ouput displayed at startup?
Edit: just tried it on my i7 6700K and no problems.
Video
http://tinypic.com/player.php?v=14jz284%3E&s=9#.V1SzM2fmpkg
I'm using the one from cryptomining-blog.
With this line: cpuminer-haswell-broadwell -a cryptonight --benchmark
Thanks, I watched the video and it helped. I've reproduced the problem with the CMB binaries and also by compiling
myself on Windows. As mentioned previously it works on my Skylake with Linux so it seems it's limited to Windows.
Anyways I have some work to do. In the meantime you can use Wolf0's cryptonight miner, windows binaries avaialble.
It shouldn't be too hard to find on github.
I have a lot of work to do. I haven't touched cryptonight in a long time and may not have tested it when I started
supporting Windows.
June 05, 2016, 07:26:45 PM
It crashes with Cryptonight. I have an i7 4770K.
What file or self compile? Can you post ouput displayed at startup?
Edit: just tried it on my i7 6700K and no problems.
Video
http://tinypic.com/player.php?v=14jz284%3E&s=9#.V1SzM2fmpkg
I'm using the one from cryptomining-blog.
With this line: cpuminer-haswell-broadwell -a cryptonight --benchmark
June 05, 2016, 06:57:40 PM
That's not what you said earlier but you are now correct and I have already made the change.
You might have a case of selective memory, because this is exactly what I said earlier:
See that "CPU supports AVX: yes"? That's a bug in has_avx(). For some reason the code you inherited returns yes if CPU either has AVX or OSXSAVE flag.
Bolded the "or" for you.
June 05, 2016, 06:55:10 PM
Using the build from crypotoblog as I am on Windows 7 64bit and have a i7 4790k (haswell).
When using the cpu miner- cpuminer-haswell-broadwell the miner will not run but it does with just cpuminer and cpuminer-sse2 on 3.3.5 and 3.3.4. I have no idea why it does not work on the first.
When using the cpu miner- cpuminer-haswell-broadwell the miner will not run but it does with just cpuminer and cpuminer-sse2 on 3.3.5 and 3.3.4. I have no idea why it does not work on the first.
June 05, 2016, 06:43:58 PM
It crashes with Cryptonight. I have an i7 4770K.
What file or self compile? Can you post ouput displayed at startup?
Edit: just tried it on my i7 6700K and no problems.
June 05, 2016, 06:35:47 PM
It crashes with Cryptonight. I have an i7 4770K.
June 05, 2016, 06:05:26 PM
I am preparing a debug build to test some changes and collect more data.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.
AVX2 is should be fixed. I tested AVX2 on a Sandybridge.
AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.
I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.
GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.
I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.
Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.
AVX2 is should be fixed. I tested AVX2 on a Sandybridge.
AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.
I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.
GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.
I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.
Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.
June 05, 2016, 04:12:31 PM
I would be nice if CPUz had open source so I could just copy their code. I found this, closest I found
to your CPU. Something I can work with to figure out what's wrong.
to your CPU. Something I can work with to figure out what's wrong.
There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
Code:
wget http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
tar xvf cpuid-20151017.src.tar.gz
cpuid-20151017/
make
./cpuid -1 | fgrep -i avx
@th3.rOOt, can you try this on your AMD, to see if it works? Thanks.
Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.
This may help explain why AVX was misidentified, but there's also AES and AVX2. In cpu_detect there is no
mention of AVX2 and AES has no special handling. Did CPU AES get misindentified in previous releases?
The result on AMD Phenom II X4 940
Code:
urban@beast:~$ /home/urban/cpuid-20151017/cpuid -1 | fgrep -i avx
AVX: advanced vector extensions = false
Thanks. I think I have AVX and AVX2 fixed. Now I'll dig into AES a bit more.
Edit: Tested AVX2 on my Sandybridge, test passed. I don't have the HW to test AVX.
Edit2: I have a theory about AES. AMD implemented the AES flag in CPUID in Sep 2010.
https://support.amd.com/TechDocs/25481.pdf
Prior to its implementation it would be undefined. There is a backup, CPUID has a Highest Feature Function
which will return the latest available feature. If AMD has implemented that I may be able to work around
the AES flag issue and get something that works.
June 05, 2016, 03:44:27 PM
I would be nice if CPUz had open source so I could just copy their code. I found this, closest I found
to your CPU. Something I can work with to figure out what's wrong.
to your CPU. Something I can work with to figure out what's wrong.
There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
Code:
wget http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
tar xvf cpuid-20151017.src.tar.gz
cpuid-20151017/
make
./cpuid -1 | fgrep -i avx
@th3.rOOt, can you try this on your AMD, to see if it works? Thanks.
Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.
This may help explain why AVX was misidentified, but there's also AES and AVX2. In cpu_detect there is no
mention of AVX2 and AES has no special handling. Did CPU AES get misindentified in previous releases?
The result on AMD Phenom II X4 940
Code:
urban@beast:~$ /home/urban/cpuid-20151017/cpuid -1 | fgrep -i avx
AVX: advanced vector extensions = false
June 05, 2016, 03:27:11 PM
June 05, 2016, 03:20:53 PM
Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.
The logic in there is "AND" as requirement. Meaning both AVX and XSAVE have to be there. In cpuminer-opt it's "OR", meaning presence of either AVX or XSAVE will return has_avx()=true.
That's not what you said earlier but you are now correct and I have already made the change.
Jump to: