Topic: [GUIDE] BitFury Miner Support/Tuning - page 2. (Read 148049 times)

anyone have a link to the pi image?  or can i just use a standard raspbian image and then copy over the chain miner etc.

Dear,
I want to buy one 400G rig, anyone is planing to sell your used rig. PM me.

Thank you!

Did you find a way to get them to work? I am having the same issue.

Sounds like there is a thinner amount of conducting metal somewhere along the path of electricity. The problem may be in the cable, the connectors, the soldering, or the PCB. Hard to tell. Is the cable hotter on the side of a PSU, or on the side of M-board? Either way I would try to replace the PSU if possible.

For one of m-boards, the cables that connect the PSU with the rPI seem to be getting hotter and hotter over time. In fact, the white connectors are starting to get brownish.  I have not done any over clocking.

Another board with even more h-cards is actually cooler than the one I mentioned before. The PSU supports more power than what the set of m-boards consume.

Does anyone know why this might be happening? Any workarounds? :-/

I compiled bfgminer with --enable-bfsb. Won't work on V1 board, but I have a v2.3 board coming to replace my broken V1. So I'll see if I can get the black arrow driver to work.

How did you get BFGminer to recognize Blackarrow bitfury boards?  I never have been able to.  I am running minepeon.

I always had better luck with bfgminer than with cgminer. Over time I have switched both of my rigs back to chainminer, which I did not want to do.

running cgminer 4.3.3 and compiling with --enable-bab i get BaB0: Delay getting work reply ...

chips are detected at startup and connected to pool, can any cgminer users help?

Possibly something wrong with the Pi or PSU (sometimes they fail if too close to 100% load)?

Went flawless. Thanks!

so one of my boards recently stopped working (slot 3, I have other boards in slots 1,2 5,6 & 9,10) - I tried reseating it several times and tried it in other slots (slot 6 and slot 13) with no effect. no hashrate, no heat, no detection in the stats.log file.

looking at it theres no visible problem. a bit of dust had accumulated between the inductor and the TPS53355 possibly (but not likely) shorting 2-3 of the pins ont he upper side of the chip. I dont think this is the problem, but its theonly lead i have

any easy troubleshooting techniques?  I have a spare TPS53355 chip I could actually drop in if that is the issue, but i dont have the fine-point soldering skils to do that myself. (contracting out that task might work, but not sure what to look for in the yellowpages (Toronto, Ontario) to find someone capable of doing it.)

any ideas? I did not have a miultimeter handy at the time so no voltage info yet. I might have to wire up a 12V/GND to the board to check at home

http://goo.gl/5ws3QU

Thanks - either that or this will do the trick:


This information was added to the blog as well: https://www.megabigpower.com/blog/?p=60

Arorts - I will look into that.

Anyone has seen the repeating message "New proxy version available  Please update!" when checking their proxy process in the miner?

Any process to back it up and update it to a new version?

Totally agree with you! I have already found here  answers to the problems I have faced with!

Well I did update my overall Raspbian using this command line, which apparently does include any OpenSSL updates as well:


However, now when I run cat /run/shm/.stat.log it's now showing even the slots where there are no H-Cards with tons of errors from B-F.

speed:13325 noncerate[GH/s]:328.450 (1.283/chip) hashrate[GH/s]:441.082 good:22942 errors:26313 spi-err:1757 miso-err:1191 jobs:283 cores:11% good:246 bad:2 off:8 (best[GH/s]:0.000) Tue Apr  8 18:28:18 2014
0:   871   32.484   35.038   2269   82   0   1   16   0   0   (2.030/chip)   17%
1:   758   30.050   33.125   2099   102   0   0   15   1   0   (1.878/chip)   16%
2:   817   33.959   35.123   2372   49   1   0   15   1   0   (2.122/chip)   18%
3:   869   34.260   34.880   2393   49   1   0   16   0   0   (2.141/chip)   18%
4:   809   31.496   31.191   2200   34   0   0   16   0   0   (1.969/chip)   17%
5:   704   28.318   28.580   1978   28   0   2   13   0   3   (1.770/chip)   15%
6:   822   25.240   27.534   1763   69   0   1   15   0   1   (1.578/chip)   13%
7:   872   34.245   34.700   2392   34   0   0   16   0   0   (2.140/chip)   18%
8:   768   26.028   27.101   1818   43   0   2   14   0   2   (1.627/chip)   14%
9:   767   24.925   25.642   1741   31   0   2   14   0   2   (1.558/chip)   13%
A:   868   27.445   31.032   1917   654   35   30   16   0   0   (1.715/chip)   15%
B:   880   0.000   19.385   0   5037   345   225   16   0   0   (0.000/chip)   0%
C:   880   0.000   19.448   0   5025   343   236   16   0   0   (0.000/chip)   0%
D:   880   0.000   19.501   0   5026   351   224   16   0   0   (0.000/chip)   0%
E:   880   0.000   19.268   0   5030   331   239   16   0   0   (0.000/chip)   0%
F:   880   0.000   19.533   0   5020   350   229   16   0   0   (0.000/chip)   0%


Previously, this file simply ended at A and didn't gave me all those errors.

Any thoughts?  

UPDATE: It seems the problem went away by itself so no more nasty extra lines in that file. :-)

I've passed this info along to our devs and will get a response shortly.

-Jason

I think it is based on raspbian, so all you need to do is update the package once available

see http://storyhub.actionaid.org/forums/viewtopic.php?t=74133&p=531967

As you might know, openssl libraries based on 1.01 and 1.02 beta releases are apparently infected with the heartbleed bug. This is the bug that allows snooping and steeling of information over SSL connections.

Does anyone know whether it's safe to upgrade/recompile the openssl libraries that came with the Raspberry PI distributed by Bitfury???
What's the simplest/safest method to do so??

I just typed openssl version -v and it definitely shows version 1.0.1e, which seems to carry the bug as explained here!!!:

Check out http://heartbleed.com

This is a CRITICAL topic!!! Please advise!!!