Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with... Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing. If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash): http://ck.kolivas.org/apps/cgminer/temp/mother |
|
|
|
Hi!
Testing version 2.6.4 on Ubuntu 12.04, found a (minor) bug, but I think it could be an older one. Yesterday I configured my system to use the onboard GPU (3300) for display and the PCIe card (5770) for mining only. Unfortunately, ADL and CL GPU mapping does not seem to work.
Ok, fixed it by myself. There is definitely a bug. When finding ADL devices, one loop mixed up CL and ADL devices. Here is the diff which fixes it: hko@cave:~/src/cgminer/cgminer$ git diff
diff --git a/adl.c b/adl.c
index 69c06de..c60f08c 100644
--- a/adl.c
+++ b/adl.c
@@ -339,16 +339,16 @@ void init_adl(int nDevs)
}
}
- for (gpu = 0; gpu < devices; gpu++) {
+ for (gpu = 0; gpu < nDevs; gpu++) {
struct gpu_adl *ga;
int iAdapterIndex;
int lpAdapterID;
ADLODPerformanceLevels *lpOdPerformanceLevels;
int lev;
-
- i = vadapters[gpu].id;
+ int adlGpu = gpus[gpu].virtual_adl;
+ i = vadapters[adlGpu].id;
iAdapterIndex = lpInfo[i].iAdapterIndex;
- gpus[gpu].virtual_gpu = vadapters[gpu].virtual_gpu;
+ gpus[gpu].virtual_gpu = vadapters[adlGpu].virtual_gpu;
/* Get unique identifier of the adapter, 0 means not AMD */
result = ADL_Adapter_ID_Get(iAdapterIndex, &lpAdapterID);
@@ -358,11 +358,11 @@ void init_adl(int nDevs)
}
if (gpus[gpu].deven == DEV_DISABLED) {
- gpus[i].gpu_engine =
- gpus[i].gpu_memclock =
- gpus[i].gpu_vddc =
- gpus[i].gpu_fan =
- gpus[i].gpu_powertune = 0;
+ gpus[gpu].gpu_engine =
+ gpus[gpu].gpu_memclock =
+ gpus[gpu].gpu_vddc =
+ gpus[gpu].gpu_fan =
+ gpus[gpu].gpu_powertune = 0;
continue;
}
and a debug log file fromfixed code: [2012-08-11 16:01:32] Started cgminer 2.6.4
[2012-08-11 16:01:32] Loaded configuration file /home/xxxxxxx/.cgminer/cgminer.conf
[2012-08-11 16:01:32] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-08-11 16:01:32] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-08-11 16:01:32] CL Platform 0 version: OpenCL 1.2 AMD-APP (937.2)
[2012-08-11 16:01:32] Platform 0 devices: 1
[2012-08-11 16:01:32] 0 Juniper
[2012-08-11 16:01:32] GPU 0 iAdapterIndex 0 strUDID 296:38420:4098:33613:4163 iBusNumber 1 iDeviceNumber
5 iFunctionNumber 0 iVendorID 4098 strAdapterName ATI Radeon HD 3300 Graphics
[2012-08-11 16:01:32] GPU 1 iAdapterIndex 2 strUDID 512:26808:4098:9539:4098 iBusNumber 2 iDeviceNumber 0
iFunctionNumber 0 iVendorID 4098 strAdapterName ATI Radeon HD 5700 Series
[2012-08-11 16:01:32] ADL found more devices than opencl!
[2012-08-11 16:01:32] There is possibly at least one GPU that doesn't support OpenCL
[2012-08-11 16:01:32] Use the gpu map feature to reliably map OpenCL to ADL
[2012-08-11 16:01:32] Mapping OpenCL device 0 to ADL device 1
[2012-08-11 16:01:32] WARNING: Number of OpenCL and ADL devices did not match!
[2012-08-11 16:01:32] Hardware monitoring may NOT match up with devices!
[2012-08-11 16:01:32] GPU 0 ATI Radeon HD 5700 Series hardware monitoring enabled
[2012-08-11 16:01:32] Setting GPU 0 engine clock to 945
[2012-08-11 16:01:32] Setting GPU 0 memory clock to 180
[2012-08-11 16:01:32] Setting GPU 0 voltage to 1.125
[2012-08-11 16:01:32] Popping work to work thread
[2012-08-11 16:01:32] Probing for an alive pool
[2012-08-11 16:01:32] Popping work to stage thread
--- Nite69 WalletId: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp Much appreciated, thanks! |
|
|
|
|
You have to delete any .bins that cgminer generates whenever you change an SDK.
|
|
|
|
I was getting ~15% discards with the 2.5 code, now have ~30% with 2.6.4... That sound about right?
Yes. |
|
|
|
Questions to ckolivas.Last ver. of cgminer support voltage control for 7970 under Linux?
No way to control 7970 voltage on linux yet unfortunately. No sign even of alternative bioses you can flash them with even. |
|
|
|
That shut someone up.
Alas I don't believe that for a second  |
|
|
|
Is there a place to get older version of cgminer? I need 2.5.0, I think 2.6.x is the problem I'm facing right now...
All older versions here: http://ck.kolivas.org/apps/cgminer/ |
|
|
|
|
People seem to not understand it is entirely possible 2 people arrive at the same solution to the same bug at different times. This complaint is now about something like a one line bugfix with exactly those circumstances. Paranoid delusions indeed.
|
|
|
|
So ... nothing you can do about it ... don't mine on p2pool with BFL Singles or MiniRigs
(MiniRigs only lose ~half as much work since they are a bit less than 2 times as fast per card vs a Single)
My understanding is that BFL added the ability to tell a MiniRig to search less than the entire nonce range (and so you can dramatically reduce stales), so it should be possible to use it on p2pool if you have a miner that implements that feature. The assumption is that the Single SCs will also have that firmware feature when they come out. So in theory it is just the normal Singles that are unusable. That's correct, but you need to use this option with cgminer to use it: --bfl-range Use nonce range on bitforce devices if supported It only works on minirigs, and in fact the first few minirigs didn't support it properly. |
|
|
|
I compiled 2.6.4 for windows and I've had it running for over 24 hours so far without any problems.
At last  Thanks  |
|
|
|
Thanks. It looks like the code was up to date, but I built it before pulling the version number change on the laptop, sorry about that. Reuploaded packages. |
|
|
|
2.6.4 still shows 2.6.3 in the display.
One of my binaries? Which one? |
|
|
|
|
And now for something completely different...
New release - 2.6.4, 7th August 2012
Bugfixes, mainly for the crash. I couldn't stand knowing the latest release has a showstopper bug in it.
Human readable changelog
The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
The scrypt code was updated - now ALL results from a GPU are checked to see if they're valid and if not, instead of being submitted where they are guaranteed to be rejected, they register as hardware errors. This will make tuning your scrypt parameters easier as HW error count will rise if you've set the parameters too high.
A few more tweaks to the BFL code to make it more robust, especially on windows.
Updated miner.php
More information from the API.
Full changelog
- Convert the serial autodetect functions to use int instead of char to
enumerate devices.
- Make the serial open timeout for BFL generically 1 second on windows.
- Deuglify windows autodetect code for BFL.
- There is no point zeroing temperature in BFL if we fail to get a response, and
we should register it as a HW error, suggesting throttling.
- Update SCRYPT README with information about HW errors.
- Use the scrypt CPU code to confirm results from OCL code, and mark failures as
HW errors, making it easier to tune scrypt parameters.
- We may as well leave one curl still available per pool instead of reaping the
last one.
- Need to recheck the pool->curls count on regaining the pool lock after the
pthread conditional wait returns.
- Display reaped debug message outside mutex lock to avoid recursive locking.
- Add specific information when ADL detects error -10 saying the device is not
enabled.
- api.c update API start message and include port number
- miner.php ignore arg when readonly
- miner.php allow pool inputs: delete, addpool, poolpriority
|
|
|
|
I was unaware of the reports in this thread. But have discovered problems with 2.6.3 myself.
I upgraded my 12 computers to 2.6.3 yesterday. Two of the computers would not mine correctly. The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command. When I reverted to version 2.5.0 they resumed working.
The other computers didn't have any issues.
10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5. 2 machines run Windows 7. The failing computers were running Ubuntu 11.04.
None of what you describe seems related to the other bug discussed here. You appear to have stumbled on something completely different, but what, I haven't got the faintest, unless you happened to be building from git and picked a bad commit to build from. I am building from git. I discovered this problem 12/6/12 9:00 pm EST and was building then. All the Ubuntu machines are made the same way. The four cards in the two misbehaving computers are: 3 5870's, 1 6850. Then I think you got that one dud commit which has since been fixed which caused massive damage. 8897e0657507072448f4e951ce1caadca15b4b30 was the dud commit and it was fixed by 3dd1658e1f3410dfdf00b267593a3cbe7041c645. Check git log to see what you're up to. |
|
|
|
I was unaware of the reports in this thread. But have discovered problems with 2.6.3 myself.
I upgraded my 12 computers to 2.6.3 yesterday. Two of the computers would not mine correctly. The screen would show only one card out of two with a non-zero hash rate but no shares were generated plus the graphics cards were not loaded as shown with the aticonfig command. When I reverted to version 2.5.0 they resumed working.
The other computers didn't have any issues.
10 of my machines run Ubuntu 11.04, ati driver 11.6, SDK 2.5. 2 machines run Windows 7. The failing computers were running Ubuntu 11.04.
None of what you describe seems related to the other bug discussed here. You appear to have stumbled on something completely different, but what, I haven't got the faintest, unless you happened to be building from git and picked a bad commit to build from. |
|
|
|
|
That bug is looking pretty consistent now. Thanks for the reports. I guess the spotfire period is not over yet for 2.6.x. I will put up a "stable" vs "development" link on the front page since it's still not up to 2.5 stability till I can sort it out.
|
|
|
|
Well I *have* seen reports of new instability with cgminer that people running certain antivirus programs ran into (?avast or something).
I'm running AVG, but the cgminer directory is excluded. I haven't had any other versions of cgminer crash like that before. I went back to 2.6.2 for now. Just telling you what I've seen, and different versions get a different response from the same antivirus software. Quite sure AVG was mentioned and only gets better with a full uninstall, but it's up to you how to tackle it. I only recommend microsoft security essentials, but I'm not a windows person by nature. Even games like HL2 have the same issues... https://support.steampowered.com/kb_article.php?ref=9402-MKEN-1517 |
|
|
|
|
Well I *have* seen reports of new instability with cgminer that people running certain antivirus programs ran into (?avast or something).
|
|
|
|
|
That's really funny/sad/disappointing/pissing me off. Apart from being able to recover from hardware errors, it seems that there is nothing good about all the BFL fixes that went into 2.6.x so far even though 2.5.0 was littered with bugs. The only way I can imagine that the U is lower with the new code is that you are having lots of throttling episodes and it is now throwing out the work during those throttling episodes in an attempt to try and recover - this should be obvious because 2.6.3 will throw a hardware error if it does that. There really isn't anything else that should affect utility that I can think of. Perhaps it's actually keeping the device busier for more sustained periods and it throttles more as a result. Do you get any hardware errors?
EDIT: Oh and usual comment about utility being related to luck till thousands of shares have passed.
|
|
|
|
(long rant snipped).
But I like reading rants come on give it all you got. Doesn't scrypt just piss you off, don't you hate us all for putting you through all this black magic? Come on ckolivas get mad! Yes indeed, scrypt mining, along with BFL code, can suck my engorged knob. I'd offer that to luke-jr as well, but he might enjoy it so I won't. |
|
|
|
|
Show Posts
