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

[-ck]

I run cgminer 4.9.2 on Raspberry Pi 2 and experience constant segfaults (once in every half hour) when Antminer U3 is attached.

I use only minimum set of command line options to start cgminer, just a server URL and login/password (everything else is by default). Source code was taken from official git and compiled with gcc 4.9.2. I used CFLAGS="-O2 -Wall --march=native" compiler option and "--enable-icarus" configuration option. Linux version is 4.1.7.

Other instances of cgminer (configured for Avalon Nano ASICs) work just fine at the same time. Also, I tested same version of cgminer under MacOS X with U3, and it seems to work stable, too. So it looks like some issue with specific setup of cgminer + Antminer U3 + Raspberry Pi 2.

Is it a known problem? Is there any patch around? Anybody interested in core dumps?

If it's a crash only with RPi then it's either a specific software bug that only shows up with the RPi build - or - it's an RPi hardware problem. It's very easy to get unreliability with the RPi simply with a dodgy flash card that's hard to figure out.
Get a backtrace if you can by following the directions here:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If it changes every time it crashes and seems to be random memory corruption it's almost certainly an RPi problem and not a software problem. Many people have run this version of cgminer on RPi without any issues so my bet is on that.

[1715253394]

1715253394

[1715253394]

1715253394

[1715253394]

1715253394

[1715253394]

1715253394

[1715253394]

1715253394

[cameloid]

Actually, crashes do not look random, they always happen at the same place. Here is a couple of examples.

1st:

Code:

GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cgminer...done.
[New LWP 12843]
[New LWP 12852]
[New LWP 12847]
[New LWP 12850]
[New LWP 12844]
[New LWP 12849]
[New LWP 12848]
[New LWP 12846]
[New LWP 12851]
[New LWP 12838]
[New LWP 12839]
[New LWP 12841]
[New LWP 12840]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `cgminer -o stratum+tcp://eu.stratum.bitcoin.cz:3333 -u cameloid.worker2 -p x --'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0004e110 in usb_perform_transfer (cgpu=0xfbec88, intinfo=<optimized out>, epinfo=0, data=0x0, length=-1166715880, transferred=0x1, timeout=0, mode=0, 
    cmd=C_REJECTED, seq=0, cancellable=24, tt=true, usbdev=<optimized out>, usbdev=<optimized out>) at usbutils.c:3097
3097		else if ((endpoint & LIBUSB_ENDPOINT_DIR_MASK) == LIBUSB_ENDPOINT_IN && *transferred)
(gdb) #0  0x0004e110 in usb_perform_transfer (cgpu=0xfbec88, intinfo=<optimized out>, epinfo=0, data=0x0, length=-1166715880, transferred=0x1, timeout=0, mode=0, 
    cmd=C_REJECTED, seq=0, cancellable=24, tt=true, usbdev=<optimized out>, usbdev=<optimized out>) at usbutils.c:3097
        callback_timeout = <optimized out>
        err_retries = <optimized out>
        dev_handle = 0xf882b0
        usb_epinfo = <optimized out>
        ut = {cgsem = {__size = "\000\000\000\000\200\000\000\000\000\000\000\000\000\000\000", __align = 0}, transfer = 0x6fd0051c, cancellable = false, list = {
            next = 0x0, prev = 0x0}}
        endpoint = 129 '\201'
        interrupt = <optimized out>
        err = 0
        errn = 110
        tv_start = {tv_sec = 1446167091, tv_usec = 182376}
        tv_finish = {tv_sec = 1446167091, tv_usec = 217754}
        buf = "\000\000\000\000\205\361\340N\031\234\351\\", '\000' <repeats 499 times>
#1  0x00000000 in ?? ()
No symbol table info available.
(gdb) quit

2nd:

Code:

GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cgminer...done.
[New LWP 13102]
[New LWP 13106]
[New LWP 13099]
[New LWP 13107]
[New LWP 13101]
[New LWP 13100]
[New LWP 13103]
[New LWP 13105]
[New LWP 13111]
[New LWP 13110]
[New LWP 13109]
[New LWP 13108]
[New LWP 13098]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `cgminer -o stratum+tcp://eu.stratum.bitcoin.cz:3333 -u cameloid.worker2 -p x --'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0004e110 in usb_perform_transfer (cgpu=0x1622c88, intinfo=<optimized out>, epinfo=0, data=0x0, length=0, transferred=0x0, timeout=0, mode=0, cmd=C_REJECTED, 
    seq=0, cancellable=false, tt=false, usbdev=<optimized out>, usbdev=<optimized out>) at usbutils.c:3097
3097		else if ((endpoint & LIBUSB_ENDPOINT_DIR_MASK) == LIBUSB_ENDPOINT_IN && *transferred)
(gdb) #0  0x0004e110 in usb_perform_transfer (cgpu=0x1622c88, intinfo=<optimized out>, epinfo=0, data=0x0, length=0, transferred=0x0, timeout=0, mode=0, cmd=C_REJECTED, 
    seq=0, cancellable=false, tt=false, usbdev=<optimized out>, usbdev=<optimized out>) at usbutils.c:3097
        callback_timeout = <optimized out>
        err_retries = <optimized out>
        dev_handle = 0x15ec2b0
        usb_epinfo = <optimized out>
        ut = {cgsem = {__size = "\000\000\000\000\200\000\000\000\000\000\000\000\000\000\000", __align = 0}, transfer = 0x6fd0051c, cancellable = false, list = {
            next = 0x0, prev = 0x0}}
        endpoint = 129 '\201'
        interrupt = <optimized out>
        err = 0
        errn = 110
        tv_start = {tv_sec = 1446169096, tv_usec = 721899}
        tv_finish = {tv_sec = 1446169096, tv_usec = 774762}
        buf = "\000\354A\270\231\227\212~1\221\261\222\370?\002\000\b\000\000\000\b\000\000\000\004\000\000\000\004\000\000\000\006\000\000\000\064\000\000\000\064\000\001\000\064\000\001\000 \001\000\000 \001\000\000\005\000\000\000\004\000\000\000\003\000\000\000T\001\000\000T\001\001\000T\001\001\000\031\000\000\000\031\000\000\000\004\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\000\000\001\000\000\000\001\000\004@\001\000\004@\001\000\005\000\000\000\000\000\001\000\001\000\000\000\374N\001\000\374N\003\000\374N\003\000\324\003\000\000\300\n\000\000\006\000\000\000\000\000\001\000\002\000\000\000\bO\001\000\bO\003\000\bO\003\000\370\000\000\000\370\000\000\000\006\000\000\000\004\000\000\000\004\000\000\000p\001\000\000"...
#1  0x00000000 in ?? ()
No symbol table info available.
(gdb) quit

[kano]

You'd need to actually compile it -g -O0 to get some useful info out of gdb
The gdb dump shows no info about why the stack was corrupted.
As a wild guess try changing line 3000 to buf[1024] instead of buf[512]
This, however, can also simply move the problem if something else is causing it.
(and compiling the code differently can also move a problem)

[mobiletalk]

You'd need to actually compile it -g -O0 to get some useful info out of gdb
The gdb dump shows no info about why the stack was corrupted.
As a wild guess try changing line 3000 to buf[1024] instead of buf[512]
This, however, can also simply move the problem if something else is causing it.
(and compiling the code differently can also move a problem)

Do you have skype or icq. I need help some problem with it.

[kano]

You'd need to actually compile it -g -O0 to get some useful info out of gdb
The gdb dump shows no info about why the stack was corrupted.
As a wild guess try changing line 3000 to buf[1024] instead of buf[512]
This, however, can also simply move the problem if something else is causing it.
(and compiling the code differently can also move a problem)

Do you have skype or icq. I need help some problem with it.

Nope.
Read the README
https://github.com/ckolivas/cgminer/blob/master/README
I also don't do any linux teaching.

[p3yot33at3r]

Well supposedly I'm getting an S7 - so it would be soon after that if it happens.

Hi kano,

A little birdy told me that Yoshi was going to contact you about the S7 actually - maybe drop him a line to remind him? He does forget things sometimes.... 

Hi kano,

Did you receive your S7 yet - or are you still waiting like the rest of us? 

[kano]

S7? What's that?

[Jay_Pal]

S7? What's that?

Isn't that the one you should get after the S6 and before the S8? 

[mm5aes]

S7? What's that?

Isn't that the one you should get after the S6 and before the S8?  

No it's a new entity, a Nativity Calendar Miner, a new heat sink falls off every day apparently .....

[Jay_Pal]

S7? What's that?

Isn't that the one you should get after the S6 and before the S8?  

No it's a new entity, a Nativity Calendar Miner, a new heat sink falls off every day apparently .....

Uh!!! I'd love to buy such calendar!!!
But they are still too expensive for me...

[fullintegrity]

where do i find how to create the file to run the miners? a cgminer .bat file runs inside the extracted cgminer program files? on c drive? i dont get how to initiate the miner? using x3 thunder and ispace.co.uk pool, but dont know the exact .bat file. Anyone have sample, i could plug my pool credentials in or even better, a simple set of instructions?
thanks a mil

[kano]

where do i find how to create the file to run the miners? a cgminer .bat file runs inside the extracted cgminer program files? on c drive? i dont get how to initiate the miner? using x3 thunder and ispace.co.uk pool, but dont know the exact .bat file. Anyone have sample, i could plug my pool credentials in or even better, a simple set of instructions?
thanks a mil

https://github.com/ckolivas/cgminer/blob/master/README#L55

[helipotte]

Anyone had any problems with poor performance of Monarchs using firmware 1.4.5?  Mine all hash at about 25% of their expected rate.  This problem

does not happen with the units I have using firmware 1.4.2 or 1.4.3.  I have tried CGminer 4.9.2 in Windows 7 X64 and with Minera on a beaglebone.

Same issue on both platforms.

[kano]

My monarch died long ago ... that someone else (not BFL) supplied me with.

BFL never contacted us about firmware changes or anything like that (or even about the Monarch until LONG after they should have) so your on your own with support of newer firmware in them since I've no idea at all what might have changed and no way to test it.

[helipotte]

My monarch died long ago ... that someone else (not BFL) supplied me with.

BFL never contacted us about firmware changes or anything like that (or even about the Monarch until LONG after they should have) so your on your own with support of newer firmware in them since I've no idea at all what might have changed and no way to test it.

I am just guessing here but it seem like CGminer is treating this unit (Monarch W/1.4.5 FW) as a "single".  My units all hash at about 60-70Gh.  Maybe incorrect

identification in some way.

[kano]

My monarch died long ago ... that someone else (not BFL) supplied me with.

BFL never contacted us about firmware changes or anything like that (or even about the Monarch until LONG after they should have) so your on your own with support of newer firmware in them since I've no idea at all what might have changed and no way to test it.

I am just guessing here but it seem like CGminer is treating this unit (Monarch W/1.4.5 FW) as a "single".  My units all hash at about 60-70Gh.  Maybe incorrect

identification in some way.

Well if you can try an older version of cgminer and if an older version works and a newer one doesn't then that would relate to identification issues.
However, that won't be the cause of slowing it down, that would more be a case of it not working.

Looking at
https://github.com/ckolivas/cgminer/blob/master/NEWS

I'd guess maybe try a real old one about the time it was working for me ...
I was running an old one back on 19-Jan (last day my moth worked for me)  but I was using 4.6.0 (or try 4.6.1)
If either of them work OK, then the problem is something that someone changed in cgminer since then.

[helipotte]

Older versions Identify it as a "BAS' aka single.  I think back around March, or page 798 of this thread:

https://bitcointalk.org/index.php?topic=28402.msg10844936#msg10844936

-ck updated the driver to properly tell the difference  between a monarch and the older 65nm stuff.  CGminer works great with my older monarchs but these

units all have later firmware (the latest i think) and they behave poorly when using cgminer.  They mine at full speed with that "other" mining software but

it has very high CPU usage with many monarchs connected to one host.

[-ck]

Older versions Identify it as a "BAS' aka single.  I think back around March, or page 798 of this thread:

https://bitcointalk.org/index.php?topic=28402.msg10844936#msg10844936

-ck updated the driver to properly tell the difference  between a monarch and the older 65nm stuff.  CGminer works great with my older monarchs but these

units all have later firmware (the latest i think) and they behave poorly when using cgminer.  They mine at full speed with that "other" mining software but

it has very high CPU usage with many monarchs connected to one host.

This was reported before (I believe by Os2sam) where they updated the firmware and never told us anything, breaking cgminer. We've lost all contact with BFL (which was very tenuous at the best of times anyway) and neither Kano nor I have any working BFL hardware any more to update the software, so there really isn't much choice I'm afraid.

[Bink]

Hearing that some buyers of used S3s on fLeaBay are getting much less hash on their pools, than their rigs show. Seems another go-round of asshats going out of their way to trash legit miner SW devs to line their own pockets.

Let's face it, someone running 6 S3s would have MUCH more than 1.2 TH/s on a pool with a legit cgm on their rigs...

[kano]

Hearing that some buyers of used S3s on fLeaBay are getting much less hash on their pools, than their rigs show. Seems another go-round of asshats going out of their way to trash legit miner SW devs to line their own pockets.

Let's face it, someone running 6 S3s would have MUCH more than 1.2 TH/s on a pool with a legit cgm on their rigs...

Yeah there's one, very much appreciated by me, person on my pool running an S3 24/7 mining to my account.

The best thing to do with the S3 is wipe it back to factory settings (with a firmware from bitmain) then add my update:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS3

His averages 0.44TH/s
Here's an accepted share rate graph of his worker over the last 12 days:

Pretty boring graph - but also pretty consistent.