Anybody else have this experience.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 711. (Read 5805728 times)
January 07, 2012, 11:25:02 AM
Got an update from Symantec Antivirus last night and it told me cgmimer was a trojan.
Anybody else have this experience.
Anybody else have this experience.
January 06, 2012, 06:27:16 AM
Woot! 2.1.2 is out. Yes I noticed 
Edit:
WTF? On my mixed GPU rig (Windows 7) it created both cypress and caymen bin files on the first launch. Either you fixed something or the gods were smiling on me.
Edit:
WTF? On my mixed GPU rig (Windows 7) it created both cypress and caymen bin files on the first launch. Either you fixed something or the gods were smiling on me.
January 06, 2012, 05:46:48 AM
Your build failure is due to the new api code. I'll have to refer this to kano for him to fix the build problems in osx. 2.0.8 may be the last version that compiles on osx for now.
Hm couldn't get to finish 2.0.8 either. But thanks for your reply! Maybe a future version will support osx again.
Thanks! I removed everything from macports and installed libcurl, yasm and so on with fink. I didn't manage to make it either (2.0.
.Code:
noname:cgminer-2.0.8 Matthias$ make
make all-recursive
Making all in lib
GEN signal.h
GEN stdint.h
GEN string.h
make all-recursive
CC memmem.o
AR libgnu.a
/usr/bin/ranlib: file: libgnu.a(dummy.o) has no symbols
ranlib: file: libgnu.a(dummy.o) has no symbols
Making all in compat
Making all in jansson
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in ccan
make[2]: Nothing to be done for `all'.
Making all in x86_64
make[2]: Nothing to be done for `all'.
CC cgminer-main.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-util.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-ocl.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-findnonce.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_generic.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_4way.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_via.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_cryptopp.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_sse2_amd64.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_sse4_amd64.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_sse2_i386.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha256_altivec_4way.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CC cgminer-sha2.o
i686-apple-darwin11-llvm-gcc-4.2: -lpthread: linker input file unused because linking not done
CCLD cgminer
ld: warning: ignoring file x86_64/libx8664.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_sha256_sse2_64_new", referenced from:
_scanhash_sse2_64 in cgminer-sha256_sse2_amd64.o
"_CalcSha256_x64_sse4", referenced from:
_scanhash_sse4_64 in cgminer-sha256_sse4_amd64.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Then i removed yasm and it finished fine and works now.
Thanks for your help!!
January 06, 2012, 04:00:43 AM
Yes there is a Windoze equivalent, its called VNC. VNC works for me, usually, but it can be a little flaky.
Thanks, I've got it working now over TigerVNC, but with a really major VNC crashing bug occurring (which is probably not caused by CGMINER, unless the issue is indirectly caused somehow by mining overloading the VNC video hook on my system, but I think I've ruled out anything like that).
So, the issue I'm experiencing is simply this: Whenever I'm logged in through a client session and click on the "All Programs" item in the Start Menu, the server process invariably crashes. This seems almost completely bonkers that that would be all it takes, but it is completely reproducible. Crashes of the server process also occur at other times, but clicking on "All Programs" definitely does it every time. I've tried two different VNC clients and gotten the same results, so I would suspect it is some kind of issue with the winvnc4.exe server process of TigerVNC, but I just can't imagine what it could be. (FYI, I'm running the TigerVNC server on Windows 7 Professional 32-bit). I don't want to hijack this thread, so please PM me if you have any insight.
January 06, 2012, 02:58:32 AM
Yes there is a Windoze equivalent, its called VNC. VNC works for me, usually, but it can be a little flaky.
Thanks, I've got it working now over TigerVNC, but with a really major VNC crashing bug occurring (which is probably not caused by CGMINER, unless the issue is indirectly caused somehow by mining overloading the VNC video hook on my system, but I think I've ruled out anything like that).
So, the issue I'm experiencing is simply this: Whenever I'm logged in through a client session and click on the "All Programs" item in the Start Menu, the server process invariably crashes. This seems almost completely bonkers that that would be all it takes, but it is completely reproducible. Crashes of the server process also occur at other times, but clicking on "All Programs" definitely does it every time. I've tried two different VNC clients and gotten the same results, so I would suspect it is some kind of issue with the winvnc4.exe server process of TigerVNC, but I just can't imagine what it could be. (FYI, I'm running the TigerVNC server on Windows 7 Professional 32-bit). I don't want to hijack this thread, so please PM me if you have any insight.
January 06, 2012, 02:29:02 AM
First off, LOVE cgminer, amazing, thank you.. please never stop development!!
Card order/sorting...
Is there any way to get CGMiner to indicate the card type it has assigned to "CARD 0", "CARD 1" etc, or at least check it against the "list-adapters" list?
Case in point, what the ATI driver indicates as card 0,1,2 is backwards from what CG miner chooses... has bit me more than once.
Example?
but cgminer has the 5800 series as GPU 0, and 6900 Series as Card 1
(now that I'm posting this, I'm wondering whether my DISPLAY order in xorg.conf doesn't match the adapter list, order wise, and whether I could fix it that way... but it would still be nice to see cgminer identify the card matching GPU)
AMD/ATI have been a bunch of fsking morons with their drivers and the driver returns a different set of values to the ATI display library and all I can do is enumerate them in the order they appear in each library and hope they're one and the same. It usually correlates with PCI slot but even then, mobo manufacturers don't enumerate them always in order either.... sighCard order/sorting...
Is there any way to get CGMiner to indicate the card type it has assigned to "CARD 0", "CARD 1" etc, or at least check it against the "list-adapters" list?
Case in point, what the ATI driver indicates as card 0,1,2 is backwards from what CG miner chooses... has bit me more than once.
Example?
Quote
[root@miners]# DISPLAY=:0 aticonfig --list-adapters
* 0. 08:00.0 AMD Radeon HD 6900 Series
1. 04:00.0 ATI Radeon HD 5800 Series
* - Default adapter
* 0. 08:00.0 AMD Radeon HD 6900 Series
1. 04:00.0 ATI Radeon HD 5800 Series
* - Default adapter
but cgminer has the 5800 series as GPU 0, and 6900 Series as Card 1
Quote
GPU 0: 398.9 / 392.2 Mh/s | A:371 R:0 HW:0 U:5.29/m I:9
80.0 C F: 42% (1801 RPM) E: 960 MHz M: 300 Mhz V: 1.088V A: 99% P: 0%
GPU 1: 364.2 / 366.1 Mh/s | A:361 R:1 HW:0 U:5.15/m I:9
78.0 C F: 52% (2888 RPM) E: 900 MHz M: 1250 Mhz V: 1.100V A: 99% P: 0%
80.0 C F: 42% (1801 RPM) E: 960 MHz M: 300 Mhz V: 1.088V A: 99% P: 0%
GPU 1: 364.2 / 366.1 Mh/s | A:361 R:1 HW:0 U:5.15/m I:9
78.0 C F: 52% (2888 RPM) E: 900 MHz M: 1250 Mhz V: 1.100V A: 99% P: 0%
(now that I'm posting this, I'm wondering whether my DISPLAY order in xorg.conf doesn't match the adapter list, order wise, and whether I could fix it that way... but it would still be nice to see cgminer identify the card matching GPU)
The 6990 / dual GPU cards also are special cases in point and while the ADL library does give tiny hints about how they're related, I can't poke and prod around them to find what the values mean because I don't own one.
i.e. unfortunately not.
January 05, 2012, 11:51:29 PM
First off, LOVE cgminer, amazing, thank you.. please never stop development!!
Card order/sorting...
Is there any way to get CGMiner to indicate the card type it has assigned to "CARD 0", "CARD 1" etc, or at least check it against the "list-adapters" list?
Case in point, what the ATI driver indicates as card 0,1,2 is backwards from what CG miner chooses... has bit me more than once.
Example?
but cgminer has the 5800 series as GPU 0, and 6900 Series as Card 1
(now that I'm posting this, I'm wondering whether my DISPLAY order in xorg.conf doesn't match the adapter list, order wise, and whether I could fix it that way... but it would still be nice to see cgminer identify the card matching GPU)
Card order/sorting...
Is there any way to get CGMiner to indicate the card type it has assigned to "CARD 0", "CARD 1" etc, or at least check it against the "list-adapters" list?
Case in point, what the ATI driver indicates as card 0,1,2 is backwards from what CG miner chooses... has bit me more than once.
Example?
Quote
[root@miners]# DISPLAY=:0 aticonfig --list-adapters
* 0. 08:00.0 AMD Radeon HD 6900 Series
1. 04:00.0 ATI Radeon HD 5800 Series
* - Default adapter
* 0. 08:00.0 AMD Radeon HD 6900 Series
1. 04:00.0 ATI Radeon HD 5800 Series
* - Default adapter
but cgminer has the 5800 series as GPU 0, and 6900 Series as Card 1
Quote
GPU 0: 398.9 / 392.2 Mh/s | A:371 R:0 HW:0 U:5.29/m I:9
80.0 C F: 42% (1801 RPM) E: 960 MHz M: 300 Mhz V: 1.088V A: 99% P: 0%
GPU 1: 364.2 / 366.1 Mh/s | A:361 R:1 HW:0 U:5.15/m I:9
78.0 C F: 52% (2888 RPM) E: 900 MHz M: 1250 Mhz V: 1.100V A: 99% P: 0%
80.0 C F: 42% (1801 RPM) E: 960 MHz M: 300 Mhz V: 1.088V A: 99% P: 0%
GPU 1: 364.2 / 366.1 Mh/s | A:361 R:1 HW:0 U:5.15/m I:9
78.0 C F: 52% (2888 RPM) E: 900 MHz M: 1250 Mhz V: 1.100V A: 99% P: 0%
(now that I'm posting this, I'm wondering whether my DISPLAY order in xorg.conf doesn't match the adapter list, order wise, and whether I could fix it that way... but it would still be nice to see cgminer identify the card matching GPU)
January 05, 2012, 10:03:50 PM
One other thing, is anyone able to start cgminer from a remote desktop session and have it detect their gpus? I can monitor what cgminer is doing on my machine over remote desktop, but if I close cgminer remotely and then try to start it back up from the remote session, it doesn't detect the gpu.
I don't know about windows, but with linux you need DISPLAY=:0 before your launch string if starting over vnc/ssh to detect the GPU's.
Is there anyone who knows if there is a Windows equivalent?
Remote desktop sessions don't have access to GPU hardware.
Yes there is a Windoze equivalent, its called VNC. VNC works for me, usually, but it can be a little flaky.
Sam
January 05, 2012, 03:54:19 PM
Your build failure is due to the new api code. I'll have to refer this to kano for him to fix the build problems in osx. 2.0.8 may be the last version that compiles on osx for now.
Hm couldn't get to finish 2.0.8 either. But thanks for your reply! Maybe a future version will support osx again.
January 05, 2012, 03:36:05 PM
...
Can anyone help me please? I'd really like to get this running.
Firstly the fact that "configure" says "checking whether the C compiler works... no"Can anyone help me please? I'd really like to get this running.
suggests that you need to fix your compile environment so it actually works normally.
Q: The build fails with gcc is unable to build a binary.
A: Remove the "-march=native" component of your CFLAGS as your version of gcc
does not support it.
His build problems are elsewhere though. I haven't had anyone who could help me on osx for a while so I've been unable to keep the osx build working.
January 05, 2012, 12:23:55 PM
Dont use remote desktop. Try VNC.
January 05, 2012, 12:22:45 PM
One other thing, is anyone able to start cgminer from a remote desktop session and have it detect their gpus? I can monitor what cgminer is doing on my machine over remote desktop, but if I close cgminer remotely and then try to start it back up from the remote session, it doesn't detect the gpu.
I don't know about windows, but with linux you need DISPLAY=:0 before your launch string if starting over vnc/ssh to detect the GPU's.
Is there anyone who knows if there is a Windows equivalent?
January 05, 2012, 10:29:03 AM
...
Can anyone help me please? I'd really like to get this running.
Firstly the fact that "configure" says "checking whether the C compiler works... no"Can anyone help me please? I'd really like to get this running.
suggests that you need to fix your compile environment so it actually works normally.
Only Suggestion I have for api.c
(since I do not have OSX and the Apple license says that if I buy OSX, I must not install it on my Linux computer - Apple are a bunch of fags)
is that at line 24 it says "#if defined(unix)"
Now OSX is a "unix" OS (it's based on BSD) so I guess whatever compiler you are using doesn't know that
So if you just remove that line 24 and the matching "#endif" that may fix it?
January 05, 2012, 09:57:11 AM
@meti
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
does this apply to nvidia graphics too?
Your build failure is due to the new api code. I'll have to refer this to kano for him to fix the build problems in osx. 2.0.8 may be the last version that compiles on osx for now.
Hm couldn't get to finish 2.0.8 either. But thanks for your reply! Maybe a future version will support osx again.
January 05, 2012, 09:45:23 AM
Should work already without midstate and smaller data type.
Excellent, thanks!
January 05, 2012, 09:34:47 AM
ckolivas, if I'm reading source code correctly, only "data" and "target" fields are necessary in getwork request, right? The rest can be calculated directly by the miner.
I also see that you're requesting 128 bytes of "data", although only first 80 bytes is really used for hashing. Can you please modify the miner that 80 bytes (160 chars in hex in getwork stream) will be enough for hashing? I'm working on some pool update and found that both poclbm and phoenix will work with 80 bytes in data already, but I would like to support your miner with this extension as well...
Should work already without midstate and smaller data type.I also see that you're requesting 128 bytes of "data", although only first 80 bytes is really used for hashing. Can you please modify the miner that 80 bytes (160 chars in hex in getwork stream) will be enough for hashing? I'm working on some pool update and found that both poclbm and phoenix will work with 80 bytes in data already, but I would like to support your miner with this extension as well...
See this commit:
https://github.com/ckolivas/cgminer/commit/e8720b908428fabac59da161b0648091179688b1
January 05, 2012, 09:23:44 AM
@meti
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
does this apply to nvidia graphics too?
Your build failure is due to the new api code. I'll have to refer this to kano for him to fix the build problems in osx. 2.0.8 may be the last version that compiles on osx for now.
January 05, 2012, 08:48:15 AM
@meti
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
does this apply to nvidia graphics too?
January 05, 2012, 08:41:01 AM
@meti
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
You will need to copy the SDK header files into the ADL_SDK subdir.
You should have files like this,
adl_defines.h
adl_sdk.h
adl_structures.h
usually found in ADL_SDK/includes from the SDK install.
January 05, 2012, 08:36:38 AM
ckolivas, if I'm reading source code correctly, only "data" and "target" fields are necessary in getwork request, right? The rest can be calculated directly by the miner.
I also see that you're requesting 128 bytes of "data", although only first 80 bytes is really used for hashing. Can you please modify the miner that 80 bytes (160 chars in hex in getwork stream) will be enough for hashing? I'm working on some pool update and found that both poclbm and phoenix will work with 80 bytes in data already, but I would like to support your miner with this extension as well...
I also see that you're requesting 128 bytes of "data", although only first 80 bytes is really used for hashing. Can you please modify the miner that 80 bytes (160 chars in hex in getwork stream) will be enough for hashing? I'm working on some pool update and found that both poclbm and phoenix will work with 80 bytes in data already, but I would like to support your miner with this extension as well...
Jump to: