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

[Nemo1024]

All my BEs (and I have 141 at the moment over 2 machines) hash at max speed (335MHz), but the COM port problem was driving me nuts. It went away once I uninstalled UPS monitoring software on both machines, but I'd rather have monitoring on.

In your case, it might be some other software that randomly locks a COM port to do a short burst of communication over it and then releases the COM port.

Luke-Jr, pretty please, add the auto-rescan function.

[HellDiverUK]

Could you guys be having issues with a legacy serial port on your machine?  While most machines now don't have a serial port on the backplane, they often have a header on the board for one, so it's turned on in the BIOS.

Might be worth checking, and turning it off in the BIOS if you don't use it. 

[Nemo1024]

I had that thought, so I disabled both COM  (COM1) and LPT in BIOS. That didn't help. It was a software issue.

[juhakall]

Is it possible to accidentally use the wrong driver for BitFury units? I'm specifically thinking of using the Metabank driver on a BFSB unit or vice versa. I heard it somewhere on IRC that using the wrong driver could brick a unit, and I'd like to get some actual information on this.

I'm currently running the main branch version with BFSB support, and it's working quite well. I threw in lots of --disables to configure, to get a binary that doesn't have any other BitFury drivers besides BFSB. Hopefully that was unnecessary.

[Mudbankkeith]

Could you guys be having issues with a legacy serial port on your machine?  While most machines now don't have a serial port on the backplane, they often have a header on the board for one, so it's turned on in the BIOS.

Might be worth checking, and turning it off in the BIOS if you don't use it. 

Next time I need a re-boot I will check this out. I do recall a reference to (com1) when first installed the drivers.

[Luke-Jr]

Is it possible to accidentally use the wrong driver for BitFury units? I'm specifically thinking of using the Metabank driver on a BFSB unit or vice versa. I heard it somewhere on IRC that using the wrong driver could brick a unit, and I'd like to get some actual information on this.

I don't know what would happen if you tried to use the wrong driver - I can certainly see it potentially bricking something.

I'm currently running the main branch version with BFSB support, and it's working quite well. I threw in lots of --disables to configure, to get a binary that doesn't have any other BitFury drivers besides BFSB. Hopefully that was unnecessary.

BFSB and Metabank drivers (the only ones with this risk) are disabled by default.

[Taugeran]

Is it possible to accidentally use the wrong driver for BitFury units? I'm specifically thinking of using the Metabank driver on a BFSB unit or vice versa. I heard it somewhere on IRC that using the wrong driver could brick a unit, and I'd like to get some actual information on this.

I don't know what would happen if you tried to use the wrong driver - I can certainly see it potentially bricking something.

I'm currently running the main branch version with BFSB support, and it's working quite well. I threw in lots of --disables to configure, to get a binary that doesn't have any other BitFury drivers besides BFSB. Hopefully that was unnecessary.

BFSB and Metabank drivers (the only ones with this risk) are disabled by default.

does the current git of bfgminer have enabled support for the BPMC BF1 on win32. if not could i get a build of it. i have shit luck setting up cygwin/mingw/msys

if yes what device driver is needed? sorry forstupid questions, im just having one of those days

[Luke-Jr]

Is it possible to accidentally use the wrong driver for BitFury units? I'm specifically thinking of using the Metabank driver on a BFSB unit or vice versa. I heard it somewhere on IRC that using the wrong driver could brick a unit, and I'd like to get some actual information on this.

I don't know what would happen if you tried to use the wrong driver - I can certainly see it potentially bricking something.

I'm currently running the main branch version with BFSB support, and it's working quite well. I threw in lots of --disables to configure, to get a binary that doesn't have any other BitFury drivers besides BFSB. Hopefully that was unnecessary.

BFSB and Metabank drivers (the only ones with this risk) are disabled by default.

does the current git of bfgminer have enabled support for the BPMC BF1 on win32. if not could i get a build of it. i have shit luck setting up cygwin/mingw/msys

if yes what device driver is needed? sorry forstupid questions, im just having one of those days

bigpic driver handles BF1s.

[Taugeran]

ty luke

[Taugeran]

another note, when i brew install bfgminer --HEAD using nwools formula my compiled version shows 3.2.90 and instead of submits/minute, it has I ###?btc/HR

[juhakall]

I noticed a per_proc setting in miner.php, perhaps it was included in a recent commit? Anyway, it mostly works and is a useful feature, but with a BFSB board it's not working correctly. The board is detected as up to 4 devices, mine currently has 3 doing 30-35 GH/s each. With per_proc=false, BSB0 shows a 100GH/s hashrate, BSB1 64GH/s and BSB2 32 GH/s. Looks like BSB0 is incorrectly also including all the chips from other BSB devices, and BSB1 similarly also includes chips from BSB2. Without per_proc=false, there's no error in the stats, all BSB devices are correctly shown as having 16 chips. BFGMiner TUI is also displaying the correct hashrate for each device.

[Luke-Jr]

NEW VERSION 3.3.0, OCTOBER 11 2013

3.0.9 is promoted to stable, and 2.10.x discontinued.

Human readable changelog:

• New drivers for bitfury-based devices: BFSB/MegaBigPower(v2 only!) kits, Big Picture Mining USB (BF1, RedFury, BlueFury, etc), LittleFury, and Metabank. See README.ASIC for setup instructions.
• Support for proxy virtual devices has been extended to include the stratum protocol when the upstream pool selected is also stratum and supplies sufficient extranonce2 space. If the upstream pool does not meet this criteria, stratum clients will be disconnected and new ones will fail to subscribe. You can take advantage of this to failover to the getwork proxy. Support for upstream getwork pools is impossble, but GBT is planned.
• opencl: Driver is disabled by default if FPGAs or ASICs are detected. To enable, use -S opencl:auto
• Third hashrate displayed is now based on nonces found, adjusted for pool rejected/stale shares. It should still be approximately equivalent to your effective/earning hashrate, but with better accuracy.
• Utility on the TUI status line has been replaced with expected Income, measured as 100% PPS BTC per hour for easy comparison with electric costs.
• RPC: Methods shared with cgminer now only consider entire devices, to be more compatible. A set of new processor-detail methods have been added to get full information per-processor.
• RPC: Old devdetail method has been made compatible with cgminer devdetails and renamed.
• New options --chroot-dir and --setuid on POSIX systems (thanks Ricardo!).

Full changelog:

