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

[kano]

OK that reply says the latest git should detect it as a BFL SC
So I guess stick with 4.9.0 and when 4.9.2 comes out it should be fixed.
https://github.com/ckolivas/cgminer/blob/master/usbutils.c#L437

[1540006895]

1540006895

[1540006895]

1540006895

[1540006895]

1540006895

[1540006895]

1540006895

[1540006895]

1540006895

[luthermarcus]

hey kano are you working on the s3+ firmware as well?

[kano]

hey kano are you working on the s3+ firmware as well?

I don't have an S3+ only two S3s
But I expect it will work, and I'll ask a guy at Bitmain to check it I guess since he has hundreds of them
- probably just need to select the S3+ advanced menu setting to get S3+ performance.

I've put the basic changes into my git but still a few wrinkles to iron out.

It turns out from a driver point of view, the S3 is a USB S2 with a few settings different.
However they also changed things in the last firmware that means it requires a factory reset after installing the last firmware before it works properly ... and also, that I've not done yet, update the pic firmware, coz the speed dropped considerably on the S3 that I simply updated the firmware without adding any of my changes

Getting there ...

[pekatete]

I've updated the AntS1 binary in my binaries git hub of 4.9.1c cgminer including an IPv6 fix.
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I've also put up a new AntS2 full firmware of current git cgminer 4.9.1+
https://github.com/kanoi/cgminer-binaries/tree/master/AntS2

Just had the chance to update to 4.9.1c from 4.9.1a
I had 4.6.1 installed prior to updating to 4.9.1a (and 4.3.2a before that), and can say without doubt that with 4.9.1a the API was broken 4.9.1c seems to have restored it (at least the non privileged stats polling).

I know this was mentioned before (and I have not yet tried it on the latest), but is it possible to now run the privileged API commands remotely (ie not through putty) with the latest 4.9.1c?

[kano]

I've updated the AntS1 binary in my binaries git hub of 4.9.1c cgminer including an IPv6 fix.
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I've also put up a new AntS2 full firmware of current git cgminer 4.9.1+
https://github.com/kanoi/cgminer-binaries/tree/master/AntS2

Just had the chance to update to 4.9.1c from 4.9.1a
I had 4.6.1 installed prior to updating to 4.9.1a (and 4.3.2a before that), and can say without doubt that with 4.9.1a the API was broken 4.9.1c seems to have restored it (at least the non privileged stats polling).

I know this was mentioned before (and I have not yet tried it on the latest), but is it possible to now run the privileged API commands remotely (ie not through putty) with the latest 4.9.1c?

Well the fix was related to the problem of using partial addresses like 192.168.0/24 instead of 192.168.0.0/24
(the IPv6 code added, removed the commented code that did that )

Using priv commands is to do with the W/R options
To enable remote access priv commands you can allow the local subnet IP/24
e.g. W:192.168.0/24 (if your local subnet is 192.168.0.*)
Or give specific remote IPs access with W:RemoteIP

So for normal access it would look something like:
W:127.0.0.1,W:192.168.0/24,W:A.B.C.D

and thus priv access is given to the local cgminer-api on the miner, any computer in the 192.168.0.* subnet and the remote computer A.B.C.D

You should always have W:127.0.0.1
The others can be R: for read access instead of W: for write/priv access

And of course you can do a lot more than that
https://github.com/ckolivas/cgminer/blob/master/API-README

[pekatete]

Using priv commands is to do with the W/R options
To enable remote access priv commands you can allow the local subnet IP/24
e.g. W:192.168.0/24 (if your local subnet is 192.168.0.*)
Or give specific remote IPs access with W:RemoteIP

So for normal access it would look something like:
W:127.0.0.1,W:192.168.0/24,W:A.B.C.D

and thus priv access is given to the local cgminer-api on the miner, any computer in the 192.168.0.* subnet and the remote computer A.B.C.D

You should always have W:127.0.0.1
The others can be R: for read access instead of W: for write/priv access

And of course you can do a lot more than that
https://github.com/ckolivas/cgminer/blob/master/API-README

Just to clarify, the documentation referenced above sems to contain notation for latter filesystem layouts. For the S1, the config file "seems" to be /etc/config/cgminer, which (at least on my S1's) is not in JSON format.
Here's mine, though I still can not access the priv command remotely (note that I've tried with the specific IP, with just the network and both as below). Also, is it necessary to restart cgminer after editing the file?

Code:

root@antMinerS1:~# vi /etc/config/cgminer

config cgminer 'default'
        option chip_frequency '282'
        option miner_count '24'
        option api-listen 'true'
        option api_allow 'W:127.0.0.1,192.168.1.60,192.168.1/24'
        option more_options '--quiet --api-network'
        option target '60'
        option overheat '70'
        option pool2pw 'x'
        option pool1user 'my.worker3'
        option pool1pw 'x'
        option pool2user '1WQgqP7A2KuQ4WT4273JXZPUf29BAbxf6'
        option pool1url 'stratum+tcp://stratum.bitcoin.cz:3333'
        option pool2url 'stratum+tcp://stratum.kano.is:3333'

[kano]

W:127.0.0.1,192.168.1.60,192.168.1/24

The W: doesn't pass on to the others so the others are effectively R:

You need a W: on the front each one you want full access

e.g.

W:127.0.0.1,W:192.168.1.60,192.168.1/24

will also give 192.168.1.60 full access


... and yes you need to restart cgminer - you can't change the API settings ever on a running cgminer

[pekatete]

W:127.0.0.1,192.168.1.60,192.168.1/24

The W: doesn't pass on to the others so they others are effectively R:

You need a W: on the front each one you want full access

e.g.

W:127.0.0.1,W:192.168.1.60,192.168.1/24

will also give 192.168.1.60 full access

Ahh! The detail of prepending the W on each IP / range evaded me ..... and that for ages! I had resorted to the insecure S5 default of W:0/0
Thanks for clarifying .....

EDIT: I've been palying with this today and had reverted to 4.9.1a to check .... and it seems to be working OK (even for non priv polling), so I'll have to strike out my earlier comment about 4.9.1a breaking the API (and blame it on the gremlins).

[minerjoen]

Hey guys,

There were i am still using CGminer 4.8.0 i also want to test the newest version 4.9 / 4.9.1, however when i use the same .bat file from 4.8.0 ( what is working perfectly ) my command prompt is opening and close directly.
So the only thing i did was taking the .bat file from 4.8.0 and place it in the 4.9 and 4.9.1 ( tested both ) but cgminer wont open, yeah well just for 0.5 sec and it close directly.

I try to read as much as possible on this topic, but i cant find the answer on my question. I dont get a message that he dont support or see my miner ( because that's easy to fix ), but my miner (cgminer) just wont start running..

The miner i am using for test is an antminer u3. 4.8 is working ''fine'' but i hope the newer version give me a stable hash rate, because with 4.8 i get on the U3 a hashrate from 50ghs / 66 ghs. So 4.8 is not that stable.

The .bat file i am using on 4.8 (but not working on 4.9/4.9.1) on Windows7 is:
cgminer.exe --bmsc-options 115200:0.57 -o stratum+tcp://notimportant.com -u 2XdsyV7ThMVPalsonotimportantoL1ctW1rJDk -p x --bmsc-voltage 0800  --bmsc-freq 1286


Hope to get a sollution in here

[kano]

You at least need to open a command prompt and run the command and see what the error is.
More details if you add -D --verbose to the cgminer options.
But most likely it will show without them.
Also ... cgminer -n will tell you what hardware it finds.

[minerjoen]

You at least need to open a command prompt and run the command and see what the error is.
More details if you add -D --verbose to the cgminer options.
But most likely it will show without them.
Also ... cgminer -n will tell you what hardware it finds.

like: cgminer.exe -D --verbose --bmsc-options 115200:0.57 -o stratum+tcp://hashgoal.com:3332 -u 2XdsyV7ThMVPp65PxSmWmjpoL1ctW1rJDk -p x --bmsc-voltage 0800  --bmsc-freq 1286
?
because of i do this, i get nothing to see.

[os2sam]

You at least need to open a command prompt and run the command and see what the error is.
More details if you add -D --verbose to the cgminer options.
But most likely it will show without them.
Also ... cgminer -n will tell you what hardware it finds.

like: cgminer.exe -D --verbose --bmsc-options 115200:0.57 -o stratum+tcp://hashgoal.com:3332 -u 2XdsyV7ThMVPp65PxSmWmjpoL1ctW1rJDk -p x --bmsc-voltage 0800  --bmsc-freq 1286
?
because of i do this, i get nothing to see.

That's what you do 2nd.  First you run your original command line in a DOS window and see what you get.

[hurricandave]

When he wrote and saved the original bat file, it was saved in the 4.8* folder and most likely has that path defined in the hidden part of the titled path. Try deleting the bat file in 4.9*. Navigate to 4.8*,  open the old bat file in edit, then left click and drag over its text, select copy. Close that session. Open the 4.9* CGminer folder and create a new text file in it. Open that file with notebook/edit and right click to Paste your text/only from the original bat file. Now save it in 4.9* as a bat and see if it works.

Quote- So the only thing i did was taking the .bat file from 4.8.0 and place it in the 4.9 and 4.9.1 ( tested both ) but cgminer wont open, yeah well just for 0.5 sec and it close directly.

[os2sam]

I had a Monarch die so I had to send it in.  It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe.  If I use the "special" version of BFGMiner on a 64 bit machine it hash's fine.  It used to hash fine with CGMiner too.  Any idea's?
Thanks,
Sam

[kano]

You at least need to open a command prompt and run the command and see what the error is.
More details if you add -D --verbose to the cgminer options.
But most likely it will show without them.
Also ... cgminer -n will tell you what hardware it finds.

like: cgminer.exe -D --verbose --bmsc-options 115200:0.57 -o stratum+tcp://hashgoal.com:3332 -u 2XdsyV7ThMVPp65PxSmWmjpoL1ctW1rJDk -p x --bmsc-voltage 0800  --bmsc-freq 1286
?
because of i do this, i get nothing to see.

That's not cgminer.
There never has been and never will be --bmsc options in cgminer.
It's some manufacturers version you were running before.

If you ran it on the command line it will tell you that there's a problem with your options.
Something like:
[2015-06-07 13:06:24] ./cgminer: --bmsc-options: unrecognized option

With the official master cgminer 4.9.1 you most probably want to be using the icarus driver options if that is a bitmain U1/U2/U3
However, as with all of our drivers we write, you don't have to supply any device options to make them work in default settings.

For the U3, the options (if you wish to change the default working options) are --au3-freq, --au3-volt and --icarus-options
See the ASIC-README
https://github.com/ckolivas/cgminer/blob/master/ASIC-README

[kano]

I had a Monarch die so I had to send it in.  It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe.  If I use the "special" version of BFGMiner on a 64 bit machine it hash's fine.  It used to hash fine with CGMiner too.  Any idea's?
Thanks,
Sam

My old monarch died quite a while ago - well it stopped working each time I tried it for a few days and I gave up on it.
Try a few older versions of cgminer and see if any of the changes to the BFL drivers caused a problem that needs to be fixed.
Otherwise I guess they could have changed the hardware ... and, well, that means bye-bye to having the monarch work with cgminer.

[-ck]

I had a Monarch die so I had to send it in.  It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe.

My guess is yet another USB identity to confuse cgminer further, possibly even intentionally from their end. Do the usual and get the dump of adding "-D -T 2>log.txt" to your cgminer commands on startup and dump the contents of log.txt here to see what cgminer makes of it.

[os2sam]

I had a Monarch die so I had to send it in.  It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe.

My guess is yet another USB identity to confuse cgminer further, possibly even intentionally from their end. Do the usual and get the dump of adding "-D -T 2>log.txt" to your cgminer commands on startup and dump the contents of log.txt here to see what cgminer makes of it.

Code:

C:\Bitcoin\cgm491>cgminer -D -T
 [2015-06-03 21:12:17] Started cgminer 4.9.1
[2015-06-03 21:13:15] BAS looking for and found BAS 0403:6014
[2015-06-03 21:13:15] USB lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock=1
[2015-06-03 21:13:15] USB res lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock ok=1
[2015-06-03 21:13:15] USB init, iManufacturer mismatch - BAS device 5:1
[2015-06-03 21:13:15] Found BUTTERFLY LABS vs Butterfly Labs
[2015-06-03 21:13:15] USB free BAS
[2015-06-03 21:13:15] USB init - BMA device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9SV3'
[2015-06-03 21:13:15] BMA0: reset got err 0
[2015-06-03 21:13:15] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:15] BMA0: setdata got err 0
[2015-06-03 21:13:15] BMA0: setbaud got err 0
[2015-06-03 21:13:15] BMA0: setflowctrl got err 0
[2015-06-03 21:13:15] BMA0: setmodemctrl got err 0
[2015-06-03 21:13:16] BMA0: purgetx got err 0
[2015-06-03 21:13:16] BMA0: purgerx got err 0
[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2
[2015-06-03 21:13:16] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:16] BitForceSC (5:1) identified as: 'BMA'


