OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

New version - 2.9.4, 19th November 2012

Bugfixes. This should push this version up to the status of current stable release.


Human readable changelog

Fixed the elusive stratum disconnect windows crash bug.
Fixed mining stratum on EMC.
Fixed mining GBT on bitminter.
Provided preliminary support for balance and loadbalance with stratum and GBT.
Provided support for numeric IPV6 stratum support.
Don't shoot GPU speed up to max when the temperature drops dramatically.
Quieten the pool not responding messages for backup pools.
Flush more work on longpoll that we may have been leaving behind.
Fixes to build on windows.
Support for fractional diff values with stratum.


Full changelog

- Provide rudimentary support for the balancing failover strategies with stratum
and GBT by switching pools silently on getwork requests.
- Convert remaining modminer and bfl uses of usleep to nmsleep.
- Convert libztex to nmsleep where possible.
- Convert unreliable usleep calls to nmsleep calls in ztex driver.
- Support workid for block submission on GBT pools that use it.
- Provide rudimentary support for literal ipv6 addresses when parsing stratum
URLs.
- Work around libcurl cflags not working on hacked up mingw installations on
windows.
- Only increase gpu engine speed by a larger step if the temperature is below
hysteresis instead of increasing it to max speed.
- Convert pool not responding and pool alive message on backup pools to verbose
level only since they mean a single failed getwork.
- Update work block on the longpoll work item before calling restart threads to
ensure all work but the longpoll work item gets discarded when we call
discard_stale from restart_threads.
- Do not attempt to remove the stratum share hash after unsuccessful submission
since it may already be removed by clear_stratum_shares.
- Check against a double for current pool diff.
- Support for fractional diffs and the classic just-below-1 share all FFs diff
target.

[sharky112065]

Cgminer 2.9.4 builds successfully on Windows using MinGW.  

[Smoovious]

New version - 2.9.4, 19th November 2012

Don't shoot GPU speed up to max when the temperature drops dramatically.

- Only increase gpu engine speed by a larger step if the temperature is below
hysteresis instead of increasing it to max speed.

Thank you so much for this.

CGminer is doing MUCH better at stabilizing at temperature quickly, instead of over-correcting like it had been doing over a longer period of time.

My bad-fan card clocked all the way down to 600, until the heat dissapated a minute later, then dipped below hysterisis, then rose back up by 10's back to 830 with no problem, then when the temp rose again, gradually this time, the fan and clock were able to react more smoothly, stabilizing quickly, and are now sitting stable at around 85% fan, 760 clock, and 74C degrees. As the temp drops tonight, it should get back up to 830 with the outside air being fed in at ~15C degrees.

This is much appreciated.

The only errors I have seen so far, is a couple 'method not found' errors, which appear to come only when the pools are initially probed. I assume this is when checking for stratum. They don't interrupt anything, and mining fires right up as usual. (the pools don't have stratum support)
(W32 binary on Win7)

-- Smoov

[cypherdoc]

i also should say thank you for the great updates.  my gpu's are performing vastly better.

[Joshwaa]

This fixed the issue on the one machine I had that crashed on quitting CGMiner.  Nice work man!

[Lem]

