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

[-ck]

That bug is looking pretty consistent now. Thanks for the reports. I guess the spotfire period is not over yet for 2.6.x. I will put up a "stable" vs "development" link on the front page since it's still not up to 2.5 stability till I can sort it out.

[1715107969]

1715107969

[1715107969]

1715107969

[1715107969]

1715107969

[1715107969]

1715107969

[1715107969]

1715107969

[1715107969]

1715107969

[sgravina]

I was unaware of the reports in this thread.  But have discovered problems with 2.6.3 myself.

I upgraded my 12 computers to 2.6.3 yesterday.  Two of the computers would not mine correctly.  The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command.  When I reverted to version 2.5.0 they resumed working.

The other computers didn't have any issues.

10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5.  2 machines run Windows 7.  The failing computers were running Ubuntu 11.04.

[-ck]

I was unaware of the reports in this thread.  But have discovered problems with 2.6.3 myself.

I upgraded my 12 computers to 2.6.3 yesterday.  Two of the computers would not mine correctly.  The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command.  When I reverted to version 2.5.0 they resumed working.

The other computers didn't have any issues.

10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5.  2 machines run Windows 7.  The failing computers were running Ubuntu 11.04.

None of what you describe seems related to the other bug discussed here. You appear to have stumbled on something completely different, but what, I haven't got the faintest, unless you happened to be building from git and picked a bad commit to build from.

[sgravina]

I was unaware of the reports in this thread.  But have discovered problems with 2.6.3 myself.

I upgraded my 12 computers to 2.6.3 yesterday.  Two of the computers would not mine correctly.  The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command.  When I reverted to version 2.5.0 they resumed working.

The other computers didn't have any issues.

10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5.  2 machines run Windows 7.  The failing computers were running Ubuntu 11.04.

None of what you describe seems related to the other bug discussed here. You appear to have stumbled on something completely different, but what, I haven't got the faintest, unless you happened to be building from git and picked a bad commit to build from.

I am building from git.  I discovered this problem 12/6/12 9:00 pm EST and was building then.  All the Ubuntu machines are made the same way.  The four cards in the two misbehaving computers are: 3 5870's, 1 6850.

[-ck]

I was unaware of the reports in this thread.  But have discovered problems with 2.6.3 myself.

I upgraded my 12 computers to 2.6.3 yesterday.  Two of the computers would not mine correctly.  The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command.  When I reverted to version 2.5.0 they resumed working.

The other computers didn't have any issues.

10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5.  2 machines run Windows 7.  The failing computers were running Ubuntu 11.04.

None of what you describe seems related to the other bug discussed here. You appear to have stumbled on something completely different, but what, I haven't got the faintest, unless you happened to be building from git and picked a bad commit to build from.

I am building from git.  I discovered this problem 12/6/12 9:00 pm EST and was building then.  All the Ubuntu machines are made the same way.  The four cards in the two misbehaving computers are: 3 5870's, 1 6850.

Then I think you got that one dud commit which has since been fixed which caused massive damage. 8897e0657507072448f4e951ce1caadca15b4b30 was the dud commit and it was fixed by 3dd1658e1f3410dfdf00b267593a3cbe7041c645. Check git log to see what you're up to.

[-ck]

And now for something completely different...

New release - 2.6.4, 7th August 2012

Bugfixes, mainly for the crash. I couldn't stand knowing the latest release has a showstopper bug in it.

Human readable changelog

The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
The scrypt code was updated - now ALL results from a GPU are checked to see if they're valid and if not, instead of being submitted where they are guaranteed to be rejected, they register as hardware errors. This will make tuning your scrypt parameters easier as HW error count will rise if you've set the parameters too high.
A few more tweaks to the BFL code to make it more robust, especially on windows.
Updated miner.php
More information from the API.

