Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 01:46:16 AM |
|
Can we use BFGMiner on Avalon? BFGMiner does support Avalon boards. However, there is no premade firmware for the host router included with them. There is an avalonhost-raminst script bundled with BFGMiner that will install it to RAM, but I haven't taken the time to document this process yet. Additional notes are in the README.ASIC file.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 01:50:30 AM |
|
@luke-Jr: ante plans to compile/include the recently open sourced bitfury slx150 bitstream for fpga devices? Unfortunately, Bitfury posted the source on MEGA, which has stopped supporting/working on GNU/Linux, so I can't even download it. Even if I could, I'm afraid I'm so tied up with everything else, it will be a while before I get the chance to really do anything this in-depth for FPGAs. However, if anyone else wants to have a go at building a JTAG-I/O bitstream binary from it (and releases their source under GPLv3-compatible terms), I'd be glad to dedicate some time toward updating the code to upload and use it.
|
|
|
|
farproc
Sr. Member
Offline
Activity: 406
Merit: 250
ALGORY.io Crowdsale starts on 8/12/2017
|
|
July 08, 2013, 05:06:14 AM |
|
Can we use BFGMiner on Avalon? BFGMiner does support Avalon boards. However, there is no premade firmware for the host router included with them. There is an avalonhost-raminst script bundled with BFGMiner that will install it to RAM, but I haven't taken the time to document this process yet. Additional notes are in the README.ASIC file. Thanks.
|
|
|
|
flyonwall
Full Member
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
|
July 08, 2013, 06:11:48 AM |
|
Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 06:26:00 AM |
|
Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?
IMO, not gonna happen. BFGMiner makes extensive use of variable-length arrays (standard C since 1999). Microsoft explicitly refuses to support variable-length arrays. I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower.
|
|
|
|
flyonwall
Full Member
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
|
July 08, 2013, 08:11:03 AM Last edit: July 08, 2013, 08:34:42 AM by flyonwall |
|
Thanks. Is it variable-length arrays, or variable-length params? Or both? I have to do some research on that.
Edit: C99 standard variable-length arrays. Doing more research at MSDN ...
Edit: Yup. The code would have to be decorated with firstprivate pragmas. Like you said, it's going to be ugly.
|
|
|
|
infamousdutch
|
|
July 08, 2013, 07:27:59 PM |
|
Is anybody already trying to build from source using Visual Studio? I realize there is already a Windows version, but I am more familiar with Visual Studio and would like to contribute by making the source buildable using MS tools. What kind of problem can I expect? I understand that MinGW is used to provide Linux API on Windows, but has anybody tried using the native Windows POSIX-compatible API?
IMO, not gonna happen. BFGMiner makes extensive use of variable-length arrays (standard C since 1999). Microsoft explicitly refuses to support variable-length arrays. I'll look at patches of course, but I'm doubtful it can be done without making the code much uglier or slower. Wow, I never know MS's C compiler didn't support VLAs. They recommend that you compile as C++ and use vectors from the STL.
|
|
|
|
LGT06
Newbie
Offline
Activity: 23
Merit: 0
|
|
July 08, 2013, 07:39:04 PM |
|
I just got a couple USB Erupters and I am mining with them just fine. I would like to know if there is a command line argument I can use to disable my GPU from mining with BFGMiner.
using bfgminer -S all starts up both my USB Erupters and my GPU (shown as OCL 0). Then I have to go into GPU options and disable it.
How can I disable OCL 0 via command line when starting BFG Miner?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 07:51:40 PM |
|
I just got a couple USB Erupters and I am mining with them just fine. I would like to know if there is a command line argument I can use to disable my GPU from mining with BFGMiner.
using bfgminer -S all starts up both my USB Erupters and my GPU (shown as OCL 0). Then I have to go into GPU options and disable it.
How can I disable OCL 0 via command line when starting BFG Miner?
Up to 3.1.1: -G 3.1.2 and newer: -S opencl:noauto
|
|
|
|
LGT06
Newbie
Offline
Activity: 23
Merit: 0
|
|
July 08, 2013, 07:58:54 PM |
|
Up to 3.1.1: -G 3.1.2 and newer: -S opencl:noauto
That did it. Not sure how I missed it in the readme when I searched for "disable". Thanks for the PEBKAC support.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 08:32:19 PM |
|
NEW VERSION 3.1.2, JULY 8 20133.0.5 and 2.10.11 are also released with 3.1.2. 3.0.5 will likely also be the final 3.0.x release (if 3.1.2 isn't at least as stable, please let me know!), but 2.10.x will continue to be maintained for now. Human readable changelog:- TUI: The "GPU management" interface has been replaced with a new generic "Manage devices" interface, allowing easy enable and disable of non-GPU devices.
- Major CPU usage reduction for faster mining rigs (on my minirig host system, from 35% down to 13%!).
- erupter: New icarus-based driver to handle autodetection of (branded) Block Erupter devices.
- opencl: Add support for AMD Catalyst 13.2+ drivers.
- The device statlines have been condensed by reducing the device-specific space down to a single temperature reading. More detailed information (such as GPU fan speeds) is still available via RPC and the new "Manage devices" interface.
- RPC: New "devscan" command to probe for new devices on demand. The effect is the same as starting BFGMiner with -S noauto -S <parameter>.
- TUI: Display percentage invalid of found nonces with hw errors.
- cpu & opencl: These legacy drivers now respect the --scan-serial auto/noauto directives, and the old -C (enable CPU) and -G (disable GPU) options are now deprecated.
Full changelog- When not compiling with optimizations, initialize unused nonce2 space to avoid warnings from memory checking tools
- TUI Manage devices: Support PgUp/PgDn keys to skip over processors within the same device
- Bugfix: bitforce: Prefer 2nd temperature if higher than 1st
- When displaying device summary statlines, use the highest temperature reported by any processor
- Stratum: Fix nonce2 sizes greater than 4 and (on big-endian) smaller than 4
- bitforce: Manage TUI: Display both temperatures (if two), and enable changing fan speed
- opencl: Add fan speed to Manage device TUI now that it's been removed from statline
- DevAPI: Remove old statline APIs entirely, and add new override_statline_temp (used by modminer/x6500 for upload %)
- README: Update statlines
- TUI: Replace DevAPI statline_before with a predefined temperature column to free up statline space
- Refactor and simplify bin2hex to speed up and avoid unnecessary heap use
- stratum: Refactor work generation to do hex2bin conversions once, rather than every single header generated
- Implement bytes_t for generic binary data storage (including smart realloc-based resize)
- Bugfix: fpgautils: Only try to change baud rate when requested
- x6500: Provide manuf/product/serial to cgpu interface
- ztex: Provide manuf/product/serial to cgpu interface
- erupter: Use baud 115200 by default
- List valid baud rates once in iospeeds.h and standardize conversions
- TUI: Display device manufacturer/product/serial in Manage device screen, when available
- DevAPI: Store manufacturer/product/serial for each device
- fpgautils: detectone_meta_info to provide metainformation (manufacturer, product, serial) on devices to detectone functions
- Bugfix: fpgautils: Close product string file from sysfs (autodetect)
- erupter: New icarus-based driver to handle autodetection of Block Erupter devices
- Add --log-file option which redirects stderr to a file, but valid anywhere in the commandline or config file
- Detect staged work underruns and increase queue to avoid them
- Rewrite hex2bin to perform much faster (reduces minirig CPU usage by more than half!)
- README: Add condensed list of dependencies
- Enable "maintainer mode" by default
- Bugfix: opencl: TUI manage: "Change settings" must not be compiled in with no-ADL builds
- Bugfix: Detect whether the linker accepts -zorigin before attempting to use it
- opencl: ADL: ADL_Adapter_ID_Get fails with newer drivers, so tolerate its failure best we can
- opencl: Don't try to use BFI_INT patching with APP-SDK newer than 1084 (Catalyst 13.1), since it doesn't work
- fpgautils: Elaborate that bitstream open failures are probably due to missing bitstream package
- fpgautils: s/firmware/bitstream/
- Bugfix: Cleanup handling of complete device/driver failure
- Deprecate -C (enable CPU) and -G (disable GPU) options, now that -S drv:[no]auto can be used for the same purposes
- Bugfix: Since at least one of unix (or __APPLE__) or WIN32 is required by util.h, make sure unix is defined if WIN32 is not
- Bugfix: Set ELF rpath for bundled libblkmaker to use $ORIGIN so it can be run from other directories
- Bugfix: Cleanup needs to happen before printing the final quit message, or it gets lost in TUI mode
- Bugfix: fpgautils: Initialize my_dev_t instances with null bytes, to ensure random unused data cannot influence hash keys
- opencl: ManageTUI: Clear log cleanly for changing settings
- Remove "GPU management" TUI entirely
- opencl: Use new "Manage device" interface to do everything "GPU management" used to be used for
- DevAPI: Add interface for drivers to define custom "Manage device" options
- DevAPI: New function called to display additional processor information for "Manage devices"
- TUI: Add enable/disable commands to device management
- TUI: Implement beginnings of generic device management interface
- Bugfix: avalon: Fix LIFE_INIT2 setting
- Add LIFE_INIT2 status (safe to call functions, but not mining yet) for devices that want to report initialization status in their statline
- Bugfix: modminer: Only program once for --force-dev-init
- Bugfix: x6500: Only program once for --force-dev-init
- fpgautils: Workaround and document Xcode clang bug
- Bugfix: avalon: Correctly claim serial port
- Bugfix: -S all: Mac OS X needs to probe /dev/cu.*, not just /dev/cu.usb*
- cpu & opencl: Refuse to detect more than once
- cpu & opencl: Respect scan-serial auto/noauto instructions
- ft232r & libztex: Skip probe of claimed devices
- fpgautils: Check for devices being claimed before calling detectone from autodetectors
- x6500 & ztex: Claim USB devices
- fpgautils: Implement bfg_claim_usb for claiming devices by USB bus number and address
- fpgautils: Replace serial_claim with bfg_claim_serial using a more cleanly extensible interface and implementation
- fpgautils: serial_claim: Include a bus enum in hash key
- Add serial port claiming logic to avalon, bitforce, and modminer drivers
- RPC: "devscan" command to probe for new devices
- New (internal) scan_serial function to probe for new devices at runtime
- Split out per-cgpu temperature configuration code to load_temp_config_cgpu
- DevAPI: Modify add_cgpu to use temporary devices_new array, so detection can be done without touching live variables
- Move more cgpu initialization to allocate_cgpu
- Move devtype default assignment to allocate_cgpu
- Move cgpu startup routine to new start_cgpu function
- Move cgpu_info allocation to new allocate_cgpu function
- Move *.drv_detect calls to a new drv_detect_all function
- DevAPI: add_cgpu: There is no need to hold mutexes while creating devices
- Bugfix: cpu: Update device "kernel name" with auto-selected algorithm
- usbtest: Improve portability to at least 2.7 and 3.2
- usbtest: Avoid messing up the display by escaping weird bytes via repr()
- usbtest: Skip last 2 optional parameters, since we use the defaults and they are not in older versions of pyserial
- Bugfix: bitforce: ZOX limits results to 16 results per call, so repeat ZOX until there are fewer
- Bugfix: Initialization for bfgtls needs to be done in each thread
- Bugfix: stratum: Be patient with stratum lines that come in slower than we can process them
- Use bfg_strerror in locations previously just logging raw error numbers
- Bugfix: stratum: Log WSAGetLastError() for error number on recv failures on Windows
- Use bfg_strerror where it is already needed (for thread-safety)
- New thread-safe bfg_strerror function to portably stringify error codes
- Bugfix: bitforce_queue: Initialize buf2 so errors don't cause the work queue to flush
- TUI: Display percentage invalid of found nonces with hw errors
- Bugfix: modminer & x6500: Increment *->diff1 for all bad nonces
- percentf2 that takes t as precalculated total
- Keep track of bad nonces independently from generic hw errors
- inc_hw_errors: Resolve cgpu outside of mutex
- Use inc_hw_errors function at every site which increases hw_errors
|
|
|
|
chamber32
Newbie
Offline
Activity: 13
Merit: 0
|
|
July 08, 2013, 11:12:56 PM |
|
3.1.2 maxes out my CPU and gives me messages about killing & restarting OCL 0.
Running HD 6970 GPU on Win8 x64.
c32
|
|
|
|
Epoch
Legendary
Offline
Activity: 922
Merit: 1003
|
|
July 08, 2013, 11:15:33 PM |
|
Yes, 100% cpu here with 3.1.2. Sigh. Back to 3.1.1. Win7/32 version.
|
|
|
|
purelithium
|
|
July 08, 2013, 11:18:11 PM |
|
My 3 x6500 boards won't mine with 3.1.2 on windows, in the UI, it says: "XBS 0: Initializing..."for each device but doesn't program them, along with an error "ft232r_open: Error opening device" three times below in the scrolling text area(sorry can't think of what to call it). Also, My MMQ goes sick after about 1 minute. BlockEruptors seem fine. Here is what i get when running bfgminer.exe -D -T -d? -S all 2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 200 [2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 400 [2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 800 [2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 1000 [2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 2000 [2013-07-08 19:15:08] scan-serial: QueryDosDevice returned insufficent buffer error; enlarging to 4000 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM9 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM5 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM6 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM7 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM3 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM8 [2013-07-08 19:15:08] scan-serial: QueryDosDevice all-adding \\.\COM4 [2013-07-08 19:15:08] setrlimit: Not supported by platform [2013-07-08 19:15:08] Started bfgminer 3.1.2 [2013-07-08 19:15:08] ft232r_scan: Found 8086:27c8 - not a ft232r [2013-07-08 19:15:08] ft232r_scan: Found 8086:27ca - not a ft232r [2013-07-08 19:15:08] ft232r_scan: Found 8086:27cb - not a ft232r [2013-07-08 19:15:08] ft232r_scan: Found 8086:27c9 - not a ft232r [2013-07-08 19:15:08] ft232r_scan: Found 8086:27cc - not a ft232r [2013-07-08 19:15:08] ft232r_scan: Found "X6500 FPGA Miner" serial "AH01A6C9" [2013-07-08 19:15:08] ft232r_scan: Found "X6500 FPGA Miner" serial "AH01A6CQ" [2013-07-08 19:15:09] ft232r_scan: Found "X6500 FPGA Miner" serial "AH01A6CU" [2013-07-08 19:15:09] ft232r_scan: Found 0409:005a - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 0409:005a - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 0409:005a - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 05e3:0727 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 10c4:ea60 - not a ft232r [2013-07-08 19:15:09] ft232r_scan: Found 1fc9:0003 - not a ft232r [2013-07-08 19:15:09] CL Platform 0 vendor: NVIDIA Corporation [2013-07-08 19:15:09] CL Platform 0 name: NVIDIA CUDA [2013-07-08 19:15:09] CL Platform 0 version: OpenCL 1.0 CUDA 3.0.1 [2013-07-08 19:15:09] Platform 0 devices: 1 [2013-07-08 19:15:09] 0 ION [2013-07-08 19:15:09] Unable to load ati adl library [2013-07-08 19:15:09] FTD2XX.DLL failed to load, not using FTDI autodetect [2013-07-08 19:15:09] FTD2XX.DLL failed to load, not using FTDI autodetect [2013-07-08 19:15:09] FTD2XX.DLL failed to load, not using FTDI autodetect [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM9 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM9: got 000187a2 [2013-07-08 19:15:09] Found ICA 0 at \\.\COM9 [2013-07-08 19:15:09] ICA 0: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 0: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM5 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM5: got 000187a2 [2013-07-08 19:15:09] Found ICA 1 at \\.\COM5 [2013-07-08 19:15:09] ICA 1: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 1: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM6 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM6: got 000187a2 [2013-07-08 19:15:09] Found ICA 2 at \\.\COM6 [2013-07-08 19:15:09] ICA 2: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 2: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM7 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM7: got 000187a2 [2013-07-08 19:15:09] Found ICA 3 at \\.\COM7 [2013-07-08 19:15:09] ICA 3: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 3: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM3 [2013-07-08 19:15:09] Icarus Read: No data in 0.10 seconds [2013-07-08 19:15:09] Icarus Detect: Test failed at \\.\COM3: get 00000000, should: 000187a2 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM8 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM8: got 000187a2 [2013-07-08 19:15:09] Found ICA 4 at \\.\COM8 [2013-07-08 19:15:09] ICA 4: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 4: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] Icarus Detect: Attempting to open \\.\COM4 [2013-07-08 19:15:09] Icarus Detect: Test succeeded at \\.\COM4: got 000187a2 [2013-07-08 19:15:09] Found ICA 5 at \\.\COM4 [2013-07-08 19:15:09] ICA 5: Init: baud=115200 work_division=0 fpga_count=0 [2013-07-08 19:15:09] ICA 5: Init: mode=default read_count=50 Hs=2.640830e-009 [2013-07-08 19:15:09] BFL: Attempting to open \\.\COM3 [2013-07-08 19:15:10] BFL: Didn't recognise BitForce on \\.\COM3 [2013-07-08 19:15:10] FTD2XX.DLL failed to load, not using FTDI autodetect [2013-07-08 19:15:15] ModMiner identified as: ModMiner Quad v0.4-ljr-alpha [2013-07-08 19:15:15] ModMiner ModMiner Quad v0.4-ljr-alpha has 4 FPGAs [2013-07-08 19:15:16] Not a ZTEX device 8086:27c8 [2013-07-08 19:15:16] Not a ZTEX device 8086:27ca [2013-07-08 19:15:16] Not a ZTEX device 8086:27cb [2013-07-08 19:15:16] Not a ZTEX device 8086:27c9 [2013-07-08 19:15:16] Not a ZTEX device 8086:27cc [2013-07-08 19:15:16] Not a ZTEX device 0409:005a [2013-07-08 19:15:16] Not a ZTEX device 0409:005a [2013-07-08 19:15:16] Not a ZTEX device 0409:005a [2013-07-08 19:15:16] Not a ZTEX device 05e3:0727 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 10c4:ea60 [2013-07-08 19:15:16] Not a ZTEX device 1fc9:0003 [2013-07-08 19:15:16] libztex_scanDevices: Skipping probe of 3 claimed devices [2013-07-08 19:15:16] Devices detected: [2013-07-08 19:15:16] 0. OCL 0 (driver: opencl) [2013-07-08 19:15:16] 1. ICA 0 (driver: icarus) [2013-07-08 19:15:16] 2. ICA 1 (driver: icarus) [2013-07-08 19:15:16] 3. ICA 2 (driver: icarus) [2013-07-08 19:15:16] 4. ICA 3 (driver: icarus) [2013-07-08 19:15:16] 5. ICA 4 (driver: icarus) [2013-07-08 19:15:16] 6. ICA 5 (driver: icarus) [2013-07-08 19:15:16] 7. MMQ 0a: ModMiner Quad v0.4-ljr-alpha (driver: modminer) [2013-07-08 19:15:16] 8. MMQ 0b: ModMiner Quad v0.4-ljr-alpha (driver: modminer) [2013-07-08 19:15:16] 9. MMQ 0c: ModMiner Quad v0.4-ljr-alpha (driver: modminer) [2013-07-08 19:15:16] 10. MMQ 0d: ModMiner Quad v0.4-ljr-alpha (driver: modminer) [2013-07-08 19:15:16] 11. XBS 0a: X6500 FPGA Miner (driver: x6500) [2013-07-08 19:15:16] 12. XBS 0b: X6500 FPGA Miner (driver: x6500) [2013-07-08 19:15:16] 13. XBS 1a: X6500 FPGA Miner (driver: x6500) [2013-07-08 19:15:16] 14. XBS 1b: X6500 FPGA Miner (driver: x6500) [2013-07-08 19:15:16] 15. XBS 2a: X6500 FPGA Miner (driver: x6500) [2013-07-08 19:15:16] 16. XBS 2b: X6500 FPGA Miner (driver: x6500)
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
RoboCoder
|
|
July 08, 2013, 11:20:52 PM |
|
Actually this release has juiced my overall number of accepted shares on BFL devices especially Jally's - so i likee. I do have the same problem with the X6500's (havent tried on my ModMiners)
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 08, 2013, 11:53:00 PM |
|
Wow, shocked to see so many problems, it was working so well for me Please everyone, help debug this: 1. Open http://luke.dashjr.org/tmp/code/webisect/webisect.php2. Enter a unique session id (try your name and a random number; eg "Luke-Jr-4239042") 3. Change the versions to match what you know works and what doesn't work. eg "bfgminer-3.1.1" and "bfgminer-3.1.2" This gets your bisect session started. You will then be presented with a series of builds to test. Depending on various factors, it may take a few minutes to produce each build (this is automated). 4. Download the build 5. Test the build 6. Click good, bad, or skip (see descriptions next to the buttons) If you get another build, go back to step 4 and repeat with that one. Eventually, you will hit an end (it should take about 6 builds between 3.1.1 and 3.1.2). Post the final result here, along with a clear description of your problem. Thanks, Luke
|
|
|
|
purelithium
|
|
July 09, 2013, 02:07:28 AM |
|
I'll see what I can do after work tomorrow. It's just a pain because my Mining computer is headless.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
iongchun
Member
Offline
Activity: 75
Merit: 10
|
|
July 09, 2013, 07:06:18 AM |
|
I have also have 100% CPU usage problem with 3.1.2. After doing some "git bisect", the problem seems caused by this commit: 9484dc1a468a1e5323abc0ea0666c353ba7678d6 The previous commit 75b58b16a546deb4bb7ca25ca7520ec8788ddf2a and before is fine, after that all builds start with immediate 100% CPU usage.
|
Bitcoin: 1NFMpJUW7sTKmnVKj12MxhPvCvzAKQ5gUV Namecoin: N5Tnt3JyMeizsoAFAZDr7CSxjzDtPSisK8 Mining with P2Pool. Graph. Blocks.
|
|
|
iongchun
Member
Offline
Activity: 75
Merit: 10
|
|
July 09, 2013, 07:33:19 AM |
|
I have also have 100% CPU usage problem with 3.1.2. After doing some "git bisect", the problem seems caused by this commit: 9484dc1a468a1e5323abc0ea0666c353ba7678d6 The previous commit 75b58b16a546deb4bb7ca25ca7520ec8788ddf2a and before is fine, after that all builds start with immediate 100% CPU usage.
And if the first pool is not stratum, 3.1.2 will hangs on start.
|
Bitcoin: 1NFMpJUW7sTKmnVKj12MxhPvCvzAKQ5gUV Namecoin: N5Tnt3JyMeizsoAFAZDr7CSxjzDtPSisK8 Mining with P2Pool. Graph. Blocks.
|
|
|
bitcoindaddy
|
|
July 09, 2013, 12:15:28 PM |
|
I'm trying to get bfgminer to autostart in a screen session automatically on reboot on a raspberry pi. I'm using something like: su bfgmineruser -c "screen ....." in /etc/rc.local.
When I type these commands by hand, they work fine. When started automatically at boot, bfgminer starts in a screen session like it is supposed to, BUT it doesn't recognize the Jalepeno. It is not doing any GPU mining at all, there is only one device on it, the Jalepeno.
Any suggestions or ideas would be appreciated.
|
|
|
|
|