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

[kenshirothefist]

Hi,

Many of cgminer users are already using NiceHash.com, especially Scrypt and SHA256 ASIC miners; therefore it would be very nice if a small stratum protocol extension called mining.extranonce.subscribe (as described here https://www.nicehash.com/software/#devs) would be implemented into cgminer.

I understand that this is a custom feature and I know you are not very fond of custom features. Nevertheless, there are already many custom features implemented in cgminer to support various ASIC devices and it would be really nice if you could do it since it would improve efficiency for users using cgminer when mining on NiceHash (because no disconnects would be needed when we switch buyers orders internally in our system - there is no other way for us to do it since we can't delegate the work any other way but to cut part of extranonce for ourself). Of course this can be implemented as an optional feature, enabled by a parameter (e.g. "extranonce-subscribe" : true).

It is especially important for this feature to be implemented in cgminer since the majority of ASIC device manufacturers grabs your cgminer, burns it into their devices and in some cases it is hard to put a custom (patched) version into such devices.

This feature has already been included, for example, in the latest sgminer (search for "extranonce" here: https://github.com/nicehash/sgminer/commits/master) or in official sgminer GIT source code at https://github.com/sgminer-dev/sgminer/commits/v5_0

p.s.: I do realize that this is not an optimal implementation; it would be better to extend stratum protocol in such a way that it would make extensions easily auto-detectable, however we can probably consider the stratum protocol not to be worth spending too much time on, since it is a dead end as a centralized protocol ... that's why we proposed this kind of simplified patch.

Thanks and let me know if you need any help!

[1714059916]

1714059916

[1714059916]

1714059916

[1714059916]

1714059916

[1714059916]

1714059916

[1714059916]

1714059916

[1714059916]

1714059916

[AndrewK]

Hey guys,

Having a somewhat detailed problem and I will try my best to explain. My linux skills are so-so... please bare with me.

Recently I purchased an as-is bitburner A1... It has 5 bitmine chips. I can get it running with standard cgminer but it only recognizes/uses one chip.

I then tried to compile cgminer 4.5.0 in order to add: --enable-bitmine_A1.

Ran into a couple errors but the main one was that the compiler couldn't find a reference for PATH_MAX in spi-context.c or .h...

So I included limits.h in spi-context.h... problem solved. Everything built with make and make install.

However, when I run cgminer it exits immediately. So I ran it with --syslog and this is the output I get:

cgminer: SPI: Can not open SPI device /dev/spidev0.0
cgminer: All devices disabled, cannot mine!

The device seems to be installed...

Any help or thoughts would be greatly appreciated.

Thanks!

Additional Info: Running ubuntu 14.04, I have root access and have tried these commands with SUDO as well.

Using lsusb i get:

BUS 003 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

which I just assume is the USB controller IC for the miner.

[Taugeran]

Hey guys,

Having a somewhat detailed problem and I will try my best to explain. My linux skills are so-so... please bare with me.

Recently I purchased an as-is bitburner A1... It has 5 bitmine chips. I can get it running with standard cgminer but it only recognizes/uses one chip.

I then tried to compile cgminer 4.5.0 in order to add: --enable-bitmine_A1.

Ran into a couple errors but the main one was that the compiler couldn't find a reference for PATH_MAX in spi-context.c or .h...

So I included limits.h in spi-context.h... problem solved. Everything built with make and make install.

However, when I run cgminer it exits immediately. So I ran it with --syslog and this is the output I get:

cgminer: SPI: Can not open SPI device /dev/spidev0.0
cgminer: All devices disabled, cannot mine!

The device seems to be installed...

Any help or thoughts would be greatly appreciated.

Thanks!

Additional Info: Running ubuntu 14.04, I have root access and have tried these commands with SUDO as well.

Using lsusb i get:

BUS 003 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

which I just assume is the USB controller IC for the miner.

As far as I know the bitburner series of devices (Avalon, Bitfury and A1) all use Avalon emulated protocol do you have avalon enabled

[AndrewK]

^ so, I tried it with --enable-avalon along with --enable-bitmine_A1...

it worked but I'm still only getting 30gh/s

tried it with --enable-avalon and without --enable-bitmine_A1 and still 30gh/s...

Anything else I could try?

Thanks,

[zefir]

^ so, I tried it with --enable-avalon along with --enable-bitmine_A1...

it worked but I'm still only getting 30gh/s

tried it with --enable-avalon and without --enable-bitmine_A1 and still 30gh/s...

Anything else I could try?

Thanks,

Are you sure the bitburnerA1 is supported by upstream cgminer? When I bought a few of those some months ago, I was pointed to the private repository at https://github.com/someone42/cgminer

Worked for me. Good Luck.

[AndrewK]

^F-in sweet.

Thanks man!

[PatMan]

Hi ck & kano,

Sorry, a bit off topic - but have you read this?:

https://bitcointalk.org/index.php?topic=671189.msg8381364#msg8381364

Interested to hear on what you guys think - PM me if you'd prefer to keep it off your thread 

Peace.

[-ck]

Hi ck & kano,

Sorry, a bit off topic - but have you read this?:

https://bitcointalk.org/index.php?topic=671189.msg8381364#msg8381364

Interested to hear on what you guys think - PM me if you'd prefer to keep it off your thread 

Peace.

I'm not really sure what else there is to say. They're violating the GPL like quite a few Chinese manufacturers have done to date. The only difference is they're the poster child for whom to buy from currently. They have complied in the past with the S1 and S2 so it is possible it's just too far down their care factor unless there's enough outrage over it.

I started a thread a little while ago to get a forum policy on GPL violations so that at least action can be taken at a moderation level in this forum but there is no ruling:
https://bitcointalk.org/index.php?topic=738936.0

[PatMan]

Thanks for the link ck - I wasn't aware of that thread. Reading through it, apart from the couple of posters who are confusing Open Source with Copywrong, it seems that name & shame and/or public pressure seems to be the only option apart from legal avenues then? That's naff. I reckon 90% of miners are very uncomfortable using closed software for obvious reasons, and am surprised that there hasn't been a louder noise about this already.

Public pressure it is then.

If Bitmain were to fall in line, I'm presuming that you guys would then be able to tweak/improve their drivers & implement the security fixes & improvements to cgminer as IYFTech mentioned in the post?

Peace.

[loshia]

I think that all of us shall refuse to buy closed source miners no matter of their origin.
That will be the solution to the problem. But we have to act like a community which ain't going to happen...
Greed is first and then all follows.

Sad
The funny part is that most of overseas bitmain customers and CHINESE MINING EQUIPMENT DISTRIBUTORS are based in us and they just do not care....if they are committing  a crime using/distributing such a software....
But law does not apply in bitcoin world for sure

[IYFTech]

Dear Community,

Our truly apologies for the mis-understanding reported in this Support Thread. We are very willing to share the cgminer code to the Community.
Just reviewed our internal resource again, there is a little mis-communicaton between Customer Service Team and R&D Department. We thought this task was done 3 weeks ago.. 
However, R&D Department is repacking the cgminer code and will upload it to GitHub.com in 3 hours.

Any advice from the Community and Global Customers is appreciated, feel free to contact us via PM or info@bitmaintech.com.

Thank you!

And there you have it 

That's the first of the big boys down - just a few more smaller players to do......

Just goes to show the power of the Bitcoin community if only a few people start making a noise - very happy!

Well done all concerned 

[crazyates]

Dear Community,

Our truly apologies for the mis-understanding reported in this Support Thread. We are very willing to share the cgminer code to the Community.
Just reviewed our internal resource again, there is a little mis-communicaton between Customer Service Team and R&D Department. We thought this task was done 3 weeks ago.. 
However, R&D Department is repacking the cgminer code and will upload it to GitHub.com in 3 hours.

Any advice from the Community and Global Customers is appreciated, feel free to contact us via PM or info@bitmaintech.com.

Thank you!

And there you have it 

That's the first of the big boys down - just a few more smaller players to do......

Just goes to show the power of the Bitcoin community if only a few people start making a noise - very happy!

Well done all concerned 

Have they actually posted the driver/code anywhere yet?

[-ck]

Excellent work. I assume they'll finally update the public git repository they have at https://github.com/bitmaintech/cgminer

It will likely take us a while to digest the changes before we can do anything with their driver to bring it up to speed with current cgminer.

[Axiste]

Its updated! Plenty of drivers showing as updated 2 hours ago, Including a USB3 driver, and all the usuals.

[canford]

I am running 12 Antminer U2's off a dedicated Win7 box.  Usually works fine, but lately I been getting tortured by cgminer thinking one of the 12 is a LIN device:



Rebooting results in the same problem.  The only way to fix it is to shutdown the PC, unpower and repower all 12 of the U2s, then reboot, so it seems like something in the internal miner state itself is the cause.  Then it works again for a couple of days before the problem recurs.  I've tried moving things around between USB ports, same issue.  Any ideas about what is causing this?  Any and all help much appreciated, ckolivas you do an amazing job maintaining cgminer.

Thanks!

[-ck]

I am running 12 Antminer U2's off a dedicated Win7 box.  Usually works fine, but lately I been getting tortured by cgminer thinking one of the 12 is a LIN device:

Rebooting results in the same problem.  The only way to fix it is to shutdown the PC, unpower and repower all 12 of the U2s, then reboot, so it seems like something in the internal miner state itself is the cause.  Then it works again for a couple of days before the problem recurs.  I've tried moving things around between USB ports, same issue.  Any ideas about what is causing this?  Any and all help much appreciated, ckolivas you do an amazing job maintaining cgminer.

Unfortunately a lot of these devices don't have identifiers so the only thing that we have to identify them by is the communication chip they use or the protocol they share (like U2 and R-Box [LIN]), so telling them apart is precarious. You could try telling cgminer to not try to enable any lin devices by adding: --usb LIN:0

[canford]

I am running 12 Antminer U2's off a dedicated Win7 box.  Usually works fine, but lately I been getting tortured by cgminer thinking one of the 12 is a LIN device:

Rebooting results in the same problem.  The only way to fix it is to shutdown the PC, unpower and repower all 12 of the U2s, then reboot, so it seems like something in the internal miner state itself is the cause.  Then it works again for a couple of days before the problem recurs.  I've tried moving things around between USB ports, same issue.  Any ideas about what is causing this?  Any and all help much appreciated, ckolivas you do an amazing job maintaining cgminer.

Unfortunately a lot of these devices don't have identifiers so the only thing that we have to identify them by is the communication chip they use or the protocol they share (like U2 and R-Box [LIN]), so telling them apart is precarious. You could try telling cgminer to not try to enable any lin devices by adding: --usb LIN:0

I tried that, but it just results in a cgminer error:



Is there any way to tell cgminer to look for 12 ANU devices and nothing else?

Thanks!

[os2sam]

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

[-ck]

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

I suck

The code only allows you to restrict by the parent driver type, and ANU and LIN are both icarus (ICA) so there's no workaround for that.

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

Unfortunately the name is based on the first device that had that parent driver and I know BF1 doesn't make much sense for all bitfury devices...

Anyway we didn't anticipate other devices would use variants of the same driver and hadn't worked around this possibility to date, and I kinda forgot 

[Jay_Pal]

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

I suck

The code only allows you to restrict by the parent driver type, and ANU and LIN are both icarus (ICA) so there's no workaround for that.

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

Unfortunately the name is based on the first device that had that parent driver and I know BF1 doesn't make much sense for all bitfury devices...

Anyway we didn't anticipate other devices would use variants of the same driver and hadn't worked around this possibility to date, and I kinda forgot 

IMHO, I don't think you suck.
As far as I've understood, manufacturers have their share of guilty on this since they don't do any effort to distinguish how the devices get recognized.
I understand it isn't quite easy to do, it implies some effort.
But they prefer the easy way as they think we don't mix devices, we only use the ones they manufacture, they are the last water in the desert.
As far as I've followed this topic, I've seen a great effort from you, trying to have CGMiner to recognize them all, when it would be useful if they introduced themselves correctly! (Hey, Hi CGMiner! I'm a Ant Miner S3 siting on /dev/USB0! Could you please include me in the workload?)
Since you are not omniscient, you've been doing a hell of a job, given the lack of help some manufacturers provide.
At least from me, my sincere thank you!