Dragonmint T1 "ERROR - failed to recv spi data"

[tim-bc]

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.

[1715121340]

1715121340

[1715121340]

1715121340

[-ck]

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.

[philipma1957]

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.

[tim-bc]

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?

[-ck]

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...

[tim-bc]

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?

[-ck]

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?

Weird. Try downloading the file manually yourself and applying it from a local download instead.

http://ck.kolivas.org/temp/t1_20180515_060842.swu

[tim-bc]

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!

[Eric1966]

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.

[tim-bc]

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.

[BitMiner247]

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.

[-ck]

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.

[BitMiner247]

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.

[tim-bc]

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

[BitMiner247]

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.

[TheNib]

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?

[philipma1957]

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?

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.

[NotFuzzyWarm]

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...

[TheNib]

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.

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?

[asddas80]

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.