Booting Linux on physical CPU 0x0
Linux version 4.6.0-xilinx-gff8137b-dirty (lzq@armdev2) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-23) ) #25 SMP PREEMPT Fri Nov 23 15:30:52 CST 2018
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: 203668K/245760K available (6345K kernel code, 231K rwdata, 1896K rodata, 1024K init, 223K bss, 25708K 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 80×30
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: 12668K (ccea2000 — 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 MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
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: 24/9, WL threshold: 4096, image sequence number: 262741923
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): recovery needed
UBIFS (ubi0:0): recovery completed
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 A9E8BDA4-70DE-45D9-83BE-2DD9F129C0C6, 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: 778/223, WL threshold: 4096, image sequence number: 3563076859
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): recovery needed
UBIFS (ubi1:0): recovery completed
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 A21581E4-693A-4BBF-A66A-FCE5ACD2EF7F, 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 = 0xab013
In fpga mem driver!
request_mem_region OK!
fpga mem virtual address is 0xd2000000
2021-06-11 04:29:56 driver-btm-api.c:630:init_freq_mode: This is scan-user version
2021-06-11 04:29:56 driver-btm-api.c:1979:bitmain_soc_init: opt_multi_version = 1
2021-06-11 04:29:56 driver-btm-api.c:1980:bitmain_soc_init: opt_bitmain_ab = 1
2021-06-11 04:29:56 driver-btm-api.c:1981:bitmain_soc_init: opt_bitmain_work_mode = 0
2021-06-11 04:29:56 driver-btm-api.c:1982:bitmain_soc_init: Miner compile time: Tue Sep 24 10:03:14 CST 2019 type: Antminer T17
2021-06-11 04:29:56 driver-btm-api.c:1983:bitmain_soc_init: commit version: 1d88fc4 2019-09-23 22:00:06, build by: lol 2019-09-24 10:12:38
2021-06-11 04:29:56 driver-btm-api.c:1800:show_sn: no SN got, please write SN to /nvdata/sn
2021-06-11 04:29:56 driver-btm-api.c:1134:miner_device_init: Detect 256MB control board of XILINX
2021-06-11 04:29:56 driver-btm-api.c:1082:init_fan_parameter: fan_eft : 0 fan_pwm : 0
2021-06-11 04:29:56 thread.c:771:create_read_nonce_reg_thread: create thread
2021-06-11 04:30:02 driver-btm-api.c:1066:init_miner_version: miner ID : 802c95864e10481c
2021-06-11 04:30:02 driver-btm-api.c:1072:init_miner_version: FPGA Version = 0xB013
2021-06-11 04:30:03 eeprom.c:431:check_pattern_test_level: L1 board
2021-06-11 04:30:03 driver-btm-api.c:704:get_product_id: product_id[2] = 1
2021-06-11 04:30:03 driver-btm-api.c:1623:get_ccdly_opt: ccdly_opt[2] = 1
2021-06-11 04:30:03 driver-btm-api.c:1864:bitmain_board_init: g_ccdly_opt = 1
2021-06-11 04:30:03 driver-btm-api.c:643:_set_project_type: project:2
2021-06-11 04:30:03 driver-btm-api.c:673:_set_project_type: Project type: Antminer T17
2021-06-11 04:30:03 driver-btm-api.c:684:dump_pcb_bom_version: Chain [2] PCB Version: 0x0100
2021-06-11 04:30:03 driver-btm-api.c:685:dump_pcb_bom_version: Chain [2] BOM Version: 0x0100
2021-06-11 04:30:09 driver-btm-api.c:1884:bitmain_board_init: Fan check passed.
2021-06-11 04:30:11 board.c:36:jump_and_app_check_restore_pic: chain[2] PIC jump to app
2021-06-11 04:30:15 board.c:40:jump_and_app_check_restore_pic: Check chain[2] PIC fw version=0xb9
2021-06-11 04:30:15 thread.c:766:create_pic_heart_beat_thread: create thread
2021-06-11 04:30:15 power_api.c:55:power_init: power init …
2021-06-11 04:30:15 driver-btm-api.c:1894:bitmain_board_init: Enter 30s sleep to make sure power release finish.
2021-06-11 04:30:15 power_api.c:46:power_off: init gpio907
2021-06-11 04:30:47 power_api.c:231:set_iic_power_to_highest_voltage: setting to voltage: 17.00 …
2021-06-11 04:30:48 power_api.c:123:check_voltage_multi: retry time: 0
2021-06-11 04:30:50 power_api.c:85:get_average_voltage: chain[2], voltage is: 21.406172
2021-06-11 04:30:50 power_api.c:96:get_average_voltage: aveage voltage is: 21.406172
2021-06-11 04:30:50 power_api.c:109:check_voltage: target_vol = 17.00, actural_vol = 21.41, more than 0.5v diff.
2021-06-11 04:30:51 power_api.c:123:check_voltage_multi: retry time: 1
2021-06-11 04:30:53 power_api.c:85:get_average_voltage: chain[2], voltage is: 19.734580
2021-06-11 04:30:53 power_api.c:96:get_average_voltage: aveage voltage is: 19.734580
2021-06-11 04:30:53 power_api.c:109:check_voltage: target_vol = 17.00, actural_vol = 19.73, more than 0.5v diff.
2021-06-11 04:30:54 power_api.c:123:check_voltage_multi: retry time: 2
2021-06-11 04:30:56 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.516094
2021-06-11 04:30:56 power_api.c:96:get_average_voltage: aveage voltage is: 18.516094
2021-06-11 04:30:56 power_api.c:109:check_voltage: target_vol = 17.00, actural_vol = 18.52, more than 0.5v diff.
2021-06-11 04:30:57 power_api.c:123:check_voltage_multi: retry time: 3
2021-06-11 04:30:59 power_api.c:85:get_average_voltage: chain[2], voltage is: 17.426191
2021-06-11 04:30:59 power_api.c:96:get_average_voltage: aveage voltage is: 17.426191
2021-06-11 04:30:59 power_api.c:181:set_iic_power_by_voltage: now set voltage to : 17.000000
2021-06-11 04:30:59 driver-hash-chip.c:233:dhash_chip_set_baud_v2: chain[2]: chip baud = 115200, chip_divider = 26
2021-06-11 04:30:59 uart.c:80:set_baud: set fpga_baud = 115200, fpga_divider = 26
2021-06-11 04:31:10 driver-btm-api.c:1009:check_asic_number_with_power_on: Chain[2]: find 30 asic, times 0
2021-06-11 04:31:12 driver-btm-api.c:347:set_order_clock: chain[2]: set order clock, stragegy 3 clock_en=0x1
2021-06-11 04:31:12 driver-hash-chip.c:490:set_clock_delay_control: core_data = 0xb4
2021-06-11 04:31:12 driver-hash-chip.c:233:dhash_chip_set_baud_v2: chain[2]: chip baud = 3000000, chip_divider = 0
2021-06-11 04:31:12 uart.c:80:set_baud: set fpga_baud = 3000000, fpga_divider = 0
2021-06-11 04:31:12 driver-btm-api.c:1650:check_clock_counter: freq 50 clock_counter_limit 6
2021-06-11 04:31:12 driver-hash-chip.c:233:dhash_chip_set_baud_v2: chain[2]: chip baud = 115200, chip_divider = 26
2021-06-11 04:31:12 uart.c:80:set_baud: set fpga_baud = 115200, fpga_divider = 26
2021-06-11 04:31:12 voltage[2] = 1690
2021-06-11 04:31:12 power_api.c:139:set_working_voltage: working_voltage = 16.900000
2021-06-11 04:31:13 temperature.c:282:calibrate_temp_sensor_one_chain: Temperature sensor calibration: chain 2 success.
2021-06-11 04:31:13 driver-hash-chip.c:233:dhash_chip_set_baud_v2: chain[2]: chip baud = 6000000, chip_divider = 7
2021-06-11 04:31:14 uart.c:80:set_baud: set fpga_baud = 6000000, fpga_divider = 3
2021-06-11 04:31:14 driver-btm-api.c:247:check_bringup_temp: Bring up temperature is 28
2021-06-11 04:31:14 thread.c:786:create_check_miner_status_thread: create thread
2021-06-11 04:31:14 thread.c:776:create_set_miner_status_thread: create thread
2021-06-11 04:31:14 driver-btm-api.c:580:calculate_timeout: dev->timeout = 392
2021-06-11 04:31:14 thread.c:761:create_temperature_monitor_thread: create thread
2021-06-11 04:31:14 freq_tuning.c:150:freq_tuning_get_max_freq: Max freq of tuning is 760
2021-06-11 04:31:14 power_api.c:378:slowly_set_iic_power_to_custom_voltage: slowly setting to voltage: 17.60 …
2021-06-11 04:31:41 power_api.c:123:check_voltage_multi: retry time: 0
2021-06-11 04:31:43 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.203818
2021-06-11 04:31:43 power_api.c:96:get_average_voltage: aveage voltage is: 18.203818
2021-06-11 04:31:43 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:31:44 power_api.c:123:check_voltage_multi: retry time: 1
2021-06-11 04:31:46 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:31:46 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:31:46 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:31:47 power_api.c:123:check_voltage_multi: retry time: 2
2021-06-11 04:31:49 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:31:49 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:31:49 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:31:50 power_api.c:123:check_voltage_multi: retry time: 3
2021-06-11 04:31:52 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:31:52 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:31:52 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:31:53 power_api.c:123:check_voltage_multi: retry time: 4
2021-06-11 04:31:55 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.197695
2021-06-11 04:31:55 power_api.c:96:get_average_voltage: aveage voltage is: 18.197695
2021-06-11 04:31:55 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:31:56 power_api.c:123:check_voltage_multi: retry time: 5
2021-06-11 04:31:58 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:31:58 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:31:58 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:31:59 power_api.c:123:check_voltage_multi: retry time: 6
2021-06-11 04:32:01 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.197695
2021-06-11 04:32:01 power_api.c:96:get_average_voltage: aveage voltage is: 18.197695
2021-06-11 04:32:01 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:32:02 power_api.c:123:check_voltage_multi: retry time: 7
2021-06-11 04:32:04 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:04 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:04 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:32:05 power_api.c:123:check_voltage_multi: retry time: 8
2021-06-11 04:32:07 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:07 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:07 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:08 power_api.c:123:check_voltage_multi: retry time: 9
2021-06-11 04:32:10 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.185449
2021-06-11 04:32:10 power_api.c:96:get_average_voltage: aveage voltage is: 18.185449
2021-06-11 04:32:10 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:11 power_api.c:123:check_voltage_multi: retry time: 10
2021-06-11 04:32:12 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:12 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:12 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:32:13 power_api.c:123:check_voltage_multi: retry time: 11
2021-06-11 04:32:16 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:16 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:16 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:17 power_api.c:123:check_voltage_multi: retry time: 12
2021-06-11 04:32:19 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:19 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:19 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:32:20 power_api.c:123:check_voltage_multi: retry time: 13
2021-06-11 04:32:21 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.185449
2021-06-11 04:32:21 power_api.c:96:get_average_voltage: aveage voltage is: 18.185449
2021-06-11 04:32:21 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:22 power_api.c:123:check_voltage_multi: retry time: 14
2021-06-11 04:32:24 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.197695
2021-06-11 04:32:24 power_api.c:96:get_average_voltage: aveage voltage is: 18.197695
2021-06-11 04:32:24 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:32:25 power_api.c:123:check_voltage_multi: retry time: 15
2021-06-11 04:32:28 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:28 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:28 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:32:29 power_api.c:123:check_voltage_multi: retry time: 16
2021-06-11 04:32:30 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.185449
2021-06-11 04:32:30 power_api.c:96:get_average_voltage: aveage voltage is: 18.185449
2021-06-11 04:32:30 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:31 power_api.c:123:check_voltage_multi: retry time: 17
2021-06-11 04:32:33 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:33 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:33 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:32:34 power_api.c:123:check_voltage_multi: retry time: 18
2021-06-11 04:32:36 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:36 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:36 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:37 power_api.c:123:check_voltage_multi: retry time: 19
2021-06-11 04:32:39 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.185449
2021-06-11 04:32:39 power_api.c:96:get_average_voltage: aveage voltage is: 18.185449
2021-06-11 04:32:39 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:40 power_api.c:123:check_voltage_multi: retry time: 20
2021-06-11 04:32:42 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:42 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:42 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:43 power_api.c:123:check_voltage_multi: retry time: 21
2021-06-11 04:32:45 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:45 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:45 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:46 power_api.c:123:check_voltage_multi: retry time: 22
2021-06-11 04:32:48 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.197695
2021-06-11 04:32:48 power_api.c:96:get_average_voltage: aveage voltage is: 18.197695
2021-06-11 04:32:48 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:32:49 power_api.c:123:check_voltage_multi: retry time: 23
2021-06-11 04:32:51 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:51 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:51 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:52 power_api.c:123:check_voltage_multi: retry time: 24
2021-06-11 04:32:54 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:32:54 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:32:54 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:55 power_api.c:123:check_voltage_multi: retry time: 25
2021-06-11 04:32:57 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.185449
2021-06-11 04:32:57 power_api.c:96:get_average_voltage: aveage voltage is: 18.185449
2021-06-11 04:32:57 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:32:58 power_api.c:123:check_voltage_multi: retry time: 26
2021-06-11 04:32:59 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.179326
2021-06-11 04:32:59 power_api.c:96:get_average_voltage: aveage voltage is: 18.179326
2021-06-11 04:32:59 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.18, more than 0.5v diff.
2021-06-11 04:33:00 power_api.c:123:check_voltage_multi: retry time: 27
2021-06-11 04:33:03 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.197695
2021-06-11 04:33:03 power_api.c:96:get_average_voltage: aveage voltage is: 18.197695
2021-06-11 04:33:03 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.20, more than 0.5v diff.
2021-06-11 04:33:04 power_api.c:123:check_voltage_multi: retry time: 28
2021-06-11 04:33:06 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:33:06 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:33:06 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:33:07 power_api.c:123:check_voltage_multi: retry time: 29
2021-06-11 04:33:08 power_api.c:85:get_average_voltage: chain[2], voltage is: 18.191572
2021-06-11 04:33:08 power_api.c:96:get_average_voltage: aveage voltage is: 18.191572
2021-06-11 04:33:08 power_api.c:109:check_voltage: target_vol = 17.60, actural_vol = 18.19, more than 0.5v diff.
2021-06-11 04:33:09 driver-btm-api.c:141:stop_mining: stop mining: power set failed!
2021-06-11 04:33:09 thread.c:832:cancel_check_miner_status_thread: cancel thread
2021-06-11 04:33:09 thread.c:806:cancel_temperature_monitor_thread: cancel thread
2021-06-11 04:33:09 thread.c:816:cancel_read_nonce_reg_thread: cancel thread
2021-06-11 04:33:09 driver-btm-api.c:127:killall_hashboard: ****power off hashboard****
My S17+ is not fully functioning. Chain#1 is missing from the miner status report. Does that mean I’m getting 2/3 of the hash rate with a 100% power draw (2920w)? Or the power draw would be proportionally lower, say 2/3 of 2920w?
It seems chain malfunction is a fairly common problem, but I want to make sure I’m still profitable using only two chains. It would be great if you can share your experience. Thank you!
BTW, the error I’m getting according to the Kernel log is the following:
2021-04-06 22:56:18 thread.c:976:asic_status_monitor_thread: ERROR: chain 1 get hashrate_reg_counter 20, require 65, failed times 1: ooooo ooooo ooooo ooooo xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
2021-04-06 22:56:18 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 0
2021-04-06 22:56:19 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 1
2021-04-06 22:56:19 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 0
2021-04-06 22:56:19 thread.c:996:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 0 times.
2021-04-06 22:56:19 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 1
2021-04-06 22:56:20 thread.c:976:asic_status_monitor_thread: ERROR: chain 1 get hashrate_reg_counter 20, require 65, failed times 1: ooooo ooooo ooooo ooooo xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
2021-04-06 22:56:21 thread.c:996:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 1 times.
2021-04-06 22:56:22 thread.c:976:asic_status_monitor_thread: ERROR: chain 1 get hashrate_reg_counter 20, require 65, failed times 1: ooooo ooooo ooooo ooooo xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
2021-04-06 22:56:22 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 0
2021-04-06 22:56:22 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 1
2021-04-06 22:56:23 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 0
2021-04-06 22:56:23 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 1
2021-04-06 22:56:23 thread.c:996:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 2 times.
2021-04-06 22:56:24 thread.c:976:asic_status_monitor_thread: ERROR: chain 1 get hashrate_reg_counter 20, require 65, failed times 1: ooooo ooooo ooooo ooooo xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
2021-04-06 22:56:25 thread.c:996:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 3 times.
2021-04-06 22:56:25 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 0
2021-04-06 22:56:26 thread.c:976:asic_status_monitor_thread: ERROR: chain 1 get hashrate_reg_counter 20, require 65, failed times 1: ooooo ooooo ooooo ooooo xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
2021-04-06 22:56:26 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 2, chip = 54, reg = 1
2021-04-06 22:56:26 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 0
2021-04-06 22:56:27 temperature.c:838:get_temp_info: read temp sensor failed: chain = 1, sensor = 3, chip = 50, reg = 1
2021-04-06 22:56:27 thread.c:996:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 4 times.
2021-04-06 22:56:27 thread.c:1000:asic_status_monitor_thread: chain 1 can’t get enough hashrate reg val for 5 times, power off.
Содержание
- Как устранить ошибку температуры в журнале Antminer T17
- I2c rw error status 0x4198fe00
- Вопрос
- Троян использует «режим Бога» Windows, чтобы спрятаться в системе
- Crash on OTA Update (IDFGH-1848) #231
- Comments
- Geend commented Jan 14, 2017
- michal037 commented Jan 14, 2017
- konrad282 commented Jan 14, 2017 •
- ustccw commented Jan 17, 2017
- ustccw commented Jan 17, 2017
- Scalpel78 commented Feb 4, 2017
- ppisljar commented Feb 19, 2017
- FayeY commented May 3, 2017
- ppisljar commented May 3, 2017
- Scalpel78 commented May 9, 2017
- gregstewart90 commented May 23, 2017
- chegewara commented Nov 20, 2017 •
- projectgus commented Nov 20, 2017
- chegewara commented Nov 21, 2017
- francescofcf commented Oct 3, 2018 •
- csibrak commented Oct 21, 2018 •
- javicordon commented Jan 24, 2019
- chegewara commented Jan 25, 2019
- javicordon commented Jan 25, 2019
Как устранить ошибку температуры в журнале Antminer T17
Как устранить ошибку температуры в журнале Antminer T17
Система контроля температуры майнера полагается на чип датчика температуры хэш-платы для предоставления данных в реальном времени для обнаружения. Различная хэш-плата может иметь несколько термочувствительных чипов, обычно расположенных рядом с хэш-чипом. Если чип не обнаружен при запуске майнера, хэш-плата не сработает.
Следует отметить, что микросхема датчика температуры обычно не повреждается. Когда возникает температурная ошибка, некоторые обслуживающие персонал напрямую заменяют чип датчика температуры, но неисправность не может быть устранена.
На самом деле проблема не в самом чипе. Скорее всего, это вызвано неисправной микросхемой U1 или последней микросхемой, или это может быть вызвано пониженным напряжением источника питания.
Если весь журнал майнера указывает на ошибку температуры, тогда мы можем сначала обновить прошивку. Если ошибка все еще отображается, проверьте силу тока на входе. Пониженное напряжение источника питания также не позволяет всей машине считывать температуру.
Например, следующая подсказка:
2020/04/27 04:15:48] WARN: chain[1] — 3 sensor(s) reported their temps!
[2020/04/27 04:16:02] ERROR: src/temp.c:218 chain[1] sen[2] — Lost, no updates for 10 sec
[2020/04/27 04:16:02] WARN: chain[1] — 2 sensor(s) reported their temps!
[2020/04/27 04:16:29] ERROR: src/temp.c:218 chain[1] sen[1] — Lost, no updates for 10 sec
[2020/04/27 04:16:29] WARN: chain[1] — 1 sensor(s) reported their temps!
[2020/04/27 04:17:29] INFO: Setting voltage from 17500 to 17400 mV gradually
[2020/04/27 04:17:39] ERROR: src/temp.c:218 chain[1] sen[3] — Lost, no updates for 10 sec
[2020/04/27 04:17:39] WARN: chain[1] — 0 sensor(s) reported their temps!
[2020/04/27 04:17:39] ERROR: driver-btm-chain.c:950 chain[1] — Failed to read temp from all sensors!
Если температура не может быть считана ни одной хэш-платой, ее необходимо снять и проверить с помощью тестером чипов антминер. Эта ситуация обычно вызвана неправильным хеш-чипом. Замените поврежденный чип, чтобы устранить неисправность.
Обратите внимание: использование хэш-платы от разных майнеров может привести к тому, что некоторая хэш-плата не сможет определить температуру. Поскольку версия хэш-платы отличается, используемая микросхема измерения температуры также может быть другой. Майнер распознает только одну программу прошивки на плате управления, остальные будут нечитаемыми.
Видеоурок по осмотру и ремонту хэш платы на примере модели: S9
(Методы обнаружения и восстановления большинства майнеров в Antminer в основном одинаковы)
Нажмите для просмотра: Видеоурок по ремонту и диагностике неисправностей AntminerS9.
Связанные инструменты обслуживания:
Официальный термореактивный гель — 220г
Новая версия многофункционального испытательного стенда
Инструмент для стружки олова
Нажмите, чтобы увидеть больше инструментов для обслуживания майнеров
Источник
I2c rw error status 0x4198fe00
Вопрос
We’re running various version of Ubuntu 14.04.2 LTS on Generation 2 Hyper-V Hosts. On a random Basis, the file system will be mounted Read-Only due to a «disk error» (which really isn’t the case here). As a result, we must reboot the Ubuntu guest to get the file system to mount RW again.
The Error we see is the following:
Apr 30 00:02:01 balticnetworkstraining kernel: [640153.968142] storvsc: Sense Key : Unit Attention [current]
Apr 30 00:02:01 balticnetworkstraining kernel: [640153.968145] storvsc: Add. Sense: Changed operating definition
Apr 30 00:02:01 balticnetworkstraining kernel: [640153.968161] sd 0:0:0:0: Warning! Received an indication that the operating parameters on this target have changed. The Linux SCSI layer does not automatically adjust these parameters.
Apr 30 01:23:26 balticnetworkstraining kernel: [645039.584164] hv_storvsc vmbus_0_4: cmd 0x2a scsi status 0x2 srb status 0x82
Apr 30 01:23:26 balticnetworkstraining kernel: [645039.584178] hv_storvsc vmbus_0_4: stor pkt ffff88006eb6c700 autosense data valid — len 18
Apr 30 01:23:26 balticnetworkstraining kernel: [645039.584180] storvsc: Sense Key : Unit Attention [current]
Apr 30 01:23:26 balticnetworkstraining kernel: [645039.584183] storvsc: Add. Sense: Changed operating definition
Apr 30 01:23:26 balticnetworkstraining kernel: [645039.584198] sd 0:0:0:0: Warning! Received an indication that the operating parameters on this target have changed. The Linux SCSI layer does not automatically adjust these parameters.
This relates to the VSS «Windows Server Backup» process that kicks off at midnight on the host and finishes an hour and half later.
Yes, we do have hv_vss_daemon and hv_kvp_daemon running for the correct kernel version we have. We’re currently running kernel version 3.13.0-49-generic #83 on one system and 3.16.0-34-generic #37 on the other. — We see the same errors on both.
As a result, we’ve been hesitant to drop any more ubuntu guests on our 2012R2 hyper-v system because of this. We can stop the backup process and all is good, but we need nightly backups to image all of our VM’s. All the windows guests have no issues of course. We also have some CentOS based guests running without issues from what we’ve seen.
Источник
Троян использует «режим Бога» Windows, чтобы спрятаться в системе
Как известно, в операционной системе Windows Vista, 7, 8 и 10 есть своеобразная пасхалка — GodMode (режим Бога). Начиная с версии Vista можно создать папку со специфическим именем, которая перенаправляет на настройки Windows или служебные папки, такие как «Панель управления», «Компьютер», «Принтеры» и проч.
Например, если создать на рабочем столе папку с названием GodMode. (вместо GodMode можно указать любые символы), то внутри будут отображаться все настройки, в том числе и те, которые не включены в меню «Панели управления» или «Параметры»: скриншот.
Очень удобная фича для управления настройками в системе и для системного администрирования.
К сожалению, режим Бога используют не только сисадмины, но и авторы вирусов.
Специалисты из антивирусной компании McAfee Labs рассказывают о трояне Dynamer, который использует режим Бога, чтобы скрыться от обнаружения в системе.
Dynamer при установке записывает свои файлы в одну из таких папок внутри %AppData%. В реестре создаётся ключ, который сохраняется после перезагрузки, запуская каждый раз бинарник зловреда.
Таким образом, исполняемый файл нормально запускается по команде из реестра, но вручную зайти в эту папку нельзя: как указано в списке выше, папка <241d7c96-f8bf-4f85-b01f-e2b043341a4b>работает как ярлык на настройки «Подключение к компьютерам и программам на рабочем месте» (RemoteApp and Desktop Connections).
Вот содержимое папки, если открыть её в проводнике.
Более того, авторы трояна добавили к названию папки «com4.», так что Windows считает папку аппаратным устройством. Проводник Windows не может удалить папку с таким названием.
Аналогично, удаление невозможно из консоли.
Нормальные антивирусы обходят этот трюк вирусописателей. Чтобы удалить папку вручную, нужно запустить из консоли следующую команду.
Троян Dynamer впервые обнаружен несколько лет назад, но Microsoft до сих пор считает его «серьёзной угрозой» для пользователей Windows.
В качестве бонуса.
Список имён папок (GUID) в режиме Бога для быстрого доступа к отдельным настройкам Windows
Источник
Crash on OTA Update (IDFGH-1848) #231
I’m trying to use the 25_ota example. Unfortunately the applications crashes right after making the http request to the webserver.
So here is the last uart output from the esp32:
And here is the core dump:
To me it seems like there is a problem trying to write to the flash.
The text was updated successfully, but these errors were encountered:
I have a similar problem but on something else.
#233
I had the same issue but helped chosing [*] Run FreeRTOS only on first core option in the project config.
In addition, I must modify the checking header code in resolve_pkg function because my hello_world.bin file starts with 0xE9 0x08 instead of 0xE9 0x09.
@konrad282 you are right! there is a mini-error in header check ,we should not check second bytes which present that segment counts.
@Geend @michal037 as @konrad282 mentioned, we should change FreeRTOS work on first core at make menuconfig ，while there are some control-logic errors when working on dual core.
So this is a bug? And it will be fixed?
I am trying to use esp_ota_begin from arduino core . i guess it won’t work there as i can’t force FreeRTOS to run on first core only ? or is there a way ? (sorry i know its not the right forum, but it is somehow related, and fixing the issue with running this on multiple cores should solve my problem as well)
Hi, this problem should have been solved now, isn’t it?
yup, seems to work well with the latest esp-idf
I’m still getting error with the latest esp-idf.
It fails with the error:
I (4984) ota: Connected to http server
I (4984) ota: Send GET request to server succeeded
I (4994) ota: Writing to partition subtype 16 at offset 0x110000
I (5554) ota: esp_ota_begin succeeded
E (5554) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x3c
E (5554) ota: Error: esp_ota_write failed! err=0x1503
I (5554) ota: Connection closed, all packets received
I (5564) ota: Total Write binary data length : 0
E (5564) ota: esp_ota_end failed!
E (5574) ota: Exiting task due to fatal error.
Error seems to originate at
if (it-> wrote_size == 0 && size > 0 && data_bytes[ 0 ] != 0xE9 ) <
Are you in the build directory or the root directory? I got this error if I wasn’t in the build directory.
cd /path/to/project/build python -m SimpleHTTPServer 8070
@projectgus Hi
Im having the same error (#231 (comment)) when im trying to update from external server, from internet. File is accessible and is proper compiled cause from lan app can read it and write to ota partition (veeeery slow but write it).
EDIT: not very slow, it just stop after 11KB write, and ota image is hello-world example. It stall for 5 minuts now, after last log line:
For errors like this:
E (5554) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x3c
0x3c is the ASCII code for , and suggests that the response payload is HTML not an app binary file. This usually happens if there is a HTTP server error.
Unfortunately the OTA example is only a poor imitation of an HTTP client which sends a very basic HTTP request and doesn’t check for an error in the result. We are working on an HTTP/HTTPS client library which will provide a much more useful (and safe) abstraction for HTTP connections.
Also, @chegewara has determined that the OTA example currently doesn’t send a valid HTTP/1.1 request at all. This will be updated to a valid HTTP/1.0 request, same as in the HTTP & HTTPS examples.
To diagnose problems with the OTA example:
- Look at the server logs for error responses to the HTTP request.
- Log the header response after the request and look for error messages, etc.
The proper HTTP/HTTPS client library should be available soon, and this example will be updated to use it.
Just found the issue in my ota app. I have set ota file path this way and it works from linux ubuntu 14 server from vbox on local machine (laptop), but it causes mentioned error if i try to ota flash from home server.
#define EXAMPLE_FILENAME «ota.bin»
But if i change file path to this one then i can ota flash from home server:
#define EXAMPLE_FILENAME «/ota.bin»
I have the same problem.
I do not have much knowledge about HTTP connections.
These are my tests:
From Internet :
No problem — Works fine OTA OK
downloads correctly the image.bin and upgrade the firmware
From Android:
SimpleHTTpServer — ubi.jp — Works fine OTA OK
HFS HTTP File Server 1.0 — vortexinfinitum — Works fine OTA OK
Http Server – streamingnology inc — Not works OTA error
Tiny Web Server – Leonardo Javier Russo — Not works OTA error
HTTP Server powered by Apache — Tautvydas Andrikys — Not works OTA error
IOS:
AirDisk -XUEHUI wu — Not works OTA error
Files – File Manager & Browser – Hian Zin Jong — Works fine OTA OK
Now I would like to build a custom app to perform OTA, but I would like to know what is the reason why a server works and another server does not.
Apache2 default conf. is keepalive=On.
It could cause trouble.
Simply turn it off on the server. (It has solved my issues with OTA.)
I hope this info could help you.
Just checking if ESP-IDF v3.3 implements an «error check» in the result of an HTTP request.
An OTA update sometimes doesn’t get all the binary data length.
If it does implement an «error check» I will do a more robust debug on why sometimes it does downloads full bin, and why sometimes it doesn’t.
If it doesn’t yet, I will be implementing a data length check before, and retry (by MQTT 1. Run OTA 2. URL 3. bin_size) as a work around.
Unfortunately the OTA example is only a poor imitation of an HTTP client which sends a very basic HTTP request and doesn’t check for an error in the result. We are working on an HTTP/HTTPS client library which will provide a much more useful (and safe) abstraction for HTTP connections.
The proper HTTP/HTTPS client library should be available soon, and this example will be updated to use it.
@chegewara Indeed, it is the one I am currently using.
The example works fine as described, local and over Internet Server. My question is orientated to the HTTP request used for OTA. (i.e. It doesn’t seem to be persistent in case of Response Timeout or Keep-alive Timeout, or error check.)
When you get a bin from a web server esp_http_client_fetch_headers(client) returns the size of the bin file, or -1 if any error. If there is a keep-alive timeout as it was happening to me (in the middle of reading data from http stream), then connection is closed anyway and continues with the OTA. It doesn’t verifies if the data data read is the same size as returned from the http header.
Of course it shows the errors E (19325) esp-tls: read error :-76: E (19325) TRANS_SSL: esp_tls_conn_read error, errno=No more processes followed by E (26301) esp_image: invalid segment length 0xffffffff E (26301) native_ota_example: esp_ota_end failed! E (26301) native_ota_example: Exiting task due to fatal error.
Knowing this may happen, it can be improved and get a safer version of the library.
We are working on an HTTP/HTTPS client library which will provide a much more useful (and safe) abstraction for HTTP connections.
As for now, I modified the Keep-alive parameters on the server, and double checking the OTA to be written («downloaded») has the same size as reported in http header.
Источник
ASIC-майнеры настроены на довольно быструю и эффективную добычу криптовалюты и стали популярны. Однако в их работе случаются сбои – падает хешрейт, нагревается оборудование, возможно возникновение серьезных ситуаций, таких как пожар. Чтобы не допустить этого, нужно постоянно мониторить статус ASIC, понимать его значение.
Структура ASIC-майнера состоит из нескольких частей – программного и аппаратного обеспечения. Программное обеспечение помогает управлять деталями оборудования и способно отслеживать напряжение электрического тока, а также интенсивность охлаждения, и сообщать о возможных неисправностях. Аппаратное обеспечение состоит из блока питания и вентиляторов, микропроцессоров и плат, блока памяти.
Одна из важнейших ошибок, о которых сообщает программное обеспечение, это “DISABLED”. Статус означает, что майнинг остановлен в связи с поломкой во избежание перегрева деталей. Нужно найти поломку и устранить ее. Чтобы возобновить майнинг после ремонта, необходимо дать команду “mining start”. Если оборудование непригодно для восстановления, то можно купить ASIC у нас.
Другие статусы:
- ERROR_TEMP_LOST означает потерю датчика температуры. После того, как определитель теряется 2 раза и более, майнинг останавливается во избежание перегрева.
- ERROR_EEPROM_INFO появляется при ошибке чтения. Чтобы устранить сбой, надо перепрошить EEPROM.
- ERROR_SOC_INIT означает ошибку инициализации драйвера из-за поломки аппаратной части или проблем с программным обеспечением – несоответствия его модели майнера или неправильной установки. Необходима диагностика аппаратной части и переустановка программного обеспечения или использование предыдущей его версии.
- ERROR_POWER_LOST означает проблемы с блоком питания из-за его поломки или программное обеспечение его не опознает.
- ERROR_FAN_LOST – это выход из строя кулера или дефект датчика.
- ERROR_TEMP_TOO_LOW. Буквально статус означает низкую температуру. Проблема кроется в программном обеспечении либо потере датчика температуры.
- SUSPENDED – статус, при котором требуется перезагрузка.
- TUNING означает проведение тюнинга, при котором скорость добычи криптовалюты может снизиться.
Если какая-то деталь не подлежит восстановлению, то купить все для майнинга вы сможете у нас.