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

[centove]

Try the up and down arrows...

That does nothing. Doesn't even most the blinking prompt line.

I should also mention that because of the formatting I can't see any of the 'Settings', 'Pool Management', or 'Display options' messages.

That only works with bfgminer, cgminer don't appear to do any sort of keyboard control.

[Taugeran]

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?

[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

[-ck]

Is there anyway to change the layout.

Currently my 18 erupters show up like this:
(Marked and pasted from the command prompt; no formatting changes made, except for adding a '.' in the brackets to avoid a forum post formatting issue)
But all 18 are crunching away:

(5s):5.942G (avg):5.883Gh/s | A:252  R:0  HW:4  WU:76.0/m

I assume you're on windows if you can't resize your command prompt window. There is compact mode which summarises them only, and you can change your command prompt window by right clicking on the window frame and choosing settings and change the default to more rows.

[-ck]

[snip comments about 'waiting for pool issue']

On further investigation, I've found how this can happen, and have committed a fix for this into git so it should go into the next version. The actual issue goes back quite a way so backtracking versions will not avoid it.

Thanks, heard more comments about people running into it over the weekend from KNC users, who, of course in 0.98 firmware, went to cgminer 3.6.6.

by the way, is this the fix:

- Use a non blocking connect with a 1 second select timeout when initiating
stratum to allow us to iterate over all IPs returned by getaddrinfo in round
robin DNS pools.

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 %

Thanks. No that wasn't the change and it looks like I didn't fix it anyway and it's a separate issue based on post release bug reports. More coming 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

You built it yourself with knc support. Don't do that.

[-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