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

[purelithium]

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!

[1714046494]

1714046494

[1714046494]

1714046494

[vpereira]

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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>...
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?

[jml]

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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>...
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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>...
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

[jml]

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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>...
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

[vpereira]

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.

[drewage]

I wanted to install MacMiner on a Mac Mini late 2006 but currently it isn't compiled for 32 bit support.  If I install Ubuntu 10.04, which is the recommended version for this hw, will I still be able to install bfgminer from the PPA?  Is it compiled for 32 bit support?  I tried to compile it, bfgminer, using Xcode but it kept throwing errors related to the fact that Snow Leopard apparently uses a legacy version of C or ObjC.  Or will I have to upgrade the hardware and go from there?

By the way, I'm not all that adept in a shell environment but I'm willing to try...   

[jml]

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.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.


So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others

[fabrizziop]

Hey, I'm in ubuntu 13.04 x64 mining scrypt. BFGMiner hangs if my internet connection goes down, it gives a segmentation fault. It only happens when the internet is down (it doesn't matter if the actual interface is down, as I used a switch and unplugged my pfsense router from switch, BFGMiner crashed). Is there any script that if BFGMiner stops then it starts it again?.

Thanks in advance.

edit: quick ugly solution, run the miner with this scrypt:

Code:

#!/bin/sh
export DISPLAY=:0
export GPU_MAX_ALLOC_PERCENT=100
export GPU_USE_SYNC_OBJECTS=1
while true
do
	bfgminer PLACE SETTINGS HERE
done

[vpereira]

he wrote in his post.. after you run it and it aborts, you should run in the gdb shell:

    thr app all bt

and paste the backtrace here.. but as I C developer, you should know how to get this backtrace anyway

anyway I had a strange problem as well, involving a X6500, that it simply gone as soon as I removed it from the USB hub and gave to it a dedicated USB port and in my experience, the USB hub is a common source of problem.

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.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.


So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others

[Luke-Jr]

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.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.


So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others

Before you 'run' in gdb, do

Code:

handle SIGILL nostop noprint pass

[jml]

he wrote in his post.. after you run it and it aborts, you should run in the gdb shell:

    thr app all bt

and paste the backtrace here.. but as I C developer, you should know how to get this backtrace anyway

anyway I had a strange problem as well, involving a X6500, that it simply gone as soon as I removed it from the USB hub and gave to it a dedicated USB port and in my experience, the USB hub is a common source of problem.

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.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.


So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others

True, but he said to run that after it crashes, not to abort which is a voluntary action. In my case, the pi needs a hard reboot.

Anyway, I have been trying it out with 2 BE on the hub and seems to go well for now going 24hours.

[jml]

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.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.


So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others

Before you 'run' in gdb, do

Code:

handle SIGILL nostop noprint pass

Hi Luke,

I have executed the line you gave and I can run bfgminer within gdb. The problem is that when the application crashes, it causes the pi to hang. I cannot SSH back into it and I need to switch it off and then back off.

I am a bit confused in using the thr command as the thread is killed after I need to reboot.

Any suggestions? Maybe piping execution code to a file?

[vpereira]

no clue on your /var/log/messages?

[jml]

https://dl.dropboxusercontent.com/u/22873106/messages

[jml]

As it is, the pi can either run the FPGA's on its own, or run solely with the BE's, but not both as it causes the pi to hang up.

[Zeronic]

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

[jml]

I had running the ztex fpga with the BE and no problems; has been running for more than 12 hours.

[Luke-Jr]

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

All current versions are known working - I wouldn't release them if they didn't work.
There is no sign of a X6500 on your USB bus in the pastebin, with or without the correct driver.
X6500 is 0403:6001

[jml]

Luke,

I have been running CM1's within a single USB channel and allowed ZTEX and BE's to run on another USB channel connected to the raspberry pi.

So here is the way they are connected:

Raspberry pi = 2 USB ports (a)

(a)  1 USB port has USB 4 port hub       (1)
(a)  1 USB port has USB 4 port hub       (2)

(1)  4 port hub has one ZTEX link and 2 DLINK 7 port hub links
(2)  4 port hub has 2 CM1's connected

I think the CM1's and BE's don't seem to like sharing the same USB hub channel. That is my theory for now.
I have had these running now for 3+ hours as the pi usually HUPs in about one hour.

[jml]

Luke,

I have been running CM1's within a single USB channel and allowed ZTEX and BE's to run on another USB channel connected to the raspberry pi.

So here is the way they are connected:

Raspberry pi = 2 USB ports (a)

(a)  1 USB port has USB 4 port hub       (1)
(a)  1 USB port has USB 4 port hub       (2)

(1)  4 port hub has one ZTEX link and 2 DLINK 7 port hub links
(2)  4 port hub has 2 CM1's connected

I think the CM1's and BE's don't seem to like sharing the same USB hub channel. That is my theory for now.
I have had these running now for 3+ hours as the pi usually HUPs in about one hour.

Update: HUPed after 3 hours operation.