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

[Aurum]

Is "gpu-dyninterval" : "7" only used when using "intensity" : d

[1714299083]

1714299083

[Aurum]

Win7 x64 drivers 13.4 7970 gives me 714kh/s on 1050/1500 settings on cgminer 3.2.1

What TC, I, temp-target and are you changing GPU Vddc
1050/1500 won't even run on my 7970s.

[Jcw188]

I have finally gotten some mining going after a lot of fooling around with drivers. I'm running xp 32 bit, Radeon 6670s, sdk 2.5 and catalyst 11.7. I have two machines that I believe are almost identical. However one I have running fine at 94 khash/sec.

The big problem is the other machine that seems to be getting a lot of hardware errors (hw). Anyone hav any ideas what can cause this?  I'm just running it standard with I 15 and have tried fooling around with the core
Clock and memory.  Thanks for help I just don't understand hat can cause hw errors.

Btw this is scrypt mining, coincidentally at flounds pool multipool.in. An yes this stratum issue is really annoying, hits both my miners to cause often disconnects which I can only assume are slowing my hashing.

I've never gotten good results with I > 13 on any of my miners.

I tried it will lower intensity and was still getting HW errors.  What can cause HW errors?  I was reading about fooling around with thread concurrency or shaders to try to fix this.  It's just that this machine is almost the same as the other one and the other one works great so I don't know what could be different on this one causing HW.

It's not fooling around with settings, it doing what you are supposed to do as the SCRYPT-README tells you to do.

Settings and performance on scrypt are affected buy many things: how much available RAM the computer has, how much RAM the GPU has, how many GPUs you are trying to run, the PCI-e bandwidth of the motherboard and of course the driver versions also depend on which GPUs you are using ...

Ok thanks.  The readme says must use SDK 2.6 or later.  I have 2.5 running scrypt on a similar machine so I figured it would work on this machine too.  I think I will try the --shaders command, and lowering parameters like intensity.  Then try SDK 2.6 but that wasn't working at all for me last time I tried. 

[SkyNet]

I am getting a quite strange error message when trying to scrypt mine with 3x 7950s in an older Core2Duo machine.
Without setting ANY parameter (not even intensity) just pool data, I am getting the following error:
Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
All 3 GPUs are set to OFF and no mining whatsoever
Drivers ver 12.8 and SDK 2.7
Any idea what that could be?
Could it be that there is an issue with the machine having only 2gb of ram?

[Aurum]

I am getting a quite strange error message when trying to scrypt mine with 3x 7950s in an older Core2Duo machine.
Without setting ANY parameter (not even intensity) just pool data, I am getting the following error:
Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
All 3 GPUs are set to OFF and no mining whatsoever
Drivers ver 12.8 and SDK 2.7
Any idea what that could be?
Could it be that there is an issue with the machine having only 2gb of ram?

"Without setting ANY parameter..." So you don't any *.conf in your cgminer folder?
"All 3 GPUs are set to OFF..." How did you set the GPUs to off if you didn't set any parameters?

As for memory, I keep hearing how scrypt mining is very RAM intensive. I've heard you need more RAM than you have video memory. I don't see that with my miners, e.g.:
Dedicated 4x7970 miner has 12 GB GDDR5 plus 10 GB DDR3 and I still have 8.69 GB available.
Dedicated 3x7970 miner has 9 GB GDDR5 plus 4 GB DDR3 and I still have 3.02 GB available.
2x7970 on my workstation, several other programs running, has 9 GB GDDR5 plus 8 GB DDR3 and I still have 5.36 GB available.
You might want to go to 4 GB but I suspect your problem is elsewhere.

[Foss]

Could it be that there is an issue with the machine having only 2gb of ram?

Yes too low memory, and install win7x64

[rav3n_pl]

Win7 x64 drivers 13.4 7970 gives me 714kh/s on 1050/1500 settings on cgminer 3.2.1

What TC, I, temp-target and are you changing GPU Vddc
1050/1500 won't even run on my 7970s.

I`m not touching voltage, fan is on driver auto, adl disabled (this is my desktop and when adl is enabled miner crash when switching users).
TC 8192, I 13

Code:

 
cgminer version 3.2.1 - Started: [2013-07-25 21:49:05]
--------------------------------------------------------------------------------
 (5s):731.0K (avg):729.0Kh/s | A:26374  R:126  HW:0  U:46.8/m  WU:0.0/m
 ST: 1  SS: 0  NB: 780  LW: 10312  GF: 0  RF: 0
 Connected to rav3n.dtdns.net diff 14 with stratum as user toy.gpu
 Block: 6dbc8d61137b268c...  Diff:15.1K  Started: [08:27:36]  Best share: 527K
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:                | 730.1K/729.0Kh/s | A:26374 R:126 HW:0 U:  46.77/m I:13
--------------------------------------------------------------------------------

 [2013-07-27 08:27:45] Pool 0 difficulty changed to 15.066359
 [2013-07-27 08:27:45] Stratum from pool 0 requested work restart

Mining DBL, but it is no difference from LTC.

[-ck]

Is "gpu-dyninterval" : "7" only used when using "intensity" : d

yes

[kano]

Request from me to anyone having trouble with ICA or AMU devices on linux with the latest cgminer.
Firstly, I've written a standalone program, that's all the necessary code from cgminer (with lots of changes and added code) to test libusb on anyone's linux
It's here: http://198.245.60.111/Pix/usbfail.c
It has instructions in the top how to compile it.

Running it will simply show you if the version of libusb on your linux is ... problematic ... but of course only if you have 2 or more ICA or AMUs

If anyone does this could they report 4 things in a pastebin or similar link (pastebin is here: http://pastebin.com/ )
Report their hardware (e.g. an intel/amd desktop, an RPi, or some other such description)
Report their linux verion with uname -srvmpio
Report their libusb version e.g.
 RPM based system: rpm -qva | grep libusb
 APT based system: apt-cache policy libusb-1.0 | egrep "^l|Install"
 Pacman system: pacman -Q | grep libusb
Report their libusb libraries e.g. maybe something like: ls -las /lib*/libusb* /usr/lib*/libusb*
and finally the output of running ./usbfail
You may need to run it a few times - basically what's of interest is the most common result running it.
If it locks up in "flushing" and says it failed on exit after ~17s then that's the expected result for a bad libusb version

An aside - you can run ./usbfail lock and it should actually report USB working even if it fails without using lock
It was simply a test to see if serial access to all usb IO solved the problem

You can (if you are inclined) also compile it against a working libusb and that should make usbfail work as expected also
To do this is something like:
In the cgminer directory, create a libusb directory mkdir libusb
Then cg libusb
Then in that directory extract the archive from:
Get libusb http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.16-rc10/
e.g. tar -xvf libusb-1.0.16-rc10.tar.bz2
Then cd libusb-1.0.16-rc10
Then ./configure
You also need udev development files so will get a configure error if they aren't installed
Then make
So you've now built libusb and can compile usbfail and link against it as shown in the 2nd example in the top of usbfail.c

Of course none of this will fix cgminer for you, but really what I'm looking for is the answer to an on going problem to decide how to fix it.
It would appear it would be good to add a libusb folder in with cgminer and put a working version of it in there and compile cgminer against it and thus know that cgminer is always using a working version of libusb

None of this has anything to do with windows.

[turtle83]

http://pastie.org/private/qzjzezzghx4ojwyysygfqw

on Ubuntu 13.04
the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success.

I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically  do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success.

[kano]

http://pastie.org/private/qzjzezzghx4ojwyysygfqw

on Ubuntu 13.04
the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success.

I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically  do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success.

Thanks, that info is perfect and says exactly what I'd hope it says.
For 12.04 the problem for you is almost certainly in the libusb version.
I expect (though I'll wait to see before I'm 100% certain) that current git and latest libusb should not get SICK devices, should not hash at ~100MH/s for some devices (instead of ~333MH/s) and should not have regular TIMEOUT errors (a rare few is OK)

Detection problems 'might' also be addressed by current git since there is a usb config setup change I've added that may help
Though interestingly enough, writing this test code I found a situation where it would actually get out of sync with replies during initialisation, that I'll look into and see if it is related, once the libusb version issue is clarified and resolved.

[turtle83]

http://pastie.org/private/qzjzezzghx4ojwyysygfqw

on Ubuntu 13.04
the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success.

I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically  do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success.

Thanks, that info is perfect and says exactly what I'd hope it says.
For 12.04 the problem for you is almost certainly in the libusb version.
I expect (though I'll wait to see before I'm 100% certain) that current git and latest libusb should not get SICK devices, should not hash at ~100MH/s for some devices (instead of ~333MH/s) and should not have regular TIMEOUT errors (a rare few is OK)

Detection problems 'might' also be addressed by current git since there is a usb config setup change I've added that may help
Though interestingly enough, writing this test code I found a situation where it would actually get out of sync with replies during initialisation, that I'll look into and see if it is related, once the libusb version issue is clarified and resolved.

FYI im on 13.04 not 12.04.

I just rebuilt cgminer (newest commit bda1e333222e9921be793a1e517d84d4aba88ea5)
./configure command:-

Code:

LIBUSB_CFLAGS="-I/home/xxx/tmp/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="/home/xxx/tmp/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" ./configure --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon

Summary: http://pastie.org/private/5qstv1txipwwddh97ujhmq

both AMUs are running at ~333MH/s.. and they start mining as soon as cgminer starts. Stopped and started a few times to be sure.

If the problem is fixed for most linux users by using a specific libusb version AND inclusion of this version of libusb in distro repositories is not in the horizon, i guess cgminer should bundle the working lib.

[dc81]

recompiled cgminer using the libusb above and now able to mine multiple block erupters on my raspberry pi

[MineForeman.com]

recompiled cgminer using the libusb above and now able to mine multiple block erupters on my raspberry pi

Alternatively you could use Arch Linux and your good to go with your PI .

[JLM]

Hi. Maybe somebody ask this, but i couldn´t find the answer:

X6500 could be run with CGMiner?
Could somebody tell me where is driver?

Thanks!!!

[kano]

Hi. Maybe somebody ask this, but i couldn´t find the answer:

X6500 could be run with CGMiner?
Could somebody tell me where is driver?

Thanks!!!

Not in cgminer.
We've never had an x6500 miner.

[JLM]

Hi. Maybe somebody ask this, but i couldn´t find the answer:

X6500 could be run with CGMiner?
Could somebody tell me where is driver?

Thanks!!!

Not in cgminer.
We've never had an x6500 miner.

Thanks for answer.
That´s too bad. I´d like to run my Erupter USB with a single FPGAMining x6500...
Well, thinking what to do.
Thanks anyway.

[ChipGeek]

I would expect something like "-I /usr/include/libusb-1.0" in the compile command. Maybe you need to re-run ./configure?

Thank you.  ./configure was the last bit of magic required. 

I finally got what I was looking for in the first place:

Code:

[GetInfo] => DEVICE: BitFORCE SC 0x0a
FIRMWARE: 1.0.0 0x0a
MINIG SPEED: 7.85 GH/s 0x0a
PROCESSOR 3: 15 engines @ 259 MHz 0x0a
PROCESSOR 7: 15 engines @ 270 MHz 0x0a
ENGINES: 30 0x0a
FREQUENCY: 266 MHz 0x0a
XLINK MODE: MASTER 0x0a
CRITICAL TEMPERATURE: 0 0x0a
XLINK PRESENT: NO 0x0a
OK 0x0a 0x00

[lano1106]

Hi,

I just want to report that I am seeing frequent core dump with cgminer 3.3.1 since I have recompiled cgminer with Icarus support to work with 10 USB Eruptors.

I have reproduced the problem with debug symbols to get a nice trace of where the problem is. Will continue digging further the problem to help you guys to nail down the problem:

Program terminated with signal 11, Segmentation fault.
#0  0x000000000045acfb in icarus_initialise (icarus=icarus@entry=0x7f665c012fa0, baud=<optimized out>)
    at driver-icarus.c:384
384            icarus->usbdev->PrefPacketSize = AMU_PREF_PACKET;
(gdb) where
#0  0x000000000045acfb in icarus_initialise (icarus=icarus@entry=0x7f665c012fa0, baud=<optimized out>)
    at driver-icarus.c:384
#1  0x000000000045b6c8 in icarus_initialise (baud=<optimized out>, icarus=0x7f665c012fa0) at driver-icarus.c:888
#2  icarus_scanhash (thr=0x7f665c03aaf0, work=0x119b5e0, max_nonce=<optimized out>) at driver-icarus.c:891
#3  0x0000000000411005 in hash_sole_work (mythr=0x7f665c03aaf0) at cgminer.c:5859
#4  0x00000000004097b3 in miner_thread (userdata=0x7f665c03aaf0) at cgminer.c:6135
#5  0x00007f66cb2a6bba in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007f66ca1f227d in clone () from /usr/lib/libc.so.6

Also is ck away in vacation. I sent him a small patch for something I caught while reviewing code last week and I haven't heard back anything.

Maybe I can share the patch here or perhaps do it over github:

removal of a useless memcpy:

--- cgminer-3.3.1/cgminer.c.orig        2013-07-16 01:56:51.587678112 -0400
+++ cgminer-3.3.1/cgminer.c     2013-07-16 02:03:57.530715675 -0400
@@ -1710,7 +1710,6 @@ static void gen_gbt_work(struct pool *po
                work->job_id = strdup(pool->gbt_workid);
        cg_runlock(&pool->gbt_lock);
 
-       memcpy(work->data + 4 + 32, merkleroot, 32);
        flip32(work->data + 4 + 32, merkleroot);
        free(merkleroot);
        memset(work->data + 4 + 32 + 32 + 4 + 4, 0, 4); /* nonce */

[kano]

The segfault will be usbdev is null (since it can disappear underneath the code)
Try current git - I put a fix for that in a little over a month ago

Edit: also compile it with -g -O0 since optimisation will often hide information that can help track down a bug