T17/S17 malfunction: cases, solutions, remedies, RMA history - page 18.

The_binary_Observer

newbie

Activity: 11

Merit: 50

My friend mikeywith, I really appreciate your good words, thanks. About your question of keep it stock or overclocking, I rather underclocking them cut the blue wire from the fans and place the miner in a horizontal position instead of vertical so the chips on the boards also stay in horizontal position and that might help to keep them from falling easily. Also I observed that the base plate where the fans are attached are not completely open to the airflow as those in the S9. Those plates have metal fins forming squares in front of the fans and let me tell you those fins cause a disruption and some blockage of the airflow into de miner. In the past I did some experiment placing a simple air filter in front of the intake fans on S9, after few minutes of operation the miner's temperature raised exponentially in relation with a no air filter condition.

Based on that, I suspect that any obstruction of the air flow, no matter how small is can cause the temperature on the miner to raise abnormally high and relatively quick. The solution to this is to cut those stupid square fins that are in the fan base plate and leave them as those that come with the S9. Just keep the outer frame of the plate which is in reality where the plate and fans attach to the aluminum body of the miner.

About your question of which soldering paste to use, the BEST choice all over the board hands down is Kester TSF-6522. it can be bought on electronic specialty stores such as Digikey. This compound is specially good since is a tacky and NO CLEAN class which is very important. Due to the limited space between the hashing chips is absolutely necessary to leave no trace of soldering material around and within the chip that is about to be soldered.

Here is the link: https://www.digikey.com/products/en/soldering-desoldering-rework-products/flux-flux-remover/266

I hope this have helped many people around to understand what is really going on with this miners and to suggest to those that are willing to fix by themselves their miners to do it. Instead to spend the money by sending your machine, as Bitmain expects to do it, to Hong Kong, I rather buy the chips, the hot air soldering machine and soldering compound and do it myself. Yet, if you feel you are not able to do such a job find an electronic technician that have hot air soldering skills and ask to do the job, you can supply the hashing chips and the soldering paste.

To all good friends in this community I tell you guys WE ALL are on our own on this and if I were a lawyer I will be filling for a class action lawsuit against Bitmain. By the time and in the best of our interests let's find out how to solve our miners problems by ourselves so we can be back in business in a safe and low cost manner.

Best regards.

Quote from: favebook on May 26, 2020, 07:51:25 AM

... Would you mind setting up a ticket and telling them all of this? You might get a refund or some coupon or even a job offer there Cheesy

Friend Favebook, I already did and I'm really sick of "copy and paste" answers by someone called Jessica L. who is in charge of technical department.

favebook

sr. member

Activity: 604

Merit: 416

Quote from: The_binary_Observer on May 26, 2020, 12:53:23 AM

I have some background in electronics and analyzing those intermittent failures that these miners have just got me a little confused, specially during a time that I checked control boards and data cables by disconnecting back and forth.
At times the miner was full throttle mining just to drop after few hours. That in electronics is called a "cold soldering". Although there are not visible cold solderings I discovered that the soldering material that is being used on this S17 have 2 problems.

First, high amount of lead and low proportion of tin, and of course zero silver in the soldering material. This can be observed under the microscope used to soldering circuit boards. All of the solderings showed a greyish mate color and no shinning finish.

Second, below normal temperature of the soldering material, also leaves traces, specially on the hashing board chips. Also analyzed under the microscope there are traces that look like an sponge along with tiny cracks surrounding the chip's area at the surface of the hashing board.

What mikeywith said... We need more people like you, seriously!

Would you mind setting up a ticket and telling them all of this? You might get a refund or some coupon or even a job offer there Cheesy

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: The_binary_Observer on May 26, 2020, 12:53:23 AM

Since that soldering material is all over the hashing and controller boards is just a matter of time chips keep coming off the boards, the only and costly solution is to desoldering them all and soldering back with a good quality soldering flux, other than that those miners will keep failing over and over.

Basically most of the S17 series are doomed.

You have just explained 'scientifically' what I have been trying to tell everyone for months, dude we need more people like you around.

So, since the soldering melts at fairly low temp, will under-clocling these miners give any improvement in the lifespan of that tin before chips start falling? Or should someone just overclock the heck out of them because they will melt either way? Or leave them at stock?

Also what soldering flux do you suggest to use? A product link from Amazon will be great.

The_binary_Observer

newbie

Activity: 11

Merit: 50

Hello, I have been reading every single answer to this interesting post. This is because I have also been framed by Bitmain with those S17+ antminers. I have some background in electronics and analyzing those intermittent failures that these miners have just got me a little confused, specially during a time that I checked control boards and data cables by disconnecting back and forth. At times the miner was full throttle mining just to drop after few hours. That in electronics is called a "cold soldering". Although there are not visible cold solderings I discovered that the soldering material that is being used on this S17 have 2 problems.

First, high amount of lead and low proportion of tin, and of course zero silver in the soldering material. This can be observed under the microscope used to soldering circuit boards. All of the solderings showed a greyish mate color and no shinning finish.

Second, below normal temperature of the soldering material, also leaves traces, specially on the hashing board chips. Also analyzed under the microscope there are traces that look like an sponge along with tiny cracks surrounding the chip's area at the surface of the hashing board.

So, this takes me into the conclusion that somebody at Bitmain's is trying to cut ends and by doing this they have compromised 50% of the S17, T17 series. The use of soldering with high percentage of plumb just tells me that they are throwing the cheapest crap they have to solder the components on those miners. Also they are trying to reduce electricity costs by not heating well enough the soldering material melted at the trays and this is specially true because the soldering material with higher proportion-ratio of lead instead of tin and silver takes colder temperatures to melt.

So taking all this into consideration I really recommend to all of those that are willing to throw the money into shipping costs, customs fees and no mining income, just don't do it because Bitmain still uses the same bad quality materials to fix it.

Since that soldering material is all over the hashing and controller boards is just a matter of time chips keep coming off the boards, the only and costly solution is to desoldering them all and soldering back with a good quality soldering flux, other than that those miners will keep failing over and over.

Basically most of the S17 series are doomed.

PopoJeff

full member

Activity: 414

Merit: 182

I responded to customer service email, advising that I was not concerned with speed of repair/replacement, and asked if I could delay the return until CA is re-opened. Received a response that we could do just that, file a temporary repair ticket for CA, and update/renew as needed until CA reopened.

My business aspect is unique, in that this miner was bought almost completely with previous credit. I spent less than $200 total, including shipping and tariff. Plan was to bring in an almost free 70th unit, and sell the 50th unit, effectively getting paid to swap out and increase by 20th. But not doing that til I get a good unit.

So I unplug this thing on Wednesday to not waste power. Spend 2 days of emailing, and figure out I'm in a holding pattern. I plugged it back in Friday to fiddle with it again, and its running perfectly again with no errors almost 24hrs now. That tells me theres nothing wrong on my end network wise, if the errors come and go randomly.

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: PopoJeff on May 22, 2020, 04:32:04 AM

I responded asking for alternatives, as my shipping to CA is ~ $100, and to Hong Kong is ~$400-500. I'd rather wait for CA to reopen, than spend 4-5x shipping cost.

$400-500 + the time wasted from sending it to receiving it back will probably cause you to lose more than you will ever mine with that gear, they do have an address in Netherlands, I presume it would be cheaper and faster to ship it there, you need to ask them if you can send it there (obviously after checking the shipping price to that location), here is a list of all their repair sites.

PopoJeff

full member

Activity: 414

Merit: 182

Quote from: PopoJeff on May 19, 2020, 06:43:35 PM

Well, ran flawlessly since the above post.... 9 days. Then the whole thing dropped out today. That reg crc error returned, and the failure to read temp sensor error came back too.

Looking to figure out the return process this week.

Contacted Bitmain customer service and created a repair ticket to claim DOA since I'm still within my 30day window. But CA repair facility is closed due to CoronaVirus govt lockdown. Customer service asked me to ship it to the HONG KONG location. I responded asking for alternatives, as my shipping to CA is ~ $100, and to Hong Kong is ~$400-500. I'd rather wait for CA to reopen, than spend 4-5x shipping cost.

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: Scorpyy on May 19, 2020, 07:31:55 AM

So chip / heatsink issue on most of units, and yet Bitmain claims if heatsink is loose or chip is burned that warranty for that board is voided, so sad.

Are you sure about this? assuming you haven't disassembled the miner the warranty is still valid no? I honestly never understood their warranty program, when I read how they offered to send technicians to the mining farms in china to fix their faulty 17 series and how was Jihan wu "begging those miners to give Bitmain a second chance with the S19" it looks like and for obvious reasons, the way they treat large farms is way different than how they treat the average joe like ourselves, I don't want to keep repeating this but I hope this serves a lesson to avoid the 17 series, and not buy any 19 series mining gear until reports show that they have a reasonably low RMA/failure rate.

Today one of my friends lost the last working chain on his S17, it would show 0 Asics, sometimes more, it became unstable and useless, he bought that gear for 4k back then, most certainly way too far from ROIing on that gear.

PopoJeff

full member

Activity: 414

Merit: 182

Quote from: PopoJeff on May 10, 2020, 07:06:18 AM

Thanks so much for your help and sharing of knowledge.

Log looks good so far...

Well, ran flawlessly since the above post.... 9 days. Then the whole thing dropped out today. That reg crc error returned, and the failure to read temp sensor error came back too.

Looking to figure out the return process this week.

favebook

sr. member

Activity: 604

Merit: 416

Quote from: Scorpyy on May 19, 2020, 07:31:55 AM

