Bitcoin Forum

Hi Mining experts,

Well after a while trading and playing a bit with some bots I thought it would be nice to have a Bitmain Antminer D3.
So I Ordered one (quite some time ago) and it arrived today.

First thing I did was to make sure the D3 actually worked so I:
1) Connected all power cables from the APW3++ to the D3 (hash boards and the controller board) its a very stable 230Volts 50Hz here
2) Connected the UTP cable to the network switch
3) Connected the power to the mains
4) Left ALL settings on default to see if the D3 actually worked

Logged in on the Web interface and the Miner status reported all was well:
All chains were there (1 2 3), ASIC# reported as 60 per chain, Frequency 487, MH/S all in the 5700.00 range, HW 0, Temp PCB in the 50 range, Temp Chip in the 60+ range, ASIC status all o (So i assume no reported defects here)

The User was stil Antminer_1 (didn't change it, wanted to see if the D3 works to begin with)

So this looked ok, then after a short while the D3's red light blinked once and the fan's speed increased after a short while to go down again.
When I checked the kernel log there was a line that was added @the same time the red light blinked:
local0.err cgminer[374]: read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!


I've no idea what this means, other than when the cgminer software is running it cant for some reason get all of the chips temps?
however the status window does report temps per hash board?

I'm not sure if its a config/controller/controller cable/hash board/Software(firmware)/other problem

Any insights would be greatly appreciated!
Thanks!
David

what about the number of HW errors. is it increased?

Hi alexiamni,

It still reads 0 for all three hash boards, think this is because cgminer has not started with actual mining?

to be honest, i don't know real reason for that problem, if i can call that problem. but HW does not increase and it is good. i think it is not real problem for worry.

The part that has me worried a bit is that the red error led flashes (once) then the kernel log shows that message and the fan goes up and then It does the same after a minute or so.

Don't know if it's software or hardware related

it will be right to contact to Bitmain Support. maybe they can help you.

i have the same problem but for me after one or tw hours the d3 show xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx on the asics chips in one hashing board but withe the reebot starts works perfectly  agin for an onther peridod of time and my temp are 68-72 more less any help?

Do you get the same cgminer error Message?

If the entire bord registers as defect, it almost looks like there is a defect in the on hash bord power supply? All power cables are inserted properly and the control cables have no damage?
If there is one defect chip the bord should continue to function.

Might be best if you contact Bitmain to ask if you can remove the defect hash bord and send it back for repair.

Have the feeling that quality control was not that great :(

Mine just loops and doesn't hash, doesnt show any defect chips or bords.
Still don't know what it could be in my case.

have you try to check the pool you are mining for? configuration because mine at first do the same and was that the pool info was bad and other solution i sell my power to nicehash but maybe check that and if you cant i can help you to try to config and see if you can start mining and i underclok mine to realative fix send a message maybe i can help you

Same is happening to me read my post
https://bitcointalk.org/index.php?topic=2195355.msg22053491#msg22053491

I have 14 machines they all do it i guess all D3 miners do this this is the only thing that would explain the changes on the mining difficulty if you watch it goes up and down all day long i guess because the miners are having this behavior

I concur with @unknownbtc - my D3s are showing a lot of fluctuations in difficulty with one hash board going xxxxxxxxxxxxxx then returning to oooooooooooooooooo.   

Hi guys!

Thanks for all the replys really helpful!
Seems that my D3 has the exact same behavior.

Just for fun I tested the D3 with a lab grade PSU (extremely stable single rail ripple free source) and the
Behaviour was the same.
Also installed the latest firmware, made no difference.

Most important thing is that the D3 does work, can imagine that the overall performance could be better if the D3 was a bit more stable.
Bitmain might just have a golden firmware version that they use in their farms ;)

An interesting one as well, do any of you guys have a blade constantly running hotter than the others, like 8degress?

Chain#   ASIC#   Frequency   MH/S(RT)   HW   Temp(PCB)   Temp(Chip)   ASIC status
1 60 487 5646.18 0 53 65 oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooo
2 60 487 5637.95 0 51 65 oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooo
3 60 487 5718.85 0 58 73 oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooooooo oooo

EDIT: And I only get HW Errors on the same blade , switched PSU, same...
Until my proper PSU arrives, i'm running a 3 PSU setup, one per blade, the PSU's were fine, as they were running on GPU rigs..., this is getting me frustrated.

I'm having exactly the same issue, but mine causes  mostly HW errors, will try to leave it on just DASH instead of zpool which is constantly jumping in/out of different coins, as such, difficulty changes and causes this

EDIT: Even with Dash only it happens, but less because it's only 1 coin, this will probably be fixed in a firmware update , HOPEFULLY

Im even mining on antpool

I have Antminer D3 12 machine same error "read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!" All

All of you who have problem with your D3 ...

What voltage you power supply connected ? 110/120V .. 220V .. 245V ?

Also what PSU's are you using . Bitmain ? Server psu w break out borad ? PC psu ?

Are You using power line Ethernet adapter to connect your miner to a network ?
A lot of the time, the electrical wiring in the house just isn’t ideal for powerline ethernet.

Are You using any kind of Surge protector with your power line adapters ?
Surge protectors can protect your computer, but they also scramble powerline ethernet signals. Plugging a powerline ethernet device into a power bar with surge protection will severely limit your potential speed, if not stop the device from working altogether.

I have 2 Antimner D3 (https://shop.bitmain.com/productDetail.htm?pid=00020170918214914392zGPQW7nE06A2) at this moment ,so far no problem with them , mining only dash , not using prohashing, nicehash pool or something similar to mining different coins .

The D3 description on bitmain site says : "Power consumption: 1200W (at the wall, with Bitmain’s APW3 PSU, 93% efficiency, 25°C ambient temp)." In my experience my D3's pulling a little bit more power at the wall than 1200 watts from 245Volt with bitmain PSU

If you running your miners from 110/120 volt with Bitmain APW3++ (https://shop.bitmain.com/productDetail.htm?pid=00020170920224132179WEIOvhXx06D6) , you might get in trouble as those psu's are rated 1200 watts if connected to a 110/125 volt outlet  , 1600 watts if connected to 220V

try this troubleshooting tips what another forum member received from Bitmain support :

Hi Guys,

Just a quick followup, I've had a chance to so some more testing with 5 D3's and did the following:
1) Tested with a single APW3++ PSU on a 230V mains source
2) Tested with a 3600 Watts single rail PSU (Lab testbench PSU, so not a converted server PSU or PC PSU)
3) Tested with a power conditioner (used in high end audio setups)
4) Flashed the latest available firmware from: https://s3.cn-north-1.amazonaws.com.cn/shop-bitmain/download/Antminer-D3-201709131713-0M.tar.gz
5) Hard wire connection to a Cisco 24Port managed switch (tested on different ports with different cables)
6) Set the mining pool to Antpool
7) Inspected the hashbords of a single D3 for damaged solder points powerlanes etc, loose/missing heatsinks -> All looked fine.

