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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dlasher on November 02, 2013, 11:37:11 AM

upgraded from 3.6.2 to 3.6.6 two days ago, and have twice run into a new issue.

(5) different machines running 3.6.6 at (3) different physical locations, different carriers.

each miner set up for (6) pool entries, (3) btcguild, (2) eligius, (1) deepbit, set to "failover" mode.

I've now had (2) of them completely stall, no new work.

At that point ALL work in/out of cgminer stops..I get idle miner notifications from btcguild, but it doesn't fail down to eligius or deepbit.

For now I'm going back to 3.6.2, but wanted you to know I'd seen something new. I'm sorry I don't have better logs.

No I have not had this reported. There are some issues with pools that use round robin DNS and stratum and possibly you have run into that. There is nothing really different in 3.6.6 versus 3.6.2 if I recall correctly that might have made this come up so if you may well have the same issue with 3.6.2. I've made some changes to the upcoming code that hopefully will help this but a new release is not due out just yet while I keep bashing my head against the AMU wall.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: OgNasty on November 02, 2013, 03:09:07 PM

Any idea why my Blue Fury's aren't being detected? Zadig driver installation went smoothly... Do I need a special command to recognize them or something?

No. Sometimes mine take up to a minute to recognise and initialise properly. Also if you have AMUs, I have heard that they conflict and you may have to unplug and plug the furies back in for the to work concurrently.

jmc1517

newbie

Activity: 56

Merit: 0

Finished 2nd run of cgminer-cgtochop which was started again at 18:50
AMU 26 zombie at 20:42 replugged as AMU 34 at 21:40
AMU 17 zombie at 22:11 and AMU 27 zombie at 22:18
Run stopped at 23:43

Logfile here (without --debug)
https://dl.dropboxusercontent.com/u/44240170/logfile-cgtochop-2.txt

I'll run 3.5.1 overnight and try the "wtf" versions tomorrow...

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: aigeezer on November 02, 2013, 07:06:14 PM

Quote from: -ck on November 02, 2013, 06:39:58 PM

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

cgtochop is going fine for now, 4.5 hours in, but a wtf test is irresistible. Trying it now. Yikes - crashed on launch, not sure why.

I've put a debug enabled wtf in the debug directory. I'd like to debug any crashes too so please follow the instructions for debug and grab the binary from here:
http://ck.kolivas.org/apps/cgminer/debug/

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: -ck on November 02, 2013, 06:39:58 PM

Quote from: jmc1517 on November 02, 2013, 03:00:12 PM

My run with cgminer-tow with --debug produced no errors after running all night and until midday today. Typical.

I've been running cgminer-cgtochop since 13:11
First zombie at 14:40 AMU 16 and error timeouts from AMU 0. Replugged at 14:43 recovered as AMU 34.
Another zombie AMU 16 again, but it's not in the same place (different hub too), so they have auto-renumbered (?)
Replugged the zombie AMU at 17:42 and it came back as AMU 35. Mining normally again.
Run stopped at 18:49 due to broadband problems (BT home hub - don't ask).

I'm continuing the run as it looks the most promising yet

First logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-cgtochop-1.txt

Thanks for that, yes the logfiles are helpful. Despite what it may look like, we are making progress.

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

cgtochop is going fine for now, 4.5 hours in, but a wtf test is irresistible. Trying it now. Yikes - crashed on launch, not sure why.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: jmc1517 on November 02, 2013, 03:00:12 PM

My run with cgminer-tow with --debug produced no errors after running all night and until midday today. Typical.

I've been running cgminer-cgtochop since 13:11
First zombie at 14:40 AMU 16 and error timeouts from AMU 0. Replugged at 14:43 recovered as AMU 34.
Another zombie AMU 16 again, but it's not in the same place (different hub too), so they have auto-renumbered (?)
Replugged the zombie AMU at 17:42 and it came back as AMU 35. Mining normally again.
Run stopped at 18:49 due to broadband problems (BT home hub - don't ask).

I'm continuing the run as it looks the most promising yet

First logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-cgtochop-1.txt

Thanks for that, yes the logfiles are helpful. Despite what it may look like, we are making progress.

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

mastahofdesastah

full member

Activity: 163

Merit: 100

Thx for the answer directly from the Boss

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: chadtn on November 02, 2013, 05:03:24 PM

I built the latest version yesterday and noticed the same issue with only one line of stats showing occasionally. I wondered if it was something I did or just a new change to the format. I haven't taken the time to check the change log yet. heh..

Chad

You have not installed libncurses dev before building

chadtn

sr. member

Activity: 672

Merit: 250

I built the latest version yesterday and noticed the same issue with only one line of stats showing occasionally. I wondered if it was something I did or just a new change to the format. I haven't taken the time to check the change log yet. heh..

Chad

mastahofdesastah

full member

Activity: 163

Merit: 100

Hi guys

I normally use minepeon, and just updated to 3.6.6 with no problem.

But on my Debian machine i got a strange problem. The Bitburners Fury are hashing fine, but cgminer shows only 1 line:

(5s):690.7G (avg):612.9Gh/s | A:312467 R:2922 HW:82996 WU:8563.7/m

Normally i see the Pool stats/Temps etc. on the top, and i want it back.

I tried to reinstall with the "git pull" option, with no success...

i start it with this Option:

/cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u XXXXXXXXXXXXXXXXXX -p x --avalon-options 115200:256:10:50:256 --bitburner-voltage 1200 --avalon-temp 40 --avalon-fan 100 --avalon-cutoff 60

Im sure im making a stupid error. Tried to google it, found nothing..

Can someone help me? Thx

OgNasty

donator

Activity: 4760

Merit: 4323

Leading Crypto Sports Betting & Casino Platform

Any idea why my Blue Fury's aren't being detected? Zadig driver installation went smoothly... Do I need a special command to recognize them or something?

jmc1517

newbie

Activity: 56

Merit: 0

My run with cgminer-tow with --debug produced no errors after running all night and until midday today. Typical.

I've been running cgminer-cgtochop since 13:11
First zombie at 14:40 AMU 16 and error timeouts from AMU 0. Replugged at 14:43 recovered as AMU 34.
Another zombie AMU 16 again, but it's not in the same place (different hub too), so they have auto-renumbered (?)
Replugged the zombie AMU at 17:42 and it came back as AMU 35. Mining normally again.
Run stopped at 18:49 due to broadband problems (BT home hub - don't ask).

I'm continuing the run as it looks the most promising yet

First logfile here:
https://dl.dropboxusercontent.com/u/44240170/logfile-cgtochop-1.txt

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: -ck on November 02, 2013, 08:32:02 AM

Throw that out and try:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cgtochop.exe

cgtochop finally found a zombie after 6+ hours. LEDs had been coming on from time to time, 7+/- seconds typically, but it was fine otherwise. I'll try to hot-swap the zombie.

Edit: the zombie was AMU6. It reassigned to 13 on the swap. The run continues.

Edit: the cgtochop run appeared to freeze about 6.5 hours in. All the LEDs came on at once and the BAL fan slowed to idle. The display looked normal, and the program shut down with the Q command. Of possible relevance - I had just started a lot of unrelated file download activity from another program a moment before the failure. I'll restart it if possible.

dlasher

sr. member

Activity: 467

Merit: 250

Con,

upgraded from 3.6.2 to 3.6.6 two days ago, and have twice run into a new issue.

(5) different machines running 3.6.6 at (3) different physical locations, different carriers.

each miner set up for (6) pool entries, (3) btcguild, (2) eligius, (1) deepbit, set to "failover" mode.

I've now had (2) of them completely stall, no new work.

here's the messages:

Quote

[2013-11-01 17:10:07] Accepted 00cdfacd Diff 318/128 BAS 3 pool 0
[2013-11-01 17:10:07] Accepted 01f1c8fc Diff 131/128 BAS 0 pool 0
[2013-11-01 17:10:08] Accepted 01264c88 Diff 222/128 BAS 1 pool 0
[2013-11-01 17:10:09] Network diff set to 391M
[2013-11-01 17:10:19] Waiting for work to be available from pools.

and

Quote

[2013-11-02 01:38:48] Accepted 009d365c Diff 416/256 BAS 2 pool 0
[2013-11-02 01:38:59] Accepted 000139c9 Diff 53.5K/256 BAS 2 pool 0
[2013-11-02 01:39:05] Network diff set to 391M
[2013-11-02 01:39:15] Waiting for work to be available from pools.

At that point ALL work in/out of cgminer stops..I get idle miner notifications from btcguild, but it doesn't fail down to eligius or deepbit.

For now I'm going back to 3.6.2, but wanted you to know I'd seen something new. I'm sorry I don't have better logs.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: aigeezer on November 02, 2013, 08:17:17 AM

Quote from: -ck on November 01, 2013, 10:02:49 PM

Quote from: aigeezer on November 01, 2013, 09:50:38 PM

Quote from: -ck on November 01, 2013, 09:35:45 PM

Ok well the crash is totally unexpected and may be some other change to the master code instead of the usb comms experiments. Anyway, here's some more...

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

OK. For the heck of it, I tried "tob" with logging/debug on and it has been fine for two hours. I'll switch to chopwsync now.

Edit: Oops, three zombies after three minutes with chopwsync.

Edit: I added logging/debug to chopwsync and it found a zombie! I have to leave for 10 hours or so but I'll look at the log then. Meanwhile I'll run some other version.

Well that didn't last long, thanks.

Throw that out and try:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cgtochop.exe

OK. Running cgtochop now. I hope to have some log files for you shortly.

Would you clarify something, please? Are these tests all intended as replacements for cgminer.exe or cgminer-nogpu.exe? I've been using them as the latter, based on a file-size check from back when we started doing this, but I'm getting the sense that my 7970 has been mining too. Its contribution would be so small these days that it would just look like noise. Anyway, that could be a big confound for all my testing. Gulp.

cgminer.exe -n
will always tell you what it's built for.
These are non-gpu builds since it's only that never ending source of pain, the AMU that we're testing here.

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: -ck on November 01, 2013, 10:02:49 PM

Quote from: aigeezer on November 01, 2013, 09:50:38 PM

Quote from: -ck on November 01, 2013, 09:35:45 PM

Ok well the crash is totally unexpected and may be some other change to the master code instead of the usb comms experiments. Anyway, here's some more...

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

OK. For the heck of it, I tried "tob" with logging/debug on and it has been fine for two hours. I'll switch to chopwsync now.

Edit: Oops, three zombies after three minutes with chopwsync.

Edit: I added logging/debug to chopwsync and it found a zombie! I have to leave for 10 hours or so but I'll look at the log then. Meanwhile I'll run some other version.

Well that didn't last long, thanks.

Throw that out and try:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cgtochop.exe

OK. Running cgtochop now. I hope to have some log files for you shortly.

Would you clarify something, please? Are these tests all intended as replacements for cgminer.exe or cgminer-nogpu.exe? I've been using them as the latter, based on a file-size check from back when we started doing this, but I'm getting the sense that my 7970 has been mining too. Its contribution would be so small these days that it would just look like noise. Anyway, that could be a big confound for all my testing. Gulp.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: aigeezer on November 01, 2013, 09:50:38 PM

Quote from: -ck on November 01, 2013, 09:35:45 PM

Ok well the crash is totally unexpected and may be some other change to the master code instead of the usb comms experiments. Anyway, here's some more...

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

OK. For the heck of it, I tried "tob" with logging/debug on and it has been fine for two hours. I'll switch to chopwsync now.

Edit: Oops, three zombies after three minutes with chopwsync.

Edit: I added logging/debug to chopwsync and it found a zombie! I have to leave for 10 hours or so but I'll look at the log then. Meanwhile I'll run some other version.

Well that didn't last long, thanks.

Throw that out and try:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cgtochop.exe

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: -ck on November 01, 2013, 09:35:45 PM

Ok well the crash is totally unexpected and may be some other change to the master code instead of the usb comms experiments. Anyway, here's some more...

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

OK. For the heck of it, I tried "tob" with logging/debug on and it has been fine for two hours. I'll switch to chopwsync now.

Edit: Oops, three zombies after three minutes with chopwsync.

Edit: I added logging/debug to chopwsync and it found a zombie! I have to leave for 10 hours or so but I'll look at the log then. Meanwhile I'll run some other version.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: aigeezer on November 01, 2013, 07:54:51 AM

Quote from: jmc1517 on November 01, 2013, 07:24:30 AM

As an aside: I've been running 3.5.1 since yesterday midday. No errors, so I'm still happy with it.

So, I've trialled the new 3 above. Got zombies fairly quickly on all of them so terminated the tests soon after they occurred (I can leave them running longer if it would help prove anything).

Results as follows:
cgminer-tob started at 09:33, first zombie at 09:37, 2nd at 9:43. Stopped at 09:44.
cgminer-tor started at 09:48, first zombie at 10:00, 2nd at 10:23. Stopped at 10:41.
cgminer-tow started at 10:45, first zombie AMU 32 after 2 minutes, but must have failed and auto-replugged (?)
as AMU 32 is now showing after AMU 33 in the table.

Logfiles here (without --debug):
https://dl.dropboxusercontent.com/u/44240170/logfile-tob.txt
https://dl.dropboxusercontent.com/u/44240170/logfile-tor.txt
https://dl.dropboxusercontent.com/u/44240170/logfile-tow.txt

Currently running cgminer-tow with --debug. Just on the off-chance of capturing an error...

Just starting to catch up to you. "tob" crashed within seconds. That unhelpful Windows message "cgminer-nogpu has stopped working". On to "tor".

Edit: AMU7 has gone zombie about 15 minutes in to "tor". I'll try "tow" now.

Edit: "cgminer-nogpu.exe has stopped working" after about 15 seconds in "tow". Back to "tob" for a while, I guess.

Edit: "tob" has a zombie on AMU6 for this run about 20 minutes in. Last time it crashed early. Tough stuff to track down.

Edit: ~~just noticed (2 hours in to "tob" run) that there is no LED on, even though AMU6 is still reported as zombie. That's a first, I think~~. Sorry - unit wasn't into socket far enough.

Weird - As I'm typing, all ~~but one~~ (see above) of the LEDs came on solid and the BAL fan has slowed. The display is still updating normally, it seems and everything claims to be hashing. I don't trust it though, so I'll restart it.

Edit: Several more zombies from time to time. Another interesting pattern, unique to "tob" perhaps - I usually get the "cgminer-nogpu has stopped working" crash now when I try to restart a zombie by disconnecting either just it or its whole hub and replugging.

Ok well the crash is totally unexpected and may be some other change to the master code instead of the usb comms experiments. Anyway, here's some more...

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

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: ksenter on November 01, 2013, 07:47:48 PM

By the way, my power blinked for a second, the UPS kept the computer on, and cgminer started saying:
[2013-11-01 17:58:14] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
[2013-11-01 17:58:14] BAL0: RequestQueJob failed (err=-7 amt=0)
Guess it lost the connection to the Little Single. So I hotplugged the usb cable to it, and it recovered.

Wasn't sure if it was supposed to be able to recover without having to unplug/replug the usb cable, so I thought I'd mention it. But it probably had more to do with windows losing the device than cgminer, just mentioning it in case.

My LS seems to handle such situations. It's connected to the same UPS as the 'puter.

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