Full changelog
- Convert the serial autodetect functions to use int instead of char to
enumerate devices.
- Make the serial open timeout for BFL generically 1 second on windows.
- Deuglify windows autodetect code for BFL.
- There is no point zeroing temperature in BFL if we fail to get a response, and
we should register it as a HW error, suggesting throttling.
- Update SCRYPT README with information about HW errors.
- Use the scrypt CPU code to confirm results from OCL code, and mark failures as
HW errors, making it easier to tune scrypt parameters.
- We may as well leave one curl still available per pool instead of reaping the
last one.
- Need to recheck the pool->curls count on regaining the pool lock after the
pthread conditional wait returns.
- Display reaped debug message outside mutex lock to avoid recursive locking.
- Add specific information when ADL detects error -10 saying the device is not
enabled.
- api.c update API start message and include port number
- miner.php ignore arg when readonly
- miner.php allow pool inputs: delete, addpool, poolpriority

[kano]

2.6.4
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.6.4a
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'

No Problems so far on my GPU, BFL or 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

I have also added a WinXP cgminer-2.6.4a.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

FYI: I've deleted all the other 2.6.* executables due to the known bugs in them

[Peao]

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

Thank you 

[Luke-Jr]

The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.

Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:

Code:

commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr <luke-jr+git@utopios.org>
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken

[bitcoindaddy]

2.6.4 still shows 2.6.3 in the display.

[Krak]

New release - 2.6.4, 7th August 2012

Does this one still require that stupid nonexistent file?

[nitrox]

REPORT :
windows 7 x64
driver 12.6
SDK 12.7
cgminer 2.6.4 - crash several times
--------------------------------------------------------------------------------
Description:
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x502101d7
Faulting module name: aticaldd.dll, version: 6.14.10.1741, time stamp: 0x4fd61f98
Exception code: 0xc0000005
Fault offset: 0x0003b678
Faulting process id: 0xe7c
Faulting application start time: 0x01cd74abd6926380
Faulting application path: D:\mining\cgminer\cgminer.exe
Faulting module path: C:\Windows\system32\aticaldd.dll
Report Id: 3e1c18e0-e0b6-11e1-8745-001d60c3d47b
--------------------------------------------------------------------------------
back to cgminer 2.6.2 - stable working

[kano]

The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.

Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:

Code:

commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr <luke-jr+git@utopios.org>
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken

lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)

[Luke-Jr]

The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.

Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:

Code:

commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr <luke-jr+git@utopios.org>
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken

lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)

Is this the first time you expressed your absolute ignorance of how git works in public?

For the sake of others who aren't programmers and have an obviously good reason to not understand how git works: Every commit in cgminer, including cgminer's master branch, also exists in bfgminer's repository when I do general "tree" merges for any other changes made to cgminer. What is canonical is the main bfgminer branch, is the chain of "first parents". Gitorious has a nice graph view of the tree where you can clearly see the canonical bfgminer branch (left-most), the cgminer branch (2nd left-most), and other feature/bugfix branches being merged in. You can also use your browser's find-in-page feature to locate 1946c80 (the original fix in BFGMiner 2.6.3) and c7bcad (the later cgminer duplication-of-effort).

[kano]

The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.

Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:

Code:

commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr <luke-jr+git@utopios.org>
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken

lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)

Is this the first time you expressed your absolute ignorance of how git works in public?
...

Hmm, when was the last one ... oh yeah I remember ... about 2 weeks ago ...
"I'm not a git export" ...
https://bitcointalk.org/index.php?topic=28402.msg1055547#msg1055547

So you fixed it and then applied ckolivas fix also?
Doubly fixed now in your miner Twice as fixed Good for you Be happy

[-ck]

2.6.4 still shows 2.6.3 in the display.

One of my binaries? Which one?

[gyverlb]

2.6.4 still shows 2.6.3 in the display.

One of my binaries? Which one?

http://ck.kolivas.org/apps/cgminer/cgminer-2.6.4-x86_64-built.tar.bz2

[-ck]

2.6.4 still shows 2.6.3 in the display.

One of my binaries? Which one?

http://ck.kolivas.org/apps/cgminer/cgminer-2.6.4-x86_64-built.tar.bz2

Thanks. It looks like the code was up to date, but I built it before pulling the version number change on the laptop, sorry about that. Reuploaded packages.

[joyyen]

is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !

[420]

is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !

well you should be able to with task schedule