I have an issue with cgminer 2.9.x (I switched from 2.8.7 to 2.9.3, now I'm with 2.9.4).

My system has two 7970s. Usually it's capable of about 19 shares/minute. "Difficulty-1 shares", I mean.
I have many pools in my configuration file, and I use fallback policy.

Well, now I'm switching to my pool 0, rpc.hhtt.1209k.com, which is tuned for "difficulty-999 shares" (I find about one "difficulty-999 share" per hour).
See the log:

Code:

...
 [2012-11-19 10:36:29] Switching to http://pool.ABCPool.co:8332
 [2012-11-19 10:36:29] Switching to http://mtred.com:8337
 [2012-11-19 10:36:29] Switching to http://rpc.hhtt.1209k.com:8337
 [2012-11-19 10:36:29] Accepted 8d81b74e Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:36:33] Accepted 9c765368 Diff 1/1 GPU 0 pool 4 
 [2012-11-19 10:36:34] Accepted f5f6497e Diff 1/1 GPU 0 pool 4 
 [2012-11-19 10:36:37] Accepted aa91e76a Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:36:38] Accepted 17cb863a Diff 10/1 GPU 1 pool 4 
 [2012-11-19 10:36:50] Accepted b9670e13 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:36:54] Accepted 4d2b40f4 Diff 3/1 GPU 1 pool 4
 [2012-11-19 10:38:07] Accepted 142dfb12 Diff 12/1 GPU 0 pool 4 
 [2012-11-19 10:38:14] Accepted 4f4fb19d Diff 3/1 GPU 1 pool 2 
 [2012-11-19 10:38:14] Accepted 56687d8a Diff 2/1 GPU 0 pool 4 
 [2012-11-19 10:39:06] Accepted 2f83dc92 Diff 5/1 GPU 1 pool 1 
 [2012-11-19 10:39:15] Accepted 00ce37c3 Diff 317/1 GPU 0 pool 4 
 [2012-11-19 10:39:16] Accepted b9c90f24 Diff 1/1 GPU 1 pool 1 
 [2012-11-19 10:40:29] Accepted 95753f80 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:40:34] Accepted 6239214f Diff 2/1 GPU 1 pool 4 
 [2012-11-19 10:40:37] Accepted f5648f73 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:40:38] Accepted 2b2d9fc4 Diff 5/1 GPU 1 pool 4 
 [2012-11-19 10:41:38] Accepted cdfe2d9c Diff 1/1 GPU 1 pool 1 
 [2012-11-19 10:41:40] Accepted 15ceb2b8 Diff 11/1 GPU 1 pool 4 
 [2012-11-19 10:42:35] Accepted 0de06499 Diff 18/1 GPU 0 pool 1 
 [2012-11-19 10:42:41] Accepted 59500529 Diff 2/1 GPU 0 pool 1 
 [2012-11-19 10:42:47] Accepted a0dc87de Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:42:49] Accepted 978a2ccf Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:43:38] Accepted 6be7ba5e Diff 2/1 GPU 1 pool 4 
 [2012-11-19 10:43:42] Accepted 3c094d76 Diff 4/1 GPU 1 pool 4 
 [2012-11-19 10:44:42] Accepted 91337feb Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:44:46] Accepted e2bd8f63 Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:45:44] Accepted 3b42ce4c Diff 4/1 GPU 1 pool 2 
 [2012-11-19 10:45:49] Accepted d8b08491 Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:45:49] Accepted 98727667 Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:45:51] Accepted 032377c7 Diff 81/1 GPU 0 pool 1 
 [2012-11-19 10:46:49] Accepted 7cf04e4f Diff 2/1 GPU 1 pool 4 
 [2012-11-19 10:46:49] Accepted 0bc6194e Diff 21/1 GPU 1 pool 4 
 [2012-11-19 10:46:52] Accepted 366d07fe Diff 4/1 GPU 1 pool 2 
 [2012-11-19 10:46:56] Accepted 5da0bb66 Diff 2/1 GPU 1 pool 4 
 [2012-11-19 10:46:58] Accepted 85677bfa Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:47:59] Accepted d6938f60 Diff 1/1 GPU 1 pool 1 
 [2012-11-19 10:48:02] Accepted c58fa884 Diff 1/1 GPU 1 pool 1 
 [2012-11-19 10:48:03] Accepted b74432dc Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:48:05] Accepted 24be1fee Diff 6/1 GPU 1 pool 2 
 [2012-11-19 10:48:06] Accepted 70910858 Diff 2/1 GPU 1 pool 2 
 [2012-11-19 10:48:07] Accepted 23e7534b Diff 7/1 GPU 1 pool 2 
 [2012-11-19 10:48:09] Accepted a2c36b72 Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:49:12] Accepted 502d43d2 Diff 3/1 GPU 1 pool 2 
 [2012-11-19 10:49:20] Accepted a41b80f2 Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:50:16] Accepted 9482541a Diff 1/1 GPU 0 pool 4 
 [2012-11-19 10:50:18] Accepted 1b69cc8d Diff 9/1 GPU 0 pool 4 
 [2012-11-19 10:51:48] Accepted cdcdded5 Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:52:41] Accepted 559e8003 Diff 2/1 GPU 1 pool 1 
 [2012-11-19 10:52:48] Accepted 8f5d78a7 Diff 1/1 GPU 1 pool 1 
 [2012-11-19 10:52:51] Accepted 205b2509 Diff 7/1 GPU 1 pool 1 
 [2012-11-19 10:52:51] Accepted 76581889 Diff 2/1 GPU 1 pool 1 
 [2012-11-19 10:52:54] Accepted ebe6da75 Diff 1/1 GPU 0 pool 4 
 [2012-11-19 10:53:01] Accepted bc9fd7d0 Diff 1/1 GPU 0 pool 4 
 [2012-11-19 10:53:54] Accepted 7ce2b8b3 Diff 2/1 GPU 1 pool 2 
 [2012-11-19 10:53:55] Accepted a2b7a2db Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:55:59] Accepted 9d0da0ad Diff 1/1 GPU 0 pool 1 
 [2012-11-19 10:55:59] Accepted 0972d111 Diff 27/1 GPU 0 pool 1 
 [2012-11-19 10:56:04] Accepted d4f173f9 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:56:04] Accepted d4e587d2 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:57:05] Accepted 5d619343 Diff 2/1 GPU 0 pool 1 
 [2012-11-19 10:57:20] Accepted 5a9e7aad Diff 2/1 GPU 1 pool 2 
 [2012-11-19 10:57:22] Accepted c51ea99d Diff 1/1 GPU 1 pool 2 
 [2012-11-19 10:58:42] Accepted 9ce257d0 Diff 1/1 GPU 1 pool 4 
 [2012-11-19 10:59:07] Accepted 000c5b3d Diff 5.3K/999 GPU 1 pool 0