C:\Bitcoin\cgm491>cgminer -n
 [2015-06-03 21:18:11] USB all: found 31 devices - listing known devices
.USB dev 0: Bus 5 Device 1 ID: 0403:6014
  Manufacturer: 'BUTTERFLY LABS'
  Product: 'BitFORCE SHA256 SC'

Here's the portion that was relevant last time.  Let me know if you need the entire dump.
Thanks,
Sam

[-ck]

Code:

C:\Bitcoin\cgm491>cgminer -D -T
 [2015-06-03 21:12:17] Started cgminer 4.9.1
[2015-06-03 21:13:15] BAS looking for and found BAS 0403:6014
[2015-06-03 21:13:15] USB lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock=1
[2015-06-03 21:13:15] USB res lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock ok=1
[2015-06-03 21:13:15] USB init, iManufacturer mismatch - BAS device 5:1
[2015-06-03 21:13:15] Found BUTTERFLY LABS vs Butterfly Labs
[2015-06-03 21:13:15] USB free BAS
[2015-06-03 21:13:15] USB init - BMA device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9SV3'
[2015-06-03 21:13:15] BMA0: reset got err 0
[2015-06-03 21:13:15] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:15] BMA0: setdata got err 0
[2015-06-03 21:13:15] BMA0: setbaud got err 0
[2015-06-03 21:13:15] BMA0: setflowctrl got err 0
[2015-06-03 21:13:15] BMA0: setmodemctrl got err 0
[2015-06-03 21:13:16] BMA0: purgetx got err 0
[2015-06-03 21:13:16] BMA0: purgerx got err 0
[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2
[2015-06-03 21:13:16] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:16] BitForceSC (5:1) identified as: 'BMA'


C:\Bitcoin\cgm491>cgminer -n
 [2015-06-03 21:18:11] USB all: found 31 devices - listing known devices
.USB dev 0: Bus 5 Device 1 ID: 0403:6014
  Manufacturer: 'BUTTERFLY LABS'
  Product: 'BitFORCE SHA256 SC'

Here's the portion that was relevant last time.  Let me know if you need the entire dump.

Thanks. It's recognising it fine and running it as a monarch so if it's not working then they changed the protocol and, well, there's no sign of any updated protocol documentation and I do believe all communication channels between the cgminer development team and BFL have effectively been severed so... fuck.

[os2sam]

Code:

C:\Bitcoin\cgm491>cgminer -D -T
 [2015-06-03 21:12:17] Started cgminer 4.9.1
[2015-06-03 21:13:15] BAS looking for and found BAS 0403:6014
[2015-06-03 21:13:15] USB lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock=1
[2015-06-03 21:13:15] USB res lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock ok=1
[2015-06-03 21:13:15] USB init, iManufacturer mismatch - BAS device 5:1
[2015-06-03 21:13:15] Found BUTTERFLY LABS vs Butterfly Labs
[2015-06-03 21:13:15] USB free BAS
[2015-06-03 21:13:15] USB init - BMA device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9SV3'
[2015-06-03 21:13:15] BMA0: reset got err 0
[2015-06-03 21:13:15] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:15] BMA0: setdata got err 0
[2015-06-03 21:13:15] BMA0: setbaud got err 0
[2015-06-03 21:13:15] BMA0: setflowctrl got err 0
[2015-06-03 21:13:15] BMA0: setmodemctrl got err 0
[2015-06-03 21:13:16] BMA0: purgetx got err 0
[2015-06-03 21:13:16] BMA0: purgerx got err 0
[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2
[2015-06-03 21:13:16] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:16] BitForceSC (5:1) identified as: 'BMA'


C:\Bitcoin\cgm491>cgminer -n
 [2015-06-03 21:18:11] USB all: found 31 devices - listing known devices
.USB dev 0: Bus 5 Device 1 ID: 0403:6014
  Manufacturer: 'BUTTERFLY LABS'
  Product: 'BitFORCE SHA256 SC'

Here's the portion that was relevant last time.  Let me know if you need the entire dump.

Thanks. It's recognising it fine and running it as a monarch so if it's not working then they changed the protocol and, well, there's no sign of any updated protocol documentation and I do believe all communication channels between the cgminer development team and BFL have effectively been severed so... fuck.

Oh, Joy.

It does work, kind of.  80 or 90 Ghs, 120Ghs sometimes briefly.  Also the temp goes all the way up to 50 or so as if it was mining full speed.

Thanks,
Sam