OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[hahahafr]

Question: Did the cgminer developers receive their BFL Single SC development unit?

[-ck]

Question: Did the cgminer developers receive their BFL Single SC development unit?

Not yet, no

[-ck]

I tried to setup my PC/GPU for doing LTC scrypt mining yesterday, following the directions here https://asktom.cf/index.php?topic=83371.0, here https://asktom.cf/index.php?topic=83371.msg1733884;topicseen#msg1733884, and here https://asktom.cf/index.php?topic=97143.0.

I installed the Litecoin client, setup a mining pool account with WeMineLTC, and was able to compile the cgminer tool, so I should have all of the necessary software tools installed. However, I have two different types of errors that occur:

[snip]

 [2013-06-15 23:50:31] Error -55: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
 [2013-06-15 23:50:31] GPU 0 failure, disabling!

The miner is never starting successfully. Your choice of driver and sdk simply isn't working with your hardware, so you'll need to start from scratch with those... as it says in the GPU README.

[macboy80]

***Insert standard "I tried to search" disclaimer***

I am getting an error with cgminer 3.2.1; windows7 x64; BFL Jalapeno: "Waiting for USB hotplug devices or press q to quit" I have installed the winUSB drivers. The Jalapeno works fine with BFGminer and the other drivers. Does anyone have any suggestions, as I would prefer to use cgminer?

This has been discussed allot.  Just look back in a few of the recent pages.

A couple of folks have changed the code to add a longer wait and the authors have it fixed in the git tree.  But the fix hasn't been released yet.  So you can compile the code yourself and test it or wait for the next release.
Sam

Thanks for the quick reply. I wasn't sure that the wait time issue was related to detecting the device. I will wait patiently for the next release.

EDIT:
With a nudge from conman on the IRC. I was able to get it working. Apparently, the timing issue doesn't exist on windows. I did the following (in case anyone has this problem) :
1) I extracted zadig from the .zip. Previously, I was running from the archive.
2) I unplugged the Jalapeno first, then installed the WCID driver, then pluged the jally in, then installed winUSB.

Hope this helps.

[rudrigorc2]

the host is a 703N router

Im following the http://ck.kolivas.org/apps/cgminer/README and after running  cgminer -n  I get this:

Code:

 [2013-06-16 04:33:14] USB all: found 27 devices - listing known devices
.USB dev 0: Bus 1 Device 27 ID: 0403:6001
  Manufacturer: 'FTDI'
  Product: 'FT232R USB UART'                    
 [2013-06-16 04:33:14] 1 known USB devices

running cgminer:

Code:

[[2013-06-16 04:46:58] Started cgminer 3.2.1                    
 [2013-06-16 04:46:58] SEM: avalon USB failed to get (98307) '/tmp/cgminer-usb-1-27' - device in use                    
 [2013-06-16 04:46:58] No devices detected!                    
 [2013-06-16 04:46:58] Waiting for USB hotplug devices or press q to quit                    
 [2013-06-16 04:46:58] Probing for an alive pool                    
^C [2013-06-16 04:46:59] Shutdown signal received.

Im want a way to avoid searching for the avalon device, seems cgminer finds the usb devices but cant mine

so tried cgminer --usb AVA:0
cgminer stops looking for an avalon; now I need it to recognize the fpgas

--usb AVA:0,ICA:5

 [2013-06-16 04:51:39] Started cgminer 3.2.1                  
 [2013-06-16 04:51:39] Invalid --usb DRV:limit - unknown DRV='ICA'            

[loshia]

Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash).
It looks there are more HW errors, but I'm not 100% sure.

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

Con,

Will you be so kind to comment this:

https://asktom.cf/index.php?topic=140539.msg2489565#msg2489565

10X

[-ck]

Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash).
It looks there are more HW errors, but I'm not 100% sure.

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

Con,

Will you be so kind to comment this:

https://asktom.cf/index.php?topic=140539.msg2489565#msg2489565

10X

