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

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

[-ck]

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!

Thanks very much

All it would have taken from the hardware manufacturers would have been to manually set the iManufacturer and/or iProduct code on the communication chip they used. Virtually all USB communication chips allow you to do this, but rushing to release shit as quickly as possible with the least effort seems to be the norm for them. I guess I can understand that but it's really not much work at all... it's just that they put precisely zero effort to anything that didn't get their hardware sold ASAP.

I suspect this situation will change now that the hardware wars are completely different and speed to marketing is no longer likely to give any competitive advantage at all now that we're in the power efficiency wars.

[ManeBjorn]

You definitely do not suck.
You have made one of the best mining software programs there is.
Because manufacturers have been lazy is not a reflection on you.
Keep up the great work.  I know I appreciate as well as the mining community as a whole.
You are actually the next interview I am going to pursue for mining software in the next couple weeks after I heal from my surprise surgery on thurs.

I also agree with your stance on the violations of GPL.
Name and shame start the thread.  I have also been starting an outline for an article about this situation.

Thanks again. 

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 

[canford]

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!

Thanks very much

All it would have taken from the hardware manufacturers would have been to manually set the iManufacturer and/or iProduct code on the communication chip they used. Virtually all USB communication chips allow you to do this, but rushing to release shit as quickly as possible with the least effort seems to be the norm for them. I guess I can understand that but it's really not much work at all... it's just that they put precisely zero effort to anything that didn't get their hardware sold ASAP.

I suspect this situation will change now that the hardware wars are completely different and speed to marketing is no longer likely to give any competitive advantage at all now that we're in the power efficiency wars.

Given the chaos, I think cgminer is pretty amazing.  The combination of a new industry, competition between vendors, and the rush-rush-rush mentality driven by constantly increasing bitcoin difficulty produces a lot of anxiety and hurried engineering.  Hopefully things will settle a bit, manufacturers will make identifying their equipment easier, and bitcoin prices will rise enough that miners are not on the razor's edge of profitability all the time.  That last is probably wishful thinking.  I am running 12 U2s, 6 S1s and 3 SP10s, and cgminer powers all of them, no small accomplishment!

[nst6563]

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units?  I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.  

command line:  sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins.  I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.  

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
I've re-cloned and recompiled with different configurations, all of which enable the bitmine_A1 (I also compiled with Avalon as was mentioned in a previous post, some I enabled ALL hardware).  None detect the hardware.
Here are a couple screenshots of what happens when I run cgminer:



Using an rpi (obviously since it's built into the unit) and the following command line with the compiled versions of cgminer 4.5.0

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

I've also tried

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

as well as

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

The command line for the version of cgminer that came with it (3.9.0) is:

Code:

sudo ./cgminer --hotplug=0 --cs=8 --hwreset --stmcu=1 --diff=8 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x --api-listen --api-allow W:127.0.0.1 --api-port 4028 --real-quiet

[zefir]

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units?  I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.  

command line:  sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins.  I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.  

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
[...]

Look, as you noticed by the chosen config options, the upstream cgminer currently supports A1 products from Bitmine only. Without knowing the architecture of a Gridseed (or whatever product using the A1), you won't be able to get it mining (unless it is a 1:1 clone of one of Bitmine's products). If you had the required details, you (or the manufacturer) could write a variant of the A1-board-selector that abstracts the product specific properties and makes it accessible as a vector of A1-chip-chains.

Knowing more or less what I am talking about (I wrote those A1 driver and framework), I suggest you better bother the manufacturer and ask for upstream integration of their private driver (assuming there is one). They essentially have to, i.e. if your product was delivered with a private binary version of cgminer, GPL grants you the right to request the source code. If they refuse to deliver, there are means to deal with GPL violations.

But I guess you were not looking for troubles, so the short answer is this: no, it won't work.

[nst6563]

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units?  I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.  

command line:  sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins.  I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.  

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
[...]

Look, as you noticed by the chosen config options, the upstream cgminer currently supports A1 products from Bitmine only. Without knowing the architecture of a Gridseed (or whatever product using the A1), you won't be able to get it mining (unless it is a 1:1 clone of one of Bitmine's products). If you had the required details, you (or the manufacturer) could write a variant of the A1-board-selector that abstracts the product specific properties and makes it accessible as a vector of A1-chip-chains.

Knowing more or less what I am talking about (I wrote those A1 driver and framework), I suggest you better bother the manufacturer and ask for upstream integration of their private driver (assuming there is one). They essentially have to, i.e. if your product was delivered with a private binary version of cgminer, GPL grants you the right to request the source code. If they refuse to deliver, there are means to deal with GPL violations.

But I guess you were not looking for troubles, so the short answer is this: no, it won't work.

Hey - an answer is an answer right?  At least now I know I'm spinning wheels for nothing and can actually chase down the right path.  I was under the assumption (I know...don't assume) that they were all at least very close hardware wise with the controller and board implementations.
If I were to get the source, what would I do with it then?  I'm not a C coder, so having the source itself won't do me much good to get it working with a more recent version of cgminer.  Would I give it to you to look at to gauge feasability of adding it to upstream?