Getting funny behaviour disabling a GPU within cgminer from current git: 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? |
|
|
|
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) |
|
|
|
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.
ck, I'm having the same "OFF" problem described, in rigs with 5970 and 5870: https://bitcointalk.org/index.php?topic=28402.msg727748#msg727748I have a theory as to how this might be happening now, and it involves cards that may well be getting sick occasionally, and have committed some code to the git tree for it. It would be interesting for you to run your cards with the old version overnight that doesn't have this problem, and then after it has run for an extended period, go into the GPU menu and see if any of the GPUs have been re-initialised at any time or if the "Last initialised" time is close to the main "Started" time at the top. |
|
|
|
|
The pool where donations were going was hacked and I'm considering moving all my shares to p2pool as well now. I have grave concerns about centralising work to pools and increasingly see p2pool - or something like it - as the solution for bitcoin's future strength, going back to its decentralised nature as its strength. This means I won't realistically have a way of accepting small hashrate contributions donations with --donation that I can reasonably support. So after much angst I have decided that I will be deprecating the donations feature in upcoming versions and go back to the previous donation model of as-and-when you feel like it.
I thank those who have used the --donation feature greatly till now. It averaged around 400Mh/s over that time and at least kept me "mining" while my own mining rig was dead for over a month.
I recommend people disable --donation now and restart their miners for I don't know what will happen to hashes going to the pool during this instability (it is going offline for 24+ hours likely).
|
|
|
|
I use these flags -I 8 --gpu-engine 950,850,830,950 --gpu-memclock 850,180,180,850 --auto-fan --temp-target 75 --temp-overheat 82 How do I check it's detecting right? It lists in the same order as 2.1.2. --gpu-reorder worth checking? I can't see anything wrong with that. Without --gpu-reorder it uses the same order as 2.1.2 would have detected. I guess you'd know pretty quickly if it was setting the wrong speed on the wrong device and... [2012-02-05 00:01:17] GPU 0 AMD Radeon HD 6800 Series hardware monitoring enabled [2012-02-05 00:01:17] GPU 1 ATI Radeon HD 5900 Series hardware monitoring enabled [2012-02-05 00:01:17] GPU 2 ATI Radeon HD 5900 Series hardware monitoring enabled [2012-02-05 00:01:17] GPU 3 AMD Radeon HD 6800 Series hardware monitoring enabled looks pretty convincing. So I'm at a loss for why it should be any worse. 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. |
|
|
|
|
You can't. memory can only go 125 lower than engine via the ATI Display Library which is how cgminer works, unless you flash your card. Windows apps use other windows-specific tricks to get around it that I can't use in cgminer.
|
|
|
|
Using 2.2.1 on a mixed card rig [2012-02-05 00:01:17] CL Platform vendor: Advanced Micro Devices, Inc.
[2012-02-05 00:01:17] CL Platform name: AMD Accelerated Parallel Processing
[2012-02-05 00:01:17] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-02-05 00:01:17] GPU 0 AMD Radeon HD 6800 Series hardware monitoring enabled
[2012-02-05 00:01:17] GPU 1 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-05 00:01:17] GPU 2 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-05 00:01:17] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2012-02-05 00:01:17] GPU 3 AMD Radeon HD 6800 Series hardware monitoring enabled
[2012-02-05 00:01:17] Dual GPUs detected: 2 and 1
[2012-02-05 00:01:17] 4 GPU devices detected And the second core of the 5970 keeps showing OFF after 12-18 hrs running with this error [2012-02-04 03:37:42] Thread 2 idle for more than 60 seconds, GPU 2 declared SICK!
[2012-02-04 03:37:42] Attempting to restart GPU
[2012-02-04 03:37:42] Thread 4 still exists, killing it off
[2012-02-04 03:37:42] Thread 5 still exists, killing it off
[2012-02-04 03:37:42] Thread 4 restarted
[2012-02-04 03:37:43] Thread 5 restarted
[2012-02-04 03:37:44] Thread 4 being disabled
[2012-02-04 03:37:44] Thread 5 being disabled I first thought it was clocks, but it has been running for 5 months at the same clocks. I lowered them a few times anyway but still the same error. If I go back to 2.1.2 it runs fine, 24 + hours now.  Well 2.2.1 has the dual GPU linkage going on which 2.1.2 does not. Bear in mind the auto fanspeed control now looks at the temps of both GPUs, but overall this should run things cooler rather than hotter so unless you have some specific setup, or maybe have autofan off on one of the devices or different clock settings... Also, have you checked it's actually detecting the right card in the right device and linking the right devices? |
|
|
|
Oops, I might have tried that with 2.1.2 instead of 2.2.1. I have both on the machine currently. I'll try rerunning with 2.2.1 EDIT: Ok I am an idiot, this was caused by my failure to type export DISPLAY=:0 in the shell each time before I ran it. I mistakenly thought that command applied to the entire login session. Hope that info helps anyone else running into the same problem. Carry on.  You know I was actually about to say that's what usually causes it, but I doubted it would happen between runs. Seems I was wrong  |
|
|
|
[2012-02-04 22:53:02] Pushing ping to longpoll thread
[2012-02-04 22:53:02] ADL Initialisation Error!
[2012-02-04 22:53:02] Pushing ping to thread 0
[2012-02-04 22:53:02] Init GPU thread 0
[2012-02-04 22:53:02] List of devices:
[2012-02-04 22:53:02] 0 Cypress
[2012-02-04 22:53:02] 1 Cypress
[2012-02-04 22:53:02] 2 Cypress
[2012-02-04 22:53:02] 3 Juniper
[2012-02-04 22:53:02] 4 Cypress
[2012-02-04 22:53:02] Selected 0: Cypress
[2012-02-04 22:53:02] Preferred vector width reported 4
[2012-02-04 22:53:02] Max work group size reported 256
Only place it has a line with ADL.
result = ADL_Main_Control_Create (ADL_Main_Memory_Alloc, 1);
if (result != ADL_OK) {
applog(LOG_INFO, "ADL Initialisation Error! Error %d!", result);
return ;
}
The newer version should also show what the error is, but the main initialisation is failing. What version of cgminer are you running? It will be one of the following. #define ADL_OK_WAIT 4
All OK, but need to wait.
#define ADL_OK_RESTART 3
All OK, but need restart.
#define ADL_OK_MODE_CHANGE 2
All OK but need mode change.
#define ADL_OK_WARNING 1
All OK, but with warning.
#define ADL_OK 0
ADL function completed successfully.
#define ADL_ERR -1
Generic Error. Most likely one or more of the Escape calls to the driver failed!
#define ADL_ERR_NOT_INIT -2
ADL not initialized.
#define ADL_ERR_INVALID_PARAM -3
One of the parameter passed is invalid.
#define ADL_ERR_INVALID_PARAM_SIZE -4
One of the parameter size is invalid.
#define ADL_ERR_INVALID_ADL_IDX -5
Invalid ADL index passed.
#define ADL_ERR_INVALID_CONTROLLER_IDX -6
Invalid controller index passed.
#define ADL_ERR_INVALID_DIPLAY_IDX -7
Invalid display index passed.
#define ADL_ERR_NOT_SUPPORTED -8
Function not supported by the driver.
#define ADL_ERR_NULL_POINTER -9
Null Pointer error.
#define ADL_ERR_DISABLED_ADAPTER -10
Call can't be made due to disabled adapter.
#define ADL_ERR_INVALID_CALLBACK -11
Invalid Callback.
#define ADL_ERR_RESOURCE_CONFLICT -12
Display Resource conflict.
|
|
|
|
Allegedly 2.4 and 2.5 do need more memory speed for some strange reason. BTW, any ideas where I'd start looking to see why cgminer stops detecting fan rpm speeds/gpu temps after it has been previously run? Only way to get it to detect them again is to reboot the machine. It's at a driver level that this is failing. I have no idea why it would change its mind to not support it on future runs. When it fails, if you start it with debugging enabled you will get what the ADL error is, but that still won't give an answer as to how to fix it. Something like "ADL Initialisation Error!" any error with adl in it. |
|
|
|
what SDK are you using and what speeds are you getting with 950/300 ? v2.4 sdk. That's probably the issue, thought I had 2.1 installed. I'll see if I can remove 2.4 and install 2.1, hopefully that will make a difference. Currently getting ~430mh at 950/300 setting, that drops to 425 when going to 950/180. Allegedly 2.4 and 2.5 do need more memory speed for some strange reason. |
|
|
|
|
How robust is this tool to cope with additions (i.e. not changes but more fields) to the API? It should be able to. Planning on adding maybe two more entries next version.
|
|
|
|
What phatk kernel and poclbm kernel does this use ?
Where can I see detailed output ?
Thanks !
Both custom ones unique for cgminer. Phatk is something like ~phatk2.2. poclbm, not sure. The current development versions are updated slightly to work with GCN, but are not the fastest GCN kernels. edit: exactly what detailed output are you after? Where can I see what values cgminer chooses for the worksize and vectors with each kernel etc. ? Thanks ! Start with --verbose -T But basically it uses -v 2 -w 128 unless you specify otherwise |
|
|
|
What phatk kernel and poclbm kernel does this use ?
Where can I see detailed output ?
Thanks !
Both custom ones unique for cgminer. Phatk is something like ~phatk2.2. poclbm, not sure. The current development versions are updated slightly to work with GCN, but are not the fastest GCN kernels. edit: exactly what detailed output are you after? |
|
|
|
|
Found it. While the kernel init problem proved to be a red herring, the rejects was not. Fixed in git now, thanks for your debugging.
|
|
|
|
[2012-02-03 23:28:22] Unable to open phatk120203.cl or ./phatk120203.cl for reading
phatk110817.cl was present but not phatk120203.cl. Wait wait wait... they should be pulled into your local git directory by git pull... Something fishy is going on and I don't think it's my code or my git repo  They were pulled, but I hadn't copied them from the source/git directory to the working/running directory that I use. After copying them, as previously reported it ran but without LP (p2pool) and with all rejects after the donation acknowledgement. I think the rejects were coincidence. Lots of rejects are not uncommon in p2pool if I'm not mistaken? Unless the blockchain is very different on p2pool and donation breaks it (but I didn't think it would do that). So that leaves no bug as far as I can tell. |
|
|
|
[2012-02-03 23:28:22] Unable to open phatk120203.cl or ./phatk120203.cl for reading
phatk110817.cl was present but not phatk120203.cl. Wait wait wait... they should be pulled into your local git directory by git pull... Something fishy is going on and I don't think it's my code or my git repo |
|
|
|
...
3. Default intensity is "dynamic" meaning it's meant to be used on a desktop with a GUI. If this does not describe your setup, use a static intensity, usually 7-9 provides the best, depending on hardware. Try and find the largest value that does not fluctuate too much. Dynamic works fine regardless of what pool you're using it on, provided that's what you want.
...
It's a dedicated mining system. I changed from I 8 or 9 (I forget which offhand) to default (dynamic), which yielded I 3 or 4 and a markedly lower Mh/s, because I thought that with p2pool's frequent longpolls it was better to be more responsive to them. Not quite. I would recommend -I 9 -g 1 instead. That will give you more mhashes but because only one thread will be running per GPU, it will return data faster. |
|
|
|
Here's the -n output from the latest commit, the one that fails to run: [2012-02-03 22:56:14] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-02-03 22:56:14] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-02-03 22:56:14] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-02-03 22:56:14] Platform 0 devices: 6
[2012-02-03 22:56:14] 6 GPU devices max detected
...which (if memory serves) is the same as what -n produces from the 2.1.2 version number commit, which is running fine. If you look carefully you'll see it's different. What does starting it with your regular commands and "--verbose -D -T" give you up until it fails? |
|
|
|
|
No, I need -n from the last commit to see if/why it fails. I can't reproduce it... No offence, but are you sure you did ./autogen.sh first?
|
|
|
|
|
Show Posts
