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

[-ck]

I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me

That's a very insightful observation, thanks, will investigate further.

[-ck]

No point testing any of those earlier ones. Yours looks more resistant to being fixed than aigeezer's too. You have lots of problems... and I have nothing new for you to test at this time.

Well I could suggest going back to the code in 3.5.1 - which seems to work flawlessly for me - but I'm not good at dodging flying objects...!!!  Seriously, I do appreciate all the time and effort you've been putting into this, and if a solution is not forthcoming, then I can happily stay with 3.5.1 or even 3.3.1 for my particular setup.

Last run of 3.7.0 produced one zombie after 2 hours.  I came back after 4 hours, so just the one. Logfile here if required:
 https://dl.dropboxusercontent.com/u/44240170/logfile-3.7.0.txt

Edited to correct formatting.

No, there are too many changes post 3.5.1 that everything else depends on. In the same way new versions come out for other reasons and need bugfixes, the solution is to fix the current  behaviour, not go to the old behaviour.

EDIT: What's interesting is that the pattern is the same every time in your logs. One device disappears and then another has timeouts forever more. However it also seems to keep hashing fine based on the fact that your summary shows the hashrate is the same for AMU0 as the rest.

EDIT2: Here're the next tests (note this is specifically for your issue now since last report aigeezer's was working)
http://ck.kolivas.org/apps/cgminer/temp/cgminer-lt.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-nt.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-et.exe

[-ck]

Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.

Well, no one confirmed whether I had fixed it or not, so I had to run blind. Therefore the bug is still there.

Sorry for the misunderstanding. When I posted my report, it was referred to the latest git master (that's why I suggested users to revert to v3.6.6 instead of just pulling the latest commits). Since no related commit appeared after my post, I thought you were working on a fix and you still had to push it to the git repo. My bad, I should probably have been more explicit.

Try latest git then please.

[aneutronic]

I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time.

It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author %

I'd like to add my thanks also, I've had increases in MHSav with every upgrade on my POS avalon.

I've been running 3.6.6 for a couple of days, best yet other than the minor OOM issue which I'm assuming is from the itty bitty memory in the wr703.


3.7.0 wouldn't start up though:

Code:

[2013-11-04 17:41:04] Started cgminer 3.7.0                    
 [2013-11-04 17:41:04] AVA0: Reset succeeded (Controller version: 2013060665)                    
 [2013-11-04 17:41:05] AVA0: Idling 24 miners                    
 [2013-11-04 17:41:06] Probing for an alive pool                    
 [2013-11-04 17:41:06] Pool 1 difficulty changed to 64                    
 [2013-11-04 17:41:06] Switching to pool 1 stratum+tcp://mmpool.bitparking.com:3333 - first alive pool                    
 [2013-11-04 17:41:06] Pool 0 stratum+tcp://mint.bitminter.com:3333 alive, testing stability                    
 [2013-11-04 17:41:06] Switching to pool 0 stratum+tcp://mint.bitminter.com:3333                    
 [2013-11-04 17:41:06] Pool 0 difficulty changed to 64                    
 [2013-11-04 17:41:06] Network diff set to 17M                    
 [2013-11-04 17:41:06] Stratum from pool 0 requested work restart                    
Segmentation fault

In any case thanks for your dedicated work,  I also think you should add the --donate-author% switch.

[-ck]

I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time.

It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author %

I'd like to add my thanks also, I've had increases in MHSav with every upgrade on my POS avalon.

I've been running 3.6.6 for a couple of days, best yet other than the minor OOM issue which I'm assuming is from the itty bitty memory in the wr703.

3.7.0 wouldn't start up though:

Code:

Segmentation fault

In any case thanks for your dedicated work,  I also think you should add the --donate-author% switch.

Thanks. Later avalon firmware set the --lowmem option. I wonder if your particular firmware isn't setting it? If not, try adding it to the extra options anyway. I see you're building firmware yourself which is pretty brave, as I've not been able to generate good firmware in a while myself since breaking my wrt(and replacing it I've not been able to get it stable). A segmentation fault should be an obvious crash in the code though, but unless you can go digging around creating a debug build, I can't really do much about it. In all honesty I give up and plug the usb cable from my avalon into my pc every time I try to build firmware as I don't have time to work on the wrt any more.

As for the donation option, believe it or not at the moment I'm too busy to add more features, even if it means that feature would give me donations. I am trying freaking hard to stabilise the code currently, and even though bug reports continue, most of the changes are necessary to do away with legacy issues in cgminer that won't stand the test of time, and changes for upcoming hardware that are essential.

EDIT: If I get time I'll try building a binary for the wrt and test it myself but it's quite far down the priority list sorry.

[LB72]

HI


I use cgminer 3.7 and the message :

KnC spi: Can not open SPI device /dev/spidev1.0: No such file or directory

I don't use KNC Miner. How can I disable that ?

OS : Archlinux


Thank you

did you compile from scratch?

Hi,
No I installed cgminer from repo pacman -S cgminer

[aneutronic]

I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time.

It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author %

I'd like to add my thanks also, I've had increases in MHSav with every upgrade on my POS avalon.

I've been running 3.6.6 for a couple of days, best yet other than the minor OOM issue which I'm assuming is from the itty bitty memory in the wr703.

3.7.0 wouldn't start up though:

Code:

Segmentation fault

In any case thanks for your dedicated work,  I also think you should add the --donate-author% switch.

Thanks. Later avalon firmware set the --lowmem option. I wonder if your particular firmware isn't setting it? If not, try adding it to the extra options anyway. I see you're building firmware yourself which is pretty brave, as I've not been able to generate good firmware in a while myself since breaking my wrt(and replacing it I've not been able to get it stable). A segmentation fault should be an obvious crash in the code though, but unless you can go digging around creating a debug build, I can't really do much about it. In all honesty I give up and plug the usb cable from my avalon into my pc every time I try to build firmware as I don't have time to work on the wrt any more.

As for the donation option, believe it or not at the moment I'm too busy to add more features, even if it means that feature would give me donations. I am trying freaking hard to stabilise the code currently, and even though bug reports continue, most of the changes are necessary to do away with legacy issues in cgminer that won't stand the test of time, and changes for upcoming hardware that are essential.

EDIT: If I get time I'll try building a binary for the wrt and test it myself but it's quite far down the priority list sorry.

--lowmem is still being set by default, the output I posted was from trying to start 3.7.0 at the command prompt to see why it wouldn't start and --lowmem was set that time also. The wr703 is a neat little router but it's a poor choice for this. Seriously, a $10,000 miner piloted by a $20 router, you'd think they could of at least spent another $15 and used an rpi FFS.

 It's NBD, maximizing the hashing is most important and it restarts with no problem. Don't worry about creating a build now for these, you have enough on your plate. Not sure how to do the debug build as I don't have a lot of experience but glad to be of help if I can. Let me know what you need and I'll try not to ask too many stupid questions.

[aigeezer]

No point testing any of those earlier ones. Yours looks more resistant to being fixed than aigeezer's too. You have lots of problems... and I have nothing new for you to test at this time.

Well I could suggest going back to the code in 3.5.1 - which seems to work flawlessly for me - but I'm not good at dodging flying objects...!!!  Seriously, I do appreciate all the time and effort you've been putting into this, and if a solution is not forthcoming, then I can happily stay with 3.5.1 or even 3.3.1 for my particular setup.

Last run of 3.7.0 produced one zombie after 2 hours.  I came back after 4 hours, so just the one. Logfile here if required:
 https://dl.dropboxusercontent.com/u/44240170/logfile-3.7.0.txt

Edited to correct formatting.

No, there are too many changes post 3.5.1 that everything else depends on. In the same way new versions come out for other reasons and need bugfixes, the solution is to fix the current  behaviour, not go to the old behaviour.

EDIT: What's interesting is that the pattern is the same every time in your logs. One device disappears and then another has timeouts forever more. However it also seems to keep hashing fine based on the fact that your summary shows the hashrate is the same for AMU0 as the rest.

EDIT2: Here're the next tests (note this is specifically for your issue now since last report aigeezer's was working)
http://ck.kolivas.org/apps/cgminer/temp/cgminer-lt.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-nt.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-et.exe

Yes, mine has been stable on 3.7.0 for 9.5 hours now. I still get heart-stopping LED flares 10 seconds or so at a time, but they always recover so far. I speculate that jmc1517's issues may be related, but who knows? Our configurations seem so similar, at least on the surface. Watching from the sidelines for now, but I'll switch my other Win7 machine over to 3.7.0 tomorrow and see if it's stable now too.

[mdude77]

Might want to update the subject to reflect new version?

M

[-ck]

Might want to update the subject to reflect new version?

Thanks. Maybe I was subconsciously anticipating the need to go to 3.7.1 soon 

[-ck]

HI


I use cgminer 3.7 and the message :

KnC spi: Can not open SPI device /dev/spidev1.0: No such file or directory

I don't use KNC Miner. How can I disable that ?

OS : Archlinux


Thank you

did you compile from scratch?

Hi,
No I installed cgminer from repo pacman -S cgminer

In that case then whoever is maintaining the arch package is enabling things in the default build that {s}he shouldn't.

[loshia]

I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me

That's a very insightful observation, thanks, will investigate further.

10X Con

but after your latest changes (rev 6bc691adb26cad59f0598882cb85488f3f5edbe6 1 parent 42b3cf1
ckolivas authored 18 minutes ago ) it is still not working

What works for me is:

for (i = 0; i < mining_threads; i++) {
      cgpu = mining_thr->cgpu;
      mining_thr->work_restart = true;
      if (cgpu && cgpu->deven == DEV_ENABLED) {
         flush_queue(cgpu);
         cgpu->drv->flush_work(cgpu);
      }
   }


        __func__ = "restart_threads"
#1  0x0000000000412ae6 in test_work_current (work=0x7fe9bc0771f0)
    at cgminer.c:4347
        pool = 0x18577d0
        bedata = "\000\000\000\000\000\000\000\003\263\f2c\020\373\024\065RÕ¡ß¡/\305\375\325\304\325\351%\224", <incomplete sequence \347>
        hexstr = '0' <repeats 15 times>, "3b30c326310fb143552d5a1dfa12fc5fdd5c4d5e925946be7\000g\363Z"
        ret = true
        __func__ = "test_work_current"
#2  0x000000000041bc02 in stratum_rthread (userdata=0x18577d0)
    at cgminer.c:5711
        work = 0x7fe9bc0771f0
        timeout = {tv_sec = 90, tv_usec = 0}
        sel_ret = <optimized out>
        rd = {fds_bits = {1024, 0 <repeats 15 times>}}
        s = 0x7fe9bc0771f0 ""
        pool = 0x18577d0
        threadname = "StratumR/0\000\000\000\000\000"
#3  0x00007fe9cba15e9a in start_thread (arg=0x7fe9b75f6700)
    at pthread_create.c:308
        __res = <optimized out>
        pd = 0x7fe9b75f6700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -183325595836687369,
---Type <return> to continue, or q <return> to quit---
                140642120497280, 140641780591040, 0, 3, 191364403420650487,
                191162282270186487}, mask_was_saved = 0}}, priv = {pad = {0x0,
              0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
              canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#4  0x00007fe9cb7423fd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

[-ck]

I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me

That's a very insightful observation, thanks, will investigate further.

10X Con

but after your latest changes (rev 6bc691adb26cad59f0598882cb85488f3f5edbe6 1 parent 42b3cf1
ckolivas authored 18 minutes ago ) it is still not working

What works for me is:

Code:

for (i = 0; i < mining_threads; i++) {
		cgpu = mining_thr[i]->cgpu;
		mining_thr[i]->work_restart = true;
		if (cgpu && cgpu->deven == DEV_ENABLED) { 
			flush_queue(cgpu);
			cgpu->drv->flush_work(cgpu);
		}
	}

Oh I see, thanks.

[loshia]

I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me

That's a very insightful observation, thanks, will investigate further.

10X Con

but after your latest changes (rev 6bc691adb26cad59f0598882cb85488f3f5edbe6 1 parent 42b3cf1
ckolivas authored 18 minutes ago ) it is still not working

What works for me is:

Code:

for (i = 0; i < mining_threads; i++) {
		cgpu = mining_thr[i]->cgpu;
		mining_thr[i]->work_restart = true;
		if (cgpu && cgpu->deven == DEV_ENABLED) { 
			flush_queue(cgpu);
			cgpu->drv->flush_work(cgpu);
		}
	}

Oh I see, thanks.

if (cgpu && cgpu->deven == DEV_ENABLED) cgpu->drv->flush_work(cgpu);

flush work is not initialized  in this case 

[-ck]

if (cgpu && cgpu->deven == DEV_ENABLED) cgpu->drv->flush_work(cgpu);

flush work is not initialized  in this case 

Updated git. The mining thread shouldn't appear with read lock held so see if that code suffices.

[loshia]

if (cgpu && cgpu->deven == DEV_ENABLED) cgpu->drv->flush_work(cgpu);

flush work is not initialized  in this case 

Updated git. The mining thread shouldn't appear with read lock held so see if that code suffices.

10X
But on my tplinks it sill segfaults from time to times because of it - drv->flush-queue . It is a temporally fix probably. But unfortunately no gdb on my tplink. I hope you will see it on your Avalon unit...

Thank you
Best

[whiteEAGLE]

Hello forum!

Can anybody help me with setting up cgminer on a RPi?
I'm nwe to the RPi and don't really know what i'm doing....
At this time i'm using minepeon and it works so far.
But i want to set up cgminer on Raspbian. Is there a "How to" guide somewhere in the last 666 sides tread

Hope someone has the time to take care of a newbie

Thanks!

[Beastlymac]

Hello forum!

Can anybody help me with setting up cgminer on a RPi?
I'm nwe to the RPi and don't really know what i'm doing....
At this time i'm using minepeon and it works so far.
But i want to set up cgminer on Raspbian. Is there a "How to" guide somewhere in the last 666 sides tread

Hope someone has the time to take care of a newbie

Thanks!

Follow this guide. But change 3.3.4 to 3.7.0
http://www.huement.com/blog/?p=941

[Askit2]

Hello forum!

Can anybody help me with setting up cgminer on a RPi?
I'm nwe to the RPi and don't really know what i'm doing....
At this time i'm using minepeon and it works so far.
But i want to set up cgminer on Raspbian. Is there a "How to" guide somewhere in the last 666 sides tread

Hope someone has the time to take care of a newbie

Thanks!

Don't use Raspbian. Please. All my runtime issues disappeared when working under arch. Please use arch.

If you must use raspbian here is what I did to get everything setup....
First install the requirements to build cgminer. (I would as it makes hotfixes on git useable).
Some of these aren't strictly required. Like you don't need vim or screen. Screen is just awesome though.

Code:

apt-get install vim screen
apt-get install git
apt-get install automake
apt-get install autoconf
apt-get install libcurl4-openssl-dev
apt-get install libusb-1.0.0-dev
apt-get install libncurses5-dev
apt-get install libudev-dev
apt-get install pkg-config
apt-get install libtool

Next build instructions.
Each line is its own command.

Code:

git clone https://github.com/ckolivas/cgminer --branch master

cd cgminer

CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-klondike

make clean

make

Again I would likely use Pacman to get the packages you need to build your own. Pacman is on Arch (What mine peon runs) and works just fine. Hopefully the USB/Memory errors on Raspbian get worked out soon but I got tired of waiting.

EDIT: My instructions are likely dated but the package list is from things Kano and CK posted. The rest are just things I wrote down so I wouldn't forget.

EDIT2: There is one file that needs copied. Look in the readme and follow the code. Really it isn't hard to set it up.

[RaTTuS]

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=54176&p=417366#p417366
works for me raspbian no issues,

for 3.6.1
I don't bother with the libusb just plain cgminer