OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 582.

DutchBrat

hero member

Activity: 868

Merit: 1000

Quote from: jddebug on May 03, 2012, 11:48:24 AM

Problem with version 2.4.0 that has been reported by one other than me.

If cgminer switches to your configured backup pool, it will not switch back on its own. At least for 2 of us.

FYI

I experienced that on 1 of 7 mining rigs

All have the same setup, all were running 2.4.0.

So not sure what the trigger was for this to happen

All WinXp 12.4 58XX series

jddebug

sr. member

Activity: 446

Merit: 250

Problem with version 2.4.0 that has been reported by one other than me.

If cgminer switches to your configured backup pool, it will not switch back on its own. At least for 2 of us.

FYI

EDIT: My config was set to --failover-only in case that has something to do with the bug.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: twmz on May 03, 2012, 11:19:54 AM

This wasn't about unplugging and plugging a device in. It was about crashes. If the BFL unit fails at some point (as is happening with one of mine), it used to just die and be dead forever. Now, it goes into a disabled state and you can attempt to restart it from the API without having to completely restart cgminer.

I don't think anything has changed with hotplug support (i.e. it's still not supported).

From your description I assume you are running Linux. I'm on Windows, where cgminer 2.3.6 quits to the command prompt if a BFL dies. I'll have to do some testing of 2.4.0 to characterize its new behavior before general deployment.

Currently I launch 2.3.6 from a (Windows) batch file containing a loop; if a BFL unit dies, 2.3.6 exists and the batch file simply restarts it automatically. Works well for me, which is why I hesitate to jump onto 2.4.0 without first understanding its changed behavior.

Regarding cgminer's API, anyone have experience using it under Windows?

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:33:01 AM

Quote from: af_newbie on May 03, 2012, 06:28:33 AM

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.

Con, sorry, maybe I was not clear. Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name. When the user upgrades to next version of cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate. When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

twmz

hero member

Activity: 737

Merit: 500

Quote from: Epoch on May 03, 2012, 09:36:22 AM

Quote from: -ck on May 03, 2012, 01:43:11 AM

NEW VERSION: 2.4.0 - May 3, 2012

Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.

I'd like clarification on this point, please.

I understand that if cgminer is mining, a Single is unplugged, cgminer will continue mining. What isn't clear from the changelog is what happens when the Single is plugged back in. Will an automatic attempt be made to re-detected it? If so, will cgminer stop trying after some time limit, or will it continue the attempt indefinitely? Or is there something that needs to be done manually in the UI re-enable the device?

This wasn't about unplugging and plugging a device in. It was about crashes. If the BFL unit fails at some point (as is happening with one of mine), it used to just die and be dead forever. Now, it goes into a disabled state and you can attempt to restart it from the API without having to completely restart cgminer.

I don't think anything has changed with hotplug support (i.e. it's still not supported).

fred0

sr. member

Activity: 349

Merit: 250

Quote from: Inaba on May 03, 2012, 09:56:32 AM

It would be nice to have the ability to enable/disable a specific PGA unit. I have a couple of slow units, but no clue which ones they are on the rack... if I could disable them, at least i could see which light switches off.

You can do this using the API

https://bitcointalksearch.org/topic/m.875407

Inaba

legendary

Activity: 1260

Merit: 1000

It would be nice to have the ability to enable/disable a specific PGA unit. I have a couple of slow units, but no clue which ones they are on the rack... if I could disable them, at least i could see which light switches off.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:06:23 AM

Quote from: OpytZabilParol on May 03, 2012, 06:02:38 AM

Quote

I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s

Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

ancow

full member

Activity: 373

Merit: 100

Quote from: -ck on May 03, 2012, 07:35:00 AM

Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.

Since I'll be out for a while and haven't seen any more commits in a while here's the current git's backtrace:

Code:

Core was generated by `. cgminer -k poclbm --benchmark -I 4'.
Program terminated with signal 11, Segmentation fault.
#0  __list_add (next=0x0, prev=0x1ce2bc0, new=0x40edcc8) at elist.h:37
37              next->prev = new;
(gdb) bt
#0  __list_add (next=0x0, prev=0x1ce2bc0, new=0x40edcc8) at elist.h:37
#1  list_add (head=0x1ce2bc0, new=0x40edcc8) at elist.h:53
#2  recruit_curl (pool=0x1ce2ac0) at cgminer.c:1991
#3  pop_curl_entry (pool=0x1ce2ac0) at cgminer.c:2005
#4  0x0000000000409785 in get_work_thread (userdata=0x4146770) at cgminer.c:2046
#5  0x00007fdfb8fa7b50 in start_thread (arg=) at pthread_create.c:304
#6  0x00007fdfb7fb690d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

This includes https://github.com/ckolivas/cgminer/commit/852f6a0eb02f1c5a715a62e6b1142ca684aa4611 and a clean rebuild. Hopefully it'll help...

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: -ck on May 03, 2012, 01:43:11 AM

NEW VERSION: 2.4.0 - May 3, 2012

Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.

I'd like clarification on this point, please.

I understand that if cgminer is mining, a Single is unplugged, cgminer will continue mining. What isn't clear from the changelog is what happens when the Single is plugged back in. Will an automatic attempt be made to re-detected it? If so, will cgminer stop trying after some time limit, or will it continue the attempt indefinitely? Or is there something that needs to be done manually in the UI re-enable the device?

xzion

member

Activity: 96

Merit: 10

Quote from: -ck on May 03, 2012, 05:29:13 AM

Quote from: OpytZabilParol on May 03, 2012, 05:27:20 AM

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

Wrong, you should downgrade your driver and read the FAQ.

the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ancow on May 03, 2012, 08:17:42 AM

I don't think it is. After all, then you'd have an even harder time getting the precompiled bins ckolivas provides (assuming he still does) to run on a less optimal SDK version. This way, at least you can get a faster .bin without having to fuck up your system trying to install different SDKs.

I stopped collecting these because the number of downloads was very small and I removed the directory. Part of the reason i was collecting them was that long term bug where it would fail to build the kernel .bin files (due to amazing AMD stupidity on a scale I could never have imagined). That bug has since been fixed.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: af_newbie on May 03, 2012, 08:12:09 AM

You're right. You probably would need an SDK version in there as well. Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch. But over time, SDK-cgminer versions in the bins might be the ticket. Just an idea might be worth considering.

I've actually considered it in the past but the limitation was the way the SDK reported back its version: "OpenCL 1.1 AMD-APP (844.4)" for example. It's a rather long name to add to the filename and doesn't say anything about SDK 2.6, and each of linux, windows, 32, 64 bit have different versions as well (by the way cgminer tries to detect each of them but the list is getting longer every day). The only purpose it would serve is debugging for me on the forum when someone says their hashrate is slow. However, if their hashrate is slow, I can say with 101% certainty they're on SDK 2.6 or later.

ancow

full member

Activity: 373

Merit: 100

Quote from: af_newbie on May 03, 2012, 08:12:09 AM

Quote from: -ck on May 03, 2012, 06:59:24 AM

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

You're right. You probably would need an SDK version in there as well. Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch. But over time, SDK-cgminer versions in the bins might be the ticket. Just an idea might be worth considering.

I don't think it is. After all, then you'd have an even harder time getting the precompiled bins ckolivas provides (assuming he still does) to run on a less optimal SDK version. This way, at least you can get a faster .bin without having to fuck up your system trying to install different SDKs.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.

ancow

full member

Activity: 373

Merit: 100

When running the latest cgminer with "cgminer -k poclbm --benchmark", it segfaults. Gdb says (bt with current master):

Code:

Program terminated with signal 11, Segmentation fault.
#0  0x000000000040a099 in reap_curl (pool=0xd5fab0) at cgminer.c:4036
4036            list_for_each_entry_safe(ent, iter, &pool->curlring, node) {
(gdb) bt
#0  0x000000000040a099 in reap_curl (pool=0xd5fab0) at cgminer.c:4036
#1  watchpool_thread (userdata=) at cgminer.c:4061
#2  0x00007f116e9edb50 in start_thread (arg=) at pthread_create.c:304
#3  0x00007f116d9fc90d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

According to a quick git bisect, the following commit introduced a first segfault:

Code:

4cd973264f6426c9b3db73b420bb33768f1f3d90 is the first bad commit
commit 4cd973264f6426c9b3db73b420bb33768f1f3d90
Author: Con Kolivas 
Date:   Thu Apr 26 23:29:21 2012 +1000

    Create discrete persistent submit and get work threads per pool, thus allowing all submitworks belonging to the same pool to reuse the same curl handle, and all getworks to reuse their own handle.
    Use separate handles for submission to not make getwork potentially delay share submission which is time critical.
    This will allow much more reusing of persistent connections instead of opening new ones which can flood routers.
    This mandated a rework of the extra longpoll support (for when pools are switched) and this is managed by restarting longpoll cleanly and waiting for a thread join.

However, that segfault has a different backtrace. According to git bisect, that exact backtrace was introduced by:

Code:

85008a78539f79bbec1f25fcffafe6a232e2597b is the first bad commit
commit 85008a78539f79bbec1f25fcffafe6a232e2597b
Author: ckolivas 
Date:   Wed May 2 10:12:07 2012 +1000

    Reap curls that are unused for over a minute.
    This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking.

However, you should probably do some further testing... Wink

The backtrace produced by 4cd973264f6426c9b3db73b420bb33768f1f3d90 is:

Code:

Program terminated with signal 11, Segmentation fault.
#0  __pthread_mutex_lock (mutex=0x18) at pthread_mutex_lock.c:50
50      pthread_mutex_lock.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x18) at pthread_mutex_lock.c:50
#1  0x00000000004130e3 in mutex_lock (lock=0x18) at miner.h:410
#2  tq_push (tq=0x0, data=) at util.c:625
#3  0x0000000000409705 in workio_get_work (wc=0x3621ff0) at cgminer.c:2068
#4  workio_thread (userdata=0x17414c0) at cgminer.c:3105
#5  0x00007ff96d476b50 in start_thread (arg=) at pthread_create.c:304
#6  0x00007ff96c48590d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: af_newbie on May 03, 2012, 06:57:00 AM

Con, sorry, maybe I was not clear. Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name. When the user upgrades to next version of cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate. When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

OpytZabilParol

jr. member

Activity: 63

Merit: 1

Thank you.
I cut a .bin file from cgminer-2.3.6 with the replacement and now I have 462Mh/s on new 2.4.0 version.
I have just a few days ago started using cgminer, before this was a phoenix.
Thanks again for your help.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: af_newbie on May 03, 2012, 06:28:33 AM

Quote from: -ck on May 03, 2012, 06:06:23 AM

Quote from: OpytZabilParol on May 03, 2012, 06:02:38 AM

Quote

I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s

Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: OpytZabilParol on May 03, 2012, 06:23:32 AM

Quote from: -ck on May 03, 2012, 06:06:23 AM

Quote from: OpytZabilParol on May 03, 2012, 06:02:38 AM

Quote

I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s

Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

No. Here are the contents of my folders:

This is what I'm trying to say.. .that has been said many times and is in the FAQ. If you run cgminer, it caches the binary built from the SDK installed the very first time you run it, and then even if you upgrade driver+SDK, it still runs like the old SDK. However if you install a new cgminer, there are no cached .bin files (see the .bin files in each folder), so it generates a new .bin file from the current SDK installed. The only way to compare versions 2.3.6 and 2.4.0 with your current installation of driver+SDK combination is to delete the .bin files from both of them and start them both again.

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 582. (Read 5805740 times)