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

I just tried enabling solo mining on my machine and initially it leaked some shares to the backup pools and then again when there was a new block, but then it settles down and mines solo till the next block and repeats the cycle.

This seems like normal behavior to me.  This machine uses two GPU's at about 510Mhs.
Sam

I see...

But, and I hate to pester, that raises so many questions in my head. Wouldn't doing that mean my machines are definitely not working anywhere near what they're supposed to be? And then, if bitcoind is really THAT slow, I don't see how solo mining was ever worth it.. here's a picture of solo mining with one bfl single for ~30 minutes. This was the only device solo mining on the network at the time:
http://i.imgur.com/tRgwI.png
More than half of the work is going toward pool 2 (pool 1 is down, probably a coincidence). I mean, is it only not complaining that pool 0 is too slow because it can grab work from pool 2? Or is it designed to not put those kinds of errors when soloing? Pretty sure I've seen them before when solo, on an NB or something..

Here we have soloing now with --failover-only, ~45 minutes, everything else the same (even pool 1 is still down  ) :
http://i.imgur.com/kYkXO.png
Sorry about the disparity in uptime, but the last prompt makes me believe that bitcoind is only fast enough to provide half of what the single can handle. Temps are also the same, so it's safe to assume the single is being worked pretty closely to the last prompt as well. Everything is the same.. not sure if that matters but it seems to matter.

But if I'm misunderstanding all of this, which is fine; what is the "limit" of bitcoind in GH/s? Will solo'ing on one of those new ASIC mini-rigs basically be a no-go? I appreciate learning about this as it interests me greatly.

It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.

I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.

I am so confused, haha.

Thanks, much appreciate the useful filtering, and thanks luke-jr for your debugging.

Con, I hope quoting this so you can see it doesn't come off wrong:
The issue doesn't affect me, and presumably Kano has already seen it and could even be dealing with it, but I figure better safe than sorry, and this particular post seems both civil and useful enough to be worthy of your time.

Great feedback, thanks. Please email me the old binaries [email protected] (one at a time or email will reject them), thanks!

I have some of your old windows binaries. Not sure if it would be any help for you.
I have 2.4.4, 2.5.0, 2.6.2, 2.6.3, 2.6.4, 2.6.5 and the current 2.7.0 I didn't grab 2.6.0 or 2.6.1 because of BFL issues and since I only have a single to mine with it didn't seem helpful.

Thank You for making WU field. My backup pool uses difficulty 8 shares so I used to have to use just the average because U would be lower due to occasional work from backup pool. My Rejects are maybe 10% of what 2.6.5 had me at. I have had 0 hardware issues today all issues where throttling related and today was cooler, my average is so far 11 Mhash faster and my U is maybe lower but WU is at 12. Very short test so far only hours not days to fully break in the averages but still.

So far it works great for me, no pool slow to provide work, averge higher, shares bleeding to the backup so I get paid rather then a delay on working.

Your crash is entirely within the AMD driver, so either you are having a hardware problem (dodgy card, too much overclocking, overheated vrms etc) or a driver problem. Can't see anything in the backtrace related to cgminer.

Hi ckolivas,
I have an issue with one of the rigs (2 x 5850), no matter which version of cgminer I use. GPU1 dies in matter of a couple of hours, rig does not respond, sometimes a hard reset is inevitable.
The system runs:
CentOS 6.3
kernel 2.6.32-279.5.1.el6.x86_64
glibc-2.12-1.80.el6_3.4.x86_64
glib2-2.22.5-7.el6.x86_64
gcc-4.4.6-4.el6.x86_64
AMD-APP-SDK-v2.5-lnx64
ati-driver-installer-11-12-x86.x86_64

