Pages:
Author

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

legendary
Activity: 2576
Merit: 1186
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...
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. 
legendary
Activity: 2576
Merit: 1186
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?
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.
full member
Activity: 195
Merit: 100
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.
legendary
Activity: 2576
Merit: 1186
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/*/*
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
Does bfgminer require root account to run Ztex boards?
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.
full member
Activity: 135
Merit: 100
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 :-)
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 Smiley

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
legendary
Activity: 2576
Merit: 1186
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.
full member
Activity: 135
Merit: 100
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
legendary
Activity: 2576
Merit: 1186
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.
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.
hero member
Activity: 504
Merit: 500
Ok, Done. Thanks! Couldn't figure out how to label it enhancement though.
legendary
Activity: 2576
Merit: 1186
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).
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.
legendary
Activity: 2912
Merit: 1060
legendary
Activity: 2576
Merit: 1186
Just a quick update to let everyone know the plans for BFGMiner 3.0:
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. Smiley
member
Activity: 103
Merit: 10
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

Pages:
Jump to: