(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64

[Epoch]

It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.

Appreciated, thanks. It doesn't take long for me to run into this state (no more than a few hours at most) so I will, at the very least, be able to see if your fix improves the situation quickly enough.

If you can test 2.99.0, that does include this change.

2.99.0 crashed (simultaneously on 2 machines) when bitminter went down around an hour ago (both using stratum); bfgminer 2.10.5 on a 3rd machine did not crash (although it was pointed at ozcoin at the time). Will try 2.99.0 again to see if it improves the WAIT issue.

[kano]

While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?

It's already actual, since pools can't know who is or isn't verifying what.

Umm what? So you just said that there is no verification of the transaction data that GBT sends. So if there is no double checking, how is there an actual increase in security?

Say my boss installs a security camera by the vending machine, purposefully doesn't turn it on, and then leaves the room. We both know there's a security camera, but we both know it's not working. Is there an actual increase in security? Am I actually deterred from stealing? I would say no.

This is more like he installs a security camera, leaves it on, but "never" looks at the monitor/tape attached.
You really don't know if today might be the day he checks it...

You have yet ever to explain how having the transaction list is 'more' secure - other than to say "It is more secure" thus it must be ... LOL
Let alone how you could actually do anything with it.

The simple point is that if any pool does anything with 'bogus' transactions, you don't need a miner to see it ... any bitcoind can see it ... and the miner would need a bitcoind also ...
If the pool is giving you 'suspect' transaction to mine, it makes no difference until you find a block, but when you find a block those 'suspect' transaction will be there for everyone to see in the blockchain anyway.
But you have NO clear definition of what IS a 'suspect' transaction.

More the point, the reason why you haven't done anything with this data is simply that you cannot code up anything to actually do anything useful with it.

The check itself is a waste.

Basically it's some weird attack at pool ops - and we certainly know one ex-pool op who can't be trusted.

[Epoch]

It seems to be failing over from a getwork/GBT pool to a stratum pool which has been suspended due to inactivity.
I can't reproduce your problem here, but I'm adding an extra check that a pool is working before switching to it, for 2.10.6; hopefully that will fix it.

Appreciated, thanks. It doesn't take long for me to run into this state (no more than a few hours at most) so I will, at the very least, be able to see if your fix improves the situation quickly enough.

If you can test 2.99.0, that does include this change.

Just an update: I've been running 2.99.0 for 20 hours now, using the same settings (same pools, pool order, with stratum enabled) as before that led to the unrecoverable WAIT issue. So far the WAIT issue has not re-appeared for me; your extra check in 2.99.0 is looking good so far. I will keep running it.

[Luke-Jr]

I'm coming up on 2 days uptime with BFGMiner 2.99.0 myself... pretty happy with how well it's working out so far - now I just hope the SC driver changes work without problems (haha).

In other news, it took about an hour to basically just merge Avalon's cgminer fork into BFGMiner. It doesn't work nicely yet (the whole thing appears as a single Processor), but should work. And since the new driver API is abstracted nicely, you can build an Avalon BFGMiner that supports all the other devices as well. I don't have a complete firmware image for it yet, but that may be right around the corner since we already have OpenWrt support. Too bad I don't have an Avalon to test on.
I was actually surprised how simple merging it turned out to be. While the cgminer fork requires hacks, those ended up all being in code that I could just mirror inside the Avalon driver (since it's abstracted now).
The code is under the git branch "avalon" if anyone wants to give it a go or check it out...

[JakeTri]

Hi Luke,

I'm running 2.99.0 on multiple systems for several days (3 to be more exact) without any issue so far.
My setup use GPUs and BFL FPGA.

Jake

[Luke-Jr]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

[Luke-Jr]

(above firmware seems to be fixed now; please note that if you symlink the BFGMiner OpenWrt Makefile directory, the symlink and directory names must be identical)

[xvc]

Hi thanks for Your work in developing BFGMiner.
I appreciate that.

I'm new user on bitcointalk and wish to report that the newest version runs smoothly on windows 7 64bit with 2 7970 cards and one ZTEX 1.15y module attached.

Good work !

[Luke-Jr]

Just a little early notice.. 3.0 alpha1 will not work correctly with BitForce SC devices.
So expect to upgrade to 3.0 final before your ASICs arrive.

[JakeTri]

Luke, do you have any new gentoo ebuild for 2.99.0 version ?

I manually patched the latest ebuild available on the bitcoin overlay (2.10.5) to account for the new file names used by the documentation and it build fine but I'm not sure if that was the only change needed.

It would be nice is the bitcoin overlay have a bfgminer-9999 version that build directly form git

[Blackasaurus]

is there a function similar to diablo miner's -f? What it did was it allowed me to game or do GPU semi intensive things on my computer while continuing to mine (of course not as fast)

[Luke-Jr]

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

[mitty]

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!

[Luke-Jr]

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!

You can workaround the issue by adding the stratum URI as one pool, and the getwork URI as another and --no-stratum to prevent the getwork from trying to auto-upgrade. This way, the stratum one will just die like normal, and then BFGMiner will failover to the next pool (getwork).

[mitty]

Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it.

Does anyone have a decent workaround for hanging stratum connections?
Already a known bug: https://github.com/luke-jr/bfgminer/issues/177

I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution.

Thanks!

You can workaround the issue by adding the stratum URI as one pool, and the getwork URI as another and --no-stratum to prevent the getwork from trying to auto-upgrade. This way, the stratum one will just die like normal, and then BFGMiner will failover to the next pool (getwork).

Thanks!

[Epoch]

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.

[Luke-Jr]

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.

What device(s), pool(s) etc? Can you post a debug.log somewhere?

[Epoch]

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.

What device(s), pool(s) etc? Can you post a debug.log somewhere?

I'm using the following command line (user and pass obfuscated):

Code:

bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all

Debug output here: http://pastebin.com/gj9LnKid

Using the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only.

[Luke-Jr]

I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing.

Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries.

What device(s), pool(s) etc? Can you post a debug.log somewhere?

I'm using the following command line (user and pass obfuscated):

Code:

bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all

Debug output here: http://pastebin.com/gj9LnKid

Using the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only.

Can you meet up with me on IRC for some more aggressive investigation?

[twobitcoins]

The code in findnonce.c leaks the contents of work structures.  It seems that postcalc_hash() should call "clean_work(&pcd->work);" before "free(pcd);".  Also, postcalc_hash_async should use calloc instead of malloc, otherwise when it calls __copy_work which calls clean_work, there is a risk that clean_work will try to free uninitialized pointers.

This problem likely exists elsewhere in the code.  Several other source files use __copy_work but not clean_work, which is suspicious.  Perhaps it would be safer for all work structures to be allocated on the heap with make_work rather than embedded in other structures.