Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 819. (Read 5805740 times)

full member
Activity: 168
Merit: 100
Live long and prosper. \\//,
I did gave a try to linux (Ubuntu 10.04 LTS), and I can't start my compiled miner without to change dir to /usr/local/bin...

Code:
[2011-07-30 11:00:58] Long-polling activated for http://pit.deepbit.net:8332/lis
tenChannel
[2011-07-30 11:01:01] Unable to open phatk110722.cl for reading

[2011-07-30 11:01:01] Unable to malloc source
[2011-07-30 11:01:01] Failed to init GPU thread 0
[2011-07-30 11:01:01] Unable to open phatk110722.cl for readingSzegmentálási hiba
placi@ubuntu:~$

"Szegmentálási hiba" = Segmentation fault
full member
Activity: 373
Merit: 100
Latest git, compile error without OpenCL:
Code:
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib  -DHAS_YASM -O3 -Wall -msse2 -march=native -MT cgminer-main.o -MD -MP -MF .deps/cgminer-main.Tpo -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c
main.c: In function ‘reinit_device’:
main.c:3420:12: error: ‘reinit_gpu’ undeclared (first use in this function)
main.c:3420:12: note: each undeclared identifier is reported only once for each function it appears in
main.c: In function ‘main’:
main.c:3717:7: warning: unused variable ‘name’
main.c:3714:18: warning: unused variable ‘j’
main.c: At top level:
main.c:168:12: warning: ‘opt_device’ defined but not used
main.c:367:14: warning: ‘forced_int_1010’ defined but not used
main.c:384:14: warning: ‘set_devices’ defined but not used
main.c:489:14: warning: ‘set_vector’ defined but not used
make[2]: *** [cgminer-main.o] Fehler 1
make[2]: Verlasse Verzeichnis '/home/reini/root/bitcoin/cgminer_build'
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/home/reini/root/bitcoin/cgminer_build'
make: *** [all] Fehler 2
newbie
Activity: 17
Merit: 0
i've been wondering if there is some way of adding a web interface for remotely monitoring/controlling cgminer.

the simplest way of monitoring is simply redirecting output to a logfile, but how about some way of controlling it? any ideas that dont require ck writing more code?  Wink
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Updated git tree getting ready for last release before I disappear for 10 days.

 Significant work went into attempting to make the thread restart code robust
to identify sick threads, tag them SICK after 1 minute, then DEAD after 5
minutes of inactivity and try to restart them. Instead of re-initialising the
GPU completely, only a new cl context is created to avoid hanging the rest of
the GPUs should the dead GPU be hung irrevocably.
- Use correct application name in syslog.
- Get rid of extra line feeds.
- Use pkg-config to check for libcurl version
- Implement per-thread getwork count with proper accounting to not over-account
queued items when local work replaces it.
- Create a command queue from the program created from source which allows us
to flush the command queue in the hope it will not generate a zero sized binary
any more.
member
Activity: 77
Merit: 10
will you plan to release 64 bit for windows in the future?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Code:
[2011-07-29 22:19:38] Thread 1 idle for more than 60 seconds, GPU 0 declared SICK!
[2011-07-29 22:19:38] Attempting to restart thread
[2011-07-29 22:19:38] Thread 1 restarted

Restarting the thread didn't seem to work, because it kept SICK and gpu load was still 0%. Trying to "restart" the GPU via the curses interface resulted in a segfault. I seem to have problems running cgminer with gdb attached, even just with text interface (-T). (Still with 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a, trying latest now.)
Yeah you caught the code in a state of flux. I've just committed a change which tries to send the device a command if it finds it sick. If the command returns it means the GPU isn't hung (hopefully) and then it will try to restart it itself if it gets to 10 minutes (dead state).
member
Activity: 98
Merit: 10
Code:
[2011-07-29 22:19:38] Thread 1 idle for more than 60 seconds, GPU 0 declared SICK!
[2011-07-29 22:19:38] Attempting to restart thread
[2011-07-29 22:19:38] Thread 1 restarted

Restarting the thread didn't seem to work, because it kept SICK and gpu load was still 0%. Trying to "restart" the GPU via the curses interface resulted in a segfault. I seem to have problems running cgminer with gdb attached, even just with text interface (-T). (Still with 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a, trying latest now.)
hero member
Activity: 658
Merit: 500
I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something
You do realise that you can specify kernels with the -k switch?
oh shi-

I didn't realize this because kernels didn't have their own folders
let me test this out

 I can't specify arbitrary kernel names if I have different versions, I can only use -k poclbm and -k phatk
full member
Activity: 373
Merit: 100
I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something
You do realise that you can specify kernels with the -k switch?
newbie
Activity: 47
Merit: 0
Hi there,

my cgminer crashes, if my primary pool goes offline. Is there a problem with the pool switch algorithm? In the Pool Menu i see all 3 pools as active, and i can switch manually to all of them.
member
Activity: 98
Merit: 10
I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.
Not sure that one's correct yet sorry. Before did you ever get any thread restarts that you can remember?

Not sure about it. I think I should enable logging to a file and see when the error occurs, and if I see any thread restarts on 1.4.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.
Not sure that one's correct yet sorry. Before did you ever get any thread restarts that you can remember?
hero member
Activity: 658
Merit: 500
I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something
member
Activity: 98
Merit: 10
I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.
full member
Activity: 420
Merit: 100
Now its the best minner, really stable and powerfull.

thx bro  Grin
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
For 1.5.2 my stats have gone up the first run by 2%

Thanks ckolivas Smiley

My last two runs (that I stopped myself of course) were:

1.5.1: 6hrs 6min 51sec Av: 696.7 Mh/s

1.5.2: 16hrs 4min 23sec Av: 710.9 Mh/s

My current one is at 2.5 hours and Av: 708.2 Mh/s but slowly rising
(the screen is connected to one of the 6950's and when it's un-blanked it drops 50Mh/s and it was un-blanked for a while when I started this run)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Here's what my work looks like:

{
   "id": 0,
   "result": {
      "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
      "midstate": "aca85347af9a2c933be96bdd8a0e9a2b11da0977108243537ea4daa16fb4dd2a",
      "data": "000000012c0fad8f9157ef574727e1e86cb27760f3914d9b6635d0240000082a000000002ffcdde 6edf23bac3d969036e734e26572061b9b3bd4551b19ccd05a7f928ea54e32b2bc1a09ec04000000 0000
0000800000000000000000000000000000000000000000000000000000000000000000000000000 000000080020000",
      "hash1": "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"
   },
   "error": null
}

That's just what work looks like from the pool. I think you just haven't spotted it in 1.4.

If you're having a problem, it's something else.
newbie
Activity: 56
Merit: 0
I'm not sure what you're telling me. That error: null field is coming from your pool, not from cgminer.

then why is it not coming from pool if I'm using 1.4?
newbie
Activity: 11
Merit: 0
As for CPU mining in 1.5.x+, I find the rate of accepted shares is the same crap rate as previous versions, as far as CPU mining goes. It's no worse than it ever was, but the efficiency is higher (efficiency being accepted shares / requests, NOT the reject rate).

I can confirm 1.5.2 does not drop hashing speed anymore (Linux, Ubuntu 10.04, CPU mining only). I ran one all night and the speed is still as expected. My accept/rejects are reasonable unlike what others have reported. Here it is:

Code:
 cgminer version 1.5.2 - Started: [2011-07-28 23:09:41]
--------------------------------------------------------------------------------
 [(5s):6.8  (avg):6.8 Mh/s] [Q:1335  A:48  R:4  HW:0  E:4%  U:0.08/m]
 TQ: 2  ST: 2  LS: 0  SS: 0  DW: 1331  NB: 88  LW: 1517  LO: 0  RF: 0  I: 0
 Connected to http://api.bitcoin.cz:8332 as user _________._____
 Block: 0000082a6635d024f3914d9b6cb27760...  Started: [09:00:19]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 CPU 0: [3.4 / 3.4 Mh/s] [Q:761  A:19  R:1  HW:0  E:2%  U:0.03/m]
 CPU 1: [3.4 / 3.4 Mh/s] [Q:758  A:29  R:3  HW:0  E:4%  U:0.05/m]
--------------------------------------------------------------------------------
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I'm not sure what you're telling me. That error: null field is coming from your pool, not from cgminer.
Jump to: