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...
Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 79. (Read 1193358 times)
December 13, 2013, 01:56:55 AM
December 12, 2013, 05:28:08 PM
My Jalapeno needs a hard reboot the odd time too, or it just falls off the USB bus. Usually after the host has rebooted.
December 12, 2013, 05:10:39 PM
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.
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!
December 12, 2013, 09:55:26 AM
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.
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.
December 12, 2013, 09:47:06 AM
@stewdk, static binary is redistributable cause it doesn't require libraries.
December 12, 2013, 09:42:23 AM
@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.
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?
December 12, 2013, 04:18:46 AM
@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.
But that's not the point.
The application fails to compile statically, into single binary with all libraries bundled.
December 11, 2013, 02:44:59 PM
also can i use set device with NFY@Serial#:osc6_bits=##
i cant find code to indicate either way
i cant find code to indicate either way
December 11, 2013, 01:56:42 PM
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:
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 [email protected] wall supply
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 [email protected] wall supply
December 11, 2013, 01:38:38 PM
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?
I don't remember what you said back then, and I can't find it on this thread.
What are your thoughts?
December 11, 2013, 11:03:25 AM
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:
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:
Append the quantal repository to /etc/apt/sources.list:
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):
Check that the new version (0.9.20-1) of libmicrohttpd is available:
Now, apt won't actually choose the new version of libmicrohttpd-dev yet, so create file /etc/apt/preferences.d/libmicrohttpd-dev with contents:
Check the pinned priorities for good measure (Candidate should be version 0.9.20-1) :
Double check the installed versions
Finally, compile bfgminer by the usual means.
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.
December 11, 2013, 10:21:08 AM
I want to statically link libraries so that I have single all-in binary.
That's what I do:
But I get error on make:
I'm not a C programmer, could someone help me to understand what is going on?
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?
December 11, 2013, 07:38:52 AM
I've gained a lot with this method I would recommend to anyone to start winning start already miner 
December 11, 2013, 03:44:07 AM
@Luke-Jr I can't get my USB block erupters to work on bfgminer.
I run Gentoo & they never show up in /dev/ttyUSB0 the way you keep saying it does, I have done everything I can think of & than some.
Well, there's something broken with your install, because they should appear as /dev/ttyUSB* - they do on any Linux/linux-based OS I've seen, even on OpenWRT.
Do you have the VCP drivers installed?
December 10, 2013, 11:37:39 PM
thanks for your hard work!!!
December 10, 2013, 09:33:57 PM
just curious for an explaination of this snippet of code from driver-bitfury.c:
in bitfury_init_oldbuf
i have one NF1 that seems to throw it incessantly after a period of time if i set the osc6 above 52. this is on a BBB(independantly powered) linked into a dlink DUB-H7/B powered with a 2.5A supply.
also on the hub is another NF1(runs fine at 54 bits) and a pencil modded BPMC BF1.
for shits and giggles ive changed the supply to the dlink to a 3.5A to see if theres a difference.
TL;DR
is that tidbit of code an indication the chip is power starved for the frequency it is set at?
in bitfury_init_oldbuf
Code:
if (tried > 3)
{
applog(LOG_ERR, "%"PRIpreprv": %s: Giving up after %d tries",
proc->proc_repr, __func__, tried);
bitfury->desync_counter = 99;
return false;
}
i have one NF1 that seems to throw it incessantly after a period of time if i set the osc6 above 52. this is on a BBB(independantly powered) linked into a dlink DUB-H7/B powered with a 2.5A supply.
also on the hub is another NF1(runs fine at 54 bits) and a pencil modded BPMC BF1.
for shits and giggles ive changed the supply to the dlink to a 3.5A to see if theres a difference.
TL;DR
is that tidbit of code an indication the chip is power starved for the frequency it is set at?
December 10, 2013, 08:15:46 PM
I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php
could you fix the pool diff in scrypt?
its always Diff 0/0
that's the only thing that I can see needs fixing.
what your saying makes no sense
I mine on litecoinpool.org they start out with pool Diff 32 & if your hash is slow you will get kicked down to 16 or 8 but no lower
& when I use bfgminer what do I see Diff 0/0 so that tells me there is something worng with bfgminer when doing scrypt.
cgminer v3.7.2 works fine with scrypt 80/16
BFGMiner is showing the correct difficulty numbers. They are just so small they get rounded to 0. "Diff 32" is actually Diff 0.00048828125. cgminer is using the same conversion scheme that pools use, where all difficulties are multiplied by 65536. Except that even cgminer has now dropped that conversion in the block difficulty number. If only that conversion scheme had never been implemented, all this confusion could've been avoided.
I guess the conversion scheme was done because decimal numbers are thought of as inconvenient. Because scrypt mining is about a thousand times slower than sha256 on GPUs, it would take a thousand times longer to mine Diff 1 shares. Thus no pool would ever set a real target of even 1 for a worker. Then someone came up with the genius idea of multiplying everything by 65536 so it looks neater. Sheesh.
Oh WoW I did not know that, thanks for the info juhakall
It sure would have been nice for Luke-Jr to post that info somewhere on the bfgminer github page.
@Luke-Jr I can't get my USB block erupters to work on bfgminer.
I run Gentoo & they never show up in /dev/ttyUSB0 the way you keep saying it does, I have done everything I can think of & than some.
the only thing I ever find is this, here's the path to one of them /dev/bus/usb/01/016
& that's info that comes up with lsusb. I have CP210x all setup in my kernel
CONFIG_USB_SERIAL_CP210X=m should it not be a module? should I bake it into the kernel?
well anyways they run ok on cgminer with no problems but I would love to have them to run on bfgminer someday.
I only use bfgminer for my block erupter blades because my block erupter blades don't like "stratum-mining-proxy" but they like "bfgminer stratum-proxy" kind of odd but its all good.
December 10, 2013, 06:32:38 PM
i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/
Tried solution for ArchLinux on Raspberry-Pi:1) wget https://aur.archlinux.org/packages/hi/hidapi-git/hidapi-git.tar.gz
2) tar -xf ./hidapi-git.tar.gz
3) cd ./hidapi-git
4) change in PKGBUILD file:
a) arch=(i686 x86_64) to arch=(armv6h)
You might have to change arch=(armv**) to more appropriate for beaglebone (armv7?).
b) depends=('systemd-tools' 'libusbx' 'fox') to depends=('systemd-tools' 'libusbx')
c) ./configure --enable-testgui --prefix=/usr to ./configure --prefix=/usr
5) in hidapi-git directory run makepkg --asroot
6) pacman -U ./hidapi-git-354.1a42177-1-armv6h.pkg.tar.xz
This allows to install and remove hidapi as a package cleanly.
7) configure bfgminer < 3.8.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --without-sensors --without-libmicrohttpd
In 3.8.1 hashbuster2 changed to hashbusterusb
UPD: yet configure option still the same - no need to change here.
UPD2: I'm wrong it has been changed, but not in README
HTH!
December 10, 2013, 04:24:04 PM
i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/
Tried solution for ArchLinux on Raspberry-Pi:1) wget https://aur.archlinux.org/packages/hi/hidapi-git/hidapi-git.tar.gz
2) tar -xf ./hidapi-git.tar.gz
3) cd ./hidapi-git
4) change in PKGBUILD file:
a) arch=(i686 x86_64) to arch=(armv6h)
You might have to change arch=(armv**) to more appropriate for beaglebone (armv7?).
b) depends=('systemd-tools' 'libusbx' 'fox') to depends=('systemd-tools' 'libusbx')
c) ./configure --enable-testgui --prefix=/usr to ./configure --prefix=/usr
5) in hidapi-git directory run makepkg --asroot
6) pacman -U ./hidapi-git-354.1a42177-1-armv6h.pkg.tar.xz
This allows to install and remove hidapi as a package cleanly.
7) configure bfgminer < 3.8.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --without-sensors --without-libmicrohttpd
In 3.8.1 hashbuster2 changed to hashbusterusb
UPD: yet configure option still the same - no need to change here.
UPD2: I'm wrong it has been changed, but not in README
HTH!
December 10, 2013, 04:17:52 PM
showed hidraw and libusb were installed to /usr/local/lib
https://bitcointalksearch.org/topic/m.3879613
Jump to: