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

[Btc-Go]

I want to statically link libraries so that I have single all-in binary.
That's what I do:

Code:

LDFLAGS=-static ./configure --disable-avalon --disable-largefile --enable-cpumining --enable-opencl --disable-bigpic --disable-bitfury --disable-bfsb --disable-bigpic --disable-littlefury --disable-nanofury --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-icarus --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --enable-scrypt --without-sensors --without-curses --without-libusb --without-libudev --disable-twinfury

But I get error on make:

Code:

bfgminer-driver-opencl.o: In function `load_opencl_symbols':
/usr/local/src/bfgminer/driver-opencl.c:222: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
bfgminer-miner.o: In function `main':
/usr/local/src/bfgminer/miner.c:11017: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

I'm not a C programmer, could someone help me to understand what is going on?

[1714861062]

1714861062

[stewdk]

If you're using Ubuntu 12.04 Precise and want to compile bfgminer with blade/cube functionality via libmicrohttpd, chances are you'll have a bad time because the libmicrohttpd version included with 12.04 is out of date.  You can work around this by installing the libmicrohttpd packages from the 12.10 Quantal release.  Sure you could just download the .deb files from http://packages.ubuntu.com/quantal/libmicrohttpd-dev and install them manually, but there's a fancier way (inspired by and portions copied from http://blog.sleeplessbeastie.eu/2012/10/08/ubuntu-precise-install-youtube-dl-package-using-quantal-repo/).

First things first, uninstall the old versions of libmicrohttpd5 and libmicrohttpd-dev and do a sudo apt-get update.

Check your available package versions:

Code:

apt-cache policy libmicrohttpd5 libmicrohttpd10 libmicrohttpd-dev

Note that libmicrohttpd5 is the 12.04 runtime package and libmicrohttpd10 is the quantal runtime package.

Create file /etc/apt/apt.conf.d/00release with contents:

Code:

APT::Default-Release "precise";

Append the quantal repository to /etc/apt/sources.list:

Code:

deb http://us.archive.ubuntu.com/ubuntu/ quantal universe

Code:

sudo apt-get update

As you defined default release as precise there should not be any packages to update (unless updates were released between the time that you started and now, something that I actually encountered while writing this up):

Code:

sudo apt-get upgrade --simulate

Check that the new version (0.9.20-1) of libmicrohttpd is available:

Code:

apt-cache policy libmicrohttpd5 libmicrohttpd10 libmicrohttpd-dev

Now, apt won't actually choose the new version of libmicrohttpd-dev yet, so create file /etc/apt/preferences.d/libmicrohttpd-dev with contents:

Code:

Package: libmicrohttpd-dev
Pin: release a=quantal
Pin-Priority: 990

Check the pinned priorities for good measure (Candidate should be version 0.9.20-1) :

Code:

apt-cache policy libmicrohttpd-dev

Code:

sudo apt-get install libmicrohttpd10 libmicrohttpd-dev

Double check the installed versions

Code:

dpkg --list | grep libmicrohttpd

Finally, compile bfgminer by the usual means.

[HellDiverUK]

Luke-Jr, back in November I was asking about getting the BlueFurys running on OpenWRT.  I finally got round to testing the BlueFury again on OpenWRT, and it's still showing 100% errors.

I don't remember what you said back then, and I can't find it on this thread.

What are your thoughts?

[Taugeran]

so i got my BBB up and running with my 2 NFY 1 BPMC and 5 BES but:



im having an issue that if all the devices are plugged in at same time and in one instance of bfgminer one "random" of my NFY will hang at initializing.... while the other goes on just fine.

but in this image i got everything running for a short while in 2 different instances but then one of the NFY errors/hangs/stops hashing.



lsusb -t output:

Code:

miner@arm:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 480M
        |__ Port 2: Dev 46, If 0, Class=HID, Driver=usbfs, 12M
        |__ Port 4: Dev 38, If 0, Class=HID, Driver=usbfs, 12M
        |__ Port 5: Dev 4, If 0, Class=hub, Driver=hub/5p, 480M
            |__ Port 1: Dev 5, If 0, Class=HID, Driver=usbhid, 480M
            |__ Port 2: Dev 47, If 0, Class=comm., Driver=cdc_acm, 12M
            |__ Port 2: Dev 47, If 1, Class=data, Driver=cdc_acm, 12M
            |__ Port 4: Dev 55, If 0, Class=hub, Driver=hub/4p, 480M
                |__ Port 1: Dev 56, If 0, Class=vend., Driver=cp210x, 12M
                |__ Port 2: Dev 57, If 0, Class=vend., Driver=cp210x, 12M
                |__ Port 3: Dev 58, If 0, Class=vend., Driver=cp210x, 12M
                |__ Port 4: Dev 59, If 0, Class=hub, Driver=hub/4p, 480M
                    |__ Port 1: Dev 60, If 0, Class=vend., Driver=cp210x, 12M
                    |__ Port 2: Dev 61, If 0, Class=vend., Driver=cp210x, 12M