• openwrt: Optional libevent support
• RPC: Add missing drivers to Device Code
• bigpic_process_results: Cleanup
• RPC: Use procs count for device summaries, rather than iterating over linked list (which may span multiple devices)
• Bugfix: Use bfg_waddstr for cg_[mv]wprintw so special characters get interpreted properly
• Bugfix: bitfury: Clear force_reinit flag after reinit
• Bugfix: Use base unit for zero, and only if all values are zero
• RPC: Always build pga* and proc* methods
• Bugfix: icarus: Check for valid fd before all usage
• Bugfix: Stratum initiate: Clear json var after freeing it, to avoid a potential double-free if retry fails before new JSON is parsed
• Bugfix: Correct --log-file error message
• Cleanly fall back to other micro- prefix symbols if locale doesn't support the preferred one(s)
• Bugfix: bfg_waddstr: Missing break after selecting degrees symbol
• Silence warning about (never really) uninitalised variable use in notifystatus
• RPC: Complete split between devs/pga* and proc* methods
• RPC: Internal restructuring to support device-wide view
• RPC: Remove devdetail method, and rework newer devdetails to use its code
• configure: Advise running ldconfig when detected and probably necessary
• configure: Simplify final information summary
• Bugfix: configure: Disable httpsrv/libevent if not available
• README: Mention free GPU mining dependencies
• Write config: Avoid writing default temperature settings
• bitforce: Set default cutoff temperature to 85C for SC-class devices
• When shutting down, don't wait for mining threads any longer after the 1 second sleep
• bitfury: Silence warning about (never possible) uninitialised variable use
• bigpic: Handle write failures
• json_rpc_call_completed: Silence incorrect type cast warning
• icarus: Silence warning about (never really) uninitalised variable use in icarus_scanhash
• fpgautils: Check for fgets error
• Silence warning about (never really) uninitalised variable use in multi_format_unit
• ft232r: Silence warning about (never really) uninitalised variable use
• Silence unused result warnings for notifier_{read,wake}
• Log a warning if --cmd-* returns a non-zero exit code
• configure: Update bigpic driver dependency on bitfury code
• metabank: Initialise --temp-cutoff to 50C
• README.ASIC: Document special care needed for some bitfury-based miners
• Bugfix: bitfury: Correct results from RPC pgaset
• bitfury: Move Slot and fasync RPC info to details instead of status
• bitfury: Include chip fasync in RPC status
• bfsb: Split up processors among a separate device per board
• Bugfix: bitfury: Copy rxbufs to stack in case we need to do SPI communication in the meantime
• bfsb: Merge bfsb_detect_chips into bfsb_autodetect (unchanged)
• bfsb/metabank: Allow pgaset to change osc6_bits and SPI baud rate
• bitfury: Fix code indentation
• bitfury: bitfury_init_oldbuf: Optimise during runtime
• metabank: Remove unused variables
• bitfury: Send a work with lots of nonces to help cold-started bitfurys fill a static buffer
• Bugfix: configure: Show --enable-bfsb/metabank in help, since they are disabled by default
• metabank: Reduce i2c banking to only when necessary
• bfsb: Only build spi_bfsb_select_bank if bfsb driver is being compiled
• bitfury: Reorganize polling to hit chips sequentially, so SPI traffic can be minimised
• bitfury: spi_emit_data: Return address read data will be located at after txrx
• bitfury: After 8 bad nonces in a sample period, reinit immediately rather than waiting for the remaining up-to-0x38
• bitfury: Reinitialise chips if their active nonce stops changing
• bitfury: Recalibrate immediately when we know we need it
• bitfury: Reset chips if more than 8 hw errors are found in a 0x40 result sample period
• bitfury: If previous nonce mismatch persists, try recalibrating oldbuf
• bfsb: Shutdown chip when disabling
• bfsb: Expose Clock Bits and Slot to RPC
• configure: Simplify dynclock necessity detection
• configure: Tie libudev usage to fpgautils
• configure: Simplify fpgautils necessity detection
• DevAPI: add_cgpu_slave for more elegant multi-device threads
• Use procs count for device summaries, rather than iterating over linked list (which may span multiple devices)
• metabank: Split up processors among a separate device per board
• metabank: Merge metabank_detect_chips into metabank_autodetect (unchanged)
• Removed temperature output from metabank_api_extra_device_status().
• Modified code to store temperature at cgpu->temp for metabank devices.
• bitfury: Added get_api_extra_device_status for 'devs' request in metabank driver: Slot, Clock Bits, Temperature, Voltage.
• minerloop_async: Run watchdog code within actual device thread
• bitfury: Remove unused libbitfury_readHashData
• Bugfix: DevAPI: Don't call job_process_results when there was no previous job
• bigpic: Convert to async minerloop
• bitfury: Port to Windows
• bigpic: Use bitfury_fudge_nonce
• Use common bitfury_decnonce for all bitfury-based devices
• Rename bf1 driver to bigpic, as the same device has other brands too
• bf1: Clean up log messages
• bf1: Reduce loglevel of debug messages
• Bugfix: bf1: Add missing header to Makefile.am, and fix .dname/.name
• Bugfix: bf1: Fix warnings
• BF1 driver modified to work under Windows -> packing of structs isn't working with Windows
• Corrected hash rate estimation for BF1. Only 756 out of 1024 nonces are scanned.
• Cleaning up the bf1 driver code
• BF1 driver working
• Bitfury BF1 source files added
• bfsb: modified to use LukeJr:'s new code
• configure: Reorder output
• configure: Allow to build *fury drivers only
• bitfury: Turn commented debug stuff into #ifdef BITFURY_SENDHASHDATA_DEBUG
• bitfury: Implement queue_full to ensure all processors have a work ready before scanwork
• bfsb: set api speed to 625khz
• initial support for bitfurystrikesback boards
• bitfury: LINE_LEN instead of 2048
• bitfury: 4Mhz SPI by default
• bitfury: double SPI polling
• bitfury: +Strange Counter -printf Counter
• bitfury: tuning of parameters; fixed cycles calculation
• bitfury: Move clock increase from common code to metabank driver init
• bitfury: Add driver-bitfury.h for shared function declarations
• bitfury: Do debug logging of read data before rotation
• bitfury: Decode nonce array sooner to make debugging easier
• bitfury: Check that the previous nonce still matches, to detect response corruption
• bitfury: Workaround corruption by looking for matches rather than changes
• bitfury: Rewrite using async minerloop (currently only setup on metabank driver)
• bitfury: Fix memory issues
• littlefury: Turn off chips when exiting
• littlefury: Adapt to 16-bit payload size (protocol change)
• Bugfix: littlefury: Fix bitfury_do_packet
• bitfury: Report bad nonces properly
• bitfury: Unify common nonce fudging code
• Bugfix: bitfury: Chips only scan 0xbd000000 nonces per work
• bitfury: Fix logging to use applog
• bitfury: Split driver into bitfury_gpio (bare GPIO) and metabank (i2c banked GPIO)
• littlefury: Use bitfury driver scanwork
• bitfury: Eliminate more static variables
• bitfury: Treat each chip as its own processor
• bitfury: Resolve devices[chip] only once per chip
• bitfury: Move second_run logic back to libbitfury
• bitfury: Loop over chips once during scanwork
• bitfury: Abstract hashes_done2 which keeps track of time deltas per thr on its own
• littlefury: Need to set tv_morework
• bitfury: Abstract out payload_to_atrvec
• littlefury: Log read return value when unexpected
• bitfury: Eliminate non-const global variables
• littlefury: Safeguard on job switching
• Bugfix: littlefury: Keep reading until error, EOF, or buffer filled
• littlefury: Log devproto of incomplete reads
• Enable littlefury detection
• Bugfix: configure: Enable bitfury by default properly
• bitfury: Require explicit -S bitfury:auto to probe GPIO-based SPI
• bitfury: Move i2c slot handling to metabank-specific driver code
• littlefury: Initial driver for BitCentury's USB miner
• bitfury: Split actual chip detection into simple function
• Bugfix: bitfury: Fix driver "name" to be correct length
• bitfury: Abstract SPI interface
• Bugfix: bitfury: Fix more warnings
• Bugfix: bitfury: Fix warnings
• bitfury: Intercept and use applog for perror calls
• Bugfix: bitfury: Handle SPI init failure cleanly
• bitfury: major intermediate update
• bitfury: added chip series detection; multiple chip mining
• Bitfury ASIC initial support
• DynClk: Improve commented documentation
• Replace Utility with (expected) Income calculated by actual shares submitted in 100% PPS value
• format_unit3: BTC formatting with 2 decimal place digits
• format_unit3: Support for nano- and pico- sizes
• format_unit3: Use an enum for float-precision parameter
• format_unit2: Support milli- and micro- unit prefixes
• opencl: Disable by default if other devices are found; to enable, use -S opencl:auto
• write_config: Save request-diff option
• Stratum: Clear unused extranonce2 space
• Don't even show 'Attempting to restart' for devices that don't support it
• Workaround bug in PDCurses wresize
• Bugfix: Include config.h in sha2.c first
• make-release: Include libevent-2-0-5.dll in Windows packages
• README: Document dependency on libevent
• README: Document new --chroot-dir and --setuid options
• Bugfix: Use correct configure define for chroot
• Remove --disable-chroot build option: always compile --chroot-dir if supported
• Bugfix: Use correct configure define for pwd.h
• Improvements on code
• Update miner.c
• Added basic chroot support, added option to configure.ac.
• Updated miner.c
• Added basic chroot support
• Replace u-hashrate with nonce-based hashrate adjusted for rejects/stales
• SSM: Windows port
• SSM: Allow configuring stratum port via --stratum-port option and RPC setconfig
• SSM: Implement mining.hashes_done extension
• Proxy: Catch invalid usernames and error
• SSM: Report hashes done based on share submissions
• SSM: Include current time in job ids to avoid false hardware errors due to job id reuse
• SSM: If no notify is currently set, try to set it before refusing a subscribe
• SSM: Prune old jobs after expiry
• SSM: Use pool data read lock when subdividing notify
• SSM: Gracefully fail when upstream stratum notify cannot be subdivided
• SSM: Gracefully fail when upstream pool is not stratum (by closing subscribed clients, and refusing to subscribe new ones)
• SSM: Properly fail cleanly when maximum clients are connected
• SSM: Clean up stratumsrv_job when pruning it
• SSM: Avoid responding to notifications, and give an error for unknown methods
• SSM: Propagate work updates to clients
• Mostly functional stratum proxy driver
• Stratum: Split actual work generation away from the current pool data
• Bugfix: Stratum: Dereference pool swork coinbase buffer inside data lock
• SGW: Split proxy code out from driver-getwork into driver-proxy
• Bugfix: miner.php: Check $dototal[$name] is set before comparing its value
• Bugfix: RPC: Use bad_nonces in Hardware% instead of generic hw_errors
• Bugfix: RPC: Handle LIFE_DEAD2 case
• Make failure to open sharelog or noncelog abort startup
• Nonce logging option --noncelog to simply store every nonce and its info
• Abstract --sharelog option parsing

[juhakall]

Another thing I've noticed with BFSB hardware and bfgminer is that the load average is always very high. Around 1.6 or so. This doesn't seem to be a problem, I'm just curious what could cause it, when CPU usage is less than 10%. I know that at least high I/O loads can cause high load averages even if the CPU is mostly idling. The load average is only 0.2-0.3 with chainminer, though, so this leads me to believe that bfgminer is doing something different. I'm also running the exact same binary on my other raspberry with 2 BFL Jalapenos, and its load average is always close to zero.

[MineForeman.com]

Hi Luke, I am having a bit of a problem adding and setting pool priories via the api.  What I sam trying to do is;-

1. Add a new pool ( api command 'addpool' parameter 'stratum+tcp://stratum.btcguild.com:3333,User,Pass' )
2. Find the new pool id via the API (api command pools )
3. Switch to the new pool (api command switchpool)

I then get the following output from the running miner;-

Code:

 [2013-10-12 01:30:09] Switching to pool 1 stratum+tcp://stratum.btcguild.com:3333
 [2013-10-12 01:30:12] Stratum from pool 1 requested work update
 [2013-10-12 01:30:12] Pool 1 is hiding block contents from us
 [2013-10-12 01:30:12] Reconnect requested from pool 1 to stratum-lb-12j9j.btcguild.com:3333
 [2013-10-12 01:30:13] Pool 1 is issuing work for an old block: 000000000000000f32406b5c5eab162c30268d45Pool 1 is issuing work for an old block: 000000000000
000f32406b5c5eab162c30268d
 [2013-10-12 01:30:13] Stratum from pool 1 requested work update
 [2013-10-12 01:30:40] Stratum from pool 1 requested work update
 [2013-10-12 01:31:10] Stratum from pool 1 requested work update
 [2013-10-12 01:31:40] Stratum from pool 1 requested work update
 [2013-10-12 01:32:10] Stratum from pool 1 requested work update
 [2013-10-12 01:32:40] Stratum from pool 1 requested work update

... bla bla bla ...

Strange thing is, when I disable and remove the new pool via the api it successfully starts to work again with the old pool;-

Code:

 [2013-10-12 01:45:09] Switching to pool 0 http://stratum.bitcoin.cz:3333
 [2013-10-12 01:45:10] Stratum from pool 0 requested work update
 [2013-10-12 01:45:14] Stratum from pool 0 requested work update
 [2013-10-12 01:45:14] Stratum from pool 0 requested work update
 [2013-10-12 01:45:22] Stratum from pool 0 detected new block
 [2013-10-12 01:45:23] Staged work underrun; increasing queue minimum to 7
 [2013-10-12 01:45:23] Stratum from pool 0 requested work update
 [2013-10-12 01:45:26] Accepted 0d3a0a9f ICA 3  Diff 19/4
 [2013-10-12 01:45:26] Accepted 1844399b ICA 0  Diff 10/4
 [2013-10-12 01:45:28] Accepted 0fcb2216 ICA12  Diff 16/4
 [2013-10-12 01:45:35] Accepted 124bbf09 ICA12  Diff 13/4
 [2013-10-12 01:45:35] Accepted 035fa12a ICA 1  Diff 75/4
 [2013-10-12 01:45:38] Accepted 3bbf3051 ICA 7  Diff 4/4
 [2013-10-12 01:45:40] Accepted 1f310966 ICA 7  Diff 8/4

