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

Do you face this problem only with bfgminer? Your jalapeno might suffer from insufficient cooling.

Thanks for the new version.

The "Intensity < 0 = 100% CPU" Issue ist still there.
I have upgraded to APP SDK 2.5 to see if it would make any difference but it does not.

Is there anything I could do to have less GPU usage while not maxing CPU usage?

EDIT: To answer my question: Everything works fine when I set "gpu-threads" : "1", in the conf file.
I have tried: "bfgminer -g 1 -I -5" but it is completely ignored when a .conf file is present.

using bfgminer 3.1.1, I get around 11% HW-erros with my Jalapeno.
is this normal? I gander it's not.

what to do, what to do?

edit: I have 8 Erupters on another BFGminer instance.

OCL is the GPU stuff. Try disabling it with -G

I am trying to set up a BFL ASIC single for a friend.  I have worked on it for maybe 4 or 5 hours now and can't figure out how to get it working.  I have tried my best to find the answer on my own, but I've reached my limit.  It's time to ask the community, so here it goes:

I am using Mac OSX 10.7

I invoke cgminer with the following command:
/Applications/MacMiner.app/Contents/Resources/bfgminer/bin/bfgminer -S /dev/cu.usbserial-00002026 -o stratum+tcp://stratum.mining.eligius.st:3334 -O MyBitcoinAddress

Running the command "ls /dev/cu.*" in terminal shows "/dev/cu.usbserial-00002026" as one of the devices.

I get the following error:
 [2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
 [2013-06-23 20:34:10] OCL 0 failure, attempting to reinitialize
 [2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
 [2013-06-23 20:34:10] OCL 0 failure, disabling!
 [2013-06-23 20:34:10] OCL 0 (thread 0) being disabled
 [2013-06-23 20:34:10] Error -54: Enqueueing kernel onto command queue. (clEnque
ueNDRangeKernel)
 [2013-06-23 20:34:10] OCL 0 failure, attempting to reinitialize
 [2013-06-23 20:34:10] OCL 0 (thread 1) being disabled

If I leave it running it gives me more of the same errors.

As I said before, I have spent hours trying to figure this out on my own, so I think I am clear of the accusation of being a help vampire.  Someone with better Googleing skills could probably figure it out pretty quickly.

Thanks in advance for the help

Up and mining with bfgminer-3.1.1-win64.  Thanks Luke.

NEW VERSION 3.1.1, JUNE 22 2013

Human readable changelog:

• bitforce: Support for Little Single boards, and Jalapenos with 1.2 firmware.
• avalon: Support new overclocking speeds (325, 350 and 375).
• Fixed a bunch of bugs, including GPU mining and at least one stratum-related crash.
• Windows: Now compiled with debugging information and new backtrace.dll to print usable backtraces to stderr on crash.

Full changelog

• stratum: Deliver exact socket-error within the debug error message
• Don't install docs for (compile-time) disabled functionality
• Bugfix: Handle make dependencies on subdirectory files properly
• Bugfix: Use EXTRA_*_DEPENDENCIES for Cygwin workaround, to fix program make dependencies
• Support new overclocking speeds for avalon: 325, 350 and 375
• Bugfix: logging: Since we are inlining snprintf, stdio.h is needed
• Bugfix: serial_autodetect_ftdi: Debuglog FTDI COM port mappings returned, fix type of FT_HANDLE
• Bugfix: Allow starting non-libusb devices if libusb_init fails
• Bugfix: Add missing newline to libusb_init failure message
• Bugfix: opencl: Remove unnecessary casts from rot() macro, which created type issues
• Bugfix: Remove unused variables
• Suspend stratum connections when we know they've failed and don't try to recv data from them once the socket no longer exists.
• applog/quit fix GPU errors created
• logging remove extra added
• remove varargs from logging/quit/in general as much as possible
• compile unix code on Mac OS X fixes not finding the config file in $HOME
• Create a pool_localgen bool function for testing when a pool can generate work locally.
• Use mining start time for device MH/U calculations
• Bugfix: Save start time for stats to correct "Elapsed" key on "stats" RPC request
• modminer: tidy up free in device detect function
• bitforce: RPC pgaset fanmode 9 for auto fan control
• Bugfix: usbtest: Correct obvious typos
• Initial import of usbtest.py script
• Include microseconds in log output with new --log-microseconds option
• bitforce: Workaround chip ids not necessarily being in order by choosing processor count based on expected chip ids rather than parallelization
• serial_autodetect_ftdi: Debuglog FTDI COM port mappings returned
• Bugfix: On stratum disconnect, clear stratum_active and stratum_notify atomically along with sock
• Windows: Use backtrace.dll to print usable backtraces to stderr on crash
• Bugfix: bitforce: parallelized: Properly handle parallelized protocol with only 1 chip
• Bugfix: bitforce: XLINK: Increment boardno when moving on to the next board
• bitforce: XLINK: Update to use actual length,xlinkid header order
• Bugfix: bitforce: XLINK: Avoid trying to send 0 bytes after each write
• Bugfix: opencl: Build fpgautils even if OpenCL is the only driver, now that it uses it for kernel-finding
• Bugfix: Do not try to call get_stats or get_statline* if device is still initializing
• Bugfix: opencl: Add missing include for fpgautils.h (needed for open_bitstream)

Hey Luke, if you are still there I have a question.  I am trying to set up bfgminer with my new BFL single SC.  I am not having any luck.  I had changed the driver to try to set up cgminer but couldn't figure out how to compile a configuration file to enable bflsc.  Anyway, I rolled back the driver because I read where you mentioned that.  I got the driver rolled back but I can't get bfgminer to work.  I haven't got anything to work when I try a conf file so I went back to none.  The best I got was it wouldn't accept any of my three mining sites saying the url was wrong.  It never did see any of my mining hardware.  Anyway, like I said I went back to the original without doing a conf file.  Now it won't start and I am not sure what to do.     
     Oh, I did do a bat file like BFL recommends but that is where it says my urls are wrong even though I can use the same three urls with cgminer with my video cards and fpga, just not the asic.

Ok thanks luke gonna try to get it running tommorow on this machine again
Hopefully i get it working
Meanwhile i let it run on the old machine, hopefully the wfie does not turn it off :S

This looks fine to me. What's the problem?

You don't want the WinUSB driver for BFL devices. Uninstall that first.
FTDI's current official driver has problems with USB 3 ports.
If it's already installed, you will need to use their CDM_Uninstaller to remove it completely. Put VID 0403 and clear PID (it should be blank); add it to the list and uninstall.
Once that's done, the simple workaround is to use a USB 2 hub (or port) the first time you plug each device in.
After the device has installed correctly, you should be safe to move it back to a USB 3 port/hub.

Sorry if this is off-subject. When I received my erupters, I tried using CGminer 3.1.1.1 and 3.2.1. Trying various configs with each version always resulted in machine seizure, sometimes in as little as 20 min and sometimes after 5-6 hours.

I gave up and switched to bfgminer 3.1.0 and no crashes, thank you! However during my atempts to get cgminer working, I had tried uninstalling and re-installing the SiLabs VCP driver several times. Each time the COM port numbers advanced till now I'm up to COM14-19. Is there any way to remove all the extra COM ports and get back to COM3 --> onward? TIA.
 

Thank you for the quit answer Luke

F:\Easy Miner\bfgminer>bfgminer -G -D -T -d?
[2013-06-21 22:59:36] setrlimit: Not supported by platform
[2013-06-21 22:59:36] ft232r_scan: Found 15c2:ffdc - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4396 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4396 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4399 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4398 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4397 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4398 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 050d:815f - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 0403:6014 - not a ft232r

[2013-06-21 22:59:36] ft232r_scan: Found 1002:4397 - not a ft232r

[2013-06-21 22:59:36] Started bfgminer 3.1.0
[2013-06-21 22:59:36] FTDI reports 1 devices
[2013-06-21 22:59:36] FTDI reports 1 devices
[2013-06-21 22:59:36] BFL: Attempting to open \\.\COM3
[2013-06-21 22:59:36] Found BitForce device on \\.\COM3
[2013-06-21 22:59:37]   DEVICE: BitFORCE SC
[2013-06-21 22:59:37]   FIRMWARE: 1.0.0
[2013-06-21 22:59:37]   MINIG SPEED: 5.13 GH/s
[2013-06-21 22:59:37]   PROCESSOR 3: 14 engines @ 182 MHz
[2013-06-21 22:59:37]   PROCESSOR 7: 13 engines @ 200 MHz
[2013-06-21 22:59:37]   ENGINES: 27
[2013-06-21 22:59:37]   FREQUENCY: 189 MHz
[2013-06-21 22:59:37]   XLINK MODE: MASTER
[2013-06-21 22:59:37]   CRITICAL TEMPERATURE: 0
[2013-06-21 22:59:37]   XLINK PRESENT: NO
[2013-06-21 22:59:37] FTDI reports 1 devices
[2013-06-21 22:59:37] Not a ZTEX device 15c2:ffdc
[2013-06-21 22:59:37] Not a ZTEX device 1002:4396
[2013-06-21 22:59:37] Not a ZTEX device 1002:4396
[2013-06-21 22:59:37] Not a ZTEX device 1002:4399
[2013-06-21 22:59:37] Not a ZTEX device 1002:4398
[2013-06-21 22:59:37] Not a ZTEX device 1002:4397
[2013-06-21 22:59:37] Not a ZTEX device 1002:4398
[2013-06-21 22:59:37] Not a ZTEX device 050d:815f
[2013-06-21 22:59:37] Not a ZTEX device 0403:6014
[2013-06-21 22:59:37] Not a ZTEX device 1002:4397
[2013-06-21 22:59:37] Devices detected:
[2013-06-21 22:59:37]   0. BFL 0  (driver: bitforce_queue)
 devices listed

F:\Easy Miner\bfgminer>

This is the output i get when i give the command in the easyminer\bfgminer map
Its actually connected to my old htpc at the moment since it does not work at all on my new intel i7 system even if i install any of them given winsub drivers
The new machine has many usb3 ports i am not sure if this is the reason why it totally fails to see the device even though its clearly listed in the usb devices under hardware.

Is this with BFGMiner version 3.1.0? Can you post the output from

I received a jalapeno mini miner from bfl and run into some weird problems
To recover some of the stolen btc and the financial losses with buying from BFL
So i decided to mine enough to get a better miner someday

When i use the easyminer software i can run it on some pools and seem to run ok but kinda sluggish

Now comes the idiot part when i use cgminer or bfgminer from a command batch it simply does not find the asic miner
So i start the easyminer crap and poof it runs again.
For parameters i used the help provided on eligius wiki and help pages

I do not want the miners to use any gpu they find since that would kill any income considering the electircal costs in my country for little extra hashes

bfgminer -G -o stratum+tcp://stratum.mining.eligius.st:3334 -O my btc address

for the other i used cgminer -o http://stratum.mining.eligius.st:3334 -u address -p x -G

When i start both it takes a while to start and then i get the message no comm devices detected.

So i took another test with bitminter client and guess what: it simply runs instant without any problem

Thanks, this was just what I was looking for!  Just now got my cute little Erupter up and running.  It worked the first time!

I'm running P2Pool, so my payout address and bitcoind RPC username/password are not set here, they're in P2Pool instead.  Here's my command line, in case it helps others:


Edit: I donated!  Much thanks, very nice and powerful program.

Josh

-S all is sufficient if the driver is in order.

I'm not missing the driver. Each time ubuntu updates it makes a new kernel version folder. each with a  build and updates folder. The original kernel folder has all the drivers and etc....

I rebooted and ran bfgminer again with -S /dev/ttyUSB0 and it appears to still be using my GPU. What flags do I need to use to make it use the block erupter? I've googled all day and can't find any clear instructions for linux. Plenty for Windoze 7 though.

Linux is a a monolithic kernel. So its "drivers" are technically builtin, even if they're loaded at runtime.
This means you cannot use a driver compiled for any other version, with the current one; it must be the matching version.
Where did you get your kernel from that it is missing the driver? :/

Could you check, why I cannot add stratum pool through API?

This stratum pool is added but it is DEAD. When I add pool from bfgminer GUI, it is OK, pool is ALIVE. When I add getwork pool from API, it is ALIVE.

Another example of pool that is DEAD when added through API:

and I see this error in bfgminer:


UPDATE:
I found that when I add stratum pool with echo -n "addpool|URL,USER,PASS", it is ALIVE. It means, that trailing newline was troublemaker; I still don't understand, why trailing newline was problem for stratum but was working fine for getwork. And why it was problem for stratum, because password is not important in my examples and newline was added to password that was the last parameter in the line....

Correct code looks like this:

I've been using bfgminer for GPU mining for several months now and it's been working great. I have a new question. I looked at the ReadMe and didn't see what I was looking for. I'm sure this has been asked a million times, but I'm still nooby.

I got an asicminer block erupter yesterday. Can I set up bfgminer to use it and my gpu together? I'd like to get both hashing, just not sure what I need to do to do it.

Should I run 2 instances of bfgminer: one for the asic, and one for the gpu? Trying to get my head around this. Any help would be great.

Also, I'm running Ubuntu 13.04. I know I have to put -s in the command line, but do I have to put anything else in?

Edit: using -s /dev/ttyUSB(#) gives error /dev/ttyUSB(#) is not a number.(Yes, I'm using the number of my port for (#))  

Edit 2: I got bfgminer to start by using the -S /dev/ttyUSB0 flag, but it's not mining anything. I looked around in my folders and the usb to uart bridge drivers(cp210x.ko in linut) are in the "3.8.0-19-generic" directory, but not in the newer kernel directories. Does this make a difference? Shouldn't it access it from the previous kernel directories? I'm at a loss here. I'd like to get this block erupter hashing.