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.

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 

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.

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!

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!

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 

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!

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.