Topic: Dragonmint T1 "ERROR - failed to recv spi data" (Read 590 times)
hello friend from 2021. I hope you solved this problem, I have the same problem with these miners, if you find a solution please help me.
do you have it set on low efficiency setting or high turbo or balanced setting
try balanced setting if you have yet to try it.
try balanced setting if you have yet to try it.
yeah sucks I have tried that too looks like I am 2 boards down... What about a new controller ? or is it the hashboards not doing properly as in communicating with the controller?
if I can't remedize it will I have ti buy new hashboards?
Considering that Halong Mining, makers of the T1, are out of business good luck with that...
hi, I am getting this error now also tried all your steps... is this looking like a new hashboard or boards for me in this case I assume ?
if I can't remedize it will I have ti buy new hashboards?
if I can't remedize it will I have ti buy new hashboards?
do you have it set on low efficiency setting or high turbo or balanced setting
try balanced setting if you have yet to try it.
Code:
Jun 18 15:45:21 dragonMint cgminer[1339]: vid type detected: 0
Jun 18 15:45:21 dragonMint cgminer[1339]: fan speed set to 100
Jun 18 15:45:22 dragonMint cgminer[1339]: T1: checking T1 chain
Jun 18 15:45:22 dragonMint cgminer[1339]: chain0: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: 0: detected 63 chips
Jun 18 15:45:22 dragonMint cgminer[1339]: collect core success
Jun 18 15:45:22 dragonMint cgminer[1339]: chain1: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: ERROR - failed to recv spi data
Jun 18 15:45:22 dragonMint cgminer[1339]: failed to reset chain 1!
Jun 18 15:45:22 dragonMint cgminer[1339]: chain2: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: ERROR - failed to recv spi data
Jun 18 15:45:22 dragonMint cgminer[1339]: failed to reset chain 2!
Anyone have any ideas on this issue? The log comes from a T1 with only the left board hashing.
It's exactly as you've said - the chain isn't working. When the controller can no longer talk to the mining board, it has communication errors. The driver tries to reset the comms channel and then tries to re-init the board. If it doesn't succeed it shuts down and tries restarting cgminer. If it can't communicate with the board during the extensive init sequence on driver startup, the board will never come up.
hi, I am getting this error now also tried all your steps... is this looking like a new hashboard or boards for me in this case I assume ?
if I can't remedize it will I have ti buy new hashboards?
Oh no. Sorry to hear it didn't work man.
I swapped the controller cable from a working T1 and the board is still dead. I'm starting to think it might just be a bad board.
Unfortunately I'll probably just have to send it off for warranty work.
I swapped the controller cable from a working T1 and the board is still dead. I'm starting to think it might just be a bad board.
Unfortunately I'll probably just have to send it off for warranty work.
tim-bc, when you staggered turning on the miners one at a time was it only on that circuit/pdu? I have other miners currently running on other circuits and I'm wondering if I need to pull everything and then power them on again one by one.
It seemed to help the first time that all of the dragonmint were restarted, I only lost 1 board. But, after the last time it happened I have done all the steps and I still have 6 boards lost 
I changed the performance back to "balanced" cause it's obvious it doesn't like the overclock, and I'm still getting the dead board unfortunately. I thought it may be a bad PSU so I swapped it out with a PSU (myRig) from one of my working T1's and same thing, dead board. Updated to the latest firmware and same result.
Tomorrow I'm going to try swapping the cable from the controller to the board and try to rule that one out.
Tomorrow I'm going to try swapping the cable from the controller to the board and try to rule that one out.
Hey guys wondering if anyone has figured out a possible solution? I tried switching my T1's to performance mode and I'm getting the "Error - failed to recv spi data" on two of my machines. On one all hash boards are down and on the other one board is down.
In performance mode you're overclocking them. There is no guarantee that you'll have enough power at that level, nor that the chains will be stable. You need extra power and aggressive cooling to make it likely to work, but even then it's not guaranteed.
Hey guys wondering if anyone has figured out a possible solution? I tried switching my T1's to performance mode and I'm getting the "Error - failed to recv spi data" on two of my machines. On one all hash boards are down and on the other one board is down.
tim-bc, when you staggered turning on the miners one at a time was it only on that circuit/pdu? I have other miners currently running on other circuits and I'm wondering if I need to pull everything and then power them on again one by one.
tim-bc, when you staggered turning on the miners one at a time was it only on that circuit/pdu? I have other miners currently running on other circuits and I'm wondering if I need to pull everything and then power them on again one by one.
Hey. Did you ever get all boards up and running again tim-bc?
I got most of the dead boards (10 out of 11) back again. But in my case, it seems like the issue was mostly due to them all booting at the exact same time.
Hey. Did you ever get all boards up and running again tim-bc?
I have the same error in the miner logs, T1 was delivered to me from Halong with one PCB inop so sent it off to MyRig for repair.
They returned it and it was still broken.
It lights up on startup, then the chain fails to come online, just as you mentioned. Tried changing the cable as philipma1957 mentioned, same board with the problem.
Will just have to send it off to MyRig again I guess - shame though at £20/time from the UK, for a miner that has never functioned since delivery from Halong!
Thanks.
I have the same error in the miner logs, T1 was delivered to me from Halong with one PCB inop so sent it off to MyRig for repair.
They returned it and it was still broken.
It lights up on startup, then the chain fails to come online, just as you mentioned. Tried changing the cable as philipma1957 mentioned, same board with the problem.
Will just have to send it off to MyRig again I guess - shame though at £20/time from the UK, for a miner that has never functioned since delivery from Halong!
Thanks.
So I found that the issue with upgrading the firmware was with the network (I was already trying to apply from local), I could move the miners to another network and upgrade them just fine. But when doing so I noticed some boards were OK even without an upgrade. This made me read back to what you said about inrush of current.
I realized that instead of trying to turn all of the T1 back up at once by pdu/breaker, I should try staggering them instead, turning one on every 15-30 seconds. This was very effective and almost all of the miners are working well again. Thanks again for your help Con!
I realized that instead of trying to turn all of the T1 back up at once by pdu/breaker, I should try staggering them instead, turning one on every 15-30 seconds. This was very effective and almost all of the miners are working well again. Thanks again for your help Con!
Also make sure you're on the latest firmware
It does seem to help, I upgraded one and it went back from 1 board to 2. The only problem is that most of the miners get stuck around 30% when upgrading. https://i.stack.imgur.com/Tg9de.png Any idea why?http://ck.kolivas.org/temp/t1_20180515_060842.swu
Also make sure you're on the latest firmware
It does seem to help, I upgraded one and it went back from 1 board to 2. The only problem is that most of the miners get stuck around 30% when upgrading. https://i.stack.imgur.com/Tg9de.png Any idea why? Thank you for the extensive reply, Con. My only question is why would this issue start to occur after a reboot?
In my case I was watching about a dozen of the T1, all of them 16 TH for a couple weeks, until they were all rebooted (power off for 5-10 mins, then back on). After this, 4 miners came back up with only 1 board and there are 4 more that only have 2. Tried rebooting them all but exact same results.
I made sure to check pool stats to confirm the hashrate drop. Any idea why those faulty boards were still able to keep hashing until the miners were rebooted?
Inrush of current, thermal changes, hot vs cold, who knows. The 10nm chips are very fussy. Might be worth powering them down to let them cool and then start again. Also make sure you're on the latest firmware; some earlier ones weren't as reliable at starting them. They're a royal pain in the arse to start reliably... In my case I was watching about a dozen of the T1, all of them 16 TH for a couple weeks, until they were all rebooted (power off for 5-10 mins, then back on). After this, 4 miners came back up with only 1 board and there are 4 more that only have 2. Tried rebooting them all but exact same results.
I made sure to check pool stats to confirm the hashrate drop. Any idea why those faulty boards were still able to keep hashing until the miners were rebooted?
Thank you for the extensive reply, Con. My only question is why would this issue start to occur after a reboot?
In my case I was watching about a dozen of the T1, all of them 16 TH for a couple weeks, until they were all rebooted (power off for 5-10 mins, then back on). After this, 4 miners came back up with only 1 board and there are 4 more that only have 2. Tried rebooting them all but exact same results.
I made sure to check pool stats to confirm the hashrate drop. Any idea why those faulty boards were still able to keep hashing until the miners were rebooted?
In my case I was watching about a dozen of the T1, all of them 16 TH for a couple weeks, until they were all rebooted (power off for 5-10 mins, then back on). After this, 4 miners came back up with only 1 board and there are 4 more that only have 2. Tried rebooting them all but exact same results.
I made sure to check pool stats to confirm the hashrate drop. Any idea why those faulty boards were still able to keep hashing until the miners were rebooted?
check cable connection from hash board to controller
you could swap a cable from a good board to see if the problem flows the cable or stays with the dead board.
you could swap a cable from a good board to see if the problem flows the cable or stays with the dead board.
It's exactly as you've said - the chain isn't working. When the controller can no longer talk to the mining board, it has communication errors. The driver tries to reset the comms channel and then tries to re-init the board. If it doesn't succeed it shuts down and tries restarting cgminer. If it can't communicate with the board during the extensive init sequence on driver startup, the board will never come up.
Code:
Jun 18 15:45:21 dragonMint cgminer[1339]: vid type detected: 0
Jun 18 15:45:21 dragonMint cgminer[1339]: fan speed set to 100
Jun 18 15:45:22 dragonMint cgminer[1339]: T1: checking T1 chain
Jun 18 15:45:22 dragonMint cgminer[1339]: chain0: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: 0: detected 63 chips
Jun 18 15:45:22 dragonMint cgminer[1339]: collect core success
Jun 18 15:45:22 dragonMint cgminer[1339]: chain1: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: ERROR - failed to recv spi data
Jun 18 15:45:22 dragonMint cgminer[1339]: failed to reset chain 1!
Jun 18 15:45:22 dragonMint cgminer[1339]: chain2: spi speed set to 390K
Jun 18 15:45:22 dragonMint cgminer[1339]: ERROR - failed to recv spi data
Jun 18 15:45:22 dragonMint cgminer[1339]: failed to reset chain 2!
Anyone have any ideas on this issue? The log comes from a T1 with only the left board hashing.
Jump to: