Unfortunately, this does not come from the repair shop, the 17 series is so bad, that even once repaired, it can work for 6 months, like breaking down again after 5 minutes ...
I know what I'm talking about, I repair mine, and I have the same problem!
just serie 17 .... go trash
Topic: T17 random hashplates dropping off (Read 173 times)
It's been a while... I have an update, but not a resolution.
So I finally took ASIC to maintenance.. after few hours of diagnostic - the resolution was 18 burn chips in total on 2 plates.
Well.. it is was it is, got it fixed ( not cheap ofc ), after repair asic was turned on without any issues, 40Th - all good.
Took it back to "farm", plugged in, did autotune, all good. Started mining - for one hour it stayed 40Th, then dropped to ~25.
In the morning checked the logs -
Hashplate [1] - 25/30 chips
After multiple restarts, change of profiles -
Hashplate 0 - 0/30 chips
Hashplate 1 - 25/30 chips
So obviously, again chips are burned... but since it worked only for an hour, its pretty clear that chips are an only consequence of something else failing on ASIC.
There are not many options, either control board or PSU, but I really have no idea, and after first repair I'm not sure how much I can trust repair shop...
Any comments?
So I finally took ASIC to maintenance.. after few hours of diagnostic - the resolution was 18 burn chips in total on 2 plates.
Well.. it is was it is, got it fixed ( not cheap ofc ), after repair asic was turned on without any issues, 40Th - all good.
Took it back to "farm", plugged in, did autotune, all good. Started mining - for one hour it stayed 40Th, then dropped to ~25.
In the morning checked the logs -
Hashplate [1] - 25/30 chips
After multiple restarts, change of profiles -
Hashplate 0 - 0/30 chips
Hashplate 1 - 25/30 chips
So obviously, again chips are burned... but since it worked only for an hour, its pretty clear that chips are an only consequence of something else failing on ASIC.
There are not many options, either control board or PSU, but I really have no idea, and after first repair I'm not sure how much I can trust repair shop...
Any comments?
Ok.. so update on this topic.
First of all, I was wrong that it's always a random hash plate - it is always chain[1].
1) On default firmware nothing changes
2) On chain[1] plate one capacitor for the power supply was a bit loose, soldered it, no difference tho.
3) Taking a functioning hash board and placing it in a chain[1] slot does not solve the problem - still in the log it is always chain[1] that is falling off.
4) Took ribbon cable from functioning board and placed it in chain[1] - no difference.
First of all, I was wrong that it's always a random hash plate - it is always chain[1].
1) On default firmware nothing changes
2) On chain[1] plate one capacitor for the power supply was a bit loose, soldered it, no difference tho.
3) Taking a functioning hash board and placing it in a chain[1] slot does not solve the problem - still in the log it is always chain[1] that is falling off.
4) Took ribbon cable from functioning board and placed it in chain[1] - no difference.
This could be a faulty control board, but in my years of mining I have never come across such an issue, the likelihood of a control board that works okay with 2 chains and the 3rd chain is bad is just too low, did you try the 4th slot? the control board has 4 places on which you can attach the ribbon/data cable into, there is an empty one since the T17 has only 3 dashboards, can you try to use that port and see if you get any different results?
Also, make sure the busbar is firmly put, and the screws are tightened, if either the positive or the negative is even slightly loosen the dashboard won't show up.
Ok.. so update on this topic.
First of all, I was wrong that it's always a random hash plate - it is always chain[1].
1) On default firmware nothing changes
2) On chain[1] plate one capacitor for the power supply was a bit loose, soldered it, no difference tho.
3) Taking a functioning hash board and placing it in a chain[1] slot does not solve the problem - still in the log it is always chain[1] that is falling off.
4) Took ribbon cable from functioning board and placed it in chain[1] - no difference.
Took everything apart and inspected, no visual damage, all heatsinks are sitting tight. plates look like new.
Again - can faulty control board or power supply cause such symptoms?
First of all, I was wrong that it's always a random hash plate - it is always chain[1].
1) On default firmware nothing changes
2) On chain[1] plate one capacitor for the power supply was a bit loose, soldered it, no difference tho.
3) Taking a functioning hash board and placing it in a chain[1] slot does not solve the problem - still in the log it is always chain[1] that is falling off.
4) Took ribbon cable from functioning board and placed it in chain[1] - no difference.
Took everything apart and inspected, no visual damage, all heatsinks are sitting tight. plates look like new.
Again - can faulty control board or power supply cause such symptoms?
There are is usually no physical damage that can be seen, the T17 miners have a very high failure rate, mainly due to the bad soldering of chips, the chip will usually NOT fall but the contact becomes too weak.
With that said, if you are consistently getting different results, I would flash the stock firmware (avoid the latest one) and test 1 board at a time, this could be a power-related issue, we can't tell for sure especially while running the miner with such firmware.
With that said, if you are consistently getting different results, I would flash the stock firmware (avoid the latest one) and test 1 board at a time, this could be a power-related issue, we can't tell for sure especially while running the miner with such firmware.
I appreciate your time and help, but it seems that you are focusing on one hashplate.
I’m not an expert at all, and I don’t think that it makes sense to talk about reasons for flashing etc.
I’m not hoping that there is some simple trick to make it work again. If it has to be repaired then so be it.
What is strange to me that every time it is different hashplate that drops off. I hardly believe that suddenly all plates are bad, and there was no physical damage to unit.
Therefore, my main questions are can these be a symptoms for bad control board or PSU?
First thing first I will try to flash default bitmain firmware on it.
I’m this kernel log it is chain 1, after reboot it could be chain3 and so on.
If one bad plate affects whole circuit and can trigger different hashplates that’s a different story.
I’m not an expert at all, and I don’t think that it makes sense to talk about reasons for flashing etc.
I’m not hoping that there is some simple trick to make it work again. If it has to be repaired then so be it.
What is strange to me that every time it is different hashplate that drops off. I hardly believe that suddenly all plates are bad, and there was no physical damage to unit.
Therefore, my main questions are can these be a symptoms for bad control board or PSU?
First thing first I will try to flash default bitmain firmware on it.
I’m this kernel log it is chain 1, after reboot it could be chain3 and so on.
If one bad plate affects whole circuit and can trigger different hashplates that’s a different story.
After flashing hiveon OS on T17
And why on earth would you do that?
Anyways, the kernel log shows that your chain 1 (the middle hash board) is dead, it could cause the miner to go into a loop of reboot, get rid of the firmware, and see if you see any different results which is unlikely, to be honest, and then just unplug chain 1 and mine with 0 and 2.
Of course, this assumes that you did the basic physical inspections like checking the screws on the busbar and replacing the ribbon cable.
If it always would fail on one hadhplate I would not ask, but plates change.
This boot it was plate1. After restart plate 1 might work well, but plate 3 would not be visible. After restart plate 2 and so on.
It was running for 30 minutes on default OS with stable 42Th, but I don’t think that it really matters as 30 minutes is nothing
This boot it was plate1. After restart plate 1 might work well, but plate 3 would not be visible. After restart plate 2 and so on.
It was running for 30 minutes on default OS with stable 42Th, but I don’t think that it really matters as 30 minutes is nothing
After flashing hiveon OS on T17 it started to randomly drop hashplates as in attached kernel log. Sometimes it works for 10 minutes, sometimes happens immediately. And it’s basically always different hashplate.
I can’t say that it worked fine with default firmware, as we did not test it.
Any ideas what could be wrong?
https://pastebin.com/saQGcNxi
I can’t say that it worked fine with default firmware, as we did not test it.
Any ideas what could be wrong?
https://pastebin.com/saQGcNxi
you did not test the gear and flashed it.
So we will never know if it did work fully before you flashed it.
you very likely have to settle on 2 boards.
What is the hash rate for the 2 boards? 27-29 th
Look at these logs below
It seems the Chain[1] is faulty it shows no ASIC compared to Chain[0] and Chain[2] that is why the miner run at the low hashrate because one of your hash board shut off.
Can you try to reattach the cable of the Chain[1] or try to replace the cable with a known working if you don't have extra cable try to use the cable from Chain[0] or [2] and test it again
If the result still the same try to run the miner at low power I don't know how to set it to low power mode with hiveOS but I think you can adjust it on their site.
Code:
2021-05-08 17:48:47 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[0]: find 29 asic, times 0
2021-05-08 17:48:53 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[0]: find 30 asic, times 1
2021-05-08 17:48:58 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 0
2021-05-08 17:49:04 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 1
2021-05-08 17:49:09 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 2
2021-05-08 17:49:09 driver/driver-btm-api.c:1445:check_asic_number_with_power_on: Chain 1 only find 0 asic, will power off hash board 1
2021-05-08 17:48:53 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[0]: find 30 asic, times 1
2021-05-08 17:48:58 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 0
2021-05-08 17:49:04 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 1
2021-05-08 17:49:09 driver/driver-btm-api.c:1431:check_asic_number_with_power_on: Chain[1]: find 0 asic, times 2
2021-05-08 17:49:09 driver/driver-btm-api.c:1445:check_asic_number_with_power_on: Chain 1 only find 0 asic, will power off hash board 1
It seems the Chain[1] is faulty it shows no ASIC compared to Chain[0] and Chain[2] that is why the miner run at the low hashrate because one of your hash board shut off.
Can you try to reattach the cable of the Chain[1] or try to replace the cable with a known working if you don't have extra cable try to use the cable from Chain[0] or [2] and test it again
If the result still the same try to run the miner at low power I don't know how to set it to low power mode with hiveOS but I think you can adjust it on their site.
After flashing hiveon OS on T17 it started to randomly drop hashplates as in attached kernel log. Sometimes it works for 10 minutes, sometimes happens immediately. And it’s basically always different hashplate.
I can’t say that it worked fine with default firmware, as we did not test it.
Any ideas what could be wrong?
https://pastebin.com/saQGcNxi
I can’t say that it worked fine with default firmware, as we did not test it.
Any ideas what could be wrong?
https://pastebin.com/saQGcNxi
Jump to: