OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 791.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ancow on August 26, 2011, 10:20:37 AM

Found the problem. It has to do with the fact that I hadn't changed to the cgminer directory when I was still on battery:

The problem is that cgminer uses whatever crud malloc returns and simply appends the path of the install directory. The following patch fixes this for me:

Code:

--- cgminer-git/main.c  2011-08-26 10:18:44.314759040 +0200
+++ cgminer_build/main.c        2011-08-26 16:31:27.905487304 +0200
@@ -4495,7 +4495,7 @@
        sigaction(SIGINT, &handler, &inthandler);
 
        opt_kernel_path = malloc(PATH_MAX);
-       strcat(opt_kernel_path, CGMINER_PREFIX);
+       strcpy(opt_kernel_path, CGMINER_PREFIX);
 
        // Hack to make cgminer silent when called recursively on WIN32
        int skip_to_bench = 0;

Well spotted, thanks.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zaytsev on August 27, 2011, 11:59:01 AM

Code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                              
  682 user      39  19 1915m  37m  11m S  389  0.5   4944:21 /opt/cgminer/bin/cgminer --algo auto --cpu-threads 4 --gpu-threads 1 ...

I noticed this already with 1.5.3, which I left running for awhile and got like 29g VIRT at some point, but now the history repeats itself with 1.6.0. It really looks like if there were a memleak somewhere that is not fixed. It's not a ncurses thing, I am still running the text interface, because the WINCH bug is back again in 1.6.0. Also, this doesn't manifest itself if CPU mining is disabled and doesn't depend on which algorithm exactly one does use.

Ah, knowing it's only with cpu mining will help. I'll investigate further.

zaytsev

newbie

Activity: 59

Merit: 0

Code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                              
  682 user      39  19 1915m  37m  11m S  389  0.5   4944:21 /opt/cgminer/bin/cgminer --algo auto --cpu-threads 4 --gpu-threads 1 ...

I noticed this already with 1.5.3, which I left running for awhile and got like 29g VIRT at some point, but now the history repeats itself with 1.6.0. It really looks like if there were a memleak somewhere that is not fixed. It's not a ncurses thing, I am still running the text interface, because the WINCH bug is back again in 1.6.0. Also, this doesn't manifest itself if CPU mining is disabled and doesn't depend on which algorithm exactly one does use.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: phase on August 27, 2011, 02:57:38 AM

Quote from: -ck on August 26, 2011, 11:58:55 PM

