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

[kslavik]

ckolivas,

Would you please update KNC version of cgminer to 3.8.4.

Thank you

[HappyS]

Help plz, if I have a laptop connected to several bfl asics, how do I open one window of cgminer for each?

[-ck]

ckolivas,

Would you please update KNC version of cgminer to 3.8.4.

Thank you

Done

[daddyfatsax]

Any chance of getting the Drillbit thumbs integrated? For some reason when I run 2 instances of cgminer, 1 for my BE's and 1 for DB thumbs, my laptop will crash. Not an issue with the laptop, it has been running for over a month with cgminer for the BE's and stratum proxy. 

[kano]

Any chance of getting the Drillbit thumbs integrated? For some reason when I run 2 instances of cgminer, 1 for my BE's and 1 for DB thumbs, my laptop will crash. Not an issue with the laptop, it has been running for over a month with cgminer for the BE's and stratum proxy. 

Haven't got one yet - I'll probably be visiting him soon
So I've no idea what's required to make them work.

[kano]

Help plz, if I have a laptop connected to several bfl asics, how do I open one window of cgminer for each?

Each use:
--usb BAS:1

[daddyfatsax]

Any chance of getting the Drillbit thumbs integrated? For some reason when I run 2 instances of cgminer, 1 for my BE's and 1 for DB thumbs, my laptop will crash. Not an issue with the laptop, it has been running for over a month with cgminer for the BE's and stratum proxy. 

Haven't got one yet - I'll probably be visiting him soon
So I've no idea what's required to make them work.

No problem. Just curious. Keep up the good work!

[mdude77]

My first rig runs r9 290's great with TC 30592. I have several other pc's which have the same cpu and ram and they just give memory buffer size errors. I tried lowering the TC and using 13 intensity but that gives HW errors. I'm not sure why the memory size is different on this one pc. Is there a solution for this?

GPU and scrypt mining is no longer supported by cgminer and offtopic on this thread.

It's still cgminer, so I would say that is on topic. What thread do you think I just downloaded it from. You should have renamed it and started a new thread. Then again you always were a jerk.

Be nice.  It's free.  And it's still the best around. 

M

[crazyates]

I am making a conscious decision and taking a stance to only support bitcoin by doing this and will consider all discussions regarding alternative cryptocurrencies as offtopic from here on. It is absolutely clear that we are in a stage where only ASICs matter in mining bitcoin, and cgminer is moving with the rapidly changing landscape that is bitcoin mining.

I for one was not sorry to read this, and fully support your decision. TY for all you do, and for taking a stance.

[aigeezer]

Thanks. Next test, 3.8.4 please.

Happy to oblige as always.  Test ran for just under 2 hours before a zombie (AMU16) appeared.  Did the usual thing with debug, then stopped the test.

Logfile here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-3.8.4.txt

Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.

 

[-ck]

Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.

Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC

[aigeezer]

Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.

Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC

They have been re-plugging very smoothly for the last few releases, but not so for these "cluster zombies" under 3.8.4 (one cluster of several zombies on each machine, at different times) - each seemed to need a hub replug, but with just the two samples I might not be reporting it precisely enough. No other anomalies for a while though, and no dynamic AMU reallocations since the clusters.

[TwinTurbo]

I recently tried to flash my 2nd Gen 3-card Avalon with the latest CGMiner firmware, but after restarting the box it doesn't seem to start hashing. I finally just reverted back to the August firmware and restarted the box. Everything started hashing immediately again.

Did something change in the latest version that requires the configuration parameters to change or something? Perhaps is the November firmware not intended for the 2nd gen avalon?

Any pointers greatly appreciated!

[-ck]

I recently tried to flash my 2nd Gen 3-card Avalon with the latest CGMiner firmware, but after restarting the box it doesn't seem to start hashing. I finally just reverted back to the August firmware and restarted the box. Everything started hashing immediately again.

Did something change in the latest version that requires the configuration parameters to change or something? Perhaps is the November firmware not intended for the 2nd gen avalon?

Any pointers greatly appreciated!

Yes, the firmware parameters are not compatible so you'd either have to try changing settings and saving them (not sure if this is enough), or resetting settings to default and setting your machine up from scratch (including the whole network setup part).

[Notanon]

Any chance of getting the Drillbit thumbs integrated? For some reason when I run 2 instances of cgminer, 1 for my BE's and 1 for DB thumbs, my laptop will crash. Not an issue with the laptop, it has been running for over a month with cgminer for the BE's and stratum proxy. 

Haven't got one yet - I'll probably be visiting him soon
So I've no idea what's required to make them work.

https://github.com/drillbitsystems/cgminer/releases/latest

That's a link to a forked version of 3.8.1 that Drillbit came up with, that might help to speed things up a bit.

[-ck]

Since the topic of other drivers is coming up more and more often, let me clarify/reiterate the situation regarding mainline cgminer driver support and new devices. If a regular contributor was to come along and prove themselves by extensive repeated quality code contribution to cgminer, I would be happy to include them amongst the official devs for cgminer and add them to the people with git push access to cgminer which currently numbers only the two of us.

If Kano and/or I have been offered new hardware, or offered support to develop drivers for hardware, we will develop and include the code in cgminer and actively maintain and develop it. With various manufacturers we have been engaged on this level at wildly different stages in development. Some very early in hardware development (like cointerra and hashfast), some just before distribution of the product (like BFLSC and bi*fury devices), some after the fact when manufacturer code and hardware has been out for a while (like kncminer and much later for avalon). These examples by no means include everyone. Our involvement in the driver has been proportional to the duration of our involvement.

If someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.

If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.

[Zich]

Bitburner Fury, getting roughly 52~54 gh/s.

I see   . I was dreaming for nanofury to work on Pi with cgminer

[jmc1517]

Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.

Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC

Yes that's correct with the later versions (zombies stay as zombies), although sorry to labour the point, but they usually do re-plug automatically with 3.5.1 and earlier. Usually but not always!  I do get the occasional permanent failure with 3.5.1, but it is quite rare.  Also in 3.5.1, very occasionally an AMU just falls behind and/or just stops handling traffic (Accepted shares stops increasing and/or WU slowly decreases).  Just to clarify

[kslavik]

ckolivas,

Would you please update KNC version of cgminer to 3.8.4.

Thank you

Done

I have been testing 3.8.4 version of cgminer miner for KNC.

It keeps crashing every so often.

Last time it crashed, it threw this error message: "*** Error in `/usr/bin/cgminer': malloc(): smallbin double linked list corrupted: 0xad2387a8 ***"

I would provide more details or core dumps if you tell me how

[aigeezer]

Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.

Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC

Yes that's correct with the later versions (zombies stay as zombies), although sorry to labour the point, but they usually do re-plug automatically with 3.5.1 and earlier. Usually but not always!  I do get the occasional permanent failure with 3.5.1, but it is quite rare.  Also in 3.5.1, very occasionally an AMU just falls behind and/or just stops handling traffic (Accepted shares stops increasing and/or WU slowly decreases).  Just to clarify

We still seem to have differing behaviors. I just got one repluggable zombie in my 3.8.4 run, about 26.5 hours in.

Edit: just got another, also repluggable, a few minutes later.

Edit: and another, about 30 hours in. To summarize, I've had a few repluggable zombies and one cluster of several at once that appeared to require replugging the whole hub. My sense is that 3.8.4 is not reallocating any on-the-fly. My allocations now are AMU15-21, 23-25 and 28-30. I'm pretty sure the reallocation 15-n happened when I replugged the hubs (daisy-chained) and that the few reallocations since then have come from my replugging individual zombies, rather than cgminer detecting and reallocating on its own the way it did in other recent releases.

Edit: Something a bit different. At about 32 hours, the LED came on for AMU29 and I watched its hash rate dwindle to zero on the display. It was not flagged as a zombie though. I waited a few minutes then unplugged it, which caused it to be flagged as AMU0 and labelled a zombie. On replugging, it became AMU31 and the hash rate climbed back to normal. The run continues.

Edit: I eventually had to reboot for unrelated reasons. The followup run gets occasional zombies, all repluggable so far. Recently it had one unit flagged as a zombie and at the same time another with zero hashrate but not flagged. LEDs were on for both and both were repluggable.