Bitcoin Forum
May 05, 2024, 03:36:19 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 [111] 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 ... 247 »
2201  Other / Meta / Re: BFL advertising with the old specs — Bait & Switch on: April 07, 2013, 04:39:46 PM
The ads are updated now.

You didn't comment on my thread about the same issue, but would you consider pulling your BFL ads, at least for until we know if the company is legit or not, or are you just happy that you're getting paid regardless of if the customers are getting screwed for thousands of dollars? Even if the specs are correct, the delivery estimates almost certainly are not.

[edit] Don't mean to sound like it's an accusation, more of a suggestion.
You say that as if there's any reasonable doubt that BFL is legit, which there never has been.
There never has been? Hmm? Were you around when they announced FPGAs?
Yep, it's still working great over a year later Smiley
2202  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 07, 2013, 02:07:57 AM
While you were at BFL, how many employees did you see?   Were there 22?   Or was it closer to 5?   Please let us know so we can figure out if they can even possible ship anyone beyond the first day of orders.
There were at least 14 I can think of off-hand.
2203  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 07, 2013, 02:06:13 AM
I get an error when tried to build bfgminer 2.10.6 or 3.0.0 with MingGW on Windows. I have all dependencies and successfully build BFG 2.10.5 from source.
Any suggestions how to fix this problem?

Code:
 error: @CPPFLAG_JANSSON_STATICLIB@: No such file or directory
