Bitcoin Forum
December 02, 2016, 06:15:02 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 ... 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 [438] 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4814178 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.
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
February 01, 2013, 09:37:37 PM
 #8741


Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.
Super!
My hash rate is about 9200 Mh/s on that host. Probably that is the reason why jgarzik has frequent restarts with his Avalon...

Thanks once again ..I am watching git closely and will compile/upgrade new version immediately and let you know how it goes
10X

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
1480702502
Hero Member
*
Offline Offline

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

1480702502
Report to moderator
1480702502
Hero Member
*
Offline Offline

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

1480702502
Report to moderator
1480702502
Hero Member
*
Offline Offline

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

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

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

1480702502
Report to moderator
1480702502
Hero Member
*
Offline Offline

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

1480702502
Report to moderator
1480702502
Hero Member
*
Offline Offline

Posts: 1480702502

View Profile Personal Message (Offline)

Ignore
1480702502
Reply with quote  #2

1480702502
Report to moderator
PatronDragon
Full Member
***
Offline Offline

Activity: 233

https://yobit.io/?bonus=AWQjZ


View Profile
February 01, 2013, 10:05:19 PM
 #8742

I use 2 videocards 7970 and 5870 but CGminer writes me that the incorrect file of a configuration! Write to me as the configuration file has to look correctly!
CrazyGuy
Legendary
*
Offline Offline

Activity: 1806



View Profile
February 02, 2013, 12:57:38 AM
 #8743

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:
CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Returns the following:
Code:
  curses.TUI...........: FOUND: -lncurses
Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)
Code:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.


I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev

Code:
Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...
So is that the wrong version? (Still no love on the make clean / make) Any clue on how to get the 7.25.0+ version you speak of?
Thank you for your time.

It's still supposed to work with older curls. Somewhere it is thinking you have a later version installed which you don't. Anyway I usually install libcurl4-openssl-dev

I was getting the exact same compilation errors today upgrading from 2.9.6. Ubuntu 12.04 apt-get would not install higher than 7.22.0-3ubuntu4. Instead of messing around with it further, I just went ahead and updated to 12.10 and low and behold, i've now got version 7.27.0 of libcurl4-openssl-dev. CGminer compiles fine now.

ASICPuppy.net ASIC Mining Hardware and Accessories - GekkoScience DL580 Breakout Boards are In Stock!
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 02, 2013, 01:33:29 AM
 #8744

Just for anyone interested while I work on it.

https://github.com/kanoi/cgminer/commits/usb2
Hotplug (currently v0.1) for usbutils.c (that uses libusb) devices.

So far, the usbutils devices are BFL and MMQ
I've been doing all my testing with the BFL (no MMQ testing done yet)
Works fine as it is with BFL already ... and 'should' work with MMQ Smiley

All new devices that are built with usbutils.c will automatically be hotplug also.
(so that will include any ASIC drivers written by us)

I'll get around to converting the Icarus driver to usbutils one day ... to make ICA, CM1 & LOT hotplug also
(though that CM1 name will need a change Tongue ... maybe CMR)
But it's low on the priority at the moment, my todo list has quite a few things in it that I want to do
(including enhancements to this basic hotplug)

Edit:
1) When a usbutils device disappears it says on the screen "ZOMBIE" (not dead)
That's also automatic (like hotplug is)
API says No Device=true
2) Hotplug devices say a message on the screen like:
"Hotplug: BitForce added BFL 2"
3) The Hotplug devices don't show in the device list section of the curses screen
I haven't decided how to handle that yet

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
February 02, 2013, 10:21:26 AM
 #8745

Kon,

I saw your memleak commit an i am testing it already.
However i am not sure though, there might be some other memleaks when calling pool_active which is happening quite often. I am attaching valgrind output just in case

The other stuff seemed not to be freed on cgminer exit which is not an issue:) Or i think so..
10X

