just recently did what i call a -next compile, from git source HEAD.
the TLS support would NOT allow connecting to stratum.btcguild.com:3333
performed
git revert 6520d158eba3bcff1b6e0343951ff38437ffea80 -m 1
to revert the merge
then rebuilt. This allowed connection to the pool and hashing commenced.
Did you wait a bit? BTCGuild is just hanging on TLS attempts, so there's a 30 second timeout when initially connecting and then later following the redirect.
Eleuthria apparently does not plan to fix this, and I'm not sure whether it's worth removing (or requiring explicit enabling of) TLS just to workaround it.
however, i noticed: out of the 64 chips total, 64 were recognized however only 60 were hashing/returning nonces.
to rule out hardware state, i power cycled and tried again. same thing.
to see if the Gen 2 detection was the culprit or something in between i did the following.
git clone https://github.com/luke-jr/bfgminer bfgminer-nxt-2 && cd bfgminer-nxt-2
git checkout a355ac63b5671abd7a373151b683cd4e6be9ae2d //known solid, been running for months
git cherry-pick 9d647767620ef121452db7f1ebf1d6be524ea4d8 //added Rev.2 detection/
git cherry-pick 61a2b9aacb4ff779d8c5cd29c9eab3e346aeb8be //fixed hashrate reporting for Rev.2 chips
./autogen.sh
CFLAGS="-O2" ./configure --without-libusb --without-hidapi
make -j2
sudo ./bfgminer -o stratum.btcguild.com:3333 -O user:pass --set BFY:osc6_bits=55 --set BFY:baud=500000
this resulted in a version of my previous stable build with the addition of the Rev.2 detection and reporting. Lo and behold the same 4 chips that were not returning results before, were NOT returning results with this modified version of my stable.
Can you get me a debuglog with --device-protocol-dump of this?
Bonus: whats special about the new values in bitfury_init_chip payload? do they produce a hit on one of the additional cores in rev.2 chips?
The new payload has 8 nonces in it, a few of which are never found by gen1 chips.
ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56.
FWIW, I found the bug causing this.
while (bitfury->osc6_bits < 50)
On the first iteration, bitfury points to data
beyond the array.