Antminer D3 reports trouble reading PIC temperature's

[Pumperdumper]

I Changed mine to 437 then 444m. Hasn't voided warranty in dealing with them. I had to. It was completely unusable at the "default frequency". They are not great on backing their product warranty, because on diagnosing, two boards had HW errors but oddly when all 3 run there are absolutely 0 HW errors, but it still goes all X in 3 - 4 days, and I have to reboot. I feel like they are dragging the warranty period out, by persistently telling me, "Unless the boards run seperately and X out, I can only return, and I can only return 1 hash board". Makes no sense, not a warranty.

My rant. But I think as long as the frequency is lowered, not raised, then it should not void any warranty. They made them completely inoperable at their default frequency.  I would open a repair ticket with them first though. Typical Bitmain.

I have 4 tickets open and they haven't responded to a single one.

Lol

So should I assume that chain #2 is done for since it doesn't even show the X's and O's?

I've also noticed that the third pool doesn't register any pool? I've tried mining pool hub and nice hash and both come up as dead?

4 Tickets and no response? Yikes. On mine they take 24-48 hours. I'm not in anyway remotely an authority or experienced enough on these diagnostics, but if chain 2 is not showing X or O, I would "guess" controller board?


So many issues with the D3's and I feel (have a hunch maybe?) that there are big-time firmware issues globally.

I'm curious to hear if others are experiencing, would love hear the issues and what they've done in diagnosing and troubleshooting this.

After 2 days running on a D3 with issues, Chain 1 just went entirely X'd. Before 4 days all chains X'd. And prior to that Chain 2 showed 3 ASICs X'd. This is puzzling and driving me bonkers. I feel like I need to diagnose each board for 2-4 days now each to see. Is that practical? What is strange to me are the temps and the fan (Chain 1 and 2 running solo/individually, the fan goes to 6k, 3 only at 4k).  Temp on chain 3 solo gets gets to 77c (Scary) and yet when all run at once the fan is at 4k (Temps run: C1: 69c, C2: 63c, and C3: 70-71c). Chain 3 solo show HW errors but all three running show absolutely 0 HW errors. It's very odd.

I'm lost. I'm thinking firmware? And maybe Bitmain is swamped with these issues. We, or at least the large majority of the mining community, have financed them to a monopoly and likely funded their new Sophon AI brand.   I think we all just need to persist on reporting these issues, and keep opening tickets. They need to back their products.

I'm not expert either - BUT I have updates for everyone.


So - Chain 2 (3rd ASIC) X'd out completely a few days ago. Today everything is back to normal.

These are the steps I took.


Once Chain 2 X'd out - I updated the firmware to the one posted in here from amazonaws - I flashed it to the D3 and then let it run on the remaining Chains with all the problems errors on the log.

VERY IMPORTANT SETTING CHANGE: In Miner Configuration > Advanced Settings > Frequency - I changed this from Default to 444M - I believe this is what fixed a lot of it along with the firmware update (reboots are only for the socket errors to go away and for it to get adjusted to the new firmware update)

Ran it for a total of 2 days and 12 hours

Today when I came in - I rebooted through the IP address - then a socket error showed - rebooted through the IP address 2 more times and then I went back and unplugged the machine manually. Plugged it back in and rebooted through the IP address once more.

After that all the Chains were back to normal and the machine is running at 16/mhs steadily. It even gave me the error that the temp reading is off and to reboot the PIC's



I have a sever suspicion that the readings on the backend are NOT accurate. Temperature and Chain readings could be off because of their firmware.

It does not make sense for an ASIC to X out completely and then all of a sudden come back. If it X's out that means the controller is bad and needs to be replaced - but that means that it can't come back from the dead either. A false positive. So that leaves only the option that the firmware is bad and cannot get accurate readings of the machine as it is running.

This is what I am seeing to be in my case. People might be screwing their machine more by acting on these readings and breaking something that didn't need fixing.

[1714038915]

1714038915

[1714038915]

1714038915

[DCShmooC1]

I Changed mine to 437 then 444m. Hasn't voided warranty in dealing with them. I had to. It was completely unusable at the "default frequency". They are not great on backing their product warranty, because on diagnosing, two boards had HW errors but oddly when all 3 run there are absolutely 0 HW errors, but it still goes all X in 3 - 4 days, and I have to reboot. I feel like they are dragging the warranty period out, by persistently telling me, "Unless the boards run seperately and X out, I can only return, and I can only return 1 hash board". Makes no sense, not a warranty.

My rant. But I think as long as the frequency is lowered, not raised, then it should not void any warranty. They made them completely inoperable at their default frequency.  I would open a repair ticket with them first though. Typical Bitmain.

