OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 162.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: purelithium on April 26, 2013, 09:34:43 PM

I'm curious, why have you decided not to include the FPGA bitstreams in the windows binaries anymore?

Makes the download much larger, mainly, and most miners don't need them.
Seemed reasonable to have the few who do continue using the bitstreams they already have, or download them as the separate ZIP.

purelithium

hero member

Activity: 504

Merit: 500

I'm curious, why have you decided not to include the FPGA bitstreams in the windows binaries anymore?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: psjw4450 on April 26, 2013, 05:13:21 PM

I compiled bfgminer 3.0.1 for Ubuntu and when I start it I get the command line version not the display version. Any help would be great.

See dependencies at the top of README. Especially the part about ncurses.

BitMinerN8

hero member

Activity: 626

Merit: 500

Mining since May 2011.

Quote from: Geremia on April 26, 2013, 07:07:33 PM

Quote from: psjw4450 on April 26, 2013, 05:13:21 PM

I compiled bfgminer 3.0.1 for Ubuntu and when I start it I get the command line version not the display version. Any help would be great.

There's a GUI version of BFGMiner?

No, I don't think so. It's only ever been running in a terminal window.

Geremia

sr. member

Activity: 507

Merit: 253

Quote from: psjw4450 on April 26, 2013, 05:13:21 PM

I compiled bfgminer 3.0.1 for Ubuntu and when I start it I get the command line version not the display version. Any help would be great.

There's a GUI version of BFGMiner?

BitMinerN8

hero member

Activity: 626

Merit: 500

Mining since May 2011.

Quote from: psjw4450 on April 26, 2013, 05:13:21 PM

I compiled bfgminer 3.0.1 for Ubuntu and when I start it I get the command line version not the display version. Any help would be great.

To my knowledge, there is only one version that looks like this in a terminal window, there is no GUI version.
Sample output:

Code:

bfgminer version 3.0.1 - Started: [2013-04-19 18:33:55] - [ 4 days 03:20:01]
--------------------------------------------------------------------------------
5s:29.55 avg:29.44 u:28.13 Gh/s | A:291464 R:543 S:0 HW:0 U:48.9/m BS:85.1M
ST: 2 DW: 15014 GW: 7506 LW: 2529587 GF: 0 NB: 671 AS: 0 RF: 0 E: 15.30
Connected to mining.eligius.st diff 8 with stratum as user 1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh
Block: ...01d9ae3c #232849 Diff:8.97M (64.24Th/s) Started: [21:53:18]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BFL 0: 54.0C/46.0C | 29.51/29.44/28.13Gh/s | A:291465 R:543 HW:0 U: 48.90/m
--------------------------------------------------------------------------------

[2013-04-23 21:53:30] Accepted 1900dc35 BFL 0 Diff 10/8
[2013-04-23 21:53:32] Accepted 04671aec BFL 0 Diff 58/8
[2013-04-23 21:53:32] Accepted 0bd69ace BFL 0 Diff 21/8
[2013-04-23 21:53:33] Accepted 00437944 BFL 0 Diff 971/8
[2013-04-23 21:53:33] Accepted 136c6b29 BFL 0 Diff 13/8

psjw4450

sr. member

Activity: 342

Merit: 250

I compiled bfgminer 3.0.1 for Ubuntu and when I start it I get the command line version not the display version. Any help would be great.

Epoch

legendary

Activity: 922

Merit: 1003

An update to my earlier message: Bitminter just went offline and all 3 instances of bfgminer 3.0.1 crashed (simultaneously on 3 separate PCs). Win7/64. Same behavior as with the 2.99.x branch.

Geremia

sr. member

Activity: 507

Merit: 253

Should we expect high share failure rates when compiling with "-Ofast" or "-O3"?

Geremia

sr. member

Activity: 507

Merit: 253

Quote from: Shevek on April 06, 2013, 01:11:49 PM

bfgminer -n
[2013-04-06 20:11:28] Failed to load OpenCL library, no GPUs usable
[2013-04-06 20:11:28] 0 GPU devices max detected

I get this error, too.

Here's my "bfgminer -D -d?":

Code:

[2013-04-25 09:47:31] ft232r_scan: Found 093a:2510 - not a ft232r
[2013-04-25 09:47:31] ft232r_scan: Found 1d6b:0002 - not a ft232r
[2013-04-25 09:47:31] ft232r_scan: Found 1d6b:0002 - not a ft232r
[2013-04-25 09:47:31] ft232r_scan: Found 8087:0020 - not a ft232r
[2013-04-25 09:47:31] ft232r_scan: Found 8087:0020 - not a ft232r
[2013-04-25 09:47:31] Started bfgminer 3.0.1
[2013-04-25 09:47:31] Loaded configuration file /home/geremia/.bfgminer/bfgminer.conf
[2013-04-25 09:47:31] CL Platform 0 vendor: Intel(R) Corporation
[2013-04-25 09:47:31] CL Platform 0 name: Intel(R) OpenCL
[2013-04-25 09:47:31] CL Platform 0 version: OpenCL 1.1 LINUX
[2013-04-25 09:47:31] Error -1: Getting Device IDs (num)
[2013-04-25 09:47:31] clDevicesNum returned error, no GPUs usable
[2013-04-25 09:47:31] Not a ZTEX device 093a:2510
[2013-04-25 09:47:31] Not a ZTEX device 1d6b:0002
[2013-04-25 09:47:31] Not a ZTEX device 1d6b:0002
[2013-04-25 09:47:31] Not a ZTEX device 8087:0020
[2013-04-25 09:47:31] Not a ZTEX device 8087:0020
[2013-04-25 09:47:31] Devices detected:
[2013-04-25 09:47:31] 0. CPU 0 (driver: cpu)
[2013-04-25 09:47:31] 1. CPU 1 (driver: cpu)
[2013-04-25 09:47:31] 2. CPU 2 (driver: cpu)
[2013-04-25 09:47:31] 3. CPU 3 (driver: cpu)
4 devices listed

And my "lspci -nn | grep VGA":

Code:

00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18)

Can I not mine with an Intel Integrated Graphics Controller? thanks

bigb159

full member

Activity: 163

Merit: 100

Anyone have any tips on restoring original clock, mem and voltage values on quitting? Currently bfg sets my custom gpu-engine, gpu-memclock and gpu-vddc values successfully, but they stay that way after I hit Q and exit. I was hoping as some point Trixx would start gathering dust.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: MSO on April 24, 2013, 02:38:06 PM

Luke, I reported simultaneous crashes on two machines when my network connection to Slush's pool was lost. I had not configured a pool rollover, so I'm not certain that a pool-switch was involved but it seems likely that one was attempted.

To answer your underlying question: yes, both machines were AMD 7770 GPUs running under OpenCL.

Luke, just to add to this: I have experienced simultaneous crashes on 3 machines when bitminter hiccups. I have FPGAs only, no GPUs. This was on versions prior to 3.0.1. Win7/64.

I have been running 3.0.1 on 3 instances for 17 hours now without issue ... but bitminter hasn't hiccuped yet. When it does, I'll see if my 3.0.1 instances crash.

MSO

newbie

Activity: 24

Merit: 0

Luke, I reported simultaneous crashes on two machines when my network connection to Slush's pool was lost. I had not configured a pool rollover, so I'm not certain that a pool-switch was involved but it seems likely that one was attempted.

To answer your underlying question: yes, both machines were AMD 7770 GPUs running under OpenCL.

dtown

newbie

Activity: 38

Merit: 0

Quote from: Luke-Jr on April 24, 2013, 12:54:30 AM

Could everyone who was experiencing the crash-on-pool-switch please answer: are you GPU mining?

Yes, on two different PCs.

anti

newbie

Activity: 22

Merit: 0

Quote from: Luke-Jr on April 24, 2013, 12:54:30 AM

Could everyone who was experiencing the crash-on-pool-switch please answer: are you GPU mining?

Yes. OpenCL/Tahiti. It just happened again after Slush moved his pool servers about 9-10 hours ago (pool got hacked).

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Could everyone who was experiencing the crash-on-pool-switch please answer: are you GPU mining?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

NEW VERSION 3.0.1, APRIL 24 2013

This release removes bitstreams from the Windows binary ZIPs. If you are mining with ModMiner, X6500, or ZTEX FPGAs you will need to download the source code ZIP as well and copy over the "bitstreams" directory.

Human readable changelog:

IMPORTANT: Bitstreams for ModMiner, X6500, and ZTEX FPGA boards are no longer included with the Windows builds and must be copied from the source distribution.
Bitforce SC: Switched to using bulk queue mode for all ASIC-based devices.
Bitforce SC: Fix reinitialization-on-failure, so devices can autorecover from some problems.
OpenCL: Support for mining with completely free (non-proprietary) Mesa/LLVM OpenCL on Linux (requires git Mesa/LLVM).
OpenCL: Include platform in kernel binary filenames to avoid using stale binaries from other SDK installs.
Added network hashrate (based on block difficulty) to block status line.

Full changelog

