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

[os2sam]

***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

[ewibit]

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

is it possible that this has the same reason:


a few days it has run with 7 Block erupter without Problems, then it has begun to error
it is the same hub as before, (I have changed nothing), then I tried another hub, another port, cgminer different versions, -> always errors
(Ubuntu 12.04)
TIA

[ak49er]

Just wanted to chime in and say thanks for the program.  I just hooked up my first Block Erupter to go with my two GPUs and after getting the permissions sorted following the help on here I was up and running on 3.2.1 in under 10 minutes.

[puppetmaster]

Hello

I am hoping you guys can help me with my cgminer crashing. First off, here are my two PC specs:


Main PC (Gaming & Mining)

Intel i7 2600K @ 4.7GHz
Asus P8P67 Deluxe
8GB DDR3 1600Mhz RAM (2x 4GB)
2x Saphire 6950's flashed with 6970 BIOS + overclocked
1x XFX 5870
AX1200i PSU
Various Hard Drives (2x SSD's, 3x HDD's)
Windows 7 Pro x64 SP1, AMD 13.6 Beta Drivers, SDK included with 13.6
CPU and 3x GPU are all under water


2nd PC (Mining 100%):

Intel G550
Asus P8P67 Pro
4GB DDR3 1333 RAM (1x 4GB)
1x Powercolour 5870
1x Sapphire 5870
Corsair HX620 PSU
1x 120GB HDD
Windows 7 Pro x64 SP1, AMD 13.6 Beta Drivers, SDK included with 13.6
2x GPU Underwater

Now my problem. Whatever I try on my main PC to mine, cgminer will always crash. My 2nd machine is happily mining LTC using CG miner. When I was first setting that up, it would crash sometimes depending on settings. I believe this to be due to the TC setting but after some switching around, the 2x 5870's are mining fine.

On my main PC, everything I have tried doesn't work including:

• Lots of different settings in the cg miner config as well as trying to use GUI Miner. In GUI Miner it crashes just after it says "starting" on all 3 cards. I have tried varying versions of cgminer with no effect. I have tried mining BTC and LTC with no change.
• Using a java program to generate a batch file. No effect. I have also tried using batch files and the general config for CG Miner.
• Loading cgminer and entering the information manually in the command prompt. Its lets me enter all the information and will crash after entering the worker password.
• Different AMD driver versions, however with 13.1 and 13.4 (the only 2 I have tried really), my PC will blue screen either during installation of the driver or upon the restart. I have used the AMD cleanup tool as well as driver cleaner. No change. I believe the blue screen is caused by a corrupt dll for CCC. I was in the process of manually extracting and replacing that file, however I couldn't delete the original from within my own Windows installation. I will try to resolve that as soon as I can (see next point)
• I performed a clean install of Windows on a separate partition on my main SSD. I have a Windows install identical to my Mining RIG with 13.6 (as in not a copy, just installed the same software). No change. This was a very bare windows install with no overclocking on the GFX Cards. I don't think it is driver related as it works fine on my 2nd machine with 13.6 I believe.

Few things to note:

• MY PC is 100% stable with overclocked settings, will happily run prime 95 for 12hrs+ as well as graphics benchmarks with no issues.
• I originally had Kaspersky IS on this PC, it is currently disabled but the 2nd machine + clean install does not have any A/V installed.
• Nothing is overheating. I am running both machines on water. On my main PC with all 3 cards @ 100%, temps are normally 55-60, 53-58 and 45-50 across the cards. 2nd PC usually has temps between 45-50.
• Last August I managed to mine BTC with cgminer without any problems when I had 2x 6970's
• I am currently mining BTC on this PC with the bitminter java app. No problems with this, can happily run all 3 cards at the same time and I leave the PC mining this way during the day and overnight.
• I don't really want to use any earlier than 13.x drivers, due to the fact I game on this PC a lot. I am not worried about any drop in mining speed because of that.
• I have worked with computers for years. I work with PC's all day in my day job (work in a local PC Shop, fixing computers etc etc) so I am very familiar with troubleshooting / fault finding.

Does anyone have any suggestions on how to resolve my problem. Been spending ages trying to get it sorted.

I have no doubt left information out. It's quite hard to remember everything for one post

Thanks in advance for any help.

[spazcoin]

I tried to setup my PC/GPU for doing LTC scrypt mining yesterday, following the directions here https://bitcointalk.org/index.php?topic=83371.0, here https://bitcointalk.org/index.php?topic=83371.msg1733884;topicseen#msg1733884, and here https://bitcointalk.org/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:

1) Just after the cgminer application starts, it crashes. Windows error "cgminer.exe has stopped working". A generated logfile.txt (by adding 2>logfile.txt to command line parameters) looks like:

[2013-06-15 23:03:03] Started cgminer 3.2.1
[2013-06-15 23:03:03] Probing for an alive pool
[2013-06-15 23:03:04] Pool 0 difficulty changed to 96.000000

(and that's it, crashed)
I see this error on v3.1.0, v3.1.1, and v3.2.1 cgminer packages downloaded from http://ck.kolivas.org/apps/cgminer/ as well as with the 3.2.1 version that I compiled myself. I'm guessing that this crash is just a timeout of being unable to connect to a mining server, and could be a configuration file issue. I'm starting cgminer using a batch file generated on the WeMineLTC site:

Code:

cgminer.exe --scrypt -o stratum+tcp://stratum.wemineltc.com:3333 -u spazcoin.1 -p *** -I 13 2>logfile.txt

Based on tutorial pages from others, I also tried using the following batch file for solo mining optimized use with my Radeon 5450 card:

Code:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe --scrypt --shaders 80 --intensity 9 --worksize 64 -g 1 --auto-gpu --auto-fan -o http://192.168.0.5:9332 -u spazcoin.1 -p *** --failover-only -o stratum+tcp://eu.wemineltc.com:3333 -u spazcoin.1 -p *** 2>logfile.txt

However, that configuration to point to the Litecoin server on my PC (http://192.168.0.5:9332) has always been rejected by cgminer.

2) Using the v3.2.1 precompiled version, I've gotten farther (sometimes) and the cgminer application actually runs.  However, it fails to submit a piece of work to the GPU and disables the GPU thread. logfile shown below:

[2013-06-15 23:50:21] Started cgminer 3.2.1
 [2013-06-15 23:50:21] Probing for an alive pool
 [2013-06-15 23:50:22] Pool 0 difficulty changed to 96.000000
 [2013-06-15 23:50:31] Network diff set to 46.7M
 [2013-06-15 23:50:31] Error -55: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
 [2013-06-15 23:50:31] GPU 0 failure, disabling!
 [2013-06-15 23:50:31] Thread 0 being disabled
 [2013-06-15 23:56:36] Stratum from pool 0 detected new block
 [2013-06-15 23:59:43] Stratum from pool 0 detected new block
 [2013-06-16 00:01:38] Stratum from pool 0 detected new block

I've searched through the forums and read the OpenCL documentation for that clEnqueueNDRangeKernel command, but I can't figure out what is causing the problem with enqueueing the kernel. If I exit cgminer (using 'q'), I get the following statistics, so clearly nothing is running:

Summary of runtime statistics:

 [2013-06-16 00:44:00] Started at [2013-06-15 23:50:22]
 [2013-06-16 00:44:00] Pool: stratum+tcp://stratum.wemineltc.com:3333

 [2013-06-16 00:44:00] Runtime: 0 hrs : 53 mins : 29 secs
 [2013-06-16 00:44:00] Average hashrate: 0.0 Kilohash/s
 [2013-06-16 00:44:00] Solved blocks: 0
 [2013-06-16 00:44:00] Best share difficulty: 0
 [2013-06-16 00:44:00] Share submissions: 0
 [2013-06-16 00:44:00] Accepted shares: 0
 [2013-06-16 00:44:00] Rejected shares: 0
 [2013-06-16 00:44:00] Accepted difficulty shares: 0
 [2013-06-16 00:44:00] Rejected difficulty shares: 0
 [2013-06-16 00:44:00] Hardware errors: 0
 [2013-06-16 00:44:00] Utility (accepted shares / min): 0.00/min

 [2013-06-16 00:44:00] Work Utility (diff1 shares solved / min): 0.00/min

 [2013-06-16 00:44:00] Stale submissions discarded due to new blocks: 0

 [2013-06-16 00:44:00] Unable to get work from server occasions: 0

 [2013-06-16 00:44:00] Work items generated locally: 142
 [2013-06-16 00:44:00] Submitting work remotely delay occasions: 0
 [2013-06-16 00:44:00] New blocks detected on network: 16

 [2013-06-16 00:44:00] Summary of per device statistics:

 [2013-06-16 00:44:00] GPU0                | (5s):0.000 (avg):0.000h/s | A:0 R:0
 HW:0 U:0.0/m I:13
 [2013-06-16 00:44:00]

BTW, I also downloaded the 'reaper' miner (http://zerosignalgame.com/reaperv13beta4_32.zip), but when I run it, it also stops working, just after printing a line saying

Compiling kernel... this could take up to 2 minutes.

Therefore, maybe these issues are linked and pointing to an issue with my graphics card.

OS: Windows 7 64-bit.
Graphics Card: ATI Radeon HD 5450 - driver 12.1 installed today

[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://bitcointalk.org/index.php?topic=83371.0, here https://bitcointalk.org/index.php?topic=83371.msg1733884;topicseen#msg1733884, and here https://bitcointalk.org/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://bitcointalk.org/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://bitcointalk.org/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://bitcointalk.org/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.