Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected.

I'm seeing the same. 2xNanofury and 1xBitburner Fury. cgminer 3.10.0 just quits at random intervals. Running on Debian Wheezy on BeagleBone Black, and same issue on Debian Wheezy on PC. cgminer runs for days on the same machine when not running the Nanofurys.

I have a Ubuntu Linux server with all the current updates, running a variety of miners plugged into it on cgminer 3.10.0

I plugged a nanofury NF1 into a usb hub that has a few block erupters in it and the NF1 would only mine at just less than1GH/s.

I removed the block erupters and the NF1 started mining at full speed. Even if I add just one block erupter the NF1 instantly halves it's speed. The block erupter mines at full speed only the NF1 is effected, neither reports any errors that I can see.The power pack for the hub is 2.1Amps so it should be able to handle that, so I think it might be a conflict of some sort.

Erupters run at usb1.1 speed and protocol and perhaps are having some communication interaction making everything work in the same crap manner - depends greatly on how usb hubs manage different speed devices. Try them on separate hubs.

Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected. Same setup runs bfgminer fine.

I run cgminer in xubuntu 13.10 and with 1 in usb of laptop and the other nanofury in a anker usb hub and i have no crashing problems. In the same hub i have a bifury and a redfury and all run perfect.

I have a Ubuntu Linux server with all the current updates, running a variety of miners plugged into it on cgminer 3.10.0

I plugged a nanofury NF1 into a usb hub that has a few block erupters in it and the NF1 would only mine at just less than1GH/s.

I removed the block erupters and the NF1 started mining at full speed. Even if I add just one block erupter the NF1 instantly halves it's speed. The block erupter mines at full speed only the NF1 is effected, neither reports any errors that I can see.The power pack for the hub is 2.1Amps so it should be able to handle that, so I think it might be a conflict of some sort.

Erupters run at usb1.1 speed and protocol and perhaps are having some communication interaction making everything work in the same crap manner - depends greatly on how usb hubs manage different speed devices. Try them on separate hubs.

Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected. Same setup runs bfgminer fine.

I run cgminer in xubuntu 13.10 and with 1 in usb of laptop and the other nanofury in a anker usb hub and i have no crashing problems. In the same hub i have a bifury and a redfury and all run perfect.

How strange, I even tried editing the driver and reducing the number of bits in case it was being overclocked too much by default.I have tried Ubuntu 13.10 (on two machines) and Scientific Linux 6.4 and they all do it, my Nanofury is an NF1 as designed by vs3

I have a Ubuntu Linux server with all the current updates, running a variety of miners plugged into it on cgminer 3.10.0

I plugged a nanofury NF1 into a usb hub that has a few block erupters in it and the NF1 would only mine at just less than1GH/s.

I removed the block erupters and the NF1 started mining at full speed. Even if I add just one block erupter the NF1 instantly halves it's speed. The block erupter mines at full speed only the NF1 is effected, neither reports any errors that I can see.The power pack for the hub is 2.1Amps so it should be able to handle that, so I think it might be a conflict of some sort.

Erupters run at usb1.1 speed and protocol and perhaps are having some communication interaction making everything work in the same crap manner - depends greatly on how usb hubs manage different speed devices. Try them on separate hubs.

Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected. Same setup runs bfgminer fine.

I run cgminer in xubuntu 13.10 and with 1 in usb of laptop and the other nanofury in a anker usb hub and i have no crashing problems. In the same hub i have a bifury and a redfury and all run perfect.

How strange, I even tried editing the driver and reducing the number of bits in case it was being overclocked too much by default.I have tried Ubuntu 13.10 (on two machines) and Scientific Linux 6.4 and they all do it, my Nanofury is an NF1 as designed by vs3

I have a Ubuntu Linux server with all the current updates, running a variety of miners plugged into it on cgminer 3.10.0

I plugged a nanofury NF1 into a usb hub that has a few block erupters in it and the NF1 would only mine at just less than1GH/s.

I removed the block erupters and the NF1 started mining at full speed. Even if I add just one block erupter the NF1 instantly halves it's speed. The block erupter mines at full speed only the NF1 is effected, neither reports any errors that I can see.The power pack for the hub is 2.1Amps so it should be able to handle that, so I think it might be a conflict of some sort.

Erupters run at usb1.1 speed and protocol and perhaps are having some communication interaction making everything work in the same crap manner - depends greatly on how usb hubs manage different speed devices. Try them on separate hubs.

Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected. Same setup runs bfgminer fine.

