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

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

[1531845185]

1531845185

[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

[kano]

It's this line that may (or may not) identify the issue:

[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2

[-ck]

New release: Version 4.9.2 - 12th June 2015

Long term stability updates, clean ups and driver updates.


Human readable changelog:

- Various drivers that failed to initialise (notably Antminer U3s) have been fixed by addressing various low level detection issues with other drivers.
- Blockerupter tube driver has been disabled by default in binary builds since it's broken, and the configuration advises against it.
- Fixes for various BFL devices not being properly recognised.
- Getwork support has been completely REMOVED. Only local work generation protocols are now supported (stratum, GBT and solo mining). No pool should be providing getwork support in the modern mining era anyway.
- Queue option has been REMOVED. The option is now silently ignored to not break existing configurations but no more will any antminer binaries be able to set it to 8000 or something stupid. Any attempt to tune this value is pointless and dates back to getwork.
- Expiry and scan-time have also been REMOVED. They are irrelevant with local work generation and asic mining speeds and no getwork.
- failover-only option has been REMOVED. As per above.
- Pool failover has been cleaned up without getwork
- Default Antminer U3 voltage has been changed to 775 since 750 is rarely enough to get 2nd generation ones running at full speed.
- U3 will USB reset on no shares for 2 seconds instead of 1.
- Major antminer S1/S2/S3 driver updates courtesy of kano. Use his provided firmware links.
- Systemd support courtesy of Gabe Evans
- Update to latest libjansson with custom fixes imported from ckpool
- Support for building with system libjansson (dunno why you'd want to do this so it's advised against in the config option but it seems people want useless stuff and it's harmless) - Gabe Evans
- SP30 uses applog instead of printf -  Gabe Evans
- Make json rpc requests valid -  Gabe Evans
- Syslog limits to logging - Gabe Evans
- Build configuration fixes for building from git with newer systems.
- Support mining.reconnect with port as a string or value.
- Numerous clean ups and fixes to minimise risk of invalid memory operations in the code.
- Fix for a rare crash on pool switching during failover.


Full changelog:

- Only blacklist devices on iManufacturer if they don't have an iProduct
- Simplify the pool work choice switching now that only local work generation is
supported
- Check for absense of stratum notify on stratum pools to see if they're usable
- Remove getwork support
- Remove test for localgen since all work will be
- Deprecate failover only option in anticipation of removing getwork
- Deprecate expiry option and fix it to 10 minutes, replacing all deprecated
config calls in the API with a deprecated message
- Deprecate scan-time which is irrelevant with ASIC speed mining
- Deprecate opt_queue since all mining is now local work generation which is
rapid and it serves no useful purpose to generate work that is potentially
stale, increasing CPU usage to check it before using it
- Change default au3 voltage to 775 to more reliably run at default frequency
- Set correct timeout for AU3 in icarus_detect_one though it won't affect
functioning
- Blacklist LIX device which doesn't exist
- Round up fail time to next highest integer on icarus
- AntS3 - set default work delay
- add pool block quality to api
- AntS3 - redo work send/stats and add a tuning option - not yet tuned
- Ant - ignore useless options in case they are passed
- AntS3 - initial S3 merge basic support
- Ant voltage isn't S1
- API - restore IPv4 address .0 padding and update copyright dates
- ants2 - separate freq from options
- ants2 - make it compile :p
- ants2 - add voltage
- ants2 - remove libusb/udev dependency since it doesn't use USB
- AntS1 ensure correct endian and correct wid
- libsystemd: Notify watchdog
- libsystemd: Notify run state and status line
- Catch SIGABRT signal and exit gracefully
- Add libsystemd configure option (default disabled)
- Document --with-system-jansson configure option
- SP30: Fix logging to use applog over printf calls
- Allow building with system jansson
- Set request ID in validateaddress JSON-RPC request.
- Cope with reconnect being sent a port number as an integer or string
- Added syslog mask to limit amount of output
- regressed with "BAL" little-jalapenos
- Add yet more whitelisting of BMA devices, removing the case insensitive match
for manufacturer
- Fix detection of no mining device configuration.
- Remove LT_INIT from configure which breaks ltmain.sh detection for some
automagic reason
- Add missing hashtable_seed file
- Add missing file
- Speed up shutdown by decreasing usb poll time to 100ms and using no timeout on
exit
- Cope with attempted reuse of strings in input_pool
- Manage failed URL entry at startup more gracefully, adding stratum+tcp://
automatically if http:// isn't specified
- Fix various symbol size change warnings
- Import jansson updates from ckpool
- Check for attempts to copy to/from null in cg_memcpy
- Use cg_memcpy throughtout bitfury driver
- Use cg_memcpy throughout cgminer.c and util.c
- Use alloc helper in miner.h
- Use alloc helpers in bitfury driver
- Use alloc helpers in spondoolies drivers
- Use alloc helpers in bflsc driver
- Align_len in all alloc helper calls
- Use align_len in all alloc helpers
- Use alloc helpers in usbutils
- Use alloc helpers in icarus driver
- Use alloc helpers in avalon4 driver
- Use alloc helpers in api.c
- Use the alloc helpers in util.c
- Convert all users of alloc to use the helpers in cgminer.c
- Add helper functions to various alloc functions that automatically check for
failure
- Fix rare dereference error on pool stratum queue