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: --- 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. |
|
|
|
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. |
|
|
|
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...  Nice going phase  Thanks though! Works like a charm! We all have days like this |
|
|
|
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). |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
what does indicates the second MH/s value for each GPU?
GPU 0: [381.6 / 355.2 Mh/s]
And is it normal to get U over 100%?
You mean E over 100%. Yes it's normal now. Read the README file and you'll see efficiency is the number of shares found per work item requested. It's a sign of efficiency as a miner but it doesn't earn you any more BTC. What you get rewarded for is the U(tility) which shows how many shares you return per minute. |
|
|
|
How difficult would it be to break the executable off into a library, with the executable a very thin layer over the library?
A major architectural rewrite of the code. |
|
|
|
I don't recall having seen anything regarding this issue: if mining on pools using different blockchains (Bitcoin/Namecoin), would that have any impact when run under a single instance of cgminer? I assume it wouldn't, but want to make sure. e.g.: cgminer -c btc.json -c nmc.json Thanks. You cannot run different networks. They conflict on what they think the current block is. |
|
|
|
|
Updated GIT tree. Next release still pending.
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.
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.
|
|
|
|
@ck: Is anything like Phoenix's -s planned? ie -s SOCKETNAME, --socketname=SOCKETNAME full path to file for outputting current status. That would be so delightfully cool... and useful.  No reply, so I guess it can't be done. It's a pity, because the -s would allow CG to be (possibly) considered to be a part of BAMT. As it is now, it's "just" a standalone miner.  What exactly do you mean by a socket? It looks to just be a filename on that summary. I assume this is not just redirecting stderr to your file of choice? ./cgminer -blah 2>/path/to/file ? |
|
|
|
Windows 7 64 bit, 2.3ghz Phenom x4, one Radeon HD 4870. GCMiner version 1.5.8.C:\[file hierarchy]\cgminer.exe You can't direct it like that using c:\blah\blah You must run it from the directory it's in directly. cd \blah\blah cgminer.exe -blah -blah |
|
|
|
Another thing. Since which version is pkg-config required? since 1.5.7 or earlier?
Quite a while back. I just hadn't put that into the documentation till recently since the patch to require it came from Ycros who helped get it working on multiple platforms originally. |
|
|
|
For the record, when I went from 1.5.3 to 1.5.6 it would consistentsy lock up my GPU (and pretty much my computer) within an hour (sometimes in minutes) until I lowered my OC settings. I am now getting a higher MHash/s and higher efficiency with lower OC settings. This was true on a multi-day run with 1.5.6 (over the weekend, so at least three days) and appears to be holding true for 1.5.8 (installed yesterday) as well. Giving up may not be to your advantage in the long run.
I'm actually very pleased to hear this because people are very quick to blame the software the provokes the problem rather than the problem itself. Thanks for reporting this. |
|
|
|
1.5.8 keeps crashing on me at random times.. and then i cant restart it without a reboot.
If it requires a reboot, then that's NOT cgminer but the driver that's crashing. A few people have found their overclocks have had to be relaxed with the latest versions of phatk. Personally I fixed all my instability issues by tossing out the 11.8 and 11.7 drivers and going back to 11.6. Hmm I have no problem with phatk 2.1 or 2.2 or the diablo builds any date with my other software and i threw out 11.8 and 11.7 a while ago and went back to straight old 11.6 no B included. but thanks for the info I will play with clocks a little(i'm also barely overclocked.. i dont like pushing it that hard) Decreasing intensity can help as well. It's the combination of the latest phatk kernel and the high intensity in cgminer that pushes cards to their limit. You may find the reduction in hash rate to be insignificant but the stability to increase. Try -I 7 instead of 8. |
|
|
|
Conman, can you tell me how to get pkg-config? I did the usual: mingw-get install pkg-config, but no dice.
See: http://www.mingw.org/wiki/FAQfor: How do I get pkg-config installed? It's still not easy to get it compiling under mingw32, but at least the dependencies are sorted out. |
|
|
|
1.5.8 keeps crashing on me at random times.. and then i cant restart it without a reboot.
If it requires a reboot, then that's NOT cgminer but the driver that's crashing. A few people have found their overclocks have had to be relaxed with the latest versions of phatk. Personally I fixed all my instability issues by tossing out the 11.8 and 11.7 drivers and going back to 11.6. |
|
|
|
|
Show Posts