...

Since I'm coming from pool 4, let's discard the first shares still going to pool 4 (till 10:36:54): that's normal.
In minute 10:37 there are no shares found, which is normal too (difficulty 999). Then I start to find and submit shares also for other pools. This isn't normal, IMHO, and surely it has never happened before 2.9.x. Of course, when a new block is found, very few shares always go to different pools: but now a lot of shares  (1 - 5 per minute, so up to 25% of my mining power) sistematically go to other pools, which I don't like: they're prop pools running long rounds, or simply backup PPS pools with higher fees (or lower efficiency) that should come in play only when my primary backup pool (pool 0) isn't available.

Am I missing something? Is this behaviour intentional? Why?

Thanks.

[kano]

For whatever reason they are leaking to backup pools, --failover-only (or java API 'failover-only|true') will stop them from leaking at all.

[mdude77]

For whatever reason they are leaking to backup pools, --failover-only (or java API 'failover-only|true') will stop them from leaking at all.

I also noticed a lot more "leaking" to backup pools with 2.9.4.  However it only seems to happen when I'm using a LP pool, which apparently isn't providing work fast enough to keep cgminer happy.  That's fine with me, BTW, just pointing it out.

M

[-ck]

For whatever reason they are leaking to backup pools, --failover-only (or java API 'failover-only|true') will stop them from leaking at all.

I also noticed a lot more "leaking" to backup pools with 2.9.4.  However it only seems to happen when I'm using a LP pool, which apparently isn't providing work fast enough to keep cgminer happy.  That's fine with me, BTW, just pointing it out.

It's part of my secret plan to make everyone move to stratum.

[Lem]

Thank you, Kano and mdude77.

I know that failover-only would stop the leaking, however I've always used failover to get the highest efficiency, moreover when a new block is found and some pools are quicker than others.

The strange thing is that if I use failover-only, my Mh/s stay pretty the same in the middle of a block.

So even if cgminer thinks the primary pool is lagging (and so, with failover policy, it begins to collect a lot of work from elsewhere), this doesn't look to be true. If this were true, I think that with failover-only I should see my GPUs slow down from time to time, left with not enough work from my primary pool: but this doesn't happen.

[Lem]

It's part of my secret plan to make everyone move to stratum.

Ah, LOL, nice to know it.

[derjanb]

New version - 2.9.4, 19th November 2012

First, thanks for your hard work!

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:

Code:

