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

amt = amount (I think...). Possibly if i/o op partially succeeded. Tells you the amount of bytes that were transfered., Personally I have never seen anything else than 0
err = error code. This is specific to the function called.

depending on the trace err is werr or rerr to indicate if the error happened on read or write

For instance error returned for doing i/o with a USB device usually maps with libusb error codes that can be found at

/usr/include/libusb-1.0/libusb.h

ie:

LIBUSB_ERROR_TIMEOUT = -7,

Occationally the cgminer log says:


and my Jalapeno stops working.

Can anybody tell me what this (especially the codes err=..., amt=...) mean ?

Thanks in advance

Well it's failover not failsafe, I believe.

You use it by adding more than one pool to the command line.  After the miner starts go to your pool list and verify that they are all alive.  I would also switch to each one to verify that it actually works and that you entered everything correctly.

Some pools fail in a way that the mining node keeps sending the miner work so the mining software can't detect the outage.  I have no idea about Eligius though, so I don't know if that fits or not.
Sam

Hey everyone. I think I'm having some trouble with failsafe, and I can't seem to shake it!

LukeJr over at eligius said that the pool was working properly, so I assume this is on my side.

Yesterday, and last night, Eligius connection was interrupted. It then reassigned difficultly and sat connected instead of rolling over to my failsafe. This doesn't *seem* to be affecting my slush or BTCguild connections, but I have seen it happen when BTCguild is down.

If anyone could give me some insight or maybe some troubleshooting options for making failsafe work. I'd be insanely and infinitely

Thanks I suspected something like this. Time to open this beast and make place for an USB cable :-)

Has running the "gpu max alloc percent" worked for anyone when they were having issues?  How do I do it on windows without a .bat file, can I just open a command prompt and type it in?  Thanks, I'm looking for why I only get 30 khash with a 6570 no matter the settings I try

The p2pool blockchain data is massive and the power of the wrt703n in the avalon is pitiful. Presumably it's the extra workload of dealing with that that uses a lot more CPU. Also the latency of an Avalon sucks dicks on p2pool, throwing out about 3% of work when the block change is 30s (it used to be much worse at 10s). You can run the Avalon on a regular PC via a USB cable to not have CPU usage problems but that won't fix the latency issues, as it is a major Avalon design flaw. p2pool has improved to work with ASICs, but now the hardware needs to catch up.

I just noticed something a bit odd with cgminer on avalon and p2pool.
I compared CPU usage/load between mining on bitminter with stratum and mining on p2pool with stratum. Seemed pretty similar (with the obvious ~10min between Bitcoin blocks vs ~30s between p2pool shares).

With bitminter, cgminer uses ~12% of the CPU on the Avalon, with p2pool it uses ~65%. I forced a fixed difficulty of 64 on p2pool to try to help (the difficulty algorithm makes small changes often which could explain some additional processing) with no measurable effect. The resulting overall load is ~0.9 on p2pool and ~0.2 on Bitminter.

This is not an average with large peaks and low usage between them (that could be linked to new work every ~30s on p2pool), it's constant. Some people have reported Avalon freezes/crashes on p2pool and it might be due to a temperature problem: the poor CPU might not have been tested at a constant 60% usage. Give it an already toasty environment and add high CPU usage -> overheat.

This high CPU usage might point to some inefficiencies. I'm not yet mining full time on p2pool because preliminary results show only ~90% efficiency (which seems to imply a average ~3s latency somewhere). This latency might be a completely different problem though.

Hope it can help someone understand what is going on.

Check 3.1.1 changelog

Why is it not possible to use socks5 proxy with stratum pool since cgminer 3.1.1?
It worked fine with 3.1.0.

Thanks - good to know it is getting the desired result.

You definitely made a great job. I still see werr -7 from time to time but git version seems to cope way better with the situation than 3.3.1 did.

Everytime I see werr -7, after a few seconds, cgminer fallback in normal mode and all BEs are online and hashing!

-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git)
In your case it was sending work to the device.
Basically means it took too long (more than 200ms) to write to the device.
This can also be caused by device failure e.g. overheat
The code does a device reinitialise then will try again with a new work item.
i.e. I try to reset it and see if that fixes it.

Edit: ... no temperature sensors ... good design that one

Just do it

thanks Kano.

I think that I have spotted the commit you mention:

usbutils/icarus include more locking to usbdev access on June 25th. Almost right after 3.3.1 release date. I guess that it means the next release is coming soon.

I'm now running master-git.

I still have spurious

AMU7: Comms error (werr=-7 amt=0)

that come and leave but so far I have an uptime of half an hour and things feels better.

I'll report back tomorrow how the night went with the git version.

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

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=)
    at driver-icarus.c:384
384            icarus->usbdev->PrefPacketSize = AMU_PREF_PACKET;
(gdb) where
#0  0x000000000045acfb in icarus_initialise (icarus=icarus@entry=0x7f665c012fa0, baud=)
    at driver-icarus.c:384
#1  0x000000000045b6c8 in icarus_initialise (baud=, icarus=0x7f665c012fa0) at driver-icarus.c:888
#2  icarus_scanhash (thr=0x7f665c03aaf0, work=0x119b5e0, max_nonce=) 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 */

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

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

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.

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