OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 151.

RoboCoder

sr. member

Activity: 388

Merit: 250

Save A Life, Adopt a Pet Today!

Quote from: bronan on July 09, 2013, 11:51:59 AM

currently testing bfg 3.1.2 on 2 x 7970 and am getting staged work underrun; not automatically increasing above 14 after it kept increasing the number till 14
any paramater which i can set in the config to give it more headroom ?
weird enough can not get 3.1.2 to run with the small jala, switched back to 3.1.1 which seems to run flawless
might have set wrong parameters in the .conf since i saw one posting his jala runs fine with 3.1.2
Are you using .conf to run bfg or do you run it plain with command line startup
Anyway when i start 3.1.2 it instant crash on my x64 win8

You can change it by using the Settings Menu, the Queue and put in the number you want for queued work.

bronan

hero member

Activity: 774

Merit: 500

Lazy Lurker Reads Alot

currently testing bfg 3.1.2 on 2 x 7970 and am getting staged work underrun; not automatically increasing above 14 after it kept increasing the number till 14
any paramater which i can set in the config to give it more headroom ?
weird enough can not get 3.1.2 to run with the small jala, switched back to 3.1.1 which seems to run flawless
might have set wrong parameters in the .conf since i saw one posting his jala runs fine with 3.1.2
Are you using .conf to run bfg or do you run it plain with command line startup
Anyway when i start 3.1.2 it instant crash on my x64 win8

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: flyonwall on July 09, 2013, 10:14:17 AM

Quote from: infamousdutch on July 08, 2013, 02:27:59 PM

Quote from: Luke-Jr on July 08, 2013, 01:26:00 AM

Quote from: flyonwall on July 08, 2013, 01: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?

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.

I didn't see that recommendation when I searched MSDN. Do you happen to have a link handy?

It may not be a bad idea to use STL, but I'm thinking if I do so, I might as well branch out to a full OO implementation. That would be quite an effort.

My only objective is to be able to spawn several instances of bfgminer on a system. Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of bfgminer on the same box where other users are running their own instance of bfgminer. Each bfgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow bfgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively.

I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source and GPL'd. If I were to do it, I would use VS, but if somebody else is willing to do it, it doesn't matter how it's done.

Sounds like the -d option should work fine for this...?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: bitcoindaddy on July 09, 2013, 07:15:28 AM

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.

My guess is the Jalapeno isn't booted when BFGMiner starts Wink

flyonwall

full member

Activity: 250

Merit: 100

RockStable Token Inc

Also, each bfgminer instance should be separately addressable in the RPC protocol/API.

Please PM me if you are interested in this multi-instance project. Thanks.

flyonwall

full member

Activity: 250

Merit: 100

RockStable Token Inc

Quote from: infamousdutch on July 08, 2013, 02:27:59 PM

Quote from: Luke-Jr on July 08, 2013, 01:26:00 AM

Quote from: flyonwall on July 08, 2013, 01: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?

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.

I didn't see that recommendation when I searched MSDN. Do you happen to have a link handy?

It may not be a bad idea to use STL, but I'm thinking if I do so, I might as well branch out to a full OO implementation. That would be quite an effort.

My only objective is to be able to spawn several instances of bfgminer on a system. Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of bfgminer on the same box where other users are running their own instance of bfgminer. Each bfgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow bfgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively.

I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source and GPL'd. If I were to do it, I would use VS, but if somebody else is willing to do it, it doesn't matter how it's done.

bitcoindaddy

hero member

Activity: 481

Merit: 500

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.

iongchun

member

Activity: 75

Merit: 10

Quote from: iongchun on July 09, 2013, 02: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.

And if the first pool is not stratum, 3.1.2 will hangs on start.

iongchun

member

Activity: 75

Merit: 10

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.

purelithium

hero member

Activity: 504

Merit: 500

I'll see what I can do after work tomorrow. It's just a pain because my Mining computer is headless.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Wow, shocked to see so many problems, it was working so well for me Sad

Please everyone, help debug this:
1. Open http://luke.dashjr.org/tmp/code/webisect/webisect.php
2. 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

RoboCoder

sr. member

Activity: 388

Merit: 250

Save A Life, Adopt a Pet Today!

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)

purelithium

hero member

Activity: 504

Merit: 500

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

Code:

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)

Epoch

legendary

Activity: 922

Merit: 1003

Yes, 100% cpu here with 3.1.2. Sigh. Back to 3.1.1. Win7/32 version.

chamber32

newbie

Activity: 13

Merit: 0

3.1.2 maxes out my CPU and gives me messages about killing & restarting OCL 0.

Running HD 6970 GPU on Win8 x64.

c32

Luke-Jr

legendary

Activity: 2576

Merit: 1186

NEW VERSION 3.1.2, JULY 8 2013

3.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 .
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

LGT06

newbie

Activity: 23

Merit: 0

Quote from: Luke-Jr on July 08, 2013, 02:51:40 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

legendary

Activity: 2576

Merit: 1186

Quote from: LGT06 on July 08, 2013, 02: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?

Up to 3.1.1: -G
3.1.2 and newer: -S opencl:noauto

LGT06

newbie

Activity: 23

Merit: 0

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?

infamousdutch

member

Activity: 105

Merit: 10

Quote from: Luke-Jr on July 08, 2013, 01:26:00 AM

Quote from: flyonwall on July 08, 2013, 01: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?

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.

Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 151. (Read 1193223 times)