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

Thank You!

I will do as suggested. I do have HEX16A. And i am playing with them for the moment

I will let you know if i find out what happens related to your code as long hex16 is not pushed to your git ...
Best

Absolutely do not mind at all. People auditing code is rare, and reporting meaningful bugs is the key to fixing them. What hardware do you have anyway, if you are having deadlock problems?

By the way, if you can reliably reproduce what appears to be a deadlock, make sure you have the absolute latest git, edit miner.h to enable LOCK_TRACKING
change line 765
to
and start cgminer logging the output and with the API enabled with for example the following extra options:
and when you see a deadlock send the command to get a summary of the lock status with
This should spew extra information into the logging file you generated called log.txt which will allow me to see how the deadlock was caused.

Thank you con!!!!

You do not mind to spam the thread now and then do you? I am finding bugs from time to times

I am joking..Thank you very much

Best

Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks.

If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem.

Yues i guess i do not understand the details but with latest git i am experiencing deadlocks

applog(LOG_WARNING, "Waiting for work to be available from pools.");
and everything is freezing

If i find out the reason i will let you know but something is not right

PS- Why did you disable Avalon lock lately - commit c3f13369961a7be6b19fe838ac4b5a7bc8592b16? If everything is ok the lock shall be ok also.

Anyway Thank you

I appreciate you looking over the code, however I guess you don't understand that pthread_cond_wait DROPS the mutex lock associated with it. You are supposed to called a pthread conditional wait holding a mutex lock and it picks up the lock again when the conditional or timeout is over.

Hello

I do think that this piece of code can create dead locks we are waiting to be awaken pthread_cond_wait holding lock mutex_lock(stgd_lock);

      mutex_lock(stgd_lock);
      ts = __total_staged();

      if (!pool_localgen(cp) && !ts && !opt_fail_only)
         lagging = true;

      /* Wait until hash_pop tells us we need to create more work */
      if (ts > max_staged) {
         pthread_cond_wait(&gws_cond, stgd_lock);
         ts = __total_staged();
      }
      mutex_unlock(stgd_lock);


From the other side wake_gws needs same lock and so on and so on....Con please take a look at it when you can

static void wake_gws(void)
{
   mutex_lock(stgd_lock);
   pthread_cond_signal(&gws_cond);
   mutex_unlock(stgd_lock);
}

A quick fix might be

      mutex_lock(stgd_lock);
      ts = __total_staged();
                 mutex_unlock(stgd_lock);

      if (!pool_localgen(cp) && !ts && !opt_fail_only)
         lagging = true;

      /* Wait until hash_pop tells us we need to create more work */
      if (ts > max_staged) {
         pthread_cond_wait(&gws_cond, stgd_lock);
         mutex_lock(stgd_lock);
                        ts = __total_staged();
                        mutex_unlock(stgd_lock);

      }

cbuchner1 has his own CUDAminer for nVidia cards at the moment, so it wouldn't be too much of stretch for someone else to do a dedicated miner for AMD cards that is more optimised for them rather than a catch-all program like cgminer. I also imagine once the Scrypt FPGA miners start being released soon, more attention might given to developing dedicated scrypt miners for them as well.

Personally, I'm waiting on the development of a USB stick scrypt miner that I saw in another thread somewhere, so I don't have to run my PC 24/7 and could possibly delegate to my Raspberry Pi.

I did not say or suggest that "nobody is mining altcoins". GPU mining for Bitcoins is dead. If you still want to mine altcoions then do so by using an older version that works. As for your question about ASIC hardware coming with their own built-in software the answer is no. Most do not have built-in mining software, which you could have found out with a little reading here on the forum.

If you want changes to the code, use an older version and modify it yourself or maybe someone will pick it up and maintain a fork.

I'm guessing you have profited much more than you have donated. If that is the case, then you really don't have a leg to stand on here and your getting way more than you paid for.

Please continue on with your temper tantrum. It is most entertaining to read.

The price of Bitcoin reflects that too, right?

Win7 64 bit.

That would be fine by me. I write software either because I enjoy doing it, or I earn money for it, or both. I'm writing/maintaining cgminer because I believe in bitcoin and I like to earn bitcoin. I unashamedly wrote the scrypt support for a generous bitcoin fee a long time ago so it was purely for the payment. I have no interest in altcoins so someone else should be maintaining it. Just because others have an interest in altcoins doesn't mean that I have to.

Are you seriously suggesting that nobody is mining altcoins? Just because GPU mining BTC isn't profitable doesn't mean shit. Hell, even with the drop in price, Litecoin mining can still net you a couple hundred a month with just two GPUs. Also, don't many ASIC miner rigs come with their own built-in mining software? Anyway, I highly doubt that maintaining and even tweaking scrypt support that is only a thousand lines of code is so arduous as to require substantial donations, but that is his choice. Someone will pick up the slack.

"The needs of the many outweigh the needs of the few or the one."

He is not getting any substantial donations to maintain the scrypt code and GPU mining is pretty much dead.

It is the correct decision IMO.

Might as well rename it assminer then.  

Seriously, though, mining BTC is dead for most except those lucky enough to have lots of BTC already or lots of disposable income to waste on over-priced embedded junk. Oh well, guess that's my problem.

I don't see why you drop scrypt, but that's your choice. No point in donating now, I suppose.

os2sam: What operating system ?. There was a fella on irc talking to conman who is able to run 243 AMUs on one instance of cgminer.

Scrypt and opencl support is being deprecated in the near future, and development for other coins is not going to happen, so sorry but there is no plan for improving support for other coins.

Thanks for the work on fixing scrypt share difficulty. For the most part, it has been working fine. However, I've been having issues with Novacoin p2pools.

I have been mining Novacoin through stratum p2pool at http://fsb4000.no-ip.biz:8336. It requires a public key (instead of the usual wallet address) for the username, check the Novacoin altcoin thread for further details.

I am using Xubuntu 13.10 on amd64 with 3 Sapphire 7950s using fglrx-updates 2:13.101-0ubuntu3 and gcc 4:4.8.1-2ubuntu3.

It more or less works nicely at git revision 8e5dc21ea68d3ec4198e577a1073a32fcddcbcb9, generating shares as expected and finally reporting >0 stats. However, it spams about finding blocks, which is wrong, but that is only a minor annoyance.

Pulling past that point results in core dumps, except in the case of the very latest pulls, which--for Novacoin p2pools only--results in 100% false positives for hardware errors on all GPUS. hard resetting back to 8e5dc21ea68d3ec4198e577a1073a32fcddcbcb9 yields a working cgminer for Novacoin p2pools).

Here is the output of cgminer compiled from the latest git pull on the aforementioned Novacoin p2pool:
The output continues with not a single good share being accepted.

I suspect the issue has to do with the share difficulty being very low, but that is how they (the Novacoin developers) want the p2pool configured. I will continue to use 8e5dc21ea68d3ec4198e577a1073a32fcddcbcb9 as it seems to work well enough, but hopefully this can be resolved in future cgminers.

I'll be sent one in the future, and then a driver will be developed for it. No idea of timeframe.

No chance you will implement nanofury support in the near future?

I really don't want to use the evil twin of cgminer.