Title: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: jtlpowersports on July 25, 2022, 08:25:08 PM Hello all,
Over the weekend I had an issue in my mine that lead to some high humidity. I have 3 S19's now that are "on the fritz" One machine wont hash on any board, one only see's one board, and one sees two. I am assuming the humidity killed/damaged the PSU's or in a stroke of insane badluck I managed to have a ton of dirty hashboards all happen at once. Here is a log from one machine that is only seeing two hashboards. I have other logs I can send/post as well Code: ===========================================Miner log=========================================== Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: NotFuzzyWarm on July 25, 2022, 09:48:08 PM PLEASE use the code tag on that text wall to knock it down to scrollable box ... The icon for it is #
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: BitMaxz on July 25, 2022, 11:40:10 PM This is not a complete logs I guess and I think you already reach the character limit. I suggest use pastebin.com to paste the whole logs of your miner and share the URL here.
Have you tried to do the basic guide from Bitmain? Try to follow the guide below if it didn't work it might temp sensor issue. I also one you to try run miner only one hashboard and test them one by one and then post the changes here. Quote from: https://support.bitmain.com/hc/en-us/community/posts/900002377066-s19pro-fail-to-read-pic-temp-for-chain-0 1. Unplug the power cord 20 minutes then restart it again, 2. restore the antminer to the factory settings, 3. change the power supply, plug the cable, 4. upgrade to the latest firmware, 5. clean up the dust for the antminer 6. check the ambient temperature Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: GFDhd on July 26, 2022, 01:33:46 AM Are the logs of the other 2 S19 the same? According to the log of this S19, I think it may be a problem with the PIC chip. The log indicates that no data can be read from the board. Or check to see if there is a short circuit.
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: jtlpowersports on July 26, 2022, 02:26:29 AM sorry all I have fixed the box issue. Yes I have tried all the standard stuff, I wish this one was that simple. Machines were cleaned but they may need an ultrasonic bath, looks like the previous owner didn't treat em too well. They didnt skip a beat till this weekend though.
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: MinerMEDIC on July 26, 2022, 05:59:19 PM The power supply can be turned on for testing by placing a 220-470 Ohm resistor into pin 3&4 of the 6 pin control cable.
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: jtlpowersports on July 26, 2022, 08:58:00 PM check your PM's in regards to helping fix them
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: BitMaxz on July 26, 2022, 10:41:23 PM sorry all I have fixed the box issue. Yes I have tried all the standard stuff, I wish this one was that simple. Machines were cleaned but they may need an ultrasonic bath, looks like the previous owner didn't treat em too well. They didnt skip a beat till this weekend though. What do you mean they didn't skip a beat? Are the miner is now running fine? If you have a multimeter I'd like you to check the PIC chip on the hashboard if there is 3.3v supplying the PIC chip if there is no voltage or less there is a problem with other components not supplying enough power to your PIC chip. I hope that you have some repairing tools you can follow this guide below - https://www.zeusbtc.com/manuals/Antminer-S19-Pro-Hash-Board-Repair-Guide.asp If you don't have repairing tools then your last hope is to hire a technician you can check this https://www.zeusbtc.com/ASIC-Miner-Repair/ they do have a list of repair centers and maybe there is one near in your area. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: jtlpowersports on July 27, 2022, 02:17:43 PM I meant that they had 0 issues until this failure. I have a ton of s19's that have been rock solid.
Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: junaid00000 on August 02, 2023, 10:03:12 PM hell there,
did you manage to fix the miners? i have also 4 s19j pro and s19pros having same problem alll of sudden on a humid day when my internet disconnected for few hours and machines stopped mining and more moisture came in while their only fans were on. when i noticed i turned on the internet connection but the 3 s19 j pros didnt mine even after plenty of restart and cleaning and tried everything. here is the current log, it either show the init failed of temp too high 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 <giometti@linux.it> 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: 6716K (cd46b000 - cdafa000) 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 = 159, 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 cdns-i2c e0005000.ps7_i2c: 100 kHz mmio e0005000 irq 154 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: disable subpage write nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda nand: Micron MT29F2G08ABAEAWP nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 nand: NAND_ECC_HW nand: NAND_ECC_HW_SYNDROME mtd->writesize = 2048 ecc->strength = 1 ecc->size = 2048 mtd->writesize = 2048 chip->ecc_strength_ds = 4 chip->ecc_step_ds = 512 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 8 ofpart partitions found on MTD device pl35x-nand Creating 8 MTD partitions on "pl35x-nand": 0x000000000000-0x000002800000 : "BOOT.bin-dts-marker-kernel" 0x000002800000-0x000004800000 : "ramfs" 0x000004800000-0x000005000000 : "configs" 0x000005000000-0x000005200000 : "sig" 0x000005200000-0x000006000000 : "reserve1" 0x000006000000-0x000007000000 : "upgrade-ramfs" 0x000007000000-0x00000a800000 : "upgrade-file" 0x00000a800000-0x000010000000 : "reserve2" nf_conntrack version 0.5.0 (3635 buckets, 14540 max) ip_tables: (C) 2000-2006 Netfilter Core Team NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team 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 warning (device ram0): ext4_update_dynamic_rev:746: updating to rev 1 because of new feature flag, running e2fsck is recommended 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,errors=remount-ro devpts: called with bogus options 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: 31/11, WL threshold: 4096, image sequence number: 568867222 ubi0: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4 ubi0: background thread "ubi_bgt0d" started, PID 729 UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 733 UBIFS (ubi0:0): recovery needed UBIFS (ubi0:0): recovery completed UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "config_data" UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes UBIFS (ubi0:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs) UBIFS (ubi0:0): reserved for root: 275879 bytes (269 KiB) UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8AA49973-FBED-4276-9B03-FABAB307BF04, small LPT model ubi2: attaching mtd4 ubi2: scanning is finished ubi2: attached mtd4 (name "reserve1", size 14 MiB) ubi2: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi2: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi2: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi2: good PEBs: 112, bad PEBs: 0, corrupted PEBs: 0 ubi2: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi2: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 2250234571 ubi2: available PEBs: 0, total reserved PEBs: 112, PEBs reserved for bad PEB handling: 4 ubi2: background thread "ubi_bgt2d" started, PID 740 UBIFS (ubi2:0): background thread "ubifs_bgt2_0" started, PID 744 UBIFS (ubi2:0): recovery needed UBIFS (ubi2:0): recovery completed UBIFS (ubi2:0): UBIFS: mounted UBI device 2, volume 0, name "misc" UBIFS (ubi2:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes UBIFS (ubi2:0): FS size: 11935744 bytes (11 MiB, 94 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs) UBIFS (ubi2:0): reserved for root: 563754 bytes (550 KiB) UBIFS (ubi2:0): media format: w4/r0 (latest is w4/r0), UUID 14F4DB16-6076-4A66-A0F3-03AEEC528638, small LPT model ubi3: attaching mtd7 ubi3: scanning is finished ubi3: attached mtd7 (name "reserve2", size 88 MiB) ubi3: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi3: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi3: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi3: good PEBs: 700, bad PEBs: 4, corrupted PEBs: 0 ubi3: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi3: max/mean erase counter: 200/129, WL threshold: 4096, image sequence number: 1421215485 ubi3: available PEBs: 0, total reserved PEBs: 700, PEBs reserved for bad PEB handling: 0 ubi3: background thread "ubi_bgt3d" started, PID 751 UBIFS (ubi3:0): background thread "ubifs_bgt3_0" started, PID 755 UBIFS (ubi3:0): recovery needed UBIFS (ubi3:0): recovery completed UBIFS (ubi3:0): UBIFS: mounted UBI device 3, volume 0, name "nvdada_log" UBIFS (ubi3:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes UBIFS (ubi3:0): FS size: 86978560 bytes (82 MiB, 685 LEBs), journal size 4317184 bytes (4 MiB, 34 LEBs) UBIFS (ubi3:0): reserved for root: 4108212 bytes (4011 KiB) UBIFS (ubi3:0): media format: w4/r0 (latest is w4/r0), UUID BA75565F-2B88-4C4D-8B47-65635E1B699D, small LPT model IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready random: avahi-daemon urandom read with 2 bits of entropy available 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 0xcfc7c000 *base_vir_addr = 0xb042 In fpga mem driver! request_mem_region OK! fpga mem virtual address is 0xd2000000 ===========================================Miner log=========================================== 1970-01-01 00:00:10 Open miner sn file /config/sn error 1970-01-01 00:00:10 Miner compile time: Mon Dec 26 17:09:26 CST 2022 type: Antminer BHB42XXX sn : 1970-01-01 00:00:11 This is fix-freq version 1970-01-01 00:00:11 Miner compile time: Mon Dec 26 17:09:26 CST 2022 type: Antminer BHB42XXX 1970-01-01 00:00:11 commit version: f2ab6bc 2022-12-26 17:08:34, build by: jenkins 2022-12-26 17:09:25 1970-01-01 00:00:11 opt_multi_version = 1 1970-01-01 00:00:11 opt_bitmain_ab = 1 1970-01-01 00:00:11 mid_auto_gen = 0 1970-01-01 00:00:11 opt_bitmain_work_mode = 0 1970-01-01 00:00:11 mmap fpga_mem_addr_hal = 0xb5800000 1970-01-01 00:00:11 HASH_ON_PLUG V9 = 0x7 1970-01-01 00:00:11 Note: front fan is power on! 1970-01-01 00:00:11 Note: rear fan is power on! 1970-01-01 00:00:11 start the http log. 1970-01-01 00:00:11 httpListenThread start ret=0 1970-01-01 00:00:11 start listen on 6060 ... 2023-08-02 17:56:00 miner ID : 8110350e75104814 2023-08-02 17:56:00 FPGA Version = 0xB042 2023-08-02 17:56:00 HASH_ON_PLUG V9 = 0x7 2023-08-02 17:56:00 ==========================capability start========================== 2023-08-02 17:56:00 board num = 3 2023-08-02 17:56:00 board id = 0, chain num = 1 2023-08-02 17:56:00 chain id = 0 2023-08-02 17:56:00 board id = 1, chain num = 1 2023-08-02 17:56:00 chain id = 1 2023-08-02 17:56:00 board id = 2, chain num = 1 2023-08-02 17:56:00 chain id = 2 2023-08-02 17:56:00 ==========================capability end============================ 2023-08-02 17:56:00 chain num = 3 2023-08-02 17:56:00 skip loading levels for now 2023-08-02 17:56:07 load chain 0 eeprom data 2023-08-02 17:56:14 load chain 1 eeprom data 2023-08-02 17:56:21 load chain 2 eeprom data 2023-08-02 17:56:23 power open power_version = 0x71 2023-08-02 17:56:30 power is not Calibrated 2023-08-02 17:56:32 miner type: Antminer S19j Pro 2023-08-02 17:56:32 multi machine mode 2023-08-02 17:56:32 load machine BHB42601 conf 2023-08-02 17:56:32 machine : BHB42601 2023-08-02 17:56:32 chain_num 4, chain_domain_num 42, chain_asic_num 126, domain_asic_num 3 2023-08-02 17:56:32 abandon mix board! 2023-08-02 17:56:32 abandon mix board! 2023-08-02 17:56:32 fan_eft : 0 fan_pwm : 100 2023-08-02 17:56:32 create thread get_nonce_and_register_thread 2023-08-02 17:56:32 fixed working voltage = 1320 2023-08-02 17:56:32 fixed frequency is 525 2023-08-02 17:56:32 Chain
2023-08-02 17:56:32 Chain [1] BOM Version: 0x0020 2023-08-02 17:56:32 Chain [2] PCB Version: 0x0110 2023-08-02 17:56:32 Chain [2] BOM Version: 0x0020 2023-08-02 17:56:32 Fan check passed. 2023-08-02 17:56:33 chain[0] PIC jump to app 2023-08-02 17:56:34 Check chain[0] PIC fw version=0x89 2023-08-02 17:56:36 chain[1] PIC jump to app 2023-08-02 17:56:37 Check chain[1] PIC fw version=0x89 2023-08-02 17:56:39 chain[2] PIC jump to app 2023-08-02 17:56:40 Check chain[2] PIC fw version=0x89 2023-08-02 17:56:41 create thread pic_heart_beat_thread 2023-08-02 17:56:41 max sensor num = 4 2023-08-02 17:56:41 STATUS_INITED: soc init done! 2023-08-02 17:56:41 temperature_monitor_thread start... 2023-08-02 17:56:41 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:41 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:42 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:42 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:43 start to init... 2023-08-02 17:56:43 warning:power is not calibration. 2023-08-02 17:56:45 power type version: 0x0071 2023-08-02 17:56:45 Initializing the power, please wait, this may take up to 2 minutes... 2023-08-02 17:56:47 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:47 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:49 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:49 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:53 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:53 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:54 _pic_write_iic failed! read_back_data[0] = 0x3b, read_back_data[1] = 0x00 2023-08-02 17:56:54 pic_read_iic: select slave: 0x48, reg/command: 0x00 is failed 2023-08-02 17:56:57 over max temp, pcb temp 19 (max 75), chip temp 255(max 95) pcb temp rise 0 chip temp rise 0, total_exit_failure 6 2023-08-02 17:56:57 Sweep error string = J0:6. 2023-08-02 17:56:57 ERROR_TEMP_TOO_HIGH: over max temp 2023-08-02 17:56:57 stop_mining: over max temp 2023-08-02 17:56:57 uninit_temp_info 2023-08-02 17:56:57 do not read temp anymore... 2023-08-02 17:56:57 cancel thread 2023-08-02 17:56:57 cancel thread 2023-08-02 17:56:57 ****power off hashboard**** 2023-08-02 17:57:02 temp monitor thread exit 2023-08-02 17:57:26 Version num 8 2023-08-02 17:57:26 Mask num 0xe000 2023-08-02 17:57:26 freq = 525, percent = 90, hcn = 4993, timeout = 359 one of the machine was still mining on one hashboard but it also stopped and couldnt find any hashboards, they never had any issues before this incident. miners were not that dirty. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: paid2 on August 02, 2023, 10:58:24 PM hell there, did you manage to fix the miners? Hey Did you try both of the following solutions as per : Support Bitmain : s19pro fail to read pic temp for chain 0 (https://support.bitmain.com/hc/en-us/community/posts/900002377066-s19pro-fail-to-read-pic-temp-for-chain-0) ? Solution 1 (I guess that you already tried these steps ?) : Quote 1 Unplug the power cord 20 minutes then restart it again, 2 restore the antminer to the factory settings , 3 change the power supply, plug the cable, 4 upgrade to the latest firmware, 5 clean up the dust for the antminer 6 check the ambient temperature Solution 2 : Quote My importer has found a solution to this problem. 1. Disconnect all hashboards and flash the main board firmware 2. Connect only hashboard 1 and flash the firmware 3. Connect only hashboard 2 and flash the firmware 4. Connect only hashboard 3 and flash the firmware 5. Restart the miner with all hashboards connected. This has resoved the issue for two of my S19pro 110ths units. Hopefully it will work for others too Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: BitMaxz on August 02, 2023, 11:59:59 PM hell there, did you manage to fix the miners? i have also 4 s19j pro and s19pros having same problem alll of sudden on a humid day when my internet disconnected for few hours and machines stopped mining and more moisture came in while their only fans were on. when i noticed i turned on the internet connection but the 3 s19 j pros didnt mine even after plenty of restart and cleaning and tried everything. here is the current log, it either show the init failed of temp too high If the suggestion above does not work then that's a hardware issue sometimes temp too high is due to a broken ASIC chip that needs to be replaced or a loose heatsink that needs to be attached properly. It needs a BGA HotAir blower to replace the chip or to reattach the heatsink. But if you don't have tools then it would be better to hire a technician I already posted a link above where you can find a repair center. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: junaid00000 on August 03, 2023, 12:39:32 AM i appreciate the reply.
i had tried all bitmain basic steps many times, i also tried the flashing the hashboards one by one on my s19 pro but it didnt work, but ill try this on s19 j pro too before sending it to repair. my confusion is that both s19j pro broke same day after 2 years of mining after internet disconnection on a humid day. and same happend to two s19 pros. i recently contacted zzuis mining repair center but found out they are more expensive than bitmain repair guys. also please advice that should i send the whole miner or just the hashboards for repair, coz sending only hashboards for repair will massively reduce the shipping cost. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: philipma1957 on August 03, 2023, 01:24:41 AM burn a braiins+ sd card and see if you can run it on a 2600 watt clock.
I did that and my unit is now working. had a dead s19 pro that was doing 110th at 3200 watts. or 29 watts a th Loaded braiins+ auto tuning as I type. At the moment 104.6 th and 2640 watts which is 25.88 watts. I will post tune numbers soon. 18 minutes into the tune 106.9 and 24.73 watts https://www.talkimg.com/images/2023/08/01/QOeA8.png It will get better. Well hoping for it to get better. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: mikeywith on August 03, 2023, 01:45:18 AM my confusion is that both s19j pro broke same day after 2 years of mining after internet disconnection on a humid day. and same happend to two s19 pros. Do they run custom firmware? or did Bitmain change the way they operate when internet goes down, the stock firmware for the S7 and all the way to S17 took a good measure against this issue, even if your internet goes down, the miner would still generate heat, many folks didn't like that and thus custom firmware like Vnish decided to ditch it, so to save money on the power bill, they made it so that the miner goes to sleep mood when internet is down, while keeping the fan spinning, of course, that was a very stupid move on their behalf because when the weather is super humid and you get fans spinning lowering the miner's temp to dew point, your miners takes a shower and rests in peace. I don't own a S19 pro, but my guess, Bitmain started doing the same stupid shit, mining at a humid place with fans spinning and no heat generated = kaboom. Quote i recently contacted zzuis mining repair center but found out they are more expensive than bitmain repair guys. Do you mean Zeus? I don't think Zeus has any repair center outside of China, those are just listed by them no sponsored or guaranteed by ZeusBTC, they probably did a bit of due diligence before listing all those repair centers, but that doesn't mean much, my info could be outdated but a few years ago, I was told by the owner of ZeusBTC himself that they were not affiliated with those repair centers, maybe things changed so do reach out to them. As for other repair centers charging more than Bitmain, that's pretty normal, they are probably faster than Bitmain, sending your gear to Bitmain for repair is rather risky, I heard terrible stories of people waiting for ages to get their miner's back. Quote also please advice that should i send the whole miner or just the hashboards for repair, coz sending only hashboards for repair will massively reduce the shipping cost. If the miner is under warranty Bitmain wants you to always send the whole miner unless you manage to convince them otherwise, I did that once after a long debate with them, and ended up sending them only the bad control board, if it's just for repair that isn't under warranty I see no reason why they would force you to send the whole miner, unless they suspect the issue to be something else like PSU or CB. Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: junaid00000 on August 04, 2023, 04:48:13 AM Quote
1 Unplug the power cord 20 minutes then restart it again, 2 restore the antminer to the factory settings , 3 change the power supply, plug the cable, 4 upgrade to the latest firmware, 5 clean up the dust for the antminer 6 check the ambient temperature what does this mean in point number 3: change the power supply, plug the cable. does that mean i need to change the power supply unit?? or just the power supply. i have checked two s19j with flashing braiins sd card, they show the miners do start hashing but after 1-2 minutes the temperature sensor stops sending data and the hashing stops, all 3 boards starts hashing until the temperature stops working. i have tried reducing the power usage from braiins interface but it didnt work. what do you guys think, is it the psu unit or the temperature sensor? ( may be one temp sensor gone bad on each board due to high humidity and lost internet connection for hours and machines were on and fans were sending more humid air in cold machine) which seems unlikely...or may be its psu unit which broke due to high humidity which also seems unlikely i have now 4 machines all broke before 2 year of mining, 2 s19 pro already broke 6 months ago showing same problem of temperature. does any one tried bitmain usa or china repair center for repair? Title: Re: Need Help with diagnosing 3 S19's with possible PSU failure. Post by: EastCoastASICRepair on August 15, 2023, 09:35:55 PM There is a hashboard issue with Chain 2 reporting 0 ASIC. The "pic read" error likely doesn't have anything to do with the pic but rather the temperature sensor(s) that are failing to read or unstable chips.
|