I run cgminer in xubuntu 13.10 and with 1 in usb of laptop and the other nanofury in a anker usb hub and i have no crashing problems. In the same hub i have a bifury and a redfury and all run perfect.

How strange, I even tried editing the driver and reducing the number of bits in case it was being overclocked too much by default.I have tried Ubuntu 13.10 (on two machines) and Scientific Linux 6.4 and they all do it, my Nanofury is an NF1 as designed by vs3

Which particular problem are you talking about now? The slowdown with erupters (chek2fire confirmed it worked better by running the erupter on a separate hub). Or the crashing at random intervals (which as I said is due to a bug in 3.10.0 from effectively unplugging of the device when conditions are flaky which is fixed in git post 3.10.0).

Which particular problem are you talking about now? The slowdown with erupters (chek2fire confirmed it worked better by running the erupter on a separate hub). Or the crashing at random intervals (which as I said is due to a bug in 3.10.0 from effectively unplugging of the device when conditions are flaky which is fixed in git post 3.10.0).

I took your advice and kept the nanofury away from other usb devices, but that didn't fix the crashing problem. My subsequent tests were with the nanofury alone and I used the usbutils.c file from github. Are there any other files I also needed to replace from github?

/EDITOk, the plot thickens, the crash occurs after a stratum disconnect when the pool establishes contact again after a failover, normally you would get the testing stability message but it seg faults just before that gets displayed.

I tested it on a multi pool that does a short stratum disconnect every 20min when it coin switches, enough to trigger the failover.

I didn't mention any altcoins, I asked a simple question. One that I thought was within the topic. Also, I noticed I was demoted from member to newbie after doing so. classy. anyway, I'll avoid this thread. Have a wonderful day. Happy hashing.

I didn't mention any altcoins, I asked a simple question. One that I thought was within the topic. Also, I noticed I was demoted from member to newbie after doing so. classy. anyway, I'll avoid this thread. Have a wonderful day. Happy hashing.

No one affiliated with this thread has the ability to delete posts from it or demote you so whatever you saw was pure coincidence. Only forum and global mods could possibly do that.

Hey, I'm sorry for the missing log file and debugging etc. but I thought it was worth mentioning that:

ALL of my cgminer instances that were connected to BTC Guild, that is various versions from 3.0.x to the latest have crashed at the same time, approximately 06:31 GMT today 21 Jan 2014. I could see a "cannot parse output" and then a Segmentation Fault on the terminal just before crashing, while other instances just exited like they had received a SIGTERM, SIGKILL (or SIGSEGV?).

Even my Antminer S1 with factory built-in firmware running modified cgminer crashed, too. It also crashed on my KnC Miner, but this one is the only one that respawned automagically thanks to the init scripts and monitoring.

Has anyone else experienced this? I will cross-post it on BTC Guild topic. Thanks!

I didn't mention any altcoins, I asked a simple question. One that I thought was within the topic. Also, I noticed I was demoted from member to newbie after doing so. classy. anyway, I'll avoid this thread. Have a wonderful day. Happy hashing.

No one affiliated with this thread has the ability to delete posts from it or demote you so whatever you saw was pure coincidence. Only forum and global mods could possibly do that.

Ah, sorry to sound snarky then. I have had a long day and after checking this post I noticed the demotion, so may have reacted, instead of thinking things through more thoroughly. So it is probably coincidence etc. Anyways, the question I asked has since been clarified (a big bitcoin only on that one lol) So hopefully no one has taken offense, I was mayhaps a wee snippy as the reason I WAS asking was to be clear before making any posts, so as to keep anything on topic. Anyway, love cgminer, keep up the good work.

Ah, sorry to sound snarky then. I have had a long day and after checking this post I noticed the demotion, so may have reacted, instead of thinking things through more thoroughly. So it is probably coincidence etc. Anyways, the question I asked has since been clarified (a big bitcoin only on that one lol) So hopefully no one has taken offense, I was mayhaps a wee snippy as the reason I WAS asking was to be clear before making any posts, so as to keep anything on topic. Anyway, love cgminer, keep up the good work.

Turns out that 3.10.0 is crashing on the nanofury after a random period of time. Even on a separate linux box with nothing else connected.

I'm seeing the same. 2xNanofury and 1xBitburner Fury. cgminer 3.10.0 just quits at random intervals. Running on Debian Wheezy on BeagleBone Black, and same issue on Debian Wheezy on PC. cgminer runs for days on the same machine when not running the Nanofurys.

Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

This is the official thread for support and development of cgminer, the combined ASIC & FPGA bitcoin miner written in c, cross platform for windows, linux and OSX, with monitoring, fanspeed control and remote interface capabilities, completely overhauled based on the original code cpuminer.