Bugfix: configure: Move actual roundl macro back to miner.h after math.h should be included
Bugfix: configure: Use dummy pointer to correctly detect roundl when conftest main is missing argc parameter
Bugfix: configure: Use variable argument to roundl to prevent compilers from optimizing it out entirely
Remove bitstreams from Windows binary distributions (README directs users to download source and copy them)
make-release: Remove autom4te.cache from distributed source
Bugfix: Omit --no-opencl-binaries option from build if OpenCL is not being compiled
Bugfix: Check that all pools have URIs set before starting
Bugfix: bitforce: Make noncebuf large enough for max qresults +1 (for OK line)
opencl: Ability to avoid using binary kernels with new --no-opencl-binaries option
README: Include jansson PKG_CONFIG_PATH in example for Mac
Include trailing \0 with coinbase sigs if there's room
Differentiate socket closed from socket error in recv_line.
Add new best share info to verbose logging.
Add notice for when network diff is changed.
convert sleep(const) to nmsleep()
Rename longpoll threads according to what pool they're associated with
miner.php report 'Last Valid Work' as time before request
API V1.25 - add 'Last Valid Work' time for each device
add 'count' to customsummarypage 'calc'
Bugfix: ztex: Initialize fw_buf pointer to NULL so a free before allocation is safe
Cleanup when stratum curl fails to initialise.
LTC text typo
Recreate cURL for new stratum connections, and clear stratum_notify on suspending them
clear_stratum_shares: Rename diff_stale variable to diff_cleared
MMQ it's a bitstream
Update a pool's last work time when the work is popped as well as staged.
Extend stratum connections another minute (total 2 minutes) after the last work item was staged, and maintain last_work_time for non-stratum pools.
Fix --benchmark generating valid work for cgminer.
Bugfix: Correct pdbuilder result directory
Omit add_serial_all code when serial support is not wanted
Use configure to detect presence of roundl to avoid redefining an actual function (possibly inline)
Bugfix: roundl: Add needed parenthesis to perform ?: before +
Bugfix: ft232r: Defer allocating structure until after USB endpoint is successfully opened, so it won't leak in case of failure
Bugfix: ztex: Free bitstream in memory when done with it
Bugfix: Safely handle all-space cURL debug messages, should they ever happen
Silence warnings about poor format usage for quit()
Apply noreturn and printf-format attributes to quit() function definition
Bugfix: set_serial_rts get flags to manipulate them correctly
Bugfix: Missing return for /dev globbing
Bugfix: Free unused work when retrying failed lp request
Display processor name with thread disabled/re-enabled messages
Move best share to top summary line, and add network difficulty to block line
opencl: Default to phatk kernel for Mesa platform
opencl: Default to single thread with Mesa OpenCL
opencl: Check for Mesa OpenCL and avoid using binary kernels with it
bitforce: Never increase bulkqueue poll wait time during queue underruns
bitforce: Start off polling bulk queue every 100ms
bitforce: Log device queue size after getting bulk results
bitforce: Ensure bulkqueue polling occurs at least once a second
opencl: Include OpenCL platform in kernel binary filenames
bitforce: Use bulk queue mode for all SC devices
Bugfix: bitforce: When reinitializing, free all known works to avoid decrementing reset queued counter
bitforce: Handle timeout during ZOX as cleanly as possible
Bugfix: bitforce: Make reinitialization more complete and safe
Bugfix: bitforce: Close opened fd if reinit fails
Bugfix: bitforce: Retry ZGX until device is NOT busy
bitforce: Log when zero queued results are received

dtown

newbie

Activity: 38

Merit: 0

Hello -

I've been using bfgminer for the last few months without issue. Thanks so much for your hard work.

I thnk I've found a bug that is causing bfgminer to crash on two different PCs that was discovered because of the Slush DDOS issues. When the primary pool (in this case Slush's pool) goes down bfgminer notices and fails over to my secondary pool (bitminter). During the failover switches bfgminer sometimes crashes.

This only seems to happen when a failover occurs after successfully mining on the primary pool first; in other words if I restart the program and the primary pool is already down, it moves on to the secondary pool without issue.

Please let me know if there's any other details I can provide. This is happening to me on two different mining PCs with the Win64 version.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: MineForeman.com on April 23, 2013, 02:50:12 AM

Quote from: Luke-Jr on April 23, 2013, 02:38:58 AM

Why build without OpenCL support anyway? Tongue

I have absolutely no fecking idea! Roll Eyes

When it came up it made me smile, the Raspberry PI is not known for its outstanding GPU performance. In my defence though, I did use the '--disable-opencl' flag for configure.

Yes, that's what found this bug (I don't usually build without OpenCL support)

MineForeman.com

legendary

Activity: 896

Merit: 1000

Quote from: Luke-Jr on April 23, 2013, 02:38:58 AM

Why build without OpenCL support anyway? Tongue

I have absolutely no fecking idea! Roll Eyes

When it came up it made me smile, the Raspberry PI is not known for its outstanding GPU performance. In my defence though, I did use the '--disable-opencl' flag for configure.

Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 162. (Read 1193223 times)