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

[-ck]

Ok, one of my cards has a fan on it that is dying, but it has given me a chance to observe a behavior in cgminer that, I believe, needs tweaking, when it comes to auto-fan and auto-gpu.

I notice repeatedly, that the temps of my card are fluctuating a lot, and this is why...

SNIP

Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc....  is basically impossible. As per the the readme, the algorithm is an algorithm designed to work in most places well most of the time with most hardware, and will not get it right occasionally. Since GPUs mining are dead long term, I have zero interest in rewriting the algorithm or developing it further. It won't be long before GPU miners will be the poor relatives that give me nothing for further development when ASICs hit. Sad, since I really liked GPU mining, but that's the reality. Probably best to find some static fan speed workaround in your case.

[-ck]

Thanks. That is quite different actually. I've uploaded another set of executables into that temporary directory which may get us even further. Can you try them please? There is no way on earth it will compile on VS.

This is more like what I was expecting.  The debug version is much much larger than the production one.  But the output looks about the same...

Code:

cgminerdebug.exe caused an Access Violation at location 0040cb33 in module cgminerdebug.exe Reading from location 00000000.

Registers:
eax=00000000 ebx=624836d0 ecx=74712e09 edx=07c51858 esi=00000000 edi=00770ea0
eip=0040cb33 esp=03fff3d0 ebp=00801480 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
0040CB33  cgminerdebug.exe:0040CB33
7713FAF6  ntdll.dll:7713FAF6  RtlAnsiCharToUnicodeChar
77140093  ntdll.dll:77140093  LdrGetDllHandleEx
7713FD2F  ntdll.dll:7713FD2F  LdrGetDllHandle
76641A35  KERNELBASE.dll:76641A35  GetModuleFileNameW
7666734E  KERNELBASE.dll:7666734E  IsNLSDefinedString
76641CFB  KERNELBASE.dll:76641CFB  GetModuleFileNameW
7666734E  KERNELBASE.dll:7666734E  IsNLSDefinedString
76641CFB  KERNELBASE.dll:76641CFB  GetModuleFileNameW
74AF3362  kernel32.dll:74AF3362  RegKrnInitialize

How about Watcom?  I can dust it off and see if I can get it to run there.

Whatever you can try or think of is most welcome. These latest builds totally disable creating threads for either getting or submitting work, serialising all work of that kind so the idea that it might be due to generating too many threads is basically not the issue here. RtlAnsiCharToUnicodeChar suggests perhaps it's some string function overflow, but that's not very definitive about which one or where...

[Smoovious]

Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc....  is basically impossible.

What creating a different type of controller for every combination out there? I'm not even asking for that.

When the temp is below temp-target, don't slam the clock up to max, raise it one step at a time instead, and don't drop the fan fast, lower it one step at a time.

A couple if-statements, and that's it... why complicate it with pretending you'd have to make new algorithms for every card out there?

I know you think I'm stupid, but I'm not THAT stupid.

Believe it or not, this _is_ an issue that the auto-fan and auto-gpu aren't behaving as well as they should be, and all it is, is how fast it adjusts the fan and clock speed. There is NO reason why, just because the temp drops below temp-target minus hysteresis, that the clock speed has to be pushed back up to max, instead of being raised step by step the same as it does as if the temp is within the hysteresis.

-- Smoov

[Schleicher]

With Windows 8 there's a different result for some reason:

Code:

cgminer.exe caused an Access Violation at location 0040cb33 in module cgminer.exe Reading from location 00000000.

Registers:
eax=00000000 ebx=624836d0 ecx=77052ad2 edx=00879bb8 esi=00000000 edi=00852968
eip=0040cb33 esp=048ef3cc ebp=00876c60 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

Call stack:
0040CB33  cgminer.exe:0040CB33
004663A0  cgminer.exe:004663A0
0045917C  cgminer.exe:0045917C

Screenshot:

[P_Shep]

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

I know that, but Mt. Red couldn't possibly be going down as often as cgminer is saying. Also, I'm pretty sure us1.ozco.in is currently running just fine.

It is advantageous if a pool goes down for cgminer to not try to switch to another one that hasn't been working. 1 failed getwork is enough to do it. It's the same mechanism it uses on startup to see if a pool is alive. Overkill? Dunno, I wasn't expecting pools to fail sending getworks so often.

What if cgminer just queued up the next pool in line, rather than all of them?

[P_Shep]

Incidently, I'm now running a debug version (stock 2.9.3) on my router. Hopefully the core dump will tell us what's going on.

[vedalken254]

Yo guys... Just encountered this issue on 2.9.3 running on Ubuntu 12.04 x86_64:

[2012-11-15 21:09:43] List of devices:                   
 [2012-11-15 21:09:43]    0   Cypress                   
 [2012-11-15 21:09:43] Selected 0: Cypress                   
 [2012-11-15 21:09:43] Error -6: Creating Command Queue. (clCreateCommandQueue) <--- is the debug shits (cgminer -D -T --verbose)

Worked fine until today. Now it refuses to start. Should i try to re-install FGLRX?