==8359== HEAP SUMMARY:
==8359==     in use at exit: 908,508 bytes in 4,143 blocks
==8359==   total heap usage: 31,624 allocs, 27,481 frees, 41,232,886 bytes allocated
==8359==
==8359== 10 bytes in 2 blocks are definitely lost in loss record 24 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F7F0: extract_sockaddr (util.c:871)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 32 bytes in 1 blocks are definitely lost in loss record 73 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x403F4A: string_elist_add (miner.h:528)
==8359==    by 0x404C7F: add_serial (cgminer.c:507)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 35 bytes in 2 blocks are definitely lost in loss record 75 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F810: extract_sockaddr (util.c:872)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 44 bytes in 1 blocks are definitely lost in loss record 82 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: Huh (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 49 bytes in 1 blocks are definitely lost in loss record 89 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: Huh (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 160 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 161 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41C965: main (cgminer.c:6790)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 162 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41CBDD: main (cgminer.c:6850)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 163 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 531 (504 direct, 27 indirect) bytes in 1 blocks are definitely lost in loss record 176 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x405E0D: make_work (cgminer.c:1361)
==8359==    by 0x41CCEC: main (cgminer.c:6886)
==8359==
==8359== 727 (104 direct, 623 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 1,383 (104 direct, 1,279 indirect) bytes in 1 blocks are definitely lost in loss record 187 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 65,432 bytes in 1 blocks are definitely lost in loss record 210 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x425CF6: _io_new (api.c:652)
==8359==    by 0x42DC0D: api (api.c:3684)
==8359==    by 0x412662: api_thread (cgminer.c:4348)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 672,368 (104 direct, 672,264 indirect) bytes in 1 blocks are definitely lost in loss record 212 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: Huh (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== LEAK SUMMARY:
==8359==    definitely lost: 66,418 bytes in 12 blocks
==8359==    indirectly lost: 674,193 bytes in 3,866 blocks
==8359==      possibly lost: 1,152 bytes in 4 blocks
==8359==    still reachable: 166,745 bytes in 261 blocks
==8359==         suppressed: 0 bytes in 0 blocks
==8359== Reachable blocks (those to which a pointer was found) are not shown.
==8359== To see them, rerun with: --leak-check=full --show-reachable=yes
==8359==
==8359== For counts of detected and suppressed errors, rerun with: -v
==8359== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 2 from 2)
 valgrind --lea
ak-check=full ./cgminer --api-port 9999 --per-device-stats --api-
-network --api-listen  -S/dev/ICA0 --icarus-timing=1:38
==8748== Memcheck, a memory error detector
==8748== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8748== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8748== Command: ./cgminer xxxxxxxxxx --api-port 9999 --per-device-stats --api-network --api-listen -S/dev/ICA0 --icarus-timing=1:38
==8748==
 [2013-02-02 12:00:23] Started cgminer 2.10.4

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 02, 2013, 10:44:10 AM
 #8746

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.

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

Activity: 1372


View Profile
February 02, 2013, 12:09:25 PM
 #8747

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.
I know:)
I was wondering if pool_active is causing any additional leak. That is why I posted all the output

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 02, 2013, 12:41:13 PM
 #8748

I have a memory.h overlay that I run on cgminer sometimes (that I wrote myself)
Although it uses 30x the RAM, it also includes an API call to list ALL calls to allocate RAM by filename/line of the code that allocated it, and stats about number allocated, free and number unfreed, amount allocated and freed etc etc (as well as various other very useful memory corruption tests)
I compile that in, once in a blue moon, to see if anything is allocating RAM and not freeing unnecessarily.
The output looks like this:
Code:
...
 cgminer.c:6403 a=1 f=0 d=1 ta=176 tf=0 td=176 ra=12288 rf=0 rd=12288
 cgminer.c:6405 a=21 f=0 d=21 ta=215 tf=0 td=215 ra=258048 rf=0 rd=258048
 cgminer.c:6457 a=1 f=1 d=0 ta=17 tf=17 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6475 a=1 f=1 d=0 ta=104 tf=104 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6480 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 miner.h:552 a=3 f=0 d=3 ta=96 tf=0 td=96 ra=36864 rf=0 rd=36864
 miner.h:553 a=3 f=2 d=1 ta=41 tf=34 td=7 ra=36864 rf=24576 rd=12288
 cgminer.c:1209 a=1 f=1 d=0 ta=20 tf=20 td=0 ra=12288 rf=12288 rd=0
 jansson/memory.c:0 a=99985 f=99656 d=329 ta=4264600 tf=4252207 td=12393 ra=1228644352 rf=1224601600 rd=4042752
 cgminer.c:1147 a=1027 f=1027 d=0 ta=13611 tf=13611 td=0 ra=12619776 rf=12619776 rd=0
 cgminer.c:416 a=12 f=0 d=12 ta=11904 tf=0 td=11904 ra=147456 rf=0 rd=147456
 cgminer.c:420 a=12 f=11 d=1 ta=720 tf=616 td=104 ra=147456 rf=135168 rd=12288
 util.c:896 a=13 f=0 d=13 ta=66 tf=0 td=66 ra=159744 rf=0 rd=159744
 util.c:897 a=13 f=0 d=13 ta=173 tf=0 td=173 ra=159744 rf=0 rd=159744
 util.c:583 a=47555 f=47548 d=7 ta=1864988 tf=1864784 td=204 ra=584355840 rf=584269824 rd=86016
 driver-icarus.c:573 a=2 f=0 d=2 ta=2304 tf=0 td=2304 ra=24576 rf=0 rd=24576
 driver-icarus.c:575 a=2 f=0 d=2 ta=26 tf=0 td=26 ra=24576 rf=0 rd=24576
 cgminer.c:6363 a=3 f=0 d=3 ta=192 tf=0 td=192 ra=36864 rf=0 rd=36864
 cgminer.c:6366 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 cgminer.c:6368 a=7 f=6 d=1 ta=280 tf=216 td=64 ra=86016 rf=73728 rd=12288
 driver-icarus.c:579 a=2 f=1 d=1 ta=40 tf=16 td=24 ra=24576 rf=12288 rd=12288
 driver-icarus.c:588 a=2 f=0 d=2 ta=1680 tf=0 td=1680 ra=24576 rf=0 rd=24576
 usbutils.c:535 a=1 f=0 d=1 ta=280 tf=0 td=280 ra=12288 rf=0 rd=12288
 usbutils.c:1108 a=2 f=0 d=2 ta=96 tf=0 td=96 ra=24576 rf=0 rd=24576
 driver-bitforce.c:173 a=1 f=0 d=1 ta=1152 tf=0 td=1152 ra=12288 rf=0 rd=12288
 usbutils.c:890 a=2 f=0 d=2 ta=144 tf=0 td=144 ra=24576 rf=0 rd=24576
 usbutils.c:893 a=2 f=0 d=2 ta=36 tf=0 td=36 ra=24576 rf=0 rd=24576
 usbutils.c:1021 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1028 a=2 f=0 d=2 ta=29 tf=0 td=29 ra=24576 rf=0 rd=24576
 usbutils.c:1035 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1267 a=5 f=4 d=1 ta=360 tf=240 td=120 ra=61440 rf=49152 rd=12288
 usbutils.c:1270 a=5 f=0 d=5 ta=70000 tf=0 td=70000 ra=122880 rf=0 rd=122880
 driver-bitforce.c:249 a=1 f=0 d=1 ta=28 tf=0 td=28 ra=12288 rf=0 rd=12288
...

Anyway, the point being, yep I do keep an eye on that every so often (or when someone suspects such a problem exists) and have found a couple in the past.

Edit: yes 'r' stands for real amount of ram (as opposed to 't' the requested amount) and yes the massive amount of RAM usage in jansson is almost entirely GBT

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
February 02, 2013, 01:43:42 PM
 #8749

Kano,
Thank for your input.
I am not using GBT only stratum. The part of the problem may be related to latest kon git fix related to submitting stratum work. I am running latest git with fix and looks good for last 5 hours or so. I can be sure if that was major leak eating openwrt RAM after a day or two


Best

PS:if you can take a look at pool_active it will be great. I looked at it but there are some labels (jumps), and i do not know jsoon methods - which of them return pointer (no need to be freed) and which one of them return copies (like strdup). I suspect that in that function can be a memleak also but i am not sure Sad

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 02, 2013, 01:55:35 PM
 #8750

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root      20   0 1282m 4228 2648 S  0.0  0.0   0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
February 02, 2013, 02:12:22 PM
 #8751

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root      20   0 1282m 4228 2648 S  0.0  0.0   0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...

Kano,

You can trust me on that with 2.10.4 before latest commit it was eating 45M of ram for 2-3 days maks:)

I know what i am talking about..
From the other hand:
top

                                          %VSZ
 1519  1513 root     S    64436 104%  20% /usr/bin/cgminer -o mint.bitminter.co

root@cgminer:~# free
             total         used         free       shared      buffers
Mem:         61752        29652        32100            0         3652
-/+ buffers:              26000        35752
Swap:            0            0            0

cgminer  VSZ stays untouched for 5 hours or so and free looks exelent

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
coinotron
Legendary
*
Offline Offline

Activity: 995


View Profile
February 02, 2013, 03:53:33 PM
 #8752

Ckolivas,

Recently we introduced at coinotron.com support for stratum. I spent a lot of time reading logs from my pool looking for bugs.
I discovered strange behavior of cgminer 2.10.4 mining in Stratum mode. From time to time those miners send mining.submit RPC with interchanged extranonce2 and ntime. Like in following example:
 
{"params": ["xxxxx.ltc01", "1936", "510d2a61", "22000000", "5b5c6000"], "id": 1206, "method": "mining.submit"}
                                                    ntime      extranonce2

There are even more exotic interchanges:
{"params": ["yyyy.yy", "510d2d4e", "1963", "06000000", "f7d60000"], "id": 8, "method": "mining.submit"}

Pool rejects such works. Is this known bug or effect of misconfiguration of cgminer?

Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
February 02, 2013, 04:36:19 PM
 #8753

After updating my AMD graphics driver to version 13.2 beta (under Windows 8 ) I deleted the old bin files.
Now Cgminer will crash.
Code:
[2013-02-02 17:42:26] Started cgminer 2.10.4
 [2013-02-02 17:42:26] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2013-02-02 17:42:26] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2013-02-02 17:42:26] CL Platform 0 version: OpenCL 1.2 AMD-APP (1124.2)
 [2013-02-02 17:42:26] Platform 0 devices: 1
 [2013-02-02 17:42:26] 0 Barts
 [2013-02-02 17:42:26] GPU 0 iAdapterIndex 0 strUDID PCI_VEN_1002&DEV_6738&SUBSYS_31001682&REV_00_4&21148ACA&0&0078A iBusNumber 3 iDeviceNumber 0 iFunctionNumber 0 iVendorID 1002 strAdapterName  AMD Radeon HD 6800 Series
 [2013-02-02 17:42:26] GPU 0 AMD Radeon HD 6800 Series hardware monitoring enabled
 [2013-02-02 17:42:26] FTD2XX.DLL failed to load, not using FTDI bitforce autodetect
 [2013-02-02 17:42:26] MMQ looking for 1fc9:0003 but found 046d:c049 instead
 [2013-02-02 17:42:26] MMQ looking for 1fc9:0003 but found 2304:0223 instead
 [2013-02-02 17:42:26] MMQ looking for 1fc9:0003 but found 10de:036c instead
 [2013-02-02 17:42:26] MMQ looking for 1fc9:0003 but found 046a:0011 instead
 [2013-02-02 17:42:26] MMQ looking for 1fc9:0003 but found 10de:036d instead
 [2013-02-02 17:42:26] Not a ZTEX device 046d:c049
 [2013-02-02 17:42:26] Not a ZTEX device 2304:0223
 [2013-02-02 17:42:26] Not a ZTEX device 10de:036c
 [2013-02-02 17:42:26] Not a ZTEX device 046a:0011
 [2013-02-02 17:42:26] Not a ZTEX device 10de:036d
 [2013-02-02 17:42:26] Probing for an alive pool
 [2013-02-02 17:42:26] Popping work to stage thread

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
February 02, 2013, 05:00:38 PM
 #8754

Ok, now, this is wierd.
With this command line it crashes:
Code:
cgminer-debug.exe -u name -p password -o http://localhost:15332 -I 3 --auto-fan --debug 2>log.txt
And here it doesn't:
Code:
cgminer-debug.exe -u name -p password -o http://localhost:15332 -I 3 --auto-fan 2>log.txt
Code:
cgminer-debug.exe caused an Access Violation at location 00457e17 in module cgminer-debug.exe Reading from location 557fe519.

Registers:
eax=557fe519 ebx=0065fb08 ecx=00000020 edx=00000038 esi=00000000 edi=0066ecb0
eip=00457e17 esp=0028f780 ebp=0000000e iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
00457E17  cgminer-debug.exe:00457E17
00456581  cgminer-debug.exe:00456581
6248544D  pthreadGC2.dll:6248544D  pthread_timechange_handler_np
043FFF6C


Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 02, 2013, 09:58:00 PM
 #8755

Ckolivas,

Recently we introduced at coinotron.com support for stratum. I spent a lot of time reading logs from my pool looking for bugs.
I discovered strange behavior of cgminer 2.10.4 mining in Stratum mode. From time to time those miners send mining.submit RPC with interchanged extranonce2 and ntime. Like in following example:
 
{"params": ["xxxxx.ltc01", "1936", "510d2a61", "22000000", "5b5c6000"], "id": 1206, "method": "mining.submit"}
                                                    ntime      extranonce2

There are even more exotic interchanges:
{"params": ["yyyy.yy", "510d2d4e", "1963", "06000000", "f7d60000"], "id": 8, "method": "mining.submit"}

Pool rejects such works. Is this known bug or effect of misconfiguration of cgminer?

Never seen anything like it, and I have no idea how it could happen?

Here's the parsing code:

Code:
job_id = json_array_string(val, 0);
prev_hash = json_array_string(val, 1);
coinbase1 = json_array_string(val, 2);
coinbase2 = json_array_string(val, 3);
bbversion = json_array_string(val, 5);
nbit = json_array_string(val, 6);
ntime = json_array_string(val, 7);
clean = json_is_true(json_array_get(val, 8));

and here's the submit generation code:
Code:
work->ntime = strdup(pool->swork.ntime);

sprintf(s, "{\"params\": [\"%s\", \"%s\", \"%s\", \"%s\", \"%s\"], \"id\": %d, \"method\": \"mining.submit\"}",
pool->rpc_user, work->job_id, work->nonce2, work->ntime, noncehex, sshare->id);

Pretty straight forward so your guess is as good as mine? Unless there's memory corruption going on in the miner because of scrypt's weird and wonderful use of memory, but you're describing a simple swapping which is not like memory corruption. Could you track the message the pool sent when the miner returns something odd to make sure it was sent out ok, because this is the first time this sort of bug has been reported and other scrypt pools have been supporting stratum for a while?

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 02, 2013, 10:21:17 PM
 #8756

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root      20   0 1282m 4228 2648 S  0.0  0.0   0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...

Kano,

You can trust me on that with 2.10.4 before latest commit it was eating 45M of ram for 2-3 days maks:)

I know what i am talking about..
From the other hand:
top
...
Yes I do realise the latest commit has freed an unfreed work item.

My point was simply to say that indeed cgminer doesn't use much memory (without GBT), so it *should* work fine on OpenWRT and rpi FPGA mining
So when it does indeed use lots of memory, there is something worth tracking down and there is an easy way for me to do that.
Even easier, it only involves me making a 1 line change to miner.h, make clean, make and nothing else Smiley

Aside: My default pool list (now only 8 pools + duplicates) no longer includes pools that have GBT for this reason.
Basically, if "java API pools" says "Has GBT = true" the pool is out of the default list Smiley
I do have the larger list in the original file (2 more pools + duplicates) that I can use on the RARE occasion that I need to test GBT
(Edit: and I even now have my own p2pool instance that I can run if needed - but after a bit over a day of that hitting a bad luck streak they had I stopped it Tongue Easy enough to restart if needed)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
coinotron
Legendary
*
Offline Offline

Activity: 995


View Profile
February 03, 2013, 01:14:15 PM
 #8757

Never seen anything like it, and I have no idea how it could happen?

Here's the parsing code:

Code:
job_id = json_array_string(val, 0);
 prev_hash = json_array_string(val, 1);
 coinbase1 = json_array_string(val, 2);
 coinbase2 = json_array_string(val, 3);
 bbversion = json_array_string(val, 5);
 nbit = json_array_string(val, 6);
 ntime = json_array_string(val, 7);
 clean = json_is_true(json_array_get(val, 8));

and here's the submit generation code:
Code:
 work->ntime = strdup(pool->swork.ntime);

  sprintf(s, "{\"params\": [\"%s\", \"%s\", \"%s\", \"%s\", \"%s\"], \"id\": %d, \"method\": \"mining.submit\"}",
   pool->rpc_user, work->job_id, work->nonce2, work->ntime, noncehex, sshare->id);

Pretty straight forward so your guess is as good as mine? Unless there's memory corruption going on in the miner because of scrypt's weird and wonderful use of memory, but you're describing a simple swapping which is not like memory corruption. Could you track the message the pool sent when the miner returns something odd to make sure it was sent out ok, because this is the first time this sort of bug has been reported and other scrypt pools have been supporting stratum for a while?


It is not only swapping values.  jobid, Extranonce2, ntime can be corrupted in many ways.( non hex characters, empty, even " chars ).
I didn't observe any swaps including nonce. This filed seems unaffected.

This issue doesn't occur in neither in BTC nor TRC pool. TRC mining doesn't use scrypt.

Yes I can track all mining.notifications. Here you have example conversation with client 12:

1. Pool sends mining.notification:
Code:
[2013-02-03 11:26:46.688] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 12, Outbound message: {"params": ["3", "xxx", "xxx", "xxx", [], "00000001", "1c0d849c", "510e4975", false], "id": null, "method": "mining.notify"}
2. Miner responds: (1st response is corrupted)
Code:
[2013-02-03 11:26:47.546] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 12,  Inbound message: {"params": ["xxx.elke", "", "", "", "d2af4400"], "id": 10097, "method": "mining.submit"}
[2013-02-03 11:26:54.332] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 12,  Inbound message: {"params": ["xxx.elke", "3", "08000000", "510e4975", "0f1b0e00"], "id": 10098, "method": "mining.submit"}
[2013-02-03 11:26:56.033] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 12,  Inbound message: {"params": ["xxx.elke", "3", "08000000", "510e4975", "ad8d1100"], "id": 10099, "method": "mining.submit"}

There are 17 miners of 8 different users currently mining at LTC stratum pool. All are using cgminer 2.10.4. Only 5 miners (out of 17) doesn't send those corrupted works. Rest of them has 2%-6% of corrupted submissions. If you want I can provide you with larger sample from my log file. Here you have more examples:
Code:
[2013-02-03 11:27:00.619] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 14,  Inbound message: {"params": ["yyy.c1l", "3", "510e4975", "10000000", "d9270a00"], "id": 6356, "method": "mining.submit"}
[2013-02-03 11:27:00.619] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 14, Outbound message: {"id": 6356, "result": null, "error": [28, "Ntime out of range", null]}


[2013-02-03 11:27:17.124] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 1,  Inbound message: {"params": ["zzz.docointron", "4", "F000000", "510e4993", "92f0ad00"], "id": 1274, "method": "mining.submit"}
[2013-02-03 11:27:17.124] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 1, Outbound message: {"id": 1274, "result": null, "error": [26, "Incorrect Extranonce2 size", null]}


[2013-02-03 11:27:48.558] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 11,  Inbound message: {"params": ["bbb.crunch2", "510e49b1", "5", "10000000", "9a3a8300"], "id": 17147, "method": "mining.submit"}
[2013-02-03 11:27:48.558] TraceActivity Verbose: 0 : [AsyncTcpServer], ClientId: 11, Outbound message: {"id": 17147, "result": null, "error": [26, "Incorrect Extranonce2 size", null]}

PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
February 03, 2013, 02:14:41 PM
 #8758

Hello guys, looking for a little advice. I'm running cgminer with Xubuntu Natty on my two rigs and am very happy with the stability and performance. My main PC, that I use daily, is Windoze 7 64bit - and I'm using my spare graphics cards on this to mine when it's switched on. The mobo has integrated Intel HD graphics which I use as the primary connection to my monitor via dvi and secondary to my HD TV via HDMI, leaving the graphics cards free for mining - or so I thought. When mining I still get the "lag" that is associated with mining on my Intel Graphics display, even though it is not being used for mining. Am I missing some kind of setting that will completely separate my integrated graphics from mining leaving it free for general usage without the "lag" issue? I have checked the readme, googled etc but can't seem to find a solution. My PC mobo & CPU support virtualization, so I did try installing Xubuntu on a virtual machine (Oracle VirtualBox) on my PC with the hope of mining that way, but setting up VGA passthrough is beyond my ability/knowledge of linux, as I've only just started using it and have been unable to find a tutorial that I fully understand or feel comfortable using (Linux noob  Grin).

Any help/suggestions or advice would be gratefully accepted.....

Peace.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
Nicksasa
Sr. Member
****
Offline Offline

Activity: 288



View Profile WWW
February 03, 2013, 09:03:05 PM
 #8759

I've noticed the same thing as cointron from the first moment i implemented stratum support.

eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
February 04, 2013, 02:08:23 AM
 #8760

I've noticed the same thing as cointron from the first moment i implemented stratum support.

I've reported this a few times on BTC Guild.  Miners submitting blank/random byte data in ntime/extranonce occasionally.  This was a much older cgminer version that had the problem though, and I think that user stopped submitting bad data after upgrading.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Pages: « 1 ... 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 [438] 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 ... 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!