error: @CPPFLAG_JANSSON_STATICLIB@: No such file or directory
make[2]: *** [libblkmaker_jansson_0.1_la-blkmaker_jansson.lo] Error 1
make[2]: Leaving directory `/home/Admin/bfgminer-3.0.0/libblkmaker
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Admin/bfgminer-3.0.0'
make: *** [all] Error 2
This suggests a broken jansson install - please find your jansson.pc file and PM me a copy (it should be small and plaintext) so I can add a workaround.
2204  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 06, 2013, 11:05:43 PM
How can I get crash logs to you from windows?
Unfortunately, I don't know any way to get useful information from Windows. Sad
2205  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 09:38:25 PM
Last 3 trolls seem to be missing the fact that the bet deadline was at the end of April 1, not the start of it.
2206  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 06, 2013, 08:29:21 PM
Should there be a git tag for the 3.0.0 release?  I don't see one.
Forgot to push the tags to GitHub, sorry. Should be there now.
2207  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 06, 2013, 08:28:49 PM
It's a fork of cgminer, isn't it?
It began as a fork of cgminer (a CPU/GPU miner), but not to be confused with the current cgminer, which has become a fork of BFGMiner for trolling reasons.
2208  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 06, 2013, 06:30:47 PM
Just installed from ppa (ubuntu 12.04):

 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
Do older versions work? Can you run:
Code:
bfgminer -D -d?
2209  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 05:45:13 PM
All I did was accept a device I paid for a long time ago.
Trying to make me the bad guy here just discredits you even more, and exposes how your bias is the only basis for your argument.
Do you deny that you made your post with conscious intent of fulfilling BFL's side of the betsofbitoin.com wager?
Yes, I can honestly deny that.
While I was vaguely aware there were bets going on, I don't and still have no reason to care about their terms or outcome.
If I were doing it to influence a bet, I would have posted it immediately, instead of as an afterthought 20 minutes after I posted them to my BFL-hosted blog.
2210  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 05:09:56 PM
All I did was accept a device I paid for a long time ago.
Trying to make me the bad guy here just discredits you even more, and exposes how your bias is the only basis for your argument.
Did you or did you not show proof of ownership after the deadline of the bet has passed? I'm in reference to the the two images you posted provided by Josh.
Whether I did or not, is not my problem. I have every right to post pictures of my device Josh took for me.

To actually answer your question, requires a great deal of defining: what is considered "proof of ownership" and what is the deadline? In the context of the bet (which I had/have nothing to do with), it seems "proof of ownership" was defined as "credible pictures" - so I would say that part is true; it also defines the deadline as the end of the day of April 1st, which my post was certainly before.
But again, this has nothing to do with me. I don't see how accepting my paid-for hardware, or posting pictures of it taken by BFL, makes me in any way a party to the bet or somehow a "scammer". That is complete nonsense.
2211  Other / Meta / Re: BFL advertising with the old specs — Bait & Switch on: April 06, 2013, 04:42:43 PM
The ads are updated now.

You didn't comment on my thread about the same issue, but would you consider pulling your BFL ads, at least for until we know if the company is legit or not, or are you just happy that you're getting paid regardless of if the customers are getting screwed for thousands of dollars? Even if the specs are correct, the delivery estimates almost certainly are not.

[edit] Don't mean to sound like it's an accusation, more of a suggestion.
You say that as if there's any reasonable doubt that BFL is legit, which there never has been.
2212  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 06, 2013, 04:31:40 PM
Core dumps and/or backtraces would be very helpful to debugging any crashes. Did the 2.99.x versions work stable for those experiencing this?

I've not experienced any crashing myself, but it does seem there are conditions where the SC devices have begun to stop hashing (which IMO is much more annoying than a crash), so I definitely need to put a focus on just fixing stuff for 3.0.1.

BTW, does anyone have a comprehensive list of pools that operate a getblocktemplate server besides the above two?
The getblocktemplate wiki page has a long list of pools, though perhaps it should be merged into the pool comparison page.
2213  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 04:16:23 PM
All I did was accept a device I paid for a long time ago.
Trying to make me the bad guy here just discredits you even more, and exposes how your bias is the only basis for your argument.
2214  Bitcoin / Pools / Re: [ANN] BTC Guild Registration Limits/51% Mitigation Plan on: April 06, 2013, 05:35:36 AM
I have updated the plan a little bit to proposals that include increased fees to push some miners out to other pools, rather than relying on registrations being cut off.  Cutting off registrations will not prevent old miners from turning on ASICs they receive, and with over 80,000 accounts on BTC Guild, it's far more likely for the new hash rate to come from old users than new ones at this time.
Thank you, I know it's not easy turning down customers (miners) when you have aqquired them by clearly offering a superior service. But it is the right thing to do. Veterans of these forums undoutably understand that a 51% attack serves no ones interest, especially the entitys who controlls the hashrate, but the masses who are just discovering and experementing with bitcoin do not. This serves a preemtive measure against Fear, Uncertanity and Doubt.
In case you're claiming the risk of "51% attacks" is FUD, let me assure you it isn't.
If there were no risk, then you might as well be using PayPal.
2215  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 05:33:03 AM
Quite frankly this is getting to be a big motherfuckin' thorn up my ass, coupled with the other shit that's goin' on as of late.

Let's take a look at another bet currently runner of which in no way should even be up, for I don't have the foggiest idea what I would be betting on. http://betsofbitco.in/item?id=1324

Quote
BFL will not ship the first batch of their ASIC miners before July 2013

Butterfly Labs has had a long history of postponing their shipment dates. You bet on the fact that the first batch BFL ASIC has not been shipped until July 1st 2013.


Info
Opening date: March 12, 2013
Bet deadline: June 29, 2013 end of day Eastern Time
Event date: July 1, 2013 end of day Eastern Time
Category: Technology
Total agree bets: 2.20
Total disagree bets: 3.05
Total weighted agree bets: 5697.852
Total weighted disagree bets: 7160.416

WHY THE FUCK IS THIS EVEN UP?

Quote
BFL will not ship the first batch of their ASIC miners before July 2013

The title above mentions the first batch. Explain exactly to me what constitutes the first batch.
This is obviously another poorly defined bet, yes.
While the first batch is pretty well-defined by BFL, the bet fails to mention whether it needs to begin shipping by July 1, or be completely 100% shipped.
In the latter case, it also fails to define how the answer is to be determined - did BFL agree to disclose when the first batch is 100% shipped? If not, it would seem the former (first batch has begun shipping) must be the case. But this should be explicit.
In the case of "first batch begun shipping", does that include my order (which is obviously pre-first batch) or not? IMO, it shouldn't - but again, this should be explicit.

Now what I'm wondering is... why are people betting on poorly-defined bets?
2216  Bitcoin / Pools / Re: [ANN] BTC Guild Registration Limits/51% Mitigation Plan on: April 06, 2013, 03:07:48 AM
How about you screw externalities, keep on adding users and let the free market sort it out?
This is part of the "free market sorting it out":
Having a single entity with blind control over even 25% of the network blocks is a threat that devalues everyone's bitcoins (including their own).
Therefore, it makes economic sense for BTCGuild to try to deter this from occurring.

Too bad they won't allow miners to audit their block data by supporting GBT.
2217  Economy / Games and rounds / Re: Contest: New name for BFGMiner! (0.33 - 1 BTC prize) on: April 06, 2013, 02:36:30 AM
Thank you all for participating. BFGMiner 3.0 has been released with two winners.

First place goes to wizkid057 with "St. Barbara's Faithfully Glorified Mining Initiative Naturally Exceeding Rivals" (400 TBC / 0.67108864 BTC)
Second place goes to mrb with "basically a freaking good miner" (200 TBC / 0.33554432 BTC)

028fdd4a2ae0d707984a13889b7b20f797986213b50c47928a73ba6c0371a358
2218  Economy / Scam Accusations / Re: coinjedi / betsofbitco.in SCAMMERS: Declares "Push" on obvious win for BFL bet on: April 06, 2013, 02:23:48 AM
bitbet.us had almost the same bet and it was not a "push".
http://bitbet.us/bet/265/bfl-will-deliver-asic-devices-before-april-1st/
It's not the same bet. One customer is not "customers" - and it wasn't within 10%.
2219  Bitcoin / Mining software (miners) / Re: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 on: April 05, 2013, 06:55:16 PM
As of BFGMiner 3.0, we have a new forum thread.
MOD Note: For those who can't read: the above is a link.
2220  Bitcoin / Mining software (miners) / Re: BFGMiner 3.0: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC/Avln on: April 05, 2013, 06:54:39 PM
NEW VERSION 3.0.0, APRIL 5 2013

Please note that libcurl 7.29.0 has a socket leak with request failures, which can lead to BFGMiner running out of file descriptors and/or crashing if you have a dead pool! All older and newer versions of libcurl should be fine.

Also note that if you are compiling from git yourself, you must manually run configure after autogen.sh - it is no longer run automatically to be consistent with how every other software package does this.

2.10.6 is also released and promoted to stable. Note it does not support ASICs.

Human readable changelog:
  • New device driver for ASIC devices, including both Butterfly Labs' BitForce SC and Avalon.
  • Enhanced device driver API, enabling devices to asynchronously handle multiple slave processors. Use --show-processors to view each individually (not yet supported for Avalon).
  • You can now use --request-diff <difficulty> to ask for a specific share target from pools that support BIP 23 GBT Basic Pool Extensions.
  • Support for submitting found blocks to a local Bitcoin GBT server (bitcoind or Bitcoin-Qt with -server flag): just append #allblocks to the end of your bitcoind's URI.
  • Stratum connection resuming support - if you lose an active stratum connection, BFGMiner will attempt to resubmit any lost shares when it reconnects.
  • Android target support. You will have to compile it yourself, but it should just work - no patching needed.
  • New Python RPC client example from Christian Berendt.

Full changelog
  • debian: Include new api-example.py in docs
  • added example for Python using the RPC API
  • added SPEC file for SUSE distributions
  • Bugfix: bitforce: Free initialization data to avoid trivial one-time memory leak
  • Support for local submission of found blocks (GBT only)
  • bitforce: RPC pgaset fanmode 0-5 for manual fan control
  • bitforce: More debugging information
  • Bugfix: modminer: Since RPC always includes the temperature, we don't need to add it specially
  • bitforce: Expose dual temperature sensors to RPC
  • bitforce: Support for up to 2 temperature sensors per processor
  • Bugfix: bitforce: BFP_QUEUE: Attempt to recover from extra queue results, or the next job finishing early
  • bitforce: Always send a new job ASAP after flushing the queue
  • bitforce: Implement "Queue Job Pack" (ZWX) and use it for XLINK devices to avoid USB latency issues
  • bitforce: Ignore INPROCESS added to ZOX response
  • Implement minerloop_queue for devices that process work items too fast to keep track of which one they're currently working on
  • bitforce: Split ZOX command into its own function
  • Bugfix: DevAPI: Free work when preparing it fails
  • DevAPI: Abstract get_and_prepare_work for minerloops
  • DevAPI: Move select() logic from minerloop_async to do_notifier_select
  • Clarify stratum mining.set_difficulty debug log message
  • No longer call configure from autogen.sh
  • Bugfix: bitforce: Ensure result_busy_polled gets set for queue mode to avoid unnecessary 10ms wait times
  • Bugfix: bitforce: Use common code for end of job_get_results, so queue results don't short-circuit timing code
  • Bugfix: bitforce: Ensure "OK" doesn't remain in queued results buffer
  • Bugfix: bitforce: next_line needs to increment beyond the newline character
  • Update README for x970 memdiff values.
  • Do not scan other gpu platforms if one is specified.
  • Update README for sync objects on windows.
  • Add information for setting gpu max alloc and sync parameters for windows with scrypt.
  • Whitelist AMD APP SDK 2.8 for diablo kernel.
  • Show pool number in switch message
  • Clear just the socket buffer when we don't care what is left in a stratum socket.
  • Clear the stratum socket whenever we are closing it since the buffer is going to be reused.
  • Do not continue work from a stratum pool where the connection has been interrupted.
  • Close any existing stratum socket if we are attempting to restart stratum so the pool knows the connection has gone.
  • Show mechanism of stratum interruption if select times out.
  • Make stratum connection interrupted message higher priority to be visible at normal logging levels.
  • API add 'Network Difficulty' to 'coin'
  • avalon: if all result are wrong in one batch read. reinit the avalon
  • avalon: record the last result temperature info
  • delay when close avalon; only record matched result
  • avalon: fix no_matching_work only count when debug
  • avalon: minor change
  • avalon: add idle code
  • avalon: fliter the temp_max >= 100, print the result for debug.
  • avalon: export more data to API stats
  • avalon: add default chip frequency
  • avalon: fix the work_i3 init
  • avalon: add reinit_device
  • avalon: the temp_history_count base on timeout
  • avalon: fix mistake on adjest_fan
  • avalon.c: fix the copyright
  • bfgminer-rpc: add -o option: no format, only the result
  • avalon: update fan pwm
  • avalon: update the FAN_PWM MAX/MIN
  • avalon: minor change
  • avalon: overclock code
  • avalon: fix the display
  • avalon: minor change
  • avalon: fix the fan/temp control
  • avalon: fix the temp_avg
  • avalon: fix temp
  • avalon: add fan/temp control
  • avalon: add FAN speed factor
  • avalon: add TODO on fan/temp control. cleanup detect
  • avalon: add the gate_miner bits
  • avalon: only send one byte on reset
  • avalon: add support on send 2 bulk taskes at begin
  • avalon: fix the hash_count return
  • avalon: fix the LOG_WARNING
  • avalon: add comment on hash_count
  • avalon: WORKAROUND on hashrate
  • avalon: update max miner_num
  • avalon: add more info on api
  • avalon: add nonce_elf and more info on match miner_num
  • avalon: change reset to 300ms
  • avalon: move bulk buffer to it's info structrue
  • avalon: more work on hashrate and read_count
  • avalon: add baud 38400 support
  • avalon: fix nonce_range EB
  • avalon: fix the hashrate wrong
  • more info on avalon API
  • avalon: fix the nonce_range EL
  • avalon: fix the read count
  • avalon: more work on nonce_range
  • avalon: read() times and send delay fixed
  • avalon: add the send delay option
  • avalon: print out fan/temp info
  • avalon: add the result info (fan/temp etc)
  • avalon: more check on hardware error
  • avalon: more work on get_work_count
  • avalon: now we have dynamic get_work_count
  • avalon: more work on parameters
  • avalon: add timeout parameter
  • avalon: baud as parameter now
  • avalon: send work pitch should be : (15*(8+2)*4/19200)s
  • avalon: more work on match work
  • avalon: fix free_work
  • avalon: continue on reset work. wait for buffer empty
  • avalon: add options, if write() error. sleep(1) before reset()
  • avalon: more cleanup
  • avalon: finish read when Buffer empty
  • avalon: fix the nonce EB issue
  • avalon: MORE work
  • avalon: fix the EB/LB issue
  • avalon: some cleanup
  • avalon: fix the first configure task
  • more work on the avalon buffer
  • avalon: fix the BIG_ENDIAN issue
  • avalon: Fix the buffer statu
  • change defines to avalon parameters
  • fix the cts return
  • avalon: change the data to uint8_t, add some test temp code
  • avalon: fix task init
  • avalon: more data format work
  • change to avalon data format
  • debug: add a debug hexdump.c
  • avalon: add some code on match work
  • avalon: try to correct the pool_status and dev_status
  • avalon: more work on multi-works
  • avalon: more work on read
  • avalon: more work on get results
  • more RTS code on avalon.c/h
  • more RTS code
  • avalon: some cleanup
  • avalon: more work on new work queue structrue
  • fpgautils.c: use lancelot as target
  • avalon: since we submit task as bulk data. modify again
  • add scanhash_queue
  • renmae avalon.h to driver-avalon.h
  • fpgautils.c: add get_serial_cts
  • understand the avalon protocol more
  • avalon: new software structrue but target as lancelot
  • add avalon.h
  • avalon: fix warning
  • avalon: add TODO comments
  • more AVALON defines
  • avalon: more work
  • add driver-avalon.c
  • add avalon support to automake
  • Default to work queue mode on BitForce SC devices
  • bitforce: Implement support for non-contiguous XLINK slave addressing
  • gnulib: stdint: fix build with Android's Bionic fox x86
  • gnulib: stdint: Improve support for Android.
  • gnulib: stdint: Add support for Android.
  • Check for ?e##toh macros independently from hto?e##
  • If pthread_cancel is missing/emulated, set asynchronous thread cancel type on stage, watchdog, watchpool, and longpoll threads since the emulation cannot support deferred cancellation
  • If pthread_cancel is missing (Bionic/Android), emulate it using pthread_kill and pthread_exit
  • configure: Intelligently detect what flags/libs get us working pthread, and define HAVE_PTHREAD_CANCEL if pthread_cancel is available
  • Bugfix: Initialize mutex_request to invalid so devices that don't use it (bitforce) don't try to
  • RPC: pools: Add "Message" to show last client.show_message received over stratum
  • Stratum: Support client.show_message method
  • Don't retry without resume support, if the first attempt just timed out
  • Bugfix: minerloop_async: Intelligently handle work updates and device disables during transitions
  • Bugfix: minerloop_async: Free old (unused) prepared work when replacing it with an upgraded one
  • Bugfix: Free pool sessionid before replacing it
  • Bugfix: Stratum: Address dereference-after-free and memory leak introduced in resume support
  • Stratum: If old protocol fails as well, try to resume again next time around
  • Bugfix: Stratum: Only failover to old mining.subscribe protocol if the previous attempt was the new one (fixes a flood of retries)
  • Try to extract the sessionid associated with mining.notify on 3rd level array and submit it along with the userid to support mining resume, failing gracefully and restarting if the pool rejects it.
  • Cope with misread sessionid on stratum for now.
  • Use the sessionid as passed on stratum connect to attempt to resume a connection once and then clear it if it fails, to use a new connection.
  • Move to storing the nonce1 in the work struct instead of the sessionid for the now defunct first draft mining.resume protocol.
  • Only continue submitting shares with mining.resume support on stratum when the session id matches.
  • Provide support for mining.resume with stratum, currently re-authorising after successful resumption pending finalising of the protocol process.
  • Provide basic framework for restarting stratum depending on whether resume support exists or not.
  • Abstract out the setting up of the stratum curl socket.
  • Remove redundant setting of strings to NULL since the whole work struct is zeroed.
  • Only clear stratum shares mandatorily on stratum dropouts when the pool does not support resume.
  • Stratum: Keep trying to submit shares, even across reconnects
  • Use new select loop primitives in submission thread
  • Bugfix: Missing pool_no parameter to applog for no-stratum-sessionid debug message
  • Do as much outside of mutex locking of sshare_lock as possible.
  • Remove last reference to struct work used outside the sshare_lock in submit_work_thread
  • Unlock the sshare_lock in submit_work_thread when all references to work and sshare are complete.
  • Bugfix: Copy and free sessionid on work objects
  • Add timestamps to stratum_share structs as they're generated and copy the stratum sessionid if it exists to stratum work generated.
  • Store session id for stratum if the pool supports it for future mining.resume support.
  • Keep the unique id of each work item across copy_work to prevent multiple work items having the same id.
  • x6500: Never consider processors idle if they're enabled
  • x6500: Make mutex management cleaner by blocking device select loop during idle get_stats
  • Bugfix: minerloop_async: Always refer to real thread for select loop
  • Bugfix: Initialize work_restart_notifier[1] to INVSOCK instead of -1 to be portable
  • ztex: Use restart_wait to react quicker to work updates
  • Handy TIMEVAL_USECS macro
  • Restore blocking restart_wait function with nearly identical semantics as old one
  • Bugfix: bitforce: Rework sleep delay adjustment logic to properly deal with more accurate timing readings (added in device API update)
  • Hidden --force-rollntime option for getwork pools (use like --pool-priority, after each pool definition)
  • Include processor id in get_work logging
  • Support for BIP23 BPE request target extension via new --request-diff option
  • Hidden option to reduce "work update" messages to debug level: --quiet-work-updates
  • Change "work restart" to "work update" in messages to reflect reality more accurately (no work is lost), and normalize case of "longpoll"
  • HACK: Since get_work still blocks, reportin all processors dependent on this thread
  • Move FD_SETSIZE definition to configure so it affects everywhere it needs to
  • Move absolute_uri function to util.c
  • Remove now-unused blocking-wait code (restart_cond, restart_wait, and stale_wait)
  • Bugfix: bitforce: Zero hashes complete if we get an invalid response
  • HACK: Since get_work still blocks, reportout all processors dependent on this thread
  • bitforce: Support for work queue protocol on BitForce SC devices
  • Use new double-stage format for SC devices
  • modminer+x6500: Expose frequencies to API in terms of MHz to be consistent with ztex driver and cgminer
  • bitforce: Replace (bool)cgpu->nonce_range with (enum)bitforce_data->proto
  • bitforce: XLINK support for multiple processors
  • bitforce: Prepare log messages for XLINK by separating into proc and dev messages
  • bitforce: Always use fd/mutex pointers on actual device, to prepare for XLINK support
  • bitforce: Get fd/mutex pointers only once per function
  • bitforce: Abstract commands to bitforce_cmd1 (single-stage) and bitforce_cmd2 (double-stage) functions
  • bitforce: Debuglog device information during detection
  • Bugfix: Missing includes needed on Windows
  • Bugfix: Use waddstr instead of wprintw to display completed device summary line, so literal %s don't get interpreted as formatting options
  • Bugfix: bitforce: Avoid polling continuously between work restart and job completion
  • bitforce: Use poll device API when job_get_results needs to wait
  • bitforce: Use poll device API when job_start needs to wait
  • stale_work_future function to determine in advance if a work/share will be stale at some future time
  • bitforce: Minimally refactor to adapt to new minerloop_async
  • minerloop_async: Break out of select on work_restart_notifier
  • Replace UNIX-only work_restart_fd pipe with portable work_restart_notifier
  • Bugfix: Clean out unused variables from minerloop_async
  • Move new device API code to new deviceapi.c source file
  • Make minerloop_async more async, using some callbacks to handle event completions
  • Split part of minerloop_async into do_get_results, and a bit other reorganization
  • Abstract select_timeout function to convert a realtime timeval to a timeout pointer for select()
  • Split part of minerloop_async into do_process_results, and don't allow api->job_get_results to return hashes
  • Split part of minerloop_async into do_job_prepare and do_job_start
  • Initialize thr->tv_poll to -1 (disabled)
  • Update the hashmeter one last time before disabling a device
  • minerloop_async: Break out of select for wakeup notifications
  • Replace mining thread queues (which were only used for wakeup pings) with notifiers (which can be used with select and co)
  • Unify all mining thread wakeup to mt_enable (simplifying code)
  • Bugfix: get_statline: Correct device summary status, only showing DEAD or OFF if it affects all processors
  • Working processor disable/enable with new async minerloop (currently gets stuck if all processors disabled)
  • Bugfix: get_statline: Only care about the processor status if --show-processors is set
  • Bugfix: watchdog: Use processor thr_info even if it isn't a real thread
  • Only support thread-per-device or N-threads-per-processor; simplify work_restart check
  • x6500: Remove mutex, since driver is single-threaded now
  • Bugfix: Update utility every get_statline call, and include every processor involved
  • HACKING: New text file to document the internal workings of (currently) the device API
  • Bugfix: mining_threads is now a total of thr_info objects, not necessarily actual running threads
  • x6500: Working (but incomplete) asynchronous/single-threaded driver
  • Incomplete (but workable) asynchronous minerloop
  • Core support for managing multiple processors from a single thread
  • Allow device drivers to implement their own minerloop
  • Move cgpu_info and thr_info initialization to main, and ensure all get initialized before starting any threads
  • Refactor and simplify miner_thread (no major behavioural changes)
  • Move difficulties to end of share result message, so they can be made to line up nicely
  • Bugfix: Consolidate share result message code (including fixing displayed hash portion for stratum)
  • miner.php: Include ProcID in Device column as a letter
  • Show summaries per-device unless --show-processors is used (also available on Display TUI menu)
  • Order next_proc linked list in processor id order
  • Consolidate processor summary line generation for TUI and text-only modes
  • RPC: Update to include ProcID so multiprocessor devices can be understood correctly
  • RPC: Common function for adding device-identifying fields
  • modminer: Make single-processor statline look like other temperature-only statlines
  • modminer: Split each FPGA into its own logical processor (in the same device still)
  • modminer: Get mutex pointer only once per function
  • ztex: Combine master+slave devices into a single multiprocessor device
  • Preformat dev_repr (device representation) and proc_repr (processor representation) once for use everywhere
  • x6500: Split each FPGA into its own logical processor (in the same device still)
  • x6500: Get mutex pointer only once per function
  • Minimal support for defining devices with multiple logical processors
  • Rename all README files to standard README.* style
Bugfixes included in both 3.0.0 and 2.10.6:
  • Bugfix: openwrt: Never include _ in platform name
  • Bugfix: Fixed typo in bfgminer-rpc usage
  • pool_active: Ensure temporary curl is always cleaned up
  • Try to find jansson via pkg-config first, and fall back to checking system defaults if that fails
  • Attempt to find libjansson via pkg-config if AC_CHECK_LIB fails
  • Update scrypt readme re drivers and sdk.
  • Bugfix: README: Move --device out of GPU only options
  • Update .gitignore
  • Added bfgminer-rpc binary to .gitignore
  • Bugfix: Actually change to the newly selected pool when statum is inactive and it decides to change
  • Bugfix: modminer: Properly fail on dynclock error
  • Bugfix: opencl: Clean pc_data->work before freeing pc_data
  • Bugfix: Correct order of libblkmaker libraries so static builds work
  • Bugfix: Need to ensure __BIG_ENDIAN__ is defined before including uthash.h
  • Bugfix: Stratum: When destroying cURL easy handle, be sure to clear pool stratum_curl pointer
  • Bugfix: bitforce: Fix warning
  • Bugfix: Stratum: Properly handle non-integer "id" for client.get_version requests
  • json_dumps_ANY utility function to portably implement json_dumps(..., ... | JSON_ENCODE_ANY)
  • Bugfix: bitforce: Free old name when updating it on reinitialization
  • Stratum: Include pool number in send/recv protocol logging
  • Include pool number in stratum thread name
  • API always report failed send() replies
  • API.java allow partial reads
  • Bugfix: Stratum: Use curl_easy_cleanup to close connection, so cURL understands what is going on
  • Bugfix: hash_pop: If a work should be rolled, use a clone of it rather than consume a rollable work
  • openwrt: Move Makefile into a bfgminer subdirectory to avoid symlinking issues
  • openwrt: Use --with-curses=ncurses to avoid ncursesw dependency
  • configure: Support --with-curses=FOO to look for curses implementation in libFOO
  • Set pool socket to INVSOCK after closing connection, just in case
  • Clean up compiler warnings
  • Bugfix: Check that pool is active one last time before selecting it
  • Bugfix: Trim whitespace (like newlines) off the end of debug info from libcurl
  • Bugfix: submit_nonce: Backup the original work->blk.nonce since the miner code uses it to track work consumption
  • Bugfix: Scheduler needs to unpause disabled devices, even if it isn't waking them up
  • Bugfix: Use SOCKETTYPE for notifiers, to avoid potential overflow on Win64
  • Bugfix: Some versions of MingW define localtime_r, but don't handle the timeval.tv_sec case that we use; so undef any preexisting one and use our own
  • Bugfix: reinit_gpu: Remember the selected device to correctly change properties of
  • Bugfix: cpu: reinit_device hasn't worked since 93b284d, so just remove it entirely instead of letting it screw with thread 0
  • Document necessity to run ldconfig and possibly configure ld.so
  • Bugfix: Complete startup after just one pool is found active, no need to wait for the rest
  • Bugfix: Update links
  • miner.php: Replace PGA dev number with concatenated device ID
  • Bugfix: miner.php: Display devices with aligned columns instead of assuming they come out of the RPC aligned
  • Bugfix: miner.php: Silence PHP "local timezone" warning
  • Bugfix: api-example: Try to use BSD sockets on any non-Windows platform
  • Bugfix: stratum: Delay mining.get_transactions request until after auth has succeeded, so its failure doesn't abort the connection (also avoids any delay from a large result)
  • --no-getwork option to disable getwork protocol support
  • Clarify dependencies with Debian/Ubuntu package names
Pages: « 1 ... 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 [111] 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 ... 247 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!