[GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning

[MatthewBCF]

Sandor111, I've been using the latest (0.9a) on/off for ~4 days and my blades are always freezing, esp when getting a new block or after I see "dispatching new work.." - One might conclude it is any message except "accepted" which has a chance of causing the freeze.

I figure examples worth 1000 words too.  Notice the timestamps from the top 3 accepted and then it just drops into new block but no work, waiting changes nothing.

 [2014-05-06 05:17:36] Accepted 8ccd7d9d GSD 0@22
 [2014-05-06 05:17:47] Accepted 26722406 GSD 0@6
 [2014-05-06 05:17:48] Accepted 1340d68a GSD 0@3
 [2014-05-06 05:18:05] Stratum difficulty changed
 [2014-05-06 05:18:05] Dispatching new work to GC3355 threads
 [2014-05-06 05:18:05] New job_id: 5b2d Diff: 263
 [2014-05-06 05:18:05] Accepted 5352d64d GSD 0@13
 [2014-05-06 05:18:10] New job_id: 5b64 Diff: 263
 [2014-05-06 05:18:10] Stratum detected new block
 [2014-05-06 05:18:50] New job_id: 5c39 Diff: 263
 [2014-05-06 05:18:50] Stratum detected new block
 [2014-05-06 05:18:56] New job_id: 5c96 Diff: 263
 [2014-05-06 05:18:56] Stratum detected new block
 [2014-05-06 05:19:03] New job_id: 5cf6 Diff: 263
 [2014-05-06 05:19:03] Stratum detected new block

[fivejonnyfive]

Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?

thx

Sure, look in my signature for examples on that.

Just curious, On a Raspberry Pi do the device names stay constant across reboots? I think I was accidentally sold a voltmodded gridseed (which I'd be pretty stoked about) but the fast one last time I booted doesn't seem to be the fast one this time I booted.

[MatthewBCF]

Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?

thx

Sure, look in my signature for examples on that.

Just curious, On a Raspberry Pi do the device names stay constant across reboots? I think I was accidentally sold a voltmodded gridseed (which I'd be pretty stoked about) but the fast one last time I booted doesn't seem to be the fast one this time I booted.

For me the devices stay the same ..as long as usb cables aren't moved (duh?).  I've given up trying to expect consistency until they are hashing for awhile..then it settles in.  I've seen sometimes 250% of expected rate at the start, but it will settle down.

[kenshirothefist]

I'd like to contact David Bartley (dtbartle), the author of CGMiner 3.7.2 with GridSeed GC3355 support (https://github.com/dtbartle/cgminer-gc3355). Does anybody know if he is a member of this (or any other) forum? I would like to ask him if he could include some additional patches.

[PVmining]

* Add --gc3355-timeout=N option: restart GC3355 chips when no share is submitted and timeout expires. N = value in seconds.

does it restart a single chip, or the complete GS?

I had some problems to get cpuminer 9.d working with higher diff rates (512) - a few versions ago wafflepool & clevermining for example worked.
Now it seems as some single chips don't start working att all. I use 5 chip GS with fixed frequency for every single chip.

[surgexvb]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Same issue here still.too on Raspberrypi.  I get a LOT of rejects, sometimes my pool shows.only 75% efficiency.  I've tried different pools.with the same result.  Tried with auto tune on and off, same result.  Using version 0.9e.  C worked the best so far.  5 chip miners, 21 per RasPi.

[plzt]

I have to say I've had little but trouble since switching off the last non-versioned minerd I got on the 28th April
It seems to be the issue that everyone else has - eventually work just stops being submitted. Still appears to be working, still have a full set of stats coming but the pool is reporting nothing its end!

I'm giving 0.9e a try now and will see how long it can run for

[RowanX]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

[sandor111]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Add --log

[sandor111]

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

Sandor111, I've been using the latest (0.9a) on/off for ~4 days and my blades are always freezing, esp when getting a new block or after I see "dispatching new work.." - One might conclude it is any message except "accepted" which has a chance of causing the freeze.

I can't say I've tried everything, but I am pretty sure it isn't the cards as this is an issue occurring in cpuminer, not cgminer.

Overall I think it is a fantastic step fwd, seems stable.  I know you are going to add the single step freq soon too, so that will be a big plus.

Otherwise, any ideas on why the blade freezes, particularly when the difficulty jumps and/or new block or dispatching work ..I wish I could be more precise but it is definitely when something besides hashing happens.

I have a pile of 5chips that run on the same raspi with no issue too.

Thanks

The latest is 0.9e, in which Blade stability issues is fixed.

[jamieb81]

Hi sandor,

I don't know if anyone else has this issue but on this version, when checked the miners this morning

they were like super super hot! something that never happened before at same frequency settings

[sandor111]

Hi sandor,

I don't know if anyone else has this issue but on this version, when checked the miners this morning

they were like super super hot! something that never happened before at same frequency settings

I just checked the power meter, and it is still at ~7W/unit, cool to the touch. Probably the effect of overvolting?

[reactor]

0.9e ran just fine overnight.  Notice that the 5-chips are quirkier than the blades in terms of performance, but it could also be that I'm on a pool with a fixed [higher] difficulty.  Otherwise performance is consistent across all devices and hashrate has been the highest sustained ever on these things. 

Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.

[5ick3uffalo]

Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?

thx

Sure, look in my signature for examples on that.

Just curious, On a Raspberry Pi do the device names stay constant across reboots? 

They stay constant.

[reactor]

Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?

thx

Sure, look in my signature for examples on that.

Just curious, On a Raspberry Pi do the device names stay constant across reboots?  

They stay constant.

You don't say... I was curious about this but haven't paid enough attention across reboots and reconfigs.  Knowing this I may have to move the 5-chips to a multicoin pool or something for better diff.

[RowanX]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Add --log

Here is an hours worth of log:
http://pastebin.com/BghRt9LX

FWIW this was my bat file (running 2 Gridseeds):

minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

pause

[sandor111]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Add --log

Here is an hours worth of log:
http://pastebin.com/BghRt9LX

FWIW this was my bat file (running 2 Gridseeds):

minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

pause

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

[RowanX]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Add --log

Here is an hours worth of log:
http://pastebin.com/BghRt9LX

FWIW this was my bat file (running 2 Gridseeds):

minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

pause

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

When I run with 0.9c I do get "Stratum detected new block" messages in the log, if that is what you mean (same pool).

[sandor111]

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?

Personally I'm still getting 0.2% rejects whatever the pool I go with.

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Add --log

Here is an hours worth of log:
http://pastebin.com/BghRt9LX

FWIW this was my bat file (running 2 Gridseeds):

minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

pause

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

When I run with 0.9c I do get "Stratum detected new block" messages in the log, if that is what you mean (same pool).

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78

[kha0S]

That's quite a statement. Pool runs fine for everyone else and the conclusion is that we don't report new blocks on the network...  

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

When I run with 0.9c I do get "Stratum detected new block" messages in the log, if that is what you mean (same pool).

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78