OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Askit2]

On 3.5.1 I can run it without killing it as often as 20 minutes and all I get for errors are the following.

Code:

 cgminer version 3.5.1 - Started: [2013-10-19 03:00:18]
--------------------------------------------------------------------------------
 (2s):45.65G (avg):47.42Gh/s | A:8921  R:17  HW:113  WU:665.8/m
 ST: 2  SS: 0  NB: 1  LW: 8926  GF: 0  RF: 0
 Connected to multiple pools with block change notify
 Block: 00099e2139b95812...  Diff:268M  Started: [03:00:18]  Best share: 2.92K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BAJ 0:  max 43C 3.89V | 5.573G/5.276Gh/s | A:1014 R: 0 HW: 0 WU: 78.6/m
 BAJ 1:  max 41C 3.85V | 5.078G/5.182Gh/s | A:1096 R: 0 HW: 0 WU: 71.3/m
 BAJ 2:  max 45C 3.62V | 4.972G/4.968Gh/s | A: 842 R: 0 HW: 0 WU: 67.7/m
 BAJ 3:  max 44C 3.86V | 5.111G/5.166Gh/s | A: 853 R:17 HW:24 WU: 73.2/m
 BAJ 4:  max 44C 4.05V | 5.442G/5.449Gh/s | A:1131 R: 0 HW:17 WU: 81.2/m
 BAJ 5:  max 46C 3.71V | 5.469G/5.443Gh/s | A: 957 R: 0 HW:15 WU: 75.4/m
 BAJ 6:  max 47C 2.39V | 5.306G/5.663Gh/s | A:1180 R: 0 HW: 7 WU: 76.4/m
 BAJ 7:  max 41C 3.75V | 2.612G/4.931Gh/s | A: 787 R: 0 HW:50 WU: 71.0/m
 BAJ 8:  max 45C 3.91V | 4.890G/5.407Gh/s | A:1061 R: 0 HW: 0 WU: 72.5/m
--------------------------------------------------------------------------------

 [2013-10-19 03:13:40] Accepted 0b3311d8 Diff 22/9 BAJ 3 pool 3
 [2013-10-19 03:13:42] Accepted 042c66b3 Diff 61/32 BAJ 7 pool 2
 [2013-10-19 03:13:46] BAJ 4 usb read error: LIBUSB_ERROR_IO
 [2013-10-19 03:13:46] BAJ4: RequestQueJobStatus failed (err=-1 amt=0)
 [2013-10-19 03:13:46] BAJ4: result of 1 too small (OK0x0a0x00) ignored
 [2013-10-19 03:13:47] USB: BAJ4 read2 buffering 15 extra bytes
 [2013-10-19 03:13:47] BAJ4: Invalid temp reply: 'ERR:INVALID DATA0x0a0x00'
 [2013-10-19 03:13:47] Pool 0 difficulty changed to 26.264444
 [2013-10-19 03:13:50] Accepted 00e13e15 Diff 290/26 BAJ 6 pool 0
 [2013-10-19 03:13:50] Accepted 07411b78 Diff 35/32 BAJ 8 pool 2
 [2013-10-19 03:13:50] Accepted 1541bc9f Diff 12/9 BAJ 8 pool 3
 [2013-10-19 03:13:51] Accepted 088a7af4 Diff 29/26 BAJ 2 pool 0
 [2013-10-19 03:13:55] Accepted 0aa21363 Diff 24/9 BAJ 4 pool 4
 [2013-10-19 03:13:58] Accepted 08b5fe78 Diff 29/9 BAJ 5 pool 4

or

Code:

 [2013-10-19 03:17:34] Accepted 06d55831 Diff 37/9 BAJ 5 pool 4
 [2013-10-19 03:17:36] Accepted 02f20ba9 Diff 86/9 BAJ 0 pool 4
 [2013-10-19 03:17:37] BAJ 6 usb read error: LIBUSB_ERROR_IO
 [2013-10-19 03:17:37] BAJ6: RequestQueJobStatus failed (err=-1 amt=0)
 [2013-10-19 03:17:38] BAJ6: result of 1 too small (OK0x0a0x00) ignored
 [2013-10-19 03:17:38] USB: BAJ6 read2 buffering 16 extra bytes
 [2013-10-19 03:17:38] BAJ6: Invalid temp reply: 'ERR:INVALID DATA0x0a0x00'
 

Code:

 [2013-10-19 03:19:15] Accepted 03db0146 Diff 66/32 BAJ 0 pool 2
 [2013-10-19 03:19:19] BAJ 6 usb read error: LIBUSB_ERROR_IO
 [2013-10-19 03:19:19] BAJ6: QueJobStatus failed (err=-1 amt=0)
 [2013-10-19 03:19:20] BAJ6: incorrect result count 1 (OK:QUEUED0x00) will try 3
 (OK:QUEUED0x0aINPROCESS:10x0aCOUNT:10x0aBAA5E374CDE767253D2FE7708327EEAF699F92D
2D92550EC4A4DADEB4962B59A,543E943752624E7819100AB6,1,3351D8020x0aOK0x0a0x00)
 

[Taugeran]

cgminer 3.6.x does not support ztex fpgas anymore ?

correct

[-ck]

On 3.5.1 I can run it without killing it as often as 20 minutes and all I get for errors are the following.

Code:

 [2013-10-19 03:19:15] Accepted 03db0146 Diff 66/32 BAJ 0 pool 2
 [2013-10-19 03:19:19] BAJ 6 usb read error: LIBUSB_ERROR_IO
 [2013-10-19 03:19:19] BAJ6: QueJobStatus failed (err=-1 amt=0)
 [2013-10-19 03:19:20] BAJ6: incorrect result count 1 (OK:QUEUED0x00) will try 3
 (OK:QUEUED0x0aINPROCESS:10x0aCOUNT:10x0aBAA5E374CDE767253D2FE7708327EEAF699F92D
2D92550EC4A4DADEB4962B59A,543E943752624E7819100AB6,1,3351D8020x0aOK0x0a0x00)
 

Hmm ok you did get IO errors previously as well. The difference is the newer version made them seen as fatal. Well I'll try to emulate the old behaviour and maybe even try resubmitting the transfers to even improve on the old behaviour. I've updated git master to emulate the old behaviour for now where the errors were non fatal.

EDIT: BTW IO errors still suggest there is something hardware wrong in your setup, dodgy cable, connection etc., even if it works most of the time.

[Roy Badami]

Would it be possible to make it listen to "--bitburner-fury-options" instead of the --avalon-options parameter? That would make it possible to run both Bitburner XX and Bitburner Fury devices in 1 CGminer window.

When using the newest Bitburner Fury firmware, the device now identifies as BBF. Is it possible to add a separate options parameter for the BBF?

I had the same requirement, so I've implemented this here: https://github.com/roybadami/cgminer/commit/c69a130dc1ab0bab81d2ef2c95611b09e411a826

See https://asktom.cf/index.php?topic=294735.msg3369661#msg3369661

I'll submit a pull request soon

roy

[Testit]

3.6.4 seems really stable and works great thanks a lot for your hard work

[Roy Badami]

Would it be possible to make it listen to "--bitburner-fury-options" instead of the --avalon-options parameter? That would make it possible to run both Bitburner XX and Bitburner Fury devices in 1 CGminer window.

When using the newest Bitburner Fury firmware, the device now identifies as BBF. Is it possible to add a separate options parameter for the BBF?

I had the same requirement, so I've implemented this here: https://github.com/roybadami/cgminer/commit/c69a130dc1ab0bab81d2ef2c95611b09e411a826

See https://asktom.cf/index.php?topic=294735.msg3369661#msg3369661

I'll submit a pull request soon

roy

I figured since at least one other person is waiting for this, I'd go ahead and submit a pull request:

https://github.com/ckolivas/cgminer/pull/509

[-ck]

3.6.4 seems really stable and works great thanks a lot for your hard work

Great thanks for the feedback

When reporting back feedback like this can you please give a quick summary of what OS and mining hardware you're all using as well?

[crazyates]

3.6.4 seems really stable and works great thanks a lot for your hard work

Great thanks for the feedback

When reporting back feedback like this can you please give a quick summary of what OS and mining hardware you're all using as well?

3.5 was giving me problems with devices disconnecting, couldn't add them back, and then eventually my system would run out of RAM.

3.6.4 is running great.

Win 8 x64, 8GB RAM, 1x BFL LS, 2 AMUs, and 2 MSI 7950s (separate instance for LTC).

[techman05]

May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4.

My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as"http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved.

Future bug fixes maybe?

[-ck]

May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4.

My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as"http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved.

Future bug fixes maybe?

Um, you do not use tcp by itself anywhere. You're probably thinking of stratum+tcp:// and http:// is implicitly tcp, so your syntax is wrong.

[btc6000]

3.6.4 seems really stable and works great thanks a lot for your hard work

3.3.1 seems to be the most stable on my setup


Cheers,

[Askit2]

The IO error on the devices only seems to happen on Linux not my windows box. When I moved those units to the raspberry pi it started having issues.
I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.

I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.

I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.

Code:

BAJ 1Get Results failed (err=-7 amt=0) [2169.902077]unable to handle kernel NULL pointer dereference at Virtual Address 0000006c
[2169.910398] pyd=c362c000
[2169.918266] [0000006c] *pgd=18ccb831, *pte = 00000000, *ppte=00000000
[2169.929642] Internal Error: Oops: 17 [#1] PREEMPT ARM
Entering kdb (current=0xdbfd2500, pid 2222) Oops: (null)
due to oops @0xc02677b0

Pid: 2222, comm:                ip
cpu: 0      Not tainted (3.6.11+ #371)
PC is at smsc95xx_async_cmd_callback+0x30/0x44
LR is at usb_hcd_giveback_urb+0x60/0xf4
pc : [<c02677b0>]     lr : [<c027244c>]     psr: a0000193
sp : dc9b98d8      ip : 00000000    fp : dc984980
r10 : dc984980   r9 : f298052c       r8 : ffffffb9
r7 : dbe35ba0     r6 : ffffffb9          r5 : c1528d60     r4 : dbf06dc0
r3 : 00000000     r2 : ffffffb9          r1 : 00000000     r0 : dbf06de0
Flags NvCv IRQs off FIQs on Mode svc_32 ISA ARM Segment User
Control:n 00c5387d Table: 03b2c008 DAC: 00000015

After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.

[-ck]

The IO error on the devices only seems to happen on Linux not my windows box. When I moved those units to the raspberry pi it started having issues.
I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.

I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.

I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.


After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.

There's no doubt the USB in the RPi is less reliable than a real PC. Part of the problem is that the network device is actually a USB device low down meaning USB comms are compromised as a result, and it's all on the same bus.

Code:

Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Unfortunately I can't really start digging into kernel code, but I can at least suggest trying a different distro (though I believe I've said that before). I can reliably crash my RPi by just plugging something into the USB slot that draws more power than usual (such as the BF1 stick) without mining even running. Would be interesting to see now that you've built from git whether you get complete failures with transfer errors or just IO errors as a temporary glitch now.

[opentoe]

Can someone point out what each number is and what's it for? Mabe someone that knoiws addendeum this file so we all know what all these numbers  mean, yea?


http://www.photopiks.com/cgminer.jpg

[Pontius]

Can someone point out what each number is and what's it for? Mabe someone that knoiws addendeum this file so we all know what all these numbers  mean, yea?

Check the README (lines 447ff.)...

[techman05]

May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4.

My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as"http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved.

Future bug fixes maybe?

Um, you do not use tcp by itself anywhere. You're probably thinking of stratum+tcp:// and http:// is implicitly tcp, so your syntax is wrong.

So I have to use that whole statement when filling in the address. O.k I'll go change that.

[-ck]

May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4.

My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as"http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved.

Future bug fixes maybe?

Um, you do not use tcp by itself anywhere. You're probably thinking of stratum+tcp:// and http:// is implicitly tcp, so your syntax is wrong.

So I have to use that whole statement when filling in the address. O.k I'll go change that.

Or just leave it out entirely and cgminer will figure out what to do.

[techman05]

When I just did mint.bitminter:3333 cgminer said my information was wrong (Instructions whether I accidentally didn't do verbatim) say put my user_Miner and then doesn't specify password(I got workers doing this once I set it up right starting with just starting the pool address with tcp:\\ option which gave me the errors in my config file.

Either way I notices bitminter came up slow when I restarted and changed my settings and it seems o.k now.

[aigeezer]

3.6.4 seems really stable and works great thanks a lot for your hard work

3.3.1 seems to be the most stable on my setup


Cheers,

Same for me, 3.3.1 is the only version that never failed on the one machine I used it on for weeks. On another machine I updated regularly from 3.4.n through 3.6.4 and always got at least one zombie after a day or so (no big deal) or problems that were much more severe, particularly with 3.6.4. Symptoms have varied but often include loss of Internet access (of all things) which often (but not always) returns if I shut off cgminer. Causality seems very murky and I know my comments are anecdotal only. I'd guess that a memory leak has crept in some time after 3.3.1 but I've done no testing along those lines.

I've discovered that the machine that was stable on 3.3.1 also becomes unstable on 3.5.n and up, which is the main reason I'm posting this. It's not a complaint, but perhaps it will be a useful clue to some obscure issue.

Both machines are core i7 64 running Win7 64. Both use a bunch of erupters and one has a BFL LS as well. At first I thought the instability was caused by the heavier load on one machine but now I'm pretty sure it is not load-dependent.

[HellDiverUK]

Both machines are core i7 64 running Win7 64. Both use a bunch of erupters and one has a BFL LS as well. At first I thought the instability was caused by the heavier load on one machine but now I'm pretty sure it is not load-dependent.

A Raspberry Pi would run ALL your stuff - load has got nothing to do with it, as there isn't any on an i7.

Shit, I have 30GH/s gong through a TPLink 703N (a £10 router powered off USB with a Dorito for a CPU and 8MB RAM).