btw Luke there is nothing about -G in readme
it says only
Quote
GPU mining can be disabled by specifying the -S opencl:noauto option.
Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 145. (Read 1193223 times)
August 03, 2013, 09:55:19 AM
-G -S erupter:all
btw Luke there is nothing about -G in readme
it says only
btw Luke there is nothing about -G in readme
it says only
August 03, 2013, 12:43:44 AM
-G -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100
You get some more functionality by using -G -S erupter:allu mean this cmd line or: -G -S erupter:all --icarus-options 115200:1:1 --icarus-timing 3.0=100
or only -G -S erupter:all
what is correct now ?
August 02, 2013, 10:24:36 PM
Thought i would throw my 2 cents in here, just upgraded to 3.1.4 and running 32 usb miners and everything running fine, except the last miner is showing up twice ICA31 2x, and seems to be mining, so did i just get my 33th usb miner 4free? 
Maybe! I don't know what would cause this kind of thing :/-G -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100
You get some more functionality by using -G -S erupter:allWell i tried that, screen looks bit different, but still got now 2 BES31's a going
any idea what that extra command did? think i would get any higher hash rate? BTW love this program.. Keep up the good work.running
-G -S erupter:all
August 02, 2013, 10:14:32 PM
Thought i would throw my 2 cents in here, just upgraded to 3.1.4 and running 32 usb miners and everything running fine, except the last miner is showing up twice ICA31 2x, and seems to be mining, so did i just get my 33th usb miner 4free?
Maybe! I don't know what would cause this kind of thing :/-G -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100
You get some more functionality by using -G -S erupter:all August 02, 2013, 10:12:46 PM
Thought i would throw my 2 cents in here, just upgraded to 3.1.4 and running 32 usb miners and everything running fine, except the last miner is showing up twice ICA31 2x, and seems to be mining, so did i just get my 33th usb miner 4free?
PS
I have already tried restarting the miner 3 or 4 times still getting that 33th miner in there somehow use the same .bat file i been using since 3.1.1
here is what i have in the bat file sides the login/pool info:
-G -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100
PS
I have already tried restarting the miner 3 or 4 times still getting that 33th miner in there somehow use the same .bat file i been using since 3.1.1
here is what i have in the bat file sides the login/pool info:
-G -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100
August 02, 2013, 02:57:29 PM
MMQ clock speed changes don't actually take effect. It appears they do, but revert to bfgminer-chosen clocks immediately after exiting Manage menu.
Combined clockrate at 900mhz, actual hashrate 676. not helpful.
Combined clockrate at 900mhz, actual hashrate 676. not helpful.
August 02, 2013, 07:40:16 AM
NEW VERSION 3.1.4, AUGUST 2 2013
...
...
- Reorganised TUI display, adding network transfer rate, and totals summary line including count of total devices/processors hashing as well as hottest temperature across all sensors.
I like the new TUI
So far 3.1.4 works fine from last night on 3 systems. I'll let you know if I see any issue.
August 02, 2013, 07:36:46 AM
Finally captured the error message i'm getting with 3.1.3 and two jalapenos...
BFL0: idle for more than 60 seconds, declaring sick!
BFL0: attempting to restart
BFL0: re-initialising
and that's when bfg stops working and throws up the "search for a solution" or "close the application" dialog.
BFL0: idle for more than 60 seconds, declaring sick!
BFL0: attempting to restart
BFL0: re-initialising
and that's when bfg stops working and throws up the "search for a solution" or "close the application" dialog.
August 01, 2013, 10:35:57 PM
NEW VERSION 3.1.4, AUGUST 2 2013
Human readable changelog:
Full changelog
Human readable changelog:
- Enable triggering "identify" (flash LED) function from Manage device TUI for devices that support it.
- modminer & x6500: Enable changing clock frequency from Manage devices TUI interface.
- Mac/BSD: Fix new IO speed support detection, so Icarus-compatible devices work by default.
- Device ailments (SICK, ERR, etc) are now displayed in red/pink.
- erupter: Add support for "identify" (flash LED) function. After some delay (up to 13 seconds), the LED will light for 3 seconds (hashing stops during this time). Thanks to Rotorgeek and Canary for helping test!
- bitforce: Display voltages in Manage device TUI.
- Reorganised TUI display, adding network transfer rate, and totals summary line including count of total devices/processors hashing as well as hottest temperature across all sensors.
- Improved timer functionality under the hood, taking advantage of QueryPerformanceCounter on Windows and clock_gettime on *nix. This should fix issues (eg, erupters reporting insane hashrates) related to system clock changes (such as NTP drift adjustment).
- Removed blank/wasted lines above/below log window in TUI mode.
- bitforce: Clear queues at startup to avoid spurious warnings.
- Stratum: Add support for rolling ntime header.
Full changelog
- Windows: Rebuild pdcurses with UTF-8 and wide character support
- Bugfix: Avoid using wide curses symbols/macros when USE_UNICODE is not defined
- Unicode: Use line drawing in TUI Help
- Use bfg_waddstr even with Unicode disabled, since it's needed for red highlight
- Colour bad conditions in red
- Unicode: Cross-tee intersecting lines
- Unicode: Use WACS_VLINE for vertical lines
- Unicode: If degrees symbol is available, add it to temperatures
- Unicode: bfg_waddstr wrapper to handle non-ASCII characters, currently used only by logging and statlines
- Unicode: Use WACS_HLINE for horizontal lines
- Add framework for using Unicode in TUI (can be disabled with --no-unicode)
- Avoid using potentially locale-dependent ctype functions in locale-independent contexts
- Refactor temperature in TUI statlines to share code nicer
- Bugfix: avalon: Fix applog formatting
- Bugfix: Align totals columns in per-processor view
- Bugfix: Fix curses-less build
- configure: Workaround buggy autoconf versions
- Bugfix: erupter: Include headers in order necessary for Windows
- Bugfix: Reimplement get_intrange using strtol instead of sscanf (which is broken on Windows)
- Bugfix: get_intrange: Check for extra garbage at the end, only after we know we have an end-position
- Bugfix: Fix Enter key in TUI on Windows
- erupter: Split identify-handling logic into handle_identify function
- Bugfix: erupter: Ensure identify is handled during no-once or firstrun
- erupter: After identify, check if a work restart is needed immediately
- erupter: Implement identify function by pausing hashing for 3 seconds
- Bugfix: icarus: Remember firstrun state in case it gets changed for the next run
- icarus: Move actual dynclock updates to icarus_job_start
- icarus: Split out icarus_job_prepare, and rename icarus_job_start
- Bugfix: ZeroStats: Reset column widths to 1
- miner.php: Include max temperature in device totals line
- Bugfix: Stratum Fix debug logging of initial mining.subscribe command
- Bugfix: Call pool_set_opaque from work_decode, so block content hiding/providing messages work for getwork/GBT
- Split block contents hiding/providing notices out from stratum code
- Add test suite for get_intrange
- Bugfix: Check for error conditions in get_intrange to not have weird --device behaviour when bad values are provided
- Bugfix: erupter: Take advantage of detectone_meta_info to handle Emerald autodetection
- TUI Help describing the various status fields (contributed by midnightmagic)
- Bugfix: ManageTUI: Allow 'I' key to be used by devices not supporting identify
- Bugfix: Prefer Sapphire over Emerald for -S erupter:*
- Bugfix: Clear total_bad_nonces when zeroing statistics
- Bugfix: modminer: Since we are not searching iManuf string for needles, only look for "ModMiner"
- Bugfix: sysfs autodetect: Recurse into tty/ subdirectory (necessary for CDC/ACM ttys)
- sysfs autodetect: Split tty* directory search into new _sysfs_find_tty function
- modminer: Reduce default clock to 190 MHz
- README: Update driver info to include Erupter driver
- README: FAQ about scrypt and difficulty
- Include count of working devices/processors in totals statline
- Format totals statline the same way as individual device/processor statlines
- Rearrange TUI a bit, including menu at the top (+1 log line) and hashrate total closer to device summaries
- Bugfix: setup_stratum_curl: Need to release stratum lock on connection failure too
- Bugfix: Avoid unnecessary locks inside curses_print_status, which is called with the console lock held
- Bugfix: setup_stratum_curl: Hold stratum lock until connection completes, to avoid potential races
- Bugfix: stratum_works: If stratum is already active, it works (avoid trying to initialise it again)
- Replace hashrate_to_bufstr/ti_hashrate_bufstr with format_unit/multi_format_unit_array
- New multi_format_unit_array to fill multiple buffers instead of building a delimited string
- multi_format_unit: Skip recounting length of fixed-length strings
- Shrink status line to fit in 80 columns
- Add network bandwidth rate to TUI
- New multi_format_unit variadic macro to handle formatting multiple numbers at once
- format_unit: Option to choose 3-digit integer display vs 5-character floating-point display
- Optimization: format_unit: Handle number first, to avoid having to restore suffix later
- Generalise hashrate_pick_unit/hashrate_to_bufstr into pick_unit/format_unit
- Extend hashrate_pick_unit/hashrate_to_bufstr to handle sub-kilo units
- Split total_bytes_xfer to total_bytes_rcvd and total_bytes_sent
- Bugfix: _decode_udev_enc_dup: Allocate enough space for full string
- Bugfix: Never use waddstr for logwin, since it would bypass special newline handling
- Bugfix: bitforce: Set kname on chip processors
- bitforce: Include voltages in Manage device TUI
- Defer newlines going to curses logwin, to avoid a useless blank line at the bottom of the window
- Ensure printing to logwin always goes through _wlog
- Remove blank line above log window
- bitforce: Identify parallel queue protocol distinctly from mere bulk queue
- ManageTUI: Include kernel name, when available
- Stratum: Roll ntime as we generate work
- Stratum: Make swork.ntime native-endian
- Stratum: Treat ntime as uint32_t (as it should be), still always big endian
- Debuglog ManageTUI actions/responses
- ManageTUI: Add generic Identify support
- Bugfix: Move serial_detect* and open_bitstream to DevAPI code so CPU/OpenCL can build properly without fpgautils
- Short-circuit logging sooner in quiet mode
- Write to both stderr and console within same console lock "session"
- Bugfix: Also hold the console lock when writing to stderr
- Use common console locking function for stdout in logging.c
- Move console lock and unlock functions (which also handle thread cancelstate) to miner.h
- Bugfix: bitforce: Only try to clear queues of SC devices, since FPGA MR boards interpret ZQX/ZOX differently
- Timer-based gettimeofday substitute for systems with poor time-of-day clocks (Windows)
- Use clock_gettime(CLOCK_MONOTONIC) for timers when available
- Use QueryPerformanceCounter for timers on Windows
- Generic refactoring for timer_set_now
- Replace all remaining uses of gettimeofday for timers, with timer_set_now (aka cgtime)
- Don't mix timers with timestamps (visual only)
- Always use struct timeval for timers, and don't mix timers with timestamps (functional only)
- get_datestamp: Change timeval parameter to time_t, and implement get_now_datestamp for common "current time" use case
- Use get_datestamp for (non-microsecond) log timestamps
- Bugfix: ztex: Allocate final processor names on the heap, so they survive when the stack for ztex_prepare is gone
- Bugfix: ztex: Copy serial number to device "name" before cloning it for other processors
- Bugfix: x6500: Use cgpu->temp directly since there is only one sensor per processor
- Bugfix: Actually show the highest temperature, not just calculate it
- x6500: Allow changing clock speed from TUI Manage device
- x6500: Port pgaset clock from modminer driver at 66d2a3ab072fcdbc3c7ed41a97f265afa917bbee
- modminer: Allow changing clock speed from TUI Manage device
- bitforce: Flush job and result queues at startup to avoid unnecessary warnings
- x6500: Reduce default clock to 190 MHz
- Bugfix: fpgautils: Close libusb handle after copying USB strings
- use BSD sed syntax to generate iospeed_local.h
August 01, 2013, 09:18:11 PM
Hello!
Just letting you all know that I had been trying to get bfgminer 3.1.3 to work on an old Mac, to use some block erupters.
It has 10.5, and I have been having problems with homebrew on 10.5, so I downloaded and compiled all the libraries individually.
I managed to successfully compile it after a few strategic edits, but every time I tried to use it with my block erupters, it would fail on the scan, complaining about an "Unsupported baud rate".
I knew that my erupters and hub work fine because the bitminter client works fine for me.
On a whim, I decided to try compiling earlier versions, and it turns out Version 3.1.2 works fine for me. So I am good now, but I figured I should let you all know....
Just letting you all know that I had been trying to get bfgminer 3.1.3 to work on an old Mac, to use some block erupters.
It has 10.5, and I have been having problems with homebrew on 10.5, so I downloaded and compiled all the libraries individually.
I managed to successfully compile it after a few strategic edits, but every time I tried to use it with my block erupters, it would fail on the scan, complaining about an "Unsupported baud rate".
I knew that my erupters and hub work fine because the bitminter client works fine for me.
On a whim, I decided to try compiling earlier versions, and it turns out Version 3.1.2 works fine for me. So I am good now, but I figured I should let you all know....
July 31, 2013, 03:22:56 PM
I followed the README.FPGA but using the WinUSB (v6.1.7600.16385) no version of BFGMiner will detect the X6500.
Update: After a Software Update and a reboot, I now get "FTDI reports 1 devices". So from this point I need to add something like the -S X6500:auto to the command string?
Update: After a Software Update and a reboot, I now get "FTDI reports 1 devices". So from this point I need to add something like the -S X6500:auto to the command string?
Try the -S X6500:auto or just -S all and it still won't mine on the X6500.
July 31, 2013, 12:33:27 PM
ah. ok. i'm on 3.1.3, so i'll do that -S thing.
Thanks
Thanks
July 31, 2013, 12:27:31 PM
Howdy. program works great except for random crashing. I have two BFL 5Gh/s Jalapenos, mining on Slush's pool, Windows 7, 64bit. It'll hum along just fine for a while, and then randomly just stop working. After reading a few pages of this thread, i've restarted it with -D -T args to see if i can get any info about the crashing.
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
I think if you add -G to the command string that will disable the GPU's.
Thanks. Will try that on next crash/restart. :-)
3.1.2>= -G should work
3.1.3 forward will be -S OpenCL:noauto
July 31, 2013, 09:18:43 AM
Howdy. program works great except for random crashing. I have two BFL 5Gh/s Jalapenos, mining on Slush's pool, Windows 7, 64bit. It'll hum along just fine for a while, and then randomly just stop working. After reading a few pages of this thread, i've restarted it with -D -T args to see if i can get any info about the crashing.
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
I think if you add -G to the command string that will disable the GPU's.
Thanks. Will try that on next crash/restart. :-)
July 31, 2013, 07:57:30 AM
Howdy. program works great except for random crashing. I have two BFL 5Gh/s Jalapenos, mining on Slush's pool, Windows 7, 64bit. It'll hum along just fine for a while, and then randomly just stop working. After reading a few pages of this thread, i've restarted it with -D -T args to see if i can get any info about the crashing.
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
I think if you add -G to the command string that will disable the GPU's.
July 31, 2013, 05:22:57 AM
Howdy. program works great except for random crashing. I have two BFL 5Gh/s Jalapenos, mining on Slush's pool, Windows 7, 64bit. It'll hum along just fine for a while, and then randomly just stop working. After reading a few pages of this thread, i've restarted it with -D -T args to see if i can get any info about the crashing.
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
Also, by default it starts up detects/mines with both BFL devices and my GPU. i've looked at the --device|-d command not sure how to get it to do something useful like only enable the BFLs. The devices are listed as
OCL 0
BFL 0
BFL 1
so, would the numbering be as simple as 0, 1 and 2? so if i just want the BFL's used, i would add -d 1-2 to my command line?
July 30, 2013, 10:39:54 PM
I followed the README.FPGA but using the WinUSB (v6.1.7600.16385) no version of BFGMiner will detect the X6500.
Update: After a Software Update and a reboot, I now get "FTDI reports 1 devices". So from this point I need to add something like the -S X6500:auto to the command string?
Update: After a Software Update and a reboot, I now get "FTDI reports 1 devices". So from this point I need to add something like the -S X6500:auto to the command string?
July 30, 2013, 08:52:14 PM
Update: HUPed after 3 hours operation.
What do you mean by HUPed?The HUP signal is sent when you close the terminal...
HUP happens because I use SSH to open a terminal. When I try to SSH back in, I can't. This is why I need to power it down and then back up again.
I have been using GNU screen all along.
July 30, 2013, 08:21:23 PM
I have exactly this same problem. If i run 3.11 they are reconized and work properly, but if i run 3.13 i get the same error. (so i am running
OH! I do have a fix for a X6500 regression slated for 3.1.4. Just didn't realize it manifested this way >_<Stay tuned, probably just a few more days...
If you'd like to help test now, the latest git is always available from WeBisect.
I downloaded the win64 to test. It worked with both the x6500's and the ModMiners just fine. Yay! Thanks. Will let you know if i see any problems.
July 30, 2013, 07:13:33 PM
Results of working on getting BFGMiner to work with X6500.
Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp
http://pastebin.com/bn8tecQT
Luke can we got a known working version or a better suggestion please?
All current versions are known working - I wouldn't release them if they didn't work.Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp
http://pastebin.com/bn8tecQT
Luke can we got a known working version or a better suggestion please?
There is no sign of a X6500 on your USB bus in the pastebin, with or without the correct driver.
X6500 is 0403:6001
http://tinypic.com/r/26126g5/5
I'm kind of lost at this point.
Update: HUPed after 3 hours operation.
What do you mean by HUPed?The HUP signal is sent when you close the terminal...
HUP happens because I use SSH to open a terminal. When I try to SSH back in, I can't. This is why I need to power it down and then back up again.
I have exactly this same problem. If i run 3.11 they are reconized and work properly, but if i run 3.13 i get the same error. (so i am running
OH! I do have a fix for a X6500 regression slated for 3.1.4. Just didn't realize it manifested this way >_<Stay tuned, probably just a few more days...
If you'd like to help test now, the latest git is always available from WeBisect.
Jump to: