Bitcoin Forum
December 08, 2016, 04:09:46 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 [46] 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4823171 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Internet151
Full Member
***
Offline Offline

Activity: 174



View Profile
August 17, 2011, 07:54:37 PM
 #901

Code:
[2011-08-17 17:56:04] Failed to init GPU thread 0
[2011-08-17 17:56:07] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:07] Failed to init GPU thread 1
[2011-08-17 17:56:10] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:10] Failed to init GPU thread 2
[2011-08-17 17:56:13] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:13] Failed to init GPU thread 3


for me 1.5.6 seems to work only on single card machines, i get the same message from 2 diff machines, one is 2x 5870 and one is 2x 5830

any ideas ?

P.S.
1.5.5 works just fine

Once I tried to update from 1.5.4 to 1.5.6 I noticed the same problem. One of my rigs with a single GPU is able to start up cgminer just fine but ones with multiple GPU's have the same error above.
1481213386
Hero Member
*
Offline Offline

Posts: 1481213386

View Profile Personal Message (Offline)

Ignore
1481213386
Reply with quote  #2

1481213386
Report to moderator
1481213386
Hero Member
*
Offline Offline

Posts: 1481213386

View Profile Personal Message (Offline)

Ignore
1481213386
Reply with quote  #2

1481213386
Report to moderator
1481213386
Hero Member
*
Offline Offline

Posts: 1481213386

View Profile Personal Message (Offline)

Ignore
1481213386
Reply with quote  #2

1481213386
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481213386
Hero Member
*
Offline Offline

Posts: 1481213386

View Profile Personal Message (Offline)

Ignore
1481213386
Reply with quote  #2

1481213386
Report to moderator
miscreanity
Legendary
*
Offline Offline

Activity: 1078


View Profile
August 17, 2011, 07:58:33 PM
 #902

... one is 2x 5870 and one is 2x 5830

Once I tried to update from 1.5.4 to 1.5.6 I noticed the same problem. One of my rigs with a single GPU is able to start up cgminer just fine but ones with multiple GPU's have the same error above.

Cards? 5xxx series issue? My 69xx cards are running nicely.
shaps
Newbie
*
Offline Offline

Activity: 15


View Profile
August 17, 2011, 07:58:45 PM
 #903

v1.5.6: cryptopp_asm32 seems to think it is doing around 50MHash on a Core2Duo.
gigica viteazu`
Sr. Member
****
Offline Offline

Activity: 455

beast at work


View Profile
August 17, 2011, 08:12:24 PM
 #904

ok my single card miner are using v11.7 driver and 2x card miners are using v11.6 ... this may be the cause of the v1.5.6 crash


i`ll update tomorrow the drivers to v11.7 on one of the 2x card miner to see if that is what causing the crash

BURST-3FDG-W622-8KAF-E52KP
Internet151
Full Member
***
Offline Offline

Activity: 174



View Profile
August 17, 2011, 08:26:48 PM
 #905

ok my single card miner are using v11.7 driver and 2x card miners are using v11.6 ... this may be the cause of the v1.5.6 crash


i`ll update tomorrow the drivers to v11.7 on one of the 2x card miner to see if that is what causing the crash

Nah that's not it, I had the same problem as you with catalyst 11.7.
Internet151
Full Member
***
Offline Offline

Activity: 174



View Profile
August 17, 2011, 08:27:55 PM
 #906

... one is 2x 5870 and one is 2x 5830

Once I tried to update from 1.5.4 to 1.5.6 I noticed the same problem. One of my rigs with a single GPU is able to start up cgminer just fine but ones with multiple GPU's have the same error above.

Cards? 5xxx series issue? My 69xx cards are running nicely.

4x Radeon HD 5870's.
Meatball
Sr. Member
****
Offline Offline

Activity: 322



View Profile
August 17, 2011, 08:44:34 PM
 #907

I can vouch for the fact that on my multi card rigs with Catalyst 11.7 (some with SDK 2.1, some with SDK 2.5), 1.5.6 works fine.

Also, catalyst 11.8's are out.  Testing it on one dual card machine and it's working fine with 1.5.6
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2011, 12:54:21 AM
 #908

Code:
[2011-08-17 17:56:04] Failed to init GPU thread 0
[2011-08-17 17:56:07] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:07] Failed to init GPU thread 1
[2011-08-17 17:56:10] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:10] Failed to init GPU thread 2
[2011-08-17 17:56:13] OpenCL compiler generated a zero sized binary, may need to reboot!
[2011-08-17 17:56:13] Failed to init GPU thread 3


for me 1.5.6 seems to work only on single card machines, i get the same message from 2 diff machines, one is 2x 5870 and one is 2x 5830

any ideas ?

P.S.
1.5.5 works just fine

I wish I knew what the actual issue is here, BUT what's happening is it's trying to build a program using the opencl compiler and it's being reported as being zero sized. The compiler seems to be screwing something up and I can't seem to debug why and where. However, most people find that starting it up many times over it will eventually work, and from that moment on it works fine.... go figure. Perhaps I should just make it try over and over within the code...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
August 18, 2011, 01:02:22 AM
 #909

I last upgraded to 1.5.3 on the day it was released.  It ran stable from that day until today when I stopped it to upgrade to 1.5.6.  It lead to a dead GPU within a rather short period of time twice in spite of a cooler environment.  In each instance, cgminer would behavie as if it was going to quit wen I hit Q, but then never terminate (defunct/zombified) and I would be unable to start a new SSH session or perform a soft reboot (init 6 wouldn't do anything, so I assume all new processes were locking up), so I had to hard reboot.  I switched back to 1.5.3 and I am mining fine.  This is on an HD 5830.  Any thoughts?  Any thing I might do to help debug?  This is Fedora 15 with the old JSON library that I have to modify the Makefile to ignore and use the built-in (hasn't been a problem on previous builds).
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2011, 01:04:47 AM
 #910

I last upgraded to 1.5.3 on the day it was released.  It ran stable from that day until today when I stopped it to upgrade to 1.5.6.  It lead to a dead GPU within a rather short period of time twice in spite of a cooler environment.  In each instance, cgminer would behavie as if it was going to quit wen I hit Q, but then never terminate (defunct/zombified) and I would be unable to start a new SSH session or perform a soft reboot (init 6 wouldn't do anything, so I assume all new processes were locking up), so I had to hard reboot.  I switched back to 1.5.3 and I am mining fine.  This is on an HD 5830.  Any thoughts?  Any thing I might do to help debug?  This is Fedora 15 with the old JSON library that I have to modify the Makefile to ignore and use the built-in (hasn't been a problem on previous builds).
That is a hardware hang on your GPU from being overworked. Ironically the faster kernel means you have to decrease your overclock or provoke a hang. You'll have to find a new stable lower OC value for this kernel.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
August 18, 2011, 01:15:36 AM
 #911

I last upgraded to 1.5.3 on the day it was released.  It ran stable from that day until today when I stopped it to upgrade to 1.5.6.  It lead to a dead GPU within a rather short period of time twice in spite of a cooler environment.  In each instance, cgminer would behavie as if it was going to quit wen I hit Q, but then never terminate (defunct/zombified) and I would be unable to start a new SSH session or perform a soft reboot (init 6 wouldn't do anything, so I assume all new processes were locking up), so I had to hard reboot.  I switched back to 1.5.3 and I am mining fine.  This is on an HD 5830.  Any thoughts?  Any thing I might do to help debug?  This is Fedora 15 with the old JSON library that I have to modify the Makefile to ignore and use the built-in (hasn't been a problem on previous builds).
That is a hardware hang on your GPU from being overworked. Ironically the faster kernel means you have to decrease your overclock or provoke a hang. You'll have to find a new stable lower OC value for this kernel.
That is ironic.  I figured if the processor is running at 99% utilization, it is running at 99% utilization, but I'll give that a shot.  Once done, will there still be much benefit to running the newer kernel?  I mean, won't the slower clock speed cancel out the gains?  I know that my failover pool's single piece of work wasn't solved in either instance of 1.5.6 and it is usually the first or second hash found in 1.5.3, presumably it will be stale when/if it is found in this scenario, so is that intentional or an unintended side effict from other optimizations (I suppose it could also be something I won't experience when I get stable)?

EDIT: The failover pool's single share was sloved quickly after I lowered the overclocking, so either the other two instances were flukes or the lack of that solution was related to instability.
kripz
Full Member
***
Offline Offline

Activity: 182



View Profile
August 18, 2011, 01:49:15 AM
 #912

When does cgminer disable and re-enable a pool?

I just checked on my miner and the pool was disabled for some reason. The pool came back up and cgminer didn't re enable it straight away.

 Merged mining, free SMS notifications, PayPal payout and much more.
http://btcstats.net/sig/JZCODg2
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
August 18, 2011, 04:08:29 AM
 #913

v1.5.6: cryptopp_asm32 seems to think it is doing around 50MHash on a Core2Duo.
Lol, I noticed that too.  It's mainly due to the nonce.  It'll slowly level out over time to the actual value.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
August 18, 2011, 06:51:38 AM
 #914

I mean, won't the slower clock speed cancel out the gains?

Correct, but if you get the same hashrate al lower clock speed, you save some power. This saves money, heat, and is considered safer in the long run for your system.
Phil21
Full Member
***
Offline Offline

Activity: 152


View Profile
August 18, 2011, 07:39:42 AM
 #915

Hey,

Great work on this!  Takes pretty much all the features I had hacked into/worked around/etc. w/ Phoenix, and integrated them nicely.  Currently in the process of rolling out cgminer across the whole cluster.

One quickie... Right now, I do graph mHash/sec per GPU, and have various alarms that trigger.  While options exist to get per-gpu stats as-is (e.g. --debug), they are not optimal.

Right now the interval status line logging works great for me - it would be perfect if an option existed to also list the latest GPU stats as well.  Something like:

[2011-08-18 02:12:17] [ALL (5s):508.0  (avg):536.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]
[2011-08-18 02:12:17] [GPU0 (5s):204.0  (avg):214.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]
[2011-08-18 02:12:17] [GPU1 (5s):204.0  (avg):217.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]

I figure this would save me an hour or two of hacking things together, so I'd be happy to "donate" 2btc for this feature Smiley

Also, with --verbose on, and logging stderr to a logfile, I'm getting a lot of:
[2011-08-18 02:20:49] X-Roll-Ntime found 

Does this log entry have a purpose/something I should be looking at?

Additionally, the periodic GPU stats could be removed from --verbose, replaced with the above feature - it would keep the log output consistent nicely I believe.

-Phil
ollie0108
Newbie
*
Offline Offline

Activity: 9


View Profile
August 18, 2011, 08:49:14 AM
 #916

Hi there...
I configured the program with ./configure CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" on FreeBSD.
But when I type make next, it showed up like this:
Quote
make  all-recursive
Making all in lib
make  all-recursive
Making all in compat
Making all in jansson
Making all in ccan
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib   -I/usr/local/include -MT cgminer-util.o -MD -MP -MF .deps/cgminer-util.Tpo -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c
In file included from util.c:35:
miner.h:33:1: warning: "alloca" redefined
In file included from util.c:16:
/usr/include/stdlib.h:237:1: warning: this is the location of the previous definition
util.c: In function 'json_rpc_call_sockopt_cb':
util.c:268: error: 'SOL_TCP' undeclared (first use in this function)
util.c:268: error: (Each undeclared identifier is reported only once
util.c:268: error: for each function it appears in.)
util.c:268: error: 'TCP_KEEPCNT' undeclared (first use in this function)
util.c:271: error: 'TCP_KEEPIDLE' undeclared (first use in this function)
util.c:274: error: 'TCP_KEEPINTVL' undeclared (first use in this function)
*** Error code 1

Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
*** Error code 1

Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
*** Error code 1

Stop in /usr/home/users/xxxxxxx/xxxxxxxx/cgminer-1.5.6.
Could somebody please help?
Thanks Cry
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2011, 10:25:12 AM
 #917

Hey,

Great work on this!  Takes pretty much all the features I had hacked into/worked around/etc. w/ Phoenix, and integrated them nicely.  Currently in the process of rolling out cgminer across the whole cluster.

One quickie... Right now, I do graph mHash/sec per GPU, and have various alarms that trigger.  While options exist to get per-gpu stats as-is (e.g. --debug), they are not optimal.

Right now the interval status line logging works great for me - it would be perfect if an option existed to also list the latest GPU stats as well.  Something like:

[2011-08-18 02:12:17] [ALL (5s):508.0  (avg):536.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]
[2011-08-18 02:12:17] [GPU0 (5s):204.0  (avg):214.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]
[2011-08-18 02:12:17] [GPU1 (5s):204.0  (avg):217.9 Mh/s] [Q:5  A:0  R:0  HW:0  E:0%  U:0.00/m]

I figure this would save me an hour or two of hacking things together, so I'd be happy to "donate" 2btc for this feature Smiley

Also, with --verbose on, and logging stderr to a logfile, I'm getting a lot of:
[2011-08-18 02:20:49] X-Roll-Ntime found 

Does this log entry have a purpose/something I should be looking at?

Additionally, the periodic GPU stats could be removed from --verbose, replaced with the above feature - it would keep the log output consistent nicely I believe.

-Phil
Seems fair enough. It seems a lot of people use the debug mode and just parse that. I can make this ~ the verbose mode.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Ali
Member
**
Offline Offline

Activity: 84


View Profile
August 18, 2011, 10:47:08 AM
 #918

@ckolivas:

The cpu-only miner still crashes when started with this bat-file:

Quote
set http-proxy=http://127.0.0.1:8118
cgminer-cpuonly.exe   -o http://uswest.btcguild.com:8332/ -u user -p pass
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2011, 10:53:27 AM
 #919

@ckolivas:

The cpu-only miner still crashes when started with this bat-file:

Quote
set http-proxy=http://127.0.0.1:8118
cgminer-cpuonly.exe   -o http://uswest.btcguild.com:8332/ -u user -p pass
The CPU mining component of cgminer is annoying me as random bugs keep coming up, I have no incentive to work on it, and I am quite against CPU mining as a concept any more. Unless someone gives me a good reason to work on it any more, I'm going to recommend people go back to the original cpuminer code or ufasoft, and I will code out the cpu mining component of cgminer. Comments please!

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
August 18, 2011, 11:25:44 AM
 #920

I think what we really need is an else command so that if someone inputs the wrong option/format into the command line, then it will tell them flat out to try again.  Maybe a front-end would help to make debugging and sorting through actual bugs and mistyped commands?  But the fact is, I need your CPU miner.  Without it, I have pretty much nothing.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 [46] 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!