[-ck]

Yo guys... Just encountered this issue on 2.9.3 running on Ubuntu 12.04 x86_64:

[2012-11-15 21:09:43] List of devices:                    
 [2012-11-15 21:09:43]    0   Cypress                    
 [2012-11-15 21:09:43] Selected 0: Cypress                    
 [2012-11-15 21:09:43] Error -6: Creating Command Queue. (clCreateCommandQueue) <--- is the debug shits (cgminer -D -T --verbose)

Worked fine until today. Now it refuses to start. Should i try to re-install FGLRX?

Code:

CL_OUT_OF_HOST_MEMORY                       -6

No idea why in your case, but that's what the error means.

[-ck]

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

I know that, but Mt. Red couldn't possibly be going down as often as cgminer is saying. Also, I'm pretty sure us1.ozco.in is currently running just fine.

It is advantageous if a pool goes down for cgminer to not try to switch to another one that hasn't been working. 1 failed getwork is enough to do it. It's the same mechanism it uses on startup to see if a pool is alive. Overkill? Dunno, I wasn't expecting pools to fail sending getworks so often.

What if cgminer just cued up the next pool in line, rather than all of them?

Doesn't really cut if for spilling of work to all the backup pools and other failover strategies. If the shit going on at the moment ever calms down I'll look to just do it silently and not call the backup pools dead visibly.

[-ck]

Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc....  is basically impossible.

What creating a different type of controller for every combination out there? I'm not even asking for that.

When the temp is below temp-target, don't slam the clock up to max, raise it one step at a time instead, and don't drop the fan fast, lower it one step at a time.

A couple if-statements, and that's it... why complicate it with pretending you'd have to make new algorithms for every card out there?

I know you think I'm stupid, but I'm not THAT stupid.

Believe it or not, this _is_ an issue that the auto-fan and auto-gpu aren't behaving as well as they should be, and all it is, is how fast it adjusts the fan and clock speed. There is NO reason why, just because the temp drops below temp-target minus hysteresis, that the clock speed has to be pushed back up to max, instead of being raised step by step the same as it does as if the temp is within the hysteresis.

The clock raising to the max was put in there to workaround a problem with the driver where it drops to low power during any relatively idle period and even if you try to set it to high speed it ignores you, and the return values from the driver reporting back its current speed get stuck at low speed confusing the feedback mechanism.

I'll think about a possible workaround, when time permits me to code once more.

[vedalken254]

Yo guys... Just encountered this issue on 2.9.3 running on Ubuntu 12.04 x86_64:

[2012-11-15 21:09:43] List of devices:                    
 [2012-11-15 21:09:43]    0   Cypress                    
 [2012-11-15 21:09:43] Selected 0: Cypress                    
 [2012-11-15 21:09:43] Error -6: Creating Command Queue. (clCreateCommandQueue) <--- is the debug shits (cgminer -D -T --verbose)

Worked fine until today. Now it refuses to start. Should i try to re-install FGLRX?

Code:

CL_OUT_OF_HOST_MEMORY                       -6

No idea why in your case, but that's what the error means.

Thanks Con. I re-installed the AMD APP SDK and the fglrx driver and then rebooted then ran aticonfig --initial -f then rebooted again and now it works again!

[live627]

I might have found a bug. Not sure,  though, and it might have been fixed and I never noticed...

CGMiner 2.6.4
Windows 7 x64
Catalyst 11.5

Crashes on start when both voltage is set and debug mode is enabled. I haven't looked into it further.

[rav3n_pl]

I might have found a bug. Not sure,  though, and it might have been fixed and I never noticed...

CGMiner 2.6.4
Windows 7 x64
Catalyst 11.5

Crashes on start when both voltage is set and debug mode is enabled. I haven't looked into it further.

Erm, DO NOT use outdated binaries?

[Askit2]

Code:

$ make
make  all-recursive
make[1]: Entering directory `/home/User/cgminer'
Making all in lib
make[2]: Entering directory `/home/User/cgminer/lib'
  GEN    signal.h
  GEN    string.h
make  all-recursive
make[3]: Entering directory `/home/User/cgminer/lib'
make[4]: Entering directory `/home/User/cgminer/lib'
  CC     memmem.o
  CC     sigaction.o
  CC     sigprocmask.o
  AR     libgnu.a
make[4]: Leaving directory `/home/User/cgminer/lib'
make[3]: Leaving directory `/home/User/cgminer/lib'
make[2]: Leaving directory `/home/User/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/User/cgminer/compat'
Making all in jansson
make[3]: Entering directory `/home/User/cgminer/compat/jansson'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/User/cgminer/compat/jansson'
make[3]: Entering directory `/home/User/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/User/cgminer/compat'
make[2]: Leaving directory `/home/User/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/User/cgminer/ccan'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/User/cgminer/ccan'
make[2]: Entering directory `/home/User/cgminer'
  CC     cgminer-cgminer.o
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
make[2]: *** [cgminer-cgminer.o] Error 1
make[2]: Leaving directory `/home/User/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/cgminer'
make: *** [all] Error 2

