Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 222. (Read 5805531 times)
September 18, 2013, 05:59:35 PM
More correctly, read up about gpus (GPU-README) and --gpu-platform
September 18, 2013, 11:55:57 AM
Decided to just use the prebuilt Binaries instead of compiling it for Windows XP 32bit because I ran into too many problems. I can get CGminer to load but it is only recognizing the card in the first PCI-E slot. I have a dual card system with an Invidia gt520 in the first PCI-E slot and the XFX 5870 HD. Cgminer will only mine on the Nvidia card although it gives and error of Multiple OpenCl devices and ADL devices being misdetected/mismatched. I tried to use the -n function in a bat file but I get a brief flash of readout and then the program shuts down. I have been able to mine BTC on OpenCL via GIUminer on the ATI card but for some reason it's giving me errors for scrypt mining with CGminer. Any suggestions?
1. Is there anyway to generate a Log file so I can read the error output message?
2. Is there a command to put in the Bat file to ignore the primary card (nvidia) and only work off the secondary card (ati). Since I can't get -n command to function it I don't even know if it is being detected? It is being detected by cpuz and the system registry and I have been able to mine BTC with it but not Litecoin in scrypt?
Add a "pause" to your batch file, e.g.:1. Is there anyway to generate a Log file so I can read the error output message?
2. Is there a command to put in the Bat file to ignore the primary card (nvidia) and only work off the secondary card (ati). Since I can't get -n command to function it I don't even know if it is being detected? It is being detected by cpuz and the system registry and I have been able to mine BTC with it but not Litecoin in scrypt?
cgminer.exe -c gristle.conf -n
pause
exit
It will wait for you to hit any key before it exits cmd window.
In your gristle.conf file add the line:
"device" : "1",
and cgminer will only enable device 1.
September 18, 2013, 07:38:03 AM
the hub not necessarily cgminer issue . My cg miner compile on Linux what successfully compiled but so far mines buffering assuming my erroupter when in use with the pi needs more power since it works with my pc.
Only place I've heard 3.0 hubs don't work is the raspberry pi for whatever compatibility issue occuring.
Only place I've heard 3.0 hubs don't work is the raspberry pi for whatever compatibility issue occuring.
September 18, 2013, 04:32:49 AM
I am on MacOSX 10.6.8 (Snow Leopard) with the Mac Ports collection installed.
SNIPOnly the release tarball will compile on osx. What I'm saying, though, is if you have a 3.4.3 release, it IS using the latest libusb - statically compiled - regardless of who compiled it for you unless they've gone in and hacked the code to dynamically link the library because there is no way for it to use a dynamic library any more.
I've tried and tried using the latest releases compiling etc. I use an anker usb 10 port hub usb 3.0, so maybe thats whats wrong?
September 17, 2013, 09:54:26 PM
I am on MacOSX 10.6.8 (Snow Leopard) with the Mac Ports collection installed.
SNIPOnly the release tarball will compile on osx. What I'm saying, though, is if you have a 3.4.3 release, it IS using the latest libusb - statically compiled - regardless of who compiled it for you unless they've gone in and hacked the code to dynamically link the library because there is no way for it to use a dynamic library any more.
September 17, 2013, 09:31:14 PM
Just tried them on a Mac Mini with Snow Leopard and a single Block Erupter USB, give the USB timeout errors:
Code:
[2013-09-17 14:00:28] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:30] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:32] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:34] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:36] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:37] Stratum from pool 0 detected new block
[2013-09-17 14:00:38] AMU0: TIMEOUT GetResults took 1998ms but was 100ms
I have a stack of libusb libraries, no idea where they come from. There are even ones with the binary cgminer from http://spaceman.ca/cgminer though I can't see them linked with otool -L
Quote
root % otool -L cgminer
cgminer:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
@executable_path/dependencies/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
cgminer:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
@executable_path/dependencies/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
Perhaps I need some other command to see which USB library is being used.
Here is a list of the libusb stuff on my Mac
Code:
/usr/lib/libusb-1.0.0.dylib
/usr/lib/libusb-1.0.a
/usr/lib/libusb-1.0.la
/opt/local/bin/libusb-config
/opt/local/i386-mingw32/lib/libusbcamd.a
/opt/local/i386-mingw32/lib/libusbcamd2.a
/opt/local/include/libusb-1.0
/opt/local/include/libusb-1.0/libusb.h
/opt/local/lib/libusb-0.1.4.dylib
/opt/local/lib/libusb-1.0.0.dylib
/opt/local/lib/libusb-1.0.a
/opt/local/lib/libusb-1.0.dylib
/opt/local/lib/libusb-1.0.la
/opt/local/lib/libusb.a
/opt/local/lib/libusb.dylib
/opt/local/lib/libusb.la
/opt/local/lib/pkgconfig/libusb-1.0.pc
/opt/local/lib/pkgconfig/libusb.pc
/opt/local/var/macports/software/libusb
/opt/local/var/macports/software/libusb/libusb-1.0.8_0.darwin_10.x86_64.tbz2
I haven't been able to get the cgminer github source to compile myself, not from lack of trying! So I am dependent on the pre-compiled binaries I can find.
A fresh attempt yeilds:
Code:
root % ./autogen.sh
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
Running autoreconf -if...
./autogen.sh: line 12: libtoolize: command not found
configure.ac:24: installing './compile'
configure.ac:17: installing './config.guess'
configure.ac:17: installing './config.sub'
configure.ac:22: installing './install-sh'
configure.ac:53: error: required file './ltmain.sh' not found
configure.ac:22: installing './missing'
Makefile.am:21: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Makefile.am: installing './depcomp'
autoreconf: 'configure.ac' or 'configure.in' is required
Configuring...
./autogen.sh: line 21: /configure: No such file or directory
I know the Mac uses glibtoolize not libtoolize so if I patch autogen.sh to use glibtoolize it then gives:
Code:
root % ./autogen.sh
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
Running autoreconf -if...
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./config.guess'
glibtoolize: copying file `./config.sub'
glibtoolize: copying file `./install-sh'
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
Makefile.am:21: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
autoreconf: 'configure.ac' or 'configure.in' is required
Configuring...
./autogen.sh: line 21: /configure: No such file or directory
root %
CFLAGS="-O2" ./configure --enable-icarus
However when I try to make I get:
Code:
root % make
make all-recursive
Making all in lib
GEN arg-nonnull.h
GEN c++defs.h
GEN warn-on-use.h
GEN signal.h
GEN stdint.h
GEN string.h
make all-recursive
CC dummy.o
CC memmem.o
AR libgnu.a
/opt/local/bin/ranlib: file: libgnu.a(dummy.o) has no symbols
ranlib: file: libgnu.a(dummy.o) has no symbols
Making all in compat
Making all in jansson
CC dump.o
CC error.o
CC hashtable.o
CC load.o
CC memory.o
CC pack_unpack.o
CC strbuffer.o
CC strconv.o
CC utf.o
CC value.o
AR libjansson.a
Making all in libusb-1.0
make[3]: *** No rule to make target `all'. Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
root %
And that's where I get stuck. Any suggestions on how to proceed?
I am on MacOSX 10.6.8 (Snow Leopard) with the Mac Ports collection installed.
September 17, 2013, 05:50:56 PM
Really? 
How about this? Are you able to reproduce this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.
That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.
I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.
Is there an "official" way to report bugs or is ckolivas going to read this?
I read it. I read all bug reports - that doesn't mean I instantly respond. It was probably coincidence and an unrelated crash since I went to 50 million shares without a problem. Try a debug build.How about this? Are you able to reproduce this?
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.
That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.
Is there an "official" way to report bugs or is ckolivas going to read this?
September 12, 2013, 01:16:34 AM
When building CGMiner with only Icarus support, I notices cgminer-driver-opencl.c, cgminer-ocl.c, and cgminer-adl.c are still compiled and linked in. Why? Also, the OpenCL kernels are installed, even though without any OpenCL mining built in, they are less than useless.
That's because the default is to build for opencl. You'll see that ./configure shows:--disable-opencl
As for install, it's ancient and hardly anyone uses installs via "make install" so no attempt was made to modernise it.
I explicitly disabled OpenCL, instead of letting it not find OpenCL and disable it on its own, and those files are still compiled in.
September 17, 2013, 04:48:14 PM
Really?
How about this? Are you able to reproduce this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.
That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.
I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.
Is there an "official" way to report bugs or is ckolivas going to read this?
I read it. I read all bug reports - that doesn't mean I instantly respond. It was probably coincidence and an unrelated crash since I went to 50 million shares without a problem. Try a debug build. How about this? Are you able to reproduce this?
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.
That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.
Is there an "official" way to report bugs or is ckolivas going to read this?
September 17, 2013, 04:05:30 PM
New debug executables uploaded.
All done and started, now we just have to play the waiting game.
I haven't seen it crash for at least 2-3 days on 3.4.3
I'm currently swamped with other work and probably need a small break from regular cgminer coding anyway.
How about this? Are you able to reproduce this?
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field. So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.
That's not a bug. If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.
Is there an "official" way to report bugs or is ckolivas going to read this?
September 17, 2013, 06:49:54 AM
New debug executables uploaded.
All done and started, now we just have to play the waiting game.
I haven't seen it crash for at least 2-3 days on 3.4.3
I'm currently swamped with other work and probably need a small break from regular cgminer coding anyway.
September 12, 2013, 12:45:02 AM
When building CGMiner with only Icarus support, I notices cgminer-driver-opencl.c, cgminer-ocl.c, and cgminer-adl.c are still compiled and linked in. Why? Also, the OpenCL kernels are installed, even though without any OpenCL mining built in, they are less than useless.
September 17, 2013, 06:16:58 AM
New debug executables uploaded.
All done and started, now we just have to play the waiting game.
I haven't seen it crash for at least 2-3 days on 3.4.3
September 17, 2013, 04:27:06 AM
No worries - I've done this before for you, happy to do it again.
Let me know when you have 3.4.3 ready
New debug executables uploaded. Let me know when you have 3.4.3 ready
September 17, 2013, 01:15:50 AM
Just tried them on a Mac Mini with Snow Leopard and a single Block Erupter USB, give the USB timeout errors:
Code:
[2013-09-17 14:00:28] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:30] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:32] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:34] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:36] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:37] Stratum from pool 0 detected new block
[2013-09-17 14:00:38] AMU0: TIMEOUT GetResults took 1998ms but was 100ms
September 17, 2013, 12:28:40 AM
No doubt my usbfail.c test would show that libusb not working either ....
September 17, 2013, 12:09:47 AM
Just tried them on a Mac Mini with Snow Leopard and a single Block Erupter USB, give the USB timeout errors:
Code:
[2013-09-17 14:00:28] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:30] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:32] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:34] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:36] AMU0: TIMEOUT GetResults took 1999ms but was 100ms
[2013-09-17 14:00:37] Stratum from pool 0 detected new block
[2013-09-17 14:00:38] AMU0: TIMEOUT GetResults took 1998ms but was 100ms
Hardware is ok with bfgminer compiled from github.
September 16, 2013, 11:40:16 PM
No worries - I've done this before for you, happy to do it again.
Let me know when you have 3.4.3 ready
Let me know when you have 3.4.3 ready
September 16, 2013, 11:29:21 PM
Is there anything I can help with?
I do experience that crash where it just says "cgminer has stopped working". A quick reboot and its up again.
Thanks. I'll keep you posted when I upload the latest debug build and I'll get you to follow the instructions on how to get debugging information from it.I do experience that crash where it just says "cgminer has stopped working". A quick reboot and its up again.
You can read the instructions and get prepared here, but they're only cgminer 3.4.2 for the moment:
http://ck.kolivas.org/apps/cgminer/debug/
September 16, 2013, 11:22:25 PM
Is there anything I can help with?
I know you're a big fan of Linux, but you've done extremely well with the windows version of cgminer. The reason I am running windows is because I have a HP N40L server with a remote access card that doesn't support the linux GUI at all so it was extremely slow.
The HP N40L server ($200 micro server) is a great little unit, the remote access card allows me to remote into it even if it is switched off, or hard locked.
Its running Windows 7 x64 and cgminer 3.4.3.
Once windows was installed, I didn't even need to install drivers because they are all natively supported and there are none to install.
I copied on cgminer, and create a quick batch file, and boom, 25 block erupters and a Butterfly labs 7gh/s unit all work without an issue.
I do experience that crash where it just says "cgminer has stopped working". A quick reboot and its up again.
I know you're a big fan of Linux, but you've done extremely well with the windows version of cgminer. The reason I am running windows is because I have a HP N40L server with a remote access card that doesn't support the linux GUI at all so it was extremely slow.
The HP N40L server ($200 micro server) is a great little unit, the remote access card allows me to remote into it even if it is switched off, or hard locked.
Its running Windows 7 x64 and cgminer 3.4.3.
Once windows was installed, I didn't even need to install drivers because they are all natively supported and there are none to install.
I copied on cgminer, and create a quick batch file, and boom, 25 block erupters and a Butterfly labs 7gh/s unit all work without an issue.
I do experience that crash where it just says "cgminer has stopped working". A quick reboot and its up again.
Jump to: