OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 147.

vpereira

newbie

Activity: 52

Merit: 0

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

jml

full member

Activity: 238

Merit: 100

I provide the alternative form but without using sudo and giving pool address, username and password and I still get an illegal instruction:

I get it running gdb as sudo and without sudo prefix and I get the same message.

Code:

pi@raspberrypi ~/bfgminer-3.1.2 $ gdb --args ./bfgminer {MY ARGS} -S all
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /home/pi/bfgminer-3.1.2/bfgminer...done.
(gdb) run
Starting program: /home/pi/bfgminer-3.1.2/bfgminer -o http://api.bitcoin.cz:8332 args -S all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0xb6a704c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0

jml

full member

Activity: 238

Merit: 100

Quote from: vpereira on July 28, 2013, 02:34:11 PM

Quote from: jml on July 28, 2013, 11:44:56 AM

Quote from: jml on July 28, 2013, 11:27:40 AM

Quote from: Luke-Jr on July 28, 2013, 10:07:59 AM

Quote from: jml on July 28, 2013, 09:11:38 AM

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

A backtrace may be useful.
Rebuild with

Code:

make clean && ./configure CFLAGS='-O0 -ggdb' && make

Note that -O0 is OH ZERO.

Then start bfgminer with

Code:

gdb --args ./bfgminer YOUR OPTIONS ETC -S all

When it crashes, run

Code:

thr app all bt

... and post the output from this (it will be many pages).

Thanks for the reply,

I have done that and I am now waiting for it to fail.

Luke, I get the following screen:

Code:

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sudo...(no debugging symbols found)...done.
(gdb)

I have executed the following:

Code:

gdb --args sudo ./bfgminer -S all

Do I need to do anything else?

in the gdb shell you should write "run" and wait until it crashes.. then you could get more hints from the crash....not sure if it helps you.. there is any core file in your running directory?

The problem is that I need to run bfgminer as sudo and gdb is taking the first argument as the command sudo. Its been quite a while since I have done Linux but does gdb have a command to take a string with spaces as an argument?

If I run using pi, I get this:

Code:

pi@raspberrypi ~/bfgminer-3.1.2 $ sudo gdb --args ./bfgminer -S all
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /home/pi/bfgminer-3.1.2/bfgminer...done.
(gdb) run
Starting program: /home/pi/bfgminer-3.1.2/bfgminer -S all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0xb6a704c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0

vpereira

newbie

Activity: 52

Merit: 0

Quote from: jml on July 28, 2013, 11:44:56 AM

Quote from: jml on July 28, 2013, 11:27:40 AM

Quote from: Luke-Jr on July 28, 2013, 10:07:59 AM

Quote from: jml on July 28, 2013, 09:11:38 AM

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

A backtrace may be useful.
Rebuild with

Code:

make clean && ./configure CFLAGS='-O0 -ggdb' && make

Note that -O0 is OH ZERO.

Then start bfgminer with

Code:

gdb --args ./bfgminer YOUR OPTIONS ETC -S all

When it crashes, run

Code:

thr app all bt

... and post the output from this (it will be many pages).

Thanks for the reply,

I have done that and I am now waiting for it to fail.

Luke, I get the following screen:

Code:

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sudo...(no debugging symbols found)...done.
(gdb)

I have executed the following:

Code:

gdb --args sudo ./bfgminer -S all

Do I need to do anything else?

in the gdb shell you should write "run" and wait until it crashes.. then you could get more hints from the crash....not sure if it helps you.. there is any core file in your running directory?

purelithium

hero member

Activity: 504

Merit: 500

Luke, is there any way to force BFGMiner to use the old(non-agressive clocks) bitstream for the MMQ? Ever since 2.9.x whenever you introduced the bitstream that aggressively clocks the MMQ higher and higher, I've noticed the HW errors being insane. Right now running for almost a week, the HW errors on 3.1.3 are 15%. That's a lot of hashes wasted. The software just keeps clocking the chips higher and higher, increasing the HW errors and decreasing the effective hashrate. If the clocking code was tied to the HW errors, that would better maximize hashrate, I think. If the HW errors exceed a certain % of shares, to lower the clocks progressively until it goes back below that threshold.

I know a few weeks ago you made a commit on github to be able to adjust the clocks in the Manage Devices menu, but there hasn't been a release since.

Can you either release this new clock-adjusting feature so I can set my clocks manually back to 210mhz where I actually got 840 mh/s Or maybe fix the bitstream/clocking code(sorry not a programmer, not sure what is involved here)?

Thanks! love the software as always!

jml

full member

Activity: 238

Merit: 100

Quote from: jml on July 28, 2013, 11:27:40 AM

Quote from: Luke-Jr on July 28, 2013, 10:07:59 AM

Quote from: jml on July 28, 2013, 09:11:38 AM

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

A backtrace may be useful.
Rebuild with

Code:

make clean && ./configure CFLAGS='-O0 -ggdb' && make

Note that -O0 is OH ZERO.

Then start bfgminer with

Code:

gdb --args ./bfgminer YOUR OPTIONS ETC -S all

When it crashes, run

Code:

thr app all bt

... and post the output from this (it will be many pages).

Thanks for the reply,

I have done that and I am now waiting for it to fail.

Luke, I get the following screen:

Code:

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sudo...(no debugging symbols found)...done.
(gdb)

I have executed the following:

Code:

gdb --args sudo ./bfgminer -S all

Do I need to do anything else?

jml

full member

Activity: 238

Merit: 100

Quote from: Luke-Jr on July 28, 2013, 10:07:59 AM

Quote from: jml on July 28, 2013, 09:11:38 AM

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

A backtrace may be useful.
Rebuild with

Code:

make clean && ./configure CFLAGS='-O0 -ggdb' && make

Note that -O0 is OH ZERO.

Then start bfgminer with

Code:

gdb --args ./bfgminer YOUR OPTIONS ETC -S all

When it crashes, run

Code:

thr app all bt

... and post the output from this (it will be many pages).

Thanks for the reply,

I have done that and I am now waiting for it to fail.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: jml on July 28, 2013, 09:11:38 AM

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

A backtrace may be useful.
Rebuild with

Code:

make clean && ./configure CFLAGS='-O0 -ggdb' && make

Note that -O0 is OH ZERO.

Then start bfgminer with

Code:

gdb --args ./bfgminer YOUR OPTIONS ETC -S all

When it crashes, run

Code:

thr app all bt

... and post the output from this (it will be many pages).

jml

full member

Activity: 238

Merit: 100

Hello,

I have been running a pi (I have two pi's; R1 and R2) with a ZTEX 1.15x and 2 CM1 FPGA boards running BFGMiner 3.0.2. I recently upgraded to version 3.1.2 and acquired 7 USB Block Erupters plugged into a DLINK 7 port hub which maximum amperage is 3A.

The CM1 and ZTEX do not have significant problems in running but upon installing the new BE, it only takes about one hour until the pi crashes and needs to be restarted. I have tried both hardware revisions and I can confirm that it still crashes on both.

I reduced the load on the USB device from 7 to 5 (5 * 0.51 = 2.5amps) and it still makes the pi crash to the point of needing a hard restart. I am now testing with 4 USB BE plugged into the hub.

The arguments used when executing BFGMiner is "-S all".

I am not sure if this is a problem with power draw which I am trying to eliminate or a software problem that is causing the pi to crash.

Any help is greatly appreciated.

vpereira

newbie

Activity: 52

Merit: 0

for me, i have a cluster with 12 fpgas running on raspberrypi. I isolated one x6500 and I'm trying to run it, together with the pi and it simply get sick and die Sad

anybody running a x6500 + bfgminer? which cmline params do you use?

Zeronic

member

Activity: 243

Merit: 10

Quote from: vpereira on July 27, 2013, 06:32:47 AM

what is the best way to bootstrap a x6500? I have one, with fan and heatsink that after some minutes, it get SICK and DEAD. bfgminer, compiled yesterday from github. Im running it together with 3 usb erupter..

Even with the zadig_v2.0.1.160 driver, I can't get BFGminer to see any of my X6500.

vpereira

newbie

Activity: 52

Merit: 0

what is the best way to bootstrap a x6500? I have one, with fan and heatsink that after some minutes, it get SICK and DEAD. bfgminer, compiled yesterday from github. Im running it together with 3 usb erupter..

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: viriat0 on July 26, 2013, 05:33:06 PM

Quote from: Taugeran on July 26, 2013, 05:25:42 PM

Quote from: viriat0 on July 26, 2013, 04:43:09 PM

hello folks,

is normal this happen?

[2013-07-26 22:41:40] Stratum from pool 0 requested work update
[2013-07-26 22:41:41] Accepted 05f4ca86 ICA 1 Diff 42/2
[2013-07-26 22:42:00] Stratum from pool 0 requested work update
[2013-07-26 22:42:06] Stratum from pool 0 requested work update
[2013-07-26 22:42:13] Stratum from pool 0 requested work update
[2013-07-26 22:42:18] Stratum from pool 0 requested work update
[2013-07-26 22:42:25] Stratum from pool 0 requested work update

Conected on 50BTC.

cheers

What is your total hashrate in bfgminer?

1000MH/S

3 USB Asicminer

Use:

/bfgminer# ./bfgminer -o pool.50btc.com:8332 -u username -p 123 -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100

thanks

Does it have large strings of the stratum request events frequently or just every once in a while. With a 1Ghash/sec rig you should see results far outstrip requests.

viriat0

hero member

Activity: 1008

Merit: 501

Quote from: Taugeran on July 26, 2013, 05:25:42 PM

Quote from: viriat0 on July 26, 2013, 04:43:09 PM

hello folks,

is normal this happen?

[2013-07-26 22:41:40] Stratum from pool 0 requested work update
[2013-07-26 22:41:41] Accepted 05f4ca86 ICA 1 Diff 42/2
[2013-07-26 22:42:00] Stratum from pool 0 requested work update
[2013-07-26 22:42:06] Stratum from pool 0 requested work update
[2013-07-26 22:42:13] Stratum from pool 0 requested work update
[2013-07-26 22:42:18] Stratum from pool 0 requested work update
[2013-07-26 22:42:25] Stratum from pool 0 requested work update

Conected on 50BTC.

cheers

What is your total hashrate in bfgminer?

1000MH/S

3 USB Asicminer

Use:

/bfgminer# ./bfgminer -o pool.50btc.com:8332 -u username -p 123 -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100

thanks

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: viriat0 on July 26, 2013, 04:43:09 PM

hello folks,

is normal this happen?

[2013-07-26 22:41:40] Stratum from pool 0 requested work update
[2013-07-26 22:41:41] Accepted 05f4ca86 ICA 1 Diff 42/2
[2013-07-26 22:42:00] Stratum from pool 0 requested work update
[2013-07-26 22:42:06] Stratum from pool 0 requested work update
[2013-07-26 22:42:13] Stratum from pool 0 requested work update
[2013-07-26 22:42:18] Stratum from pool 0 requested work update
[2013-07-26 22:42:25] Stratum from pool 0 requested work update

Conected on 50BTC.

cheers

What is your total hashrate in bfgminer?

viriat0

hero member

Activity: 1008

Merit: 501

hello folks,

is normal this happen?

[2013-07-26 22:41:40] Stratum from pool 0 requested work update
[2013-07-26 22:41:41] Accepted 05f4ca86 ICA 1 Diff 42/2
[2013-07-26 22:42:00] Stratum from pool 0 requested work update
[2013-07-26 22:42:06] Stratum from pool 0 requested work update
[2013-07-26 22:42:13] Stratum from pool 0 requested work update
[2013-07-26 22:42:18] Stratum from pool 0 requested work update
[2013-07-26 22:42:25] Stratum from pool 0 requested work update

Conected on 50BTC.

cheers

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Foss on July 25, 2013, 02:59:05 AM

Luke-Jr
I mean this:

will you improve it? Wink

BFGMiner is the improvement already. It is not difficulty 64, it is difficulty 0.001.

Foss

full member

Activity: 125

Merit: 100

Luke-Jr
I mean this:

will you improve it? Wink

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Foss on July 24, 2013, 02:34:04 PM

Quote from: Luke-Jr on July 24, 2013, 01:43:36 PM

Quote from: Foss on July 24, 2013, 06:09:02 AM

Hi, why diff show 0 when scrypt mining? In cgminer show 32 or 64, depending of pool

cgminer is showing Ldiff (Litecoin difficulty).
BFGMiner is showing pdiff (pool difficulty).

Exactly pool difficulty in BFGMiner is 0, and Ldiff is 894. in cgminer pool difficulty is 32, and Ldiff is 58.6M. Here my settings:
@echo off
setx GPU_MAX_ALLOC_PERCENT 100
bfgminer.exe --scrypt -o stratum+tcp://mining.eu.hypernova.pw:3333 -u user -p password -d 0,1 -I 20,19 -w 256 -v 1 -g 1 --lookup-gap 2 --thread-concurrency 21772,16192 --queue 0 -s 1, whats wrong?

You're confusing Litecoin's network difficulty with Litecoin-difficulty-unit.

Target	pdiff	bdiff	Ldiff
BC network (today)	31.3M	31.3M	2T
LTC network (today)	894.212	894.198	58.6M
pdiff 1	1	0.999985	65536
bdiff 1	1.000015	1	65537
Ldiff 1	0.000015	0.000015	1

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: Foss on July 24, 2013, 02:34:04 PM

Quote from: Luke-Jr on July 24, 2013, 01:43:36 PM

Quote from: Foss on July 24, 2013, 06:09:02 AM

Hi, why diff show 0 when scrypt mining? In cgminer show 32 or 64, depending of pool

cgminer is showing Ldiff (Litecoin difficulty).
BFGMiner is showing pdiff (pool difficulty).

Exactly pool difficulty in BFGMiner is 0, and Ldiff is 894. in cgminer pool difficulty is 32, and Ldiff is 58.6M. Here my settings:
@echo off
setx GPU_MAX_ALLOC_PERCENT 100
bfgminer.exe --scrypt -o stratum+tcp://mining.eu.hypernova.pw:3333 -u user -p password -d 0,1 -I 20,19 -w 256 -v 1 -g 1 --lookup-gap 2 --thread-concurrency 21772,16192 --queue 0 -s 1, whats wrong?

From the cgminer README/FAQ:

Quote

Q: Why do the scrypt diffs not match with the current difficulty target?
A: The current scrypt block difficulty is expressed in terms of how many
multiples of the BTC difficulty it currently is (eg 28) whereas the shares of
"difficulty 1" are actually 65536 times smaller than the BTC ones. The diff
expressed by cgminer is as multiples of difficulty 1 shares.

It looks like BFGMiner does not do the same re-calculation that CGMiner does.

Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 147. (Read 1193223 times)