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

Con, I'll grab 2.7.5 after I get some sleep, test it out and report back since I was one of the ones that was having the -10 intensity issue.

Thanks for all your hard work man.

If you simply enable core dumps it will at least tell you (with gdb) roughly where it is crashing with 'bt'
If you compile it -g and without -O2 the bt will even tell you the line of code and allow you to access the variables at each stack level.
i.e. you don't run it in gdb, you simply gdb the core file to see all the details of the state when it crashed.

I'm guessing you're getting the crashes once again when running through tor? I don't know the first thing about tor... yet.

No, the bug doesn't show up at all without adding the HW: counter fix.

It's only when I start identifying HW errors in the Icarus code (for CM1 also of course) that the HW: number jumps up a few thousand rarely (unexpectedly)
The mining side effect is so small that no one would notice it at all without the HW: counter.
Thus I want to know why it happens before I put the code out.
If you have time, come visit #cgminer FreeNode IRC and I'll give you a version that has the HW: counter but also spits out a lot of debug if it happens (so I can work out why)

2.7.5 crashes occasionally:

[2012-08-31 03:36:40] Accepted 7de59791.15d93a38 BFL 15 pool 0
 [2012-08-31 03:36:40] Accepted 2c6bbc81.dd42014b BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 1d1efc9b.b8563b1f BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 518e7a52.f2ccc827 BFL 20 pool 0
 [2012-08-31 03:36:40] Accepted 764d3e7d.cc1a8543 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 1764a65f.7da58c1e BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted fc3d419d.66247269 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 781d0fcc.7e3675a1 BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted dc8763e5.658a1a1a BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted 010403c4.3e8ba7f8 BFL 30 pool 0
 [2012-08-31 03:36:41] Pool 0 communication failure, caching submissionsSegmentation fault

I tried to get a backtrace of it, but when I run it in the debugger, it doesn't crash and I can't seem to run torify through gdb anyway, which is what I'm running cgminer through.

Which brings me to another request:  Can you make cgminer tor friendly, so you don't have to torify it?  I would love an option to be able to point cgminer to a tor server natively for all it's communications.  Would save a ton of hassle.

New version: 2.7.5, 31st August 2012

Survived a whole week without needing to give a hotfix update yay \o/.

This release is just a minor bugfix update. I've changed my build environment so it is less work to build binaries, so I have included an fpgaonly binary as well as the full feature binary. The windows binary is now compressed with 7z since it's getting so large, and will include a different set of DLLs due to it being built differently.


Human readable changelog

- Hopefully fixed the bug where dynamic intensity gets stuck at -10
- Much less pool-not-providing-work fast enough messages.
- Fixed share leakage to backup pools the way it was supposed to work.
- Properly detect SDK2.7 and choose optimal parameters for it.
- Remove the hardcoded worksize for 256 - it had the opposite effect with the new kernels
- Fix the rare occasion there are many new blocks detected in a row.
- Hopefully fixed the load balance and rotate strategies.


Full changelog

- Adjust opencl intensity when adjusting thread count to prevent it getting
pegged at a value below the minimum threads possible.
- miner.h max_hashes -> int64_t
- Keep the local block number in the blocks structs stored and sort them by
number to guarantee we delete the oldest when ageing the block struct entries.
- Use correct sdk version detection for SDK 2.7
- Revert "Pick worksize 256 with Cypress if none is specified."
- Test for lagging once more in queue_request to enable work to leak to backup
pools.
- There is no need to try to switch pools in select_pool since the current pool
is actually not affected by the choice of pool to get work from.
- Only clear the pool lagging flag if we're staging work faster than we're using
it.
- needed flag is currently always false in queue_request. Remove it for now.
- thr is always NULL going into queue_request now.

Yes it is, and we shall carry on making it longer.

This thread is getting Very long

There have been other suggestions, but assuming you use Linux you could limit the access only to localhost and then use stunnel or ssh with port forwarding to setup secure connections to the miner.

I'm running a debug version of it (yet again) since yesterday trying to find the cause of the loop (that doesn't really cause any problems but I need to know why first )

(I ran it for 3 or 4 days before and couldn't get the error to happen again)

If you (or anyone else) has enough CM1's, I can give you a binary that will turn on the debug when it hits 2000 HW errors and thus give me the debug that will probably say why it gets into the loop (and also gets out of it so it doesn't actually cause any problems)
... though I did a minor change yesterday ... but no idea if that is the cause ... bit not likely

Though I guess I should chase up spiccioli now since he was the one who regularly had the same error I've so far only had once.

No ... and clear text passwords make most people think something that isn't true (and shouldn't exist in any system)
Curl isn't available for the API since that would clash with cgminer using it with the pools and possibly cause problems there.
Any other encryption requires code at both ends ... though since curl allows ssl and requires an ssl library I guess that library could make it simple at the miner end - but complicate the monitor end.

Hey All! Thanks for creating an absolutely incredible mining program. You all rock!

I'm writing a monitoring program for my miner, I've IP address restricted access to the port, but I was wondering if there is any way of providing a password on access?

Cheers!

And I was just about to try this latest version, and I see that.  Damnit.

Set the intensity on those 2 cards.
They are dropping to I -10

I am currently on latest cgminer (2.7.4), mining with p2pool (3.1)...
Since 2.7.x CGMINER uses all my CPU (on multicore CPU system), but what is even more problematic is that in few minutes after start of cgminer, on system with 3 GPUs, only one of the GPUs still works at full power, while other two go to IDLE (mining only with few MH/s, instead of few hundreds). See the screenshot below...
What is curios is the message - "Pool 0 not providing work fast enough" ... but since p2pool v.3.1 is a month+ old, it was running without problems on older versions of cgminer...

Anyone experiencing the same? Any idea how to resolve this? Should I report it to p2pool thread as well?
Bitcoind is 0.6.3.


http://s11.postimage.org/s0ldetish/problem2012_08_30_151010.png

I don't think anyone got hurt. Just the other nearly same named miners developer that you mentioned the name of liked maybe 10 pages back to come on this thread and accuse ckolivas of all sorts of things. Moderator asked him to stop etc. I think Con just ment you hadn't read the whole thread not new as a bad thing. Con seems like a great person that makes great software. Helps people and tries really hard not to ignore anyone but is always quite patient with people.

Actually I shouldn't forget kano. He is also a developer for CGMiner and a great person. I learn a lot from kano too.

Yes, i am new. one-two month only. Chances are that I do not know. Did not want to hurt anyone, I'm sorry.

You haven't been here very long, have you?

wrong thread .........

i have used exactly this libusbx. I folow only steps from "windows-build.txt" from scratch.
I have used in the assembly of these options: --enable-ztex --disable-opencl --enable-scrypt --enable-cpumining
Nothing more.
CPU mining works.....
Q: And why you write "only ignore luke-jr"? He sayd it will be a solution in the next version of BFGminer for Ztex boards.