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

Do i have to set the Kerneloption (-k ) to use the modified poclbm if a had an AMD 7xxxx with SDK 2.7 or does cgminer set it automatical?

cut/paste ...

2.7.2
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.7.2a
https://github.com/kanoi/cgminer/downloads

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'
I highlighted that coz the 2.7.2 release has different version numbers in the OpenCL for the modified GPU code.

No problems so far on my BFL or my 2xGPU+2xIcarus

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt

FYI:
 I included Luke-jr's (as ckolivas' release clearly says) Linux BFL flash code.
 I have no idea where he got the details from - BFL wouldn't tell me when I asked them long ago.
 The FPGA-README explains how to compile and use it

 It works for me with an error at the end, as I mentioned in the FPGA-README
 I also worked for someone else without an error, who has a BFL that doesn't do the strange things my BFL does
 I put my bitstream up to 896 and found it would throttle - so back down to 880 again and running fine.

---

I have also added a WinXP cgminer-2.7.2a.exe

This ONLY has BFL + ICA (as below) thus it doesn't need a computer with OpenCL on it
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce

You will most likely also need the windowsdlls.zip file there in my downloads since some of my *.dll might be slightly different to ckolivas

With your new-fangled get working, does scanhash still need to operate (send work)...(get result), or can it work now work (get previous result)...(send new work) ?

New version - 2.7.3, 23rd August 2012

LATEST STABLE IS 2.6.6! DON'T USE 2.7.3

Not happy with 2.7.1, NOR 2.7.2, NOR 2.7.3 but this is what we're up to:
Bugfixes for networking, dynamic mode, new kernels, updated miner.php, and a bfl flash utility for linux.

Full changelog:
- Minimise the number of getwork threads we generate.
- Pick worksize 256 with Cypress if none is specified.
- Give warning with sdk2.7 and phatk as well.
- Whitelist sdk2.7 for diablo kernel as well.
- Only keep the last 6 blocks in the uthash database to keep memory usage
constant. Storing more is unhelpful anyway.
- BFL Flash - always distribute source
- Increase kernel versions signifying changed APIs.
- BFL flash - include source in builds and more FPGA-README
- Check we haven't staged work while waiting for a curl entry before proceeding.
- Use atomic ops to never miss a nonce on opencl kernels, including nonce==0,
also allowing us to make the output buffer smaller.
- Remove compile errors/warnings and document compile/usage in FPGA-README
- bitforce-firmware-flash.c by Luke-jr
- Ignore the submit_fail flag when deciding whether to recruit more curls or not
since we have upper bounds on how many curls can be recruited, this test is
redundant and can lead to problems.
- API-README update cgminer version number
- API-README fix groups P: example mistake
- API-README add COIN and other edits
- gpu->hit should be reset on new work as well.
- Do not add time to dynamic opencl calculations over a getwork.
- miner.php allow 'coin' is custom pages

Okay I believe I've found the problem with 2.7.1 and pushed it to master git branch (this is not included in the test binary I uploaded).

Yeah I had this happen on all 21 of my rigs.  10 shut down CGMiner all at once, the other 11 shut it down about 20 minutes after.  Obviously something was triggering mass closure of CGMiner.  I reverted to 2.7.0 and they've all been running fine for 12 hours.  My debugging days are behind me so I don't have any clue why it closed down.

How do I get CGminer to output the log to a file so I can review it under (I'm using Win 7 x64).

No, once a pool is removed, because there may still be work "in flight" it still keeps a reference to the old pool around till those work items are complete. After a couple of minutes no more shares will be submitted to it. Thanks tho.

I saw another interesting glitch.  I disabled, then removed pool 4, leaving pools 0, 1, 2, and 3, with priorities to match, and my next share was submitted to, pool 5.  There hadn't been a pool 5 at all, so that was really weird, then it seemed to stop submitting good shares, so I quit and started over.  Obviously there's probably not enough information here to even point toward the problem, but on the off chance that an event like that could lead to an epiphany, I would post about it.  Regarding the git version, I'm not incredibly familiar with git and didn't have a lot of time to figure it out again.  Moreover, I was still waiting to see if the problem I saw within 15 minutes of adding pool 4 the first time happened again, and it didn't all day, since I was done with that pool, I just happened to stumble upon this.  In case this info is helpful, I'm still on a really old sdk, and I compiled with --enable-scrypt, which obviously won't function (as someone pointed out after I asked, and I may have previously known and forgotten).  Point is, I don't know if these non-scrypt bugs are hanging out in the scrypt modifications or not, but maybe they could be?  The only reason I'm not still on 2.4.(whatever the highest was) is because I was having high CPU usage in linux after pool problems, and finally decided to try to end them, 2.6.(whatever the highest was) still had that, and so did 2.7.0 and 2.7.1.  I probably need to find stable pool or just quit mining since all I have is a 5830.

I had this too, on 3 different rigs both Linux & Windows. With an invalid pool 0 it closes immediately after starting. On Linux I'm using latest git now, let's see if that helps.

Well as usual no one puts their hand up, so here's a windows binary to test instead for those having the refusing to stay on one pool problem:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

So I upgraded to 2.7.1 and I've been getting cgminer quiting after about an hour. It doesn't crash, it just closes itself.

hope someone can help with this problem.
this is my first time using cgminer. i have managed to get it working with one one of my gpu's. however when i have a second gpu plugged in i get some strange results. I can only have 2 gpu at a time due to space and heat.

i have one 5870 working fine in all configurations.
one 5770 only operates at about 50% of potential performance. circa 90-120MHs
one 5870 that fan goes ape shit and BSODs

i can run all these card fine with GUIminer. however i have some asic and fpga on order and wanted to get used to cgminer.

any suggestions.

Miners used to get this when there were a lot of weird network problems. I fixed it in BFGMiner, but it's back with the 2.7.0 changes. Perhaps my original fix might shed some light on the current problem.

Alas that was the bug I was trying to fix going from 2.7.0 to 2.7.1. If anyone's on git and want to give the latest git master a try there's one tiny change which might help, but it's a long shot.

I can confirm similar behavior as well in yet another scenario.  I added a 5th pool (I already had pools in positions 0 through 4) through the curses interface.  I then proceeded to switch to it.  Shortly thereafter, cgminer switched back to pool 0 (presumably due to a problem with pool 4), and then I started getting alive and down messages every few minutes but not submitting shares to pool 4 (I also started submitting shares to pools 1 and 2 álong with 0 in spite of --failover-only and 18 hours since launch of cgminer).  I deleted pool 4, added it again, switched to it again, and voila, cgminer is mining on it again.  Next time I may try disabling and re-enabling it instead of deleting it, however I can also report that it said disabled on the pool after I hit P before I deleted it.  I thought they were only supposed to go to disabled (vs dead) after a long string of rejects, and I didn't see any rejects.  I don't know if this additional information is helpful or not, but something is up...

ETA: I am using 2.7.1, I think the two quotes above are too, I just realized none of them indicate it in this post.

Not at all expected behaviour.

Ok, thanks for the answer

Because I don't care about LTC, the software to mine it is really awkward, newbies keep coming around expecting me to hold their hands and explain it to them when it is not remotely trivial, and it complicates cgminer code and support.

Seems to work now, thanks!

Why is that?