Pages:
Author

Topic: BFGMiner 5.5.0: CPU/GPU/FPGA/ASIC mining software, GBT+Stratum, RPC, Linux/Win64 - page 34. (Read 834576 times)

legendary
Activity: 2576
Merit: 1186
That's what git describe does...

anto@hp8530w:~/Development/bfgminer-5.3.0$ git describe
bfgminer-5.2.0-49-g3f30343
full member
Activity: 179
Merit: 131
gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes. Smiley

Yes. You are right that OpenWRT clones your repository, packs it, copies it into the package source directory and deletes the whole cloned directory. However, I think the gen-version.sh does not generate the version of the latest git as it uses "git describe" command which takes the version base on the latest tag as below.

Code:
anto@hp8530w:~/Development$ git clone -b bfgminer https://github.com/luke-jr/bfgminer.git bfgminer-5.3.0
Cloning into 'bfgminer-5.3.0'...
remote: Counting objects: 47192, done.
remote: Compressing objects: 100% (87/87), done.
remote: Total 47192 (delta 48), reused 0 (delta 0), pack-reused 47105
Receiving objects: 100% (47192/47192), 36.94 MiB | 6.02 MiB/s, done.
Resolving deltas: 100% (30084/30084), done.
Checking connectivity... done.
anto@hp8530w:~/Development$
anto@hp8530w:~/Development$ cd bfgminer-5.3.0/
anto@hp8530w:~/Development/bfgminer-5.3.0$
anto@hp8530w:~/Development/bfgminer-5.3.0$ git describe
bfgminer-5.2.0-49-g3f30343
anto@hp8530w:~/Development/bfgminer-5.3.0$
anto@hp8530w:~/Development/bfgminer-5.3.0$ git log -1
commit 3f303439dd2ca3d329c7ac981e8d89cfc65438da
Merge: c000fc9 04e9c86
Author: Luke Dashjr
Date:   Tue Oct 20 19:22:24 2015 +0000

    Merge branch 'bm1382clock' into bfgminer
anto@hp8530w:~/Development/bfgminer-5.3.0$

I think you need to decide Luke how you would set the version of the latest git. Perhaps something like including the commit SHA for instance bfgminer-5.3.0-3f30343 for the above example.
legendary
Activity: 2576
Merit: 1186
will 5.4 stay in the S5 on reboot or do i have to find someone that knows how to compile one of bitmians images and replace cgminer or  learn it my self which im gonna do either way because i want to . just wondering how that's gonna work inside in a S5, btw, can't wait .
Someone will need to add it to a firmware image for it to stay permanently.
legendary
Activity: 1274
Merit: 1000
LUke


will 5.4 stay in the S5 on reboot or do i have to find someone that knows how to compile one of bitmians images and replace cgminer or  learn it my self which im gonna do either way because i want to . just wondering how that's gonna work inside in a S5, btw, can't wait .



I'm about to buy a OpenWRT  switch/router and learn that as well . my verizon router model #  no one has a way of doing yet but the model it self can be done just not the batch # router i have  or id have it at OpenWR, i own that router.
full member
Activity: 179
Merit: 131
gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes. Smiley

As I always say, I am not a programmer. But it looks quite simple so I think I will fork your repository, try to work out what you suggested and pull request it when I manage to implement that.
legendary
Activity: 2576
Merit: 1186
You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?

Yes, perhaps I did. But I always use your Makefile for my OpenWRT 14.07 package build. The only differences are instead using the following
Code:
PKG_SOURCE_URL:=http://luke.dashjr.org/programs/bitcoin/files/$(PKG_NAME)/$(PKG_VERSION)/

I use the following for tmp40389 branch
Code:
PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=tmp40389

Or I use the following for the HEAD version (bfgminer branch)
Code:
PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=HEAD

And I don't do anything else a part from building it with the following command.
Code:
make package/bfgminer/{clean,compile,install}

Do you think there are some build environment variables that I missed to set?

Where is the version that is being displayed on the UI or spit out on the debug log, being set on?

gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes. Smiley
full member
Activity: 179
Merit: 131
You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?

Yes, perhaps I did. But I always use your Makefile for my OpenWRT 14.07 package build. The only differences are instead using the following
Code:
PKG_SOURCE_URL:=http://luke.dashjr.org/programs/bitcoin/files/$(PKG_NAME)/$(PKG_VERSION)/

I use the following for tmp40389 branch
Code:
PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=tmp40389

Or I use the following for the HEAD version (bfgminer branch)
Code:
PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=HEAD

And I don't do anything else a part from building it with the following command.
Code:
make package/bfgminer/{clean,compile,install}

Do you think there are some build environment variables that I missed to set?

Where is the version that is being displayed on the UI or spit out on the debug log, being set on?
legendary
Activity: 2576
Merit: 1186
This looks good, thanks.

 Huh I don't see any significant differences when I compared the debug logs from the HEAD and tmp40389 line by line, but you said "this looks good". Care to explain please?

Your tmp40389 has been running for more than 12 hours on my router as you can see below. And I saw you have commited some changes on the HEAD version (bfgminer branch). Are the changes related to the bug included in that commits?



tmp40389 is 5.3.0 with only the intended fix for the issue.
So it doesn't have the accidental workaround (naming the compac driver correctly) that was in the main bfgminer branch.
full member
Activity: 179
Merit: 131
This looks good, thanks.

 Huh I don't see any significant differences when I compared the debug logs from the HEAD and tmp40389 line by line, but you said "this looks good". Care to explain please?

Your tmp40389 has been running for more than 12 hours on my router as you can see below. And I saw you have commited some changes on the HEAD version (bfgminer branch). Are the changes related to the bug included in that commits?


legendary
Activity: 2576
Merit: 1186
I have one suggestion Luke, if you don't mind.

I have been trying different branches of your github. At some points (and actually just now), I am confused with the versions as all of them only show "bfgminer 5.3.0-unknown". I can differentiate them from the package versions as I can set them. But there is no way to know the version on the screenshot of the UI or debug log (unless I make sure to identify them from the log file name).

Would it be possible to include an indication of branch/tag/commit/whatever in the UI and debug log to differentiate between each version?

You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?
legendary
Activity: 2576
Merit: 1186
legendary
Activity: 2576
Merit: 1186
Hmm, maybe try changing the single-quotes to double-quotes.

Thank you, that did the trick!

Code:
C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,0x0a02"
Reply was 'STATUS=E,When=1445296756,Code=93,Msg=PGA 0 set failed: invalid clock: '0x0a02' data must be
 prefixed with an x,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => E
   [When] => 1445296756
   [Code ] => 93
   [Msg] => PGA 0 set failed: invalid clock: '0x0a02' data must be prefixed with an x
   [Description] => bfgminer 5.3.0
)

It appears that the leading '0' needs to be dropped from the hex frequency value, however:
Code:
C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0a02"
Reply was 'STATUS=S,When=1445296795,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445296795
   [Code ] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

I can successfully report an immediate increase in hash speed on the sticks once the command is issued.  Thanks again, looking forward to 5.4.0.  Smiley
Sounds like the "leading zero" is your problem.
There was never any expectation/support for one.
How can I improve documentation to make that clear?

I have two gekko compacs running on this particular machine and the rpc command only appears to have increased the frequency on one stick.  I replaced "cbm0" with "cbm1" to see if I could effect the other stick.  The command was accepted successfully, however, the second stick did not increase in hash rate.  Do I need to do something different to get the second stick to see the new frequency?

I forgot pgaset doesn't take a device specification like that. Really you need to identify them by number, so 0 and 1 instead of cbm0 and cbm1.
legendary
Activity: 1274
Merit: 1000
Hmm, maybe try changing the single-quotes to double-quotes.

Thank you, that did the trick!

Code:
C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,0x0a02"
Reply was 'STATUS=E,When=1445296756,Code=93,Msg=PGA 0 set failed: invalid clock: '0x0a02' data must be
 prefixed with an x,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => E
   [When] => 1445296756
   [Code] => 93
   [Msg] => PGA 0 set failed: invalid clock: '0x0a02' data must be prefixed with an x
   [Description] => bfgminer 5.3.0
)

It appears that the leading '0' needs to be dropped from the hex frequency value, however:
Code:
C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0a02"
Reply was 'STATUS=S,When=1445296795,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445296795
   [Code] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

I can successfully report an immediate increase in hash speed on the sticks once the command is issued.  Thanks again, looking forward to 5.4.0.  Smiley

I looks like you do not need the trailing quote mark for whatever reason, but it will error if you omit the leading one:
Code:
C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0982
Reply was 'STATUS=S,When=1445297249,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445297249
   [Code] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

Edit - for some reason the forum keeps inserting the extra /code breaks at the end.  I didn't put them there, and when I edit to delete them they just show up again when I save...[/code][/code][/code]


I have two gekko compacs running on this particular machine and the rpc command only appears to have increased the frequency on one stick.  I replaced "cbm0" with "cbm1" to see if I could effect the other stick.  The command was accepted successfully, however, the second stick did not increase in hash rate.  Do I need to do something different to get the second stick to see the new frequency?
full member
Activity: 179
Merit: 131
I have one suggestion Luke, if you don't mind.

I have been trying different branches of your github. At some points (and actually just now), I am confused with the versions as all of them only show "bfgminer 5.3.0-unknown". I can differentiate them from the package versions as I can set them. But there is no way to know the version on the screenshot of the UI or debug log (unless I make sure to identify them from the log file name).

Would it be possible to include an indication of branch/tag/commit/whatever in the UI and debug log to differentiate between each version?
full member
Activity: 179
Merit: 131
This is ready to be tested. Please download and test these binaries (or GitHub branch tmp40389 if you build from source).

How do we actually test this build?  Grin

I am using your tmp40389 branch as I need to compile it for my WiFi router. The initialisation phase below looks the same to me.

Code:

 [2015-10-19 18:05:06] Timers: Using clock_gettime(CLOCK_MONOTONIC)
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] setrlimit: Soft fd limit not being changed from 1024 (FD_SETSIZE=1024; hard limit=4096)
 [2015-10-19 18:05:06] Started bfgminer 5.3.0-unknown
 [2015-10-19 18:05:06] Loaded configuration file /etc/bfgminer/bfgminer.conf
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc01 (path=/dev/ttyUSB1, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc00 (path=/dev/ttyUSB0, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB1: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB1: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB0: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB0: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] Found AMU 0 at /dev/ttyUSB0
 [2015-10-19 18:05:06] Found AMU 1 at /dev/ttyUSB1
 [2015-10-19 18:05:06] AMU 0: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] AMU 1: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] Probing for an alive pool
.
.
legendary
Activity: 2576
Merit: 1186
If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?
The only way I can think to confirm it further, would be to produce a 5.3.0 with only that bug fixed.
Probably won't have this until tomorrow or Monday.
This is ready to be tested. Please download and test these binaries (or GitHub branch tmp40389 if you build from source).
legendary
Activity: 2576
Merit: 1186
OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.

Could you please briefly explain the bug?
Drivers are registered in a hash table by their name, and when you specify -S dname:anything, when is seen, it always probes first. But the hash table does not support multiple entries with the same string, so since compac was called "antminer", it was getting probed for anything specifying "antminer".

Is that related to the issue that I raised on your github 2 months ago?
No.

If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?
The only way I can think to confirm it further, would be to produce a 5.3.0 with only that bug fixed.
Probably won't have this until tomorrow or Monday.
full member
Activity: 179
Merit: 131
OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.

Could you please briefly explain the bug?

Is that related to the issue that I raised on your github 2 months ago?

If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?
legendary
Activity: 2576
Merit: 1186
OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.
full member
Activity: 179
Merit: 131
Pages:
Jump to: