Both Bittrex and Bitfenix have been "hacked" - more than likely inside jobs.

Also Bittrex will holds your funds.
They held over 5k of bitcoin from me for accidentally sending to a bitcoin cash wallet on their exchange.
Refusing to help!   Thieves.

I'd recommend against updating S9v1 units to the autofrequency firmware as it seems to increase hardware failure.
Even Bitmain now states the following:

* Attention: do not use this fw on old S9 miners with fixed frequency.

and have put up older fixed frequency firmware - which I'm pretty sure is still v1 on the bmminer.

Yes but V2 firmware comes with it's own set of problems - at least in my experience and from what I've read with some others.

I've got 22 x s9's.  I had zero issues with any up until first batch about 4 months into mining one board started producing xxxx's
Not a huge issue as scripts I've written would just reboot when this occurred and it would be good for random 15min - 15hours.
I had a couple others at same time start acting up in other units, but a downclock to 525 kept them solid.

I decided to try the autotune on a couple units.  This one with the intermittent hashboard was one of two I tested.
It seemed to fix it.  Or at least it showed as hashing away correctly as did the other unit.  Other unit I updated was one that had to run 525.
Well autotune did help on this one and propped it up close to full hashrate without chips dropping.  So thinking all was well I started to update more.

That's when i started getting a headache of issues.  I updated 6 more units and seemed all good until about 24-48 hours into mining I had 4 units just stop hashing.
I could reach them via IP but they simply stopped hashing.  I'd reboot them wait 40+ minutes and they'd eventually come back to the GUI and just sit there - not hashing.
I reflashed old firmware on these 4 - same result just didn't take as long before going back to GUI with no mining.  Somehow the firmware was locking up in the PIC phase cycle and would just hang.
I then did remote reflash of firmware and still nothing.  I ended up having to travel to the remote site and pull the 4 units.  A hardware firmware reset on 2 of the controllers brought 2 of them back to life.
The other 2 would not recognize any blades until I removed everything from the chassis and re-seated everything and flashed them multiple times with the older firmware and I eventually got them to come back.
As soon as I left - 12 hours later one dropped again.  This time was not able to resurrect it - and deduced the controller has gone bunk.  So I've taken the three hash boards and piggy backed them into 3 working units for now until I can get a replacement control board.  Since then I also learned that while the one unit with intermittent hashboard wasn't really hashing away at full speed.  Pool side indicated that the board would drop, but gui hashrate never would fully reflect it.  So I've since reflashed that back to old firmware so that my script could see the dropped board and powercycle as needed to get the most out of it.

As for other bitmain products - I had 4 boards go bad with 50+ s7's, and the early firmware releases were not good as major lockups would occur requiring power cycle and some dropped chips on the boards needing reboots.  With the latest firmware though all the S7's I have almost never need a physical reboot nor drop chips.  S4's I had never had anything but reboots needed - and fan replacements, they seemed to burn through the fans.  S3 +'s nothing more than a random reboot from time to time.

Overall I think I would have been better off leaving most of the s9's on firmware v1.
Not sure if it makes a load of difference, but I have 3 or 4 different version of controller boards in these things.
Perhaps some boards do better with the v2 firmware and others don't.  Not really certain.

I just tried it for S&L's - it did increase my fan speeds, but it also reset the CGI page back to nodisplay.

I haven't actually tried it for the fan setting specifically.  I've done this to open up the ability to turn off the beep and that's worked fine.
I have my rigs pulling in the cold winter air so even with the updated auto tune they rarely exceed 80c on the temp chip2 readings.

but if you want to make the change - you'd just ssh into the rig.

cd /www/pages/cgi-bin
vi minerConfiguration.cgi

find:
 <div class="cbi-value" id="fan_ctrl" style="display:none">

change to
<div class="cbi-value" id="fan_ctrl">

directly above about 14 lines (right above "<legend>Pool 2</legend>")  you will also need to change:

<fieldset class="cbi-section" id="cbi-bmminer-default" style="display:none">

to

<fieldset class="cbi-section" id="cbi-bmminer-default">

:w
:q

reload page.

Why not just hack the cgi and unlock your fan setting?

Well you are port forwarding directly to the miner on port:80, and you left default user/pass as root?
It's like an open invitation for a hack.  Good thing you noticed quickly.
If you are going to open ports on your network you'll want to set up a specific VNC over SSH using a locked box.
Most people find it just easier to use a third party client like teamviewer or hamachi - but still you'll be going to a designated box that from there can use browser to control miners.

