4 GPUs on 1 computer, and I've got 1 instance of GPUMiner open using cgminer.
Well I have no idea what GPUMiner is. But 5830's should be getting 300+Mhash/s though. I spoke too soon...all 4 of my 5830s are averaging 220 MHash each now, and they aren't overheating because the temp is only 60c for each of them Sigh...so frustrating, maybe its time to finally quit after mining for 1.5 years. All because I decided to switch to new version of GUIminer with cgminer. I used to use old guiminer version + phoenix Can't really debug it with guiminer in front of it. Try cgminer direct. |
|
|
|
And another (this in 2.9.6): $ gdb cgminer core.29958
GNU gdb (GDB) Fedora (7.3-43.fc15)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/cgminer...done.
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/3a/8fe6cb0063d56fc9be76ecd085c05f1b8a76e6
[Thread debugging using libthread_db enabled]
Core was generated by `cgminer -o http://GBTPOOL:GWPORT -O x:y'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000003c6f67abcc in free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.14.1-5.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 libcurl-7.21.3-11.fc15.x86_64 libgcc-4.6.0-10.fc15.x86_64 libssh2-1.2.7-1.fc15.x86_64 libstdc++-4.6.0-10.fc15.x86_64 mesa-libGLU-7.11-1.fc15.x86_64 nspr-4.8.8-1.fc15.x86_64 nss-3.12.10-6.fc15.x86_64 nss-softokn-freebl-3.12.10-2.fc15.x86_64 nss-util-3.12.10-1.fc15.x86_64 openldap-2.4.24-3.fc15.x86_64 openssl-1.0.0g-1.fc15.x86_64 xorg-x11-drv-catalyst-libs-11.6-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
(gdb) bt full
#0 0x0000003c6f67abcc in free () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004093d9 in submit_upstream_work (work=0x7fa534000b10,
curl=0x7fa5340014a0, resubmit=false) at cgminer.c:2336
gbt_block = 0x3966373762363563 <Address 0x3966373762363563 out of bounds>
varint = 0x6663336638373135 <Address 0x6663336638373135 out of bounds>
data = "\002\000\000\000H\005\321\\\207\366\271\256[\254\311A\200\251\372s\311\350S\234\246\264\345\322\337\003\000\000\000\000\000\000\232\313W\272\233 \r\203-\375P\006N\222\255\062\025\204\252Z\226\230\205\233s\254b1\002\251\367_UÕ»P\352\340\004\032\071\356\234\033"
hexstr = 0x3739313030303030 <Address 0x3739313030303030 out of bounds>
val = 0x3335363632353435
res = 0x6634613266623831
err = 0x3966376163613262
s = "{\"id\": 0, \"method\": \"submitblock\", \"params\": [\"020000004805d15c87f6b9ae5bacc94180a9fa73c9e8539ca6b4e5d2df03", '0' <repeats 12 times>, "9acb57ba9b200d832dfd50064e92ad321584aa5a9698859b73ac623102a9f75f55d5bb50eae0041a39ee"...
rc = 55
thr_id = 808464481
cgpu = 0x3135636361383833
pool = 0x3435653636343365
rolltime = 0
hash32 = 0x3139613637393130
tv_submit = {tv_sec = 0, tv_usec = 0}
tv_submit_reply = {tv_sec = 0, tv_usec = 0}
hashshow = '\000' <repeats 67 times>
worktime = '\000' <repeats 199 times>
#2 0x6461393935383765 in ?? ()
No symbol table info available.
<snip>
#90 0x0000000000424eba in sha2_update (ctx=Cannot access memory at address 0x653561383730341d
) at sha2.c:259
fill = <error reading variable fill (Cannot access memory at address 0x653561383730342d)>
left = <error reading variable left (Cannot access memory at address 0x6535613837303431)>
Cannot access memory at address 0x653561383730343d
(gdb) Interesting. The only thing I can think of that could cause this is trying to submit a share even before gbt is fully set up, or the gbt structures sent by the pool are corrupt somehow. Does this happen shortly after startup? Is the GBT pool somewhere I can test it publicly or is this your custom pool? Thanks. |
|
|
|
So current miners try GBT first, and if it has a Stratum HTTP header they switch to Stratum.
I have no idea how it works with GBT in miners. That X-Stratum is for getwork protocol... GBT is all done in http so the headers can just as easily contain x-stratum as getwork does, and cgminer will still switch to stratum if it finds the header in gbt comms. |
|
|
|
|
New version - 2.9.6, 2nd December 2012
Minor bugfixes.
Human readable changelog:
Fixed further crashes with GBT mining.
Scrypt mining now shows more of the relevant hash portion and higher diffs than just 65.5k.
Full Changelog:
- Make gen_stratum_work more robust by using a dynamically allocated array for
the header in case bogus data is sent by the pool to avoid overflowing a static
array.
- scrypt_diff now returns a uint64_t
- Support monitoring and reporting much higher diffs for scrypt mining,
truncating irrelevant zeroes from displayed hash.
- Pass ostate values around in scrypt to be able to extract full hashes if
needed later on.
- Since we will be using calloc_str to put a string into it, convert the
function to calloc_strcat which does it automatically.
- Revert "Handle crash exceptions by trying to restart cgminer unless the
--no-restart option is used."
- Count longpoll and GBT decodes as queued work since the count otherwise
remains static.
- Use the string helper functions to create gbt blocks of any length.
- Provide helper functions calloc_str and realloc_strcat to create and extend
arbitrary length arrays based on string length.
|
|
|
|
|
There was a huge spike in hashrate just before the block halving as people tried to get the "last block" and the "first block" and then that stopped. Since then, the hashrate is pretty close to what it was before the spike. What's actually happening is the vast majority of miners are still hanging in there. It will just take time for the reality of mining at a loss to get through to them. There are an awful lot of miners that are just hopeful the value will go up, and there are still a heap of miners who honestly don't even know the reward has halved. It will just take time for the new steady state to be reached, but by then ASICs will have honest and truly hit, so there may well be no significant drop in hashrate at any stage. Don't underestimate the power of inertia on human nature.
|
|
|
|
I really wouldn't celebrate... all the GPU btc mining escapees will blow your difficulty out of the water killing your mining profit margins. Difficulty is supposed to parallel price. Price does not go up just because miners are driving difficulty up.
And as expected, difficulty has now been driven past the point of profitability in no time  |
|
|
|
|
LTC just died in the arse as a bunch of GPU miners jumped on board for a bit and pushed difficulty beyond profitability. I did warn them that the BTC halving would hurt LTC but they saw more people mining as a good thing. The LTC fanboys thought that more people mining would somehow magically drive LTC prices up when there is no such mechanism.
|
|
|
|
Been having random crashes ever since I upgraded to 2.9.5 from 2.4.x. My install is 1½ years old Ubuntu 11.04, with 11.6 drivers and 2.4 SDK I believe. Runs fine for a day or so, and this happens on both a 4x 5970 machine and a 5x 58xx one.
It screws up the screen output a bit when it crashes, and looks like this:
Any ideas? Should I just downgrade back to 2.4 as that seemed to work, I mainly updated due to stratum but I suppose that's not really necessary atm.
Absolutely do not downgrade please. Are you running with a pool, backup or otherwise, with GBT at all? There is still one bug when mining on GBT which is only fixed in git. Alternatively run a debug build with core dumps enabled and get a backtrace if you know how. Sorry, I'm pretty much clueless around linux/cgminer  Primary pool is eclipse (GBT), secondary is btcguild with Stratum. EDIT: It seems git has a newer version, will try if that helps. Yes please try the git version then since you have a gbt pool. I also recommend connecting to EMC's stratum pool instead. |
|
|
|
Been having random crashes ever since I upgraded to 2.9.5 from 2.4.x. My install is 1½ years old Ubuntu 11.04, with 11.6 drivers and 2.4 SDK I believe. Runs fine for a day or so, and this happens on both a 4x 5970 machine and a 5x 58xx one.
It screws up the screen output a bit when it crashes, and looks like this:
Any ideas? Should I just downgrade back to 2.4 as that seemed to work, I mainly updated due to stratum but I suppose that's not really necessary atm.
Absolutely do not downgrade please. Are you running with a pool, backup or otherwise, with GBT at all? There is still one bug when mining on GBT which is only fixed in git. Alternatively run a debug build with core dumps enabled and get a backtrace if you know how. |
|
|
|
Thus, all the efforts now for cgminer development should be in the direction of LTC (scrypt)  I only work on something if there's an incentive of some sort. |
|
|
|
cgminer version 2.9.5 - Started: [2012-11-30 18:39:27]
--------------------------------------------------------------------------------
(5s):0.000 (avg):0.000h/s | Q:9 A:0 R:0 HW:0 E:0% U:0.0/m
TQ: 0 ST: 12 SS: 0 DW: 5 NB: 2 LW: 20 GF: 1 RF: 0 WU: 0.0
Connected to coinotron.com with LP as user Nolo.5
Block: 2eee5f52bb986e0aa827f861... Started: [18:39:30] Best share: 0
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S ]ettings [D]isplay options [Q]uit
GPU 0: 51.0C 1216RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 1: 44.5C 1244RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 2: 39.0C 1237RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 3: 39.5C 1270RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
--------------------------------------------------------------------------------
[2012-11-30 18:39:27] Thread 1 being disabled
[2012-11-30 18:39:28] Error -5: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
[2012-11-30 18:39:28] GPU 2 failure, disabling!
[2012-11-30 18:39:28] Thread 2 being disabled
[2012-11-30 18:39:28] Error -5: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
[2012-11-30 18:39:28] GPU 3 failure, disabling!
[2012-11-30 18:39:28] Thread 3 being disabled
[2012-11-30 18:39:30] LONGPOLL from pool 0 detected new block
What does this error -5 mean?
#define CL_OUT_OF_RESOURCES -5 Combination of your current graphics requirements and your choice of settings for your hardware is too high. |
|
|
|
CGMiner attempting undesired conection to IP in Germany on every primary pool fail. Dare to "explain" it a bit?  You sir, imply some very serious allegations and I suggest you consult your lawyers before posting such drivel before I sue you for libel. You are connecting to 50BTC.com and this is what 50BTC is sending you: [2012-12-01 09:29:51] HTTP hdr(X-Long-Polling): http://5.9.207.236:8331/LP That address is where 50BTC's longpoll comes from. If you don't want to connect to there, use a different pool. |
|
|
|
What I really worry about, is that new hardware will continue to come out frequently enough that people end up on a cycle of investing in hardware that basically never pays itself off as slightly newer hardware and higher diffs keep coming out. Sure at some stage the limits of technology will be reached, but given the best tech at the moment is going to be 65nm ASICs when CPUs are 28nm devices, I can see the cycle going on for some time, and then even if btc mining ASICs end up in line with CPU manufacturers, they still continue to evolve over time. Dramatic profits from ASICs will likely only last a couple of weeks at most for a lucky few. The rest of you who paid for devices that don't even exist yet will not be making any magical profit no matter how big the hashrate appears. Your proportion of the total bitcoin hashrate will remain pitiful.
Sigh...
There's definitely some merit to this, but remember, the exact same thing happens with Video Cards, every 9-12 months the new GPU cards hit the market and are more efficient at mining. Of course video cards are much less expensive than the current round of ASIC's and can be resold. The resale and multipurpose nature of them is what makes the equation so different though. My 7970s are selling for more than half of what I bought them for. Though I had to invest the money in the first place, there is still that extra return on selling them at the end, provided you don't try to keep them forever. |
|
|
|
Hmm. So cgminer tries GBT first, and if it sees no Stratum header it stays on GBT?
In order of priority, cgminer will try to mine on stratum first, gbt second and getwork if all else fails, based on what order I think mining should occur. As far as I'm concerned, it's up to the pool operator to decide what they think is most important to prioritise. If you want to put a stratum redirect header in your GBT based pool, that's entirely your choice, knowing that cgminer will then use stratum preferentially. You can see the way cgminer prioritises the different protocols based on what I think is best for miners and pools, and the rest is up to you. |
|
|
|
|
I've always thought FPGAs were a waste of money. Assuming ASICs come in the next 2 months, indeed hardly anyone would have made a return on investment with FPGAs yet they will find themselves with devices that have no other realistic useful purpose - AKA doorstops. I have never spent a cent on FPGAs, do not own one, and have only gotten involved with their development when no one else could find solutions to awkward problems with them. On the other hand, GPUs have only just fallen below profitability, yet if you factor in resale value for them, they still don't look so bad compared to FPGAs, but mining long term on them seems a waste now. I never once believed GPU mining would die in the face of FPGAs unless the status quo was somehow magically maintained for years which I never believed would happen.
However, ASICs are a totally different ball game. They basically will redefine what mining means with bitcoin, where there is no point mining with anything else if any profit is to be made. They will make GPUs, and even FPGAs, look totally useless to mine with. 1 year from now, absolutely no one will be mining BTC on anything but ASICs, except for newbies to bitcoin mining, who will ask the obvious questions about GPU mining, and still even CPU mining.
I will sorely miss the "anyone can use their spare hardware to mine with" aspect to bitcoin mining. I honestly believe that is more true to the ideal of bitcoin, where everyone running a node was contributing to its security. However, what spare hardware people had has changed dramatically recently anyway as PCs are dramatically on the decline and people move to more portable devices with less CPU/GPU power in the form of tablets and phones etc. Alas the algorithm lends itself really well to ASIC based mining, meaning everything else will be a complete waste of time. Now while cgminer will continue to work on alternate cryptocurrencies, I honestly think all the alternative cryptocurrencies will go nowhere. The only reason to mine them is to find something that can be profitable by converting it to BTC.
Down the track, cgminer will indeed be used mostly to mine with dedicated ASIC hardware to mine BTC. GPU mining for BTC will be as irrelevant then as CPU mining is today. I don't like the fact that the network will be secured with devices from 4 or 5 manufacturers making hardware that serves only one purpose - btc mining. While BTC mining previously was still only in the hands of intel, amd and nvidia, the fact is it was not on their radar at all. Bitcoin mining was a lucky aside they did, where AMD/ATI GPUs happened to do better than anyone else, and anyone with spare cycles on their hardware could choose to contribute and earn a little on the side.
Long term, cgminer will be the lowest overhead c software to drive ASICs to do bitcoin mining, with lots of code in it that is no longer relevant to BTC mining. What I really worry about, is that new hardware will continue to come out frequently enough that people end up on a cycle of investing in hardware that basically never pays itself off as slightly newer hardware and higher diffs keep coming out. Sure at some stage the limits of technology will be reached, but given the best tech at the moment is going to be 65nm ASICs when CPUs are 28nm devices, I can see the cycle going on for some time, and then even if btc mining ASICs end up in line with CPU manufacturers, they still continue to evolve over time. Dramatic profits from ASICs will likely only last a couple of weeks at most for a lucky few. The rest of you who paid for devices that don't even exist yet will not be making any magical profit no matter how big the hashrate appears. Your proportion of the total bitcoin hashrate will remain pitiful.
Sigh...
|
|
|
|
|
I really wouldn't celebrate... all the GPU btc mining escapees will blow your difficulty out of the water killing your mining profit margins. Difficulty is supposed to parallel price. Price does not go up just because miners are driving difficulty up.
|
|
|
|
Please add --no-restart
That way it will not try to restart if it crashes, which is stopping it from dumping properly. Thanks. Does this help? I truncated everything after the #2 because they all (737) said "No symbol table info available." gdb cgminer core.15150
GNU gdb (GDB) Fedora (7.3-43.fc15)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/cgminer...done.
[New LWP 15230]
[New LWP 15205]
[New LWP 15158]
[New LWP 15209]
[New LWP 15157]
[New LWP 15150]
[New LWP 15210]
[New LWP 15207]
[New LWP 15202]
[New LWP 15206]
[New LWP 15203]
[New LWP 15212]
[New LWP 15208]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/3a/8fe6cb0063d56fc9be76ecd085c05f1b8a76e6
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Core was generated by `cgminer -o http://GBTPOOL:GWPORT -O x:y'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000003c6f67e8c1 in strcat () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-18.fc15.x86_64 glibc-2.14.1-5.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 libX11-1.4.3-1.fc15.x86_64 libXau-1.0.6-2.fc15.x86_64 libXext-1.2.0-2.fc15.x86_64 libXinerama-1.1.1-2.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libcurl-7.21.3-11.fc15.x86_64 libgcc-4.6.0-10.fc15.x86_64 libidn-1.19-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libssh2-1.2.7-1.fc15.x86_64 libstdc++-4.6.0-10.fc15.x86_64 libxcb-1.7-2.fc15.x86_64 mesa-libGLU-7.11-1.fc15.x86_64 ncurses-libs-5.8-2.20110319.fc15.x86_64 nspr-4.8.8-1.fc15.x86_64 nss-3.12.10-6.fc15.x86_64 nss-mdns-0.10-9.fc15.x86_64 nss-softokn-freebl-3.12.10-2.fc15.x86_64 nss-util-3.12.10-1.fc15.x86_64 openldap-2.4.24-3.fc15.x86_64 openssl-1.0.0g-1.fc15.x86_64 xorg-x11-drv-catalyst-libs-11.6-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
(gdb) bt full
#0 0x0000003c6f67e8c1 in strcat () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004093f0 in submit_upstream_work (work=0x7f67e4000c00, curl=0x7f67e400b5f0,
resubmit=false) at cgminer.c:2331
gbt_block = "02000000ca538130d3b31ccc24be835ba05bf2b8c41f8dfe8c112584ca03", '0' <repeats 12 times>, "8d4ca763df01df8377efc6a798d0607e3325259b4923e603308d8237d8ece2b97a22b650eae0041a11865698400100000001", '0' <repeats 64 times>, "ffffffff4b034e34030e"...
varint = 0x3030303030303030 <Address 0x3030303030303030 out of bounds>
header = 0x3136646362313465 <Address 0x3136646362313465 out of bounds>
data = "76a914dcacb1cb4f31a6a3a239ae0199626bce00a72c3788acacc59502000000001976a91428220c"
hexstr = 0x3838376332663736 <Address 0x3838376332663736 out of bounds>
val = 0x3633343139613637
res = 0x3931303030303030
err = 0x3030303030306461
s = "4188acb896", '0' <repeats 12 times>, "1976a914f52651ec8fe199ea975c63fc36369364c31fe80288ac980b", '0' <repeats 12 times>, "1976a9140f9bfe4cfd6c45c623a77d8087982c41a6fef69588ac50a2", '0' <repeats 12 times>, "1976a914cccdfc3b5e7ae849041e954dc48f47b96b2219f4"...
rc = 57
thr_id = 959918646
cgpu = 0x3239333738353534
pool = 0x6465343939663962
rolltime = 1681469798
hash32 = 0x6639313265646462
tv_submit = {tv_sec = 7306075964502533688, tv_usec = 4121744960866432049}
tv_submit_reply = {tv_sec = 4134645543713452080, tv_usec = 3978477492665463857}
hashshow = "ad", '0' <repeats 12 times>, "1976a9141f24c264b0f47ece27326a3905be9b91fd1da97788ac34"
worktime = "ac4c320200000000001976a914bd43b675c496b8b13bde490465ea355a94136faf88acc0543a00000000001976a914bcd6b30774cc7bdcc922e4f1817ca035667b18cd88acd46e1800000000001976a9147cb7a1d86ddddcdc8ef192cbd0bc67a370524b"
#2 0x3931303030303030 in ?? ()
No symbol table info available. It sure does. This bug should be fixed in git now, thanks! |
|
|
|
One question about "Best share:" ... is it working correctly when Solo Mining?
Yes |
|
|
|
In case anyone wants me to try something else... Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full
And post the information from that please. I'm getting "No stack." I assume that makes it obvious I've never done this before... ETA: cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g Also, FYI, this is the exact error I was getting in 2.9.4 on GBT only: Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing latest version, x86_64 linux, build with -02 -Wall I'm not sure whether the fact that it is also happening on that other miner will make you laugh or cry... Well that's my code so it's no surprise... Please add --no-restart That way it will not try to restart if it crashes, which is stopping it from dumping properly. Thanks. |
|
|
|
|
Show Posts
