[File transfers broken after recent updates]

My best guess is that the network driver for the 2.5 GbE NIC is broken, of course that could be unrelated to the updates. The relevant lines from dmesg appears to be:

 

[   11.812340] r8152 4-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256
[   11.827250] r8152 4-1.4:1.0 eth1: v2.14.0 (2020/09/24)

 

I will try to figure it out myself.

 

[  220.889619] ------------[ cut here ]------------
[  220.889683] NETDEV WATCHDOG: eth1 (r8152): transmit queue 0 timed out
[  220.889792] WARNING: CPU: 4 PID: 0 at net/sched/sch_generic.c:443 dev_watchdog+0x398/0x3a0
[  220.889802] Modules linked in: softdog xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink br_netfilter bridge governor_performance aufs quota_v2 quota_tree snd_soc_hdmi_codec r8152 snd_soc_rockchip_i2s snd_soc_core snd_pcm_dmaengine snd_pcm panfrost leds_pwm gpu_sched snd_timer snd hantro_vpu(C) pwm_fan gpio_charger soundcore rockchip_rga rockchip_vdec(C) videobuf2_vmalloc v4l2_h264 videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_memops fusb302 videobuf2_v4l2 videobuf2_common tcpm typec rockchipdrm dw_mipi_dsi videodev dw_hdmi analogix_dp drm_kms_helper mc sg cec rc_core drm drm_panel_orientation_quirks gpio_beeper cpufreq_dt lm75 sunrpc ip_tables x_tables autofs4 raid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx realtek md_mod dwmac_rk stmmac_platform stmmac pcs_xpcs
[  220.890423]  adc_keys
[  220.890449] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G         C        5.10.35-rockchip64 #21.05.1
[  220.890459] Hardware name: Helios64 (DT)
[  220.890474] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[  220.890487] pc : dev_watchdog+0x398/0x3a0
[  220.890499] lr : dev_watchdog+0x398/0x3a0
[  220.890508] sp : ffff800011c0bd50
[  220.890518] x29: ffff800011c0bd50 x28: ffff000004116880
[  220.890542] x27: 0000000000000004 x26: 0000000000000140
[  220.890565] x25: 00000000ffffffff x24: 0000000000000004
[  220.890587] x23: ffff8000118b7000 x22: ffff0000056ff41c
[  220.890609] x21: ffff0000056ff000 x20: ffff0000056ff4c0
[  220.890630] x19: 0000000000000000 x18: ffff8000118ded48
[  220.890651] x17: 0000000000000000 x16: 0000000000000000
[  220.890672] x15: 0000000000000294 x14: ffff800011c0ba10
[  220.890693] x13: 00000000ffffffea x12: ffff80001194ed80
[  220.890714] x11: 0000000000000003 x10: ffff800011936d40
[  220.890736] x9 : ffff800011936d98 x8 : 0000000000017fe8
[  220.890758] x7 : c0000000ffffefff x6 : 0000000000000003
[  220.890779] x5 : 0000000000000000 x4 : 0000000000000000
[  220.890800] x3 : 0000000000000103 x2 : 0000000000000102
[  220.890822] x1 : 7f083c788958b700 x0 : 0000000000000000
[  220.890844] Call trace:
[  220.890858]  dev_watchdog+0x398/0x3a0
[  220.890877]  call_timer_fn+0x30/0x1f8
[  220.890891]  run_timer_softirq+0x290/0x540
[  220.890905]  efi_header_end+0x160/0x41c
[  220.890922]  irq_exit+0xb8/0xd8
[  220.890935]  __handle_domain_irq+0x98/0x108
[  220.890953]  gic_handle_irq+0xc0/0x140
[  220.890965]  el1_irq+0xc0/0x180
[  220.890982]  arch_cpu_idle+0x18/0x28
[  220.890994]  default_idle_call+0x44/0x1bc
[  220.891008]  do_idle+0x204/0x278
[  220.891019]  cpu_startup_entry+0x28/0x60
[  220.891036]  secondary_start_kernel+0x170/0x180
[  220.891047] ---[ end trace 70adf4164f23c02e ]---
[  220.891106] r8152 4-1.4:1.0 eth1: Tx timeout
[  220.894064] xhci-hcd xhci-hcd.0.auto: bad transfer trb length 16744300 in event trb
[  220.894138] r8152 4-1.4:1.0 eth1: Tx status -2
[  220.894222] xhci-hcd xhci-hcd.0.auto: bad transfer trb length 16744300 in event trb
[  220.894265] r8152 4-1.4:1.0 eth1: Tx status -2
[  220.894337] xhci-hcd xhci-hcd.0.auto: bad transfer trb length 16744300 in event trb
[  220.894451] r8152 4-1.4:1.0 eth1: Tx status -2
[  220.894525] xhci-hcd xhci-hcd.0.auto: bad transfer trb length 16744300 in event trb
[  220.894567] r8152 4-1.4:1.0 eth1: Tx status -2
[  223.095841] usb 4-1.4: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd

 

That "Tx status -2" don't look right.

 

The 1 GbE connection seems to work fine. 

[File transfers broken after recent updates]

My Helios64 setup has been running stable for months now (except for one MOSFET that failed and had to be replaced), however after recent updates using the OMV5 package manager I am unable to transfer files to my computer (SMB shares). When trying to transfer to a Windows computer the transfer speed immediately plummets to 0, stays there forever or File Explorer crashes/stops responding. 

 

When transferring to an Ubuntu system the transfer time outs. 

I can browse the files on the SMB share, I can play them (movies, music, etc) or run them directly with no issues. 

 

I can transfer files using scp with no problem (just at much reduced speed/bandwidth). 

 

Version: 5.6.7-1

Kernel: 5.10.35-rockchip64

 

I was hoping for new updates to fix whatever is broken, but new updates won't install because of "unmet dependencies" and "you have held broken packages". So far this is for armbian-bsp-cli-helios64 21.05.2 and linux-buster-root-current-helios64 21.05.1

 

Anyone know what's wrong?

 

[Only HDD 1 & 2 power up]

16 hours ago, gprovost said:

@Ammonia Nice job :-) What was the casualties ?

Should have told you that better unsolder first the Molex connectors since they easily start to melt when expose to close to heatgun.

 

R144 and C129 disappeared into the 4th dimensions, as SMDs of that size has a tendency to do. I protected the connectors and the rest with some kapton tape, that worked well. I will put replacements of those passives back after the holidays, just need to get myself a smaller tip for the iron. Doubt that missing soft start will be an issue though.

[Only HDD 1 & 2 power up]

The MOSFET has now been replaced with a new one of the same model and all hard drives are now booting up as normal. It didn't go completely without any casualties, but shouldn't be an issue.

As I often ask myself, is that dust or some 0201s?

 

 

[Only HDD 1 & 2 power up]

2 hours ago, gprovost said:

@Ammonia Have you managed to fix it yourself ? If not please contact us to support@kobol.io

 

I ordered a replacement MOSFET (same model), including a drop-in replacement from vishay with better power ratings (just in case it should happen again). Unfortunately shipping is taking longer than it should. I temporarily bypassed the MOSFET to get all the hard drives to boot up so I could transfer the more important data. I was hoping fixing it would be faster than receiving a replacement board - and for me dealing with UPS is playing Russian roulette. Fixing it by replacing a 13-14 cent component is the better option for us both. Hopefully I won't ruin the board in the process!

[Only HDD 1 & 2 power up]

I did some more troubleshooting. The +5V HDD Rail A is present when no hard drives are connected, but drops to 0.8 V when the the drives are connected. It looks like the rail is enabled by a TDM3421 P-channel MOSFET?

 

Measuring the MOSFET with no load:

Gate = 3V, Source = 5V, Drain = 5V.

 

With the rail loaded:

Gate = 3V, Source = 5V, Drain = 0.85V

 

Is it implemented as a high-side switch? Any plans of releasing the schematic for the Helios64? I'm no electrical engineer but I suspect the MOSFET is faulty?

[Only HDD 1 & 2 power up]

I checked the +12V and +5V on the 15-pin power connector directly (that the hard drives plug into). All measure fine, but of course that is without a load connected.

 

In my case only the two hard drives connected to 12V HDD Rail B start up. Something wrong with the power staggering approach in bootloader?

 

dmesg output immediately after booting:

 

ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

ata3: SATA link down (SStatus 0 SControl 300)

ata4: SATA link down (SStatus 0 SControl 300)

ata5: SATA link down (SStatus 0 SControl 300)

[Only HDD 1 & 2 power up]

My Helios64 was running fine with 5 HDDs for a couple of weeks, then I suddenly couldn't access the shares anymore and I noticed only two HDDs were running (the rest having no indicator lights).

 

HDD slot 3, 4 and 5 appears "dead", no power up on boot, no indicator lights. I have checked both +12V and +5V rails and they are present, everything is plugged in. I can move the HDDs from slot 3, 4 and 5 to slot 1 and 2 and they will power up just fine. The hard drives also work in other machines.

 

I'm a bit lost as to what might be wrong, any ideas?