OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[scifimike12]

Can't run CG miner...

"Too many values passed to set temp cutoff"

This is in 2.8.7

Just tried 2.10.2... same thing... window just closes. Help?

Also, Diablominer runs just fine on this box... I just would rather run CGminer.

Sounds like you have an additional character value in the conf file.  Either edit it out or delete the file and try running CGMiner again.

[1714268501]

1714268501

[1714268501]

1714268501

[1714268501]

1714268501

[1714268501]

1714268501

[1714268501]

1714268501

[-ck]

I hacked
static bool __clone_available(void)
{
        struct work *work, *tmp;
        bool cloned = false;

        mutex_lock(stgd_lock);
        if (!staged_rollable) {
                mutex_unlock(stgd_lock);
                goto out;
        }
        mutex_unlock(stgd_lock);
I do not know if it is OK but from what i can see there is race condition accessing staged_rollable or at least i think so
I will let you know if it crashesh again


For me it seems that stage_work called from  __clone_available crashed
From the other hand

static void stage_work(struct work *work)
{
   applog(LOG_DEBUG, "Pushing work from pool %d to hash queue", work->pool->pool_no);
   work->work_block = work_block;

static unsigned int work_block; is a global and it has been never locked, so maybe a instance of test_work_current was trying to change it
work->work_block = ++work_block; and race conditions occurred?

I am not both c and threads expert, but as long as i know each global var shall be locked when changed. Maybe when read also but it depends on gcc os and whatever. Is that true? If yes we have a potential code that can cause core dumps because of it

I do not how to lock work->work_block = ++work_block; so i am running same version with staged_rollable locked and i do expect within a day or two same crash to appear
10X

For the first function, you should note

Code:

/* Called with stgd_lock held */
static bool __clone_available(void)

So adding another lock does nothing and only risks recursive lock deadlocks or livelocks.

For the second value, work_block is simply an integer value and even if it's wrong can not lead to a crash since there's nothing being dereferenced at any stage.

[-ck]

It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was.

Seems like a solution in search of a problem.

Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations.

I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faac
This one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was.

The function you replaced works fine and does exactly what I wrote it to do 15 months ago.
Check and see if it was a block based on the block header difficulty.
... though as I said, it's way faster that your replacement - which most likely is code you just copied out of elsewhere (and now say it's yours)

Oddly enough that's still required in cgminer - I guess the clone doesn't need that any more
There is nothing to clean up except your retarded brain not being able to understand the simple original code I wrote.

I think there's a valid point here though. His version of your code is not the issue here but rather a problem with the hash when it hits the share_diff function in cgminer.

[Luke-Jr]

I hacked
static bool __clone_available(void)
{
        struct work *work, *tmp;
        bool cloned = false;

        mutex_lock(stgd_lock);
        if (!staged_rollable) {
                mutex_unlock(stgd_lock);
                goto out;
        }
        mutex_unlock(stgd_lock);
I do not know if it is OK but from what i can see there is race condition accessing staged_rollable or at least i think so
I will let you know if it crashesh again


For me it seems that stage_work called from  __clone_available crashed
From the other hand

static void stage_work(struct work *work)
{
   applog(LOG_DEBUG, "Pushing work from pool %d to hash queue", work->pool->pool_no);
   work->work_block = work_block;

static unsigned int work_block; is a global and it has been never locked, so maybe a instance of test_work_current was trying to change it
work->work_block = ++work_block; and race conditions occurred?

I am not both c and threads expert, but as long as i know each global var shall be locked when changed. Maybe when read also but it depends on gcc os and whatever. Is that true? If yes we have a potential code that can cause core dumps because of it

I do not how to lock work->work_block = ++work_block; so i am running same version with staged_rollable locked and i do expect within a day or two same crash to appear
10X

For the first function, you should note

Code:

/* Called with stgd_lock held */
static bool __clone_available(void)

So adding another lock does nothing and only risks recursive lock deadlocks or livelocks.

Someone might mention to Con that it is in fact called without the lock held, and that the deadlock occurred when stage_work (called by __clone_available) tried to lock the same lock.
I fixed this in BFGMiner (since 2.10.0) by staging the cloned work outside of the lock in clone_available.

[-ck]

I hacked
static bool __clone_available(void)
{
        struct work *work, *tmp;
        bool cloned = false;

        mutex_lock(stgd_lock);
        if (!staged_rollable) {
                mutex_unlock(stgd_lock);
                goto out;
        }
        mutex_unlock(stgd_lock);

For the first function, you should note

Code:

/* Called with stgd_lock held */
static bool __clone_available(void)

Meh the lock got lost in the rework for 2.10, will fix in git. This is likely your problem after all, thanks!

[loshia]

Guy's,
Thank you very much! Have a nice holidays, merry Christmas and a happy new year!

If something else pops up i will let you know. gdb never lies:)

Best

[-ck]

New release: 2.10.3 - 26th December 2012

What a difference xmas makes.


Human readable changelog:

When switching from a stratum pool to another one, the last few shares were dropped and the share submission failure message was displayed.
There may have been stratum messages waiting to be parsed and cgminer would only parse them once a new message was received. This fix could potentially give even lower rejects!
There is now a [Z]ero stats option under the display menu which resets all the visible statistics.
Fixed the best_share displayed bug.
The current pool target diff is now shown in the status line like so:

Code:

 Connected to au.ozco.in diff 2 with stratum as user ckolivas.0

The current block target diff is now shown in the status line like so:

Code:

 Block: 01f8c77ced4b9c2a...  Diff:3.37M  Started: [10:01:27]  Best share: 129

Block solve detection is now supported with scrypt mining as well (BLOCK! written at end of share and solved blocks listed under pool stats).
Fixed a crash with rolltime pools.
Stratum support for scrypt mining.


Full changelog:

- Do not give the share submission failure message on planned stratum
disconnects.
- Parse anything in the stratum socket if it's full without waiting. Empty the
socket even if a connection is not needed in case there are share returns.
- Provide a mechanism to zero all the statistics from the menu.
- Display the current pool diff in the status line.
- Display block diff in status line.
- Generalise the code for solving a block to enable block solve detection with
scrypt mining.
- Generate the output hash for scrypt as well and use the one function to set
share_diff.
- Use the flip80 function in regeneratehash and the correct sized hash array.
- Use one size for scratchbuf as a macro in scrypt.c
- Stage work outside of the stgd lock to prevent attempted recursive locking in
clone_available.
- share_diff needs to be performed on a BE version of the output hash to work,
leading to false best_share values as spotted by luke-Jr.
- Remove the unused sha224 functions.
- Use the flip functions in hashtest.
- Simplify the setting of the nonce data field in work on submitting nonces.
- Scrypt code does not enter the hashtest function.
- Go back to cloning available work under staged lock.
- Updated links to AMD APP SDK
- Updated link to ADL SDK
- scrypt_diff uses a uint64_t as well.
- Correct target for stratum support with scrypt mining.
- libztex: fixed a typo
- libztex: check returnvalue of libusb_claim_interface() and release the
interface in case of early exit

[kano]

cut/paste ...

2.10.3
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.3a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Yes I had to create a seperate git for the binaries since github has disabled the download feature

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.3a
chmod +x cgminer-2.10.3a
md5sum cgminer-2.10.3a
b0ce7640a66efd1e83a7bc31ea545703  cgminer-2.10.3a

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'

No problems so far (15 minutes) on my GPU, BFL or 'MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

MMQ+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
BFL (858MH/s) on OzCoin Stratum with fixed 8 diff (BFL now on 864 bitstream)

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

[bitcoindaddy]

Binaries no longer included?

[-ck]

Binaries no longer included?

You mean linux binaries I guess. I made them but forgot to upload them. There now.

[Schleicher]

I am a little bit confused.
What difficulty is this, 2.6M or 40?

Code:

      "target": "00000000000000000000000000000000000000000000000000fb650600000000",
      "data": "00000001bece016f6cd7b6168a5b686840c2184e4de9dadcb5b0fd269687d8a9cbcd25945179969c324587aeca65baba6f8c60eed93f96c2e4c66c5adcfc5e2c1560226650db22e91c0665fb00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"

This is getwork from my Litecoin client.
Cgminer thinks this is 2.6M difficulty.

[PatMan]

cut/paste ...

2.10.3
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.3a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Yes I had to create a seperate git for the binaries since github has disabled the download feature

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.3a
chmod +x cgminer-2.10.3a
md5sum cgminer-2.10.3a
b0ce7640a66efd1e83a7bc31ea545703  cgminer-2.10.3a

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'

No problems so far (15 minutes) on my GPU, BFL or 'MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

MMQ+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
BFL (858MH/s) on OzCoin Stratum with fixed 8 diff (BFL now on 864 bitstream)

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

Thanks again Kano. Does this also work on normal Ubuntu 11.04 by the way? Thinking of changing from windoze on my other rig too - cgminer runs soooo much more stable on Ubuntu....

[SAC]

cut/paste ...

2.10.3
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.3a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Yes I had to create a seperate git for the binaries since github has disabled the download feature

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.3a
chmod +x cgminer-2.10.3a
md5sum cgminer-2.10.3a
b0ce7640a66efd1e83a7bc31ea545703  cgminer-2.10.3a

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'

No problems so far (15 minutes) on my GPU, BFL or 'MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

MMQ+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
BFL (858MH/s) on OzCoin Stratum with fixed 8 diff (BFL now on 864 bitstream)

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

Thanks again Kano. Does this also work on normal Ubuntu 11.04 by the way? Thinking of changing from windoze on my other rig too - cgminer runs soooo much more stable on Ubuntu....

Should libraries used when compiling would be the same unless Xubuntu has done something crazy like change the base system for their distro instead of just the graphic environment like it should have done.

Edit: display driver and sdk used would have to be the 12.6 or newer as this has scrypt compiled in so you would need better than is available in that distro installed as well, you need to download then install newer version for it to work.

[-ck]

I am a little bit confused.
What difficulty is this, 2.6M or 40?

Code:

      "target": "00000000000000000000000000000000000000000000000000fb650600000000",
      "data": "00000001bece016f6cd7b6168a5b686840c2184e4de9dadcb5b0fd269687d8a9cbcd25945179969c324587aeca65baba6f8c60eed93f96c2e4c66c5adcfc5e2c1560226650db22e91c0665fb00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"

This is getwork from my Litecoin client.
Cgminer thinks this is 2.6M difficulty.

Check last FAQ in readme.

[kano]

...

Thanks again Kano. Does this also work on normal Ubuntu 11.04 by the way? Thinking of changing from windoze on my other rig too - cgminer runs soooo much more stable on Ubuntu....

Should libraries used when compiling would be the same unless Xubuntu has done something crazy like change the base system for their distro instead of just the graphic environment like it should have done.

Edit: display driver and sdk used would have to be the 12.6 or newer as this has scrypt compiled in so you would need better than is available in that distro installed as well, you need to download then install newer version for it to work.

It should just work on Ubuntu 11.04 since they have the same base.
The reason for the 11.04 binary is that 12.04 binaries will not run on 11.04 at all.
11.10 binaries will run on 11.04 using the link (hack) I mention in linux-usb-cgminer

However, scrypt will require SDK 2.6
Scrypt does actually work on SDK 2.4, but with abysmal performance.

[PatMan]

...

Thanks again Kano. Does this also work on normal Ubuntu 11.04 by the way? Thinking of changing from windoze on my other rig too - cgminer runs soooo much more stable on Ubuntu....

Should libraries used when compiling would be the same unless Xubuntu has done something crazy like change the base system for their distro instead of just the graphic environment like it should have done.

Edit: display driver and sdk used would have to be the 12.6 or newer as this has scrypt compiled in so you would need better than is available in that distro installed as well, you need to download then install newer version for it to work.

It should just work on Ubuntu 11.04 since they have the same base.
The reason for the 11.04 binary is that 12.04 binaries will not run on 11.04 at all.
11.10 binaries will run on 11.04 using the link (hack) I mention in linux-usb-cgminer

However, scrypt will require SDK 2.6
Scrypt does actually work on SDK 2.4, but with abysmal performance.

Cool, that's what I figured. I´ve tried a few different combinations of SDK's/drivers and ended up reverting back to the 11.12 driver & 2.1 SDK you mentioned in your guide every time, it´s the best performing & most stable setup I´ve found. I´ll tryout Ubuntu 11.04 on my other rig with the same configuration as soon as the SSD arrives I think. Nice one.

[jjiimm_64]

woooo hoooooo 49.4M

[Found Blocks] => 1
[Best Share] => 49402097

[-ck]

woooo hoooooo 49.4M

[Found Blocks] => 1
[Best Share] => 49402097

Nice!  Were you running PoT on ozcoin? If so, at what diff and did you check the pot calculator to see how much that one share was worth?
http://tradebtc.net/potcalc.php

[-ck]

New version: 2.10.4, 29th December 2012

Mainly a hotfix release supporting the upcoming stratum implementation in p2pool.


Human readable changelog:

p2pool is about to release their stratum support, and cgminer would just crash on it. This version fixes it.
It was possible to mine on a stratum pool before the actual stratum structures were set up depending on when the pool sent out its notify details after authorisation.
The WU: value was not being reset when Zero stats was being used.


Full changelog:

- Change the pool stratum socket buffer to be dynamically allocated to
accomodate any size coinbase and keep receiving data in recv line for up to 60s
if no end of line has been received.
- Differentiate socket full from sock full.
- Allow stratum to startup without notify but check it is valid before creating
stratum work.
- Do not try to generate stratum work unless the notify command has succeeded.
- Reset total diff1 shares when zeroing stats as well to show correct work
utility.

[kano]

cut/paste ...

2.10.4
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.4a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Yes I had to create a seperate git for the binaries since github has disabled the download feature

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.4a
chmod +x cgminer-2.10.4a
md5sum cgminer-2.10.4a
23876ee992bb28bb6f98d13c7a016efa  cgminer-2.10.4a

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'

No problems so far (15 minutes) on my GPU, BFL or 'MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

MMQ+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
BFL (858MH/s) on OzCoin Stratum with fixed 8 diff (BFL now on 864 bitstream)

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