I have 4 tickets open and they haven't responded to a single one.

Lol

So should I assume that chain #2 is done for since it doesn't even show the X's and O's?

I've also noticed that the third pool doesn't register any pool? I've tried mining pool hub and nice hash and both come up as dead?

4 Tickets and no response? Yikes. On mine they take 24-48 hours. I'm not in anyway remotely an authority or experienced enough on these diagnostics, but if chain 2 is not showing X or O, I would "guess" controller board?


So many issues with the D3's and I feel (have a hunch maybe?) that there are big-time firmware issues globally.

I'm curious to hear if others are experiencing, would love hear the issues and what they've done in diagnosing and troubleshooting this.

After 2 days running on a D3 with issues, Chain 1 just went entirely X'd. Before 4 days all chains X'd. And prior to that Chain 2 showed 3 ASICs X'd. This is puzzling and driving me bonkers. I feel like I need to diagnose each board for 2-4 days now each to see. Is that practical? What is strange to me are the temps and the fan (Chain 1 and 2 running solo/individually, the fan goes to 6k, 3 only at 4k).  Temp on chain 3 solo gets gets to 77c (Scary) and yet when all run at once the fan is at 4k (Temps run: C1: 69c, C2: 63c, and C3: 70-71c). Chain 3 solo show HW errors but all three running show absolutely 0 HW errors. It's very odd.

I'm lost. I'm thinking firmware? And maybe Bitmain is swamped with these issues. We, or at least the large majority of the mining community, have financed them to a monopoly and likely funded their new Sophon AI brand.   I think we all just need to persist on reporting these issues, and keep opening tickets. They need to back their products.

I'm not expert either - BUT I have updates for everyone.


So - Chain 2 (3rd ASIC) X'd out completely a few days ago. Today everything is back to normal.

These are the steps I took.


Once Chain 2 X'd out - I updated the firmware to the one posted in here from amazonaws - I flashed it to the D3 and then let it run on the remaining Chains with all the problems errors on the log.

VERY IMPORTANT SETTING CHANGE: In Miner Configuration > Advanced Settings > Frequency - I changed this from Default to 444M - I believe this is what fixed a lot of it along with the firmware update (reboots are only for the socket errors to go away and for it to get adjusted to the new firmware update)

Ran it for a total of 2 days and 12 hours

Today when I came in - I rebooted through the IP address - then a socket error showed - rebooted through the IP address 2 more times and then I went back and unplugged the machine manually. Plugged it back in and rebooted through the IP address once more.

After that all the Chains were back to normal and the machine is running at 16/mhs steadily. It even gave me the error that the temp reading is off and to reboot the PIC's



I have a sever suspicion that the readings on the backend are NOT accurate. Temperature and Chain readings could be off because of their firmware.

It does not make sense for an ASIC to X out completely and then all of a sudden come back. If it X's out that means the controller is bad and needs to be replaced - but that means that it can't come back from the dead either. A false positive. So that leaves only the option that the firmware is bad and cannot get accurate readings of the machine as it is running.

This is what I am seeing to be in my case. People might be screwing their machine more by acting on these readings and breaking something that didn't need fixing.

Almost like we got D3's from the same batch. Problems are similar. I received a response, cleared to open and check the boards, saying a PCB board (Chain 3) was too high (showed 244c  ) last time all X'd out. So running on 444m, latest firmware from the last AWS link. it still bugs out. I don't think examining the boards for loose heat sinks, blown or unsoldered caps, etc is really going to solve anything. I think your right, the frequency is an issue and I personally suspect the backend readings are bad too, maybe from the firmware. I figure I'll give it a shot though.

[MaxiMan]

Hello, new here as my D3 came just last week.
Also had this issue, but its confirmed that Error Reading Temps and fans going max speed comes when internet or pool connection is lost.
And it triggers many errors like hashing boards showing XXXX sometimes, or just nothing showing there...

Today zpool went down for about 2~3 hours and confirmed this issue, just looping the same behavior.
What annoys me is why it becomes noisy at 5am sounds like a siren lol... anyways this behavior is weird... its the contrary to any GPU used.
Fan speed decreases if not working detected... why ASIC Fans became crazy like something is overheating?
There is a way to configure to avoid FANs to running crazy full speed when connection is lost?

Thanks in advance!

[unknownMe]

L3+ October batch is doing exactly the same... all reported together:
- Touching it on the wrong places / LAN cable moving makes it turn off mining / red light flashing
- Disconnecting / reconnecting pools makes the fans go crazy
- No connection to pools makes it keep on spinning up all the time
- Turning all hash boards into XXXXXX, till rebooting then fine...

