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

[The00Dustin]

Their GUI only seems to allow for detected files to be submitted.  It doesn't detect the original ZIP file that I downloaded as containing anything malicious.

Maybe if I added the DLL with no compression...

The link you sent says contact support.  Can you do that and then send them the source so maybe they can send it on for deeper analysis?

[Luke-Jr]

I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software.  :/

AVG Research Lab has analyzed the file(s) you have sent from your AVG Virus Vault. Below you can find the results for each file. The final verdict on the file is either a correct detection or a false positive detection.

Further information about the verdicts are available at our website:
http://www.avg.com/faq-1184

"c:\Users\Chris Howie\Desktop\bfgminer-2.5.1-win32\pdcurses.dll" - detection is correct

Yeah, that's more or less what I expected.

Actually, on further thought, it is possible that file could be infected (though very unlikely). It is an exception to my general "compile everything" policy - I just used their official DLL binary.

Anyhow, here's what I sent to AVG:

One of my users is reporting that AVG insists my software is a virus, even after sending to you for review. Please correct your procedures to actually do proper checking and not flag innocent software.

The flagged file is pdcurses.dll, which I am using the official Windows binary distributed at:

http://voxel.dl.sourceforge.net/project/pdcurses/pdcurses/3.4/pdc34dllw.zip

If this official binary is indeed infected, please provide evidence so that it is removed from SourceForge (a highly respected software website).

In the meantime, want to see if it detects one I compile myself?
http://luke.dashjr.org/tmp/code/pdcurses.dll
e8bc66188d8f0503a5850bb11340e0eb8d60491a827ce27add2b460b65096780  pdcurses.dll

[Luke-Jr]

NEW VERSION 2.5.2, JULY 29 2012

2.6.0 with scrypt support will follow soon, but since it potentially introduces many new bugs, I felt it prudent to release 2.5.2 first.

Human readable changelog:

• Found and fixed a major bug where --failover-only would flood your current pool with requests if a secondary one longpolled first
• Refactored stale detection algorithm to only flag shares that are actually stale
• For BitFORCE devices, abandon nonce searches at the expense of any shares found in them, only if shares found would be guaranteed to be stale anyway; this is similar to how CGMiner abandons searches on any work restart, but shouldn't lose any valid shares
• If you have more devices than fit in your BFGMiner console window, you can scroll them with the Up/Down arrow keys. This obviously also means it no longer crashes on Windows
• Moved the "Q" (requested getworks) in the overall curses summary to the second status line as "GW", since it makes more sense there (and balances better on the screen)
• Improved config file parsing - you can use real JSON Numbers and false (for boolean options) now
• New "poolpriority" RPC command that can be used to set the priority order of failover - this is mainly for improved handling of failover with Puppet Master
• Submit stale shares, even during failure retries, if the user or pool wants them
• Many various other minor bugfixes

Full changelog