Any ideas?  The code works perfectly in cgminer and I am desperately trying to keep both miners working in my project (minepeon) to give people the choice as to what miner they want to run.  MinePeon uses the api allot to interact with the miner.

Thanks

Neil

[Luke-Jr]

Code:

 [2013-10-12 01:30:09] Switching to pool 1 stratum+tcp://stratum.btcguild.com:3333
 [2013-10-12 01:30:12] Stratum from pool 1 requested work update
 [2013-10-12 01:30:12] Pool 1 is hiding block contents from us
 [2013-10-12 01:30:12] Reconnect requested from pool 1 to stratum-lb-12j9j.btcguild.com:3333
 [2013-10-12 01:30:13] Pool 1 is issuing work for an old block: 000000000000000f32406b5c5eab162c30268d45Pool 1 is issuing work for an old block: 000000000000000f32406b5c5eab162c30268d

Pretty sure this is a known problem with BTCGuild right now.
Eleuthria said he was fixing it about an hour ago or so.

[MineForeman.com]

Right you are, I tried it with ozion and it worked as expected (I should have tried that furst but I had just done my cgminer test cases and it worked a few hours before), I was just a little thrown by the error, I had never seen that one before.

Nil

P.S. The MinePeon crowd are very excited to get fury support in bfgminer, I just wish I had one to test with (one is on its way, but not here yet).

[Luke-Jr]

P.S. The MinePeon crowd are very excited to get fury support in bfgminer, I just wish I had one to test with (one is on its way, but not here yet).

Note that there have been some reports that using -S metabank:auto or -S bfsb:auto on the wrong device may brick the unit.
So be careful to only use those when it's actually known to be the real device.

[TR4L]

Hey guys,  I'm currently running Linux Mint and have been struggling with CGMiner (note that it's CG and not BFG).  Reason I'm posting here:  Which one is better for mining.  Currently I'm using BFGminer to run my BFL Asic miner (running on a separate computer) and it's so similar to CGMiner that I kinda wanna try it.  I have 5 7970s and am using them to mine LTC.  Does anyone have a real answer (I don't care about your preference... not to sound rude or anything, I want to know which one is better)?

[Mudbankkeith]

Hi Luke-Jr

I'm currently waiting,( impatiently) for my BlueFury sticks to arrive.
I have just installed 3.3.0 on my pc and all seems to be ok. My erupters appear to settle down to their stable mining state faster than before.
GPU's are now retired to the box under the stairs, waiting for the day when BTc go into 4 figures and electricity is free.

When I receive my "Blues", is there anything extra I need to do before plugging them in?

I've looked through the "read notes" but to be fair, If I could understand all of this before next christmas, I could also learn to write my own Miner
The concern is the recent comments about "incorrect drivers" and "bricking"....................

[Taugeran]

Hi Luke-Jr

I'm currently waiting,( impatiently) for my BlueFury sticks to arrive.
I have just installed 3.3.0 on my pc and all seems to be ok. My erupters appear to settle down to their stable mining state faster than before.
GPU's are now retired to the box under the stairs, waiting for the day when BTc go into 4 figures and electricity is free.

When I receive my "Blues", is there anything extra I need to do before plugging them in?

I've looked through the "read notes" but to be fair, If I could understand all of this before next christmas, I could also learn to write my own Miner
The concern is the recent comments about "incorrect drivers" and "bricking"....................

that only applies to the Bitfurystrikesback/megabigpower and Metabank ßfury devices in the 25-400 Ghash range.

but as always regardless of device. take your time and double check everything.

-Taugeran