I've been having problems with cgminer crashing after about 1-3 hours. I'm running on Windows 7 x64 with a pair of Sapphire HD 5770 cards. I launch cgminer using a scheduled task with the following command line in a batch file: cgminer -o http://<pool0>:8332 -u <username> -p <passwd> -o http://<pool1>:8332 -u <username> -p <passwd> --enable-cpu -t 4 -a 4way --text-only -l 30 > "_logs\%date:~10,4%%date:~4,2%%date:~7,2%_%time:~0,2%%time:~3,2%%time:~6,2%.log" 2>&1 Eventually Windows pops-up a dialog saying the program has crashed. The pattern I've seen is cgminer is always trying to perform a pool fail-over right before the crash: [2011-09-13 17:15:47] Pool 0 http://<pool0>:8332 not responding!
[2011-09-13 17:15:47] Switching to http://<pool1>:8332
[2011-09-13 17:15:47] Pool 0 http://<pool0>:8332 recovered
[2011-09-13 17:15:47] Switching to http://<pool0>:8332 That's the last message before the program crashes. Windows reports the following regarding the crash: Problem signature:
Problem Event Name: APPCRASH
Application Name: cgminer.exe
Application Version: 0.0.0.0
Application Timestamp: 4e6c4b8a
Fault Module Name: libpthread-2.dll
Fault Module Version: 2.8.0.0
Fault Module Timestamp: 4b7d316b
Exception Code: c0000005
Exception Offset: 00001b73
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 Any ideas why this is happening? Likely this is a dereferencing error somewhere in my code, but being on windows the bug report is largely unusable unfortunately since the windows crashes are un-debuggable. Should anyone be experiencing this on linux, please enable core dumps and get a stacktrace if you know how. If not, contact me. |
|
|
|
How does the load balancing work? Does it hash equally at all pools or will it hash faster at pools proving work faster or a better connection?
It will hash faster for pools that support rolltime and have better network connectivity. |
|
|
|
damn, this software sucks balls... guiminer FTW !!!!!
What do you find that sucks about Cgminer ? I actually used Guiminer up until about a week or so ago, then switched to Cgminer and could never go back. Cgminer has it all. Mining, Management, Monitoring and Overclocking all-in-one and if you can write a simple BAT file, you are on your way and takes FAR LESS TIME to configure than even Guiminer, which I had to admit, as nice when I was a complete mining noob. I don't see how anyone could NOT love this software. Allan Nice feedback, thanks  |
|
|
|
Well I honestly am completely baffled since the build has -ldl added... Unless the LDFLAGS are not being passed at all. God I hate autofoo tools. Anyone with a clue out there?
2.0.2 resolves all the compile problems.. ADL present/missing works, compiles cleanly both ways. Thank you for your persistence and patience. Now to the actual function.. should auto GPU clock/fans be working under linux? 2.4 AMD SDK/11.4 driver? (as I recall?) When I hit "G" on the linux version, I don't have the same GPU options as I do when I run the windows binary on my desktop machine.. Try 11.6. Some clocking things weren't working in earlier drivers and 11.6 was the last good one. |
|
|
|
|
That may or may not be correct. I don't follow the windows stuff that closely.
|
|
|
|
None of the initialisation code for the GPUs actually changed between 2.0 and 2.0.2. You are getting stung by random windows fuckage (this bug seems confined to windows) where you may have to restart it multiple times to get it working because it fails to build the kernels. You just happened to be lucky on the 2.0 release. However you are also in luck as there is a way around if it you already had it working in an earlier version. Copy any files from your 2.0.0 directory that have names ending in .bin into your 2.0.2 directory and try again.
Yep, that worked. How far into the future will that carry me you think? If you change the installed SDK which comes with the driver in windows I think, you'll need new .bin files generated. Alternatively if a new kernel comes out for cgminer, you'll also need new .bins. Otherwise you can keep using them. |
|
|
|
I just tried 2.0.2 and got the same error that I had with 2.0.1 which is as follows
---------------------------------------------
[2011-09-11 10:14:20] Failed to init GPU thread 0, disabling device 0
[2011-09-11 10:14:20] The most common reason for this failure is cgminer being u
nable to read the kernel .cl files
[2011-09-11 10:14:20] Alternatively if it has failed on different GPUs, restarti
ng might help.
Press enter to continue:
---------------------------------------------
When I try to restart either GPU it crash's. When I press Q to quit the program it also crash's.
I'm back to using 2.0.0 again.
Sam
None of the initialisation code for the GPUs actually changed between 2.0 and 2.0.2. You are getting stung by random windows fuckage (this bug seems confined to windows) where you may have to restart it multiple times to get it working because it fails to build the kernels. You just happened to be lucky on the 2.0 release. However you are also in luck as there is a way around if it you already had it working in an earlier version. Copy any files from your 2.0.0 directory that have names ending in .bin into your 2.0.2 directory and try again. |
|
|
|
running CGMiner 2.02 on win7 64 bit. sdk 2.4, 11.6 driver. ASUS directCU 6870 non ref card. mem clock is displayed wrong in win7 build on the ASUS. "--gpu-memclock 300" is in the command line and GPU-Z and CCC both correctly show the 300 MHz clock speed, so it does get set. below is the "G" output. --------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 74.0C 2807RPM | 311.3/314.8Mh/s | A:59 R:0 HW:0 U:4.70/m
--------------------------------------------------------------------------------
GPU 0: 319.8 / 316.6 Mh/s | A:29 R:0 HW:0 U:4.30/m
74.0 C F: 71% (2840 RPM) E: 1010 MHz M: 1050 Mhz V: 1.200V A: 98% P: 0% this is a cosmetic bug only as the clock is correctly set. and ONLY the asus 6870. on my 6770 the mem clock displays correctly. other than that, which is may be specific to that card, FANTASTIC. Thanks for the feedback. I'd be very cautious of believing any other number than that one reported back by cgminer. There are different ways of querying the card that report back different values and cgminer is simply reporting back what the card says is its current running speed. On my 6970s it says the speed was set fine when I set it low, but then reports back at full memory speed. Looking at the temperature+fanspeeds confirms it is definitely running at the hotter 1375 (default). |
|
|
|
I changed it in the menu - one card lowered fan to 58%, second got overheated though the fan was showing 100% and was automatically disabled. But the second card was just soundless in reality, the fan was not working actually, just pretending lol
Hmm, I wonder then if the fan just doesn't support the high values it's trying to set it to. Can you leave autofan off and try setting it manually to higher values and see if they work ok? I did spot something in the code that might be responsible but I need to know if you can manually set it to 100% ok. Oh the menu should also report to you what range is okay (usually it's 0-100), so can you tell me what that shows too please? |
|
|
|
I'm sorry to report this, but auto-fan option is broken for me in 2.0.2 (windows 7 64 11.8 ). Fan speed is just going down to zero  I had to manually specify --gpu-fan 65 to make it work. Most unusual  What parameters are you passing? Thanks for the reply. I'm at a loss end myself 2.0.1 works fine with the same bat file --log 10 --intensity 9 --failover-only --submit-stale --auto-fan --auto-gpu --gpu-engine 830 --gpu-memclock 300 --temp-target 82 --temp-overheat 88 But when I use this bat file with 2.0.2 fan speed starts to diminish almost to zero and gpu overheats and I have to stop cgminer. Now I have to use this bat file --log 10 --intensity 9 --failover-only --submit-stale --gpu-fan 65 --gpu-memclock 300 this way it works... Interesting. When you start it (the safe way) do the parameters all look to make sense in the menu under G->Change settings for that device? You can enable and disable autofan on the fly in there so can you see if that's any different? As in, see what is reported in the parameters after you enable autofan and what happens. You should be able to disable it on the fly, and ultimately it *should* cut out at 95 degrees with --auto-gpu on. I did add more autofan logic in there but it was supposed to make it safer, not the other way around  |
|
|
|
I'm sorry to report this, but auto-fan option is broken for me in 2.0.2 (windows 7 64 11.8 ). Fan speed is just going down to zero I had to manually specify --gpu-fan 65 to make it work. Most unusual What parameters are you passing? |
|
|
|
Did you create cgminer or not? I believe you should treat everyone same and help to improve your software.
I most certainly did create cgminer as free software as a bitcoin miner to support and strengthen the bitcoin p2p network and I am under absolutely no obligation whatsoever to do jack shit. |
|
|
|
Hello,
some of us has been having problems with cgminer mining SC. No matter which pool we choose, we always get "unexpected error" message.
Any other mining software works fine. So I believe there is sometinh on cgminer side.
Unfortunately I'm not inclined to provide support for BTC forks. |
|
|
|
|
That's somewhere between bizarre, amusing and depressing at the same time o_O
|
|
|
|
Oddly enough, after some restarts and system updates, it seems to now be overclocking it over the ViDock. I can't say why, but I'm happy.
Is this with the new v2.0.2? Some changes I made to it should help set things even though it thinks it has failed now. No, it still can't do what msi afterburner does, nor can it outdo the 125 difference limit on 6970s. |
|
|
|
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU0: [875/750MHz 69.5C 57%] [359.5/130.4 Mh/s] [Q:57 A:52 R:1 HW:0 E:91% U:1.74/m]
GPU1: [875/750MHz 75.5C 85%] [359.5/138.0 Mh/s] [Q:53 A:53 R:1 HW:0 E:100% U:1.77/m]
GPU2: [875/750MHz 69.5C 51%] [359.5/137.3 Mh/s] [Q:53 A:49 R:1 HW:0 E:92% U:1.64/m]
GPU3: [875/750MHz 73.0C 85%] [359.4/137.2 Mh/s] [Q:66 A:54 R:1 HW:0 E:82% U:1.80/m]
GPU4: [875/750MHz 69.5C 49%] [360.4/137.5 Mh/s] [Q:57 A:46 R:0 HW:0 E:81% U:1.54/m] This is amazing, no monitoring scripts or separate windows needed. Having trouble with the auto-gpu though, can anyone tell me how to properly set it so the fan will jump to 100% before the engine clock is lowered? In version 2.0.1 or later, specify a max fanspeed up to 100 with --gpu-fan 100 or --gpu-fan 0-100 |
|
|
|
Welcome back to BTC talk.  New version:2.0.2 (most important change is fix for a rare crash) - Exit cleanly if we abort before various threads are set up or if they no longer exist. - Fix a rare crash in HASH_DEL due to using different mutexes to protect the data. - Flag devices that have never started and don't allow enabling of devices without restarting them. - Only force the adapter speed to high if we've flagged this device as being managed. - Flag any devices with autofan or autogpu as being managed. - Use a re-entrant value to store what fanspeed we're trying to set in case the card doesn't support small changes. Force it to a multiple of 10% if it fails on trying to speed up the fan. - Do not bother resetting values to old ones if changes to GPU parameters report failure, instead returning a failure code only if the return value from get() differs. - Remove redundant check. - Only display supported values from fanspeed on change settings. - Missing bracket from output. - Display fan percentage on devices that only support reporting percent and not RPM. - Properly substitute DLOPEN flags to build with ADL support when -ldl is needed and not when opencl is not found. |
|
|
|
cgminer is being packaged by some other trojan and the antivirus software is pointing the finger at cgminer instead of what it's packaged with since it's cgminer that does the mining. The antivirus AV software makers are all fscking up on this and cgminer is not the first mining software to be wrongly labelled. Until they get their act together, all the AV companies one after another will follow each other and tag it a virus. If you feel hard done by, file a complaint with your AV software provider, move to another provider, or another OS. They can easily find the actual code for cgminer online and audit it to see it isn't a fscking rootkit: https://github.com/ckolivas/cgminer |
|
|
|
|
In that case, no, there is no reason.
|
|
|
|
|
Show Posts