i can get everything working if i remove the last 2 BES (devs 60 and 61)

poor ascii art of layout: BBB---DLINK---7port
                                          |  |  |    || || |
                                         N  N B    EEEEE

N=NFY
B=BPMC
E=Erupter

each hub is powered by a separate 5V@3.5A wall supply

[Taugeran]

also can i use set device with NFY@Serial#:osc6_bits=##

i cant find code to indicate either way

[Btc-Go]

@stewdk, I use debian with libmicrohttpd ver 0.9
But that's not the point.

The application fails to compile statically, into single binary with all libraries bundled.

[stewdk]

@stewdk, I use debian with libmicrohttpd ver 0.9
But that's not the point.

The application fails to compile statically, into single binary with all libraries bundled.

Ah, sorry for the confusion, my other post wasn't necessarily directed towards you, just in general...  I took a stab at trying to compile it statically on my setup anyway, and was not successful.  I don't use GPUs or scrypt, so I ran ./configure without any options:

Code:

LDFLAGS=-static ./configure

The configure succeeds, but the make fails.  If I rerun ./configure without the static link flag, then the make succeeds.  I'm guessing if you really want a static binary then you might have to get dirty with the build setup and that'll likely take a lot of work.  What were you hoping to achieve with a static binary anyway?

[Btc-Go]

@stewdk, static binary is redistributable cause it doesn't require libraries.

[stewdk]

After using BFG miner on my SC Single, it eventually errored out. When I restarted it, it now only picks my graphics cards.

Has anyone experienced this? Is there any way I can trouble shoot it? I didn't alter anything. I can't figure it out.

I tried using bfgminer for my Jalapeno, and it would only detect it like every fifth time I started bfgminer.  I've found that unplugging and replugging both the power and USB cable from my Jalapeno will help it get back online.  However, cgminer detects my jalapeno pretty much every time.  Just sayin'.  I think the initialization code in cgminer is much more robust compared to bfgminer.  I did flash the firmware on my jalapeno though, so I can't rule that out as being the issue.

[Trance104]

After using BFG miner on my SC Single, it eventually errored out. When I restarted it, it now only picks my graphics cards.

Has anyone experienced this? Is there any way I can trouble shoot it? I didn't alter anything. I can't figure it out.

I tried using bfgminer for my Jalapeno, and it would only detect it like every fifth time I started bfgminer.  I've found that unplugging and replugging both the power and USB cable from my Jalapeno will help it get back online.  However, cgminer detects my jalapeno pretty much every time.  Just sayin'.  I think the initialization code in cgminer is much more robust compared to bfgminer.  I did flash the firmware on my jalapeno though, so I can't rule that out as being the issue.

Who woulda thought?? Unplugging it and plugging it back in got it to work! My hats off to you sir!

Thank you very much!

[HellDiverUK]

My Jalapeno needs a hard reboot the odd time too, or it just falls off the USB bus.  Usually after the host has rebooted.

[asjfdlksfd]

Hi, is there a way to see the chips stats in the same way for Chilly as it is possible to see the stats for Jally/(Little) Single?

Cheers...

[dadach]

why is cgminer so retarded that he cannot distinguish between 2 different cards in a computer?

[HellDiverUK]

why is cgminer so retarded that he cannot distinguish between 2 different cards in a computer?

Why are you so retarded the you cannot post in the correct thread? 

[xzempt]

bfgminer 3.3.0  has been working great for a couple weeks now.....      but last night it just quit recognizing my blades....

i can access the blades and point them to a getwork pool and they mine.....



switch them to point to pc running bfgminer.... they quit mining and bfgminer wont even show them on the network?




any ideas?

[stewdk]

After using BFG miner on my SC Single, it eventually errored out. When I restarted it, it now only picks my graphics cards.

Has anyone experienced this? Is there any way I can trouble shoot it? I didn't alter anything. I can't figure it out.

