Jump to content

prahal

  • Posts

    17
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @wurmfood have you tried with all your usb devices unplugged ? Too much power drained (even if the devices have not changed in the meantime, the power of the helios64 might have lessened a bit) ? The USB-A are 900mA.
  2. I found a similar issue in the forum: The user https://forum.armbian.com/profile/16806-mortomanos/ was provided an armbian overlay that fixed his emmc -110 issue. But this overlay was not disclosed. Maybe you could ask him (and share the overlay or ask him to share the overlay). Alban
  3. Sorry it took me so long (investigating the hard freezes on my side took too much time, I hope to have a simple reproducer of the freeze one day). So with your u-boot instead of the current armbian one I noticed a new error at the point you get emmc failures [ 2.556749] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 2.627809] mmc1: Command Queue Engine enabled [ 2.628301] mmc1: new HS200 MMC card at address 0001 [ 2.629765] mmcblk1: mmc1:0001 AJTD4R 14.6 GiB [ 2.633459] mmcblk1: p1 [ 2.634455] mmcblk1boot0: mmc1:0001 AJTD4R 4.00 MiB [ 2.637466] mmcblk1boot1: mmc1:0001 AJTD4R 4.00 MiB [ 2.640380] mmcblk1rpmb: mmc1:0001 AJTD4R 4.00 MiB, chardev (241:0) [ 2.720113] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? that is the usb cable is bad (which could be power related). I do not have this error with current armbian helios64 u-boot. I noticed you boot from NVME and from Helios64_FCC_CE_Test_Manual_v0.2.pdf the M.2 Slot is for SATA SSD or USB 2.0 Device. Thus I suspect the M.2 port plus the power issue I suggest you to try to upgraded your u-boot and retry. With linux-u-boot-helios64-current at 21.08.9, do armbian-config > System > Install > and there from your logs it seems you should chose "5 Install/Update the bootloader on SD/eMMC" . If you want to restore to you current u-boot install: apt install linux-u-boot-helios64-current=21.08.2 EDIT: sorry I told you to chose ""3 Boot from eMMC - system on SATA, USB or NVMe", I copy pasted too fast (this would show a warning that tell you that the system partition will be rewritten so you might have guessed that it was a bad idea). "Install/Update the bootloader on SD/eMMC" is the way to update u-boot. Alban
  4. Do you mean all kernel from below 5.10.63 up to 5.10.63 ? If so could you report your serial console u-boot boot output ? 5.10.60 in https://mirrors.xtom.de/armbian/pool/main/l/linux-5.10.60-rockchip64/ are broken for most (all) of us. It would be really helpfull if an u-boot version could be related to working vs not working I found a bad commit in the kernel between 5.10.43 and 5.10.60 bu it makes no sense to me that it breaks emmc (though I don't know much about emmc) But if you manage to run 5.10.60 on emmc that would help us both. -110 means timeout attempting to contact the emmc,
  5. It turns out that zram could not be made big enough for both a big jellyfin collection and borg so zswap is the answer for me (without zram though due to above issue). As zram with a real swap file or partition is a bad idea due to LRU issue (once zram is filled swap of new content will only happen with the slower swap file). And having both zram and zswap looks weird (both will try to allocate RAM zram for its metadata and compressed items and zswap for its cache so more RAM lost for no added benefit. To sum up if swap requirements increase above what zram can offer (175% RAM even with 3:1 compression lzo compression , zstd being a little too cpu intensive for the helios64) turn to zswap with a quite big swap file or partition (12GiB) and disable zram.
  6. @TDCroPower OMV release are tied to a specific Debian release OMV 5 is buster only, OMV6 bullseye. OMV 6 should be pretty stable, a rc is close to release. As for the upgrade from google I get https://forum.openmediavault.org/index.php?thread/40927-omv-5-omv-6-upgrade/&postID=288759#post288759 and https://www.openmediavault.org/?p=3010 votdev: OMV5 systems with version 5.6.18 or later can be upgraded via the command line tool omv-release-upgrade. Please note that this migration path has not yet been tested with many systems. I cannot tell for certain but I believe omv-release-upgrade also upgrades Debian from buster to bullseye.
  7. @lanefu mind is your board rk3399 RAM DDR4 or DDR3 ? https://forum.armbian.com/topic/15047-nanopi-m4v2-randomly-crashes/page/2/?tab=comments#comment-111422 about nanopi M4V1 DDR3 being fine but nanopi M4V2 DDR4 instable.
  8. even though I disabled DVFS : $ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=conservative MAX_SPEED=1416000 MIN_SPEED=1416000 I had a few random reboot. I disabled zswap and , since I get this kind of trace about it: mars 30 22:15:29 helios64 kernel: ------------[ cut here ]------------ mars 30 22:15:29 helios64 kernel: kernel BUG at mm/zswap.c:1313! mars 30 22:15:29 helios64 kernel: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP mars 30 22:15:29 helios64 kernel: Modules linked in: binfmt_misc softdog veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge governor_performance aufs zram quota_v2 quota_tree ftdi_sio r8152 usbserial snd_soc_hdmi_codec leds_pwm snd_soc_rockchip_i2s snd_soc_rockchip_pcm gpio_charger pwm_fan snd_soc_core panfrost gpu_sched snd_pcm_dmaengine snd_pcm snd_timer snd hantro_vpu(C) soundcore rockchip_vdec(C) rockchip_rga rockchip_iep v4l2_h264 fusb302 videobuf2_dma_contig sg videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_sg tcpm videobuf2_memops videobuf2_v4l2 videobuf2_common typec videodev mc gpio_beeper cpufreq_dt nfsd dm_mod auth_rpcgss nfs_acl lockd grace sunrpc ledtrig_netdev lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear realtek raid10 uas dwmac_rk stmmac_platform mars 30 22:15:29 helios64 kernel: md_mod stmmac pcs_xpcs adc_keys mars 30 22:15:29 helios64 kernel: CPU: 4 PID: 3214 Comm: containerd-shim Tainted: G C 5.15.29-rockchip64 #trunk.0010 mars 30 22:15:29 helios64 kernel: Hardware name: Helios64 (DT) mars 30 22:15:29 helios64 kernel: pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) mars 30 22:15:29 helios64 kernel: pc : zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: lr : zswap_frontswap_load+0x218/0x330 mars 30 22:15:29 helios64 kernel: sp : ffff80000e363b10 mars 30 22:15:29 helios64 kernel: x29: ffff80000e363b10 x28: 000000000000094b x27: ffff0000f5526080 mars 30 22:15:29 helios64 kernel: x26: ffff800009b3d700 x25: 0000000000002690 x24: 00000000ffffffea mars 30 22:15:29 helios64 kernel: x23: ffff00000f2e9980 x22: ffff00000f2e9988 x21: ffff8000094f49c8 mars 30 22:15:29 helios64 kernel: x20: fffffbffeffcb170 x19: ffff00003319e4d0 x18: 00000000000000ff mars 30 22:15:29 helios64 kernel: x17: 00000000ffffffff x16: 0000000000000001 x15: 5165ca840ace4dcb mars 30 22:15:29 helios64 kernel: x14: ffff80000b7e257e x13: ffff80000b7e257e x12: 0000000000000001 mars 30 22:15:29 helios64 kernel: x11: ffff80000b08d6ad x10: 000000000000000b x9 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x8 : 0000000000000209 x7 : ffff80000e363a70 x6 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x5 : 0000000000000001 x4 : 0000000000000030 x3 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x2 : 0000000000000000 x1 : ffff000004f50e80 x0 : 0000000100000000 mars 30 22:15:29 helios64 kernel: Call trace: mars 30 22:15:29 helios64 kernel: zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: __frontswap_load+0x88/0x168 mars 30 22:15:29 helios64 kernel: swap_readpage+0x1a8/0x3c0 mars 30 22:15:29 helios64 kernel: do_swap_page+0x4e0/0x6c8 mars 30 22:15:29 helios64 kernel: __handle_mm_fault+0x5e4/0xdd0 mars 30 22:15:29 helios64 kernel: handle_mm_fault+0xe8/0x278 mars 30 22:15:29 helios64 kernel: do_page_fault+0x1e0/0x448 mars 30 22:15:29 helios64 kernel: do_translation_fault+0x58/0x68 mars 30 22:15:29 helios64 kernel: do_mem_abort+0x40/0xb0 mars 30 22:15:29 helios64 kernel: el0_da+0x24/0x58 mars 30 22:15:29 helios64 kernel: el0t_64_sync_handler+0x68/0xb8 mars 30 22:15:29 helios64 kernel: el0t_64_sync+0x180/0x184 mars 30 22:15:29 helios64 kernel: Code: 12800174 a9446bf9 17ffffc4 d4210000 (d4210000) mars 30 22:15:29 helios64 kernel: ---[ end trace 240751e909ea5fbc ]--- like https://bugzilla.kernel.org/show_bug.cgi?id=192571 . I was able to reproduce the above a few times with: stress -c 1 -m 16 --vm-keep but am unable today. As it seems zswap is useless on zram a swap, maybe it should be turned off either way. I disabled it by adding: extraargs=zswap.enabled=0 to /boot/armbianEnv.txt
  9. @fraz0815 Could you try to revert those kernel commits : 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related). see Those commits are proper fixes but trigger the emmc hs400 breakage on helios64 rockchip 3399 .
  10. prahal

    eMMC errors

    I have bisected the issue for helios64. See: Could you try to revert this commit and check the issue vanish ? You could also try to revert those commits against latest kernel : 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related). Point is that helios64 is not a mainline supported architecture (the patches for it are not upstream but only Armbian) so maybe you will be in a better position to report the regression upstream and have one investigate the roots of the regression.
  11. You should settle the dust down. First check where you mount /dev/mmcblk2p1. Do you: mount /dev/mmcblk2p1 /mnt or mount /dev/mmcblk2p1 /mount ? Because the content of the emmc will show up in the above command right directory. It will not be in /mount or /mnt if you did not made it so in the mount command. Second give use the emmc boot/armbianEnv.txt because it could be you set the sdcard armbianEnv.txt to boot with sdcard kernel and "rootdev" (ie boot partition) as emmc. Thus it works but you have to let the sdcard for the boot which is fragile. It ought ot contains: verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8 rootfstype=ext4 overlays=dwc3-0-host usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u only. "echo" and "> /mount/boot/armbianEnv.txt" where only there so you could paste the full command and have it write the armbianEnv.txt in /mount/boot for you. If you write them down in armbianEnv.txt it kills boot. Then feel free to update. I currenty run OMV with buster and armbian up to date on my helios64.
  12. If it is empty then you now know why u-boot fails to boot the kernl. Mine was filled with garbage due to the FS corruption (due to the emmc bug) Fill the emmc armbianEnv.txt with: echo 'verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8 rootfstype=ext4 overlays=dwc3-0-host usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u' > /mount/boot/armbianEnv.txt and reboot. You are done !
  13. Beware ! Do not change your sdcard /boot/armbianEnv.txt. Only the one of the emmc ! thus /mnt/boot/armbianEnv.txt if you mount /dev/mmcblk2p1 to /mnt . As I understood you checked the /boot/armbianEnv.txt of the Sdcard which is not right. If you boot from the sdcard then this one is correct, do not change it. But check your emmc one is not corrupted. Thus /mnt/boot/armbianEnv.txt and compare with the one I gave. As fsck showed your emmc partition was corrupted and fixed by fsck. Try to run fsck /dev/mmcblk2p1 as second time and paste output just to be confident it is now ok. Then when yoiu boot without sdcard try to force u-boot to boot from emmc. run bootcmd_mmc0 from u-boot prompt. Cheers. There are not many option for a failed boot. But check emmc not sdcard files. From your lsblk output : rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8
  14. check that eMMC boot/armbianEnv.txt contains: verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=a79a14c0-3cf4-4fb9-a6c6-838571351371 rootfstype=ext4 overlays=dwc3-0-host usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u Note rootdev=UUID= will be different. You can check your by running sudo blkid from the sdcard os. I believe yours is fine so you could also: fsck /dev/mmcblk2p1 when booting from sdcard (booting kernel that has the emmc fix only ! your log shows 5.10.63 armbian 22.08.2 so your are fine. But double check before fscking). Fscking will tell you if the filesystem is fine (readable/mountable by for one u-boot itself to start the kernel). My mmcblk2p1 boot/armbianEnv.txt content was wrong as I ran fsck when my emmc was unstable (this was a bad idea). Thus u-boot was unable to start the system. Restoring armbianENv.txt fixed my boot. The red is fine it is color for deb file type. just a note. The steps were to download from : root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-dtb-current-rockchip64_21.05.4_arm64.deb root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-headers-current-rockchip64_21.05.4_arm64.deb root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-image-current-rockchip64_21.05.4_arm64.deb not 5.10.63 ... but 5.10.63 will be fine too per ie 21.08.2 has the emmc fix.
  15. If you boot from sdcard while your previous system was on eMMC the ssh identification is different. If you want to connect to the sd card rescue system: ssh -o "UserKnownHostsFile /dev/null" -o StrictHostKeyChecking=no -o "PasswordAuthentication yes" root@helios64 I mean if your system is on eMMC and you boot from a sd card rescue system you have to tell ssh to ignore the host (and force password auth because the sd card system will not have public kay auth set up). about the failure at step 10 ... you should remove the sd card before boot (and your jumper mod) to boot from eMMC and all should be fine. Mind the process you followed did not tell to set the jumper 10 because it tells to switch boot media via u-boot prompt a command "run bootcmd_mmc1" for sd and "run bootcmd_mmc0" for eMMC. Doing both jumper 10 and u-boot bootcmd_mmc1 is undefined. Simply do one or the other not both. Cheers
×
×
  • Create New...