• Limit total number of curls recruited per pool to the number of mining threads to prevent blasting the network when we only have one pool to talk to.
• Bugfix: Skip writing configuration of range-limited int options with negative values
• Bugfix: Correctly attempt to load ~/.bfgminer/bfgminer.conf or ~/.cgminer/cgminer.conf as defaults
• Send X-Minimum-Wait header on longpolls, to explicitly inform pools we will handle a response with no delay
• bitforce: Abandon (only) stale searches for work restarts
• Keep a counter of enabled pools and use that instead of iterating over the pool list. Use that value to ensure we don't set the last remaining active pool to the rejecting state.
• bitforce: Skip out of sending work if work restart requested
• RPC: Writeup on poolpriority command usage
• Bugfix: API: Report errors from poolpriority command
• RPC: New "poolpriority" command to set the order of pool priorities
• strtok_ts: Thread-safe strtok that work on POSIX or Windows
• Bugfix: Supress "caught up" event when first switching to a pool
• Announce and restart work immediately when current pool has caught up to the current block
• Bugfix: Don't consider work stale due to other pools' longpolls, if --failover-only is active
• Refactor stale_work function to only flag actual stale shares
• stale_work: Don't factor getwork delay into expiry for shares (only for work itself)
• Bugfix: Use pool number rather than numeric pointer to strict pool, in block found notice
• Accept JSON Numbers in config file parameters
• Improve readability of OPT_HASARG in parse_config
• Allow JSON false as a valid value for strictly boolean options
• Include scan-serial in example configuration file
• fpgautils: add support for 57.6 kBd serial
• miner.php add a socket RCV timeout for if cgminer is hung and the API thread is still running
• BFL force all code to timeout to avoid hanging
• Detach pthread from within the api thread in case it is terminated due to not being instantiated before pthread_cancel is called from main, leading to a segfault.
• Initialise mdplatform.
• Find the gpu platform with the most devices and use that if no platform option is passed.
• Allow more platforms to be probed if first does not return GPUs.
• Bugfix: It is not a hardware error if nonces returned from modminer don't meet the pool target
• bitforce & icarus: Log detection failures at debug log level, so we don't confuse users who have different devices (which is why these drivers are failing detection!)
• Show "WAIT" (LIFE_WAIT status) if a cgpu is idle waiting for work (pool slow/dead)
• Instead of quitting on failing N retries, just discard the share
• Bugfix: Don't discard stale shares after submission failure, if user or pool wants stales submitted
• Bugfix: Record discard-during-retry shares in the sharelog
• Bugfix: Only show Algorithm in RPC summary if CPU mining is actually active
• OpenCL: Remove intensity from statline, since it overflowed
• Move "Q" (requested getworks) to second status line as "GW" to balance out better
• Bugfix: Use a mutex to control non-curses output
• Simplify code to a single vprintf path for curses-less printing
• Move opt_quiet check to my_log_curses, so it works for curses-less builds
• Use log_generic for vapplog to cut down on code duplication
• Add space to log output now that there is more screen real estate available.
• Bugfix: Copy argv[0] given to dirname()
• Find the gpu platform with the most devices and use that if no platform option is passed.
• Allow more platforms to be probed if first does not return GPUs.
• Detach pthread from within the api thread in case it is terminated due to not being instantiated before pthread_cancel is called from main, leading to a segfault.
• Debug output per thread hashrate is out by a factor of 1000.
• Don't check if CPUs are sick since they can't be.
• Calculate midstate in separate function and remove likely/unlikely macros since they're dependent on pools, not code design.
• Display in debug mode when we're making the midstate locally.
• Bugfix: Document --no-adl and --gpu-platform
• Bugfix: Remove redundant documentation of --auto-fan and --auto-gpu (they are in GPU-specific options)
• CPU mining may not be included in binaries, but it's not deprecated for BFGMiner either
• Bugfix: Restore case-insensitivity to input
• Scroll the device list with up/down arrow keys, if it is overflowed
• Use select statement to handle input
• Bugfix: Actually check that the device fits in the individual summary window before trying to print it
• Bugfix: Fix build without curses but with OpenCL
• Bugfix: Don't show a Temperature key if it isn't known
• BFGMiner-specific NEWS fix

[Epoch]

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  

I also checked cgminer 2.6.0 (on which bfgminer 2.5.2 is largely based, except for scrypt) and it runs fine.

[Luke-Jr]

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  

Can you try replacing libcurl-4.dll with the one from 2.5.1?

[Epoch]

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  

Can you try replacing libcurl-4.dll with the one from 2.5.1?

Yes, that fixed the issue. Thanks, Luke.

[Luke-Jr]

NEW VERSION 2.5.3, JULY 29 2012

Human readable changelog:

• This should fix the issue Epoch reported

Full changelog

• Bugfix: Add zlib1.dll to Win32 release archive
• Bugfix: SICK low-hashrate is now determined by being under 1/3 the runtime average hashrate
• Bugfix: cpu_set_t is never #defined, so use CPU_ZERO which is a macro

