I left 2.1 running on both cards overnight. Today, one card is showing only the hardware problem error occasionally, no increase in rejects. Here is ~5hr log of it to get an idea of how often it pops up,
http://pastebin.com/raw.php?i=qQedNWRG. I immediately restarted that miner using 2.1 and got the first hardware problem after 4mins of mining. Next I switched back to diapolo 7-11. Ran it for 15 mins without a single hardware error. Okay once more back to 2.1, again another hardware problem after only 2 mins this time. So I can turn the problem on and off by switching versions. This whole time my other card has been running 2.1 since last night without a single problem. I'm not too concerned about the hardware problem error. But the first night I tried out 2.1 I was getting a large amount of rejects also.
EDIT: Backed off clock 10mHz like CanaryInTheMine said in his earlier post to 990 for 10 mins and no problem showed up. Put back to 1000 and one popped up after ~30secs. Running the newer version at the slower speed doesn't net me any gain in mhash.
Again, the hardware problem doesn't concern me much. It's just the sudden amounts of rejects I was getting after I first switched to 2.1
Well the hardware error indicates not necessarily a 'hardware error', but a bad hash was detected outside the running OpenCL kernel by the first validity check:
In __init.py__:
if not hash.endswith('\x00\x00\x00\x00'):
self.interface.error('Unusual behavior from OpenCL. '
'Hardware problem?')
So to get this error, either the SHA hashing math or the hash checking in OpenCL was corrupted, and an invalid hash was returned as a valid share. If this happens, then it is also possible that a hash that would be a valid solution could be corrupted and not returned or sent.
Diapolo's 7-17 kernel is also more sensitive to overclock than previous ones, and will start returning the 'hardware error' at overclocks where 7-11 doesn't. Either a different stream core instruction on the die is being used that doesn't overclock well, or the higher utilization causes some failure. My way of thinking is you don't want to overclock to the point where any bad math is happening in any stream processors. If you have to overclock 5% less on a kernel that is 1% more efficient, then you lose any gains.