Author

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

sr. member
Activity: 383
Merit: 250
have you find something why cgminer stats go away after a longer term? (on y rigs on windows 64bit after 10-10.5 days cgminer don't show temp and fan speed, after quit and restart (only cgminer) all is okay)

They will tell you it is because you are remote controlling your computer. As in you are controlling your PC form another PC (VNC, Logmein, etc...)

For me that explanation is rubbish though. I use a KVM.

I too would like a valid explanation as to why this is happening.
sr. member
Activity: 457
Merit: 251
I just compiled the new cgminer direct from git using git clone and the steps recommended (./autogen.sh then CFLAGS="-O3 -Wall -march=native" ./configure)
I'm getting an incomprehensible bunch of data after a few minutes of mining (cgminer with -w 256 and --submit-stale shuts down and gives me this info):
Code:
00000000 00:00 0 
                  7f7175ebb000-7f71766b5000 r-xp 00000000 08:06 7210304                    /usr/lib/fglrx/libaticaldd.so
                                        7f71766b5000-7f71767b5000 ---p 007fa000 08:06 7210304                    /usr/lib/fglrx/libaticaldd.so
                                                              7f71767b5000-7f7176803000 rw-p 007fa000 08:06 7210304                    /usr/lib/fglrx/libaticaldd.so
    7f7176803000-7f71768c0000 rw-p 00000000 00:00 0
                                                    7f71768c0000-7f71768c5000 r-xp 00000000 08:06 4070088                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
        7f71768c5000-7f7176ac4000 ---p 00005000 08:06 4070088                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
                                            7f7176ac4000-7f7176ac5000 r--p 00004000 08:06 4070088                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f7176ac5000-7f7176ac6000 rw-p 00005000 08:06 4070088                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
                                    7f7176ac6000-7f7176ac8000 r-xp 00000000 08:06 4070080                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
                                                                      7f7176Aborted

Any ideas why?  Huh (I wasn't getting this with 2.2.1)
hero member
Activity: 686
Merit: 500
have you find something why cgminer stats go away after a longer term? (on y rigs on windows 64bit after 10-10.5 days cgminer don't show temp and fan speed, after quit and restart (only cgminer) all is okay)
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
1) does the binary also give you that?
oops no binary yet - sorry
I compiled it without checking if there was a binary.
(and my lowly 725Mh/s is running OK on 2.2.2)
Quote
2) If you must compile, did you start afresh?
3) If you didn't it's better to, but at least be sure you autogen'd and configure'd and make clean'd
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
With the latest version from git, I keep getting this:
Code:
(gdb) bt
#0  0x00007fae64776405 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fae64779680 in *__GI_abort () at abort.c:92
#2  0x00007fae647ace0b in __libc_message (do_abort=, fmt=) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007fae647b6656 in malloc_printerr (action=3, str=0x7fae6488d3e8 "double free or corruption (!prev)", ptr=) at malloc.c:6283
#4  0x00007fae647bb38c in *__GI___libc_free (mem=) at malloc.c:3738
#5  0x000000000040d4af in free_work (work=0x1573ee0) at cgminer.c:1550
#6  miner_thread (userdata=0x124eda0) at cgminer.c:3211
#7  0x00007fae6580ab50 in start_thread (arg=) at pthread_create.c:304
#8  0x00007fae648194ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()
Hmm... could be a race on the work item. Can you "git checkout a3e77937c8b8d924b2671aa4a77e9f13689ac64a", rebuild, and see if it goes away?
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
1) does the binary also give you that?
2) If you must compile, did you start afresh?
3) If you didn't it's better to, but at least be sure you autogen'd and configure'd and make clean'd
full member
Activity: 373
Merit: 100
With the latest version from git, I keep getting this:
Code:
(gdb) bt
#0  0x00007fae64776405 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fae64779680 in *__GI_abort () at abort.c:92
#2  0x00007fae647ace0b in __libc_message (do_abort=, fmt=) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007fae647b6656 in malloc_printerr (action=3, str=0x7fae6488d3e8 "double free or corruption (!prev)", ptr=) at malloc.c:6283
#4  0x00007fae647bb38c in *__GI___libc_free (mem=) at malloc.c:3738
#5  0x000000000040d4af in free_work (work=0x1573ee0) at cgminer.c:1550
#6  miner_thread (userdata=0x124eda0) at cgminer.c:3211
#7  0x00007fae6580ab50 in start_thread (arg=) at pthread_create.c:304
#8  0x00007fae648194ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
- Update example web miner.php to use new API commands
Anyone who used the old one this one should be interesting to look at once or twice Smiley
(I of course use it to view the status of my rig since it's all in one page)
Of course there are other more complex ones out there for pure display only
This one also happens to allow you to change everything that the API allows (unless I missed something Tongue)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version 2.2.2, source up for now, top post, binaries pending.

Changelog:
Version 2.2.2 - February 6, 2012

- Provide support for the submitold extension on a per-pool basis based on the
value being detected in a longpoll.
- Don't send a ping to a dynamic device if it's not enabled as that will just
enable it for one pass and then disable it again.
- Rewrite the convoluted get_work() function to be much simpler and roll work as
much as possible with each new work item.
- Roll as much work as possible from the work returned from a longpoll.
- Rolling work on each loop through the mining thread serves no purpose.
- Allow to stage more than necessary work items if we're just rolling work.
- Replace divide_work with reuse_work function used twice.
- Give rolled work a new ID to make sure there is no confusion in the hashtable
lookups.
- Remove now-defunct hash_div variables.
- Remove unused get_dondata function.
- Silence ADL warnings.
- Silence unused parameter warnings.
- Stagger the restart of every next thread per device to keep devices busy ahead
of accessory threads per device.
- Deprecate the --donation feature. Needlessly complex, questionable usefulness,
depends on author's server and a central pool of some kind, and was not heavily
adopted.
- It's devices that report back now, not threads, update message.
- Continue auto-management of fan and engine speeds even if a device is disabled
for safety reasons.
- No need to check we're highest performance level when throttling GPU engine
speed.
- Abstract out tests for whether work has come from a block that has been seen
before and whether a string is from a previously seen block.
- Probe but don't set the timeout to 15 seconds as some networks take a long
time to timeout.
- Remove most compiler warnings from api.c
- Add last share's pool info in cgpu_info
- Allow the OpenCL platform ID to be chosen with --gpu-platform.
- Iterate over all platforms displaying their information and number of devices
when --ndevs is called.
- Deprecate main.c
- Some networks can take a long time to resolve so go back to 60 second timeouts
instead of 15.
- Only enable curses on failure if curses is desired.
- Fix warnings in bitforce.c
- Bugfix: Need to open BitForce tty for read-write
- Fix various build issues.
- Modularize code: main.c -> device-cpu + device-gpu
- Fix phatk kernel not working on non-bitalign capable devices (Nvidia, older
ATI).
- Update poclbm kernel for better performance on GCN and new SDKs with bitalign
support when not BFI INT patching. Update phatk kernel to work properly for non
BFI INT patched kernels, providing support for phatk to run on GCN and non-ATI
cards.
- Return last accepted share pool/time for devices
- Display accepted share pool/time for CPUs
- Bug intensity always shows GPU 0
- Update example web miner.php to use new API commands
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
OK. So AFAIK there are 5 kernel settings we have to adjust here :

BFI_INT ( where can I see if this is on / off ? )
Fastloop ( where can I see if this is on / off ? )

Vectors
Worksize
Intensity

What is the long8 at the end of the .bin produced ?

Thanks !

Honestly, unless you are running 7000 series cards, you can leave all these at their defaults with the exception of "Intensity", which should be set to "d" for you desktop monitor, and 8 for dedicated mining cards.
hero member
Activity: 518
Merit: 500
OK. So AFAIK there are 5 kernel settings we have to adjust here :

BFI_INT ( where can I see if this is on / off ? )
Fastloop ( where can I see if this is on / off ? )

Vectors
Worksize
Intensity

What is the long8 at the end of the .bin produced ?

Thanks !
sr. member
Activity: 322
Merit: 250
We are bees, and we hate you.
Just started using this over GUI, and I must say, I am very impressed.
I bumped up from 1.8Ghash to 2.1. The improvement was definitely worth the few seconds of setup.  Grin
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?

That it does. Just looks a little strange.
I'll make it prettier
full member
Activity: 373
Merit: 100
Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?

That it does. Just looks a little strange.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Getting funny behaviour disabling a GPU within cgminer from current git:

Code:
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Enabled ALIVE
Thread 1: 6.2 Mh/s Enabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Disabled ALIVE
Thread 1: 6.2 Mh/s Disabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
[2012-02-05 23:29:25] Thread 1 being disabled
[2012-02-05 23:29:25] Thread 1 being re-enabled
[2012-02-05 23:29:26] Thread 0 being disabled
[2012-02-05 23:29:26] Thread 1 being disabled

This isn't 100% reproducible so far (happened 4/5 tries) - is this known/expected?
Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?
full member
Activity: 373
Merit: 100
Getting funny behaviour disabling a GPU within cgminer from current git:

Code:
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Enabled ALIVE
Thread 1: 6.2 Mh/s Enabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Disabled ALIVE
Thread 1: 6.2 Mh/s Disabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
[2012-02-05 23:29:25] Thread 1 being disabled
[2012-02-05 23:29:25] Thread 1 being re-enabled
[2012-02-05 23:29:26] Thread 0 being disabled
[2012-02-05 23:29:26] Thread 1 being disabled

This isn't 100% reproducible so far (happened 4/5 tries) - is this known/expected?
donator
Activity: 1218
Merit: 1079
Gerald Davis
Also, on a related note, maybe your processor can get 8MH/s and the 8MH/s extra isn't even coming from the video card.  If that is the case, cutting the CPU frequency in half would lower it to a 4 MH/s gain at a still much more expensive MH/W (although realistically, even if it is the GPU getting that, running the CPU 100% at half frequency will probably still draw enough power to make it a net loss).
Are you theorizing that my CPU is explicitly doing some of the work, as if I was CPU mining, or do you mean something more nuanced than that? I didn't think my CPU would be used for explicit mining unless I had it specifically enabled to do so. I'm carrying out the U experiments that you guys suggested as we speak, btw.
Only as one (very unlikely) possibility.  I have read that the 100% cpu bug is because AMD offloads some of the work to the processor to make a game run even faster (so why couldn't it do the same thing with hashing), but I have also read that it is how AMD was making sure the processor was instantly ready when the video card finishes its task (in which case it wouldn't be doing that).

No.  No hashing is offloaded to CPU.  If you enable CPU mining it will operate as a seperate OpenCL device.  100% CPU bug isn't work being done it is just clock cycles being wasted.
donator
Activity: 798
Merit: 500
Note also that you are having it being disabled and reading OFF. There is only one place in the code where cgminer does this itself - when it hits the thermal cutoff limit. Now it is possible there is some code convolution issue going on somehow that makes the fan not rise when one of the GPUs is being restarted. Note that your bug report shows thread 2 being idle (which would be GPU 1) and then it proceeds to disable threads 4 and 5 (being GPU 2)... Interesting... I'll audit the code, but perhaps try it without auto-fan on, setting what you know to be a safe static fan speed and see if the problem persists.

Running 10+ hours without auto-fan and no errors. I'll update if I get one, but looks promising.
newbie
Activity: 78
Merit: 0
Im runnung Debian 6...

I gave up messing with init scripts that start screen sessions and put this in my /etc/rc.local instead
Code:
su - user -c "/path/to/cgminer/start/script.sh"

Quote
Oh, and i use command line arguments, because either on windows or linux, even after saving the config, it ignores me Sad (cgminer always asks for input)

This is usually because you have a syntax error in your config.  You can see what the errors are if you specify the config.

Code:
cgminer -c ~/.cgminer/cgminer.conf

I don't know why it is built this way.  IMO, when you fail to parse a config, you should fail out, not act like there was no config.

Thx about the config, i fixed it, much nicer now XD

--
Putting

Code:
su - rcocchiararo -c "/home/rcocchiararo/bitcoin/startcg.sh"

in rc.local seems to do nothing.

Running that from a "root terminal" (inside rcocchiararo GUI loggin) nets me a CPU mining session

Code:
[2012-02-05 12:18:17] Error: Getting Device IDs (num)
[2012-02-05 12:18:17] clDevicesNum returned error, none usable
[2012-02-05 12:18:17] Started cgminer 2.1.2

My script has:

Code:
#!/bin/bash
export AMDAPPSDKROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export AMDAPPSDKSAMPLESROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export LD_LIBRARY_PATH=${AMDAPPSDKROOT}lib/x86:${LD_LIBRARY_PATH}

export DISPLAY=:0

cgminer 2>>/var/log/cgminer.log


Maybe something from my "exports" is not ok ? i mean, just running "cgminer" from a terminal with my user (rcocchiararo) makes it work. (i once had the exports in .bashrc, but i no longer do).

also, i believe, at least on my debian system, it wont work to have that in rc.local, because it would be similar to double clicking my script and telling it to "run" instead of "run in terminal". If i do that, this is what happens:

Code:
[2012-02-05 12:02:55] Started cgminer 2.1.2
[2012-02-05 12:02:56] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
Error opening terminal: unknown.

I tried using rc.local to launch screen, but similar things happen, i THINK i got it to run, but it was only with CPU (manually i can confirm it, unless i run it from my users terminal).

Maybe the fact that root is unable to login with GUI in debian (at least debian 6) causes cgminer some headaches ?

I tried:

Code:
su - rcocchiararo -c "/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo"

Still, the last "rcocchiararo" seems to do nothing, because i changed that to "pepe" and i even ran:

Code:
/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh pepe

And the user who was running cgminer according to "top" was the one who launched the command (rcocchiararo, not pepe).

Im runnung Debian 6

With the following script, i understand that i get the same thing you indicated:

Code:
#! /bin/sh
### BEGIN INIT INFO
# Provides:          cgminer
# Required-Start:    $all
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mining
# Description:       Start BTC Mining
### END INIT INFO

script
  sleep 15
  cd /home/rcocchiararo/bitcoin
  exec /usr/bin/screen -dmS Miner su -c /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo
end script

This won't work as a sh script because the script keyword is an Upstart conf file function. You would want to take out both script/end script. I don't know offhand if Debian has Upstart but if it does then the best practice would be to use that by putting this as a conf file in /etc/init. If it doesn't then you could rewrite it as a script by removing the "script / end script" and taking out exec so it just calls screen. I don't think exec is a sh command either. Upstart conf file is not the same as a script.

The cgminer config writer doesn't write a fully working config unfortunately. You have to tweak some values - particularly zero ones. My version here does actually write a working config even with engine/memory values that work. But my version of the code is considered too dangerous by ckolivas to include in the mainline since it reads current ADL values to put in the config. There may be instances/cards where it causes problems - for my 5830s it works ok.

I thought that might be the case, thats why i tried with and without script/exec, and i still failed Sad

-------------

EDIT: success!

Finally, by setting a "startup application" to run:

Code:
/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo

Now my home server mines after rcocchiararo auto logins (that was already configured, but without screen, i had the "no terminal" issue.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I had two rigs today with "dead" status on the gpu's (5850's on win x64), with error messages saying "Failed to reinit GPU thread" and "Thread <#> no longer exists" on 2.2.1. The strange thing is that it seems to have actually happened at the same time in both rigs (they were mining on the same pool, different workers, reported both dead for 10h). Could this be related to some pool communication bug?
Yep, it sure could.

(no, I have no idea where or how though)
Jump to: