OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 826.

Viceroy

hero member

Activity: 924

Merit: 501

Version 1.4.1 will not compile on CENTOS, same error as below.

Code:

util.c:254: error: expected declaration specifiers or â...â before âcurlsocktypeâ
util.c: In function âjson_rpc_callâ:
util.c:347: error: âCURLOPT_SOCKOPTFUNCTIONâ undeclared (first use in this function)
util.c:347: error: (Each undeclared identifier is reported only once
util.c:347: error: for each function it appears in.)
make[2]: *** [cgminer-util.o] Error 1
make[2]: Leaving directory `/root/building/cgminer-1.4.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/building/cgminer-1.4.1'
make: *** [all] Error 2

What is the fix???

Quote from: zaytsev on July 23, 2011, 05:46:45 AM

Version 1.4.0 no longer builds on RHEL5:

Quote

checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
...
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib -DHAS_YASM -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -Wall -MT cgminer-util.o -MD -MP -MF .deps/cgminer-util.Tpo -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c
util.c:254: error: expected declaration specifiers or '...' before 'curlsocktype'
util.c: In function 'json_rpc_call':
util.c:348: error: 'CURLOPT_SOCKOPTFUNCTION' undeclared (first use in this function)
util.c:348: error: (Each undeclared identifier is reported only once
util.c:348: error: for each function it appears in.)
make[2]: Leaving directory `/builddir/build/BUILD/cgminer-1.4.0'
make[2]: *** [cgminer-util.o] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/cgminer-1.4.0'
RPM build errors:
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.75423 (%build)
Bad exit status from /var/tmp/rpm-tmp.75423 (%build)
Child returncode was: 1

Could be old gcc or curl... is it possible to put a conditional to fix this? Previous versions did build just fine... The full log is here: http://rpm.zaytsev.net/test/cgminer/build.log

P.S. The fix by ycros doesn't help, I tried to replace util.c.

P.P.S. Yes, that's the curl version that is too old. Is it possible to make longpoll optional via configure??? It doesn't have all this CURLOPT_SOCKOPTFUNCTION stuff. It would suck if the support for RHEL5 would have to be dropped completely.

Clipse

hero member

Activity: 504

Merit: 502

Does cgminer allow external adjustments to the gpu utilization, or would it be possible to add support for such a feature?

What I need to do is feed from external source to phoenixminer specific gpu utilization ie. external source parses to cgminer instance to utilise 29% of gpu cycles etc.

ancow

full member

Activity: 373

Merit: 100

~~With 1.4.1 (unmodified) on OS X, somehow the kernel isn't built:~~

Edit: seems I stumbled on the "need to reboot to get a kernel" bug.

iopq

hero member

Activity: 658

Merit: 500

I was comparing this to diablominer, and they're about the same at -I 7, at -I 8 there's desktop lag and I'm getting about 155Mhash/s in both +/- 1 Mhash

without -I 7 the GPU utilization drops below 99% which affects the speed

zaytsev

newbie

Activity: 59

Merit: 0