Results:
- All of the D3's had the random error mode red led warning flash
- All of the D3's had the random (The red led is in sync with this message) "read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!" message in the kernel log's.
- All of the D3's had the occasional "all x'es" on 1 or 2 hashbords, and returning to normal after a "reboot"

This seems to be what most of the contributors to this thread experienced as well.
- So it seems that it's not related to the stability of the used power supply.
- Chances that each D3 (at least in the case of the posters in this thread, that have several D3's that exhibit the exact same behavior) has 1 or 2 malfunctioning hashbords seems unlikely,
and I assume that Bitmain would notice this with their Quality Assurance tests.

That kind of leaves me with:
- Software bugs
- Controller (board) bugs

What I still want to test:
- Is the behavior the same when disconnecting 1 or 2 hashboards.

I'm hoping that Bitmain is able to sort this out with a firmware update (if it's indeed a software problem), however... They might not be inclined to do so since the rapid increase in Dash difficulty might make this
an uninteresting investment.

I have the same thing after rebooting it takes about a day - but I found another unusal thing

Since tonight one of my antminers D3 has a lot of traffic (normal are under  200K now it is over 10M). You see it only if you have a look on the traffic monitor. All the rest was fine with mining so it is not easy to see this. I put now the new firmeware in.
Lets see what happend.

After three hours of monitoring everything looks good again with the new Firmeware. The traffic is again under 200 K.

Great input,

I also tested with 7 different PSU's, same results, as for the controller, I switched the boards around on the controller, and in my case, the same board has errors along the controller ports.

A thing i noted, is that whenever the pool stops responding, those errors just come up, and then when it starts receiving back jobs, everything comes back to normal (just not the HW Errors part of course), this happens like 100% of the times so far.
So i'd say it's a software bug mixed with hardware issues.
Also, then the pool stops responding, the fans spin up to their max (bad software design i'd say).
Also tried to underclock to under 15GH/s values, same issues happen.
As for the networking part, well, I have other things running on the network for months now with no issues... so I cut that one out

Let's wait and see what bitmain does about this

i am also having this issue, does new firmware packed in tar.gz i have to upload via webgui ?, does this new firmware helped others ?

Mine are much more stable lately. And yes, you have to upload via webgui and the firmware is packed on tar.gz

The software is looking at the wrong pointer for the info from the hardware. You need to supply the proper info for the software, probably in the config file and then restart the whole thing, that will solve the problem. It is not a big deal and only takes a minute of two.

The data is hardcoded into the miner when it's built, you can probably check the cgminer from ckolivas and check the antminers headers there (although D3 is not there)
So the software is not getting wrong pointers, it's just badly made, like whenever there is a connection error to one of the pools, the PIC temperature error is thrown, because the ASIC's are kind of reset or something, and even the fans spin up for no reason, bad coding.

Or if there is no work from the pool (can happen), same things happen.

Just check the kernel log and you'll find this pattern

I think it's just an overclock issue. We had the same issues, after we reduced the clock speed to 437, all problems where gone. No xxxooxxxx and HW errors since 3 days.
Now we are hashing with 15.8GH/s, which is the clock rate which was originally announced by BitMan.
Conclusion: BitMan has just overclocked the D3 and labeled it with 17GH without testing it. An that is really annoying.  >:( >:( >:(

having same isssues any soultion on   t his ?

so whats the round up on the D3?

its performing as it should?

is the quality flagging on some units??

im asking as i trying to get hold of one, anyone selling in UK?

Just got two new D3. Had the same kind of problem with them. Random failures  with red LED blinking (failure LED) , coolers at max, noise and sometimes loosing network connection. Only cold reboot helps.

Noticed that behavior when touching the device or just the network cable.

Finally managed to repeat the failures manually with both units by messing with network cable, but not disconnecting it. We have done some dangerous tests.

Removing the front panel solves the problem completely. Looks like the front panel contacts sometimes with metal RJ-45 socket on board causing device failure. Reproduced this on video.

https://youtu.be/-Kug4HwiFYY (https://youtu.be/-Kug4HwiFYY)

Please donate LTC  if it helps: LKPV84ysTA3eR58oCAoLwUgLPUyuxLcgdu

So far i know from personal testing  ...

D3 hangout at max speed when pool seems to be offline or dead.

D3 hangout at max speed on multi coin pool when pool take time to submit new work, back to normal when submission is done.

This 2 issues result in message warning about "trouble reading PIC temperature's", so for my case is a software issue.

If you have this issue without problem on pool, check controller unplug/plug etc ...

I never have a "red light issue".

D3 lost some chip when running have to reboot, fixed after firmware update.

D3 dont like to be turned off with "shutdown -h now", stuck for long time have to kill it by hand.

In some case your D3 will lost stability after this hard shutdown, and you will start to have xxxx xxxxx xxxx board even if you reboot. Go back to factory default and upgrade firmware again (even if is same version)

I running them on low noise setup, 43% fan speed each. You need fresh air to enter and that ok.

My D3's running between 70c to 83c without any issue. For a CPU, 85c as critical point is ok, CPU can handle MORE.

Some time one of my miner get disconnect like pool is dead, but the other one working ... Same switch, same network. A easy fix was to ssh on this one and enable a ping on google. No more connection lost (that maybe come from my router port)

bump to this

WRote a small script in php to check your D3's and reboot them automatically in case an hashboard has errors

https://gist.github.com/tperalta82/6e11253cd4b9cf9c5c6fa15bbf046d4f

put this in a linux server as a cronjob, change the $hosts array, to add your arrays.

There are 3 different methods to call reboot on the miner, personally, the wget one is better for me, because it runs everywhere (embedded devices)
Had an issue with curl, seems to fail to authetnicate on some weird cases
and ssh lib is not present everywhere.

Read the code first, understand it, redistribute it, improve it, do whatever you want with it.

P.S.: it works for me

I don't know what cause this to happen. I started mining on nicehash and this read_temp_func repeating occured every 5-10 minutes. But when I move to others pool like antpool itself. It works fine for many hours. I'll keep monitor and test on this situation. Hope the next firmware they release solve this.

I got all xxxx xxx on one of my boards too, a  online reboot fixed the problem for now.

I got 2 D3 yesterday and they keep speeding up the fans every 5 minutes.

Every time this happens, the log says "read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!". I configured mining on nicehash and I'm wondering if this is connected to the problem?

Anyone got a grip on this issue by now to narrow it down?

Switched to ViaBTC and the problem didn't occur again. Might be an issue with Nicehash. Since everyone keeps forgetting to send a follow up if the problem was solved, please send me a PM if I forget it as well ;)

Same problem here :/

I also had this problem
The problem is only with the Nicehash pool
If you use a different pool, the problem does not exist

Shurkan

Hi Guys,

There seems to be a new firmware for the D3
With the description:
1. fix the issue: some miner's chip status is 'x' after running for several hours or days.

https://s3.cn-north-1.amazonaws.com.cn/shop-bitmain/download/Antminer-D3-201711022227-0M.tar.gz

I'll Test it when I can.

we can confirm that this is now running well so far.

Do try it out.

Has the recent update for the D3 solved the " trouble reading PIC temperature's" error when the pool dies or it loses connection?

i have tested new firmare but i have some hw error on my september bach ...

This error come from your pool, when D3 cant reach pool and get work.

Cgminer seems to have trouble to check temp, since i mining on mining dutch pool no more error at all.

 Same problem, same issue. The last time, All ASICS went out. Same responses from Bitmain. Flashed the firmware twice. Worked for about 3 days fine. Still thinking, probably right, a bug or controller board. Maybe the firmware update didn't fix all. Maybe I do have a bad Hash or controller board. It's weird. Interested in hearing from others who've flashed the firmware but still experience.

Hi Guys,

For me same thing...

However there seems to be a new firmware?
https://s3.cn-north-1.amazonaws.com.cn/shop-file-server/firmwares/Antminer%20D3/Firmware/00720170915192904493x4FcBXYX06A9/Antminer-D3-201711201715-0M.tar.gz

New: Antminer-D3-201711201715-0M.tar.gz vs Old: Antminer-D3-201711022227-0M.tar.gz

Have not tried it yet.

Are you also receiving less hardware errors when mining on dutchpool?
Do you have a normal duct tube connected from outside to the miner or do you have an external ventilator to assist the airflow?

New Firmware released Nov 20. Specifically to fix this issue. I'll flash and test over the holidays & report whether any success.

Where do you download the newest software for the D3?
Do you need to download it and insert it in "Flash new firmware image" or is there a command where the D3 downloads and installs the software by itself?

Hi,

Just use the web interface (system -> upgrade; bottom section select the tar.gz and upload the downloaded file the antminer flashes the firmware and reboots).

You can get it from here:
https://shop.bitmain.com/support.htm

(Menu On The left) Antminer D3 -> Firmware

Or direct link:
https://s3.cn-north-1.amazonaws.com.cn/shop-file-server/firmwares/Antminer%20D3/Firmware/00720170915192904493x4FcBXYX06A9/Antminer-D3-201711201715-0M.tar.gz

Just thought id share my experience with 50 of these toasters.

a bunch of them had red flashing lights and do not hash (7 of the 50)

it doesnt matter how much you restart the miner on the GUI, it does not matter if you upgrade firmware, the "socket refused" error is still present.

how to fix:

turn off miner at the wall, unplug the controller board 6pin, replug in controller board

turn on and problem is fixed

After upgrading to the latest firmware which is https://s3.cn-north-1.amazonaws.com.cn/shop-file-server/firmwares/Antminer%20D3/Firmware/00720170915192904493x4FcBXYX06A9/Antminer-D3-201711201715-0M.tar.gz I still get read_temp_func: can't read all sensor's temperature, close PIC and need reboot!!!

Anything I can do to fix this?

I have cool fan on D3, with soft tube on back to extract hot air outside.

Since i do firmware update i have less hw error (Not 20 nov. version for moment)

I dont know if is linked to dutch mining.

I wrote an mail to the Bitmain service.
The problem is the default frequency of the Antminer D3 with 19,3 Gh/s is already overclocked.
You need to change the frequency of your miner to 487 and then it will mine with 17 Gh/s but with 0 HW errors.

I underclocked my D3 to 487, this did not fix the issue. However what I did do was reflash the newest firmware a second time onto my D3, I have had zero issues and no furthers errors since.



EDIT: After 12 hours of mining the read temp function has occurred once, but it is far less then before.



BTC 1MaidYHDxpCwNWLaPrEeWtVxXtWFndhdUS
LTC LdeYLW7HYDjwFLKXzwvT8zGR1DeWcqVsnf

Did someone try out the different frequencies already and can report the different hashrates for each frequency? Mining with 0 hardware errors is good but the sacrifice of 2 GH/s is a lot, did someone find the perfect frequency alraedy?

And...No. It lasted 4 1/2 days before it X'd out again. 5 a.m. woke to fan speed at max, all basics out. I keep updating the firmware and running the dials on each chain, just results in chains 1 & 2 with oddly no HW errors, (and fan at 6k), chain 3 runs very hot with a lot of errors. I would think chain 3, or controller board. Bitmain just says unless the ASIC's X out, can't send create a warranty claim, nor will they take the entire miner back for warranty diags. So I'll try the cable unplug/reset next. And maybe I'll ramp up the frequency and diagnose the boards for much longer than the requested "20 Minutes".

Hey guys,


Extremely useful thread - so just wanted to say a big thank you.


Just got out D3 last week - they shipped the machine first and then the PSU -_-


Hooked it up today in our server room, plenty of ventilation and cool (sub 75 in there)

Once we had the D3 going, very first thing I noticed was a 19mh rate, then after we switched out the pool settings to miningpoolhub / zpool / poolmining.org (someone mentioned pools might be an issue?) it was up and running until I noticed one of the ASIC's went all Vin Diesel Triple X on us.

After that - I attempted a reboot + manual reboot and then updated the firmware with a few reboots in between. Prior to getting to the reboot - the ASIC (second one) went from XXX to not even showing up or registering which makes me think it's basically kaput.

Also noticed that the frequency settings came set as "Default" and I read in another thread that they should come with a specific number and if you change that number that it will void the warranty.

Any suggestions on what to do next?

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  :o) 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.

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!

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!

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

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 ?

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

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

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

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

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

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

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.

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

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.

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?

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.

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

Hi!

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

Thanks and bye, FNT

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

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?