[Luke-Jr]

NEW VERSION 2.6.1, JULY 29 2012

Note that this does not have CGMiner's scrypt "sick" bug, and only adds scrypt support (2.5.3 has everything else).

Human readable changelog:

• Major feature upgrade: Scrypt support. This is non-trivial to get working well and I suggest reading the SCRYPT-README included before asking any questions. While I do not in general support other currencies to bitcoin, with a large enough bitcoin bounty Con added this feature; see: https://bitcointalk.org/index.php?topic=92887.0

Full changelog

• Autoselect --scrypt iff all pools send scrypt work
• Adapt SCRYPT-README to BFGMiner (directing Bitcoin donations the correct direction to reach Con)
• Remove mentions of Litecoin specifically
• Bugfix: Fix build without OpenCL but with scrypt
• make-release: Add SCRYPT-README
• Bump version 2.6.0, adding SCRYPT README to makefile.
• Smarter autogen.sh script.
• Sleeping on intensity decrease is broken, remove it.
• Sleep only the extra amount of time we overran the dynamic interval in dynamic mode.
• Add scrypt documentation in the form of a separate readme.
• Fix build error without scrypt enabled.
• Limit thread concurrency for scrypt to 5xshaders if shaders is specified.
• Simplify repeated use of gpus[gpu]. in ocl.c
• Find the nearest power of 2 maximum alloc size for the scrypt buffer that can successfully be allocated and is large enough to accomodate the thread concurrency chosen, thus mapping it to an intensity.
• Don't make opt_scrypt mandatory blocking with opencl code.
• Update kernel versions reflecting changes in the API.
• Make the thread concurrency and lookup gap options hidden on the command line and autotune parameters with a newly parsed --shaders option.
• Fix target testing with scrypt kernel as it would have been missing shares below target.
• Always create the largest possible padbuffer for scrypt kernels even if not needed for thread_concurrency, giving us some headroom for intensity levels.
• Use the detected maximum allocable memory on a GPU to determine the optimal scrypt settings when lookup_gap and thread_concurrency parameters are not given.
• Check the maximum allocable memory size per opencl device.
• Add debugging output if buffer allocation fails for scrypt and round up bufsize to a multiple of 256.
• Nonce testing for btc got screwed up, leading to no accepted shares. Fix it.
• Display size of scrypt buffer used in debug.
• Allow intensities up to 20 if scrypt is compiled in.
• Add name to scrypt kernel copyright.
• Allow lookup gap and thread concurrency to be passed per device and store details in kernel binary filename.
• Ignore negative intensities for scrypt.
• Change the scale of intensity for scrypt kernel and fix a build warning.
• Correct target value passed to scrypt kernel.
• Use 256 output slots for kernels to allow 1 for each worksize.
• Test the target in the actual scrypt kernel itself saving further calculations.
• Reinstate GPU only opencl device detection.
• Decrease lookup gap to 1. Does not seem to help in any way being 2.
• Fix build.
• Make pad0 and pad1 local variable in scrypt kernel.
• Constify input variable in scrypt kernel.
• Send correct values to scrypt kernel to get it finally working.
• Create command queue before compiling program in opencl.
• Fix external scrypt algo missing.
• Limit scrypt to 1 vector.
• Handle KL_SCRYPT in config write.
• Get rid of stuff.
• Don't enqueuewrite buffer at all for pad8 and pass work details around for scrypt in dev_blk.
• Set the correct data for cldata and prepare for pad8 fixes.
• Get rid of spaces in arrays in scrypt kernel.
• Start with smaller amount of hashes in cpu mining to enable scrypt to return today sometime.
• Free the scratchbuf memory allocated in scrypt and don't check if CPUs are sick since they can't be. Prepare for khash hash rates in display.
• Add cpumining capability for scrypt.
• Set scrypt settings and buffer size in ocl.c code to be future modifiable.
• Cope with when we cannot set intensity low enough to meet dynamic interval by inducing a forced sleep.
• Make dynamic and scrypt opencl calls blocking.
• Fix nonce submission code for scrypt.
• Make sure goffset is set for scrypt and drop padbuffer8 to something manageable for now.
• Set up buffer8 for scrypt.
• Build fix for opt scrypt.
• Don't check postcalc nonce with sha256 in scrypt.
• Don't test nonce with sha and various fixes for scrypt.
• Make scrypt buffers and midstate compatible.
• Use specific output array entries in scrypt kernel.
• Provide initial support for the scrypt kernel to compile with and mine scrypt with the --scrypt option.
• Enable completely compiling scrypt out.
• Begin import of scrypt opencl kernel from reaper.