RPM for EL6, still broken on EL5 because of curl :-(

ck, -O2 -g is not helping either, it still doesn't segfault under gdb, but reliably segfaults when run from the terminal. Look, I managed to make it to dump core with -O0, then loaded in gdb and did bt full. Does it help?

Quote

Core was generated by `/opt/cgminer/bin/cgminer --cpu-threads 4 --gpu-threads 0 --url xxx'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt full
#0 memset () at ../sysdeps/x86_64/memset.S:1016
No locals.
#1 0x00007ff9732ad842 in wredrawln () from /lib/libncurses.so.5
No symbol table info available.
#2 0x000000000040ab0a in watchdog_thread (userdata=0x0) at main.c:2991
y = 17
logx = 131
i = 4
x = 131
logy = 17
now = {tv_sec = 1311508655, tv_usec = 958182}
interval = 2
rotate_tv = {tv_sec = 1311508643, tv_usec = 956086}
zero_tv = {tv_sec = 0, tv_usec = 0}
#3 0x00007ff9736e09ca in start_thread (arg=) at pthread_create.c:300
__res =
pd = 0x7ff968a9a700
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140709179533056, -1219236616075443200, 0, 0, 4, 0, 1217862590511481856,
1217801615496348672}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 0}}}
not_first_call =
robust =
freesize =
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007ff972ff570d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#5 0x0000000000000000 in ?? ()
No symbol table info available.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

New release: Version 1.4.1

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1.tar.bz2

Linux x86_64 dynamic binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1-x86_64-built.tar.bz2

Win 32 binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1-win32.zip

I thought it was time for a mostly bugfix release. The only new feature in this version is the new trickle function which trickles work automatically to a backup pool if the primary pool is still responding but slow to ensure the GPU is always doing work even if it hasn't quite reached the stage where cgminer decides to switch pools. This happens by default with any pool management strategy choice. The rest of the changes are bugfixes to things reported mostly on this forum (thanks for your reports). The rest of the changelog follows:

Do away with GET for dealing with longpoll forever. POST is the one that works
everywhere, not the other way around.
- Detect when the primary pool is lagging and start queueing requests on backup
pools if possible before needing to roll work.
- Load balancing puts more into the current pool if there are disabled pools.
Fix.
- Disable a GPU device should the thread fail to init.
- Out of order command queue may fail on osx. Try without if it fails.
- Fix possible dereference on blank inputs during input_pool.
- Defines missing would segfault on --help when no sse mining is built in.
- Revert "Free up resources/stale compilers." - didn't help.
- Only try to print the status of active devices or it would crash.
- Some hardware might benefit from the less OPS so there's no harm in leaving
kernel changes that do that apart from readability of the code.

xcooling

member

Activity: 145

Merit: 10

+1 for POST instead of GET.

Could you add an option [P]ause , so we could pause the current work, if we wanted to quickly use the gpu for another task, and then resume it later.

Diapolo

hero member

Activity: 772

Merit: 500

Quote from: -ck on July 23, 2011, 08:22:21 PM

Quote from: twmz on July 23, 2011, 08:19:52 PM

Quote from: -ck on July 23, 2011, 08:00:36 PM

[2011-07-24 02:22:31] Failed to init GPU thread 0

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

Great, glad it works, and thanks for testing!

Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?

No funky values, but the truth

, so leave it like it is!

Dia

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

re: POST vs GET on longpoll

I am absolutely getting sick of this freaking problem of how to do a longpoll. I originally converted to GET because someone suggested that's what the deepbit unofficial guide suggested was the way to do a longpoll. Then I discovered lots of other longpolls didn't work because MANY operating systems could easily lose their longpoll connection through routers and so on because they didn't issue any sort of keepalive for up to 2 hours by default (7200 seconds). So with help I converted it to use keepalives much more frequently. In the meantime, deepbit longpolls were BROKEN by the use of GET. Now someone posts me a fix for deepbit longpolls, using POST again. As far as I can see, there is NO ADVANTAGE to using GET and unless someone can positively prove me otherwise, I will be converting every longpoll to POST once more and putting this issue to bed forever.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: neptop on July 22, 2011, 08:30:41 PM

Quote from: -ck on July 22, 2011, 07:23:07 PM

Quote from: neptop on July 22, 2011, 07:19:19 PM

Would it be possible to add a multipool strategy that's similar to load balance, but with the first one having priory? So the second one is just active when the first one for some reason doesn't have enough work, for example because of latency.

That's basically failover that you're describing... That's the default policy. Or do you mean micro delays instead of macro ones?

Yes, to even out (very) short performance drops.

Updated git tree: Now the default policy will detect when the primary pool is lagging and use a backup pool if there's one available.

nebiki

sr. member

Activity: 742

Merit: 250

Quote from: -ck on July 23, 2011, 10:20:17 PM

Not every work item has a solution. Thus you will not get always get the same number of submissions as queries. Conversely some work items have more than one solution. This leads to "efficiency" of greater than 100% (when not solo mining).

alright, i don't really get it, but it sounds like "it's not a bug". thanks for the answer!

Quote from: -ck on July 23, 2011, 10:20:17 PM

As for the flag idea... Tongue

ya, it figures.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: OCedHrt on July 19, 2011, 10:28:00 AM

Quote from: -ck on July 19, 2011, 06:07:39 AM

Quote from: xcooling on July 19, 2011, 06:04:45 AM

how does one specify phatk110714.cl or poclbm110717.cl ?

One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards.

Phoenix with phatk worked on my 4850, and that was faster than poclbm.

You can now specify which kernel you want with the -k option.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: nebiki on July 23, 2011, 09:29:27 PM

when solo-mining, i get

Code:

Q:1438  A:0  R:1360

what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".

another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<

Not every work item has a solution. Thus you will not get always get the same number of submissions as queries. Conversely some work items have more than one solution. This leads to "efficiency" of greater than 100% (when not solo mining).

As for the flag idea... Tongue

nebiki

sr. member

Activity: 742

Merit: 250

when solo-mining, i get

Code:

Q:1438  A:0  R:1360

what happened to the 78 requested work items? i know up to 2*NB (due to 2 threads) might be thrown away, but at that time NB was 24. still missing 30 "shares".

another thing: is it possible to set a flag for solo mining so the miner will report rejected shares as accepted? i really like the overview, but with rejected shares everything says "0" :<

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zaytsev on July 23, 2011, 06:27:02 PM

ck, I am still trying to track down the annoying window resize segfault. I compiled the git version like this:

Quote

CFLAGS="-O0 -g -Wall -march=native" ./configure --prefix=/opt/cgminer

and started like this

Quote

gdb /opt/cgminer/bin/cgminer

then I did "set args" and "run" and it does NOT segfault. If I run it like this from the command line it segfaults upon resize. Is there any other way to collect the information that would help you to fix the issue?

Leave the -O2 -g on and try again (in gdb).

twmz

hero member

Activity: 737

Merit: 500

Quote from: -ck on July 23, 2011, 08:22:21 PM

Quote from: twmz on July 23, 2011, 08:19:52 PM

Quote from: -ck on July 23, 2011, 08:00:36 PM

[2011-07-24 02:22:31] Failed to init GPU thread 0

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

Great, glad it works, and thanks for testing!

Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?

I was just coming back to say that it actually ramped back up to where it was was 1.3.1. I think it is fine as is now that I understand what to expect.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: twmz on July 23, 2011, 08:19:52 PM

Quote from: -ck on July 23, 2011, 08:00:36 PM

[2011-07-24 02:22:31] Failed to init GPU thread 0

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

Great, glad it works, and thanks for testing!

Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?

twmz

hero member

Activity: 737

Merit: 500

Quote from: -ck on July 23, 2011, 08:00:36 PM

[2011-07-24 02:22:31] Failed to init GPU thread 0

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

[2011-07-24 02:22:31] Failed to init GPU thread 0

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

ancow

full member

Activity: 373

Merit: 100

New trace on OSX (copied latest main.c and ocl.c to the 1.4.0 directory), same parameters as before + debug and verbose output:

Code:

[2011-07-24 02:22:31] Testing pool http://pit.deepbit.net:8332                    
[2011-07-24 02:22:31] Long-polling activated for http://pit.deepbit.net:8332/listenChannel                    
[2011-07-24 02:22:31] Successfully retrieved and deciphered work from pool 0 http://pit.deepbit.net:8332                    
[2011-07-24 02:22:31] Pool 0 http://pit.deepbit.net:8332 active                    
[2011-07-24 02:22:31] Testing pool http://swepool.net:8337                    
[2011-07-24 02:22:31] X-Roll-Ntime found                    
[2011-07-24 02:22:31] Successfully retrieved and deciphered work from pool 1 http://swepool.net:8337                    
[2011-07-24 02:22:31] Pool 1 http://swepool.net:8337 active                    
[2011-07-24 02:22:31] Init GPU thread 0                    
[2011-07-24 02:22:31] List of devices:                    
[2011-07-24 02:22:31]   0       ATI Radeon HD 6750M                    
[2011-07-24 02:22:31] Selected 0: ATI Radeon HD 6750M                    
[2011-07-24 02:22:31] Preferred vector width reported 4                    
[2011-07-24 02:22:31] Max work group size reported 1024                    
[2011-07-24 02:22:31] Loaded binary image poclbm110717ATI Radeon HD 6750Mv2w128long8.bin                    
[2011-07-24 02:22:31] Initialising kernel poclbm110717.cl without BFI_INT patching, 2 vectors and worksize 128                    
[2011-07-24 02:22:31] Creating Command Queue. (clCreateCommandQueue)                    
[2011-07-24 02:22:31] Failed to init GPU thread 0                                                                                                            
[2011-07-24 02:22:31] Init GPU thread 0                                                                                                                      
[2011-07-24 02:22:31] List of devices:                    
[2011-07-24 02:22:31]   0       ATI Radeon HD 6750M                    
[2011-07-24 02:22:31] Selected 0: ATI Radeon HD 6750M                    
[2011-07-24 02:22:31] Preferred vector width reported 4                    
[2011-07-24 02:22:31] Max work group size reported 1024                    
[2011-07-24 02:22:31] Loaded binary image poclbm110717ATI Radeon HD 6750Mv2w128long8.bin                    
[2011-07-24 02:22:31] Initialising kernel poclbm110717.cl without BFI_INT patching, 2 vectors and worksize 128                    
[2011-07-24 02:22:31] Creating Command Queue. (clCreateCommandQueue)                    
[2011-07-24 02:22:31] Failed to init GPU thread 0                    
[2011-07-24 02:22:31] 2 gpu miner threads started                    
[2011-07-24 02:22:31] 0 cpu miner threads started, using SHA256 'c' algorithm.                    
 GPU 0: [0.0 Mh/s] [Q:0  A:0  R:0  HW:0  E:0%  U:0.00/m]
[2011-07-24 02:22:33] Attempting to restart thread 0, idle for more than 60 seconds                    

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 559]
0x00000001000065aa in reinit_gputhread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2880
2880            if (!(pthread_cancel(*thr->pth)) && pthread_join(*thr->pth, NULL)) {
(gdb) backtrace
#0  0x00000001000065aa in reinit_gputhread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2880
#1  0x00000001000065aa in reinit_thread [inlined] () at /Users/XXX/cgminer-1.4.0/main.c:2910
#2  0x00000001000065aa in watchdog_thread (userdata=) at main.c:3019
#3  0x00007fff81b74fd6 in _pthread_start ()
#4  0x00007fff81b74e89 in thread_start ()

I sincerely doubt the "idle for more than 60 seconds" message, especially since the program crashed before it ran that long.

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