As it's different hardware, I think it's just errors in the firmware!

[mjknieser]

Newbe to this Forum and newbe to Antminer D3.

So my new D3 as of yesterday is reporting the following from the "Kernel Log" tab:

-----

Dec 16 03:55:41 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 03:55:41 (none) local0.warn cgminer[361]: Switching to pool 0 stratum+tcp://x11.mine.zpool.ca:3533
Dec 16 03:55:44 (none) local0.warn cgminer[361]: API running in IP access mode on port 4028 (15)
Dec 16 08:32:55 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 not responding!
Dec 16 08:32:55 (none) local0.warn cgminer[361]: Switching to pool 1 stratum+tcp://dash.poolmining.org:3062
Dec 16 08:32:59 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 08:33:03 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 08:33:25 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 08:38:10 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 stable for 5 mins
Dec 16 08:38:10 (none) local0.warn cgminer[361]: Switching to pool 0 stratum+tcp://x11.mine.zpool.ca:3533
Dec 16 09:46:27 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 09:46:27 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 not responding!
Dec 16 09:46:27 (none) local0.warn cgminer[361]: Switching to pool 1 stratum+tcp://dash.poolmining.org:3062
Dec 16 09:46:31 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 09:46:32 (none) local0.warn cgminer[361]: Waiting for work to be available from pools.
Dec 16 09:46:36 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 09:46:37 (none) local0.warn cgminer[361]: Work available from pools, resuming.
Dec 16 09:46:59 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 09:51:40 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 stable for 5 mins
Dec 16 09:51:40 (none) local0.warn cgminer[361]: Switching to pool 0 stratum+tcp://x11.mine.zpool.ca:3533
Dec 16 11:34:31 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 not responding!
Dec 16 11:34:31 (none) local0.warn cgminer[361]: Switching to pool 1 stratum+tcp://dash.poolmining.org:3062
Dec 16 11:34:34 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 11:34:38 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 11:35:01 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 11:39:40 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 stable for 5 mins
Dec 16 11:39:40 (none) local0.warn cgminer[361]: Switching to pool 0 stratum+tcp://x11.mine.zpool.ca:3533
Dec 16 14:43:15 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 not responding!
Dec 16 14:43:15 (none) local0.warn cgminer[361]: Switching to pool 1 stratum+tcp://dash.poolmining.org:3062
Dec 16 14:43:19 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 14:43:23 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 14:43:45 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 14:44:50 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 14:49:40 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 stable for 5 mins
Dec 16 14:49:40 (none) local0.warn cgminer[361]: Switching to pool 0 stratum+tcp://x11.mine.zpool.ca:3533
Dec 16 15:20:17 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 not responding!
Dec 16 15:20:17 (none) local0.warn cgminer[361]: Switching to pool 1 stratum+tcp://dash.poolmining.org:3062
Dec 16 15:20:17 (none) local0.warn cgminer[361]: Pool 0 stratum share submission failure
Dec 16 15:20:20 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 15:20:24 (none) local0.err cgminer[361]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!
Dec 16 15:21:47 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability
Dec 16 15:21:52 (none) local0.warn cgminer[361]: Pool 0 communication resumed, submitting work
Dec 16 15:22:11 (none) local0.warn cgminer[361]: Lost 1 shares due to no stratum share response from pool 0
Dec 16 15:22:41 (none) local0.warn cgminer[361]: Lost 1 shares due to no stratum share response from pool 0
Dec 16 15:25:53 (none) local0.warn cgminer[361]: Pool 0 stratum+tcp://x11.mine.zpool.ca:3533 alive, testing stability

------

I somehow found source code for some version of cgminer at GitHub:

https://github.com/bitmaintech/cgminer-dash/blob/master/driver-btm-DASH.c

Within this C file there is a function that matches the error message called "read_temp_func".  This "read_temp_func" runs forever as its own thread reading the temperatures from each ASIC at READ_TEMPERATURE_TIME_GAP intervals.  According to this code the only way this Kernal Log message occurs is if ALL ASIC temperatures cannot be read.

Thus, and I claim, if it really was a hardware problem, the Kernal Log should be swamped with these error messages.  Since that is not true, I claim there is some software issue.  Given my logs it appears that every time the D3 tries to switch between pools there is a "read_temp_func" error.

A result of this error, and according to the C file, the fans should switch to 100% duty cycle until the D3 can read atleast one of the ASIC's temperature sensors.

Therefore, I am not going to worry about this error pattern.

Reasonable?

---
Michael

[sanitariu]

