|
This seems like a Windows bug. POSIX and MSDN define that LC_NUMERIC should be initialised to the C locale by default, and BFGMiner is only changing LC_CTYPE - and that only with --unicode.
|
|
|
|
You are speculating. If Bitfury's next chip design is not compatible with the chained design of the existing chips, then it's not going to work chips/cards/minit planes etc. How about wait until Bitfury actually announce a new chip design before continuing with this type of discussion? It's not entirely unreasonable. He wants to know if he will be able to upgrade his existing miner with new daughterboards. It's quite possible this could be the case if Bitfury uses the same hardware interface (pinouts), even if the chips are designed to work completely different. You are of course right that there cannot be any guarantee of this at this time unless Bitfury himself commits to a future interface. |
|
|
|
ulimit -c unlimited #to enable core dumps  |
|
|
|
|
That's a recent bug in bitcoinrpc. Please report it to that project.
|
|
|
|
|
Crashes aren't a given, but I'd need at least a backtrace to try to debug it :/
|
|
|
|
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. |
|
|
|
[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. |
|
|
|
NEW VERSION 3.3.0, OCTOBER 11 20133.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
|
|
|
|
The windows version has problems. I would recommend either install Ubuntu vm or use cgminer. I have no outstanding bug reports for this... only on Mac. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Did you ever expect BFGminer to expand to this level of complexity so quickly? Probably not until recently.. I've already got a plate full of things to add for 3.4 already  |
|
|
|
Doing my test run on the main git branch now.
Should be ready for 3.3 within a day or two, assuming no surprises.
Does this support bitfury chips under the main bfg once you are done? Yes, here are the WIP release notes: - New drivers for bitfury-based devices: BFSB/MegaBigPower kits, Big Picture Mining USB, LittleFury, and Metabank.
- 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!).
|
|
|
|
|
Doing my test run on the main git branch now.
Should be ready for 3.3 within a day or two, assuming no surprises.
|
|
|
|
|
I don't understand how Eligius supporting another part(?) of the Bitcoin community is in any way detracting from here.
This thread would continue to be clutter-ish, even without the other forum.
|
|
|
|
Out of the 3 or 4 that I'll be putting together some will be going to the various miner software developers (e.g. one will be going to Luke-Jr so that he can start integrating support into his bfgminer, etc). FWIW, I can confirm receipt of this. I plan to include NanoFury support in BFGMiner 3.4 at the latest. |
|
|
|
As promised. BFG crapped out three times before it worked with both Blades at the same time. As said, it's Win7 Exnterprise x86 on a Celeron 847 NUC. No other software on the machine, other the BFGMiner 3.2.1. Crash was at log time 15:09:49 Failed to init bfd from (C:\bfgminer321\pdcurses.dll)
0x66e43b50 : C:\bfgminer321\pdcurses.dll : wclrtoeol
Failed to init bfd from (C:\Windows\system32\msvcrt.dll)
0x762aa442 : C:\Windows\system32\msvcrt.dll : unlock
Failed to init bfd from (C:\Windows\system32\msvcrt.dll)
0x762ba490 : C:\Windows\system32\msvcrt.dll : getenv
Failed to init bfd from (C:\Windows\system32\msvcrt.dll)
0x762ba462 : C:\Windows\system32\msvcrt.dll : getenv
Failed to init bfd from (C:\bfgminer321\pdcurses.dll)
0x66e41408 : C:\bfgminer321\pdcurses.dll : waddch
During bitcointroll's outage, I have identified the cause of this crash (a bug in PDCurses), submitted a patch upstream to fix it that will hopefully be merged at some point, and implemented a workaround that will be included in the next release of BFGMiner. |
|
|
|
IMHO, They should simply connect the miners to the internet and to the pool of choice of the buyer(It's in the knc website account info) and let it hash until the hosting software is ready. Can't be too hard to do, but what do I know.
Totally speculating here, but I can see 2 not-unlikely reasons it could be "too hard": - They might be limited on power availability, and need to use it all for burnins.
- The miners might already be at the datacenter, 3 hours away.
|
|
|
|
Met Alex at the Atlanta Bitcoin Conference yesterday. The miner he had with him was impressively quiet and barely warm. Looking forward to adding BFGMiner support when my unit gets here |
|
|
|
|
Show Posts