Just looks like variance, however the good news is I found somewhere to boost the hashrate on avalon ever so slightly on the next version anyway.

[mishax1]

question here,

how does cgminer determines "Discarded work" ? (besides the words that say "work from block no longer valid to work on")

and could a long route / high ping / distance to the pool reflect on it ?

just want to figure out how does a 30% discarded work is different than a 0% discarded work (while both pools use stratum)..  

[loshia]

Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash).
It looks there are more HW errors, but I'm not 100% sure.

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

Con,

Will you be so kind to comment this:

https://asktom.cf/index.php?topic=140539.msg2489565#msg2489565

10X

Just looks like variance, however the good news is I found somewhere to boost the hashrate on avalon ever so slightly on the next version anyway.

Super!
I am eager to test it. It is about time for me to start building custom avalon Images:)

I will post my results.
thank you very much!

[-ck]

New version: 3.2.2, 16th June 2013

More bugfixes for the 3.2 series. Hopefully getting close to being stable enough to not call 3.1.1 the latest stable version. USB3 hubs with multiple devices may still be problematic - please give feedback! For those who have not yet moved to the 3.2 series yet, I will remind you to please take note that the USB device driver model in cgminer has completely changed and windows users should use zadig to convert their selected USB devices to the WinUSB driver, and linux users will need to set their permissions to be able to use the usb devices as regular users. All the details are in the FGPA-README and ASIC-README files. No, this does not include a driver for the newly finished BFL singles (or doubles as I call them) since we do not have access to said hardware yet.


Human readable changelog:

- More debugging output.
- Hopefully fixed the stratum disconnection hangs on windows!
- Found numerous causes for devices dropping out on USB becoming zombies and rectified them so it should happen far less frequently now.
- Fixed numerous crashes with certain logging output on windows during hotplug/shutdown.
- Found a limitation on single core CPU devices (eg the router that drives the Avalon) and have worked around poor performing heavily threaded lock usage for such hardware, leading to less CPU usage, less delays and slightly higher hashrates.
- Zombies will now not fill the screen if they happen repeatedly - only the most active devices ever encountered will show on screen so if you don't change the number of devices and they go zombie and re-hotplug, you will not see their zombies while running, only on shutdown or API stats.
- Newly hotplugged devices show their average hashrate from when they were started rather than when cgminer was started.
- A lot more usb1.1 devices (most lancelot devices) will work on usb3 hubs now.
- Mac OSX build fixes.
- The efficiency value will no longer show for pools unless they are using the old getwork communication protocol.
- Avalon improvements to avoid duplicate shares/idle devices.
- Nominal cutoff temperature set for BFL ASIC devices.
- Don't give write/read fail errors when shutting down on OSX.
- BFL SC 5GH devices that failed to initialise due to being slow to respond should start now.
- Fixes for numerous possible crashes on hotplug/unplug.
- Numerous low level fixes.


Full changelog:

- Record and report USB pipe errors via API stats
- Suspend stratum connections when we know they've failed and don't try to recv
data from them once the socket no longer exists.
- Pipe error is quite common on usb3 so drop logging to verbose level only.
- ocl.c fix applog warnings on windows
- applog/quit fix GPU errors created
- usbutils - DEVLOCK other usbdev access
- applog usb device list can be > LOGBUFSIZ
- fix windows log warnings
- logging remove extra added <LF>
- remove varargs from logging/quit/in general as much as possible
- Don't yield when downgrading a cg ilock.
- Don't yield on grabbing the read lock variant of cglocks.
- Off by one error in device count for display.
- Don't display devices beyond the most_devices count in the curses status.
- Only display as many device rows as the maximum live existed at any time.
- usb lock out use cg locks
- usb lock out transfers during open/close
- Add error message to libusb pipe error
- Differentiate libusb control transfer pipe errors from transfer errors since
they're not fatal.
- Create a usb_bulk_transfer wrapper for libusb_bulk_transfer to cope with pipe
errors.
- Only show efficiency in pool information for pools that don't support local
work generation.
- Create a pool_localgen bool function for testing when a pool can generate work
locally.
- ignore file that is generated on Macs
- compile unix code on Mac OS X fixes not finding the config file in $HOME
- Use mining start time for device MH/U calculations
- Decrease the sleep duration before reading in avalon to not let the read
buffer overflow.
- Failure to read and write on pseudo semaphores on apple happens routinely on
shut down so should not be a quit error, just a warning.
- Unlock usb dev lock in the same place in usbutils.
- Sleep if the avalon buffer is empty and we've requested a read to allow the
write thread to take precedence.
- Yield after releasing a lock in case we are on a device with limited CPU
resources.
- Add the cgpu_info structure before avalon reset.
- Tidy up DEVLOCK/UNLOCK to have consistent use of the pstate variable without
needing brace level match.
- Icarus driver elaspsed timeout shouldn't be just USB I/O
- usbutils avoid leaving devlock locked when thread cancelled
- MMQ fix nodev failure caused by changes
- ubsutils lock all access to nodev and cgusb
- USB make device_path handled by usbutils
- tidy up free in device detect functions
- USB control creation and free of cgpu
- Add FAQ regarding Work Utility.
- Throttling the BFLSC at 80 seems to prevent generating garbled responses of
higher temps.
- Return after failed bin2hex conversion in bflsc.
- Demote failed hex2bin result to LOG_INFO and check return result in
driver-bflsc to avoid doing find_work_by_midstate.
- Set BFLSC fan speed coarsely to keep it under 60 or auto as per specs saying
it tries to stay below 60.
- Limit usbutils LATENCY_STD to 32ms to keep transfers under 512 bytes.
- Move macro definition to bflsc driver
- Use a longer timeout for retrieving bflsc details.
- Add a usb_read_ok_timeout wrapper to cope with slow init'ing devices.
- cgsem_post after creating the thread info
- Fix build.
- Use cgsem structures instead of the flaky pings in the work queue to start
mining threads and remove the unused thr_info_freeze function.

[kano]

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

I went ahead and tried it now.

"--usb 5:1,5:2" in one instance
"--usb 3:1,3:2" in the other instance

Both hashing away just fine.  Now I can more objectively compare pools.
Thanks,
Sam

Just an aside useful comment about this
You can also do:
"--usb 5:*" in one instance
"--usb 3:*" in the other instance
So all the devices you plug into bus 5 go into the first cgminer and all you plug into bus 3 go into the other one.
A small USB hub will usually be a single bus number
The bigger hubs (10 or 20 ports) may? be one or may? a few bus numbers (I'm not sure I don't have one)

[kano]

3.2.2a
3.2.2 recompiled on 64 bit Fedora18, 64 bit xubuntu 11.04 and also on the RPi 32 (2012-12-16-wheezy-raspbian and rpi-update)

https://github.com/kanoi/cgminer-binaries

To get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.2.2a
chmod +x cgminer-3.2.2a
md5sum cgminer-3.2.2a
8c16f622795c5cd8a58c6aebc024ac09  cgminer-3.2.2a
(this version should also work on Fedora 16 and Fedora 17)

To get the RPi 32bit binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/RPi_32/cgminer-3.2.2a
chmod +x cgminer-3.2.2a
md5sum cgminer-3.2.2a
cd54da55f31398e5bc6b951a139d6745  cgminer-3.2.2a

To get the Fedora 18 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.2.2a
chmod +x cgminer-3.2.2a
md5sum cgminer-3.2.2a
c1e48b33b2180b70a6f94aef3effe350  cgminer-3.2.2a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
On xubuntu 11.04 - first get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I've run all three binaries without any problems so far, with 1x6950, 1xJalapeno, 1xAMU, 1xBLT, 1xBFL, 1xICA, 1xMMQ (Total ~8.6GH/s)

All have been built with -g
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

Otherwise, the same configure options as cvolivas' binary version for 64 bit xubuntu 11.04
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
make clean
make

