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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: hashking on July 30, 2012, 12:39:28 PM

Quote from: filharvey on July 09, 2012, 05:24:41 PM

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

hashking

sr. member

Activity: 308

Merit: 250

Quote from: filharvey on July 09, 2012, 05:24:41 PM

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

legendary

Activity: 2576

Merit: 1186

Quote from: Epoch on July 30, 2012, 12:33:58 PM

Quote from: Luke-Jr on July 30, 2012, 12:10:10 PM

Quote from: Epoch on July 30, 2012, 11:48:22 AM

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

https://bitcointalksearch.org/topic/m.1065423

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.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: Luke-Jr on July 30, 2012, 12:10:10 PM

Quote from: Epoch on July 30, 2012, 11:48:22 AM

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

https://bitcointalksearch.org/topic/m.1065423

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

legendary

Activity: 2576

Merit: 1186

Quote from: Epoch on July 30, 2012, 11:48:22 AM

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

https://bitcointalksearch.org/topic/m.1065423

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

legendary

Activity: 922

Merit: 1003

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

https://bitcointalksearch.org/topic/m.1065423

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

legendary

Activity: 2576

Merit: 1186

Quote from: kano on July 29, 2012, 06:49:19 PM

Quote from: Luke-Jr on July 29, 2012, 06:15:29 PM

Quote from: kano on July 29, 2012, 05:58:21 PM

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...

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Luke-Jr on July 29, 2012, 06:15:29 PM

Quote from: kano on July 29, 2012, 05:58:21 PM

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

legendary

Activity: 2576

Merit: 1186

Quote from: kano on July 29, 2012, 05:58:21 PM

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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

legendary

Activity: 2576

Merit: 1186

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://bitcointalksearch.org/topic/attn-litecoin-gpu-miners-scrypt-support-for-cgminer-92887

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: Luke-Jr on July 29, 2012, 02:15:29 PM

Quote from: Epoch on July 29, 2012, 01:23:48 PM

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. Sad

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

Yes, that fixed the issue. Thanks, Luke.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Epoch on July 29, 2012, 01:23:48 PM

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. Sad

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

Epoch

legendary

Activity: 922

Merit: 1003

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. Sad

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

legendary

Activity: 2576

Merit: 1186

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: cdhowie on July 27, 2012, 09:15:52 AM

Quote from: cdhowie on July 27, 2012, 01:42:44 AM

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. :/

Quote

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:

Quote

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

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: cdhowie on July 27, 2012, 09:21:28 AM

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?

cdhowie

full member

Activity: 182

Merit: 107

Quote from: rjk on July 27, 2012, 09:19:17 AM

Wonder if you can zip up the source code for just pdcurses.dll and send them in together.

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...

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

Quote from: cdhowie on July 27, 2012, 09:15:52 AM

Quote from: cdhowie on July 27, 2012, 01:42:44 AM

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. :/

Quote

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.

Wonder if you can zip up the source code for just pdcurses.dll and send them in together.

Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 29. (Read 260035 times)