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. |
|
|
|
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/0B0lVSGQYLJIZVVp5aGxFVm1qVE0Check 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 |
|
|
|
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#.V1SzM2fmpkgI'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. |
|
|
|
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. |
|
|
|
Thanks Barney. Thanks Joblo for making this cpuminer. Just a little reminder that CMB doesn't build any binaries for CPUs without AES. This includes core2 and nehalem and whatever the equivalent is for AMD. If you attempt to mine an AES optimized algo with one of these builds on a CPU without AES the miner will crash. However, cpuminer-opt does support these CPUs but you will need to compile cpuminer-opt yourself. Instructions for Windows and Linux are in README.md for those interested and help is always available the cpuminer-opt thread. |
|
|
|
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 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.
There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gzwget 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 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.pdfPrior 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. |
|
|
|
CPUID status, will update with new info Trying to fix a bug that isn't a bug just creates more bugs. That's what happened with the AVX flag. The orignal implementation was correct. A detailed explanation is avaiable in this file: https://bitbucket.org/ariya/cpu-detect/src/cc2037e9bd0fb8cf12846dbfa4818fd813043972/base/cpu.h?at=masterSo I've reverted. The AVX2 flag isn't implemented by cpu-detect so I don't know if it requires the same logic ad AVX1. I will look into it further. cpu_detect returns the AES flag directly from the cpuid register so it is still a complete mystery why it was misidentified on the AMD Phenom2. The owner of a Xeon without AES posted capabilities while attemting to use the CMB Westmere build and it showed some interesting results. It correctly showed the CPU did not have AES but incorrectly displayed AVX and AVX2 as being available. This help define the problem, or should I say problems: 1. AVX shows available on non-AES CPU. This one might be understood and fixed with the correct reading of this feature. I would need a volunteer with a non-AES CPU to test. 2. AES shows available on non-AES AMD CPU. Still a mystery but seems limited to AMD. 3. AVX2 shows available on non-AES CPUs. I have to reimplement this because it does not use cpuid. I would like a volunteer or two because I don't like to publicly release code based on trial and error, which has been happening for the past few releases. These volunteers would need to be able to compile their own, Windows or Linux, doesn't matter. I hope I ave one volunteer already with an older AMD CPU. I would like a volunteer with old Intel CPU particularly Westmere and Nehalem. Investigation continues. I found a bug in my implemetation of has_avx2, but it wasn't even being used in v3.3.5. I'm going to put get_version back the way I found it and reimplement the parts I need. I should have a test build avaiable later today if there are any volunteers. Still no breakthrough of the AMD/AES issue. |
|
|
|
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.
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. |
|
|
|
Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed.  HOdl is working fine. The processor has has sse2 and sse3 capabilities. If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support non-AES CPUs if you compile yourself. See README.md for instructions. I have downloaded it from cryptomining-blog website. There is a sse2 executable which is working fine with other algos. CMB hasn't compiled any builds for CPUs without AES. Some algos will still work on your CPU because they are not optimized for AES. Please post the output at miner startup. If the algo says it has AES it will crash. If the algo doesn't have AES it will work. You will need to compile yourself to mine algos that have been optimized for AES. The instructions are in READSME.md. Checking CPU capatibility... Intel(R) Xeon(TM) CPU 2.80GHz 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... I am a noob in compiling, I have never done it. I thought that you are interested  Thanks, this is good info. It might help with the other problem being discussed. |
|
|
|
Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed. HOdl is working fine. The processor has has sse2 and sse3 capabilities. If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support non-AES CPUs if you compile yourself. See README.md for instructions. I have downloaded it from cryptomining-blog website. There is a sse2 executable which is working fine with other algos. CMB hasn't compiled any builds for CPUs without AES. Some algos will still work on your CPU because they are not optimized for AES. Please post the output at miner startup. If the algo says it has AES it will crash. If the algo doesn't have AES it will work. You will need to compile yourself to mine algos that have been optimized for AES. The instructions are in READSME.md. |
|
|
|
CPUID status, will update with new info Trying to fix a bug that isn't a bug just creates more bugs. That's what happened with the AVX flag. The orignal implementation was correct. A detailed explanation is avaiable in this file: https://bitbucket.org/ariya/cpu-detect/src/cc2037e9bd0fb8cf12846dbfa4818fd813043972/base/cpu.h?at=masterSo I've reverted. The AVX2 flag isn't implemented by cpu-detect so I don't know if it requires the same logic ad AVX1. I will look into it further. cpu_detect returns the AES flag directly from the cpuid register so it is still a complete mystery why it was misidentified on the AMD Phenom2. The owner of a Xeon without AES posted capabilities while attemting to use the CMB Westmere build and it showed some interesting results. It correctly showed the CPU did not have AES but incorrectly displayed AVX and AVX2 as being available. This help define the problem, or should I say problems: 1. AVX shows available on non-AES CPU. This one might be understood and fixed with the correct reading of this feature. I would need a volunteer with a non-AES CPU to test. 2. AES shows available on non-AES AMD CPU. Still a mystery but seems limited to AMD. 3. AVX2 shows available on non-AES CPUs. I have to reimplement this because it does not use cpuid. I would like a volunteer or two because I don't like to publicly release code based on trial and error, which has been happening for the past few releases. These volunteers would need to be able to compile their own, Windows or Linux, doesn't matter. I hope I ave one volunteer already with an older AMD CPU. I would like a volunteer with old Intel CPU particularly Westmere and Nehalem. Investigation continues. |
|
|
|
Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed. HOdl is working fine. The processor has has sse2 and sse3 capabilities. If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support non-AES CPUs if you compile yourself. See README.md for instructions. |
|
|
|
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/0B0lVSGQYLJIZVVp5aGxFVm1qVE0Check CMB or OP for Windows binaries availability. Win bins now available: http://cryptomining-blog.com/wp-content/download/cpuminer-opt-3-3-5-windows.zipI'd like to get some feedback regarding the CPU capabilities check from other AMD users as well as Nehalem and Westmere. In particular: - OS, build procedure, changes to default build. - CPU capabilities output at miner startup. - discrepencies between output and reality - did miner work, did it work at expective performance level - change in behaviour from previous releases - anything else you may think is useful. Some info can be confirmed with the following commands, piping to grep focusses on specific info. Display CPU info Linux. Maps to CPU HW capabilities. cat /proc/cpuinfo cat /proc/cpuinfo | grep AES Display default gcc options, Linux and mingw. gcc -Q -march=native --help=target gcc -Q -march=native --help=target | grep march |
|
|
|
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.
There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gzwget 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? |
|
|
|
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.
There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gzwget 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
As you can see in the source code, AVX flag is just one-bit check from 1/ECX, not how it's done in cpuminer-opt. cpuminer-opt definitely has a bug in AVX detection. Different problem. |
|
|
|
I compile it myself on my personal Win7 machine so I have CPU-Z installed. cpuminer compilation with MSYS+WinBuilds like in README, without autogen.sh, because it fails on MSYS. Also custom libcurl and openssl dll's compiled for other project. Other thing... cpuminer-opt 3.3.4 -V outputs dependency libs version built on Jun 2 2016 with GCC 4.8.3
features: x86_64 SSE2 AVX AVX2 XOP
libcurl/7.48.0 OpenSSL/1.0.2g
jansson/2.6 pthreads/2.9.1.0 cpuminer-opt 3.3.5 -V outputs just this: CPU features: SSE2 AVX AVX2
SW built on Jun 5 2016 with GCC 4.8.3
Build features: SSE2 I didn't see much use in low level features or lib dependencies being listed. I can easilly put them back, or I could even add more info to -V if you like. I'm open to suggestions. I'm still looking for some way the application can determine which -march was used and maybe other compiler options. I tried reading CFLAGS and CXXFLAGS but they are undefined in the application. I wonder if there is some way they can be passed to the program during compilation? |
|
|
|
The Linux system is how to set the NVIDIA graphics card fan speed, who can help me? thank you。  COOL-BITS-- This is accomplished by setting COOL-BITS=28, which allows setting clock speeds and fan speeds. That is the short of it. Somewhere back in this thread there is more detailed information, and the Cool-Bits2 Scrypt. The scrypt (a BASH scrypt) allows for command line regulation of fans. If you do a search on Cool-Bits, and Cool-Bits2 scrypt, you should find it It is also possible to regulate fans from the Desktop GUI if Cool-Bits=28 is set. I would have to find the stuff (again), but it is searchable. I have the scrypt printed out in a binder. If you can't find it on your own, I'll dig it out for you. --scryptr nvidia-settings has fan and clock control in the GUI when coolbits are set. There's lots of info available on the net if you search coolbits. There are some tricks to get it working on a GPU with no minitor attached but they are documented also. |
|
|
|
get this error with 3.3.5 c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
Did you include CXXFLAGS="-std=gnu++11" in your configure? build.sh (or winbuild.sh for Windows) also works and sets the flags correctly. I think I'll add a brief installation section to the OP. Perhaps that will reduce the number of these questions. It seems to be becoming a FAQ. |
|
|
|
|
Show Posts
