Bitcoin Forum
December 06, 2016, 12:28:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 [703] 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4819422 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.
Zich
Hero Member
*****
Offline Offline

Activity: 784



View Profile
January 10, 2014, 09:32:37 AM
 #14041

Don't forget I always create drivers for cgminer that report hashrate based on real shares generated, not some arbitrary amount of hashes done (that doesn't translate into meaningful hashrate). I can happily make you a build that shows you making 2.5TH if you like. Make sure you check your pool to see how many effective shares you're submitting with your other drivers... People don't like the truth.

I want to test again for more long interval but keep getting this error



Looks like a real bug. Can you try a debug build following the directions here please:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

Ok, i will try  Smiley

Update:
From bt full command
Code:

#0  0x00016504 in hash_pop () at cgminer.c:5736
        work = 0x0
        tmp = <optimized out>
        hc = <optimized out>
#1  get_work (thr=0x75838, thr_id=91372) at cgminer.c:5929
        work = 0x0
#2  0x0004154c in nf1_scan (info=0x93918, bitfury=0x75580, thr=0x75838)
    at driver-bitfury.c:910
        ret = 0
#3  bitfury_scanwork (thr=0x75838) at driver-bitfury.c:949
        bitfury = 0x75580
        info = 0x93918
#4  0x0001e4fc in hash_driver_work (mythr=0x75838) at cgminer.c:6551
        diff = {tv_sec = 0, tv_usec = 242146}
        hashes = <optimized out>
        tv_start = {tv_sec = 1389374622, tv_usec = 778640}
        tv_end = {tv_sec = 1389374622, tv_usec = 778640}
        cgpu = 0x75580
        drv = 0x75940
        thr_id = 1
        hashes_done = 0
#5  0x0001090c in miner_thread (userdata=0x75838) at cgminer.c:6605
        mythr = 0x75838
        thr_id = <optimized out>
        cgpu = <optimized out>
        drv = 0x75940
        threadname = "miner/1", '\000' <repeats 16 times>
        __func__ = "miner_thread"
#6  0x40267b04 in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0
No symbol table info available.
#7  0x4037965c in ?? () from /lib/arm-linux-gnueabi/libc.so.6
No symbol table info available.
#8  0x4037965c in ?? () from /lib/arm-linux-gnueabi/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
1481027285
Hero Member
*
Offline Offline

Posts: 1481027285

View Profile Personal Message (Offline)

Ignore
1481027285
Reply with quote  #2

1481027285
Report to moderator
Zich
Hero Member
*****
Offline Offline

Activity: 784



View Profile
January 10, 2014, 11:57:56 AM
 #14042

I just test cgminer3.10.0 on raspi under wheezy without setting to USB 1(delete dwc_otg.speed=1)

Work fine except for the error when start cgminer. After several times restart,  cgminer run fine with nanofury
But after some minute one of nanofury off
Code:
[2014-01-10 19:01:50] NF1 1: Error -7 receiving MCPSPITransfer received 0 of 64
[2014-01-10 19:01:50] NF1 1 failure, disabling!
Fletch
Full Member
***
Offline Offline

Activity: 168


I'll have a steak sandwich and a... steak sandwich


View Profile
January 10, 2014, 03:34:58 PM
 #14043

Sorry if this has been addressed before, but I tried searching and came up empty. I'm trying to find out what the two hashrates for a particular GPU/ASIC/FPGA represent. The total hashrates shown at the top of the UI I understand - on the left a 5 second average and on the right the average since the app was started. For individual GPUs however, I'm confused.

One of my GPUs is currently showing 724.1K/728.7K. The value on the left is very stable and rarely changes, but the value on the right changes constantly (+-1K). It makes perfect sense to me that the value on the left is the 5s average for that particular card. However, if the value on the right is the "total" average since the card started mining, why isn't it even more stable than the value on the left?

Or have I missed anything?

HashPeak - GPU mining hashrate peak detector
BTC: 1FLETCHvcUKosefrcZCLUQTtvx4WvgnYMC
jborkl
Full Member
***
Offline Offline

Activity: 234



View Profile WWW
January 10, 2014, 04:30:09 PM
 #14044

I have spent quite a bit of time with the Chilis figuring out why they do what they do, the best and solid solution is

1. I run them all off of powered USB hubs, none are plugged directly into the computer.
2. They do not like USB 1.1 or USB 3.0 - they will eventually have a problem and hang (to me this seems to be the root issue, but I do not know for sure)

I do not know the cause or why, I really only try to fix things so they don't do it again. This has solved the problem for me.

This also solved the Hex2bin scan failed error, which might be related- I don't know

MrTeal
Legendary
*
Offline Offline

Activity: 1246


View Profile
January 10, 2014, 06:24:28 PM
 #14045

I have spent quite a bit of time with the Chilis figuring out why they do what they do, the best and solid solution is

1. I run them all off of powered USB hubs, none are plugged directly into the computer.
2. They do not like USB 1.1 or USB 3.0 - they will eventually have a problem and hang (to me this seems to be the root issue, but I do not know for sure)

I do not know the cause or why, I really only try to fix things so they don't do it again. This has solved the problem for me.

This also solved the Hex2bin scan failed error, which might be related- I don't know
That's kind of strange, the 5V line on the USB connector isn't even terminated on the board so it's drawing 0mA of current from the USB connector. I can't say I've ever tried using a USB 1.1 hub though, I'm not sure I have one.
When you say eventually they will hang with USB3, how long does it usually take for you? I've had some running for days at a time on USB3.0 on my desktop, but obviously using the USB2.0 differential pair.
jborkl
Full Member
***
Offline Offline

Activity: 234



View Profile WWW
January 10, 2014, 07:53:30 PM
 #14046

Less than 12 hours normally, for 14 units on one host

It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.

3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash

I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0

It has not crashed since, so I have not been able to debug it any further.

This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used

I started noticing that the units on the USB hub were not  hanging, then just started figuring it out from there.


-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
January 10, 2014, 09:30:55 PM
 #14047

Con,

Do you use a 32 bit integer for block reward difficulty anywhere?  eleuthria has pointed out that we are rapidly approaching the point where difficulty will overflow.

https://bitcointalk.org/index.php?topic=406420.0
No I don't.

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

Activity: 1988


Ruu \o/


View Profile WWW
January 10, 2014, 10:33:40 PM
 #14048

Don't forget I always create drivers for cgminer that report hashrate based on real shares generated, not some arbitrary amount of hashes done (that doesn't translate into meaningful hashrate). I can happily make you a build that shows you making 2.5TH if you like. Make sure you check your pool to see how many effective shares you're submitting with your other drivers... People don't like the truth.

I want to test again for more long interval but keep getting this error



Looks like a real bug. Can you try a debug build following the directions here please:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

Ok, i will try  Smiley

Update:
From bt full command
Code:

#0  0x00016504 in hash_pop () at cgminer.c:5736
        work = 0x0
        tmp = <optimized out>
        hc = <optimized out>

Thanks for that.

This actually looks like a bug with the stratum reconnect code in cgminer since it's happening shortly after btcguild is issuing a reconnect (i.e. change address request), and is coincidental that it's happening for you with the nanofury. Unfortunately I don't have the time to debug and fix this at the moment so a workaround would be to use the redirection address you see in your logs directly instead of the standard btcguild pool address (or a different pool). I've just pushed some generic changes to git which might help this but I don't imagine it will be enough.

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

Activity: 1988


Ruu \o/


View Profile WWW
January 10, 2014, 10:36:47 PM
 #14049

Heads up to everyone: I will be travelling from today for just over a week, and while I'll be checking in on the forums, I will be relatively unavailable and unable to do any significant debugging, fixes or updates. Everyone behave while I'm away, mkay?

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

Activity: 104


View Profile
January 10, 2014, 11:21:33 PM
 #14050

Yes Sir :-)

Happy Holidays !
Zich
Hero Member
*****
Offline Offline

Activity: 784



View Profile
January 11, 2014, 03:23:44 AM
 #14051

Thanks for that.

This actually looks like a bug with the stratum reconnect code in cgminer since it's happening shortly after btcguild is issuing a reconnect (i.e. change address request), and is coincidental that it's happening for you with the nanofury. Unfortunately I don't have the time to debug and fix this at the moment so a workaround would be to use the redirection address you see in your logs directly instead of the standard btcguild pool address (or a different pool). I've just pushed some generic changes to git which might help this but I don't imagine it will be enough.

No problem  Grin

And yes, changing to the redirect address work, less error now. Thanks ck & happy holiday  Grin
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
January 11, 2014, 07:17:35 AM
 #14052

Thanks Smiley

Pushed a quick fix to git for a bug that would make cgminer crash on removing some usb devices.

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

Activity: 1078


Ιntergalactic Conciliator


View Profile
January 11, 2014, 12:46:50 PM
 #14053

happy holiday and take a rest men Smiley

loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
January 11, 2014, 12:58:52 PM
 #14054

Yes Sir :-)

Happy Holidays !
+1

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
Amph
Legendary
*
Offline Offline

Activity: 1344



View Profile
January 11, 2014, 02:06:10 PM
 #14055

there is a command that let you see all your best shares?

induktor
Hero Member
*****
Offline Offline

Activity: 523


View Profile
January 11, 2014, 11:46:35 PM
 #14056

With my Chilis I find that they tend to go out in groups as well. I need to start logging to confirm, but they'll run for a week or more without issue and then 4 seem to go out at the same time.
Yes that's common as the failure is at the usb hub level, not at the device level. cgminer tries to reset devices that stop responding but what really needs to be reset is the hub. I guess I could potentially look at the parent device and try to send it a reset but then that would be the wrong thing to do if the device was at fault and not the hub. The errors we get back at the software level are not entirely helpful to distinguish the two.
could it be possible to include an exernal GPIO reset in the program, I mean if the software reset didn't go trough, wait a while, and if still not responding send a GPIO signal, we can use that GPIO port with a small relay and execute a hardware power cycle.
Powell
Sr. Member
****
Offline Offline

Activity: 431


View Profile
January 12, 2014, 02:04:37 AM
 #14057

Heads up to everyone: I will be travelling from today for just over a week, and while I'll be checking in on the forums, I will be relatively unavailable and unable to do any significant debugging, fixes or updates. Everyone behave while I'm away, mkay?

Noooooo!  What if Cgminer catches me on fire!!! Sad
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
January 12, 2014, 01:13:44 PM
 #14058

there is a command that let you see all your best shares?
No, just the value of the best share overall in on the screen.

That is available also via the API summary command, and also best share value per pool via the API pools command.

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
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
January 12, 2014, 01:14:10 PM
 #14059

Heads up to everyone: I will be travelling from today for just over a week, and while I'll be checking in on the forums, I will be relatively unavailable and unable to do any significant debugging, fixes or updates. Everyone behave while I'm away, mkay?

Noooooo!  What if Cgminer catches me on fire!!! Sad
Burn, baby burn.

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
MrTeal
Legendary
*
Offline Offline

Activity: 1246


View Profile
January 13, 2014, 03:33:44 PM
 #14060

Less than 12 hours normally, for 14 units on one host

It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.

3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash

I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0

It has not crashed since, so I have not been able to debug it any further.

This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used

I started noticing that the units on the USB hub were not  hanging, then just started figuring it out from there.
I'll try replacing my hubs. I logged it happening this time, and while only 2 units ended up  not coming back up there were 7 that just stopped working at the same time out of the blue.
Pages: « 1 ... 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 [703] 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 ... 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!