All USBs (only) for the RPi 32bit version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0

All USBs (only) for the Fedora18 x86_64 version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0


Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.2.2) then click on the file you want then right-click save-as "View Raw"


Important: Read ASIC-README or FPGA-README about USB configuration on linux and windows

[camaro69327]

I tried to set intensity from 10 to 18, all the same, defined GPU and MEM clock manually, same issue. Trying different combinations for days but again the same.

I have [fglrx] module loaded - fglrx 9.0.2 [Sep 20 2012] with 6 minors AMD Driver and ATI OpenCL Drivers 2.8 and ADL SDK 5.0

It is promising that I'm not alone with this problem, tried to search for it but just can't define correctly the search

In case this can help someone else. I had the Exact same problem this user is experiencing . its the Fglrx drivers!!!

I struggled for a week with this and finally asked for help . The Fglrx drivers we are told to install according to a guide. Linuix nube here, so i followed the guide word for word and never got things going . the person helping me had me remove those drivers (FGLRX) and install  13.XX AMD Drivers and Magically all problems disappeared. I could set clocks and finally mine at full tilt!

Been mining non stop for 3 months 24/7 on that Linux install.

Sorry if off topic for this thread , Love cgminer , and if this could help someone else avoid the headache!

[PatMan]

Great work guys, kudos.

[Trongersoll]

This is not a complaint or  request for help. First, i'm running 3.1.1. I just consolidated 7 ASICminer USB sticks that had been running fine plugged into various USB ports into one Anker 10 port USB Hub with a fan on it. I haven't gone on to 3.2 series because the Anker is USB 3.0. What i've found is that two sticks are only averaging 200Mh/s and are get significantly more HW errors than the others. They are ICA 3 and ICA 6, i find that the numbers are multiples of 3 interesting and thought it might of interest to  the Devs. Perhaps not. I'm going to let things run as is until it is announced that 3.2 series is USB 3.0 compatible. thanks for the great job guys.

[Krak]

This is not a complaint or  request for help. First, i'm running 3.1.1. I just consolidated 7 ASICminer USB sticks that had been running fine plugged into various USB ports into one Anker 10 port USB Hub with a fan on it. I haven't gone on to 3.2 series because the Anker is USB 3.0. What i've found is that two sticks are only averaging 200Mh/s and are get significantly more HW errors than the others. They are ICA 3 and ICA 6, i find that the numbers are multiples of 3 interesting and thought it might of interest to  the Devs. Perhaps not. I'm going to let things run as is until it is announced that 3.2 series is USB 3.0 compatible. thanks for the great job guys.

Sounds like 3.2.2 has some USB 3.0 fixes; give it a shot.

[Mastergerund]

Did I miss a mandatory upgrade? I am still using 2.11.4 and it is doing fine. I understood I need to upgrade for FPGA's or ASICs, but I am only GPU mining.

[streetuff]

my 2 usb block errupters still die after a minute on linux with 3.2.2...
back to 3.1.1 for me...

x86 running lubuntu.
Linux Viotech 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 16:26:01 UTC 2012 i686 i686 i386 GNU/Linux

[freshzive]

my 2 usb block errupters still die after a minute on linux with 3.2.2...
back to 3.1.1 for me...

x86 running lubuntu.
Linux Viotech 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 16:26:01 UTC 2012 i686 i686 i386 GNU/Linux

Same here, still getting the "idle more than 60 seconds" error and disconnections.

I build from source on Ubuntu 12.04 x64. Block erupters are connected with a USB 3.0 hub and function properly in cgminer3.1.1.

Time to downgrade again.

[PCMiner]

Did I miss a mandatory upgrade? I am still using 2.11.4 and it is doing fine. I understood I need to upgrade for FPGA's or ASICs, but I am only GPU mining.

As I've been reading this thread over the last few months, it seems the 3x releases are geared more towards ASIC users, with little changes for GPU miners.  If things are stable, I'd stick with what you got.