I tried the latest cgminer-2.7.0, not using any optimizations at all except intensity set to 2. The following is grabbed from /var/log/messages.
--------------------------------------------------------------------------------------------------------------------------------------
Aug 19 06:08:21 hostname kernel: [fglrx] ASIC hang happened
Aug 19 06:08:21 hostname kernel: Pid: 3430, comm: cgminer Tainted: P           ---------------    2.6.32-279.5.1.el6.x86_64 #1
Aug 19 06:08:21 hostname kernel: Call Trace:
Aug 19 06:08:21 hostname kernel: [] ? KCL_DEBUG_OsDump+0xe/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_hardwareHangRecovery+0x1c/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic9WaitUntil15ResetASICIfHungEv+0x9/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic9WaitUntil15WaitForCompleteEv+0x9c/0xf0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic19PM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RING_+0xaf/0x170 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN15QS_PRIVATE_CORE27multiVpuPM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RIN G_+0x33/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _Z19uQSTimeStampRetiredmjj14_LARGE_INTEGER+0x74/0x80 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _Z8uCWDDEQCmjjPvjS_+0x54d/0x10c0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? down+0x2e/0x50
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE32+0x0/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_ioctl+0x1ed/0x250 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? __do_page_fault+0x1ec/0x480
Aug 19 06:08:21 hostname kernel: [] ? ip_firegl_unlocked_ioctl+0xe/0x20 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? vfs_ioctl+0x22/0xa0
Aug 19 06:08:21 hostname kernel: [] ? do_vfs_ioctl+0x84/0x580
Aug 19 06:08:21 hostname kernel: [] ? sys_ioctl+0x81/0xa0
Aug 19 06:08:21 hostname kernel: [] ? system_call_fastpath+0x16/0x1b
Aug 19 06:08:21 hostname kernel: pubdev:0xffffffffa049ed20, num of device:2 , name:fglrx, major 8, minor 92.
Aug 19 06:08:21 hostname kernel: device 0 : 0xffff88007a1b0000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90000340000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xd0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xdfb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xd0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xdfd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1500000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1300000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1200000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1100000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1000000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xf00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xe00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xd00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x800000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x500000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:6, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x20000ec0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x1920 , CP_RB_WPTR :0x1920.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x2686f000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x2686f000,phys:0x7b4f5000.
Aug 19 06:08:21 hostname kernel: device 1 : 0xffff88003759c000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90004980000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xe0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xefb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xe0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:20, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xefd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2c00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2b00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2a00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2900000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2800000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2600000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1d00000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x900000, reference count:3, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:5, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x200006c0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x6970 , CP_RB_WPTR :0x6990.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x262e7000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x262e7000,phys:0x693c3000.
Aug 19 06:08:21 hostname kernel: Dump the trace queue.
Aug 19 06:08:21 hostname kernel: End of dump
-----------------------------------------------------------------------------------------------------------------------------------

Can you see anything that causes the problem?
Thx in advance.
 
 

Yes it's definitely a bug introduced in 2.6.5 when I tried to work around windows' timers. Why, I dunno cause I can only try it on a laptop with windows that does 9.5Mhash so it's not a very useful piece of hardware to test it on...

I can confirm the same bug with intensity pegging down to -10 on dynamic but in my instance without the high CPU usage.
I upgraded from 2.6.4 which didn't have the problem.

ckvoilvas

I highly recommend you move your hosting to BTCWebHost.com, we are the oldest and most trusted Bitcoin accepting hosting provider in the world. You will never have to worry about anything like this happening again and best of all you can pay in Bitcoin.

-Tom
BTCWebHost.com
Bitcoinwebhost.com
Bitcoinwebhosting.com
BitcoinVPS.com

I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke

What is the CGMINER GPU status and CGMINER pool status? Are your other network applications continue operating when you switch user?

Use cgminer API to read GPU and POOL status.

Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.

Does the cgminer actually crash or continues running in ALIVE state and not submitting shares?

If cgminer actually crashes, post WER details.

If cgminer process is still running, check GPU/PGA and pool statuses using ANUBIS or other API status display tools.

I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.