Reading symbols from /home/user/hdd/bitcoin/cgminer-2.9.4-x86_64-built/cgminer...(no debugging symbols found)...done.
[New LWP 2833]
[New LWP 2797]
[New LWP 2800]
[New LWP 2795]
[New LWP 2822]
[New LWP 2791]
[New LWP 2799]
[New LWP 2789]
[New LWP 2790]
[New LWP 2798]
[New LWP 2796]
[New LWP 2804]
[New LWP 2793]
[New LWP 2802]
[New LWP 2792]
[New LWP 2803]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgminer -c ../cgminer.conf --gpu-engine 500-600 --temp-cutoff 85 --gpu-fan 45'.
Program terminated with signal 6, Aborted.
#0  0x00007f676e2d5425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f676e2d5425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f676e2d8b8b in __GI_abort () at abort.c:91
#2  0x00007f676e31339e in __libc_message (do_abort=2, fmt=0x7f676e41ae3f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007f676e3a9807 in __GI___fortify_fail (msg=0x7f676e41add6 "buffer overflow detected") at fortify_fail.c:32
#4  0x00007f676e3a8700 in __GI___chk_fail () at chk_fail.c:29
#5  0x00007f676e3a7b69 in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at vsprintf_chk.c:35
#6  0x00007f676e31b13d in _IO_default_xsputn (f=0x7f673affcba0, data=<optimized out>, n=2768) at genops.c:485
#7  0x00007f676e2e9f82 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1630
#8  0x00007f676e3a7c04 in ___vsprintf_chk (s=0x7f6720000b69 "0100000001", '0' <repeats 64 times>, "ffffffff4b03d52e030e00456c69676975730050aa0c473bfabe6d6dc7beb9a76e1f9fdf1bb3a777e1081161726d0f9318cf2a1237994e7c426d74a2080000"..., flags=1, 
    slen=512, format=0x448ff2 "%s", args=0x7f673affccc8) at vsprintf_chk.c:86
#9  0x00007f676e3a7b4d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:33
#10 0x000000000040fc75 in ?? ()
#11 0x0000000000414e0b in ?? ()
#12 0x00007f676f3cbe9a in start_thread (arg=0x7f673affd700) at pthread_create.c:308
#13 0x00007f676e392cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x0000000000000000 in ?? ()

Code:

./cgminer --ndevs
 [2012-11-19 12:02:57] CL Platform 0 vendor: Advanced Micro Devices, Inc.                    
 [2012-11-19 12:02:57] CL Platform 0 name: AMD Accelerated Parallel Processing                    
 [2012-11-19 12:02:57] CL Platform 0 version: OpenCL 1.2 AMD-APP (1016.4)                    
 [2012-11-19 12:02:57] Platform 0 devices: 1                    
 [2012-11-19 12:02:57]  0       Cypress                    
 [2012-11-19 12:02:57] GPU 0 ATI Radeon HD 5800 Series   hardware monitoring enabled                    
 [2012-11-19 12:02:57] 1 GPU devices max detected  

Just tell me if you need more info.

[-ck]

Thanks. Core dump or debugging output is not much help without debugging symbols. Either build with the debug symbols (add -g) or grab a debug build from
http://ck.kolivas.org/apps/cgminer/debug/

[-ck]

Thank you, Kano and mdude77.

I know that failover-only would stop the leaking, however I've always used failover to get the highest efficiency, moreover when a new block is found and some pools are quicker than others.

The strange thing is that if I use failover-only, my Mh/s stay pretty the same in the middle of a block.

So even if cgminer thinks the primary pool is lagging (and so, with failover policy, it begins to collect a lot of work from elsewhere), this doesn't look to be true. If this were true, I think that with failover-only I should see my GPUs slow down from time to time, left with not enough work from my primary pool: but this doesn't happen.

It's not an exact science, and kicks in when it's below a threshold rather than waiting for it to fall to "not enough". It's an algorithm, and like all of them, it is prone to not being perfect. Local work generation via something like stratum makes this feature pretty much unnecessary.

[Lem]

It's not an exact science, and kicks in when it's below a threshold rather than waiting for it to fall to "not enough". It's an algorithm, and like all of them, it is prone to not being perfect.

I understand. I just say that this algorithm worked better (for me, eh) in previous version, before 2.9.x.

BTW: is there a way for me to modify this threshold, maybe working on some cgminer parameters (queue, scantime, expiry...)?

Local work generation via something like stratum makes this feature pretty much unnecessary.

