Well, glad it works for starters. At least we know it managed to get up to higher diff which was half the problem to begin with. I doubt that getting it to diff 2k would help any further. So if it hashes lower than that then there's still some remaining issue, and likely it's the choice of a halfway diff.
Halfway Diff?
Checkn2diff is a hack used by the slow bitmain products to round off diff to the nearest power of 2 since they're so slow at confirming hashes. There's a chance it may not be needed with the hack I added to the driver, so try removing that command line option. As for suggest_diff, only ckpools have that implemented at the pool end anyway so I didn't bother adding it to the driver (though it's easy enough for me to do). So try without checkn2diff next.
Ok I removed the chicken diff option, but no change, really. I couldn't keep staring at half my hashrate being lost in slush's pool anymore so I pointed the S4 at ckpool (user gigawatt) and set the difficulty to 2250 (since its overclocked). Finally, a pool that recognizes my hashrate!
I wonder how thw payout will compare to Slush's pool... Assuming of course that ckppool ever solves a block lol -- it's like solo mining with a few friends!
{sigh} i'm gonna go nag Slush to re-enable user diff, now.
Halfway diff is what checkn2diff does. Because of lousy hardware support for diff, they just round down the diff to the nearest power of 2 or something like that. It wasn't that anyway.
Well I guess that means there's still something else wrong as well in that case. Maybe it's my secret plan to get everyone onto a ckpool pool.
EDIT: Further investigation shows a flood of:
[2014-10-10 07:22:22] BitMain: Nonce not find work(7010)
type errors, suggesting there are more reasons for the driver falling behind while the diff is low. There's something else broken here, and it's hard to know if the overall design is broken or it's something minor,