Got Yasm copied in and finally configure line didn't error.
Windows build.txt is missing this step entirely.
Did the Libcurl actually change between 2.7.5 and 2.9.3?
I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed.

I am more interested in how to fix it then why it happened though.

[-ck]

Code:

$ make
make  all-recursive
make[1]: Entering directory `/home/User/cgminer'
Making all in lib
make[2]: Entering directory `/home/User/cgminer/lib'
  GEN    signal.h
  GEN    string.h
make  all-recursive
make[3]: Entering directory `/home/User/cgminer/lib'
make[4]: Entering directory `/home/User/cgminer/lib'
  CC     memmem.o
  CC     sigaction.o
  CC     sigprocmask.o
  AR     libgnu.a
make[4]: Leaving directory `/home/User/cgminer/lib'
make[3]: Leaving directory `/home/User/cgminer/lib'
make[2]: Leaving directory `/home/User/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/User/cgminer/compat'
Making all in jansson
make[3]: Entering directory `/home/User/cgminer/compat/jansson'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/User/cgminer/compat/jansson'
make[3]: Entering directory `/home/User/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/User/cgminer/compat'
make[2]: Leaving directory `/home/User/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/User/cgminer/ccan'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/User/cgminer/ccan'
make[2]: Entering directory `/home/User/cgminer'
  CC     cgminer-cgminer.o
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
make[2]: *** [cgminer-cgminer.o] Error 1
make[2]: Leaving directory `/home/User/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/cgminer'
make: *** [all] Error 2

Got Yasm copied in and finally configure line didn't error.
Windows build.txt is missing this step entirely.
Did the Libcurl actually change between 2.7.5 and 2.9.3?
I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed.

I am more interested in how to fix it then why it happened though.

Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support.

The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows.

[rav3n_pl]

(...)
Got Yasm copied in and finally configure line didn't error.
Windows build.txt is missing this step entirely.
Did the Libcurl actually change between 2.7.5 and 2.9.3?
I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed.

I am more interested in how to fix it then why it happened though.

Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support.

The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows.

There is cure for windows: https://bitcointalk.org/index.php?topic=118288.msg1329247#msg1329247

[Askit2]

Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support.

The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows.

Wasn't trying to disagree I just ment that on the CFLAGS step I ended with at least one error and though it stated that it would run without the yasm in line something I still errored on both CFLAGS and MAKE.  Now after adding the exe (not super hard just picked up one from yasm.) I only get an error on the make. On the make I think earlier I noticed more errors then 1 and 2. It likely is my imagination though.

I will wait for people to test the git version and a newer one to come out.

Thanks for all your help!

[sharky112065]

Code:

$ make
make  all-recursive
make[1]: Entering directory `/home/User/cgminer'
Making all in lib
make[2]: Entering directory `/home/User/cgminer/lib'
  GEN    signal.h
  GEN    string.h
make  all-recursive
make[3]: Entering directory `/home/User/cgminer/lib'
make[4]: Entering directory `/home/User/cgminer/lib'
  CC     memmem.o
  CC     sigaction.o
  CC     sigprocmask.o
  AR     libgnu.a
make[4]: Leaving directory `/home/User/cgminer/lib'
make[3]: Leaving directory `/home/User/cgminer/lib'
make[2]: Leaving directory `/home/User/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/User/cgminer/compat'
Making all in jansson
make[3]: Entering directory `/home/User/cgminer/compat/jansson'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/User/cgminer/compat/jansson'
make[3]: Entering directory `/home/User/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/User/cgminer/compat'
make[2]: Leaving directory `/home/User/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/User/cgminer/ccan'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/User/cgminer/ccan'
make[2]: Entering directory `/home/User/cgminer'
  CC     cgminer-cgminer.o
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
make[2]: *** [cgminer-cgminer.o] Error 1
make[2]: Leaving directory `/home/User/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/cgminer'
make: *** [all] Error 2

Got Yasm copied in and finally configure line didn't error.
Windows build.txt is missing this step entirely.
Did the Libcurl actually change between 2.7.5 and 2.9.3?
I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed.

I am more interested in how to fix it then why it happened though.

Yasm is not needed anymore as CPU mining is no longer supported and the CPU code will be ripped out of Cgminer soon.

Referring to that windows-build.txt file you were talking about, did you modify the package config file for curl as directed?

Edit: It could be what C. Kolivas said, but I would check the package config file first.

[Smoovious]

The clock raising to the max was put in there to workaround a problem with the driver where it drops to low power during any relatively idle period and even if you try to set it to high speed it ignores you, and the return values from the driver reporting back its current speed get stuck at low speed confusing the feedback mechanism.

I'll think about a possible workaround, when time permits me to code once more.

Thank you...

From my observations, I only see it occur when the temp falls below the target-temp minus hysteresis, when the heat the sensors have picked up has finally dissipated enough. As long as the temp stays above target-temp minus hysteresis, it raises back up gradually again from the bottom range I specified.

If that helps narrow it down some.

-- Smoov

[Balthazar]

Does it support IPv6?