Yes very good !
I do not care too if at least one sensor is okay.
The only problem is this high rpm sound over 5-6000.
Anyone tried any options in cgminer.conf to stop RPM if you do not
have internet for example ?

[1DryVallley]

I put my D3 on line in mid December. was clocking at 516 MHz, and showing a hash rate of 19.5. but kept seeing HD faults. 

After about a month of running, lost 5 chips on one board....they just disappeared. No XXX, just gone. 

Sent the board to Bitmain (USA) for repair, and got a new board back in 10 days. Super good fast warranty service. My only cost was shipping to them. 

Set my clock rate at 487 (17.5 Mhz), and all is well. Everything is now stable, no HD in 3 days, switches pools automatically when 1st pool goes down. Temp are now 45/71 use to be 50/80.

The D3 is now happy and trouble free.

Good thing these ASIC are machines and not women, or they would be jealous as I bought a T3 today to make a little more money. 

[phuocduong]

high noise and hot, i think should use PSU over 1600w

[radiera]

hey,, it should be install old firmware or what ?? i get that problem too,, but now it has fix because supply.. i dont know my supply in home or from psu... board working again but i dont know until when it problem come again

[sanitariu]

Just put to 450Mhz and 30% fan and forget it.
That's how it works for months.
And taking only 840W

[xcajun21]

I would like to hear your story on this. Any updates? lowering the frequency fixed the issues?


This 17-19ghz
https://www.youtube.com/watch?v=LD7psoK6fFw

[sanitariu]

Yes.
One of my asics has 54 cpus only and makes much errors.
But it really does not matter so much.
Do not stop/start your D3 miner , you loose money with this.
Much more !
Just put to 450/456MHz put fan to 30-35% and forget it.
Yeah thats it
Working from 2 months non stop.

[xcajun21]

Mine is set at 469Mhz and ran for 7 days very promising, now is at 11.434 GH/s. You have more d3? only one is causing issues at that frequency, the rest is stable? Have your tried 437Mhz, that some suggest...

[sanitariu]

I have 2.
One is at 3 x 60 asics mining 456Mhz, fan 30% i use also to make warm in my kitchen.
Other one 2 x 60 asics and one is 54 asics. Mining at 450Mhz, fan 30%. Have some errors but its okay at the pool.
Second one if i put to 456Mhz i loose 1 whole board and only 2 x 60 asics.
I think 450/456 is the sweet point without troubles.
All have temperatures around 80-83 degrees. This way working from over 60 days without stop.
Sometimes i move between nicehash and dash pools.

[xcajun21]

So you get stable frequency at 450Mhz? is that 15000ghs? Why not try 437 mhz as some suggested, or even using auto reboot firmware. Have you tried that?

[sanitariu]

Yes i tried some like blisz and others but really not useful.
I do not need reboot feature. Why you need this ? It never stops.
The only useful thing would be if temp goes over 100 just shutdown miner.
This will help.
Now i have approx 15-16Ghz stable.

[xcajun21]

Mine was Okay at 437mhz for 9 days but fell down and started down hashing at 10k today
Any help with that?

[FNT]

Hi!

does anybody has a hex dump of the D3 PIC PIC16F1704?

Thanks and bye, FNT

[xcajun21]

How to fix d3 hash rate cut? So the firmware from bitmain and lower clock fixed this ?

[rascao]

Hi i got the same problem of pic temps, but i notice something, my antminer firmware display my pic version is PIC16F1704 but my hasboard have a PIC16F1705 chip on it so i think thats the problem 4 me any one else have notice something like that?

Code:

check_whether_need_update_pic_program
(none) local0.notice cgminer[375]: reset_PIC16F1704_pic_new ok
(none) local0.notice cgminer[375]: jump_from_loader_to_app_PIC16F1704_new ok
(none) local0.notice cgminer[375]: get_PIC16F1704_software_version_new ok, version = 0x81
(none) local0.notice cgminer[375]: every_chain_reset_PIC16F1704_pic_new
(none) local0.notice cgminer[375]: reset_PIC16F1704_pic_new ok
(none) local0.notice cgminer[375]: every_chain_jump_from_loader_to_app_PIC16F1704_new
(none) local0.notice cgminer[375]: jump_from_loader_to_app_PIC16F1704_new ok
(none) local0.notice cgminer[375]: every_chain_enable_PIC16F1704_dc_dc_new
(none) local0.notice cgminer[375]: pic_heart_beat_func_new
(none) local0.notice cgminer[375]: enable_PIC16F1704_dc_dc_new ok
(none) local0.notice cgminer[375]: reset_all_hash_board