Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 295. (Read 5805537 times)

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)

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

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!

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

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.

Con,

Will you be so kind to comment this:

https://bitcointalksearch.org/topic/m.2489565

10X

the host is a 703N router

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


running cgminer:



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'            

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.

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.

Not yet, no

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

I tried to setup my PC/GPU for doing LTC scrypt mining yesterday, following the directions here https://bitcointalksearch.org/topic/tutorial-solo-mining-litecoins-guide-windows-83371, here https://bitcointalk.org/index.php?topic=83371.msg1733884;topicseen#msg1733884, and here https://bitcointalksearch.org/topic/request-cgminer-for-litecoin-miner-tutorial-97143.

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:


(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:

Based on tutorial pages from others, I also tried using the following batch file for solo mining optimized use with my Radeon 5450 card:
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:


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:



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

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.

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.

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

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

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

yeeh GPU 58xx series, thank you for reaction...
OpenCL 1.1 AMD-APP (831.4) FULL_PROFILE
8.15.10.2696 (3-19-2012) - GL:ig4icd64.dll

absolutely nothing changed...
just unpack new cgminer on desktop, where all old versions located, copy config files and shortcut to new cgminer directory and do corresponding shortcut changes
 

I assume you mean your GPU fans. There were absolutely no GPU changes going from 3.2.0 to 3.2.1 so you have changed something when upgrading cgminer, likely the driver...