Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 09:54:26 PM |
|
Update: HUPed after 3 hours operation. What do you mean by HUPed? The HUP signal is sent when you close the terminal...
|
|
|
|
Xer0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 10:22:45 PM |
|
runs very well on a TP-Link MR3020 (WR703N)
Thanks!
(now i just need come watchdog stuff for failsafe things)
|
|
|
|
Zeronic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 243
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 10:50:30 PM |
|
All current versions are known working - I wouldn't release them if they didn't work. 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/5I'm kind of lost at this point.
|
|
|
|
jml
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 11:14:16 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.
|
"Everything is a matter of degree"
|
|
|
RoboCoder
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 11:59:22 PM |
|
All current versions are known working - I wouldn't release them if they didn't work. 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/5I'm kind of lost at this point. 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
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 12:13:33 AM |
|
All current versions are known working - I wouldn't release them if they didn't work. 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/5I'm kind of lost at this point. Be sure you're using Zadig the way described in README.FPGA 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 recommend running BFGMiner inside GNU Screen. 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.
|
|
|
|
RoboCoder
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 01:21:23 AM |
|
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.
|
|
|
|
jml
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 01:52:14 AM |
|
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 recommend running BFGMiner inside GNU Screen. I have been using GNU screen all along.
|
"Everything is a matter of degree"
|
|
|
Zeronic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 243
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 03:39:54 AM Last edit: July 31, 2013, 02:57:57 PM by Zeronic |
|
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?
|
|
|
|
Aahzman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 10: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?
|
|
|
|
Zeronic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 243
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 12:57:30 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?
I think if you add -G to the command string that will disable the GPU's.
|
|
|
|
Aahzman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 02:18:43 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?
I think if you add -G to the command string that will disable the GPU's. Thanks. Will try that on next crash/restart. :-)
|
|
|
|
Taugeran
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 05: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?
I think if you add -G to the command string that will disable the GPU's. Thanks. Will try that on next crash/restart. :-) it depends on which version of bfgminer is in use. 3.1.2>= -G should work 3.1.3 forward will be -S OpenCL:noauto
|
Bitfury HW & Habañero : 1.625Th/s tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1 Come join Coinbase
|
|
|
Aahzman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 05:33:27 PM |
|
ah. ok. i'm on 3.1.3, so i'll do that -S thing.
Thanks
|
|
|
|
Zeronic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 243
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 31, 2013, 08: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?
Try the -S X6500:auto or just -S all and it still won't mine on the X6500.
|
|
|
|
Dork.
Newbie
Offline
Activity: 12
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2013, 02:18:11 AM |
|
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....
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2013, 03:35:57 AM |
|
NEW VERSION 3.1.4, AUGUST 2 2013Human 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
|
|
|
|
Aahzman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2013, 12:36:46 PM |
|
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.
|
|
|
|
JakeTri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2013, 12:40:16 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) So far 3.1.4 works fine from last night on 3 systems. I'll let you know if I see any issue.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
purelithium
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2013, 07: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.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
|