Bitmaxz, I will do this when I get home then. Thanks for looking at this. The internet connection is pretty good. It's usually around 6Mb down 300+ Kb up - but sometimes it's a little laggy. It's actually cell based internet service through AT&T. No DSL or other option here for us. However, I have 12 other miners besides these 3 (8 S9 variants and 4 L3 variants) and they are all connecting and mining fine (And have been for months).
The 015 unit has only shown 2 boards a couple of times - but the second board would drop quickly. It has never shown 3 boards yet.
The PICKit3 is interesting - I looked at the links you gave on that. I did not understand what these PICs were - so now I have a better understanding. I may go ahead and get one of those PICKit3 units - but won't use it on these 3 miners. If I don't find a firmware or other fix I will send them back. The seller does not want me to open them if I'm going to return them and they still have their warranty stickers on them. So no opening them up.
I bet that PICKit3 setup along with copying the PIC file/data from a working hash board to one with missing PIC or corrupted PIC could solve a lot of problems on here.
@Bitmaxz, I tried to follow your directions - but quickly ran in to a problem on all 3 of these units - I could not flash the s9_fix_upgrade.tar.gz as I kept getting the "413 - Request Entity Too Large" error! At one point I did notice something odd too. I am using Windows 10 Pro - but when I would download that file from Bitmain - it would tell me the name of the file being downloaded was s9_fix_upgrade.tar.
tar - but then when I would view the file in the folder I saved it in, it would be just s9_fix_upgrade.tar. (no .gz, or extra .tar) I have my system set to show all file extensions too - that was not the issue. Anyway, I tried it with the way it saved it, I also renamed it and added the .gz extension as well - but no go either way. ONE time 013 took it with the .gz extension added and didn't give the 413 error - but then it wouldn't take the Antminer-S9-all-201711171757-autofreq-user-Update2UBI-NF.tar.gz flash. It was back to the same 413 error. I even tried older fixed freq firmwares, S9i and S9j firmwares - I just kept getting the 413 errors (after re-boots and power cycles too). I hunted around for a workaround to that and found that @Tim-bc had said that about the only way to force the miners to take the firmware when this error was coming up was to use a MicroSD card and to change jumper positions on the controller to write the firmware from the SD card. Long story short - I got more very weird status from these miners - 015 even showing that one chain had 150 ASIC chips on it at one point - and I just decided to cut my losses on this and am returning them to the seller.
The jumper was accessible by pulling the controller toward the hash boards - without having to open the unit up with - and then using curved forceps to reach and move the jumper - but I didn't find what file(s) needed to be put on the SD card - the .gz file, or then extracted contents, or other? I was becoming leary of having to use this approach in case anything went wrong - I didn't want to give the seller reason to not take the units back AND - it was after 1:30AM this morning at this point - so that's that. I'm done with these.
I appreciate your time reviewing the kernel logs. I did record a few more kernel logs during all this as well - including the one with the 150 ASICs on one hash board - if you would be interested in looking at that for the fun of it. If so, let me know and I'll post that on the pastebin.com site as well. Thanks!