Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 245. (Read 5806015 times)
August 22, 2013, 08:10:49 PM
Just wanted to say that it seems 3.4.0 has made my HW errors on the USB BEs drop significantly... very nice! thx!
August 22, 2013, 08:04:56 PM
Since upgrading to cgminer 3.4.0, my Jalapeno went from ~5.7 GH/s to ~5.5 GH/s. Should I let it cool down and restart it? I think something like that was discussed in this thread before.
You can isolate whether it is the Jalapeno startup or changes in 3.4.0 by comparing hash rates with your previous version of cgminer.
August 22, 2013, 05:01:52 PM
Stuck it in the fridge for about 30 minutes and it doesn't seem to have helped. If anything, it looks like it's gotten worse; down to ~5.4 GH/s now. 
August 22, 2013, 04:19:13 PM
The problem isn't so much when they are in the freezer as it is the water that condenses on them after you take it out....
August 22, 2013, 03:49:43 PM
it seems starting hash rate is partially determined based on Temperature at startup. so yeah, let it cool. some people have been refrigerateing them prior to turn on.
Hmm, refrigerating doesn't sound like a good idea. Wouldn't there be a problem with moisture?*shrug* i only know what it read here. maybe they put them in a plastic bag or frost free freezer. Pure water isn't a great conductor. It is the impurities in most water that causes problems. (doning protective vest)
August 22, 2013, 03:41:54 PM
it seems starting hash rate is partially determined based on Temperature at startup. so yeah, let it cool. some people have been refrigerateing them prior to turn on.
Hmm, refrigerating doesn't sound like a good idea. Wouldn't there be a problem with moisture? August 22, 2013, 03:37:04 PM
Since upgrading to cgminer 3.4.0, my Jalapeno went from ~5.7 GH/s to ~5.5 GH/s. Should I let it cool down and restart it? I think something like that was discussed in this thread before.
it seems starting hash rate is partially determined based on Temperature at startup. so yeah, let it cool. some people have been refrigerateing them prior to turn on.
August 22, 2013, 03:33:57 PM
Since upgrading to cgminer 3.4.0, my Jalapeno went from ~5.7 GH/s to ~5.5 GH/s. Should I let it cool down and restart it? I think something like that was discussed in this thread before.
August 22, 2013, 02:10:04 PM
Unofficial Mac binaries updated to 3.3.4 at http://spaceman.ca/cgminer.
This directly relates to the whole libusb monologue I've been having in here over the last month
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...
Karin, read the README
I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.
Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions. If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.
Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs. I'll try and do these test builds tonight and will post back with what I find.
As I have already stated, I can run two different libusb versions on the same architecture and one works while the other doesn't.
The test problem that I've mentioned in here a few times is standalone code (bits and pieces of the code I've written in cgminer - but modified) and that shows if timeouts are working ... and if they are matching the expected values also.
https://bitcointalk.org/index.php?topic=28402.msg2817682;topicseen#msg2817682
https://bitcointalk.org/index.php?topic=28402.msg2846296;topicseen#msg2846296
https://bitcointalk.org/index.php?topic=28402.msg2938585;topicseen#msg2938585
That specific version - libusb-1.0.16-rc10 - works on Linux and Windows
I've seen other 1.0.16 versions that don't work ... thus using the 'latest' libusb is not guaranteed to solve it.
Also, libusb has 2 sources: libusb and libusbx, and some OSs provide libusbx instead of libusb
The README also states how to use the libusb mentioned
Okay, I've solved this problem on Mac OS X by using libusb-1.0.2. Unfortunately, this version is from 2009, but it has worked well in testing with my own admittedly limited gear (one USB block erupter, one GPU).
I ran 44 test cases to determine this: 22 versions of libusb, 20 versions of libusbx, and a few alternates I located around the web. They span every official release and release candidate of the two libusb branches since 2009.
6 would not configure, 1 would not compile, 4 would not link with cgminer, 5 would not successfully access the USB device, 28 exhibited "TIMEOUT GetResults took 2000ms but was 100ms" errors, and only one worked without errors and generated the correct output (libusb-1.0.2). I could not get kano's usbfail.c to compile, so I simply built 44 versions of cgminer statically linked to the different libusb builds and ran my tests over 10 minutes of runtime each.
I've updated my cgminer for Mac OS X universal binaries as of a few moments ago, and will be submitting my findings to the other Mac cgminer projects (asteroid, xgminer, multiminer, macminer) for their own testing.
If this does indeed work for others, then the next step would be to approach the libusbx people and/or dig into the code myself, so that we can get a newer libusb/libusbx but with the correct operability of v1.0.2. Or perhaps 1.0.2 is fine.
August 22, 2013, 01:41:18 AM
I'm unable to compile 3.4.0 on Mac OS X:
Seems like clock_gettime(CLOCK_MONOTONIC, ...) is not available on OS X.
Yay for more unimplemented POSIX features on an operating system that claims to be POSIX. More like POSOSX.Code:
util.c: In function ‘cgtimer_time’:
util.c:891: warning: implicit declaration of function ‘clock_gettime’
util.c:891: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:891: error: (Each undeclared identifier is reported only once
util.c:891: error: for each function it appears in.)
util.c: In function ‘nanosleep_abstime’:
util.c:899: warning: implicit declaration of function ‘clock_nanosleep’
util.c:899: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:899: error: ‘TIMER_ABSTIME’ undeclared (first use in this function)
util.c:891: warning: implicit declaration of function ‘clock_gettime’
util.c:891: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:891: error: (Each undeclared identifier is reported only once
util.c:891: error: for each function it appears in.)
util.c: In function ‘nanosleep_abstime’:
util.c:899: warning: implicit declaration of function ‘clock_nanosleep’
util.c:899: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:899: error: ‘TIMER_ABSTIME’ undeclared (first use in this function)
Seems like clock_gettime(CLOCK_MONOTONIC, ...) is not available on OS X.
Will create a generic workaround for the next version.
August 22, 2013, 01:15:31 AM
I'm unable to compile 3.4.0 on Mac OS X:
Seems like clock_gettime(CLOCK_MONOTONIC, ...) is not available on OS X.
Code:
util.c: In function ‘cgtimer_time’:
util.c:891: warning: implicit declaration of function ‘clock_gettime’
util.c:891: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:891: error: (Each undeclared identifier is reported only once
util.c:891: error: for each function it appears in.)
util.c: In function ‘nanosleep_abstime’:
util.c:899: warning: implicit declaration of function ‘clock_nanosleep’
util.c:899: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:899: error: ‘TIMER_ABSTIME’ undeclared (first use in this function)
util.c:891: warning: implicit declaration of function ‘clock_gettime’
util.c:891: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:891: error: (Each undeclared identifier is reported only once
util.c:891: error: for each function it appears in.)
util.c: In function ‘nanosleep_abstime’:
util.c:899: warning: implicit declaration of function ‘clock_nanosleep’
util.c:899: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
util.c:899: error: ‘TIMER_ABSTIME’ undeclared (first use in this function)
Seems like clock_gettime(CLOCK_MONOTONIC, ...) is not available on OS X.
August 21, 2013, 11:43:27 PM
I've been using cgminer v3.3.0 with my ATI/Radeon 5700 successfully since 3.3.0 was released. Recently, the cpu was pegged at 100% and the system very sluggish as a result. I rebooted and now I can't get cgminer to startup. If I disable-gpu, it will start, otherwise it hangs with the following messages:
cgminer --verbose -D -T -c cgminer.conf.empty
[2013-08-22 13:33:00] Started cgminer 3.3.0
[2013-08-22 13:33:00] Loaded configuration file cgminer.conf.empty
[2013-08-22 13:33:00] RES: thread starting
Additionally "./cgminer --ndevs" will hang.
The system runs linux (bamt) and the GUI looks o.k., but I'm afraid that my GPU is dying.
What else can I try?
--E
cgminer --verbose -D -T -c cgminer.conf.empty
[2013-08-22 13:33:00] Started cgminer 3.3.0
[2013-08-22 13:33:00] Loaded configuration file cgminer.conf.empty
[2013-08-22 13:33:00] RES: thread starting
Additionally "./cgminer --ndevs" will hang.
The system runs linux (bamt) and the GUI looks o.k., but I'm afraid that my GPU is dying.
What else can I try?
--E
August 21, 2013, 08:42:48 PM
To save making these posts too big ... and quicker for me to write 
... somewhat abbreviated:
3.4.0a 3.4.0 recompiled on:
Fedora 18
64 bit xubuntu 11.04 (should also work on Fedora 16 and 17)
RPi 32bit Arch
RPi 32bit Raspbian
e.g. to get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.4.0a
chmod +x cgminer-3.4.0a
The 3 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.4.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.4.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.4.0a
The Xubuntu configure option (with GPU and scrypt):
LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
The rest are USB only (no GPU):
LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.
Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.4.0) then click on the file you want then right-click save-as the "View Raw" link.
Important: Read README, ASIC-README or FPGA-README about USB configuration on linux and windows
... somewhat abbreviated:3.4.0a 3.4.0 recompiled on:
Fedora 18
64 bit xubuntu 11.04 (should also work on Fedora 16 and 17)
RPi 32bit Arch
RPi 32bit Raspbian
e.g. to get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.4.0a
chmod +x cgminer-3.4.0a
The 3 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.4.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.4.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.4.0a
The Xubuntu configure option (with GPU and scrypt):
LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
The rest are USB only (no GPU):
LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev -lrt" CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.
Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.4.0) then click on the file you want then right-click save-as the "View Raw" link.
Important: Read README, ASIC-README or FPGA-README about USB configuration on linux and windows
August 21, 2013, 08:21:18 PM
...
Thank you so much for this! Just spent a long time trying to get libusb working correctly on Ubuntu 12.04 with my usb miners. This solved the problem immediately, great guide.
You're welcome.Thank you so much for this! Just spent a long time trying to get libusb working correctly on Ubuntu 12.04 with my usb miners. This solved the problem immediately, great guide.
I've also since updated the README with that but using the command line autogen/configure options to generate the correct Makefile so you don't have to edit it
August 21, 2013, 08:16:01 PM
What you are showing there is libusb failing to timeout.
That's what the test program will test and show for the version of libusb you use.
I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git:
https://github.com/kanoi/cgminer-binaries
On linux, To use the working libusb for cgminer instead of the system libusb -
First install udev-dev via one of:
Fedora: yum install libgudev1
Ubuntu derivatives: apt-get install libudev-dev
Arch: it should be installed by default as part of systemd
When you are in the cgminer folder:
mkdir libusb
cd libusb
wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true
tar -xvf libusb-1.0.16-rc10.tar.bz2
cd libusb-1.0.16-rc10
./configure
make
cd ..
cd ..
If you have already autogen/configured cgminer, next you want to edit Makefile
Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/
Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l)
Then
make clean
make
and now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly
N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb
That's what the test program will test and show for the version of libusb you use.
I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git:
https://github.com/kanoi/cgminer-binaries
On linux, To use the working libusb for cgminer instead of the system libusb -
First install udev-dev via one of:
Fedora: yum install libgudev1
Ubuntu derivatives: apt-get install libudev-dev
Arch: it should be installed by default as part of systemd
When you are in the cgminer folder:
mkdir libusb
cd libusb
wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true
tar -xvf libusb-1.0.16-rc10.tar.bz2
cd libusb-1.0.16-rc10
./configure
make
cd ..
cd ..
If you have already autogen/configured cgminer, next you want to edit Makefile
Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/
Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l)
Then
make clean
make
and now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly
N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb
Thank you so much for this! Just spent a long time trying to get libusb working correctly on Ubuntu 12.04 with my usb miners. This solved the problem immediately, great guide.
Also, is there a guide for what difficulty I should set in cgminer based on hashrate? Or should I just let cgminer decide?
August 21, 2013, 04:26:34 PM
How can I disable Intel GPU without using "cgminer -n" at all? I would like to automatically disable Intel GPU without having to manually check up the numbers with -n switch...
No, the numbers of the GPUs on Intel vs the numbers on AMD don't work that way anyway. cgminer will only mine on one SDK platform at any time (eg AMD or Intel). If you don't have the Intel OpenCL SDK installed, cgminer can't even mine on the Intel GPUs. If you have both the Intel and AMD OpenCL SDKs installed, you will need to specify one of them with the --gpu-platform command. 
August 21, 2013, 03:06:19 PM
Antivirus software are always whining about bitcoin miners like cgminer. Can you somehow modify cgminer so that antivirus software won't whine about it anymore? It's annoying.
Would involve completely rewriting it. anti-virus programs think that its a botnet (some of the code may have been used). Just add an exception to your antivius program for cgminer.exe and it should ignore it going forward.
August 21, 2013, 01:49:55 PM
It is AV program matter, not cgminer. Just add exception.
August 21, 2013, 12:13:14 PM
Antivirus software are always whining about bitcoin miners like cgminer. Can you somehow modify cgminer so that antivirus software won't whine about it anymore? It's annoying.
August 21, 2013, 10:22:08 AM
Is it normal that I can't run debug on windows 7 x64?
If I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
It used to crash here too, but to my surprise it doesn't after I reinstalled Windows.If I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
Don't ask me why.
Jump to: