Bitcoin Forum
December 11, 2016, 12:17:37 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 ... 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4828261 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.
paladin281978
Hero Member
*****
Offline Offline

Activity: 728



View Profile
October 31, 2013, 02:01:59 AM
 #13181

I stay on 3.6.4

1481458657
Hero Member
*
Offline Offline

Posts: 1481458657

View Profile Personal Message (Offline)

Ignore
1481458657
Reply with quote  #2

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

Posts: 1481458657

View Profile Personal Message (Offline)

Ignore
1481458657
Reply with quote  #2

1481458657
Report to moderator
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
October 31, 2013, 10:31:52 AM
 #13182

3.5.1 was stable overnight with my 34 erupters, although in the morning I had "lost" AMUs 17-12 which had been replaced by 34-37, but no zombies and my average hash-rate on Slush over ten rounds was the max I would have expected.

Now trialling the "to" version. Fingers crossed.
aigeezer
Legendary
*
Offline Offline

Activity: 1281


Cryptanalyst castrated by his government, 1952


View Profile
October 31, 2013, 11:50:18 AM
 #13183

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

In that case let me try

http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.exe

After 10.75 hours the "to" version has one zombie, AMU5. I'm not sure how long it was there before I checked. I think the "to" version is the best of the recent candidates on my machine. I'll swap the zombie and keep the run going if I can.

Edit: the swap of AMU5 worked fine, but I just did a double-take looking at the allocations. The AMUs usually start out as AMU 0-12, with BAL0 somewhere in the middle or at the end. Now I have AMU0-4, BAL0, AMU7-8, 11, 14-17 - yikes it just changed again. It's saying AMU5 has gone zombie but there was no AMU5 a moment ago because it had been reallocated when the first zombie showed up. There is an LED on solid, but it's not the erupter that I just swapped. Bottom line - apparent allocation anomalies, and I get the feeling that it might have recovered from errors on its own and done some reallocations without intervention. I'll swap out the new zombie AMU5 and keep going if possible. Total run time now is 11 hours.

Edit: Getting weird. The "second AMU5" was reallocated to AMU18 when it was restarted - as expected. A few seconds later AMU3 went zombie. I think this is the same physical erupter as the original AMU5, which I restarted without moving it to a different location on the hub. Maybe I haven't had enough coffee but I thought it would be known as AMU17. Bottom line - the run seems to be getting flaky now, but my observations may include human error. I'll try to keep the run going though.

Edit: the AMU3 zombie was restarted as AMU19, as expected. Now showing AMU 0 1 2 4 7 8 11 14-19, with BAL 0 after AMU 4.

Edit: about an hour later - the display now says that AMU3 is a zombie - but there was no AMU3 (see list above). The display also shows AMU15 has gone to hashrate zero. Two LEDs are on. I'll keep it all going if possible.

Edit: I unplugged an erupter with its LED on. The display said AMU5 had gone zombie. Five? There was no five. AMU15 had morphed to five, it seems, as it was no longer showing at zero hashrate. Plugged it back in and it got reallocated to AMU20. The list is now AMU 0 1 2 4 BAL0 AMU 7 8 11 14 17-20 then AMU3 showing as a zombie. I imagine 3 will get reallocated to 21 when I restart it.

Edit: Yes, 3 became 21 when plugged back in, and it is slowly climbing back to full hash rate.

Edit: Another hour or so later I find five zombies, listed as AMU 3,5,6,9 and 10 - none of those numbers were in use (see above). Still reported running are AMU 0, 1, 2, 4, 7, 8, 11, 17 and the BAL. I'll start the run from scratch, I think, sticking with "to" candidate.

Edit: Since the restart, the "to" candidate has run for seven hours with no errors or anomalies, still going strong.




-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 12:03:54 PM
 #13184

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

I'd get errors left and right on my AMD box with anything after 3.3.4, I think... until 3.6.4.  So what fixed problems for me caused problems for others.
Since yours got better moving to 3.6.x, can you also test to see if the -to binary does not make things worse for you please?

http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.exe

Thanks!

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

Activity: 56


View Profile
October 31, 2013, 12:31:17 PM
 #13185

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712
Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.
In that case let me try

http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.exe
After 10.75 hours the "to" version has one zombie, AMU5. I'm not sure how long it was there before I checked. I think the "to" version is the best of the recent candidates on my machine. I'll swap the zombie and keep the run going if I can.
ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.

Now here's the interesting bit: I unplugged the zombie AMU 29 and removed it for about 5-10 secs, then plugged it back in.  It hotplugged perfectly as AMU34 and started working and at the same time the errors for AMU 0 stopped.

Wait.... Now I have another zombie AMU 16, and repeated errors from AMU 0.   I have unplugged it and left it out and the errors from AMU 0 have stopped.  The zombie is still showing in the list (I suppose it would as no communication exists with it?)  Anyway, I've now plugged it back in and the zombie has disappeared, to be replaced by AMU 35.  All working normally again for a few minutes, but now more errors and another zombie AMU 16.  This is behaving almost like a memory leak (?) - once the errors start, they keep coming and re-occur more frequently.

I have unplugged AMU 16 - so only 33 erupters plugged in at the moment -and the errors on screen have stopped.

I suspect that if I plug it in again, the errors will restart, but I'll give it one more go. Hotplugged at 12:22 - Recognised as AMU 36 - ...and mining ok again.  I'll leave it while I have lunch and come back in an hour...

Edit: Stopped due to ongoing errors.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-to.txt
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 12:39:19 PM
 #13186

ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read?

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

Activity: 56


View Profile
October 31, 2013, 12:46:47 PM
 #13187

ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read?
All "write" errors in the whole log - including 10 from AMU 20 at 11:44 (probably a red-herring) then:

 [2013-10-31 11:46:28] AMU 29 SendWork usb write err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2013-10-31 11:46:28] AMU29: Comms error (werr=-4 amt=0)
 [2013-10-31 11:46:28] AMU 29 failure, disabling!
 [2013-10-31 11:46:28] Thread 29 being disabled

Edit: logfile here:
 https://dl.dropboxusercontent.com/u/44240170/logfile-to.txt
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 12:49:22 PM
 #13188

ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read?
All "write" errors in the whole log - including 10 from AMU 20 at 11:44 (probably a red-herring) then:

 [2013-10-31 11:46:28] AMU 29 SendWork usb write err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2013-10-31 11:46:28] AMU29: Comms error (werr=-4 amt=0)
 [2013-10-31 11:46:28] AMU 29 failure, disabling!
 [2013-10-31 11:46:28] Thread 29 being disabled

-4 really is the system telling us the device has effectively gone. That's quite different to timeouts, and in fact has been in every one of your logs (appreciate you having posted them by the way). I honestly don't know what this means but it's a very different failure to some kind of runaway process that never times out.

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

Activity: 56


View Profile
October 31, 2013, 12:55:41 PM
 #13189

ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read?
All "write" errors in the whole log - including 10 from AMU 20 at 11:44 (probably a red-herring) then:

 [2013-10-31 11:46:28] AMU 29 SendWork usb write err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2013-10-31 11:46:28] AMU29: Comms error (werr=-4 amt=0)
 [2013-10-31 11:46:28] AMU 29 failure, disabling!
 [2013-10-31 11:46:28] Thread 29 being disabled

-4 really is the system telling us the device has effectively gone. That's quite different to timeouts, and in fact has been in every one of your logs (appreciate you having posted them by the way). I honestly don't know what this means but it's a very different failure to some kind of runaway process that never times out.
Yes it does seem strange.  There are timeouts from a device, then some *other* device goes AWOL without any notice whatsoever.  Anyway, I've now posted the entire logfile if you want to have a look at it.  See Edit* in previous post.
Karin
Member
**
Offline Offline

Activity: 109



View Profile WWW
October 31, 2013, 02:18:19 PM
 #13190

I'm still getting reports from Mac users that 3.6.4 through 3.6.6 won't work with BFL Jalapeños, returning the following line:

Code:
BitForceSC detect (29:6) failed to initialise (incorrect device?)

This only occurs in the new operating system version, Mac OS X 10.9, aka Mavericks, which was a free upgrade for all Mac users.  OS 10.8 and lower work fine.

I wish I could do more to help test, but --usb-dump 0 and --verbose both do not return any additional information.  If there is anything else I can try, please let me know.  Perhaps I'll have them work back through cgminer releases and my Mac binaries (which had different libusb version up until recently when you started including them).

Easiest to use bitcoin/litecoin miner for Mac: AsteroidApp.com | @AsteroidApp | Bitcointalk forum thread
Unofficial cgminer for Mac OS X | sgminer for Mac OS X
forzendiablo
Legendary
*
Offline Offline

Activity: 1246


the grandpa of cryptos


View Profile
October 31, 2013, 08:20:19 PM
 #13191

the 3.6.6 versio nseems super buggy

Aggrophobia
Hero Member
*****
Offline Offline

Activity: 686



View Profile
October 31, 2013, 08:23:40 PM
 #13192

Are nanofurys supported by 3.6.6?
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
October 31, 2013, 09:20:50 PM
 #13193

the 3.6.6 versio nseems super buggy

It's working great for me and others.  But not everyone.  There's some factor about these machines that have problems that the authors haven't been able to pinpoint yet.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 10:03:41 PM
 #13194

the 3.6.6 versio nseems super buggy
That's a super generalisation without details.

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: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 10:28:09 PM
 #13195

Are nanofurys supported by 3.6.6?
No, none of the developers have one and no one has tried to offer us one or contribute any code for one so there's no sign of there being any support for them forthcoming in cgminer.

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

Activity: 1320


Don`t panic! Organize!


View Profile
October 31, 2013, 10:46:48 PM
 #13196

Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit.
Good I have working exe from previous build Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 10:47:21 PM
 #13197

Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit.
Good I have working exe from previous build Smiley

What hardware would that be?

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

Activity: 1320


Don`t panic! Organize!


View Profile
October 31, 2013, 10:59:47 PM
 #13198

Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit.
Good I have working exe from previous build Smiley

What hardware would that be?
2x usb erupter and 1x BFL 30GH/s directly to mobo.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 31, 2013, 11:25:57 PM
 #13199

Latest git is not mining on my machine at all. It is detecting hardware, connecting to pools and just quit.
Good I have working exe from previous build Smiley

What hardware would that be?
2x usb erupter and 1x BFL 30GH/s directly to mobo.

How very odd, I don't think any of the code for those specifically was changed, nor for windows. You sure you're building it ok for your devices if you're building it yourself?

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: 2002


Ruu \o/


View Profile WWW
November 01, 2013, 02:54:11 AM
 #13200

Edit: Since the restart, the "to" candidate has run for seven hours with no errors or anomalies, still going strong.
Here's some more, trying to narrow it down further then please.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-tob.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-tor.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-tow.exe

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 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 ... 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!