Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 76. (Read 5805508 times)

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

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

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.

Have they actually posted the driver/code anywhere yet?

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 

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

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.

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://bitcointalksearch.org/topic/what-is-the-forums-policy-on-blatant-software-license-abuse-738936

Hi ck & kano,

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

https://bitcointalksearch.org/topic/m.8381364

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

Peace.

^F-in sweet.

Thanks man!

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.

^ 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,

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

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.

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!

Hi ckolivas,

thanks for the reply, of course I understand, life goes on and there are more important things. anyway, I can run an instance of bfgminer alongside and have that take care of the NF6s.

Many thanks for all the hard work and actually reading and replying to our questions!

tip is on the way.

As I feared, the driver for the NF6 never matured. It doesn't quite run at 3x the speed of the NF2 because that would use too much power, but it should be more than 10.


And no, I'm sorry I don't know why it doesn't run at full speed. It's been a long time since I worked on that driver. I was waiting for Vs3 to get back to me on something about the driver and it never happened and then it looked like these weren't actually going to be sold so I abandoned work on it. My fault. I'll see if I can find the dev unit I got and figure out why but time and life's been rather hard of late.

OK. ckolivas, I tried running the NF6s on their own, but I could not get them to run faster than +/- 10 GH/s. The NF2 runs at 5 GH/s at the optimal setting of 54 bits, but gets unstable above. with bfgminer, the NF6 ran at 15 GH/s, so maybe it's tweaked differently? the NF6 does have 3 times the chips of the NF2 afaik, so should run at 3x the speed, I guess.