[kano]

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...
Don't forget to get the code from the master git

[Luke-Jr]

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...

What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.

[kano]

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...

What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.

1) If there is a problem with the parameter, it will still change the pools and then report an error
(shouldn't change anything until it's sure it's OK)
2) If you specify the same pool twice it leaves a gap in the pool priority numbers
(should just report an error and do nothing)

[Luke-Jr]

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...

What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.

1) If there is a problem with the parameter, it will still change the pools and then report an error
(shouldn't change anything until it's sure it's OK)
2) If you specify the same pool twice it leaves a gap in the pool priority numbers (unless it's the last priority pool)
(should just report an error and do nothing)

OK, nothing major then...

• the first one was intentional (the alternative is slower, not that it matters much)
• both issues only matter when the caller uses it wrong anyway
• neither problem can cause any real problems

Thanks Kano, I have to admit you deserve more credit than I give you sometimes...

[Epoch]

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.

[Luke-Jr]

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.

Could you open an Issue with as much details as possible, please? Especially useful is:

• Can anything be done to trigger it (as opposed to "it just happens eventually")?
• What messages appear in the log immediately before and when it goes SICK?
• Which versions did you find are working, and which ones have the problem?

Thanks!

[Epoch]

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.

Could you open an Issue with as much details as possible, please? Especially useful is:

• Can anything be done to trigger it (as opposed to "it just happens eventually")?
• What messages appear in the log immediately before and when it goes SICK?
• Which versions did you find are working, and which ones have the problem?

Thanks!

Understood. I will collect detailed information this evening.

[Luke-Jr]

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.

Could you open an Issue with as much details as possible, please? Especially useful is:

• Can anything be done to trigger it (as opposed to "it just happens eventually")?
• What messages appear in the log immediately before and when it goes SICK?
• Which versions did you find are working, and which ones have the problem?

Thanks!

Understood. I will collect detailed information this evening.

If you can reproduce it, making the log with --debug enabled may be helpful. You'll need to be sure to redirect it to a log file so it doesn't just scroll off the screen, by adding 2>logfile to your commandline.

[hashking]

For some reason when I use 2.4.4 and save out the configuration file. When I restart it comes up with fatal JSON error.

And I have to enter all my pools again.

Phil

I am also getting this error.  Has this issue been fixed.  Thanks.

[Luke-Jr]

For some reason when I use 2.4.4 and save out the configuration file. When I restart it comes up with fatal JSON error.

And I have to enter all my pools again.

Phil

I am also getting this error.  Has this issue been fixed.  Thanks.

Yes, that was fixed in 2.5.2

[bitpop]

Since the newest version 1 out of 4 singles dies after a few minutes. Restarting bfg miner gives me another few minutes.

[BlackPrapor]

Since the newest version 1 out of 4 singles dies after a few minutes. Restarting bfg miner gives me another few minutes.

Same here with my mini rigs. Right now I'm back to bfgminer 2.5.1, its more stable, but gives around 0.75% rejects. Hope that either luke, or ckolivas will fix the issue. I will definitely donate aftewards