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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Inaba on September 20, 2012, 06:24:54 PM

I don't have any development tools on Windows, so I don't know.. it's the EXE that's getting flagged for me anyway.

It was linked earlier: http://luke.dashjr.org/tmp/code/pdcurses.dll

But if the EXE is getting flagged, that probably won't help Sad

Maybe some time we should "bisect" out what it's flagging and workaround it...

Inaba

legendary

Activity: 1260

Merit: 1000

I don't have any development tools on Windows, so I don't know.. it's the EXE that's getting flagged for me anyway.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Inaba on September 20, 2012, 05:13:23 PM

I get similar problems from Bitdefender. The CS has been less than helpful. Bitdefender is a piece of shit, BTW... don't buy it.

Does the self-compiled DLL work for you?

Inaba

legendary

Activity: 1260

Merit: 1000

I get similar problems from Bitdefender. The CS has been less than helpful. Bitdefender is a piece of shit, BTW... don't buy it.

burger

full member

Activity: 195

Merit: 100

Quote from: Luke-Jr on July 27, 2012, 12:31:29 PM

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

I still get the virus warning from AVG when I downloaded 2.8.0. But your compiled version didn't have the virus.

I uploaded the file to https://www.virustotal.com/file/94995b0560d2ccda7951252397eb152b499454746b75d03479bbfa551def41e4/analysis/ and 9/41 found the virus.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: lenny_ on September 20, 2012, 06:07:25 AM

Does bfgminer require root account to run Ztex boards?

No, but you might need to check your user's permissions. The devices are under /dev/bus/usb/*/*

lenny_

legendary

Activity: 1036

Merit: 1000

DARKNETMARKETS.COM

Does bfgminer require root account to run Ztex boards?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Looks like I accidentally built 2.8.0 using some AVX instructions, so it crashes in some cases on older (pre-Sandy Bridge) CPUs.
I've rebuilt it as 2.8.0-1 and updated the download links on the main post.

elvizzzzzzz

full member

Activity: 135

Merit: 100

Quote from: Luke-Jr on September 15, 2012, 01:53:08 PM

Quote from: elvizzzzzzz on September 15, 2012, 06:36:15 AM

Thanks for the reply. That's what I guessed, it was the Debian-Ubuntu thing that caused my confusion.
FWIW the current version of eglibc on Debian|unstable is glibc_13

BFGMiner should work with any libc, so I'm guessing the problem you hit is just an ABI thing.

Just FYI - I now have bfgminer-2.7.5 as an amd64 debian package that runs on sid,
(no problems apart from something weird with patch not liking a filename)
and am working through the variables. The fan speed control works fine with my 7970,
which I need, but gpu-vddc will not alter the voltage (no big deal).

My thanks should be with you by now :-)

Luke-Jr

legendary

Activity: 2576

Merit: 1186

NEW VERSION 2.8.0, SEPTEMBER 15 2012

Some pretty major improvements here, including support for Cairnsmore FPGAs and the new ASIC-ready getblocktemplate mining protocol.

I don't expect this is entirely stable yet, and it's had (at least/only) tens of hours of testing so far. If you upgrade, be sure you can monitor and restart your rigs if needed. Please report all bugs to the Issue tracker on GitHub so I can fix them

Note that starting with this version, Jansson (JSON library) is no longer bundled with the source code and must be installed independently (binaries are unaffected). Additionally, version 2.0+ is now required. Let me know if this causes trouble for anyone.

Human readable changelog:

Basic getblocktemplate decentralized mining protocol support, including rolling extranonce (based on libblkmaker 0.1).
New Cairnsmore driver, including autodetection (based in part on Kano's Icarus "timing" feature).
Support for per-pool proxies, based in part on Kano's similar work (but cleaned up and not compatible).
Numerous minor fixups to Ztex driver.
Minor improvements to Icarus driver, including the ability to disable the reopen quirk and detection when the default hash speed is wrong.
Updated RPC API from Kano to include debug and setconfig methods.
Updated miner.php from Kano to hide IP addresses for security (configurable).

Full changelog

Be specific about jansson version requirement
Replace "Alive" in pool status with protocol in use (GBT or GWork)
Remove copy of old jansson from source repository
Honour block template expiry (BIP 23 Basic Pool Extensions "expires")
Add --no-gbt option so getblocktemplate can be disabled if it causes problems
BIP 22 long polling
Properly detect pool protocol
Bugfix: Sort out work template refcounting by properly using work_free and new workcpy
Support for rolling extranonce in templates
Initial libblkmaker integration, using a git submodule
cairnsmore: There's no set hashrate like Icarus, so always use short timing mode by default
Bugfix: Include unistd.h needed for ssize_t type
fpgautils: Don't try to scan serial at all anymore, if a device is claimed
fpgautils: serial_claim function to politely ask other drivers not to try to use device
RPC: Update to work with Cairnsmore
cairnsmore: Windows autodetect using FTDI library
cairnsmore: Beginnings of new driver, with automatic upgrade from Icarus detection
icarus: Support disabling reopen quirk via --icarus-options
proxy: Replace mess of encoding proxy into pool URI with a --pool-proxy option, and use cURL's builtin proxy URI support
save individual pool proxy settings to config
API-README update for pools proxy info
CURL support for individual proxy per pool and all proxy types
Bugfix: Update current_block_id for fixed set_curblock
miner.php by default don't display IP/Port numbers in error messages
api.c all STATUS messages automatically escaped
API add display of and setting queue,scantime,expiry
README - FPGA device FAQ
API add device diff1 work
count device diff1 shares
API-README update
api.c Correct diff1 field name
Bugfix: Sanitize block hash handling (including fixing on big endian)
Bugfix: Print the (full) correct block hash when warning about work issued against old blocks
Bugfix: When comparing current block, only pay attention to the prevblock header
Allow mixing user+pass and userpass, so long as user+pass are balanced before userpass options
ztex: Include device serial number and FPGA number in cgpu name field
ztex: Abstract common cgpu_info creation code
ztex: Do thread initialization in thread_init rather than thread_prepare
Bugfix: Tolerate working on old blocks when there is only one pool enabled
Bugfix: ztex: Detect through fpgautils so -S noauto correctly inhibits autodetection
ztex: Workaround duplicate share submissions by doubling "backlog" size
ztex: Use consistent device ids for logging
Bugfix: ztex: Increment global hw_errors too
Bugfix: free adhoc string elist element when removing it from list
Bugfix: icarus: Initialize lret variable after work restart reentry
Bugfix: ztex: Free lastnonce heap memory if backlog allocation fails
icarus: Initialize epoll event structure in a way Valgrind is happier with
Bugfix: Use strtok_r for parse_config since some options use strtok themselves
Import strtok_r from gnulib for Windows portability
Bugfix: ztex: Don't try to destroy a mutex that was never created (single FPGA Ztex devices)
ztex: Clean up redundant dereferencing in ztex_shutdown
API-README more debug parameter information
API allow full debug settings control
Sort the blocks database in reverse order, allowing us to remove the first block without iterating over them. Output the block number to debug.
Adjust opencl intensity when adjusting thread count to prevent it getting pegged at a value below the minimum threads possible.
miner.h max_hashes -> int64_t
Keep the local block number in the blocks structs stored and sort them by number to guarantee we delete the oldest when ageing the block struct entries.
Use correct sdk version detection for SDK 2.7
Bugfix: Align Ztex statline properly by removing redundant frequency
make-release: Convert text files to DOS format for Windows ZIP

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: elvizzzzzzz on September 15, 2012, 06:36:15 AM

Thanks for the reply. That's what I guessed, it was the Debian-Ubuntu thing that caused my confusion.
FWIW the current version of eglibc on Debian|unstable is glibc_13

BFGMiner should work with any libc, so I'm guessing the problem you hit is just an ABI thing.

elvizzzzzzz

full member

Activity: 135

Merit: 100

Quote from: Luke-Jr on September 15, 2012, 06:00:33 AM

Quote from: elvizzzzzzz on September 15, 2012, 05:58:48 AM

RE : Debian versions of bfgminer

I tried running bfgminer_2.6.4 on the current sid (unstable) debian distribution.
It failed with the message that GLIBC_15 not found.

I searched, but no definitive answers so far, hence before I do something stupid,
I thought I should ask.

I need something similar to bfgminer for its fan speed control BTW.

Those are Ubuntu, not Debian... probably can build Debian packages from the same packaging though! If you don't know how to do that, I'd recommend just building from the source code and running out of the build directory.

Thanks for the reply. That's what I guessed, it was the Debian-Ubuntu thing that caused my confusion.
FWIW the current version of eglibc on Debian|unstable is glibc_13

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: elvizzzzzzz on September 15, 2012, 05:58:48 AM

RE : Debian versions of bfgminer

I tried running bfgminer_2.6.4 on the current sid (unstable) debian distribution.
It failed with the message that GLIBC_15 not found.

I searched, but no definitive answers so far, hence before I do something stupid,
I thought I should ask.

I need something similar to bfgminer for its fan speed control BTW.

Those are Ubuntu, not Debian... probably can build Debian packages from the same packaging though! If you don't know how to do that, I'd recommend just building from the source code and running out of the build directory.

elvizzzzzzz

full member

Activity: 135

Merit: 100

Hi all,

RE : Debian versions of bfgminer

I tried running bfgminer_2.6.4 on the current sid (unstable) debian distribution.
It failed with the message that GLIBC_15 not found.

I searched, but no definitive answers so far, hence before I do something stupid,
I thought I should ask.

I need something similar to bfgminer for its fan speed control BTW.

purelithium

hero member

Activity: 504

Merit: 500

Ok, Done. Thanks! Couldn't figure out how to label it enhancement though.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: purelithium on September 08, 2012, 09:16:58 AM

Is there a way to change pool priority or failover order without changing the order of the pools in bfgminer.conf? And is there a way to make this persist through a restart? I know by using the Switch Pool command, I can change the priority of one pool to 0, but that reverts after a startup, even if I write the conf again.

The RPC API has a poolpriority command I added to set the priority of all pools at once. If you want to open an enhancement Issue for a --pool-priority option, I can probablyl get that added for the next minor release (I might forget if there's no issue to track it).

purelithium

hero member

Activity: 504

Merit: 500

Luke-Jr:

Is there a way to change pool priority or failover order without changing the order of the pools in bfgminer.conf? And is there a way to make this persist through a restart? I know by using the Switch Pool command, I can change the priority of one pool to 0, but that reverts after a startup, even if I write the conf again.

Love the software, can't wait until I get my MMQ to use it.

bitpop

legendary

Activity: 2912

Merit: 1060

Nice!

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Just a quick update to let everyone know the plans for BFGMiner 3.0:

ASICs! Or at least whichever of them are ready in time for the release. Planned:
FPGA Mining X6500
Next-generation getblocktemplate decentralized mining protocol, to satisfy the hashrate demands of ASICs
Improved Ztex support, now that I have a pair (x and y)

Support for getblocktemplate will be powered by my new "libblkmaker" library, currently in development, written in C for maximum portability, and licensed under the MIT license so other mining software authors can take advantage of it. Anyone who wishes to contribute to its development is welcome to do so (as with BFGMiner development, for that matter Wink

).

I'm open to adding support for any other devices simply by providing me with one for development, testing, and ongoing maintenance - just PM me.

Roland68

member

Activity: 103

Merit: 10

Quote from: crazyates on September 02, 2012, 02:30:40 PM

Quote from: Roland68 on September 02, 2012, 02:06:32 PM

After reading this thread ans the FAQ ...I still have a question:

I have 2 GPU. How can I configure one worker or pool for each GPU? like POOL1 on GPU0 and POOL2 on GPU1

This allow me to get the pool sending me an email if one of the GPU get stuck ...

Thanks for your help

2 different instances of the program, one with --device 0 and one with --device 1 options.

Thanks ...

what would be the syntax in the CFG file ?

device=0, pool= www.miner.com:1234 u=qqsdqd ...
device=1, pool= www.miner.com:1567 u=qqsdqd ...
or what Huh

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