Internet151
|
 |
August 17, 2011, 07:54:37 PM |
|
[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.
|
|
|
|
miscreanity
Legendary
Offline
Activity: 1316
Merit: 1005
|
 |
August 17, 2011, 07:58:33 PM |
|
... 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
Activity: 15
Merit: 0
|
 |
August 17, 2011, 07:58:45 PM |
|
v1.5.6: cryptopp_asm32 seems to think it is doing around 50MHash on a Core2Duo.
|
|
|
|
gigica viteazu`
Sr. Member
  
Offline
Activity: 458
Merit: 250
beast at work
|
 |
August 17, 2011, 08:12:24 PM |
|
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
|
|
|
|
Internet151
|
 |
August 17, 2011, 08:26:48 PM |
|
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
|
 |
August 17, 2011, 08:27:55 PM |
|
... 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
|
 |
August 17, 2011, 08:44:34 PM |
|
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 (OP)
Legendary
Offline
Activity: 4368
Merit: 1650
Ruu \o/
|
 |
August 18, 2011, 12:54:21 AM |
|
[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...
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
The00Dustin
|
 |
August 18, 2011, 01:02:22 AM |
|
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 (OP)
Legendary
Offline
Activity: 4368
Merit: 1650
Ruu \o/
|
 |
August 18, 2011, 01:04:47 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
The00Dustin
|
 |
August 18, 2011, 01:15:36 AM Last edit: August 18, 2011, 03:13:13 PM by The00Dustin |
|
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
|
 |
August 18, 2011, 01:49:15 AM |
|
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.
|
|
|
|
d3m0n1q_733rz
|
 |
August 18, 2011, 04:08:29 AM |
|
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
|
 |
August 18, 2011, 06:51:38 AM |
|
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
|
 |
August 18, 2011, 07:39:42 AM |
|
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  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
Activity: 9
Merit: 0
|
 |
August 18, 2011, 08:49:14 AM |
|
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: 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 
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4368
Merit: 1650
Ruu \o/
|
 |
August 18, 2011, 10:25:12 AM |
|
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  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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Ali
Member

Offline
Activity: 84
Merit: 10
|
 |
August 18, 2011, 10:47:08 AM |
|
@ckolivas: The cpu-only miner still crashes when started with this bat-file:
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4368
Merit: 1650
Ruu \o/
|
 |
August 18, 2011, 10:53:27 AM |
|
@ckolivas: The cpu-only miner still crashes when started with this bat-file: 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!
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
d3m0n1q_733rz
|
 |
August 18, 2011, 11:25:44 AM |
|
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
|
|
|
|