I concur with this assessment (for the most part).
I had a batch 16 board failure within 48 hours.  Measures 9.16V - doesn't work at all - reads 30 chips.
I have another board that was an RMA replacement from batch 9 that partially works (actually seems to work best when around 69-72c) reads 10.12 at start and 10.26 at load.
Normal-fully functional board measures 10.56 at start and up to 10.69 at load.

Ordered some trimmers today, looking forward to resurrecting boards - unless bitmain RMA gets back to me first.
So on the partial working unit will i need to remove the U2 chip?

Holy Hump DAY - Block Boys!



Party on Dudes!

I've got 7 - A2's.  Had a couple from when they first shipped and got 4 more when pricing on scrypt devices was at bottom.
Almost all of them have required some maintenance, but I've only had 1 hashboard fail completely.  I think it burned from heat overload as there was a fan that died on it and the hashboard was relatively loose from the chassis - so little heat was being exchanged to the chassis.  I've done a fair amount of tweaking/soldering/ etc to keep these operational.  One HUGE point of weakness is the soldering points of the PCI power connectors to the board.  I'd say 1 out of 4 have lost full conductivity - mostly at the soldering joint of pin to the board, poor conductivity of power leads to intermittent drops of the board.

Since you swapped out your PSU, that means you've had to disconnect and reconnect these - and good chance that one or two may have integrity loss of connection.

Sometimes boards can benefit from removal and reinsertion of the data cables as well.  Which is another weak point on these boards.  I've literally pulled some of the L shaped pins out of the soldering points on the board, or broken pins off.  Be extremely careful when removing the cables - again if you have a pin that has a poor connection it may result in hashboard just blinking and never synchronizing - much the same as a bad power connection.  

If the problem is either the PCI connection pins or the data cable connection pins - it can be fixed.  I've actually had a unit fall 4 feet from a shelf and broke off 2 of the PCI pin connectors from the board, breaking the PCI board in the corner.  There is an additional 6 pin power connection on the board as well - underneath the 8 pin.  I've used this second set of connections on the board and soldered some 6 pin connections to them and got the boards working.  With the boards that have had broken pins on the data cable, I either resoldered those pins back to the board or stripped the 10 pin data cables and soldered the wires directly to the board.  In all cases the boards have worked again.  Only the one instance of the suspected burnt chip on one board have I not been able to resurrect.

A good way to start troubleshooting is disconnect all datacables (I suggest at the controller board instead of each individual hashboard - to avoid pin stress on the hashboard).  Leave the one board you want to troubleshoot plugged in - disconnect all power to hashboards except to that single board as well.  This reduces the chance that another board is interfering with the function of the one being tested.  In some cases one failed power connection could result in all the connected boards to fail synchronization.

You could also remove the heatsink and look visually at the chips to see if any appear burned.  

Holy Crap...  I'm really starting to think about trying CK-Solo.
4 blocks in under 4 weeks.  Would have quadrupled my payouts with those results.
Well, glad to see all the green blocks racking up.

Yes - 3rd block in just over 3 weeks.
And this is a fat one indeed.

I believe that puts me in the low CDF category no?
I somehow really doubt it's going to stand as low CDF for the month though.

55 pennies is large fee to send $4,400 ?
Last week I spent $46.00 to wire $1,700 at the bank.
Sticking to .0001 per kb should still assure relatively fast acceptance.

You better just crank up the AC/DC and give that fertility goddess a rubdown.

Damn, didn't notice until now.  I hit that Juvia.  Two blocks in a week. Would have been a great solo week.

Showed up on miner GUI this time. Nice best difficulty 
https://i.imgur.com/azg39Fy.png

Well there you have it.  Thanks for the insight, and I'm glad we won the orphan race.

true dat.

Strange GUI is reporting no block found (wanted to capture the moment)-

Look here- CPWW9
https://i.imgur.com/oDTPDXG.png


But CPWW16 is the only miner at that location showing a block find-
https://i.imgur.com/oSagsAR.png

Is it unusual that the reported worker is inaccurate?
website says cryptichermit.cpww9 found the block, but it was actually cpww16?

Yes, I refer to that as the "Weighted Dice".