Were it to me, stratum would become the default... yesterday.
But I think many little pools, and expecially the last "starving" prop pools - that are still there, though - won't rush to implement it. It's a pity.

[derjanb]

Thanks. Core dump or debugging output is not much help without debugging symbols. Either build with the debug symbols (add -g) or grab a debug build from
http://ck.kolivas.org/apps/cgminer/debug/

Done.

Code:

Reading symbols from /home/user/hdd/bitcoin/cgminer-2.9.4-x86_64-built/cgminer...done.
[New LWP 27740]
[New LWP 23114]
[New LWP 23132]
[New LWP 23099]
[New LWP 22458]
[New LWP 23138]
[New LWP 22756]
[New LWP 23135]
[New LWP 24650]
[New LWP 23134]
[New LWP 23133]
[New LWP 23113]
[New LWP 27743]
[New LWP 22757]
[New LWP 25467]
[New LWP 23100]
[New LWP 26811]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgminer -c ../cgminer.conf --gpu-engine 500-600 --temp-cutoff 85 --gpu-fan 45'.
Program terminated with signal 6, Aborted.
#0  0x00007fa5177ac425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fa5177ac425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fa5177afb8b in __GI_abort () at abort.c:91
#2  0x00007fa5177ea39e in __libc_message (do_abort=2, fmt=0x7fa5178f1e3f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007fa517880807 in __GI___fortify_fail (msg=0x7fa5178f1dd6 "buffer overflow detected") at fortify_fail.c:32
#4  0x00007fa51787f700 in __GI___chk_fail () at chk_fail.c:29
#5  0x00007fa51787eb69 in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at vsprintf_chk.c:35
#6  0x00007fa5177f213d in _IO_default_xsputn (f=0x7fa4f4ff8ba0, data=<optimized out>, n=2906) at genops.c:485
#7  0x00007fa5177c0f82 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1630
#8  0x00007fa51787ec04 in ___vsprintf_chk (s=0x7fa4cc0020e9 "0100000001", '0' <repeats 64 times>, "ffffffff4c03d92e030f00456c69676975730050aa1ca20488fabe6d6d5ac523f49912c85158966f09972f3689830ac7371984a4d0e71335bb878f56b90800"..., flags=1, 
    slen=512, format=0x448ff2 "%s", args=0x7fa4f4ff8cc8) at vsprintf_chk.c:86
#9  0x00007fa51787eb4d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:33
#10 0x000000000040fc75 in sprintf (__fmt=0x448ff2 "%s", __s=0x7fa4cc0020e9 "0100000001", '0' <repeats 64 times>, "ffffffff4c03d92e030f00456c69676975730050aa1ca20488fabe6d6d5ac523f49912c85158966f09972f3689830ac7371984a4d0e71335bb878f56b90800"...)
    at /usr/include/x86_64-linux-gnu/bits/stdio2.h:34
#11 gen_gbt_work (pool=0x10ec310, work=0x7fa4cc001e40) at cgminer.c:1487
#12 0x0000000000414e0b in get_work_thread (userdata=0x7fa50000a770) at cgminer.c:3066
#13 0x00007fa5188a2e9a in start_thread (arg=0x7fa4f4ff9700) at pthread_create.c:308
#14 0x00007fa517869cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()

[gyverlb]

First, thanks for your hard work!

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:

May be the same problem than the one I reported on IRC (and started for me at 8AM GMT today), if it is, adding --fix-protocol should be a temporary fix (it disables the switch to GBT protocol).

[Subo1977]

The 2.9.3 runs the last day's without problems.

since this morning i have a problem with cgminer 2.9.3 and 2.9.4 on Windows and Linux.

on these pool's its ok. : eclipsemc, and Eligius.
after switching  or starting to p2pool the cgminer crashs after a few seconds.

after reverting to 2.8.7 already is ok.

[derjanb]

First, thanks for your hard work!

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:

May be the same problem than the one I reported on IRC (and started for me at 8AM GMT today), if it is, adding --fix-protocol should be a temporary fix (it disables the switch to GBT protocol).

You're right "--fix-protocol" fixes cgminer too. Funny thing, cause 2.9.3 was working fine the last 3 days.

[gyverlb]

You're right "--fix-protocol" fixes cgminer too. Funny thing, cause 2.9.3 was working fine the last 3 days.

I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.