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

[os2sam]

I've had a similar problem with cgminer 3.3.2

There's a 3.3.2?  I'm still using 3.3.1, which is working great for me with USB Erupters.  Of course I only have 15 of them with USB 2.0 Hubs.

Opps I think I meant 3.3.1, but mostly I meant latest master from github (805672fb51f4219e8c5848dc761509d32bffde9f -- I think it identifies itself as 3.3.2, sorry I forgot it wasn't released yet). I tried master from github first when I couldn't get 3.3.1 to work. I was about to blame the hub when I decided to try building 3.1.1 as a hail mary.

They're still working on the USB 3.0 Hub support.  Which was the reason I bought USB 2.0 Hubs.

Glad your working at least.
Sam

[1714256515]

1714256515

[notme]

I've had a similar problem with cgminer 3.3.2

There's a 3.3.2?  I'm still using 3.3.1, which is working great for me with USB Erupters.  Of course I only have 15 of them with USB 2.0 Hubs.

Opps I think I meant 3.3.1, but mostly I meant latest master from github (805672fb51f4219e8c5848dc761509d32bffde9f -- I think it identifies itself as 3.3.2, sorry I forgot it wasn't released yet). I tried master from github first when I couldn't get 3.3.1 to work. I was about to blame the hub when I decided to try building 3.1.1 as a hail mary.

They're still working on the USB 3.0 Hub support.  Which was the reason I bought USB 2.0 Hubs.

Glad your working at least.
Sam

For me USB 3.0 hubs do not work in USB 3.0 slots, but if I plug them into USB 2.0 slots they work fine.  It might be worth a try if you already have the hardware.

[chanson]

I've had a similar problem with cgminer 3.3.2

There's a 3.3.2?  I'm still using 3.3.1, which is working great for me with USB Erupters.  Of course I only have 15 of them with USB 2.0 Hubs.

Opps I think I meant 3.3.1, but mostly I meant latest master from github (805672fb51f4219e8c5848dc761509d32bffde9f -- I think it identifies itself as 3.3.2, sorry I forgot it wasn't released yet). I tried master from github first when I couldn't get 3.3.1 to work. I was about to blame the hub when I decided to try building 3.1.1 as a hail mary.

They're still working on the USB 3.0 Hub support.  Which was the reason I bought USB 2.0 Hubs.

Glad your working at least.
Sam

For me USB 3.0 hubs do not work in USB 3.0 slots, but if I plug them into USB 2.0 slots they work fine.  It might be worth a try if you already have the hardware.

Oh, right. I forgot to mention that I excluded the hub as the problem before going to 3.1.1 by reproducing the findings with the USB Eruptors plugged in directly to the computer. I observed the same behavior where individually they work fine but if two were installed each device would mine for a bit and then enter into some sort of standby mode with solid leds (they don't both enter that state at the same time--one will get there sooner than the other). Then after a few seconds both will start hashing again simultaneously. That pattern of hashing in spurts and stalling just keeps repeating itself. I didn't time it but my guess is ~15-30sec. The computer itself is an Celeron-based Intel NUC that only has USB 2.0 ports.

I don't know if it matters but the the second miner came from BTCguild and was "branded" (I assume via the Luke-JR method) but the first comes from CanaryInTheMine and is unbranded. cgminer's udev rules seem to work fine with both as far as I can tell.

Looking back through the logs did finally notice one thing. When running the 3.2.x or github version, this happens once per reboot when cgminer is starting up:

Jul 16 00:47:02 xxx kernel: [   10.527272] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Jul 16 00:47:02 xxx kernel: [   10.527304] cp210x 2-1.1.2:1.0: device disconnected
Jul 16 00:47:02 xxx kernel: [   10.588515] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Jul 16 00:47:02 xxx kernel: [   10.588549] cp210x 2-1.1.4:1.0: device disconnected

When this happens /dev/ttyUSB0 and /dev/ttyUSB1 disappear and never return. But cgminer 3.2.x is still able to hash in spurts. I had to reboot to get 3.1.1 to work.

[notme]

I've had a similar problem with cgminer 3.3.2

There's a 3.3.2?  I'm still using 3.3.1, which is working great for me with USB Erupters.  Of course I only have 15 of them with USB 2.0 Hubs.

Opps I think I meant 3.3.1, but mostly I meant latest master from github (805672fb51f4219e8c5848dc761509d32bffde9f -- I think it identifies itself as 3.3.2, sorry I forgot it wasn't released yet). I tried master from github first when I couldn't get 3.3.1 to work. I was about to blame the hub when I decided to try building 3.1.1 as a hail mary.

They're still working on the USB 3.0 Hub support.  Which was the reason I bought USB 2.0 Hubs.

Glad your working at least.
Sam

For me USB 3.0 hubs do not work in USB 3.0 slots, but if I plug them into USB 2.0 slots they work fine.  It might be worth a try if you already have the hardware.

Oh, right. I forgot to mention that I excluded the hub as the problem before going to 3.1.1 by reproducing the findings with the USB Eruptors plugged in directly to the computer. I observed the same behavior where individually they work fine but if two were installed each device would mine for a bit and then enter into some sort of standby mode with solid leds (they don't both enter that state at the same time--one will get there sooner than the other). Then after a few seconds both will start hashing again simultaneously. That pattern just keeps repeating itself. I didn't time it but my guess is ~15-30sec. The computer itself is an Celeron-based Intel NUC that only has USB 2.0 ports.

I don't know if it matters but the the second miner came from BTCguild and was "branded" (I assume via the Luke-JR method) but the first comes from CanaryInTheMine and is unbranded. The udev rules didn't care.

Looking back through the logs did finally notice one thing. When running the 3.2.x or github version, this happens once per reboot when cgminer is starting up:

Jul 16 00:47:02 ohms kernel: [   10.527272] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Jul 16 00:47:02 ohms kernel: [   10.527304] cp210x 2-1.1.2:1.0: device disconnected
Jul 16 00:47:02 ohms kernel: [   10.588515] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Jul 16 00:47:02 ohms kernel: [   10.588549] cp210x 2-1.1.4:1.0: device disconnected

When this happens /dev/ttyUSB0 and /dev/ttyUSB1 disappear and never return. But cgminer 3.2.x is still able to hash in spurts. I had to reboot to get 3.1.1 to work.

3.2+ is doing that.  It no longer uses the ttyUSB devices so it removes them to disable the driver so that cgminer can use raw USB through libusb.

[chanson]

3.2+ is doing that.  It no longer uses the ttyUSB devices so it removes them to disable the driver so that cgminer can use raw USB through libusb.

Yes, I concluded it was the desired behavior. Just being complete in reporting everything this time. I mostly wanted to clarify that the problem does indeed exist without USB 3.0 anywhere in the picture and it only seems to show up when more than one eruptor is installed. When the other user mentioned a problem when using an eruptor+fpga, it made me think that perhaps there's just some problem using eruptors with multiple devices on 3.2.x.

I know you have a large eruptor setup. Are you running 3.2.x? Your recommendation to someone else to run 3.1.1 a while ago is why I ended up trying that. (I saw you mention your eruptor farm in a p2pool thread and went through your post history to see if I was missing a step--initially I suspected a p2pool problem, but the 3.1.1 recommendation was on the money)

[Dunkelheit667]

kano mentioned some time ago libusb might causing those issues and I guess he's on the spot. As far as I'm aware all miners reporting sick/zombie AMUs used a wheezy distribution. The wheezy libusb version is quite outdated. On the other hand e.g. Arch Linux is using a newer version and cgminer 3.2.x working fine as far as I can say. But just guessing.

[notme]

kano mentioned some time ago libusb might causing those issues and I guess he's on the spot. As far as I'm aware all miners reporting sick/zombie AMUs used a wheezy distribution. The wheezy libusb version is quite outdated. On the other hand e.g. Arch Linux is using a newer version and cgminer 3.2.x working fine as far as I can say. But just guessing.

+1 for Arch

Edit: Not that you are one, but Arch Linux is not for Linux Newbies.  Please be comfortable with the command line before switching.

[daemondazz]

If your usb hub is a usb2 hub and not a usb3 hub you will be far better off moving to the latest version of cgminer instead. The only reason to stick with the old version of cgminer is if you have multiple usb1.1 devices on a usb3 hub for there remains an instability there that we've been unable to debug so far.

Is that the cause for this:

Code:

Jul 16 18:37:12 server1 cgminer[31418]: Accepted 03e8a8b7 Diff 65/1 AMU 2 pool 0
Jul 16 18:37:12 server1 cgminer[31418]: AMU1: Comms error (werr=-7 amt=0)
Jul 16 18:37:12 server1 cgminer[31418]: AMU0: Comms error (werr=-7 amt=0)
Jul 16 18:37:13 server1 cgminer[31418]: AMU2: libusb pipe error, trying to clear

Works fine with 1 USB Erupter on the USB3 hub but it doesn't like multiples.

Let me know if I can help with any debugging.

[notme]

If your usb hub is a usb2 hub and not a usb3 hub you will be far better off moving to the latest version of cgminer instead. The only reason to stick with the old version of cgminer is if you have multiple usb1.1 devices on a usb3 hub for there remains an instability there that we've been unable to debug so far.

Is that the cause for this:

Code:

Jul 16 18:37:12 server1 cgminer[31418]: Accepted 03e8a8b7 Diff 65/1 AMU 2 pool 0
Jul 16 18:37:12 server1 cgminer[31418]: AMU1: Comms error (werr=-7 amt=0)
Jul 16 18:37:12 server1 cgminer[31418]: AMU0: Comms error (werr=-7 amt=0)
Jul 16 18:37:13 server1 cgminer[31418]: AMU2: libusb pipe error, trying to clear

Works fine with 1 USB Erupter on the USB3 hub but it doesn't like multiples.

Let me know if I can help with any debugging.

I had some erupters on a hub that wasn't delivering the power it should have.  Erupters on that hub would give me that error.  After I wired the hub up to my PSU I don't see them any more.

Might not be the only cause, but that was it for me.

[nonServiam]

Hello,

i have a question. I apologize as a precaution for my not so good english.

I was in the process monitor by accident. there I saw the cgminer is permanently connected to 3dns.adobe.com.

what does that mean?

[The00Dustin]

Hello,

i have a question. I apologize as a precaution for my not so good english.

I was in the process monitor by accident. there I saw the cgminer is permanently connected to 3dns.adobe.com.

what does that mean?

Most likely it means someone is using some Adobe service in regards to their mining pool server or your ISP is using some adobe service for your DNS.  However, I was unaware that Adobe offered such services, and it could be something more dubious.  To verify, you should get the IP address(es) of your miningpool(s) if you don't already have it for your cgminer configuration.  In a command prompt:

Code:

nslookup yourminingpoolfqdn1
nslookup yourminingpoolfqdn2
(etc)

.  Then you should use do a reverse lookup the same way with the IP address(es).  In a command prompt:

Code:

nslookup ipaddress1
nslookup ipaddress2
(etc)

.  If one of the ipaddresses returns 3dns.adobe.com, you are fine, because Windows is just performing a reverse lookup on whatever IP you are connecting to.  Additionally, if nslookup shows 3dns.adobe.com as your dns server, you are probably also fine (unless your computer is infected with something that is pointing you toward malicious DNS servers).  If you can understand and perform all of those actions and you don't see 3dns.adobe.com anywhere, then you might want to get concerned and try to verify where you got cgminer from in case you got a malicious version of it from a bad source.  In any case, be aware that just because the reverse lookup returns adobe.com doesn't mean adobe is truly involved in any way.  Note that I tried to forward lookup 3dns.adobe.com and got no result, so if you aren't able to follow the steps above to you have nothing to worry about, you might want to post the pool servers you are using in hopes that someone else can try to do the same.  Unfortunately, if they aren't, that doesn't rule out the legitimate or illegitimate DNS server possibilities.

ETA:  I just searched google.com for 3dns.adobe.com, and it would appear that you are running illegitimate Adobe software.  Most likely, either a crack has modified your hosts file or you have modified it manually.  In either case, the reverse lookup is most likely from cgminer using loopback (127.0.0.1) connections to communicate with itself (or you are solo mining) and 3dns.adobe.com is being returned on reverse lookups internal to Windows from the hosts file.  In that case, nslookup won't show you 3dns.adobe.com, but given that they are apparently activation servers, you quite possibly just outed yourself as a pirate.

[xjack]

...but given that they are apparently activation servers, you quite possibly just outed yourself as a pirate.

pwned.  

[nonServiam]

Hi, this is just an empty System. teamviewer, driver, qt, p2pool 11.4, python and cgminer 4.11.4. I then put on a fresh system.

Edit: avira virus is also reported it and always detect virus. but that should be normal for cgminer yet?

[nonServiam]

In the German forum they say just the Adobe Updater. I also have the Adobe Reader on it yet. Not more. I'll try it once.

[matt4054]

ETA:  I just searched google.com for 3dns.adobe.com, and it would appear that you are running illegitimate Adobe software.  Most likely, either a crack has modified your hosts file or you have modified it manually.  In either case, the reverse lookup is most likely from cgminer using loopback (127.0.0.1) connections to communicate with itself (or you are solo mining) and 3dns.adobe.com is being returned on reverse lookups internal to Windows from the hosts file.  In that case, nslookup won't show you 3dns.adobe.com, but given that they are apparently activation servers, you quite possibly just outed yourself as a pirate.

^^^ This! I was about to write it...

(Cons)piracy theory?

[os2sam]

cgminer 4.11.4. I then put on a fresh system.

Hopefully you meant 2.11.4?!?

[QiVX]

Hey guys, I can't seem to get CGMiner to work under scrypt no matter what I try. My cards (2 5970s WC'd) work perfectly fine with Bitcoin, but I try out scrypt mining for Litecoin nothing seems to be working

Also I have 4GB of RAM and am running a AMD Sempron 145 if that helps.

This is what I am faced with:



These are the parameters I am using:

Code:

cgminer.exe --scrypt  -o stratum+tcp://stratum.give-me-ltc.com:3333 -u USERNAME -p PASSWORD -I 9

Also I am using SDK 2.1 and Drivers 11.12

[QiVX]

Hello,

i have a question. I apologize as a precaution for my not so good english.

I was in the process monitor by accident. there I saw the cgminer is permanently connected to 3dns.adobe.com.

what does that mean?

CGMiner is connecting to 127.0.0.1 (localhost)
In your HOSTS file in Windows you have specified 127.0.0.1 to be 3dns.adobe.com

You must of installed some pirated patch or crack for some Adobe product which needed to do so.

[antome]

I am running windows 8, 13.1 drivers and latest app sdk. I am litecoin scrypt mining.

I have a 5770 (device 1) and 6770 (device 0), the 5770 I dedicate to mining and the 6770 is my desktop gpu with which I sometimes mine.

I don't have an issue with cgminer crashing, I have a problem with windows freezing :/

It's hard to say, but I don't believe it to be a driver crash specifically because none of my inputs or outputs respond (ie not even the caps lock light will show).

This is the most stable/good hash rate config I have so far:

Code:

cgminer -d 1 --scrypt --lookup-gap 2 --thread-concurrency 3100 --gpu-engine 800 --gpu-memclock 900 -I 17 -g 2 -w 256 --gpu-map 0:1,1:0 -o stratum+tcp://stratum2.wemineltc.com:3333 -u antome.g -p yyx

For some reason the sensors are backwards so they are remapped.
And for multi-gpu mining:

Code:

cgminer -d 0,1 --scrypt --lookup-gap 2 --thread-concurrency 3100 --gpu-engine 800 --gpu-memclock 900 -I 11,16 -g 2 -w 256 --gpu-map 0:1,1:0 -o stratum+tcp://stratum2.wemineltc.com:3333 -u antome.g -p yyx

I am running afterburner on default in the background.
It definitely has something to do with the GPU, because all apps using some form of hardware acceleration tend to freeze windows even with only mining on my "dedicated" secondary 5770 gpu.

Could it be that programs are requesting resources from the 5770? Can I stop that? Could it be a more fundamental problem ie PSU not giving enough amps? (Definitely has enough watts).
Changing values like intensity and clockrate do not help. Likewise thread concurrency but I have not tested this extensively because 3100 gives the most khash/s.
I tried setx GPU_MAX_ALLOC_PERCENT 90, I would assume that fixes the max allocation of resources, but it doesn't, and I'm probably doing it wrong :>

Any suggestions are appreciated.

[rav3n_pl]

Mining scrypt on GPU you are using for display is a bad idea. It will lag your desktop alot even on low intensity.
Also mixing 5xxx and 6/7xxx on one machine is not good - there is no porper driver/sdk combo to use.