I tried using bfgminer for my Jalapeno, and it would only detect it like every fifth time I started bfgminer.  I've found that unplugging and replugging both the power and USB cable from my Jalapeno will help it get back online.  However, cgminer detects my jalapeno pretty much every time.  Just sayin'.  I think the initialization code in cgminer is much more robust compared to bfgminer.  I did flash the firmware on my jalapeno though, so I can't rule that out as being the issue.

Who woulda thought?? Unplugging it and plugging it back in got it to work! My hats off to you sir!

Thank you very much!

Tech support: level 99.  I don't think it helps any that there are over 750 warnings when compiling the BitForce_SC firmware...  I would just be worried about bfgminer detecting the BitForce devices properly after a power failure or reboot, especially if you need to reboot remotely.

[Pentium100]

If I use bfgminer's stratum proxy and connect with cgminer to it, all I get is h-not-zero errors for every share. Any solution for this?

[Taugeran]

If I use bfgminer's stratum proxy and connect with cgminer to it, all I get is h-not-zero errors for every share. Any solution for this?

bfgminer i believe is currently coded to broadcast to all clients a difftarget of 1 even if bfgminer is set to higher by the pool.

there is a new fork by someone who is coding dynamic target broadcasting...check the github.com network tab on bfgminer

[Luke-Jr]

If I use bfgminer's stratum proxy and connect with cgminer to it, all I get is h-not-zero errors for every share. Any solution for this?

This is a cgminer bug. When the nonce2 is smaller than 32-bit and not followed by null bytes, it corrupts the coinbase transaction and thus produces invalid shares.
BFGMiner always uses a 16-bit nonce2 (plenty big enough) to ensure it can work with upstream nonce2s as small as 24-bit.

Edit: Details:
[04:23:17] <Luke-Jr> nwoolls: basically cgminer is broken if nonce2_size is anything other than 4 (32-bit)
[04:23:41] <Luke-Jr> nwoolls: a proxy must always reduce the nonce2_size from the upstream server; BFGMiner always uses 2 (16-bit)
[04:24:14] <nwoolls> Luke-Jr: can you pastebin the patch that makes it work so i can at least give that stuff to Con and say I tried?
[04:24:30] <nwoolls> i'll hit him up when he's around and see if he's feeling cooperative
[04:24:27] <Luke-Jr> nwoolls: I'd have to write one.
[04:24:31] <nwoolls> ah gotcha
[04:24:38] <Luke-Jr> I'm not sure it's worth the effort, considering the likelihood they reject it
[04:24:48] <nwoolls> ya thats ok, i just meant enough for me to convey it to him
[04:24:42] <nwoolls> so those 2 lines should be enough to understand the issue for him?
[04:25:02] <Luke-Jr> nwoolls: probably not, those 2 lines are sufficient to explain the issue generally in a way that he will probably outright deny.
[04:25:19] <nwoolls> lol
[04:25:24] <nwoolls> nice
[04:25:27] <nwoolls> well i'll give it a shot
[04:25:34] <nwoolls> maybe he'll deny it and then look into it himself
[04:25:32] <Luke-Jr> nwoolls: after you confirm that hypothesis, you can give him more info: he is memcpy-ing nonce2 with a fixed 32-bit size, even if nonce2_size is smaller
[04:25:52] <Luke-Jr> nwoolls: he is also intentionally rejecting nonce2_size over 4 (or 8?), IIRC
[04:26:07] <Luke-Jr> which is perfectly legal, but in any case unrelated to BFGMiner interop issues
[04:26:32] <nwoolls> ty for looking into it, i appreciate it, starting to hear it from more and more users
[04:26:41] <Luke-Jr> side note: if he just memcpys the nonce2 with an adjusted size, it will fix *little endian*, but break on big

Edit2: <rant about cgminer bugs still wasting his time; 2.5 hours in this case>

[VanBreuk]

Hello, I was testing my hw capabilities with bfgminer 3.8.1 compiled in Ubuntu 12.04, enabling cpu in the build, and when trying to use cpu the benchmark test at startup returns

Code:

[2013-12-15 17:49:25] "c"        : is fastest algorithm at 0.00000 MH/s

All of the cpu cores show up once the program is running, and again the hashing totals are zero.

Code:

 8            |  12.87/ 10.53/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none

The pool command line parameters are working fine with other miners. Any idea where to look? Might it have anything to do with memory access?

Thank you.