No it should just work from the directory like it always did. HOWEVER if you have old .cl files in /usr/bin it might be using those. If you do make install with the binary version it will end up in /usr/bin (that's why I included the entire build tree this time instead of a stripped down tarball).

OMG what a total fail! I just downloaded and unpacked, copied my configuration and started with the usual scripts... Tried fiddling with config, then your suggestions, didn't work. Unfortunately, I failed to notice that I had downloaded the *source* release, no wonder the new terminal stays blank... Cheesy

Nice going phase Cool

Thanks though! Works like a charm!

We all have days like this Cheesy

phase

newbie

Activity: 49

Merit: 0

Quote from: -ck on August 26, 2011, 11:58:55 PM

No it should just work from the directory like it always did. HOWEVER if you have old .cl files in /usr/bin it might be using those. If you do make install with the binary version it will end up in /usr/bin (that's why I included the entire build tree this time instead of a stripped down tarball).

OMG what a total fail! I just downloaded and unpacked, copied my configuration and started with the usual scripts... Tried fiddling with config, then your suggestions, didn't work. Unfortunately, I failed to notice that I had downloaded the *source* release, no wonder the new terminal stays blank... Cheesy

Nice going phase Cool

Thanks though! Works like a charm!

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: phase on August 26, 2011, 11:50:45 PM

Hmm, Ubuntu 64bit binaries were working fine for me on Linuxcoin up until now, 1.6.0 won't start. Is this because of the make install changes? Do I have to run make install from the directory, even for the binary release? And where do the files end up, where do I put configuration files, and what about newer versions? Will these automatically overwrite the previous binary from now on?

No it should just work from the directory like it always did. HOWEVER if you have old .cl files in /usr/bin it might be using those. If you do make install with the binary version it will end up in /usr/bin (that's why I included the entire build tree this time instead of a stripped down tarball).

The LT

full member

Activity: 186

Merit: 100

I have a small request, if I may.

Can a version string be added to the syslog output? Right now it starts with "Testing pool" and it would be really handy to start with "cgminer v.1.6.0 started". It already has a version string in the ncurses interface so it should be a trivial addition.

Thank you,

phase

newbie

Activity: 49

Merit: 0

Hmm, Ubuntu 64bit binaries were working fine for me on Linuxcoin up until now, 1.6.0 won't start. Is this because of the make install changes? Do I have to run make install from the directory, even for the binary release? And where do the files end up, where do I put configuration files, and what about newer versions? Will these automatically overwrite the previous binary from now on?

ancow

full member

Activity: 373

Merit: 100

Found the problem. It has to do with the fact that I hadn't changed to the cgminer directory when I was still on battery:

Code:

[2011-08-26 16:24:02] Testing pool http://127.0.0.1:8336                    
[2011-08-26 16:24:02] Popping work to stage thread                    
[2011-08-26 16:24:02] Popping work to work thread                    
[2011-08-26 16:24:02] Successfully retrieved and deciphered work from pool 0 http://127.0.0.1:8336                    
[2011-08-26 16:24:02] Pushing pooltest work to base pool                    
[2011-08-26 16:24:02] Pool 0 http://127.0.0.1:8336 active                    
[2011-08-26 16:24:02] Pushing ping to thread 0                    
[2011-08-26 16:24:02] Init GPU thread 0                    
[2011-08-26 16:24:02] Discarded 0 stales that didn't match current hash                    
[2011-08-26 16:24:02] List of devices:                    
[2011-08-26 16:24:02] Pushing work to getwork queue                    
[2011-08-26 16:24:02]   0       Redwood                    
[2011-08-26 16:24:02] Selected 0: Redwood                    
[2011-08-26 16:24:02] Popping work to stage thread                    
[2011-08-26 16:24:02] Preferred vector width reported 4                    
[2011-08-26 16:24:02] Max work group size reported 256                    
[2011-08-26 16:24:02] Unable to open phatk110817.cl or 
                                                       $��/home/XXX/bin/phatk110817.cl for reading                    
[2011-08-26 16:24:02] Failed to init GPU thread 0                    
[2011-08-26 16:24:02] Init GPU thread 1                    
[2011-08-26 16:24:02] List of devices:                    
[2011-08-26 16:24:02]   0       Redwood                    
[2011-08-26 16:24:02] Selected 0: Redwood                    
[2011-08-26 16:24:02] Preferred vector width reported 4                    
[2011-08-26 16:24:02] Max work group size reported 256                    
[2011-08-26 16:24:02] Unable to open phatk110817.cl or 
                                                       $��/home/XXX/bin/phatk110817.cl for reading                    
[2011-08-26 16:24:02] Failed to init GPU thread 1                    
[2011-08-26 16:24:02] 2 gpu miner threads started                    
[2011-08-26 16:24:02] 0 cpu miner threads started, using SHA256 '4way' algorithm.

The problem is that cgminer uses whatever crud malloc returns and simply appends the path of the install directory. The following patch fixes this for me:

Code:

--- cgminer-git/main.c  2011-08-26 10:18:44.314759040 +0200
+++ cgminer_build/main.c        2011-08-26 16:31:27.905487304 +0200
@@ -4495,7 +4495,7 @@
        sigaction(SIGINT, &handler, &inthandler);
 
        opt_kernel_path = malloc(PATH_MAX);
-       strcat(opt_kernel_path, CGMINER_PREFIX);
+       strcpy(opt_kernel_path, CGMINER_PREFIX);
 
        // Hack to make cgminer silent when called recursively on WIN32
        int skip_to_bench = 0;

xcooling

member

Activity: 145

Merit: 10

Error with 6970 + 5870.. cgminer will not use both cards together.

Quote from: sharky112065 on August 25, 2011, 10:19:45 PM

1.5.8 crashes on me if the window has focus and I hit "ctrl ctrl (number of pc)" on my keyboard to use my kvm to switch pc's. If I click on the desktop so that cgminer does not have focus, then it never crashes.

Also I have 1 6970 and 3 5870's in one computer and cgminer will not use the 6970. It does however use the other 5870's provided I exit after the first run and do not delete the bin files before relaunching cgminer.

Edit: It only creates one bin file. The cypress one. Never creates the Camen one.

If there are 4 GPU's in a computer (all the same GPU type) only the last two start up and the other 2 give errors complaining about zero length bin files. If I exit cgminer and remove the line that deletes the .bin file from the folder, and start cgminer back up it works ok with all 4 GPU's. (Again running on Windows 7:

Also on Windows if you try to enable or disable a GPU from within cgminer it stops responding and the window shuts down.

Am I posting these bugs in the correct place?

Yeah, having the same issues with 6970+5870

ancow

full member

Activity: 373

Merit: 100

Quote from: -ck on August 26, 2011, 07:21:24 AM

* ckolivas adds it to the list of 2^32 things he needs/wants to do.

I see you need some more work... :-P
Seriously, though, it isn't really important to me, so take your time. As I said, just pointing stuff out.

* ancow goes back to writing test cases... *puke*

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ancow on August 26, 2011, 07:18:10 AM

I will as soon as the battery is charged and I'm off work. Until then, I was mainly trying to point out the segfault and the somewhat misleading message about the thread being idle for 60s.
(I kinda assume that the GPU is refusing to start because of being on battery, perhaps even because the battery was low; it works fine otherwise.)

Ah right, yes that is misleading and needs attending to at some stage.

* ckolivas adds it to the list of 2^32 things he needs/wants to do.

ancow

full member

Activity: 373

Merit: 100

I will as soon as the battery is charged and I'm off work. Until then, I was mainly trying to point out the segfault and the somewhat misleading message about the thread being idle for 60s.
(I kinda assume that the GPU is refusing to start because of being on battery, perhaps even because the battery was low; it works fine otherwise.)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

If it's not starting initially it will not start later on. You need to find out why it's not starting in the first place so start it with the -T -D options as well.

ancow

full member

Activity: 373

Merit: 100

Latest git. When I start cgminer on my laptop while on battery, GPU 0 starts out disabled. When I try to enable it, the following happens:

Code:

 cgminer version 1.6.0 - Started: [2011-08-26 13:55:05]
--------------------------------------------------------------------------------
 [(5s):0.0  (avg):0.0 Mh/s] [Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m]
 TQ: 0  ST: 2  SS: 0  DW: 0  NB: 1  LW: 0  LO: 0  RF: 0  I: 0
 Connected to http://swepool.net:8337 with LP as user XXX
 Block: 000007292b810580b00785b3f7d048c7...  Started: [13:55:05]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: [0.0 / 0.0 Mh/s] [Q:0  A:0  R:0  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------

[2011-08-26 13:55:27] Thread 0 idle for more than 60 seconds, GPU 0 declared SICK!
[2011-08-26 13:55:27] Attempting to restart GPU
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffecbf3700 (LWP 7573)]
0x000000000040aa9e in reinit_gpu (userdata=0xd83710) at main.c:4022
4022                    if (!pthread_cancel(*thr->pth)) {
(gdb) bt
#0  0x000000000040aa9e in reinit_gpu (userdata=0xd83710) at main.c:4022
#1  0x00007ffff796eb40 in start_thread (arg=) at pthread_create.c:304
#2  0x00007ffff726d36d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#3  0x0000000000000000 in ?? ()

Note that the program hasn't been running for 60s, but I still get the message "Thread 0 idle for more than 60 seconds, GPU 0 declared SICK!".

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

New release 1.6.0. (links in top post)

Executive summary of user visible changes:
- cgminer now stores a mini-database of every new block as it comes in and uses that to look up if the work is from an old block, or a new block has appeared on the network. This means it's better than ever at detecting when there's been a block change before longpoll has occurred, and will only discard work that it knows for sure belongs to an old block, and can synchronise block changes across multiple pools. Summary: EVEN LOWER REJECTS.
- cgminer now sorts all its staged work by time to be able to spend as much time as possible on work before it expires (especially important with lots of rolltime work).
- New CPU mining code for faster sse2 mining on 64bits and now has sse2 assembly on 32 bits as well (not working on the windows build)
- make install now stores where the binaries have been installed and can look for the kernels properly without needing to be run from the cgminer directly, or the -K option allows you to specify where you want it to read the kernels from.

Full changelog:
- Make restarting of GPUs optional for systems that hang on any attempt to
restart them. Fix DEAD status by comparing it to last live time rather than
last attempted restart time since that happens every minute.
- Move staged threads to hashes so we can sort them by time.
- Create a hash list of all the blocks created and search them to detect when a
new block has definitely appeared, using that information to detect stale work
and discard it.
- Update configure.ac for newer autoconf tools.
- Use the new hashes directly for counts instead of the fragile counters
currently in use.
- Update to latest sse2 code from cpuminer-ng.
- Allow LP to reset block detect and block detect lp flags to know who really
came first.
- Get start times just before mining begins to not have very slow rise in
average.
- Add message about needing one server.
- We can queue all the necessary work without hitting frequent stales now with
the time and string stale protection active all the time. This prevents a
pool being falsely labelled as not providing work fast enough.
- Include uthash.h in distro.
- Implement SSE2 32 bit assembly algorithm as well.
- Fail gracefully if unable to open the opencl files.
- Make cgminer look in the install directory for the .cl files making make
install work correctly.
- Allow a custom kernel path to be entered on the command line.
- Bump threshhold for lag up to maximum queued but no staged work.
- Remove fragile source patching for bitalign, vectors et. al and simply pass it
with the compiler options.
- Actually check the value returned for the x-roll-ntime extension to make sure
it isn't saying N.
- Prevent segfault on exit for when accessory threads don't exist.
- Disable curl debugging with opt protocol since it spews to stderr.

sharky112065

sr. member

Activity: 383

Merit: 250

1.5.8 crashes on me if the window has focus and I hit "ctrl ctrl (number of pc)" on my keyboard to use my kvm to switch pc's. If I click on the desktop so that cgminer does not have focus, then it never crashes.

Also I have 1 6970 and 3 5870's in one computer and cgminer will not use the 6970. It does however use the other 5870's provided I exit after the first run and do not delete the bin files before relaunching cgminer.

Edit: It only creates one bin file. The cypress one. Never creates the Camen one.

If there are 4 GPU's in a computer (all the same GPU type) only the last two start up and the other 2 give errors complaining about zero length bin files. If I exit cgminer and remove the line that deletes the .bin file from the folder, and start cgminer back up it works ok with all 4 GPU's. (Again running on Windows 7:

Also on Windows if you try to enable or disable a GPU from within cgminer it stops responding and the window shuts down.

Am I posting these bugs in the correct place?

simplecoin

sr. member

Activity: 406

Merit: 250

Quote from: -ck on August 25, 2011, 05:15:27 PM

Quote from: simplecoin on August 25, 2011, 03:19:45 PM

on the new v1.5.8. using flags -I 8 -k phatk -v 2 -w 256 I get segfaults. Any other combination of vectors/worksize is fine. However, I lose about 70mh without those flags

Running 4x5850s, ubuntu natty 64, catalyst 11.6, sdk 2.4

I can't reproduce any segfaults here with that combination. Try deleting the .bin files and start it again.

That fixed it

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: iopq on August 25, 2011, 03:38:27 PM

Quote from: simplecoin on August 25, 2011, 03:19:45 PM

on the new v1.5.8. using flags -I 8 -k phatk -v 2 -w 256 I get segfaults. Any other combination of vectors/worksize is fine. However, I lose about 70mh without those flags

Running 4x5850s, ubuntu natty 64, catalyst 11.6, sdk 2.4

I get hardware errors on the same settings running 5750 with sdk 2.1 on windows

I can't reproduce any hardware errors, but I do know the current phatk kernel prefers sdk 2.4 up.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: simplecoin on August 25, 2011, 03:19:45 PM

on the new v1.5.8. using flags -I 8 -k phatk -v 2 -w 256 I get segfaults. Any other combination of vectors/worksize is fine. However, I lose about 70mh without those flags

Running 4x5850s, ubuntu natty 64, catalyst 11.6, sdk 2.4

I can't reproduce any segfaults here with that combination. Try deleting the .bin files and start it again.

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