So chip / heatsink issue on most of units, and yet Bitmain claims if heatsink is loose or chip is burned that warranty for that board is voided, so sad.

AFAIK that website wasn't changed since era of S9's. For T/S17 gear they know they fk-ed up and are replacing whole units without any real questions. For my S17 Pro (out of warranty) "repair" cost me $60 which is less than 40% of what I paid for shipping, so I was happy. But for bigger farms, I guess they do not even ask and just replace it with new unit for free.

Scorpyy

jr. member

Activity: 43

Merit: 59

Quote from: mikeywith on May 18, 2020, 08:41:28 PM

[...]

So chip / heatsink issue on most of units, and yet Bitmain claims if heatsink is loose or chip is burned that warranty for that board is voided, so sad.

Spooky123

newbie

Activity: 1

Merit: 0

If anybody has a S17 Pro hashboard that is burnt and can't warranty it, I am looking for one for core value. Just send me a PM. Thanks.

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: foncho86 on May 18, 2020, 07:19:28 PM

Found the other board has a faulty chip, when I was cleaining it.. the chip falled down with the heatsink.

Quote from: mikeywith on May 17, 2020, 07:09:47 PM

probably has a losen heatsink or a faulty chip somewhere

See that was an easy guess, in fact the T17e has a failure rate of 30%, the majority of that 30 % is the exact problem you have, so for everyone else reading this (probably in the near future) whenever you get a board showing 0 asic or temp-sensor issues, know that most of the time it's a chip/heatsink issue.

The good thing is that the chip you going to remove will have pre-tin solder on it, so you only need to heat it and you don't need any tin-tool for that, you can refer to this videoto get a better idea on how to replace the chip,

foncho86

newbie

Activity: 7

Merit: 2

Found the other board has a faulty chip, when I was cleaining it.. the chip falled down with the heatsink.. I would get a good chip from the burned board and trying to resolder.. I have a heat gun... and flux.. and all the equipment to repair it...

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: foncho86 on May 16, 2020, 06:11:55 PM

should I change the temp sensor..

Don't do that, it's very very highly unlikely that changing the sensor will fix anything, the board that shows 0 aasic probably has a losen heatsink or a faulty chip somewhere, if you think the cold start up is causing the issue then use a custom firmware, i think they have an option of warming up the chips that could help.

Quote

?? or should I remove all the heatsinks and clean it.. and put the heatsinks again?

NO!! , removing a heatsink is not something you can easily do, you need a few tools, let alone removing all of them, you will need a few days to do that and then that might not fix the issue.

Scorpyy

jr. member

Activity: 43

Merit: 59

If you can find new sensors and know how to replace them you can try that. If machine is still under warranty i would suggest you to just return it for repair.

Switching to Asic.to or Awesome miner firmware can help a little in some cases. By upclocking the boards, the machine runs on higher temp which causes less temp sensor errors. Also you can set miner to automatically reboot after board drops.

foncho86

newbie

Activity: 7

Merit: 2

I have one T17e, one card burned out the chips heatsinks came away made short-circuit, so I have two boards left, One is dead tells me 0 Asics. And the other one must to be placed at a warm place in order to startup and work, because a normal cold start-up doesn't come to live. Do you know what I should do to fix that in order to cold start my miner normaly.. not needed to warm it up to start it.. Huh

the problem that the board gives to me when it cold start is 0,then 4 then 6 Asics and ERROR_TEMP_LOST.. should I change the temp sensor..?? or should I remove all the heatsinks and clean it.. and put the heatsinks again? in order to heat the board over a faulty contact on the board?

Thanks for any help in advance..!!!

favebook

sr. member

Activity: 604

Merit: 416

Quote from: Scorpyy on May 11, 2020, 02:51:39 AM

Does anyone know can Bitmain tell if firmware was changed in the past if i revert it to original one?

AFAIK, no.

I had a machine which pooped 2 hashboards (on original BITMAIN firmware) and I tried custom one just to see if voltage change or frequency change would bring it alive (worked fine for some time), and then I decided to RMA it. Just returned to original firmware and they repaired it w/o questions.

It was in warranty.

Scorpyy

jr. member

Activity: 43

Merit: 59

Does anyone know can Bitmain tell if firmware was changed in the past if i revert it to original one?

PopoJeff

full member

Activity: 414

Merit: 182

Thanks so much for your help and sharing of knowledge.

Log looks good so far:

Code:

    
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Xilinx Zynq
cma: Reserved 16 MiB at 0x0e000000
Memory policy: Data cache writealloc
On node 0 totalpages: 61440
free_area_init_node: node 0, pgdat c0b39280, node_mem_map cde10000
  Normal zone: 480 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 61440 pages, LIFO batch:15
percpu: Embedded 12 pages/cpu @cddf1000 s19776 r8192 d21184 u49152
pcpu-alloc: s19776 r8192 d21184 u49152 alloc=12*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 60960
Kernel command line: mem=240M console=ttyPS0,115200 ramdisk_size=33554432 root=/dev/ram rw earlyprintk
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 203444K/245760K available (6345K kernel code, 231K rwdata, 1896K rodata, 1024K init, 223K bss, 25932K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xcf800000 - 0xff800000   ( 768 MB)
    lowmem  : 0xc0000000 - 0xcf000000   ( 240 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc090c424   (9234 kB)
      .init : 0xc0a00000 - 0xc0b00000   (1024 kB)
      .data : 0xc0b00000 - 0xc0b39fe0   ( 232 kB)
       .bss : 0xc0b39fe0 - 0xc0b71c28   ( 224 kB)
Preemptible hierarchical RCU implementation.
	Build-time adjustment of leaf fanout to 32.
	RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
efuse mapped to cf800000
ps7-slcr mapped to cf802000
L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
zynq_clock_init: clkc starts at cf802100
Zynq clock init
sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 4398046511103ns
clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x4ce07af025, max_idle_ns: 440795209040 ns
Switching to timer-based delay loop, resolution 3ns
clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 537538477 ns
ps7-ttc #0 at cf80a000, irq=18
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 666.66 BogoMIPS (lpj=3333333)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x100000 - 0x100058
CPU1: failed to boot: -1
Brought up 1 CPUs
SMP: Total of 1 processors activated (666.66 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xcf880000
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
media: Linux media interface: v0.10
Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti 
PTP clock support registered
EDAC MC: Ver: 3.0.0
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 12892K (cce6a000 - cdb01000)
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
futex hash table entries: 512 (order: 3, 32768 bytes)
workingset: timestamp_bits=28 max_order=16 bucket_order=0
jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-241330
dma-pl330 f8003000.ps7-dma: 	DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 158, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xdevcfg f8007000.ps7-dev-cfg: ioremap 0xf8007000 to cf86e000
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
loop: module loaded
CAN device driver interface
gpiod_set_value: invalid GPIO
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 31 (00:0a:35:00:00:00)
Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
Xilinx Zynq CpuIdle Driver started
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAGAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
nand: WARNING: pl35x-nand: the ECC used on your system is too weak compared to the one required by the NAND chip
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
6 ofpart partitions found on MTD device pl35x-nand
Creating 6 MTD partitions on "pl35x-nand":
0x000000000000-0x000002800000 : "BOOT.bin-env-dts-kernel"
0x000002800000-0x000004800000 : "ramfs"
0x000004800000-0x000005000000 : "configs"
0x000005000000-0x000006000000 : "reserve"
0x000006000000-0x000008000000 : "ramfs-bak"
0x000008000000-0x000010000000 : "reserve1"
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
zynq_pm_ioremap: no compatible node found for 'xlnx,zynq-ddrc-a05'
zynq_pm_late_init: Unable to map DDRC IO memory.
Registering SWP/SWPB emulation handler
hctosys: unable to open rtc device (rtc0)
ALSA device list:
  No soundcards found.
RAMDISK: gzip image found at block 0
EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ram0): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 1024K (c0a00000 - c0b00000)
EXT4-fs (ram0): re-mounted. Opts: block_validity,delalloc,barrier,user_xattr
random: dd urandom read with 0 bits of entropy available
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "configs", size 8 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 8/3, WL threshold: 4096, image sequence number: 237714726
ubi0: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 40
ubi0: background thread "ubi_bgt0d" started, PID 708
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 711
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "configs"
UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi0:0): FS size: 1396736 bytes (1 MiB, 11 LEBs), journal size 888833 bytes (0 MiB, 5 LEBs)
UBIFS (ubi0:0): reserved for root: 65970 bytes (64 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID FF09433B-E002-4C29-97EC-6220DDC4BB36, small LPT model
ubi1: attaching mtd5
ubi1: scanning is finished
ubi1: attached mtd5 (name "reserve1", size 128 MiB)
ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi1: good PEBs: 1020, bad PEBs: 4, corrupted PEBs: 0
ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi1: max/mean erase counter: 31/15, WL threshold: 4096, image sequence number: 3265111179
ubi1: available PEBs: 0, total reserved PEBs: 1020, PEBs reserved for bad PEB handling: 36
ubi1: background thread "ubi_bgt1d" started, PID 720
UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 723
UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "reserve1"
UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi1:0): FS size: 123039744 bytes (117 MiB, 969 LEBs), journal size 6221824 bytes (5 MiB, 49 LEBs)
UBIFS (ubi1:0): reserved for root: 4952683 bytes (4836 KiB)
UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 1AF6F1E1-61F0-462C-AE44-C7D9596CF7E2, small LPT model
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz
macb e000b000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
In axi fpga driver!
request_mem_region OK!
AXI fpga dev virtual address is 0xcfb38000
*base_vir_addr = 0xb023
In fpga mem driver!
request_mem_region OK!
fpga mem virtual address is 0xd2000000
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz
macb e000b000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
random: nonblocking pool is initialized
macb e000b000.ethernet eth0: link down
macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz
macb e000b000.ethernet eth0: link up (100/Full)
2020-05-09 22:33:00 driver-btm-api.c:741:init_freq_mode: This is scan-user version
2020-05-09 22:33:00 driver-btm-api.c:2413:bitmain_soc_init: opt_multi_version     = 1
2020-05-09 22:33:00 driver-btm-api.c:2414:bitmain_soc_init: opt_bitmain_ab        = 1
2020-05-09 22:33:00 driver-btm-api.c:2415:bitmain_soc_init: opt_bitmain_work_mode = 0
2020-05-09 22:33:00 driver-btm-api.c:2416:bitmain_soc_init: Miner compile time: Tue Apr  7 14:11:08 CST 2020 type: Antminer S17+
2020-05-09 22:33:00 driver-btm-api.c:2417:bitmain_soc_init: commit version: 0fa7066 2020-04-06 22:14:32, build by: lol 2020-04-07 14:17:53
2020-05-09 22:33:00 driver-btm-api.c:2045:show_sn: len:16, 8108ed0c2b10481c
2020-05-09 22:33:00 driver-btm-api.c:2423:bitmain_soc_init: show sn return 1
2020-05-09 22:33:00 driver-btm-api.c:2065:handle_sn_for_factory_mode: show sn return 1
2020-05-09 22:33:00 driver-btm-api.c:2103:handle_sn_for_factory_mode: read sn success, 8108ed0c2b10481c
2020-05-09 22:33:00 fan.c:279:front_fan_power_on: Note: front fan is power on!
2020-05-09 22:33:00 fan.c:291:rear_fan_power_on: Note: rear fan is power on!
2020-05-09 22:33:00 driver-btm-api.c:1276:miner_device_init: Detect 256MB control board of XILINX
2020-05-09 22:33:00 driver-btm-api.c:1217:init_fan_parameter: fan_eft : 0  fan_pwm : 0
2020-05-09 22:33:06 driver-btm-api.c:1201:init_miner_version: miner ID : 8108ed0c2b10481c
2020-05-09 22:33:06 driver-btm-api.c:1207:init_miner_version: FPGA Version = 0xB023
2020-05-09 22:33:12 driver-btm-api.c:799:get_product_id: product_id[0] = 0
2020-05-09 22:33:12 driver-btm-api.c:799:get_product_id: product_id[1] = 0
2020-05-09 22:33:12 driver-btm-api.c:799:get_product_id: product_id[2] = 0
2020-05-09 22:33:12 driver-btm-api.c:2196:update_conf_by_power_feedback: Power feedback is disabled
2020-05-09 22:33:12 driver-btm-api.c:2200:update_conf_by_power_feedback: get_calibration_voltage, vol:1970.
2020-05-09 22:33:12 frequency.c:1366:adjust_higer_max_vol_table: adjust_higer_max_vol_table, adjust_vol = 0
2020-05-09 22:33:12 thread.c:1066:create_read_nonce_reg_thread: create thread
2020-05-09 22:33:18 driver-btm-api.c:1201:init_miner_version: miner ID : 8108ed0c2b10481c
2020-05-09 22:33:18 driver-btm-api.c:1207:init_miner_version: FPGA Version = 0xB023
2020-05-09 22:33:23 driver-btm-api.c:799:get_product_id: product_id[0] = 0
2020-05-09 22:33:23 driver-btm-api.c:799:get_product_id: product_id[1] = 0
2020-05-09 22:33:23 driver-btm-api.c:799:get_product_id: product_id[2] = 0
2020-05-09 22:33:23 driver-btm-api.c:754:_set_project_type: project:0
2020-05-09 22:33:23 driver-btm-api.c:775:_set_project_type: Project type: Antminer S17+
2020-05-09 22:33:23 driver-btm-api.c:786:dump_pcb_bom_version: Chain [0] PCB Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:787:dump_pcb_bom_version: Chain [0] BOM Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:786:dump_pcb_bom_version: Chain [1] PCB Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:787:dump_pcb_bom_version: Chain [1] BOM Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:786:dump_pcb_bom_version: Chain [2] PCB Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:787:dump_pcb_bom_version: Chain [2] BOM Version: 0x0100
2020-05-09 22:33:23 driver-btm-api.c:2334:bitmain_board_init: Fan check passed.
2020-05-09 22:33:24 board.c:36:jump_and_app_check_restore_pic: chain[0] PIC jump to app
2020-05-09 22:33:26 board.c:40:jump_and_app_check_restore_pic: Check chain[0] PIC fw version=0x88
2020-05-09 22:33:27 board.c:36:jump_and_app_check_restore_pic: chain[1] PIC jump to app
2020-05-09 22:33:29 board.c:40:jump_and_app_check_restore_pic: Check chain[1] PIC fw version=0x88
2020-05-09 22:33:30 board.c:36:jump_and_app_check_restore_pic: chain[2] PIC jump to app
2020-05-09 22:33:32 board.c:40:jump_and_app_check_restore_pic: Check chain[2] PIC fw version=0x88
2020-05-09 22:33:32 thread.c:1061:create_pic_heart_beat_thread: create thread
2020-05-09 22:33:32 power_api.c:213:power_init: Power init:
2020-05-09 22:33:32 power_api.c:214:power_init: current_voltage_raw = 0
2020-05-09 22:33:32 power_api.c:215:power_init: highest_voltage_raw = 2100
2020-05-09 22:33:32 power_api.c:216:power_init: working_voltage_raw = 1950
2020-05-09 22:33:32 power_api.c:217:power_init: higher_voltage_raw  = 2040
2020-05-09 22:33:32 power_api.c:218:power_init: check_asic_voltage_raw  = 2100
2020-05-09 22:33:32 driver-btm-api.c:2344:bitmain_board_init: Enter 30s sleep to make sure power release finish.
2020-05-09 22:34:04 power_api.c:324:set_to_highest_voltage_by_steps: Set to voltage raw 2100, step by step.
2020-05-09 22:34:30 power_api.c:85:check_voltage_multi: retry time: 0
2020-05-09 22:34:31 power_api.c:40:_get_avg_voltage: chain = 0, voltage = 21.078507
2020-05-09 22:34:32 power_api.c:40:_get_avg_voltage: chain = 1, voltage = 21.151866
2020-05-09 22:34:33 power_api.c:40:_get_avg_voltage: chain = 2, voltage = 21.124679
2020-05-09 22:34:33 power_api.c:53:_get_avg_voltage: average_voltage = 21.118350
2020-05-09 22:34:33 power_api.c:71:check_voltage: target_vol = 21.00, actural_vol = 21.12, check voltage passed.
2020-05-09 22:34:33 uart.c:72:set_baud: set fpga_baud to 115200
2020-05-09 22:34:44 driver-btm-api.c:1096:check_asic_number_with_power_on: Chain[0]: find 65 asic, times 0
2020-05-09 22:34:56 driver-btm-api.c:1096:check_asic_number_with_power_on: Chain[1]: find 65 asic, times 0
2020-05-09 22:35:07 driver-btm-api.c:1096:check_asic_number_with_power_on: Chain[2]: find 65 asic, times 0
2020-05-09 22:35:15 driver-hash-chip.c:266:set_uart_relay: set uart relay to 0x330003
2020-05-09 22:35:15 driver-btm-api.c:397:set_order_clock: chain[0]: set order clock, stragegy 3
2020-05-09 22:35:15 driver-btm-api.c:397:set_order_clock: chain[1]: set order clock, stragegy 3
2020-05-09 22:35:15 driver-btm-api.c:397:set_order_clock: chain[2]: set order clock, stragegy 3
2020-05-09 22:35:16 driver-hash-chip.c:502:set_clock_delay_control: core_data = 0x34
2020-05-09 22:35:16 driver-btm-api.c:1854:check_clock_counter: freq 50 clock_counter_limit 6
2020-05-09 22:35:16 voltage[0] = 1960
2020-05-09 22:35:16 voltage[1] = 1960
2020-05-09 22:35:16 voltage[2] = 1960
2020-05-09 22:35:16 power_api.c:226:set_working_voltage_raw: working_voltage_raw = 1960
2020-05-09 22:35:17 temperature.c:340:calibrate_temp_sensor_one_chain: chain 0 temp sensor NCT218
2020-05-09 22:35:19 temperature.c:340:calibrate_temp_sensor_one_chain: chain 1 temp sensor NCT218
2020-05-09 22:35:20 temperature.c:340:calibrate_temp_sensor_one_chain: chain 2 temp sensor NCT218
2020-05-09 22:35:20 uart.c:72:set_baud: set fpga_baud to 12000000
2020-05-09 22:35:21 driver-btm-api.c:264:check_bringup_temp: Bring up temperature is 24
2020-05-09 22:35:21 thread.c:1081:create_check_miner_status_thread: create thread
2020-05-09 22:35:21 thread.c:1071:create_show_miner_status_thread: create thread
2020-05-09 22:35:21 thread.c:1051:create_temperature_monitor_thread: create thread
2020-05-09 22:35:21 freq_tuning.c:183:freq_tuning_get_max_freq: Max freq of tuning is 650
2020-05-09 22:35:21 driver-btm-api.c:1727:send_null_work: [DEBUG] Send null work.
2020-05-09 22:35:21 thread.c:1041:create_asic_status_monitor_thread: create thread
2020-05-09 22:35:21 frequency.c:1019:inc_freq_with_fixed_vco: chain = 255, freq = 510, is_higher_voltage = true
2020-05-09 22:35:41 frequency.c:1061:inc_freq_with_fixed_step: chain = 0, freq_start = 510, freq_end = 530, freq_step = 5, is_higher_voltage = true
2020-05-09 22:35:45 power_api.c:352:set_to_voltage_by_steps: Set to voltage raw 2090, step by step.
2020-05-09 22:35:47 power_api.c:85:check_voltage_multi: retry time: 0
2020-05-09 22:35:48 power_api.c:40:_get_avg_voltage: chain = 0, voltage = 20.907335
2020-05-09 22:35:49 power_api.c:40:_get_avg_voltage: chain = 1, voltage = 20.929306
2020-05-09 22:35:50 power_api.c:40:_get_avg_voltage: chain = 2, voltage = 20.902438
2020-05-09 22:35:50 power_api.c:53:_get_avg_voltage: average_voltage = 20.913027
2020-05-09 22:35:50 power_api.c:71:check_voltage: target_vol = 20.90, actural_vol = 20.91, check voltage passed.
2020-05-09 22:35:54 frequency.c:1061:inc_freq_with_fixed_step: chain = 2, freq_start = 510, freq_end = 530, freq_step = 5, is_higher_voltage = true
2020-05-09 22:36:02 frequency.c:1061:inc_freq_with_fixed_step: chain = 0, freq_start = 530, freq_end = 540, freq_step = 5, is_higher_voltage = true
2020-05-09 22:36:06 power_api.c:352:set_to_voltage_by_steps: Set to voltage raw 2080, step by step.
2020-05-09 22:36:08 power_api.c:85:check_voltage_multi: retry time: 0
2020-05-09 22:36:10 power_api.c:40:_get_avg_voltage: chain = 0, voltage = 20.760617
2020-05-09 22:36:11 power_api.c:40:_get_avg_voltage: chain = 1, voltage = 20.831620
2020-05-09 22:36:12 power_api.c:40:_get_avg_voltage: chain = 2, voltage = 20.780487
2020-05-09 22:36:12 power_api.c:53:_get_avg_voltage: average_voltage = 20.790908
2020-05-09 22:36:12 power_api.c:71:check_voltage: target_vol = 20.80, actural_vol = 20.79, check voltage passed.
2020-05-09 22:36:12 frequency.c:1090:inc_asic_diff_freq_by_steps: chain = 0, start = 540, freq_step = 5
2020-05-09 22:36:19 frequency.c:1090:inc_asic_diff_freq_by_steps: chain = 1, start = 510, freq_step = 5
2020-05-09 22:36:24 frequency.c:1090:inc_asic_diff_freq_by_steps: chain = 2, start = 530, freq_step = 5
2020-05-09 22:36:30 driver-btm-api.c:727:set_timeout: freq = 590, percent = 90, hcn = 44236, timeout = 74
2020-05-09 22:36:30 power_api.c:310:set_to_working_voltage_by_steps: Set to voltage raw 1960, step by step.
2020-05-09 22:36:35 power_api.c:85:check_voltage_multi: retry time: 0
2020-05-09 22:36:36 power_api.c:40:_get_avg_voltage: chain = 0, voltage = 19.586872
2020-05-09 22:36:37 power_api.c:40:_get_avg_voltage: chain = 1, voltage = 19.659384
2020-05-09 22:36:38 power_api.c:40:_get_avg_voltage: chain = 2, voltage = 19.610540
2020-05-09 22:36:38 power_api.c:53:_get_avg_voltage: average_voltage = 19.618932
2020-05-09 22:36:38 power_api.c:71:check_voltage: target_vol = 19.60, actural_vol = 19.62, check voltage passed.
2020-05-09 22:36:38 thread.c:1076:create_check_system_status_thread: create thread
2020-05-09 22:36:39 driver-btm-api.c:2577:bitmain_soc_init: Init done!
2020-05-09 22:36:39 driver-btm-api.c:216:set_miner_status: STATUS_INIT
2020-05-09 22:36:43 driver-btm-api.c:216:set_miner_status: STATUS_OKAY
2020-05-09 22:36:44 frequency.c:205:get_ideal_hash_rate_GH: ideal_hash_rate = 70780
2020-05-09 22:36:44 frequency.c:223:get_sale_hash_rate_GH: sale_hash_rate = 70000
2020-05-09 22:36:48 driver-btm-api.c:1458:dhash_chip_send_job: Version num 4.
2020-05-09 22:36:48 driver-btm-api.c:1606:dhash_chip_send_job: stime.tv_sec 1589063808, block_ntime 1589063797
2020-05-09 23:06:49 thread.c:257:calc_hashrate_avg: avg rate is 72269.23 in 30 mins
2020-05-09 23:06:49 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 57~79
2020-05-09 23:36:51 thread.c:257:calc_hashrate_avg: avg rate is 72034.49 in 30 mins
2020-05-09 23:36:51 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 56~79
2020-05-10 00:06:53 thread.c:257:calc_hashrate_avg: avg rate is 72525.06 in 30 mins
2020-05-10 00:06:53 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 57~79
2020-05-10 00:36:55 thread.c:257:calc_hashrate_avg: avg rate is 72206.55 in 30 mins
2020-05-10 00:36:55 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 57~79
2020-05-10 01:06:57 thread.c:257:calc_hashrate_avg: avg rate is 72373.74 in 30 mins
2020-05-10 01:06:57 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 58~80
2020-05-10 01:36:59 thread.c:257:calc_hashrate_avg: avg rate is 72084.52 in 30 mins
2020-05-10 01:36:59 temperature.c:516:temp_statistics_show:   pcb temp 40~63  chip temp 58~79
2020-05-10 02:07:01 thread.c:257:calc_hashrate_avg: avg rate is 72276.11 in 30 mins
2020-05-10 02:07:01 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 57~79
2020-05-10 02:37:03 thread.c:257:calc_hashrate_avg: avg rate is 72427.43 in 30 mins
2020-05-10 02:37:03 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 57~79
2020-05-10 03:07:05 thread.c:257:calc_hashrate_avg: avg rate is 72172.38 in 30 mins
2020-05-10 03:07:05 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 57~80
2020-05-10 03:37:07 thread.c:257:calc_hashrate_avg: avg rate is 72237.06 in 30 mins
2020-05-10 03:37:07 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 57~80
2020-05-10 04:07:09 thread.c:257:calc_hashrate_avg: avg rate is 72478.07 in 30 mins
2020-05-10 04:07:09 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 58~80
2020-05-10 04:37:11 thread.c:257:calc_hashrate_avg: avg rate is 72410.35 in 30 mins
2020-05-10 04:37:11 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 57~80
2020-05-10 05:07:13 thread.c:257:calc_hashrate_avg: avg rate is 72040.27 in 30 mins
2020-05-10 05:07:13 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 57~80
2020-05-10 05:37:16 thread.c:257:calc_hashrate_avg: avg rate is 72515.90 in 30 mins
2020-05-10 05:37:16 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 58~80
2020-05-10 06:07:17 thread.c:257:calc_hashrate_avg: avg rate is 72201.67 in 30 mins
2020-05-10 06:07:17 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 58~79
2020-05-10 06:37:20 thread.c:257:calc_hashrate_avg: avg rate is 72211.43 in 30 mins
2020-05-10 06:37:20 temperature.c:516:temp_statistics_show:   pcb temp 39~63  chip temp 58~79
2020-05-10 07:07:22 thread.c:257:calc_hashrate_avg: avg rate is 72297.47 in 30 mins
2020-05-10 07:07:22 temperature.c:516:temp_statistics_show:   pcb temp 40~63  chip temp 58~80
2020-05-10 07:37:24 thread.c:257:calc_hashrate_avg: avg rate is 72406.68 in 30 mins
2020-05-10 07:37:24 temperature.c:516:temp_statistics_show:   pcb temp 40~65  chip temp 58~80
2020-05-10 08:07:26 thread.c:257:calc_hashrate_avg: avg rate is 72187.64 in 30 mins
2020-05-10 08:07:26 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 58~79
2020-05-10 08:37:28 thread.c:257:calc_hashrate_avg: avg rate is 72241.33 in 30 mins
2020-05-10 08:37:28 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 58~80
2020-05-10 09:07:30 thread.c:257:calc_hashrate_avg: avg rate is 72516.51 in 30 mins
2020-05-10 09:07:30 temperature.c:516:temp_statistics_show:   pcb temp 40~63  chip temp 58~80
2020-05-10 09:37:32 thread.c:257:calc_hashrate_avg: avg rate is 72341.40 in 30 mins
2020-05-10 09:37:32 temperature.c:516:temp_statistics_show:   pcb temp 40~63  chip temp 57~80
2020-05-10 10:07:34 thread.c:257:calc_hashrate_avg: avg rate is 72287.09 in 30 mins
2020-05-10 10:07:34 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 58~79
2020-05-10 10:37:36 thread.c:257:calc_hashrate_avg: avg rate is 72598.28 in 30 mins
2020-05-10 10:37:36 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 57~80
2020-05-10 11:07:38 thread.c:257:calc_hashrate_avg: avg rate is 72505.53 in 30 mins
2020-05-10 11:07:38 temperature.c:516:temp_statistics_show:   pcb temp 39~64  chip temp 58~80
2020-05-10 11:37:40 thread.c:257:calc_hashrate_avg: avg rate is 72204.11 in 30 mins
2020-05-10 11:37:40 temperature.c:516:temp_statistics_show:   pcb temp 40~64  chip temp 58~80

Topic: T17/S17 malfunction: cases, solutions, remedies, RMA history - page 18. (Read 7029 times)