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

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

(Cons)piracy theory?

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.

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?

pwned.  

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:.  Then you should use do a reverse lookup the same way with the IP address(es).  In a command prompt:.  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.

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?

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.

Is that the cause for this:


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.

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

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.

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)

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.

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.

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.

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

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.

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.

I've had a similar problem with cgminer from github on x86_64 debian 7.1 (wheezy) trying to get two AsicMiner USB eruptors to work (via Satechi 10-Port 5A USB 3.0 powered hub http://www.amazon.com/gp/product/B00B9KOCYA).

The setup works just fine with a single USB eruptor (either of them). When two are plugged in it behaves as you describe where the USB eruptors will each mine for a bit and then drop into standby mode (solid green LED) for a bit before starting up again. No errors in dmesg or anywhere. The effect for me was that mining with a single eruptor would give 330MH/s, but mining with two would give 215MH/s.

I finally solved this yesterday by downgrading to cgminer 3.1.1 (had to compile from source because libraries were missing in debian 7.1). They now both hash at full speed.

I want to use my 7970 machines for mining on ltc since they are useless now on btc for that i have a small usb devices running fine on cgminer

So i wanted to run another instance of cgminer pure solo mining with litecoin
But whatever i do it simply does not start
the weirdest of all is when i take the old reaper it runs ok and found a block

my conf in use :
{
"pools" : [
{
"name: : "Local",
"url" : "192.168.178.12:9337",
"user" : "[USER].[WORKER]",
"pass" : "[PASS]"
},
{
"name: : "Coinotron",
"url" : "coinotron.com:3334",
"user" : "[USER].[WORKER]",
"pass" : "[PASS]"
},
{
"url" : "newlc.ozco.in:9332",
"user" : "[USER].[WORKER]",
"pass" : "[PASS]"
}
],

"intensity" : "18",
"vectors" : "1",
"worksize" : "256",
"lookup-gap" : "2",
"thread-concurrency" : "21712",
"shaders" : "2048",

"gpu-engine" : "800-1000",
"gpu-fan" : "40-100",
"gpu-memclock" : "1200",
"gpu-powertune" : "10",
"gpu-vddc" : "1.100",
"temp-cutoff" : "95",
"temp-overheat" : "90",
"temp-target" : "75",

"api-port" : "4028",
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "1",

"log" : "5",
"queue" : "1",
"scan-time" : "60",
"temp-hysteresis" : "3",

"scrypt" : true,
"kernel" : "scrypt",
"kernel-path" : "/usr/local/bin"
}

the error i get after start cgminer :
[2013-07-16 23:36:02] Probing for an alive pool
[2013-07-16 23:36:02] Network difficulty changed to 0 (769.9kh/s)
[2013-07-16 23:36:02] No suitable long-poll found for http://192.168.178.12:9337

then it crashes or when i use the command for run it from command line it instant crash

Use a powered hub anyways. There was a known issue with Lancelot's and raspberry pi's USB interface and the fix was to use a powered hub.