This code is provided entirely free of charge by the programmer in his sparetime so donations would be greatly appreciated.

Note that I can NOT provide personalised support via email or personal messages under normal circumstances so they will usually be ignored.Apologies, but the demand is just far too great and I must prioritise my time.

Discarded work due to new blocks: 0Stale submissions discarded due to new blocks: 9Unable to get work from server occasions: 16Work items generated locally: 330Submitting work remotely delay occasions: 33New blocks detected on network: 10

Options for both config file and command line:--api-allow Allow API access (if enabled) only to the given list of [W:]IP[/Prefix] address[/subnets] This overrides --api-network and you must specify 127.0.0.1 if it is required W: in front of the IP address gives that address privileged access to all api commands--api-description Description placed in the API status header (default: cgminer version)--api-groups API one letter groups G:cmd:cmd[,P:cmd:*...] See API-README for usage--api-listen Listen for API requests (default: disabled) By default any command that does not just display data returns access denied See --api-allow to overcome this--api-network Allow API (if enabled) to listen on/for any address (default: only 127.0.0.1)--api-mcast Enable API Multicast listener, (default: disabled) The listener will only run if the API is also enabled--api-mcast-addr <arg> API Multicast listen address, (default: 224.0.0.75)--api-mcast-code <arg> Code expected in the API Multicast message, don't use '-' (default: "FTW")--api-mcast-port <arg> API Multicast listen port, (default: 4028)--api-port Port number of miner API (default: 4028)--balance Change multipool strategy from failover to even share balance--benchmark Run cgminer in benchmark mode - produces no shares--compact Use compact display without per device statistics--debug|-D Enable debug output--device|-d <arg> Select device to use, one value, range and/or comma separated (e.g. 0-2,4) default: all--disable-rejecting Automatically disable pools that continually reject shares--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)--failover-only Don't leak work to backup pools when primary pool is lagging--fix-protocol Do not redirect to a different getwork protocol (eg. stratum)--hotplug <arg> Set hotplug check time to <arg> seconds (0=never default: 5) - only with libusb--kernel-path|-K <arg> Specify a path to where bitstream files are (default: "/usr/local/bin")--load-balance Change multipool strategy from failover to quota based balance--log|-l <arg> Interval in seconds between log output (default: 5)--lowmem Minimise caching of shares for low memory applications--monitor|-m <arg> Use custom pipe cmd for output messages--net-delay Impose small delays in networking to not overload slow routers--no-submit-stale Don't submit shares if they are detected as stale--pass|-p <arg> Password for bitcoin JSON-RPC server--per-device-stats Force verbose mode and output per-device statistics--protocol-dump|-P Verbose dump of protocol-level activities--queue|-Q <arg> Minimum number of work items to have queued (0 - 10) (default: 1)--quiet|-q Disable logging output, display status and errors--real-quiet Disable all output--remove-disabled Remove disabled devices entirely, as if they didn't exist--rotate <arg> Change multipool strategy from failover to regularly rotate at N minutes (default: 0)--round-robin Change multipool strategy from failover to round robin on failure--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60)--sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time)--sched-stop <arg> Set a time of day in HH:MM to stop mining (will quit without a start time)--sharelog <arg> Append share log to file--shares <arg> Quit after mining N shares (default: unlimited)--socks-proxy <arg> Set socks4 proxy (host:port) for all pools without a proxy specified--syslog Use system log for output messages (default: standard error)--temp-cutoff <arg> Temperature where a device will be automatically disabled, one value or comma separated list (default: 95)--text-only|-T Disable ncurses formatted screen output--url|-o <arg> URL for bitcoin JSON-RPC server--user|-u <arg> Username for bitcoin JSON-RPC server--verbose Log verbose output to stderr as well as status output--userpass|-O <arg> Username:Password pair for bitcoin JSON-RPC serverOptions for command line only:--config|-c <arg> Load a JSON-format configuration fileSee example.conf for an example configuration.--help|-h Print this message--version|-V Display version and exit

USB device (ASIC and FPGA) options:

--icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated--icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated--usb <arg> USB device selection (See below)--usb-dump (See FPGA-README)

Each column is as follows:5s: A 5 second exponentially decaying average hash rateavg: An all time average hash rateA: The number of Accepted sharesR: The number of Rejected sharesHW: The number of HardWare errorsWU: The Work Utility defined as the number of diff1 equivalent shares / minute

Each column is as follows:Temperature (if supported)Fanspeed (if supported)A 5 second exponentially decaying average hash rateAn all time average hash rateThe number of accepted sharesThe number of rejected sharesThe number of hardware erorrsThe Work Utility defined as the number of diff1 equivalent shares / minute

TQ is Total Queued work items.ST is STaged work items (ready to use).SS is Stale Shares discarded (detected and not submitted so don't count as rejects)DW is Discarded Work items (work from block no longer valid to work on)NB is New Blocks detected on the networkLW is Locally generated Work itemsGF is Getwork Fail Occasions (server slow to provide work)RF is Remote Fail occasions (server slow to accept work)

---MULTIPOOL

FAILOVER STRATEGIES WITH MULTIPOOL:A number of different strategies for dealing with multipool setups areavailable. Each has their advantages and disadvantages so multiple strategiesare available by user choice, as per the following list:

FAILOVER:The default strategy is failover. This means that if you input a number ofpools, it will try to use them as a priority list, moving away from the 1stto the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it willmove back to the higher priority ones.

ROUND ROBIN:This strategy only moves from one pool to the next when the current one fallsidle and makes no attempt to move otherwise.

ROTATE:This strategy moves at user-defined intervals from one active pool to the next,skipping pools that are idle.

LOAD BALANCE:This strategy sends work to all the pools to maintain optimum load. The mostefficient pools will tend to get a lot more shares. If any pool falls idle, therest will tend to take up the slack keeping the miner busy.

BALANCE:This strategy monitors the amount of difficulty 1 shares solved for each pooland uses it to try to end up doing the same amount of work for all pools.

---LOGGING

cgminer will log to stderr if it detects stderr is being redirected to a file.To enable logging simply add 2>logfile.txt to your command line and logfile.txtwill contain the logged output at the log level you specify (normal, verbose,debug etc.)

In other words if you would normally use:./cgminer -o xxx -u yyy -p zzzif you use./cgminer -o xxx -u yyy -p zzz 2>logfile.txtit will log to a file called logfile.txt and otherwise work the same.

There is also the -m option on linux which will spawn a command of your choiceand pipe the output directly to that command.

If you start cgminer with the --sharelog option, you can get detailedinformation for each share found. The argument to the option may be "-" forstandard output (not advisable with the ncurses UI), any valid positive numberfor that file descriptor, or a filename.

For every share found, data will be logged in a CSV (Comma Separated Value)format: timestamp,disposition,target,pool,dev,thr,sharehash,sharedataFor example (this is wrapped, but it's all on one line for real): 1335313090,reject, ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000, http://localhost:8337,GPU0,0, 6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000, 00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5 000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498 f681634a4f1f63d01a0cd43fb338000000000080000000000000000000000000 0000000000000000000000000000000000000000000000000000000080020000

---

RPC API

For RPC API details see the API-README file

---

FAQ

Q: Can I mine on servers from different networks (eg xxxcoin and bitcoin) atthe same time?A: No, cgminer keeps a database of the block it's working on to ensure it doesnot work on stale blocks, and having different blocks from two networks wouldmake it invalidate the work from each other.

Q: Can I configure cgminer to mine with different login credentials or poolsfor each separate device?A: No.

Q: Can I put multiple pools in the config file?A: Yes, check the example.conf file. Alternatively, set up everything either onthe command line or via the menu after startup and choose settings->writeconfig file and the file will be loaded one each startup.

Q: The build fails with gcc is unable to build a binary.A: Remove the "-march=native" component of your CFLAGS as your version of gccdoes not support it.

Q: Can you implement feature X?A: I can, but time is limited, and people who donate are more likely to gettheir feature requests implemented.

Q: Work keeps going to my backup pool even though my primary pool hasn'tfailed?A: Cgminer checks for conditions where the primary pool is lagging and willpass some work to the backup servers under those conditions. The reason fordoing this is to try its absolute best to keep the GPUs working on somethinguseful and not risk idle periods. You can disable this behaviour with theoption --failover-only.

Q: Is this a virus?A: Cgminer is being packaged with other trojan scripts and some antivirussoftware is falsely accusing cgminer.exe as being the actual virus, ratherthan whatever it is being packaged with. If you installed cgminer yourself,then you do not have a virus on your computer. Complain to your antivirussoftware company. They seem to be flagging even source code now from cgmineras viruses, even though text source files can't do anything by themself.

Q: Can you modify the display to include more of one thing in the output andless of another, or can you change the quiet mode or can you add yet anotheroutput mode?A: Everyone will always have their own view of what's important to monitor.The defaults are very sane and I have very little interest in changing thisany further.

Q: What are the best parameters to pass for X pool/hardware/device.A: Virtually always, the DEFAULT parameters give the best results. Most userdefined settings lead to worse performance. The ONLY thing most users shouldneed to set is the Intensity for GPUs.

Q: What happened to CPU and GPU mining?A: Their efficiency makes them irrelevant in the bitcoin mining world todayand the author has no interest in supporting alternative coins that are bettermined by these devices.

Q: I'm having an issue. What debugging information should I provide?A: Start cgminer with your regular commands and add -D -T --verbose and providethe full startup output and a summary of your hardware and operating system.

Q: Why don't you provide win64 builds?A: Win32 builds work everywhere and there is precisely zero advantage to a64 bit build on windows.

Q: Is it faster to mine on windows or linux?A: It makes no difference. It comes down to choice of operating system fortheir various features. Linux offers much better long term stability andremote monitoring and security, while windows offers you overclocking toolsthat can achieve much more than cgminer can do on linux.

Q: My network gets slower and slower and then dies for a minute?A; Try the --net-delay option.

Q: How do I tune for p2pool?A: It is also recommended to use --failover-only since the work is effectivelylike a different block chain, and not enabling --no-submit-stale. If mining witha BFL (fpga) minirig, it is worth adding the --bfl-range option.

Q: What is a PGA?A: At the moment, cgminer supports 3 FPGAs: BitForce, Icarus and ModMiner.They are Field-Programmable Gate Arrays that have been programmed to do Bitcoinmining. Since the acronym needs to be only 3 characters, the "Field-" part hasbeen skipped.

Q: What is an ASIC?A: They are Application Specify Integrated Circuit devices and provide thehighest performance per unit power due to being dedicated to only one purpose.

Q: Can I mine scrypt with FPGAs or ASICs?A: No.

Q: What is stratum and how do I use it?A: Stratum is a protocol designed for pooled mining in such a way as tominimise the amount of network communications, yet scale to hardware of anyspeed. With versions of cgminer 2.8.0+, if a pool has stratum support, cgminerwill automatically detect it and switch to the support as advertised if it can.If you input the stratum port directly into your configuration, or use thespecial prefix "stratum+tcp://" instead of "http://", cgminer will ONLY try touse stratum protocol mining. The advantages of stratum to the miner are nodelays in getting more work for the miner, less rejects across block changes,and far less network communications for the same amount of mining hashrate. Ifyou do NOT wish cgminer to automatically switch to stratum protocol even if itis detected, add the --fix-protocol option.

Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,Diff1 Work, etc. when mining greater than 1 difficulty shares?A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the numberof difficulty shares accepted does not usually exactly equal the amount of workdone to find them. If you are mining at 8 difficulty, then you would expect onaverage to find one 8 difficulty share, per 8 single difficulty shares found.However, the number is actually random and converges over time, it is an average,not an exact value, thus you may find more or less than the expected average.

Q: My keyboard input momentarily pauses or repeats keys every so often onwindows while mining?A: The USB implementation on windows can be very flaky on some hardware andevery time cgminer looks for new hardware to hotplug it it can cause thesesorts of problems. You can disable hotplug with:--hotplug 0

Q: What should my Work Utility (WU) be?A: Work utility is the product of hashrate * luck and only stabilises over avery long period of time. Assuming all your work is valid work, bitcoin miningshould produce a work utility of approximately 1 per 71.6MH. This means at5GH you should have a WU of 5000 / 71.6 or ~ 69. You cannot make your machinedo "better WU" than this - it is luck related. However you can make it muchworse if your machine produces a lot of hardware errors producing invalid work.

---

This code is provided entirely free of charge by the programmer in his sparetime so donations would be greatly appreciated. Please consider donating to theaddress below.

I am running cgminer 3.7.2 on Mac Book Pro Mac OSX 10.5 and get following error "dyld: unknown required load command 0x80000022 Trace/BPT Trap".I know its an old version of Mac machine but its lying unused and want to start GPU mining with this.

I am running cgminer 3.7.2 on Mac Book Pro Mac OSX 10.5 and get following error "dyld: unknown required load command 0x80000022 Trace/BPT Trap".I know its an old version of Mac machine but its lying unused and want to start GPU mining with this.

Help appreciated.

RegardsKamyb

GPU mining requires OpenCL which wasn't added to Mac OS X until 10.6. You may be able to mine with USB-based devices on your 10.5 machine though.

Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

I can confirm this bug, but for me this appears seldom.

I also have problems with another pool: http://elizium.name/ (p2pool). After minutes I get: ./cgminer: double free or corruption (!prev): 0x0a01f120 *** with backtrace.